Tag Archives: penetration testiing

Pen Testing Active Directory Environments, Part VI: The Final Case

Pen Testing Active Directory Environments, Part VI: The Final Case

If you’ve come this far in the series, I think you’ll agree that security pros have to move beyond checking off lists. The mind of the hacker is all about making connections, planning several steps ahead, and then jumping around the victim’s network in creative ways.

Lateral movement through derivative admins is a good example of this approach. In this concluding post, I’ll finish up a few loose ends from last time and then talk about Active Directory, metadata, security, and what it all means.

Back to the Graph

Derivative admin is one of those very creative ways to view the IT landscape. As pen testers we’re looking for AD domain groups that have been assigned to the local administrator group and then discover those domain users that are shared.

The PowerView cmdlet Get-NetLocalGroup provides the raw information, which we then turn into a graph. I started talking about how this can be done. It’s a useful exercise, so let’s complete what we started.

Back in the Acme IT environment, I showed how it was possible to jump from the Salsa server to Avocado and then land in Enchilada. Never thought I’d get hungry writing a sentence about network topology!

With a little thought, you can envision a graph that lets your travel between server nodes and user nodes where edges are bi-directional. And if fact, the right approach is to use an undirected graph that can contain cycles, making it the inverse of the directed acyclic graph (DAG) that I discussed earlier in the series.

In plain English, this mean that if I put a user node on a server’s adjacency list, I then need to create a user adjacency list with that server. Here it is sketched out using arrows to represent adjacency for the Salsa to Enchilada scenario:  salsa-> cal    cal  -> salsa, avocado   avocado->cal,meg   meg->enchilada enchilada->meg

Since I already explained the amazing pipeline based on using Get-NetLocaGroup with –Recursive option, it’s fairly straightforward to write out the PowerShell (below). My undirected graph is contained in $Gda.


Unlike the DAG I already worked out where I can only go from root to leaf and not circle back to a node, there can be cycles in this graph. So I need to keep track of whether I previously visited a node. To account for this, I created a separate PS array called $visited. When I traverse this graph to find a path, I’ll use $visited to mark nodes I’ve processed.

I ran my script giving it parameters “salsa”, “enchilada”, and “avocado”, and it displays $Gda containing my newly created adjacency lists.


Lost in the Graph

The last piece now is to develop a script to traverse the undirected graph and produce the “breadcrumb” trail.

Similar to the breadth-first-search (BFS) I wrote about to learn whether a user belongs to a domain group, depth-first-search (DFS) is a graph navigation algorithm with one helpful advantage.

DFS is actually the more intuitive node  traversal technique. It’s really closer to the way many people deal with finding a destination when they’re lost. As an experienced international traveler, I often used something close to DFS when my local maps prove less than informative.

Let’s say you get to where you think the destination is, realize you’re lost, and then backtrack to the last known point where map and reality are somewhat similar. You then try another path from that point. And then backtrack if you still can’t find that hidden gelato café.

If you’ve exhausted all the paths from that point, you backtrack yet again and try new paths further up the map. You’ll eventually come across the destination spot, or at least get a good tour of the older parts of town.

That’s essentially DFS! The appropriate data structure is a stack that keeps track of where you’ve been. If all the paths from the current top of the stack don’t lead anywhere, you pop the stack and work with the previous node in the path – the backtrack step.

To avoid getting into a loop because of the cycles in the undirected graph, you just mark every node you visit and avoid those that you’ve already visited.

Finally, whatever nodes are already on the stack is your breadcrumb trail — the path to get from your source to destination.

All these ideas are captured in the script below, and you see the results of my running it to find a path between Salsa and Enchilada.


Stacks: it’s what you need when you’re lost.


From Salsa to Enchilada via way of Cal and Meg!

Is this a complete and practical solution?

The answer is no and no. To really finish this, you’ll also need to scan the domain for users who are currently logged into the servers. If these ostensibly local admin users whose credentials you want steal are not online, their hashes are likely not available for passing. You would therefore have to account for this in working out possible paths.

