Masquerade
Analyzed a spearphishing attack where a Finance employee executed a malicious script posing as a system admin update. Traced RC4-decrypted payload delivery via PowerShell, identified C2 traffic hidden inside Google HTTP responses, and decrypted double-encrypted AES GUID commands to recover the flag.
let's get a feel on the scope first. 44 packets for HTTP, DNS has 168 packets. let's check both protocols for unusual queries.
there's a recurring msn.com with different subdomains. let's check the HTTP statistics to see if this is where the user made requests.
multiple HTTP requests with different files for 34.174.57.99 aside from api.edgecloud.xyz. let's cross reference this IP with the conversation statistics.
a few notable IPs stand out. 34.174.57.99 shows up in the HTTP requests. there's also a one-way connection from 172.172.255.216 (every connection was refused) and back and forth from 13.89.179.14. not much on 172.172.255.216 since all connections were refused. moving on to 34.174.57.99 — this is where we see a lot of juice. the connection happened right after a request to download AMD.bin.
let's cross check the packet analysis with the Event Viewer. we're inspecting Event ID 4104 — that's where PowerShell script block logging lives.
that confirms what we saw in the packets. there was an HTTP GET to download AMD.bin and it was saved as amdfedrsr.exe. the script block also shows the RC4 decryption key used to unpack the binary.
going back to Wireshark, there's a lot of HTTP noise. if we follow the streams it's just traffic directed to Google — generated to blend in.
basing on the HTTP request statistics from earlier, let's add that to the filter and cut through the noise.
now we're down to 4 packets. looking at the GUIDs in these — they look like encoded strings rather than random gibberish.
still looks gibberish though. let's deconstruct the exe first to understand how it actually works. inspecting the whole function shows that the malware routes traffic through Google to look clean, and hides the actual commands inside CSS responses.
now we know the mechanism. let's crack those GUIDs. we first get the SHA256 of the cipher to use as the AES decryption key.
the GUID string S is double encrypted. to decrypt it we reverse the process step by step.
first step done. now we take 16 bytes and decode using the key.
first GUID decrypted. we use the same process for the rest.
this one is checking for privileges.
this one is for connections.
the last GUID contains the flag.
from the decrypted PowerShell execution we saw in the Event Viewer.
the PowerShell script used RC4 to decode the binary before saving the executable.
visible in the PowerShell script as the $k variable.
following the HTTP stream on the AMD.bin request gives us the server response timestamp.
run sha256sum against the exe file, not the binary. the value will be consistent regardless of what the file is named.
from the conversation stats and HTTP analysis, the C2 server is clearly 34.174.57.99.
AES to encrypt the traffic, with the key found in the malware binary.
from the last GUID decryption — the final command and the flag.
- →traffic masquerading works by blending into trusted destinations. the malware routed C2 through Google and hid commands inside CSS responses. familiar domains in your traffic are not automatically clean — what's inside the packets matters just as much as where they go
- →multi-layer encryption requires understanding the flow before you can reverse it. getting the AES key from the binary, then following the double-encryption steps in order was the only way through. methodology before tools
- →Event ID 4104 was the key to confirming what happened on the host. script block logging caught the full PowerShell execution including the RC4 decryption and the AMD.bin download. worth having enabled in any environment you monitor
- →static analysis was enough to fully understand this attack without running anything. deconstructing the exe, reading the PowerShell logs, and following HTTP streams in Wireshark covered the whole picture
- →file names alone mean nothing. amdfedrsr.exe is designed to look like a legitimate AMD driver process. hash verification and behavioral analysis are what actually tell you what something is