Main Content

Heya - HollyGraceful here, I make all of this content in my spare time, like it? Please support me :)
You can donate via Bitcoin or Patreon!

Hacking a Corporation From the Inside: Internal Penetration Tests

This is one part of a two part series, maybe take a look at Hacking a Corporation From the Outside: External Penetration Tests too!


Occasionally I get asked by clients how I approach the technical aspects of a Penetration Test, you know, what are all those little black boxes with green text that I’ve got open on my screen? Also occasionally, when I’m talking to new testers and people interested in becoming a penetration tester, they understand tool use and they often understand the specifics of vulnerabilities but don’t necessarily know how it all goes together.

Additionally, is filled with information on Infrastructure security, but there’s no guide about how it all fits together!  So I plan here, to write up a step-by-step example of how I go from plugging in to a corporate network and end up leaving that day as a Domain Administrator.

Every network is different, but my intention as ‘an attacker’ is generally the same and so this won’t be a complete guide to compromising networks, but hopefully will fill in some of the blanks for you if you’ve ever had a tester on site, are considering getting a tester to assess your security or if you’ve just cracked the spine on your first penetration testing book and want to know a little more about the full process.

Real World vs. Realistic

Something worth pointing out, is that when we conduct a penetration test, we’re often in a worse position than a real-world attacker would be. This generally due to penetration tests being restricted in scope, whilst attackers can play any card in the deck. Generally, when I’m performing an internal network assessment things such as social engineering, phishing, and external assets are out of scope. It’s a sort of assess one-thing-at-a-time approach. However as most penetration tests are done with the IT team being fully aware of activities, there’s no requirement to be “quiet” on the network, meaning scans can be ran as efficiently as possible with little requirement to hide activities.

Whereas a real attacker during their engagement will use a mix of techniques as required and likely starts the ‘internal’ aspect of an attack armed with a user account from the start – for example, by compromising credentials through a phishing campaign. The disadvantage that they have however is the obvious requirement to remain undetected.

Additionally a real attacker will have to enumerate the IP addressing scheme currently in use and where devices are. Whilst this is a trivial task and takes no real effort on the part of the attacker it should be noted that penetration testers cannot operate without accurate IP address information, the reason for this is legality. For a penetration testers to be able to perform an assessment, which would otherwise be illegal if not done in this setting, they require an accurate authority to work which must document exactly which systems they have permission to attack.

The Attack

When it comes to the attack, the actual act of plugging in and attacking a network, a methodology is followed – ask your penetration tester and they’ll be able to supply you with a written copy of their methodology – but remember, every network is different and every attack is different. A standard way for a tester to operate is to find the path of least resistance and use that to gain as high a privilege level as possible, then utilise this privilege level to find additional methods of entry.

A penetration test is not like vulnerability analysis. Generally with vulnerability analysis you will supply the assessor with a high level of information and privileges from the outset and they’ll perform authenticated scans of the network in order to determine all issues, or as many as possible. Vulnerability assessments generally grade issues independently and do not take in to account the real world exploit-ability of an issues or how issues can be chained together to increase their overall impact. It could be argued that a vulnerability assessment gives a wide, but not deep, impression of the security of the network and will highlight issues with systems such as patch management.

Whereas Penetration Tests aim to get as deep as possible and may sacrifice breadth to enable this, but will give a better idea of what a human attacker could pull off. These assessments will very likely involve actual exploitation of issues, the intentional compromising of systems, chaining of vulnerabilities, and will highlight the worst case scenario for a determined attacker aiming to gain a high level of access.

The tester will move through stages such as:

  • Enumeration and Mapping
  • Vulnerability Discovery
  • Exploitation
  • Lateral Movement
  • Privilege Escalation
  • Clean-up/Removal of Evidence

The tester may be lucky and move through these stages directly, potentially even utilising short cuts to skip some stages on the way to a complete compromise or they may be unlucky and have to effectively step back to try and bypass a protection mechanism.

Enumeration and Mapping

Generally any book that concentrates on Penetration Testing will have a large section devoted to enumeration, however most of the difficulty comes on external penetration tests. Once we’re inside the network there’s less work to do it’s simply a case of taking the in-scope addresses and determining what’s alive and what services are available, plus noting key systems like domain controllers.