As you might imagine, in most corporate networks, with potentially hundreds of computers and users, the graph can get gnarly very quickly. More importantly, just because you found a path, doesn’t necessarily mean it’s the shortest path. In other words, my code above may chug and find a completely impractical path that involve hopping between say, twenty or thirty computers. It’s possible but not practical.

Fortunately, Andy Robbins worked out far prettier PowerShell code that addresses the above weaknesses in my scripts. Robbins uses PowerView’s Get-NetSession to scan for online users. And he cleverly employs a beloved computer science 101 algorithm, Dijkstra’s Shortest Path, to find the optimal path between two nodes.

Pen Testers as Metadata Detectives and Final Thoughts

Once I stepped back from all this PowerShell and algorithms (and had a few appropriate beverages), the larger picture came into focus.

Thinking like hackers, pen testers know that to crack a network that they’ve land in, they need to work indirectly because there isn’t (or rarely) the equivalent of a neon sign pointing to the treasure.

And that’s where metadata helps.

Every piece of information I leveraged in this series of posts is essentially metadata: file ACLs, Active Directory groups and users, system and session information, and other AD information scooped up by PowerView.

The pen tester, unlike the perimeter-based security pro, is incredibly clever at using this metadata to find and exploit security gaps. They’re masters at thinking in terms of connections, moving around the network with the goal of collecting more metadata, and then with a little luck, they can get the goodies.

I was resisting, but you can think of pen testers as digital consulting detectives — Sherlock Holmes, the Benedict Cumberbatch variant that is, but with we hope better social skills.

Here are some final thoughts.

While pen testers offer valuable services, the examples in this series could be accomplished offline by regular folks — IT security admins and analysts.

In other words, the IT group could scoop up the AD information, do the algorithms, and then discover if there are possible paths for both the derivative admin case and the file ACL case from earlier in the series.

The goal for them is to juggle Active Directory users and groups into a configuration that greatly reduces the risk of hackers gaining user credentials.

And ultimately prevent valuable content from being taken, like your corporate IP or millions of your customers’ credit card numbers.


Pen Testing Active Directory Environments, Part V: Admins and Graphs

Pen Testing Active Directory Environments, Part V: Admins and Graphs

If you’ve survived my last blog post, you know that Active Directory group structures can be used as powerful weapons by hackers. Our job as pen testers is to borrow these same techniques — in the form of PowerView — that hackers have known about for years, and then show management where the vulnerabilities live in their systems.

I know I had loads of fun building my AD graph structures. It was even more fun running my breadth-first-search (BFS) script on the graph to quickly tell me who the users are that would allow access to a file that I couldn’t enter with my current credentials.


The “Top Secret” directory on the Acme Salsa server was off limits with “Bob” credentials but available to anyone in the “Acme-Legal” group. The PowerShell script I wrote helped me navigate the graph and find the underlying users in Acme-Legal.

Closing My Graphs

If you think about this, instead of having to always search the same groups to find the leaf nodes, why not just build a table that has this information pre-loaded?

I’m talking about what’s known in the trade as the transitive closure of a graph. It sounds nerdier than it really needs to be: I’m just finding everything reachable, directly and indirectly, from any of the AD nodes in my graph structure.

I turned to brute-force to solve the closure problem. I simply modified my PowerShell scripts from last time to do a BFS from each node or entry in my lists and then collect everything I’ve visited. My closed graph is now contained in $GroupTC (see below).



Before you scream into your browsers, there are better ways do this, especially for directed graphs, and I know about the node sorting approach. The point here is to transcend your linear modes of thinking and view the AD environment in terms of connections.

Graph perfectionists can check this out.

Here’s a partial dump of my raw graph structure from last time:


And the same information, just for “Acme-VIPs”, that’s been processed with my closure algorithm:


Notice how the Acme-VIPs list has all the underlying users! If I had spent a little more time I’d eliminate every group in the search path from the list and just have the leaf nodes — in other words, the true list of users who can access a directory with Acme-VIPs access control permission.

Still, what I’ve created is quite valuable. You can imagine hackers using these very same ideas. Perhaps they log in quickly to run PowerView scripts to grab the raw AD group information and then leave the closure processing for large AD environments to an offline step.

