Background Materials
- Even CyberArk wrote an evasion tool: https://www.cyberark.com/resources/threat-research-blog/introducing-evasor-a-new-pen-test-tool-for-windowapplocker
- https://lolbas-project.github.io OpenEDR imports commandLines from LOLBas project
Code-Execution Model Recap
- Recap your earlier track https://www.notion.so/jymcheong/c87f8e497de3403c9e3c13c95f944043?v=796c1ca53e654c43be4a43c3aa0cfb68, quite a few can reuse to contrast attack vs normal
Specific Chaining to look into
Anything that involves writing a Type 1 compiled file will be disrupted (as you would experience later). So...
Type 2 > Type 1 (see that it gets disrupted)
- Using Office Macro is easiest. There are other ways too. Have a look at evading AppLocker & LOLBAS project. Reuse earlier attempts.
- Switch OFF DetectOnly (you can switch it on for the sake of studying the attack sequences, that's the intent for this switch)
Type 2 > Shellcode (get a C2 session)
- Merge with the next goal. You will also realise Win10 WindowsDefender will block many of such shellcode-injections for free. Microsoft does an excellent job at mining signatures from open offensive tooling projects. Microsoft owns Github btw!
Type 3 > 1
https://thehackernews.com/2021/06/experts-uncover-yet-another-chinese.html example only. That RTF exploit is old, yet there are those who don't patch.
Type 3 > 2
Another example, but server side: https://thedfirreport.com/2021/06/03/weblogic-rce-leads-to-xmrig/?fbclid=IwAR0Vtnu_lhQkM90XTmHjaL-Lu7oAPde1Z7clF87A9rz6QB5BuW9eqi8qpxw
YJ's Observations
Type 2 > Type 1
I will use the VBA codes from Goal 2 to test if I can launch a Type 1 file e.g. 7Zip Installer (7z1900-x64.exe).
VBA macro codes:
*Only difference with this and Goal 2's codes is the URL of the payload. Note that the size of the original command line stored in originalCli needs to be greater than the size of the real one stored in cmdStr. Hence, you need to make sure that the URL is shortened e.g. use https://tinyurl.com/app/
Results with DetectOnly disabled (i.e. will block instead of pass-through):
The VBA macro was able to launch 7z1900-x64.exe for a split second before getting terminated as shown in the screenshot below:
Similar to what was seen in Goal 1, OpenEDR blocks the execution of Type 1 files. The way to deploy Type 1 files is to ensure that the installer file is owned by the trusted users or group i.e. SYSTEM, TrustedInstaller or Administrators (group). After which, these apps should be installed into Program File or equivalent such that standard users cannot change. Since neither of the conditions were fulfilled for 7z1900-x64.exe, the VBA macro was able to launch child process but was immediately terminated as shown in the screenshot above.
ODB Console:
Same observations except that 7z1900-x64.exe was created instead of calc.exe. Please refer to Goal 2 for more detailed explanation.
ODB Graph:
2 differences from Goal's 2 graph:
- SpoofedParentProcess edges can be seen pointing to powershell.exe and 7z1900-x64.exe. This is because both processes have spoofed parent processes.
- UAC prompted for consent to run 7Zip Installer because the installer was built with a manifest that asks for elevated rights. Hence, high privilege was seen to launch 7z1900-x64.exe.
Investigation-board presents summarised Process anomalies:
Same as what was seen in Goal 2 except that powershell.exe was tagged with "Spoofed Parent ProcessId". As mentioned above, it is because powershell.exe has a spoofed parent: explorer.exe. One important point to note is that powershell.exe is AfterExplorerBackground. If a user uses PowerShell as an interactive shell, that PowerShell process WILL BE foreground with anonymized input events linked to it.
Type 2 > Shellcode (get a C2 session)
Attempt 1 BLOCKED: Tried using Magic Unicorn to create macro containing PowerShell payload to establish C2 but was identified as virus by Windows Defender when opened.
Attempt 2 BLOCKED: Tried using Empire windows/macro module to create macro containing PowerShell payload to establish C2 but was identified as virus by Windows Defender when opened.
All attempts to carry out Empire/Metasploit modules were unsuccessful because of Windows Defender. Windows Defender was able to identify the PowerShell payload contained within the files as viruses, hence causing it to fail. For the interest of time, I will disable Windows Defender so as to move on to the other goals.
Attempt 3 (Disabled Windows Defender in the interest of time):
Description:
Use a VBA macro to inject shellcode into memory using Unicorn and Metasploit. When the user opens the document, it will open a meterpreter session.
Metasploit modules used:
windows/meterpreter/reverse_http
exploit/multi/handler
References:
Follow reference link 1 to replicate the offensive step.
Once the document is opened by the victim, a meterpreter session is started in msfconsole.
With a meterpreter session, we can start exploring the target machine e.g. sysinfo to display information about the exploited Windows machine.
ODB Console:
One sequence to note from the ODB console is:
- System > smss.exe > smss.exe > winlogon.exe > userinit.exe > explorer.exe > WINWORD.EXE > powershell.exe > powershell.exe > powershell.exe > csc.exe > cvtres.exe
Why some PowerShell scripts like this execute C# compiler csc.exe is because the PowerShell script uses cmdlet Add-Type. The C# compiler (csc.exe) can invoke compilation tools when necessary, like the resource compiler cvtres.exe.
ODB Graph:
One thing to take note of from the graph is the 2 network connections on port 8080. The reason why powershell.exe is connected to port 8080 is because I configured LPORT (Local Port) to 8080. LPORT is the Listening port (of the C2 Metasploit service) that accepts incoming traffic from the compromised machine.
Jym's Comment
Good try for a year 1 undergrad
- YJ's last encounter with offensive tooling was about 3 years ago? When we exposed him to Powershell Empire for an exercise of process-to-network attribution using Bro & MySQL data-linking.
- For the fact he knew a downloaded EXE will be denied by ACL settings on-the-fly, he chose to use macro to launch something that was already saved to Users\Download since https://tinyurl.com/33w6mpf5 ultimately stored a static string to a disk path. So instead of hardcoding a local path, he simulated network calls.
- Most malware or trojans would have written binaries like EXE or DLL to install as persistent backdoor. This would be dealt with in real-time through ACL setting to deny read access. In YJ's case, he chose to pre-download to execute this test-case in the interest of time.
Code-Execution Chain Disrupted if...
- There's Type-1 compiled code-files like EXE or DLL, even when local-admin allowed a UAC. We saw it terminated here. Note that files written by Domain Administrators are owned by Administrators-group by default but not local-admin accounts. This means it is quite risky to install programs with Domain admin.
- Type-1 files are cheap & trivial to mutate. Online resources like Virus-Total are good QA tool for malware authors to "test waters" before the real-action. How can a database of "bad" files-signatures possibly keep up?
- Even for the so call Next-Gen Machine-Learning protection agents, it is merely more sophisticated "bad signatures". We have seen how in-memory assemblies loading with offensive C# trade-craft defeat such "protection". That means a file is still written, but it is a simple stub code that loads more serialized codes into the memory. If we block such calls, we will affect a number of legit applications that uses such legit APIs. Eg. Anti-piracy software controls can use such methods against file-reverse-engineering.
- App-Control is effective against foreign files. These files that are NOT part of the system until the time of infiltration or Initial Access (as per MITRE ATT&CK convention. Unfortunately, due to administrative overheads to maintain rules, some organizations choose either not embark on App-Control or give it up.
- Tracking file-hashes may seem intuitive but very challenging in practice. File ownership of running process on the other hand is much easier to track. If the executable is user-writeable, then attackers can overwrite it too!
- OpenEDR does not need constant policy or rule updates. It is based on a common-sense approach that installer files that you wish to deploy should NOT be user-writeable (file-ownership based) & be owned either by SYSTEM, TrustedInstaller or Administrators-group.
- There are unfortunately trend of running user-writeable app from paths like User's AppData & the likes. That is a bad practice. Have a look at demo of how to persist backdoor DLL with Onedrive: https://youtu.be/1j5pnvA6txM
Exploits are over-rated
- Media & marketing hype made it look like "Exploits" (of bugs) are a big deal. When you get your hands-on, one will realize that many public exploits are already caught even by free Anti-Virus like Windows Defender. And if we are diligent with patching, it is not so straight forward to launch malicious code reliably with exploits without proper host software enumeration as per of the reconnaissance steps.
- YJ had to disable Windows Defender just to emulate a Type 2 to launch a Type 3 shell-code, otherwise, the C2 session will be blocked.
- Type 2 along with Type 1 chaining are (system features & are) very effective without any need for specific Type 3 when there's no App-Control. Remember that Least Effort Principle applies.
Chaining is equally applicable to Server-side Infiltration
- Even server side are not spared, an example: https://thedfirreport.com/2021/06/03/weblogic-rce-leads-to-xmrig/?fbclid=IwAR0Vtnu_lhQkM90XTmHjaL-Lu7oAPde1Z7clF87A9rz6QB5BuW9eqi8qpxw
- Creating a Worm-effect with server-side is favoured by criminals since there is no need for successful client-side infiltration.