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.
- 01 Initial AccessFinance employee ran a malicious script posing as a system admin update
- 02 ExecutionPowerShell fetched AMD.bin, decrypted it with RC4, and saved it as amdfedrsr.exe
- 03 Command & ControlImplant polled 34.174.57.99, hiding commands inside fake Google HTTP responses
- 04 AnalysisDouble-encrypted AES GUID commands reversed with CyberChef to recover the attacker's command sequence
Scoping the Traffic
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.
Event Viewer Analysis
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.
C2 Traffic Analysis
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 to see what's actually going on. turns out the malware keeps reaching out to the C2 at 34.174.57.99 for commands. the C2 responds with a fake Google homepage so the traffic looks clean to anyone watching. the actual commands are buried inside HTML comments disguised as CSS references.
Decrypting C2 Traffic
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.
Q&A
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.
overall this is a really great room. i enjoyed the whole decryption thing and the investigation of the malicious file. the most interesting part was figuring out that the C2 traffic was hiding inside what looked like normal Google traffic. good lesson in not trusting familiar domains blindly and always looking at what is actually inside the packets.
- →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
| Type | Indicator |
|---|---|
| C2 | hxxp://34.174.57.99 |
| Domain | api-edgecloud.xyz |
| File | AMD.bin |
| File | amdfedrsr.exe |