There is an Easier Way to Do Closure

We can all agree that knowledge is valuable just for knowledge’s sake. And even if I tell you there’s a simpler way to do closure than I just showed, you’ll still have benefited from the deep wisdom gained from knowing about breadth first searches.

There is a simpler way to do closure.

As it turns out, PowerView cmdlets with a little extra PowerShell sauce can work out the users belonging to a top-level AD group in one long pipeline.

Remember the Get-NetGroupMember cmdlet that spews out all the direct underlying AD members? It also has a –Recurse option that performs the deep search that I accomplished with the breadth-first-search algorithm above.

To remove the AD groups in the search path that my algorithm didn’t, I can filter on the IsGroup field, which conveniently has a self-explanatory name. And since users can be in multiple groups (for example, Cal), I want a unique list. To rid the list of duplicates, I used PowerShell’s get-object –unique cmdlet.

Now for the great reveal: my one line of PS code that lists the true users who are underlying a given AD Group, in this case Acme-VIPs:


This is an amazing line of PowerShell for pen testers (and hackers as well), allowing them to quickly see who are the users  worth going after.

Thank you Will Schroeder for this PowerView miracle!

Commercial Break

It’s a good time to step back, take a deep breath, and look at the big picture. If you—IT security or admin team—don’t do the work of minimizing who has access to a directory, the hackers will effectively do if for you. I’ve just shown that with PowerView, they have tools to make this happen.

Of course, you bring in pen testers to discover these permission gaps and other security holes before the hackers.

Or there is another possibility.

Our blog’s generous sponsor, Varonis Systems, has been making beautifully crafted data access and governance solutions since Yaki Faitelson and Ohad Korkus set up shop in 2004. Their DatAdvantage solution has been helping IT admins and security pros find the underlying users who have access to files and directories.

Varonis: For over ten years, they’ve been saving IT from writing complicated breadth-first-search scripts!

Taking the Derivative of the Admin

Back to our show.

Two blog posts ago, I began to show how PowerView can help pen testers hop around the network. I didn’t go into much detail.

Now for the details.

A few highly evolved AD pen testers, including Justin Warner, Andy Robbins  and Will Schroeder worked out the concept of “derivative admin”, which is a more efficient way to move laterally.

Their exploit hinges on two facts of life in AD environments. One, many companies have grown complex AD group structures. And they often lose track of who’s in which group.

Second, they configure domain-level groups to be local administrators of user workstations or servers. This is a smart way to centralize local administration of Windows machines without requiring the local administrator to be a domain-level admin.

For example, I set up special AD groups Acme-Server1, Acme-Server2, and Acme-Server3 that are divided up among the Acme IT admin team members — Cal, Meg, Rodger, Lara, and Camille.

In my simple Acme network, I assigned these AD groups to Salsa (Acme-Server1), Avocado (Acme-Server3), and Enchilada (Acme-Server2) and placed them under the local Administrators group (using lusrmgr.msc).

In large real-world networks, IT can deploy many AD groups to segment the Windows machines in large corporate environments — it’s a good way to limit the risks if an admin credential has been taken.

In my Acme environment, Cal who’s a member of Acme-Server1, uses his ordinary domain user account to log into Salsa and then gain admin privileges to do power-user level work.

By using this approach, though, corporate IT may have created a trap for themselves.


There’s a PowerView command called Get-NetLocalGroup that discovers these local admins on a machine-by-machine basis.


Got that?

Get-NetLocalGroup effectively tells you that specific groups and users are tied to specific machines, and these users are power users!

So as a smart hacker or pen tester, you can try something like the following as a lateral move strategy. Use Get-NetLocalGroup to find the groups that have local admin access on the current machine. Then do the same for other servers in the neighborhood to find those machines that share the same groups.

You can dump the hashes of users in the local admin group of the machine you’ve landed on and then freely jump to any machine that Get-NetLocalGroup tells you has the same domain groups!

So once I dump and pass the hash of Cal, I can hop to any machine that uses Acme-Server1 as local admin group.

