Malware Analysis with elastic-agent and Microsoft Sandbox
Microsoft describes the "Windows Sandbox supports simple configuration files, which provide a minimal set of customization parameters for Sandbox. [...] Windows Sandbox configuration files are formatted as XML and are associated with Sandbox via the .wsb file extension."[6]
Since both, the latest version elastic-agent (7.11+) support antivirus detection, I followed the instructions listed here [1] to configure an agent to test its detection capabilities. For my workstation, I used VMware with a fully patched Windows 10 and saved the current configuration with a snapshot. I wanted to combine both of these features; the elastic-agent and the Microsoft sandbox feature [4][5][6] to analyze my malware sample. Since the Microsoft sandbox doesn't retain anything after it is shutdown, I figure this would be a good alternative vs. restoring my previous VMware snapshot every time I tested a suspicious filename.
One minor inconvenient, if I want to use the agent, I need to add it every time to Elasticsearch to use it. If the elastic-agent isn't installed, Microsoft Defender is enabled. Here is a list of tools to either install or consider installing in the sandbox when it starts:
- Elastic-agent with malware policy (in VMware client and Sandbox client)
- MS SysMon
- MS TCPView
- Consider adding: PowerShell Script Block Logging, example here
- Wireshark to capture traffic from host
- Other browsers: Chrome & Firefox
- PeStudio
- Python
- Internet Services Simulation Suite: INetSim
- Didier Stevens suite of tools
- Proxy setup on VMware client to monitor traffic
- Any other tools you might find useful during the analysis such as this package by @mentebinaria
When starting the sandbox, using a script configured for this purpose, it can automatically load the tools needed with a batch file (MalwareAnalysis.wsb). Here is my example:
<Configuration>
<vGPU>Enable</vGPU>
<AudioInput>Enable</AudioInput>
<VideoInput>Enable</VideoInput>
<ProtectedClient>Enable</ProtectedClient>
<MappedFolders>
<MappedFolder>
<HostFolder>C:\Sandbox</HostFolder>
<ReadOnly>true</ReadOnly>
</MappedFolder>
</MappedFolders>
<LogonCommand>
<Command>C:\users\WDAGUtilityAccount\Desktop\Sandbox\SBConfig.bat</Command>
</LogonCommand>
</Configuration>
Because everything is deleted when you shutdown the sandbox (including the browser, it must be reloaded with the current version every time), I needed a way to automatically start/add/load/update what I needed to perform some basic analysis. I use a batch file I preconfigured with everything I needed to accomplish this task. Here is what I have (C:\Sandbox\SBConfig.bat):
REM Copy elastic-agent to C:\Program Files
C:\Windows\System32\xcopy.exe /i /s C:\Users\WDAGUtilityAccount\Desktop\Sandbox\elastic-agent "C:\Program Files\elastic-agent"
REM Install Sysmon64, vcredist_x86
C:\Users\WDAGUtilityAccount\Desktop\Sandbox\Sysmon64.exe -i -accepteula
C:\Users\WDAGUtilityAccount\Desktop\Sandbox\vcredist_x86.exe /q
REM Add Elastic certificate authority to Sandbox
C:\Windows\System32\certutil.exe -addstore root C:\Users\WDAGUtilityAccount\Desktop\Sandbox\ca.crt
C:\Windows\System32\certutil.exe -addstore root C:\Users\WDAGUtilityAccount\Desktop\Sandbox\stargate.crt
REM Install new Microsoft Edge
start /wait C:\Users\WDAGUtilityAccount\Desktop\Sandbox\MicrosoftEdgeEnterpriseX64.msi /quiet /norestart
REM Install Python
C:\Users\WDAGUtilityAccount\Desktop\Sandbox\python-3.9.2-amd64.exe /quiet InstallAllUsers=1 PrependPath=1 Include_test=0
REM Execute PowerShell scripts
Powershell.exe -executionpolicy remotesigned -File C:\Users\WDAGUtilityAccount\Desktop\Sandbox\ChangeExecutionPolicy.ps1
Powershell.exe -executionpolicy remotesigned -File C:\Users\WDAGUtilityAccount\Desktop\Sandbox\ScriptBlockLogging.ps1
REM Install Wireshark
REM Install npcap manually. Silent only supported with OEM
C:\Users\WDAGUtilityAccount\Desktop\Sandbox\Wireshark-win64-3.4.4.exe /S /D /desktopicon=yes
C:\Users\WDAGUtilityAccount\Desktop\Sandbox\npcap-1.20.exe
The file npcap is last because I'm using the free edition vs. the OEM which will ask to finish the installation after it starts the installer. Before you can enable ScriptBlockLogging in the Sandbox, I need to enable the PowerShell ExecutionPolicy to allow RemoteSigned. This is the command in my script to make that change (ChangeExecutionPolicy.ps1):
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force
To verify the change was applied, as PowerShell admin, execute the following command:
Get-ExecutionPolicy -List
Producing the following result:
Following the example listed here in this Elastic blog, it is time to create a policy, add the elastic-agent to Elasticsearch (pre-copied with the batch file SBConfig.bat) to run the sample file and monitor its activity. This is the four application part of the policy I configured for my agent:
After launching the script MalwareAnalysis.wsb to start the Sandbox, load, copy and install all the applications from the batch file, it is time to add the elastic-agent to the server, I am ready to launch the suspected malware file for analysis. Last month, my honeypot was uploaded a crypto miner file photo.scr and I'm going to use this file to submit the elastic-agent for analysis.
→ To view the results in Kibana, navigate Security -> Overview -> Detection alert trend
I look for activity that would indicate an alert triggered by malware and filter for the value, then View alerts to examine the flow of the activity. I can then select Analyze the content as to what this photo.scr file accessed or installed on the client. The agent captured 3 alerts:
Next is to expand one of those alerts and analyze the activity, the elastic-agent identified: 1 library, 53 networks and 7 registry:
Network Activty
Registry Activity
Each one of the can be expanded to drill further into what happened on the host.
Indicator of Compromise
SHA256
807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d Photo.scr
[2021-02-08 07:06:36] [1693] [ftp_21_tcp 29914] [103.232.236.239:64149] info: Stored 1578496 bytes of data
Domains
stafftest[.]ru
iqtesti[.]ru
jobtests[.]ru
prtests[.]ru
qptest[.]ru
pstests[.]ru
testpsy[.]ru
profetest[.]ru
hrtests[.]ru
This is one of many tasks Windows Sandbox could be used such as accessing suspicious sites, running untrusted software and scripts starting with Windows network or vGPU disable, without the fear of impacting your normal Windows installation. These various tasks can be accomplished by creating separate .wsb Sanbox script.
[1] https://www.elastic.co/blog/how-to-build-a-malware-analysis-sandbox-with-elastic-security
[2] https://www.elastic.co/endpoint-security/
[3] https://www.elastic.co/guide/en/security/current/install-endpoint.html
[4] https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-sandbox/windows-sandbox-overview
[5] https://techcommunity.microsoft.com/t5/windows-kernel-internals/windows-sandbox/ba-p/301849
[6] https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-sandbox/windows-sandbox-configure-using-wsb-file
[7] https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon
[8] https://docs.microsoft.com/en-us/sysinternals/downloads/tcpview
[9] https://github.com/mentebinaria/retoolkit?s=09
[10] https://www.virustotal.com/gui/file/807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d/detection
[11] https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows?view=powershell-7.1
-----------
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu
Office macro execution evidence
Microsoft Office Macros continue to be the security nightmare that they have been for the past 3 decades. System and security admins everywhere continue to try to protect their users from prevalent macro malware, but they find Microsoft's tooling often less than helpful.
Case in point, the Microsoft page that describes how to disable macros sports this useful warning:
If only life were so easy.... The only two people who will ever be "sure" what a macro is doing are its original developer, and the malware analyst who just reverse engineered it. And I'm actually even doubtful about the developer.
Considering how shaky and often bypassed the avialable mechanisms are to control macro usage, we would expect to at least see some decent instrumentation that allows us to log, monitor and reproduce "what happened". But... no. There are hardly any useful logs. Which over the years led to a plethora of work-arounds, YARA rules, Powershell scripts, and reverse engineering.
This week, I had the "joy" of doing a bit of the latter, while investigating an incident. One of the few places where macro execution leaves traces is in the "TrustRecords" entry in the registry:
HKCU:\SOFTWARE\Microsoft\Office\16.0\Word\Security\Trusted Documents\TrustRecords
HKCU:\SOFTWARE\Microsoft\Office\16.0\Excel\Security\Trusted Documents\TrustRecords
HKCU:\SOFTWARE\Microsoft\Office\16.0\PowerPoint\Security\Trusted Documents\TrustRecords
The version number (16.0) might vary depending on your Office installation. Whether, when and how the keys get populated also depends on the "Trust Center" setting as described in the Microsoft link above.
But in general, the registry entries will look something like this:
The rightmost value (00 or 7f) indicates which trust center warning the user clicked away. "00" means "Open for Editing" and "7F" means "Allow Macros to Run". The other hex values encode, amongst other data, the original creation time stamp of the file whose name is shown. This can be extremely helpful when you need to determine the exact time of original download, if the file came from a shady source. In combination with the file name, this can be the "pivot points" that you need in an incident to go hunting in proxy or email logs, to determine how that file got to the user in the first place.
Volatility has support to extract this information, but if you are forensicating on a live system, you can also wing it with Powershell in a pinch:
$regkeys = 'HKCU:\SOFTWARE\Microsoft\Office\16.0\Word\Security\Trusted Documents\TrustRecords',
'HKCU:\SOFTWARE\Microsoft\Office\16.0\Excel\Security\Trusted Documents\TrustRecords',
'HKCU:\SOFTWARE\Microsoft\Office\16.0\PowerPoint\Security\Trusted Documents\TrustRecords'
foreach ($key in $regkeys) {
try {$item = Get-Item $key -erroraction stop} catch { $item = "" }
foreach ($line in $item.property) {
$values = $item.getvalue($line)
if ($values[-1] -gt 0) {$type="RUN"} else {$type="EDIT"}
$timestamp = [datetime]::FromFileTimeUtc([System.BitConverter]::ToUint64($values,0))
Write-Output "$line $timestamp $type"
}
}
Yep, not exactly the most beautiful code. It ain't my fault that Microsoft insists on using 64bits for a time stamp, nor that converting such a value back into human readable time is so convoluted in Powershell :).
In my case, for the registry screenshot shown above, the Powershell spits out the following
%USERPROFILE%/Downloads/invoice%2058633.xls 03/24/2021 23:52:21 RUN
%USERPROFILE%/Downloads/Invoice%2038421.xls 03/22/2021 23:45:42 EDIT
%USERPROFILE%/Downloads/Invoice%2094377.xls 03/22/2021 21:02:04 EDIT
which tells me that the file I want is "invoice 58633.xls", because for it, Macros were allowed to run. It also gives me a timestamp for when the user made the download - March 24, 23:52 UTC.
If you have savvy ways of keeping track of or analyzing macro execution in your environment, please let us know, or share in the comments below.
Comments