One of the first things to find out though is the DNS suffix in use on the domain. There’s a few ways to get this information.

Finding the Domain

On linux you can use one of the following commands:

hostname -A
cat /etc/resolv.conf

on Windows you could use one of these:

wmic computersystem get domain
ipconfig /all

If you prefer Python, then here’s a one-liner, where you can supply a target machine IP:

python -c 'import socket; print socket.gethostbyaddr("TARGET-IP")[0];'
python -c 'import socket; print socket.gethostbyaddr("")[0];'

Finding Domain Controllers

From here you can gain a list of Domain Controllers for the domain too, using the DNS suffix – for example say the dns suffix is

set q=SRV

Finding Alive Hosts

It’s likely that the scope given by the client is just the local IP address space that they use, meaning that it’s likely that many of the in-scope IP addresses aren’t actually in use. Nmap is a simple yet powerful tool which has a decent capability to detect which hosts are alive, the default options are generally pretty good but usually I select -n (no name resolution) to keep the output list neat. I’ll usually go with something like this:

sudo nmap -iL scope.txt -n -oN alive-scan.txt -sn

This is the default host discovery check against a list of IP addresses (given in the text file scope.txt) with no name resolution (so all output is consistent), output in Nmap’s default form to the file alive-scan.txt, with no port scanning except the default host discovery ports. This is the equivalent of this command:

sudo nmap -iL scope.txt -n -oN alive-scan.txt -sn -PE -PS443 -PA80 -PP

Nmap should be ran as root so that it can make use of ‘incorrect’ TCP sequences, such as those specified by -PS443 and -PA80 (just a TCP SYN to 443,  and just an ACK to TCP 80) otherwise it will require to do a full TCP connection. The resulting list of Nmap output can be cleaned up further with a command like this:

cat alive-scan.txt | grep "report for" | awk '{print $5}' | tee alive-IPs.txt

The above command will display a list of IP addresses for alive hosts and also save that list to the file alive-IPs.txt. This is useful for loading the discovered hosts in to tools such as Nessus or Metasploit.

Vulnerability Discovery

Armed with the alive hosts, and a list of Domain Controllers, the attacker has a few options to move forward. At some point they’re going to require a user account, more enumeration is potentially possible – such as causing the Domain Controller to output a list of usernames through a NULL session. However more often than not additional enumeration requires a user account.

At this stage I will likely aim to gain a user account, there are three main ways I will approach this, generally in this order

  • LLMNR/NetBios-NS spoofing
  • Checking Shares
  • Gentle Bruteforce

LLMNR/NetBios-NS Spoofing

Attacking Link-Local Multicast Name Resolution and NetBIOS Name Services is something that I’ve covered in detail in the article Stealing Accounts: LLMNR and NBT-NS Spoofing, so I’ll just post a summary here.

What are LLMNR and NetBIOS-NS? They’re both methods of resolving hostnames to IP addresses. On your network if you try to contact a system by name first of all DNS will be used, but if that fails LLMNR will be attempted followed by NetBIOS. An attacker can respond to LLMNR/NetBIOS-NS requests and cause the victim to connect to the attacker’s machine instead and allow them to capture credentials in hashed form.

They can be exploited in two main ways, the first is by using Metasploit, the following modules will help:


Attentively there’s a tool called Responder which does the heavy lifting for you and supports lots of protocols:

python -i local-ip -I interface
python -i -I enp0s20

Full details are in Stealing Accounts: LLMNR and NBT-NS Spoofing. However in short this tool allows you to capture hashed credentials on a Windows network due to a default configuration options. You can then crack these hashes using a tool like John the Ripper. I’ve written about John the Ripper and Custom Rules here.


Sharecheck is a tool which allows you to quickly scan a subnet for Windows machines and it extracts useful information from those machines, for example it can show you the local lockout policy, the local administrator usernames, and available shares that you have read/write permissions to. Sharecheck is available here, it’s free but closed source.

Generally I use this tool multiple times during an engagement, first of all anonymously then I’ll use it with each user account that I capture. Sharecheck will highlight to you which shares you have read permissions to, and it’s surprising how often shares will have plaintext or reversibly-encrypted passwords in them.