By the way, how do you figure out definitively all the admin users that belong to Acme-Server1?

Answer: use the one-line script that I came up with above that does the drill-down and apply it to the results of Get-NetLocalGroup.

And, finally, where does derived or derivative admin come into play?

If you’re really clever, you might make the safe assumption that IT occasionally puts the same user in more than one admin group.

As a pen tester, this means you may not be restricted to only the machines that the users in the local admin domain group of your current server have access to!

To make this point, I’ve placed Cal in Acme-Server1 and Acme-Server2, and Meg in Acme-Server2 and Acme-Server3.



Lateral movement by exploiting hidden connections in the Acme network.

If you’re following along at home, that means I can use Cal to hop from Salsa to Avocado. On Avocado, I use Meg’s credentials to then jump from Avocado to Enchilada.

On the surface it appears that my teeny three-machine network was segmented with three AD groups, but in fact there were hidden connections —Cal and Meg — that broke through these surface divisions.

So Cal in Acme-Server1 can get to an Acme-Server3 machine, and is ultimately considered a derivative admin of Enchilada!

Neat, right?

If you’re thinking in terms of connections, rather than lists, you’ll start seeing this as a graph search problem that is very similar in nature to what I presented in the last post.

This time, though, you’ll have to add into the graph, along with the users, the server names. In our make-believe scenario, I’ll have adjacency lists that tell me that Salsa is connect to Cal; Avocado is connected to Cal, Meg, Lara, and Roger; and Enchilada is connected to Meg and Camille.

I’ve given you enough clues to work out the PowerView and PowerShell code for the derivative admin graph code, which I’ll show next time.

As you might imagine, there can be lots of paths through this graph from one machine to another. There is a cool idea, though, that helps make this problem easier.

In the meantime, if you want to cheat a little to see how the pros worked this out, check out Andy Robbins’ code.

Continue reading the next post in "Pen Testing Active Directory Environments"

Pen Testing Active Directory Environments, Part II: Getting Stuff Done With...

Pen Testing Active Directory Environments, Part II: Getting Stuff Done With PowerView

In my last post, I began discussing how valuable pen testing and risk assessments can be done by just gathering information from Active Directory. I also introduced PowerView, which is a relatively new tool for helping pen testers and “red teamers” explore offensive Active Directory techniques.

To get more background on how hackers have been using and abusing Active Directory over the years, I recommend taking a look at some of the slides and talks by Will Schroeder, who is the creator of PowerView.

What Schroeder has done with PowerView is give those of us on the security side a completely self-contained PowerShell environment for seeing AD environments the way hackers do.

100% Raw PowerView

Last time I was crowing about crackmapexec, the Swiss-army knife pen testing tool, which among its many blades has a PowerView parameter. I also showed how you can input PowerView cmdlets directly.

However, the really interesting things you can do with PowerView involve chaining cmdlets together in a PowerShell pipeline. And—long sigh—I couldn’t figure out how to get crackmapexec to pipeline.

But this leads to a wondrous opportunity: download the PV library from GitHub and directly work with the cmdlets.

And that’s what I did.

I uploaded PowerView’s Recon directory and placed it under Documents\ WindowsPowerShell\Modules on one of the servers in my mythical Acme company environment. You then have to enter an Import-Module Recon cmdlet in PowerShell to load PowerView—see the instructions on the GitHiub page.

And then we’re off to the races.

Classy Active Directory

I already showed how it was possible to discover the machines on the Acme network, as well as who was currently logged in locally using a few crackmapexec parameters.

Let’s do the same thing with PowerView cmdlets.

For servers in the domain, the work is done by Get-NetComputer.


Notice how this is a little more useful than the nessus-like output of crackmapexec—we get the more nutritious AD server names and domain.

To find all the user sessions on my current machine, I’ll use the very powerful cmdlet Invoke-UserHunter. More power than I really need for this: it actually tells me all users currently logged in on all machines across the domain.

