SOC164 - Suspicious Mshta Behavior Alert
Analysis of the malicious nature of mshta.exe, a binary signed by Microsoft
Last updated
Analysis of the malicious nature of mshta.exe, a binary signed by Microsoft
Last updated
Hello, aspiring blue teamers.Hope you are keeping yourselves hale and hearty
Welcome to this blog entry, as we will be tackling the “SOC164 — Suspicious Mshta Behaviour” alert on the Let’s Defend platform. It was vastly different from the other alerts that I have previously solved on this platform
Let’s jump headfirst into it.
NOTE: Always remember to investigate alerts from Let’s Defend, on a VM.
Alert particulars provided to the analyst:-
Create the case
Start the playbook
A LoLBin is any binary supplied by the operating system that is normally used for legitimate purposes but can also be abused by malicious actors. Default system binaries have unexpected side effects, which may allow attackers to hide their activities post-exploitation.
Determine which binary is supplied by the operating system but is also home to suspicious activities. To do this, you can resort to the alert details on the Monitoring page or Endpoint Security.
Previously, you found the related binary. Now, we’d like you to determine whether it was used for malicious purposes. You can use the link below to determine how legal binary can be used to perform malicious activities.
There are some characteristics common to command lines:
They often have a file-path or other artifact as one of the arguments, that changes based on the user environment or machine, such as usernames or system GUIDs in file paths. The order of arguments in the command change, or a single argument has a slightly different value. They can have randomly generated strings in embedded URLs or file paths. They can be obfuscated on purpose by attackers (variable assignment, invocation of string expressions created on the fly, etc). (list source: sophos.com)
Is the current activity suspicious?
Before we start the investigation, let's try to know more about the mshta.exe binary
To start, it is a signed, native Microsoft binary that already exists on Windows that can execute code in a variety of ways, and in today’s living off the land culture that attackers love, this makes it a prime application of interest since code execution can be proxied through it.
There are four primary methods by which adversaries leverage Mshta to execute arbitrary VBScript and JScript:
Inline via an argument passed in the command line to Mshta
Let's return to the platform.
Probing the Process logs of the host, we can find that the binary -mshta.exe did indeed run. A MD5 hash is attached with the instance
MD5 Hash of .exe = 0b4340ed812dc82ce636c00fa5c9bef2
We are given further evidence that the payload was run, in CLI mode aided by a Powershell script (Ps1.hta)
Related hash of .ps1 = 6685c433705f558c5535789234db0e5a
Next, we proceed to check out the 'Log Management' section, to find any network traffic logs corresponding to the victim's IP
We got 2 hits, but only 1 fit the bill. Seems like the binary was accessed from the malicious IP - 193.142.58.23
When expanding the Process list, we can find an instance of Powershell being executed.
We read earlier that one of the methods in which mshta.exe operates is by executing in an HTA file. So, this means that mshta.exe is indeed being executed for malicious purposes
Hence, we can mark it as Suspicious
Event marked as suspicious
What is the purpose of suspicious activities, performed with legal binaries for this incident?
From our initial research on the mshta binary, we found that it is mostly exploited to remotely execute HTML pages
Let's select 'Execute' from the options above
Execute
Who performed the suspicious/malicious activity using a binary? It would be helpful to control the binary’s parent process.
So the attack was supposedly done by a person (threat actor) and not by malicious software
User
Please go to the “EDR” page and contain the user machine!
Let's proceed to contain the victim host
We have successfully contained the host to prevent the spread of threats on the Let’s Defend network
Let’s proceed to submit evidence collected so far, that is relevant to the attack
Finish the playbook
Close the alert
This case was fascinating and I was double happy with the fact that I got all answers right!
Every alert solved is a step towards perfection and I am pretty happy with the score I received.
The SOC Analyst was presented with a suspected binary file that was being used by threat actors to perform remote code execution. With the availability of networking logs and command history, from the victim host, we were able to find the attack vector (Powershell CLI execution), used to conduct the remote attack.
Further analysis was performed on the binary file to find if it had any links to existing malware.It was found that no such association existed. The vulnerability presented in this case was the usage of binaries being signed by trusted entities(in this case Microsoft), which was in turn, being used by attackers to conduct attacks
Thank you for reading this blog entry, and stay tuned as I try to close down more SOC alerts……
My audience has a voice. Feel free to reach out to me, on my socials (links are on top of this page) for any queries to be addressed. Dropping a sweet message would make my day
Let your opinion about this write-up be known, by selecting any one of the emojis below!
(Definition: )
According to ,
According to ,
File-based execution via an
By calling the export function of mshtml.dll with as an alternative to mshta.exe
Let’s have a look at , to identify any characteristics of the binary.Looking it up, we can find the execution methods it employs.They cover languages like JavaScript and VBScript
By analyzing the MD5 hash of the binary on , we can conclude that it is not associated with any malware strain. Joe Sandbox can attest to that claim.