Once I have access to an account or two, sharecheck can quickly highlight if that account is a local administrator of any machine on the network. It’s not uncommon for certain users (like executives) to be given local administrative permission to their own machine, this can be the downfall of the whole domain. It’ll highlight that you’re an admin, if you’ve got write access to the Admin$ share.

Gentle Bruteforce

Generally at this point I’ll always have a user account, it’s rare that responder doesn’t yield anything on a network, however if it gets down to Plan C what I mean by a “Gentle Bruteforce” is what is covered in my post The Myth of Account Lockout. The summary here is that most networks are configured to use the observation window offered by Active Directory for account lockout meaning that, by default, accounts do not lock out after five bad password attempts but lock out after five bad password attempts within 30 minutes. Meaning that an attacker can try three or four every thirty minutes with relative safety from locking out an account.

Generally I find that it takes very very few attempts before I land an account. Password1, Password123, Companyname1. An attacker only needs one domain user account to push a little further in to the network. If you’re lucky then a domain controller will just supply you a list of valid user names if you ask it nicely: -a

Alternatively most usernames are based on the persons name some how, so with lists of common names you can come up with your own list to get you started, then when you get any valid account you can run enum4linux with credentials: -u administrator -p password -U


If you’re very lucky the LLMNR spoofing, looking through shares or password guessing can in fact land you a domain admin (DA) account, or maybe just a local administrator account for one or two machines. If not then we’re got a domain user at least and can start looking at privilege escalation and Lateral Movement. It’s still very common to find networks which have the same local administrator account configured on all machines, Microsoft LAPS is still fairly new and not widely deployed in my experience. If this is the case then an attacker may perform lateral movement and aim to gain command execution on as many hosts as possible, to make privilege escalation easier.

Privilege Escalation

If I’m armed with a domain user account at this point, then I’ll revisit Sharecheck first, to check if that user has Local Administrative permissions to any devices on the network, then I’ll try an escalate from domain user to local administrator (of as many devices as possible).

Escalating to Local Administrator:

  • Sharecheck
  • CPasswords
  • Build Level Escalations

Escalating to Domain Administrator:

  • Incognito
  • Mimikatz
  • Password Reuse

Shortcut! In 2014 a vulnerability was fixed in Microsoft Systems that allowed any Domain User to escalate privileges to Domain Administrator. The vulnerability was a fantastic issue due to the high impact and simplicity of the underlying issue. Microsoft released the patch MS14-068 to address this issue, which was available for all systems however the issue is only currently exploitable if a domain controller is missing this patch. If this patch is missing on a Domain Controller you can escalate from Domain user to Domain Administrator instantly. As I don’t have a write up for this issue: here’s Metasploit’s own.


There’s an old issue (circa 2014) with Microsoft Windows Domain Controllers where they may store Group Policy Passwords in an encrypted, but reversible way. Again, I’ve done a full write up on Privilege Escalation through Group Policy Preference Passwords, but here’s a summary:

Group Policy Preferences (GPP) was an addition to Group Policy to extend its capabilities to, among other things, allow an administrator to configure: local administrator accounts (including their name and password), services or schedule tasks (including credentials to run as), and mount network drives when a user logs in (including connecting with alternative credentials). The passwords are protected in storage, they are encrypted with AES…however Microsoft released the key here.

Which means if you take a look at each of the Domain Controllers that were discovered earlier and access the SYSVOL share, you may just find an XML file which contains an entry called <cpassword> which is generally a local administrator or above. If all of that sounds too manual, then GP3Finder from GrimHacker will do it for you. Usage is insanely simple: -A -t DOMAIN_CONTROLLER -u DOMAINUSER

Build Level Escalations

In the unlikely event that we’ve not gained a local administrator account on at least one machine at this point, we’ve still got a lot of options but they require a little more manual work and definitely require you to roll up your sleeves. I wrote three different articles to cover the details of approaching this type of escalation: Unquoted Service PathInsecure Service Permissions, and DLL Hijacking.

The first two are local only attacks, so an attacker would generally have to get command execution on a device, however this can usually just be achieved by using Microsoft Remote Desktop at this stage. The third one can potentially be performed remotely if any software is loaded from a Windows share and the attacker has write access to that share, that would certainly allow for a lot of lateral movement.