But this allows me then to introduce a PowerShell pipeline. Unlike in a Linux command shell, the output of a PowerShell cmdlet is an object, not a string, and that brings in all the machinery of the object-oriented model—attributes, classes, inheritance, etc. We’ll explore more of this idea below.

I present for your amusement the following pipeline below. It uses the Where-object cmdlet, aliased by the PowerShell symbol, and filters out only those user objects where the ComputerName AD attribute is equal to “Salsa”, which is my current server.


Note: the $_. is the way PowerShell lets you refer to a single object in a stream or collection of objects.

To see who’s on the Taco server, I did this instead:


Interesting! I found an Administrator.

One of the goals of pen testing is hunting down admins and other users with higher privileges. Invoke-UserHunter is the go-to cmdlet. Let’s store this thought away for the next post.

Another good source of useful information are the AD groups in the Acme environment. You can learn about organizational structure from looking at group names.

I used PowerView’s Get-NetGroup to query Active Directory for all the groups in the Acme domain. As the output sped by, I noticed, besides all the default groups, that there were a few group names that had Acme as prefix. It was probably set up and customized by the Acme system admin, which would be me in this case.

One group that caught my attention was the Acme-VIPs group.

It might be interesting to see this group’s user membership, and PV’s Get-NetGroupMember does this for me.


I now have a person of interest: Ted Bloatly, and obviously important guy at Acme.

Active Directory Treasures

At this point, I’ve not done anything disruptive or invasive. I’m just gathering information – under the hood PowerView, though is making low-level AD queries.

Suppose I want to find out more details about this Ted Bloatly person.

AD administrators are of course familiar with the Users and Computer interface through which they manage the directory (see below).



It’s also a treasure trove of information for hackers.

Can I access this using PowerView?

Through another PV cmdlet, Get-NetUser, I can indeed see all these fields, which includes phone numbers, home address, emails, job title, and notes.

Putting on my red team hat, I could then leverage this personal data in a clever phishing or pretext attack — craft a forged email or perhaps make a phone call.

I then ran Get-NetUser with an account name parameter directly, and you can see some of the attributes and their values displayed below.


However, as a cool pen tester I was only interested in a few of these attributes, so I came up with another script.

I’ll now use the PV cmdlet Foreach-Object, which has an alias of %.

The idea is to filter my user objects using the aforementioned Select-Object to only match on ted, and then use the Foreach-Object cmdlet to reference individual objects—in this case only ted—and its attributes. I’ll print the attributes using PowerShell’s Write-Output.

By the way, Get-NetUser displays a lot of the object’s AD attributes, but not all of them. Let’s say I couldn’t  find the attribute name for Ted’s email address.

So here’s where having a knowledge of Active Directory classes comes into play. The object I’m interested in is a member of the organizationalPerson class. If you look at the Microsoft AD documentation, you’ll find that this class has an email field, known by its LDAP name as “mail”.

With this last piece of the puzzle, I’m now able to get all of Ted’s contact information as well as some personal notes about him contained in the AD info attribute.


So I found Acme’s CEO and even know he’s a bowler. It doesn’t get much better than that for launching a social engineered attack.

As a hacker, I could now call it a day, and use this private information to later phish Ted directly, ultimately landing on the laptop of an Acme executive.

One can imagine hackers doing this on an enormous scale as they scoop up personal data on different key groups within companies: executives, attorneys, financial groups, production managers, etc.

I forgot to mention one thing: I was able to run these cmdlets using just ordinary user access rights.

Scary thought!

In my next post, we’ll instead to try to access Ted’s laptop more directly, and explore techniques of navigating around the Acme network.

Continue reading the next post in "Pen Testing Active Directory Environments"

Penetration Testing Explained, Part IV: Making the Lateral Move

Penetration Testing Explained, Part IV: Making the Lateral Move

You can think about the post-exploitation part of penetration testing as an army or rebel force living off the land. You’re scrounging around the victim’s website using what’s available — shells, networking utilities, berries, poorly protected password files, etc.

Kidding about the berries, but the idea is to import as little malware as possible and leverage what you find for more exploration and new attacks.

