Again, welcome back to my site for another write-up. Today, we’re going to explore some tricks that I find are not really more or less “hacking” skills or techniques (many will be), but more or less just creative thinking type of situations that can allow you to be more successful in your pentesting engagements.
What are these tricks for? None other than AD, which shouldn’t need an introduction. Let’s get started!
Taking Full Advantage of a Compromised AD Account
So, let’s say that you’ve done some sort of exploit with remote code execution, phished, or somehow in some way have compromised AD account credentials in a penetration test. Great. What now? Well, it’s important to understand where the entry points on the network are and how those footholds are established. When it comes to taking full advantage of an AD account, there’s so many factors you need to consider or you’re going to miss something.
For example, many individuals and security folks often skim past data stored on a network drive, Sharepoint (which often contains other sensitive info such as passwords or otherwise private information), Outlook, and the actual operating system itself. Based on your circumstances, you’re going to find yourself in some sort of scenario where something here will help you – I can practically guarantee it.
The idea is essentially making sure that you’re covering all your bases on potentially valuable information you’re interested in as an attacker. I’m going to abuse a bad configuration MUCH sooner than some sort of SYSTEM exploit that probably attacks the kernel and could potentially crash the system, as well as tip off the Blue Team that I’m already in the system. Go the path of least resistance – sure, it’s cool to pop Meterpreters, but it’s really not always even necessary. It can be much easier.
If the machine has Autologin enabled in Windows, you can enumerate the password in cleartext. The specific registry key that stores this value can be remotely read by the Authenticated Users group. Not that it matters – often times people make certain autologin accounts local admins. You should always check and NEVER assume someone has done the right thing. – Microsoft also fully and openly admits this reveals the password as well:
Windows Command Line Tricks for Enumeration:
So, you’ve gotten a box that sits within the network or the DMZ and you’re feeling good! Except – okay, where do I go from here? Here’s a few quick ones:
“ipconfig /displaydns >> $whatevernameyouwant.txt”
“arp -a” – Find other machine IPs sending your host ARP packets
“net use” – Display mapped SMB/NetBIOS shares.
“sc query“ – Display running services. Pipe stdout into findstr /i to essentially grep for specific strings.
“query user” – Display logged on users and idle time.
“tasklist” – Display running processes.
This simply outputs the contents of the DNS cache on the machine. An example off my machine displays “lsdsecurity.com”, demonstrating you can pull information off the machine even if things such as browser history, etc. are deleted. This is GREAT for identifying internal infrastructure and back-end systems like SCCM, WSUS, Exchange, and whatever else you can possibly think of. Combine with “findstr /i <string>” for easy grep on specific subdomain search.
I recommend staying away from running extremely intense powershell and “net user” / “net localgroup” style commands (and from creating additional local user accounts on machines if possible). I suggest finding privilege escalation via other paths if at all possible before doing this, as most competent EDR solutions like Crowdstrike and Carbon Black are going to pick this up really fast. Making a new user, adding them into local admins and remote desktop users or other blatant malicious ones like TelnetClients is just a dead giveaway.
Poisoned AppInit DLLs like the ones PentestLab mention in this article https://pentestlab.blog/2020/01/07/persistence-appinit-dlls/ are a really good example of much quieter ways to keep your foot in the door.
Read Access on Shared Drives/SMB/NetBIOS Shares
This one isn’t new by any means, but you may find it useful to use Windows Search to perform sweeping search operations across any shared drives you can get access to in AD. Personally, I have had a lot of luck searching for *.txt, *.bat, *.ps1, *.vbs, *.docx, *.ppt and so on. The syntax is how I typed it – just asterisk + file extension to dig up all files of the same type. Of course, you can also run find command lines. You can google the one liners on the internet easily. There are plenty good ones out there.
Many times, this can net you huge gains. Such info as .txt files containing passwords, Batch/.VB scripts with hard coded user credentials (often times a script that joins a computer/workstation to the domain or one that automates a software install/maps a printer), other sensitive or revealing information, and various other resources that help attackers are often stored by users visible to everyone on shared drives.
It’s also worth checking each domain account you compromise for it’s individual permissions to ensure you’re getting the maximum bang for your buck. Like i said, make sure you grab the low hanging fruit.
Citrix Privilege Escalation & Pivoting
I could probably sit here and go on all day about the various issues Citrix can create due to the very nature of how it operates. Citrix is, well, by it’s nature, very hard to get exactly “right”. The reason why this is, is because every Citrix published application setup, in laymans terms, is ran on the actual Citrix server itself, and visually forwarded to the end user. When using a Citrix application, it’s just running on the actual Windows Server machine providing the application.
Consequentially, this creates a scenario where a few things are happening.
#1. You are in an application (such as a web browser) that PROBABLY has full routable Intranet access/full VPN connectivity. Again, because it’s running internally in a network 99% of the time, you inherit the properties of that server as well in the networking capabilities on your application.
#2. Due to the “sandbox” nature of Citrix Published Applications, you run into a lot of situations where if Group Policy isn’t totally locked down on the actual servers themselves, you can escape FROM the published application into another application. A common scenario is as follows:
a. Open Internet Explorer through Citrix.
b. Invoke “Windows Help” through IE, and search for “Command Prompt” or “notepad” in the search – you’ll then be able to open another application outside of the app itself.
In many cases, you’ll be able to get Powershell and other things as low privilege which is really big, due to the next reason I’m about to list…
#3 Because Domain Administrators commonly log onto Citrix to administrate the servers – you have to deal with a situation where often times, credentials are cached by Kerberos in Windows and if compromised, all credentials can be dumped out of the Citrix machine from it’s memory. This is a VERY high risk and nearly in all cases results in a total, across the board system compromise.
#4 Often times, Citrix is provided to a majority of employees within an organization. Again, there’s a lot of reasons why this happens, mainly due to legacy software requirements or actual thick client software that is simply much too bulky to install on a mass scale. You’ll find browsers that open to HR portals or what have you in Citrix – with nothing stopping you from just navigating to other intranet resources. For every user with an AD account
So realistically, that’s pretty much the jist. Citrix is generally always a very high value target. Do not pass up on trying to poke at it during your engagements – try anything you possibly can to escape that published app and get your payloads on there. It’s pretty easy to bust out most of the time.
From there, download a meterpreter payload with Powershell, enumerate for installed patches and local SYSTEM privilege escalation exploits – once you’re SYSTEM, simply fire off post exploitation tools like Mimikatz and collect cleartext & hashed Domain User & Domain Admin credentials. It usually doesn’t get much farther than that because you’re Domain Admin by this point and just setting up your port forwarding to RDP into the domain controller and take a victory screenshot. However, it can go further than that and you may simply just get more low priv creds.
Why you shouldn’t really be running Powershell post-exploitation frameworks without EDR bypass
As I sort of touched based on earlier, I just want to share my reasoning as to why you really shouldn’t do this on a system where you’ve enumerated something like Crowdstrike or Carbon Black. I know there are other solutions out there, but I have the most experience with these two on both ends.
Full disclosure – you CAN simply taskkill /f /im “cbsensor.exe/csagent.exe” or whichever respective process that it’s running once you’re local admin. You can uninstall the sensor for Carbon Black specifically. Someone is going to know about it though. Almost any sane person has a high severity alert set up for a node uninstalling it’s sensor. But, there are quiet uninstall flags on both install packages/binaries for both solutions. If you’re not concerned about being detected, just nuke the EDRs and go wild.
Otherwise, you’re probably going to want to be a bit more methodical in how you’re approaching things. Running enumeration/post-exploitation frameworks like Bloodhound and the other 10+ heavy Powershell ones are going to be really obvious to anyone with sane alerting set up, again. Sometimes it’s totally appropriate to use these tools wide open – but initially, I like to be as quiet as possible.
Again – enumerate more. Enumerate installed updates, potential exploits, find as many services/apps you can authenticate as the user account you have as you can, perform controlled ping sweeps /32 and /24 subnets at low PP/s. Run a for loop with nslookup to enumerate further internal hosts, as well as the internal host naming conventions. Then, potentially begin running controlled, single port sweeps across your hosts using educated guesses. Port forward HTTP/SMB/RDP/ traffic to your attacking machine and pivot to attack the applications inside
I’m a big proponent of Living Off The Land – and not dropping binaries to a machine I’ve compromised. You never want to leave anything behind for forensics to get their hands on. Keep everything volatile and in memory if at all possible, and keep your persistence methods low impact.
This will conclude part 1 of the writeup. I’ll be back to drop more methodologies and pentesting concepts in Part 2. I’m staying away from simply feeding one-liner commands and automated enumeration scripts to everyone, because there’s a million and one different resources out there that provide that. What they do not provide, is the conceptual knowledge of being accountable for the noise you’re making, and how to move in a controlled manner.