After hours of OSINT (Open-Source Intelligence) and social engineering campaigns, your Red Team has finally obtained the coveted internal shell. The username, IP address, host and operating system information populates your (Command and Control) C2 framework interface, and a new stage of the engagement begins.
But now that you have the shell, where do you go from here? Truth is, you have a lot of options.
The importance of stage 0 and stage 1 payloads
Prior to obtaining the internal shell, it’s important that you have been using a less signatured and less well known C2 framework and implant system. This is often referred to as a stage 0 payload. Using this stage 0 method gives a higher chance of success in obtaining that initial foothold because common C2s (like Cobalt Strike and Metasploit) are much more likely to be alerted on. This stage 0 payload should have just enough features to troubleshoot and pivot to a more fully featured C2 framework in a stage 1 delivery.
Our first step after some basic local system enumeration will likely be to conduct this pivot. If your target organization is using an EDR (Endpoint Detection and Response) or next gen AV (Anti-Virus) this will mean creating a new process to unhook this EDR product and inject your stage 1 payload.
In this case, a stage 0 payload should:
- Be obscure and fairly unsignatured by common AV, either because it is a less well-known payload, or because you have built it internally.
- Perform basic local enumeration for stage 1 troubleshooting.
- Load a later stage 1 obfuscated and unhooked payload.
These modern EDR and AV products will hook into any new process created and overwrite Windows API calls to ntdll with their own version of ntdll. This gives the EDR the ability to look for any suspicious Windows API calls, report on them and block them before execution by the operating system. By overwriting these hooked ntdll calls with a clean version of ntdll, we can leave the EDR/AV blind to our further actions within this newly created process.
There are many tools and techniques to carry this out. As of April 2022, Scarecrow is a great option. However, this payload obfuscation tool, like all others, will continue to be more and more signatured as time goes on and it becomes more common. Scarecrow allows us to take shellcode for our Stage 1 implant and overwrite these ntdll hooks, launching our stage 1 payload without the prying eyes of our target.
A stage 1 payload should:
- Have shellcode loaders capable of being packaged with an EDR unhooking solution, such as Scarecrow.
- Have shellcode loaders capable of storing an encrypted payload that is only unencrypted after EDR has been unhooked.
- Be able to inject or execute into the current unhooked process for additional exploitation.
- Be able to open a Reverse Socks proxy within its own unhooked process.
Although this process is now beyond the reach of our target, we still need to keep a careful eye on what is placed on disk because it will be subject to static analysis. We also need to be careful about generating or injecting into any other processes that have not yet been unhooked.
Next Steps: Beacon Object Files
With our unhooked stage 1 implant, we can now work within our current process using BOFs (Beacon Object Files). Today, the tgtdelegation BOF is of special interest. This BOF allows us to remain in our current unhooked process and sign a Kerberos ticket with our existing low privilege user shell permissions that can then be used to authenticate to other services on the network.
Our command will be:
tgtdelegation [FQDN/currentdomain SPN/default]
This will return a Kerberos ticket that we can use for authentication within the domain.
Once this is obtained, we can now set up a Reverse Socks proxy using either the built-in Cobalt Strike socks proxy or another tool of our choice. Using the Cobalt Strike proxy continues to keep us out of sight of EDR.
Now with our Kerberos ticket in hand and a reverse proxy tunnel, we can begin lateral enumeration, and escalation with Kerberos credentials from our low privileged shell.
An example command may look like the following:
proxychains certipy req contoso.com/lowpriv.user@caserver.contoso.com -ca caserver -template VulnerableCertificate -k -no-pass -dns-tcp -target-ip 192.168.0.10 -dc-ip 192.168.0.1 -alt ‘DomainAdmin@contoso.com’
This command exploits an ESC1 vulnerability as an example. At this point, the domain is your oyster. We have a reverse proxy into the domain environment and Kerberos credentials. Together with proxychains and tools like Impacket that can take advantage of Kerberos authentication, we can move on into the domain environment.
Use your best judgement and opsec considerations continue exploitation from here.
This article was written by Kyle White, a Security and Privacy Risk Consulting Supervisor at RSM