This whole topic goes under the name of “malware-less” hacking, which is much harder to detect than old-school techniques. Ed Skoudis noted in our interview last month that attackers are even starting to use PowerShell for their post-exploit work.

This next post in the series will focus on moving off the original hacked site — lateral movement in pen testing speak. I’ll be giving you some ideas about doing that with as little help from imported tools as possible.

Acme Company Domain

If you can find the goodies on the original target’s site, then you make a quick getaway. However, most hackers are not that lucky unless they land on the CEO’s laptop.

To make my penetration testing a little more realistic, I decided to set up a small domain, courtesy of Amazon Web Services. After a little hair-pulling (and reading this AWS document carefully), I installed a domain controller (with Active Directory and DNS) and then created two Windows servers.

I added two mythical employees — Jane and Bob — to a mythical company called Acme with a mythical domain name of acme.local. I then associated each employee with one of the servers. I enabled basic user networking capabilities on the domain controller through the User Rights Assignment group policy. But I prevented Jane and Bob from networking to each other’s computer to make the thing more interesting

I now will disclose that I made the server firewall less restrictive than was called for in the Amazon specs.

This is obviously a very rudimentary infrastructure, but who knows, it could describe a small system in a larger company or perhaps that of a third-party supplier, like an HVAC vendor.

Hacker Things to Know

As before I used a RAT to get a foothold on internal computer, in this case Jane’s Windows 2008 server. I uploaded two tools for my pen testing into Jane’s Documents directory: ncat, which I wrote about last time, and a utility known as psexec — check out this Technet article for parameter usage.

Both are in the gray area — they’re useful for IT admins as well as hackers — so if they’re spotted they’re not necessarily incriminating. I probably should have hid them in less obvious folder than Documents, but never mind.

more arp

Living off the land with arp, systeminfo, and findstr.

I launched a shell on Jane’s server through ncat, and then started the process of gathering information. My goal in testing is to think like a hacker: pull together bits of information and make a few inferences.

First, I entered the Windows hostname command to learn the name of the machine I’ve landed on (see above). The command returns “miller”.

Is that miller as in beer? Could it be the naming scheme is based on beer names?

The systeminfo command provides even more detailed technical nuggets: besides hostname, it displays IP address, OS name and version, and the domain name. All useful.

Let’s assume I’ve done a search for PII and haven’t found anything interesting. I’d like to find another server to hop onto. I could have uploaded nmap to scan for IP addresses, but I’m doing lean pen testing.

I instead ran the native arp –a to see what else is on the subnet. I’m in luck: the arp cache shows another machine in the neighborhood.

How do I hop onto it?

The Local Admin Loophole

That’s where psexec can, in theory, be of help. It’s a favorite of Ed’s and just about anyone who’s ever proudly called themselves an IT admin.

The command lets you remotely connect to another machine in the domain, letting you launch a shell or another Windows command. There’s also Windows netsh, which is less flexible, but also has remote capabilities.

The first problem for pen tester is that psexec requires the name of the remote computer (see syntax).  At this point, I only have the IP address.

You need to scavenge.

Over in the \Windows\system32 folder you’ll find nlsookup, the classic utility to query a DNS server for converting URLs to IP addresses and vice-versa. The Windows version lets you directly feed nslookup an IP address and it returns the DNS name.

I found that this remote machine is called amstel. So the IT admin is fond of beer names. I’ll file that away.

I tried this next:

psexec \\amstel.acme.local -u jane@acme.local cmd.exe

And unfortunately Windows rejects Jane’s account. There are two problems. In my role as an Acme admin, I didn’t allow Jane to log on to another machine. Second, Jane herself needs admin level privileges to run psexec, which she doesn’t have.

This is not that unusual in the real-world — you want to restrict average users from getting around the network.

But hackers and pen testers know a secret. Often there are local accounts with elevated permission on the machine they’ve landed on.

In the Windows-verse, there has been a long history of admin-level local accounts remaining on laptops and servers long after they’ve server their purpose, usually with the incredibly obvious user names of admin or administrator and guessable passwords — Admin1234 or some other simple pattern.

