Since the dawn of hacking, there have been lots of techniques released to backdoor Windows systems. From the wild wild west of the registry to the Windows Task scheduler, hackers love to find creative ways to maintain access to their conquests. While backdoors do not have to be related to malicious code, such as the case of an maliciously added user, often times a backdoor is thought to be synonymous with other sub-forms of malware. It just isn’t true… a backdoor can be much more interesting than a RAT hidden in the Run key. The Shmoocon 2013 talk by Jake Williams and Mark Baggett really hit home for me. The blog about this talk can be found here.
Taking a step back, lets pull straight from the most authoritative source on the internet… Wikipedia:
A backdoor in a computer system (or cryptosystem or algorithm) is a method of bypassing normal authentication, securing unauthorized remote access to a computer, obtaining access to plaintext, and so on, while attempting to remain undetected
Across the spectrum of assessments I go on, I find the concept to be not quite that simple. Backdoors possess multiple qualities that are worth breaking down to understand the decision points you have available to you as an operator. Further, there is no worse feeling than having your chosen backdoor be your single point of failure.
*See the slides here*
As the art of red teaming evolves, more and more emphasis has been placed on team based solutions to common problems. Authors of capabilities or support tools are now focused on building in a collaborative approach to using their project. It is no mystery why this has happened – during engagements or assessments, people work as a team (duh). Need examples of capabilities moving this direction? Check out MSF Pro, Dradis Pro, Silent Break’s Security’s Throwback, Cobalt Strike, etc.
Over the years, I have been able to witness the collaborative approach to hacking first hand at various red team events and at my job. No longer are people stuffed into their own corner trying to individually tackle hundreds of systems, no longer are people screaming across the room to clumsily pass shells in Metasploit, and no longer is data being hoarded by a single point of failure. It is quite beautiful.
While the tools in use today are a much better step forward and have components built for scanning, I find people still rely on individualized NMap setups for pentesting. Testers often times do not even scan at all for fear of tripping sensors during more advanced engagements. With this approach, people are going back to the limited sharing of data and often missing exploit opportunities. I was inspired to find a solution that would work for my engagements but first…
*EDIT* This repo has been renamed to PowerPick and added to the Veil-Framework’s PowerTools. Find it HERE! See below for more edits. *EDIT*
Attackers have evolved to love PowerShell more than most defenders or system administrators. Tools like Powersploit’, Veil Power*, and Nishang have become routine capabilities used by Red Teams, Pentesters, Evil attackers, and skiddies alike. With this evolution and overall consolidation of techniques into a single scripting language, surely defenders have found a proven method to prevent PowerShell execution? Surely Software Restriction Policies (SRP) or AppLocker can save the day? Don’t be so sure…
Assessment after Assessment, I find that we can compromise a domain user, elevate local privileges, steal credentials, inject payloads, and escalate in the domain all using PowerShell. I have nightmares of the day someone effectively restricts PowerShell and some of the old school tactics must return. From my conversations with defenders or infosec junkies, awareness of these techniques is on the rise and people are finally starting to pay attention to the routine release of PowerShell tools to aid in offense. With that being said, until disabling PowerShell on unneeded systems becomes common practice in the trenches of commercial enterprise, attackers will still have an easy[ier] win. At this point, the restriction of PowerShell is unlikely to happen until the time/cost required to implement such defensives are minimized to a point where it can be realistically accomplished natively at scale.
For some previous research attackers’ use of PowerShell:
Once Upon a time…
…Deep, Deep in the wild jungle of domain trusts, the illustrious user hides among the clutter and noise of a Windows network. Success Audit here, Failure Audit there. The hunter, who has already compromised the domain, wonders how they can track their prey and if they will bring home the trophy for their wall. The hunter fires up Veil-Powerview and queries all the things, but as luck would have it, the evasive user eludes detection. Where oh where could this user be?!
But Seriously… I recently found myself wondering how I would go about searching for a very specific user on a very large network. The challenge presented itself like the classic needle in a hay stack… thousands of systems spread internationally with my fixation on only a couple of those users.
Why do this?
To justify my craze, it is important to note that there are legitimate reasons for this:
- Fulfilling a specific objective provided by a customer
- Gaining access to certain sensitive network resources you know only a specific user can access
- Targeting incident response or SOC ranges by targeting their personnel – Counter Network Defense
- Targeting executives, engineers, or whatever group of users you are interested in
The list could go on to fill many pages if you polled the average Red Teamer. In my case, I knew of a specific functional team that would provide a wealth of information and awareness. In my mind, they were a critical target and so I spent the time going through all of the different methods to hunt down users.
Most of my useful thoughts come out of being really stuck or challenged; it happens often. I was recently inspired to dip back into my analytical background to apply some very basic techniques for the purpose of efficiently targeting an organization’s domains after gaining internal access. Nothing like staring at thousands of lines of tool output after 12 hours of working. Instead of doing the typical grep/sed/awk magic to get useful data, I decided to try some nodal analysis to efficiently abuse the Active Directory trust relationships I was facing. I feel it is important to say; I am not a data scientist. This is a very introductory level explanation of the use of analytical tradecraft on Domain Trust data. It worked for me though…
Recently I was involved with a Red Team / Blue Team exercise with 10 commercial and college teams. The exercise was pretty standard: public msf-able vulnerabilities, default credentials, and poor domain security to start. Each network used NAT with a core router port forwarding only certain services and there was a juicy soft domain inside ready for the picking. In these exercises, the first 5-10 hours is always easy but as the teams start to dig in on their networks, patch machines, and shutdown services, the fun really begins. I have found a key strategy: Get in quick, get as much as you can, and then pick one system that you believe will be your main box to hop from. This system, this focus point of your work, must be defended. If you can hold one access, usually you can laterally move at some point and deploy capabilities to downgrade systems or even better, force a revert of the system (www.youtube.com/watch?v=e6ozwhdn3go).
The hard part of these exercises: mass command and control of owned systems against a highly active “Incident Response” team. My 10 person red team was faced with access to 100s of systems. Things like Armitage/Cobalt Strike and Asynchronous C2 have made this part so much easier for windows targets but what happens when you want to mass control the routers?