Eric Fischer from the Purchasing Department at Bartell Ltd has received an email from a known contact with a Word document attachment. Upon opening the document, he accidentally clicked on “Enable Content.” The SOC Department immediately received an alert from the endpoint agent that Eric’s workstation was making suspicious connections outbound. The pcap was retrieved from the network sensor and handed to you for analysis.
Task: Investigate the packet capture and uncover the malicious activities.
Credit goes to [Brad Duncan](https://www.malware-traffic-analysis.net/) for capturing the traffic and sharing the pcap packet capture with InfoSec community.
NOTE: DO NOT directly interact with any domains and IP addresses in this challenge.
Malicious ZIP Dropper and Cobalt Strike C2 Activity
10.9.23.102
Victim 10.9.23.102 downloads documents.zip from attirenepal[.]com via LiteSpeed
ZIP file contains chart-1530076591.xls
Victim begins POSTing encoded data to maldivehost[.]net
Encrypted HTTPS connections initiated to multiple domains:
Two IPs begin probing the victim:
Tracking beacon sent: GET /spfpoolh/cacerts.crl returns image/gif
Victim sends GET requests to the C2 IPs
C2 behavior continues, possible data exfiltration detected
Phase | ID | Technique | Description |
---|---|---|---|
Initial Access | T1204.002 | User Execution: Malicious File | documents.zip containing .xls macro from attirenepal[.]com |
Command & Control | T1071.001 | Application Layer Protocol: Web | POST request to maldivehost[.]net and Cobalt Strike IPs |
C2 Infrastructure | T1583.001 | Acquire Infrastructure: Domain | Use of multiple domains for payload delivery and staging |
Discovery | T1082 | System Information Delivery | Possibly trough macro payload |
Exfiltration | T1041 | Exfil over C2 Channel | Encrypted POST data after infection phase |
Defense Evasion | T1001.003 | Data Obfuscation: protocol impersonation | Traffic disguised as OCSP and GIF requests |
Reference: [MITRE ATT&CK Navigator] ( https://attack.mitre.org/ )
Time to open carnage.pcap and begin the forensic joyride.
First thing: the question asks for a specific timestamp format. Because why not?
Head to View > Time Display Format and pick something human-readable — preferably one that doesn’t look like binary soup.
Next, let’s see who’s been busy on the wire.
Go to Statistics > Endpoints > IPv4, sort by packets
And bingo: one IP is making the rest look unemployed.
Top talker: 10.9.23.102 with 54MB of glorious traffic. Definitely our victim.
Let’s keep that one on a leash.
Now let’s look for the first contact.
Filter by http and look for any GET or POST requests.
Boom — the first HTTP packet is from 10.9.23.102 requesting a documents.zip file. And the server obliges with a shiny 200 OK.
Peeking at the packet details, the domain behind the gift is attirenepal[.]com.
Looks like our infection kicks off here. Follow the TCP stream to see what’s wrapped inside that zip.
And what do we find? A charming .xls file named chart-1530076591.xls, served with love from a LiteSpeed webserver. If you think this is just a spreadsheet and not a macro-laced disaster waiting to happen — bless your heart.
Right after the download, our victim starts POSTing multiple times to 208[.]91[.]128[.]6 Chunked encoding, all accepted — classic exfil or C2 behavior.
Domain involved? maldivehost[.]net. Totally legit name.
Totally not suspicious.
Meanwhile, things escalate.
Two IPs (185[.]125[.]204[.]174 on port 8080 and 185[.]106[.]96[.]158 on port 80) start hammering the victim, trying to handshake like it’s speed dating for C2 servers.
Then it gets weird: one of them sends a GET /spfpoolh/cacerts.crl, and the server responds with… an image/gif? Yep. Before the TLS session even kicks off.
That’s almost certainly a tracking beacon or pre-exploitation profiler — the digital version of asking “Are you online?” before pushing a payload.
And then the victim starts responding like they’re old friends. GET requests go out, all warmly accepted. Cozy..
Time to confirm just how shady this party is.
attirenepal[.]com? Yep — flagged as malicious on VirusTotal
maldivehost[.]net? Also bad news.
The first connection is definitely our first packet 1735
2021-09-24 16:44:38
We saw in the initial recon
documents.zip
we checked this one too
attirenepal[.]com (defanged)
we found this following the TCP stream of the first packet
chart-1530076591.xls
we found this one following the TCP stream
LiteSpeed
in the same TCP stream we can find the version of the server in the field “x-powered-by”
PHP/7.2.34
We now zoom in on a more precise timeframe:
That gives us a clean window to find out what else the victim may have contacted — especially over HTTPS.
Lets start finding our DNS request from the host victim:
ip.src==10.9.23.102 && dns && frame.time >= "2021-09-24 16:44:38" && frame.time <= "2021-09-24 16:46:16"
This reveals 3 shady domains:
To be sure those are the 3 domains lets follow the udp stream and see the ip of those domains
finejewels[.]com[.]au -> 148[.]72[.]192[.]206
thietbiagt[.]com -> 210[.]245[.]90[.]247
new[.]americold[.]com -> 148[.]72[.]53[.]144
Now lets check the full communication filtering for bidirectional traffic:
ip.addr==10.9.23.102 && ip.addr==148.72.192.206 || ip.addr==210.245.90.247 || ip.addr==148.72.53.144
And we find:
– TCP handshake on port 443
– TLS handshake with SNI
– Large encrypted application data flowing
Confirmed: These 3 domains served content — likely more malware.
finejewels[.]com[.]au, thietbiagt[.]com, new[.]americold[.]com
Well we can check on dns lookup or directly on virustotal that we have already open
GoDaddy
So we know that our host communicated to185[.]125[.]204[.]174 and 185[.]106[.]96[.]158
Let’s check those 2 ip address on virus total
So those are our 2 ip
185[.]125[.]204[.]174, 185[.]106[.]96[.]158
We saw at the beginning but lets just check the hypertect transfer protocol of the first packet
ocsp.verisign.com
for this one still with thesame filter of before
ip.addr==185.106.96.158 && http
we can go view -> name resolution -> resolve network address
Let’s check on virustotal what we found to be sure
And this is it
survmeter.live
same drill
securitybusinpuff.com
well we noticed at the beginning
so just check for the victim host ip addr and http.method POST and see what we got
ip.addr==10.9.23.102 && http.request.method=="POST"
maldivehost.net
Just check the post of the first packet
zLIisQRWZI9
Just look at the length column
281
just follow the http stream of the packet we are inspecting
Apache/2.4.49 (cPanel) OpenSSL/1.1.1l mod_bwlimited/1.4
lets look for
ip.addr==10.9.23.102 && dns && frame contains "api"
2021-09-24 17:00:04
We can see in the screenshot before
api.ipify.org
Let’s try to check for smtp
farshin@mailfa.com
So, what have we learned?
From ZIP to beacon to exfil, Carnage delivered a full buffet of “don’t do this in production”, served with just enough misdirection and encrypted traffic to keep any SOC analyst awake at night.
On to the next incident. Preferably one with fewer GIFs and more firewalls.
Cybersecurity learner, log nerd, and TryHackMe badge hoarder. Let’s connect on LinkedIn before I get pulled into another packet capture.
Apparently we have to tell you this: yes, cookies are used. They're not edible, and no, you can't escape them — but you can pick what gets tracked. Yay for EU law!