So hackers try to exploit this security hole by guessing the local admin’s password.

To be fair, the Microsoft folks have been aware of this problem, and they’ve disabled admin privileges on local accounts by default starting a few OS versions ago. And they also have discouraged the addition of local user accounts.

The Amazing Lateral Move

Though I had a limited tool set and could claim only slightly above average IT skills, I was hoping to say it was easy for me to OWN Bob’s server. That was not the case. I’ll go into the details about this in another post.

I can say the reverse shell technique using netcat is not entirely transparent. There were issues with entering text from my hacker machine into remote commands that issued prompts— most notably runas.

So to make this a more interesting pen testing post, I put my Acme IT admin hat back on and gave Jane elevated permissions. Jane’s domain account was still locked out from Bob’s server.


Psexec lets you run remote commands. Redirect output when tunneling through netcat!

Now as a pen tester, I can run psexec commands. Psexec has the desirable feature of allowing a password argument. In my current set up, I can now do a brute force attack on the local admin password on Bob’s server. I finally nailed it (see above).

I was also hoping to get psexec to pop a shell on Bob’s amstel server in my reverse-shell scenario. The best I could do was run a single shell command — no scripts — from the command line, and even that took some doing. Although I couldn’t come up with an easy approach to searching for PII and other strings in the remote directory, psexec was still useful.

The larger point is that with psexec, hackers and pen testers can search for admin accounts on domain machines. Yes, they can try to guess domain level passwords, but local admin is usually far more productive.

When all Else Fails, There’s ssh

I couldn’t help but come away from my first pen testing exercise with the sense that Windows makes it difficult to run commands remotely. Not impossible, but difficult.

I’m not the only one. IT admins have felt the pain as well. And that’s why they often install open-source ssh in their Windows infrastructures.

So it’s not unreasonable for an ssh server to be running. In my Acme IT role, I had previously set up freeSSHd’s version on Bob’s server.

Now with ssh in the picture, the doors begin to open up. Using my RAT, I uploaded and launched an ssh client app on Jane’s computer. And quicker than you can say Target, I was ssh-ed into Bob’s server using the local admin account I had worked out earlier. To pull this off, I had to take advantage of ssh’s port forwarding, which is another one of those sneaky features that pen testers enjoy using. I’ll explain this in another post.

My little adventure was meant as a learning experience for me and inspiration for your own in-house testing efforts. Professional pen-testers (and hackers) would likely be using more advanced tools, but as some of my former teachers liked to say while waving their hands: the concepts I’m describing are the same!

In my next post, we’ll looking at better techniques for grabbing credentials instead of trying to guess them.

Continue reading the next post in "Penetration Testing Explained"

Interview with Pen Testing Expert Ed Skoudis

Interview with Pen Testing Expert Ed Skoudis

We’re very excited to present this Q&A with Ed Skoudis. Skoudis is a very large presence in the security world. Here’s just a snippet from his lengthy bio: founder of Counter Hack, sought-after instructor at the SANS Institute, creator of NetWars CyberCity, and winner of the US Army’s Order of Thor Medal.

We focused our questions on some of the essentials of post-exploitation techniques. Skoudis set us straight on definitions and methodologies. His answers also nicely complement our own series on pentesting basics.

Inside Out Security: Let’s say you’ve entered a target system and installed an APT or RAT …

Ed Skoudis: I’m not sure APT is the proper word here.  One doesn’t install an “APT”. An APT is a threat actor, specifically a very skilled one. [See this definition of APT.]

Also, I’d prefer not to install a RAT during a penetration test.  There is no need for one in modern pen testing. RATs tend to be too heavyweight and intrusive. Traditional RATs usually provide GUI control of the machine and a bunch of splashy doodads that aren’t required by a penetration tester.

Instead, when compromising a machine, I like to use a light-weight payload, such as a Metasploit Meterpreter or related tool to get some form of shell access.

IOS: Ok, so after you’re in what would be the next four or five steps you’d take?

