I recently completed my first Attacker vs Defender incident response engagement and it was an awesome experience. I want to clearly state that I am not a world class offensive security specialist by any means, but I did get a big confidence boost of how my skillset has progressed within a short period of time.
The purpose for this article is to share my findings with regards to the toolsets tested and used during the engagement. I pulled resources from multiple sites as well as watched several videos with regards to different techniques and methodology. I will not go into the details of how to use these tools. But, I would welcome comments and suggestions for additional tool sets, techniques, and methodologies to be used in the future.
The goal of this engagement was testing the Defender Team’s ability to detect and respond to an incident. As for the Attacker Team, their goal was to go undetected while trying to enumerate and exploit systems within a monitored environment.
Without going into too much detail, the premise for the engagement was that the Attacker Team had compromised a Windows system and established a foothold. The Attacker Team was not permitted to engage any systems outside of a designated subnet. In addition, no Internet connectivity would be available from within the designated subnet and disabling Anti-Virus was not permitted; not to mention that disabling AV would trigger alarms. However, the use of scripts and Windows binaries that did not trip AV alarms were permitted. Also, I maybe cheated a little, but one of the IT guys provided me with a copy of their AV; which came in handy while researching and testing tools in my lab. It should be noted that I was requested to gradually get “louder” on the network in an effort for the Defender Team to detect my efforts.
Knowing the boundaries and the time table, I quickly started researching for alternative tools that I would generally use while performing a pentest as well as references to ‘living off the land’. Unfortunately, I did not have access to a mentor to help guide me through this engagement. So, I relied on my methods for performing a pentest, but tried to do it quietly.
It should be noted that I did not get into a rush when executing commands. Depending on the tool, I may have waited minutes or hours to relaunch and continue a process. In addition, I tried to be very conscious of not creating predictable patterns.
Since I was not given any details about the environment, I decided to perform some intelligence gathering. I utilized the native Windows tools of nbtstat, nslookup, and arp to probe the network. In addition, I needed to understand the system that was acting as the foothold, so I used systeminfo, net user, and net localgroup to further enumerate.
After identifying that I had Administrator access on a workgroup system (no privilege escalation needed), I knew that I could launch applications with Administrator privilege and bypass providing credentials. However, I was unsure if the system was being monitored. So, I decided to use the Windows binary version of PowerOPS Framework in order to obtain the hashes for all of the local users with Get-PassHashes as well as using Get-Information to obtain additional data about the system. The folks at Black Hills have provided an excellent article on how to create a PowerOPS Windows binary.
Since I had obtained local hashes, I decided to test the results and tried to pass-the-hash against the systems that I discovered using the native Windows tools. I would normally utilize crackmapexec, by byt3bl33d3r, but that was not an option. However, I did find a ported Windows binary named CrackMapExecWin, by maaaaz, and it functioned just like the Linux version of crackmapexec. However, the AV application that was provided for my lab immediately flagged the binary as a hacking tool.
So, I continued to research, and I found two alternatives that would get me close to the features and functions of crackmapexec. The first was Check-LocalAdminHash, by dafthack, and the second was Invoke-TheHash by Kevin-Robertson.
Continuing on my quest to obtain hashes, I would normally use SpiderLabs’ Responder or one of the updated forked versions. Unfortunately, that was not an option. However, I found another one of Kevin-Robertson’s repositories named Inveigh that filled the Linux to Windows application gap.
With Inveigh launched and gathering user names and hashes, I decided to use Invoke-PasswordSpray, by Ian Hoffman, and DomainPasswordSpray, by dafthack, to spray passwords. Utilizing both of these tools provided the ability to spray passwords against Windows standalone and Windows member systems.
Once I had accumulated a few NTLMv2 hashes from Inveigh, I used my off-network Linux system to start cracking with HashCat. As the passwords were reveled, I decided to create the accounts on one of my lab systems in order to obtain LM and NTLM hashes for future use.
With the newly obtained passwords and hashes, I revisited the modules of Check-LocalAdminHash, Invoke-TheHash, Invoke-PasswordSpray, and DomainPasswordSpray to validate credentials and try to obtain additional credentials. Once I identified that an account had Service Control Manager write privileges for a system, it was time to pwn.
Usually at this stage in a pentest, I would use Meterpreter or Empire to launch PSExec for a reverse shell. However, neither one of those were an option and I needed to come up with my own solution. So, I was referred by a fellow DC615 members to Bucky Roberts’ tutorial series on creating a Python Reverse Shell. His series gave me the foundation needed to create my own reverse shell; which I added additional features and converted to a Windows binary.
Creating a ported client and server solved the issue of not having a reverse shell. However, I needed to be able to deliver and execute the client-side binary from the target; without any user interaction. So, I revisited Kevin-Robertson’s Invoke-TheHash and found another module named Invoke-SMBExec that would provide the delivery system.
The last major obstacle to overcome was the ability to download and execute the client-side binary. To resolve that issue, I created a PowerShell one-liner that was incorporated within the Command flag for Invoke-SMBExec.
After finishing my preparations, I launched the listener and executed Invoke-SMBExec. When the reverse shell established, I typed a quick whoami to reveal that I had System. At this point, I defaulted back to my penetesting instincts and used net use and net localgroup to create a local admin account with RDP access.
Since my reverse-shell was very rudimentary, I relied on RDP access to aid in pillaging and pivoting to other systems. I realize that I left behind a footprint, but my actions seemed to evade the Defender Team that was trying to detect me.
As I continued to move laterally, I started to gradually use tools that would be a little “louder” on the network. In addition, I also started to use patterns within my methods.
To further enumerate the systems and the network, I used Invoke-ReverseDnsLookup, by Matthew Graeber. I followed that up by using Port-Scan, within the PowerOPS Framework, and then I later installed and executed Nmap to help enumerate local users via the built-in NSE scripts.
Within RDP sessions, I executed Get-GPPPassword, by Chris Campbell, to find cleartext credentials within the group policies. In addition, I used Out-Minidump, by Matthew Graeber, to dump the lsass process to a file; where I used an off-network system that contained Mimikatz, by Benjamin Delpy, to recover cleartext credentials as well as NTLM and LM hashes.
I also decided to use the Windows’ native netsh application to perform packet captures. I then used an off-network system to convert the capture into a readable Wireshark format for further analysis.
In closing, it is worth repeating that this was an awesome engagement. I learned a lot, but I know I have a lot more to learn. In giving back to the community, I am hoping that this article is useful for those in an offensive or defensive security position.
Disclaimer:
This article is made available for educational purposes only!!! In addition, this article provides general information on cyber security topics used for “Ethical Hacking”.
Persons accessing this information assume full responsibility for the use and agree to not use this content for any illegal purpose. Furthermore, the author is not liable for any direct or indirect damages or expense incurred which may result from the use of the information covered within this article.
Information within this article is “as is”, without warranty of any sort.