To summarise this section, we’re looking for misconfiguration in the permissions model of software and services installed on local machiens in order to gain administrative access to that machine. For example, it’s not uncommon to find a service which executes as NT-Authority/System, but is reconfigurable by members of the “Authenticated Users” group (or similar). So an attacker can simply change which executable is launched when the service starts, a simple way to exploit this is to create an executable which creates an new local administrator account with a known password and have that execute instead of the legitimate service. Reboot, put the files back to how they were and you’re now armed with a local administrator account on at least one machine.

Getting Domain Administrator Level Access

Local Administrator accounts have full control over a system and can access all resources, storage and memory – including for processes owned by other users. I’ve written a piece on privilege escalation in Windows domain, for gaining Domain Admin level access. To summarise that piece there are two main ways of getting higher privileges, the first is token impersonation and the second is extracting plaintext passwords from memory. These methods use the tools Incognito and Mimikatz.


To summarise their write ups: Mimikatz can extract plaintext passwords. Personally I prefer to use these tools through Meterpreter although there are stand alone EXEs for them. There are lots of ways of running commands remotely if you prefer to use the EXE version. There’s a full write up here for using Mimikatz, but in short:

meterpreter > use mimikatz
meterpreter > mimikatz_command -f "sekurlsa::logonPasswords"

With any luck the above will dump a handful of plaintext passwords, if a Domain Admin is logged in you can get theirs too.


Incognito allows you to enumerate and impersonate tokens found on a compromised machine.

Through Meterpeter usage is like this:

meterpreter > use incognito
meterpreter > list_tokens -u
Delegation Tokens Available
meterpreter > impersonate_token HollNet\\Holly.da

Here Meterpreter is loading incognito into memory, listing the available tokens and I’ve chosen to impersonate a specific user, now if I drop in to a shell with this token I can steal the privileges of that user and I’ll likely just use the commands:

net user holly Holly123 /add /domain
net group "Domain Admins" holly /add /domain


Boom. Domain Admin.


I’ll generally go one step further though, now that I’ve got a high level of privilege I’ll dump all the domain password hashes and perform an audit on those, there might be an account with a terrible password that I just missed but could be a huge risk. Maybe an account has Companyname123 and I only tried Company1? This will cover that. There’s a lot of ways to extract hashes from a domain, full details here.

In summary though, if you pop a Meterpreter shell on a Domain Controller you can dump them like this:

meterpreter > hashdump

On tests though, I usually prefer to use the volume shadow copy method covered in this article as that way I’m using built in tools and so anti-virus tools are unlikely to get in the way and all the extraction happens on my machine so there’s less chance of a problem occurring on the important domain controller machine itself.

Clean-up/Removal of Evidence

Now if this was a malicious attacker performing these steps there’s much more work to be done. Such as the creation of Kerberos Golden Tickets, log carving, generally removing all traces of activity as you’d expect. However as a penetration tester there’s still work to be done too. Generally we’ll move back through the network and undo any changes that have been made to any system. Removing tools, resetting permissions, etc. We’ll keep detailed notes of where we were and when to ensure that the network can be put back to as close a state as it was in before we get there. With one important difference:

Now as we were on the race for Domain Administrator level access, once we’d compromised the credentials or token for an existing domain administrator account we could have just used that account for whatever remaining steps we had left to do however we purposely created our own account. This is for two reasons, the first is that it’s really easy for the client to validate that yes, in fact, we did manage to compromise the entire domain.

The second reason is that it’s very likely that Domain Admin wasn’t the target of the assessment, but there was some flag or trophy that the client wanted us to capture and gaining DA level access was simply a prerequisite to capturing the flag. Alternatively we may perform additional steps such as patch management analysis using this new account, either way any additional steps we perform will be done through our account meaning that if the client checks through the logs it’ll be immediately obvious which actions were part of the engagement and which are potentially unrelated malicious activity that was unfortunately timed.

When the engagement is over we won’t delete this account but simply expire its access, inform the client that it exists and that they may remove it if they wish to, but by leaving it in place it ensure that log entries are against the username, some systems will replace the username with the account SID once the account is removed, so keeping it in place but locked down helps keep everything neat.

Now it’s time to write that assessment report…


This is one part of a two part series, maybe take a look at Hacking a Corporation From the Outside: External Penetration Tests too!