How to Build a Red Teaming Attack Scenario | Part 2 - Weaponization and Connecting Actions

We described initial access, execution of the first stage payload, and defense evasion (process injection, blockdlls method, parent PID spoofing)  stages of our attack scenario in the first part of this blog series. In this part, we explain weaponization, shell code download, clearing tracks, and connecting parts to create the attack scenario.

4. Weaponization

Weaponization is the first phase of the kill chain, and it is categorized as the Build Capabilities technique under Resource Development tactic of the MITRE ATT&CK framework [19]. Building capabilities consist of creating custom payloads, post-compromise and remote access tool development, creating infected removable media, and similar techniques.

An ideal scenario should be modular in terms of changing each part independently in a new deployment. It is always a good idea to find a couple of different ways to create and deliver the first payload to the target according to the environment. As explained in the Initial Access section, different techniques can be used for delivery. Moreover, different methods can be used for creating the initial payload, such as the self-extracting archive (SFX) used in this attack scenario.

Deploying SFX archives is a commonly used method that may have a bigger impact where an attacker has the privilege to modify shared files on a fileserver. While creating a fake SFX archive with a widely used legitimate program can end up with lots of infections in a company environment, red teams may still choose this path according to the target of the operation.

Several tools are available to create an SFX archive. We used 7z SFX Builder to create an SFX archive that extracts our shellcode loader to a specific directory and executes a .bat script. We created the .bat script below to trigger CLR Hooking that will eventually download our shellcode . The SHLCD variable is the base64 encoded URL that the loader will connect to download our shellcode.

There are useful SFX properties like GUIMode, and Delete that can enable us to start our payload without much attention from the user. For a more covert real-world scenario, this SFX config may include another legitimate (non-malicious) program for executing after the CLR Hooking script.

We can generate the SFX file that will start the attack by using 7-zip extra binaries.

After generating the SFX file, if the executable is not marked as requiring administrator privileges,  we could use any Resource Editor to modify the manifest. This is required since our deployment method does not include a UAC Bypass technique. 

MITRE ATT&CK Framework Techniques and Tactics:

5. Downloading the Shellcode

Running the SFX archive with admin privileges creates a cmd window with "AppDomainManager is hooked!" message. Verbose messages can be omitted from the source code. There are also workarounds to prevent cmd.exe windows from popping up.

The shellcode loader DLL creates Werfault.exe in a suspended state and updates its Parent PID to spoolsv service.

After that, we can see a GET request made from the target to the URL defined in the SHLCD environment variable.

The shellcode (meterp.b64) that is hosted on C2 server is a stageless Meterpreter payload which is generated with msfvenom.

The shellcode loader DLL injects Werfault.exe with shellcode and starts the execution of the shellcode by using CreateRemoteThread. We can see the meterpreter session start on our C2 server. For more covert operations, other C2 frameworks can also be used as the payload.

MITRE ATT&CK Framework Techniques and Tactics:

6. Clearing Tracks

At the end of a scenario, we clear tracks to create repeatable scenarios. In this scenario, we should delete downloaded and created files.

7. Connecting Blocks to Create a Scenario

When we connect the dots, we get a scenario that includes the following steps:

1. SFXArchive.exe is downloaded and executed by the user.

2. setup.bat and DomainManager.dll is extracted into %TMP%\7zS2A77.tmp.

3. setup.bat is executed by the installer.exe process.

4. Environment variables are set for CLR Hooking.

5. Environment variable SHLCD is set to the base64 encoded URL of shellcode

6. stordiag.exe is executed by installer.exe.

7. stordiag process loads DomainManager.dll and execution is redirected into PpidSpoof.Exec().

8. A new process is created using the werfault.exe image in a suspended state.

9. BLOCK_NON_MICROSOFT_BINARIES_ALLOW_STORE mitigation is added for blockdlls feature.

10. Parent PID of the new process is changed to the PID of spoolsv.

11. Shellcode is downloaded into memory from the URL.

12. Shellcode is written to the suspended process and a new thread is created for execution.

13. Meterpreter session is connected

14. After the stordiag.exe process is finished, files in %TMP%\7zS2A77.tmp are deleted. 

References