ES: After gaining a toe-hold on the target machine, I would:

  1.  Determine the privileges I’m running with.
  2.  Determine the machine’s location on the network and its network configuration, including looking at its network interfaces (it might be dual-homed), hostname, IP address, MAC address, ARP cache, and DNS cache.  It’s important to look for both IPv4 and IPv6 information from these sources, as many systems support IPv6 in addition to IPv4, and IPv6 tends not to get as much scrutiny from security tools as IPv4, making it a nice avenue of attack.
  3. Look for the active TCP connections this machine has with other systems, especially interesting protocols such as SMB (for Windows file sharing and domain authentication) or SSH (for secure remote shell).
  4. Check to see what security tools are installed, including anti-virus, application white listing, local firewall, etc.
  5. See if I can leverage its location on the network and active TCP connections to pivot to another host.

IOS: What are some must-have tools for post-exploitation?

ES: For Windows targets, there are plentiful PowerShell tools for privilege escalation, pillaging, and pivoting.  One of the very best suite of these tools is PowerShell Empire, which rolls together some incredible functionality from a variety of other projects.

In addition to PowerShell Empire, Metasploit itself includes dozens of post-exploitation modules useful for dumping hashes, grabbing crypto keys, getting environment information (including security defenses), and much more.

IOS: What are some techniques and tools for working out local network topology?

ES: I prefer to gain as much information from a compromised machine about the network around it as I can before resorting to intrusive (and easily discovered) scanning. That’s why I like to grab ARP cache, DNS cache, and a list of active TCP connections before moving on. That information tells me about other hosts that the currently compromised one knows about.  I’ll also grab the routing table, as it may indicate additional routers on the subnet.

After pillaging that local information from a system, I then start probing to look for other targets on the same subnet, as they will likely be more accessible than systems on separate networks. A ping sweep (IPv4) or a ping of a multi-cast address (IPv6) may turn up additional nearby hosts ripe for picking and which may have identical credentials to the system(s) I’ve currently compromised!

I then typically do small-scale port scans of very interesting ports to me, those associated with protocols where I may find more juicy attack surface, including TCP 21, 22, 23, 25, 80, 443, 445, 6000, and more.

IOS: How do you go about moving around the network?

ES: I use a variety of methods for lateral movement, including the pivoting features of Meterpreter’s msfconsole route command and portfwd commands are quite useful.

On systems where Netcat is already installed (most Linuxes), I rely on Netcat relays of various types, including listener-to-client relays, but also client-to-client and listener-to-listener relays.

On Windows targets, I really love the “netsh interface portproxy” feature to forward ports through the machine, especially its ability to listen on a given port on IPv4 and then shoot data out to another port using IPv6. As far as TCP is concerned at Layer 4, it’s a single connection.  But, we switch out the underlying Layer 3 protocol (from IPv4 to IPv6) underneath a single  TCP connection. It’s beautiful.

IOS: What are the some of the ways exfiltration of data can be accomplished without it being detected?

ES: First, encryption. In many organizations, simply sending the data across a TLS connection will get the job done.  Still, they may see the large transfer.  If I need to be more subtle, I’ll consider moving data across a command-and-control channel over DNS or related protocol.  A slow dribble is far less likely to be detected than a smash-and-grab, but will still demonstrate the business risk a professional pen tester is hired to show.

IOS: How does one search for PII and other sensitive content?

ES: Understanding the business use of a compromised machine is a vital step here.  What does the machine do, and where does it store its information to do that?  This usually gets me in the right direction.

I search using typical file system commands, such as cd, ls, find, grep, and so forth on Linux, and cd, dir, findstr, etc. on Windows.  In PowerShell on Windows, we have some additional great features for searching through the file system.

There are specific tools for finding things like social security numbers and credit cards on targets, but I find that they tend to produce a lot of disk access and noise in the target environment, another items that may get a pen tester noticed and perhaps even blocked.

IOS: Finally, any recent trends you can comment on?

ES: Yes, attacks using PowerShell are really on the rise, and there are some tremendous tools like PowerShell Empire for modeling such attacks in pen tests. Furthermore, attacks against Windows Kerberos are an increasing vector today.

IOS: Thanks Ed!