Case Overview
Arya Stark gets an email presumably from Direwolf with an attachment. It looks suspicious and she forwards it to the Security.
Environment
Winterfell Server Network (192.168.10.0/24) consisting of DNS (192.168.10.230) Centos7 with bind ns1.winterfell.local and Mail server (192.168.10.140) mail.winterfell.local, Centos7 with Postfix and Dovecot.
Winterfell Desktop Network (192.168.11.0/24), having IPs: 192.168.11.101, 192.168.11.102, 192.168.11.103, 192.168.11.104, 192.168.11.105. 192.168.11.105 is Security’s IP. All desktops have Win7 SP1 with MOffice 2010 installed. For the machine to be vulnerable for the below attack steps, Windows Firewall should be disabled and macro turned on for Office Docs (Trust Center > Trust Center Settings > Macro Settings). Also, PsExec requires the DWORD called LocalAccountTokenFilterPolicy in the registry under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\ System set to a value of 1.
External (attacker’s) Network (192.168.239.0/24), consisting of Attacker casterlyrock 192.168.239.130 and attacker 192.168.239.110.
It’s impossible to connect to Winterfell Desktop Network (192.168.11.0/24) from external network (192.168.239.0/24). Only Winterfell Server Network (192.168.10.0/24) is allowed. However, Winterfell Desktop Network (192.168.11.0/24) can talk to the outside world.
Firewall is placed between External (attacker’s) Network (192.168.239.0/24) and Winterfell subnets. It runs Centos7 as well. Uses iptables as a firewall.
Lab Config
capinfos dedup.pcap # get the summary and statistics of a pcap file
nfpcapd -r dedup.pcap -l /var/log/netflow # populate Netflow (nfdump/nfpcapd) from pcap
snort -c /etc/snort/snort.conf -q -k none -l /var/log/snort -r dedup.pcap # populate snort from pcap
passivedns -r dedup.pcap -d '|'
# convert from UNIX timestamps
cat passivedns.log | awk -F'|' '{OFS="|";printf("%s",strftime("%Y-%m-%d_%H:%M:%S",$1));$1="";printf $0}' > passivedns-ts.log
VMWare Workstation. mergecap to merge separate files.
Layout
Detection & Analysis
We open the letter and see docm extension which indicates Word2007+ (implying Word file with macro) while it the letter itself it’s claimed to be a picture. We calculate the attachment’s hash md5sum Ghost.docm and the message’s hash as well md5sum 'Picture of Ghost (52.2 Kb).msg'. And make two copies of each. Running file Ghost.docm confirms that the file is a Word document. Running exiftool Ghost.docm to see the creator, the type and some other relevant meta data.
Get the macro from the file with OfficeMalScanner, by first running inflate and then info. Usage example was described by me here. Calculate the md5sum vbaProject.bin and make a copy as well (two copies, better).
So, we have the following: the file is claimed to be a picture but it’s actually a macro-enabled Word document. The sender and the creator of the document do not match. The event now becomes an incident and requires further investigation.
Both the message and the attachment are detected as malicious by VirusTotal (is it okay to use this service for such cases?).
Containment Phase
We need to know, who else got this message. We open the network capture and filter SMTP containing “Picture of Ghost” and associated with astark: smtp contains "Picture of Ghost" and smtp contains "astark". We see 5 emails sent. Use follow TCP stream on this packet. Looks like there were no replaying.
How to determine that the email was not relayed? Email headers? Which ones?
We now have an IP - 192.168.239.130. The mail client is identified as sendEmail-1.56 (X-Mailer header). Hostname of the originated PC is casterlyrock.westeros.local. Other three emails have the same characteristics and therefore are most likely related. Message-ID uniquely identifies the emails and using this information we can delete them from postfix to avoid further damage. Four PCs that are presumably compromised. We can see whether anyone communicated with these addresses:
nfdump -R /var/log/netflow -q -O tstart -A srcip,dstip -o 'fmt:%ts %sa %da %byt %fl' 'ip 192.168.239.130' | awk 'BEGIN{printf "%23s %16s %15s %8s %5s\\n", "Start time", "Source", "Dest", "Bytes", "Flows"};{print};'
We see that at 14:05 there was a request to DNS and then shortly after to the mail server. Then we see lots of requests between 192.168.11.104 starting from 15:33 and then 192.168.11.101 starting from 16:17. Looks like they’ve opened these attachments… . Let’s examine 192.168.11.104’s possible compromise.
nfdump -R /var/log/netflow -q -b -O tstart -o 'fmt:%ts %sap %dap %pkt %byt %fl' 'ip 192.168.239.130 and ip 192.168.11.104' | cut -c 12-19,25- | awk 'BEGIN{printf "%8s %21s %21s %8s %8s %5s\\n", "Start", "Source", "Dest", "Packets", "Bytes", "Flows"};{print};'
We see three conversations between 192.168.239.130 and 192.168.11.104.
The first conversation can be filtered by:
nfdump -R /var/log/netflow -q -O tstart -A srcip,dstip -o 'fmt:%ts %sa %da %byt %fl' 'ip 192.168.239.130 and ip 192.168.11.104' | cut -c 12-19,25- | awk 'BEGIN{printf "%23s %16s %15s %8s %5s\\n", "Start time", "Source", "Dest", "Bytes", "Flows"};{print};'
Seems like the client has initiated this connection, GETing a large MZPE (.exe) file. We save the exe as RAW, calculate the hash (md5sum) and make a copy. Identified as Meterpreter by VT. Since the client initiated the traffic, it is some reverse shell. Given that HTTP traffic was used, it’s probably /windows/meterpreter/reverse_http payload. We now have enough information to pass forward to forensics.
Let’s examine the second conversation.
nfdump -R /var/log/netflow -q -O tstart -o 'fmt:%ts %sap %dap %pkt %byt %fl' 'ip 192.168.239.130 and ip 192.168.11.104 and port 49161' | cut -c 12-19,25- | awk 'BEGIN{printf "%8s %21s %21s %8s %8s %5s\\n", "Start", "Source", "Dest", "Packets", "Bytes", "Flows"};{print};'
We see that after this large file download (first conversation), there are lots of small packets sent every 5 seconds. This is usually an indication of a C&C traffic. The traffic is encrypted (/windows/meterpreter/reverse_http encrypts the traffic).
The third conversation is when the two parties have switched to 8080 port.
nfdump -R /var/log/netflow -q -O tstart -o 'fmt:%ts %sap %dap %pkt %byt %fl' 'ip 192.168.239.130 and ip 192.168.11.104 and port 49162' | cut -c 12-19,25- | awk 'BEGIN{printf "%8s %21s %21s %8s %8s %5s\\n", "Start", "Source", "Dest", "Packets", "Bytes", "Flows"};{print};'
The victim initiated this conversation. After 3-way handshake there is a payload 0x2f9e0e00. Then there is a large amount of data transferred from the attacker. Analysis reveal that’s another exe. We again extract this file, get the hash and copy the file. To convert to binary: cat ex-02-hex.txt | xxd -r -p > ex-02. Identified as meterpreter by VT. Probably windows/meterpreter/reverse_tcp payload. 0x2f9e0e00at the beginning is the indication of meterpreter reverse_tcp. Since the traffic is encrypted, we would need a forensics examination to decrypt it.
Has this system communicated with other fellow systems trying to compromise them?
nfdump -R /var/log/netflow -q -O tstart -A srcip,dstip -o 'fmt:%ts %sa %da %byt %fl' 'ip 192.168.11.104' | awk 'BEGIN{ printf "%23s %16s %15s %8s %5s\\n", "Start time", "Source", "Dest", "Bytes", "Flows"};{print};'
Examine the traffic with the mail server (192.168.10.140) mail.winterfell.local in Wireshark. We see that this traffic used port 995. POP3 protocol uses this port to deliver mail to Outlook clients. The traffic is encrypted. This communication happened less than a minute before the connection over 80 port above.
It would be a sin not to turn to our DNS logs. Who knows what else we might find out. But there are no logs that would indicate that 192.168.11.104 performed DNS lookups of any sort. How likely is that? Possible reasons:
- the host performed no queries
- the host had the desired DNS name in its cache
- errors not processed by PassiveDNS (since there are some DNS lookups in Wireshark records). SANS states the possible reason for the errors:
The processing error could be due to the Wireshark capturing the packets prior to the NIC, so they did not have the necessary padding, and thus were not recognised by PassiveDNS as valid DNS packets.
Since DNS logs are useless in this case, let’s see the conversations with the DNS server in Wireshark: ip.addr == 192.168.10.140 and ip.addr == 192.168.11.104. Filter out all irrelevant traffic: ip.addr == 192.168.11.104 and udp.port == 53 !dns contains "update" and !dns contains "msn".
Timeline:
15:33:06 - 192.168.11.104 queries mail.winterfell.local.
15:33:56 - 192.168.11.104 queries ironislands.westeros.local(attacker’s server, ip 192.168.239.130). This query took place right before the conversation was started with the attacker. This is a IoC that could be used to find other compromised systems.
16:03:56 - scanning of 192.168.11.101
16:12:02 - scanning of 192.168.11.102
16:12:33 - scanning of 192.168.11.103
16:17:38 - 192.168.11.104 started talking to 192.168.11.101 over 445 TCP.
16:17 - data sent from 192.168.11.104 to the attacker.
Then we also observe that 192.168.11.104 communicated extensively with 192.168.11.101, 192.168.11.102, and 192.168.11.103, which is not usual for this network. It’s a huuuge number of flows, scanning?
nfdump -R /var/log/netflow -q -O tstart -b -c 8 -o 'fmt:%ts %sap %dap %byt %flg' 'ip 192.168.11.104 and ip 192.168.11.101 and | cut -c 12- | awk 'BEGIN{ printf "%12s %22s %18s "Source", "Dest", "Bytes", "flags"};{print};' flags S and not flags AFRPU' %11s %5s\\n", "Start time",
Checking for scanning indicators above. Yes, SYN scan. No other traffic was seen (good sign? 🪧)
nfdump -R /var/log/netflow -q -O tstart -b -c 10 -o 'fmt:%ts %sap %dap %byt %flg' 'ip 192.168.11.104 and ip 192.168.11.101 and flags SA' | cut -c 12- | awk 'BEGIN{ printf "%12s %22s %18s %11s %5s\\n", "Start time", "Source", "Dest", "Bytes", "flags"};{print};'
192.168.11.104 started talking to 192.168.11.101 over 445 TCP. This traffic is unusual in that we are not expecting SMB traffic between desktops. We see 5 flows to different ports associated with SMB protocol: 135 (ASF), 139 (ASF), 445 (ARSF), 3389 (ARSF) and 445 again (APRSF). The first 4 look like a scan and the last one - some real activity. Looks like the attacker probed all possible ports for SMB and 445 returned that the port was open. And now sends something over this port. To examine this particular flow closer:
nfdump -R /var/log/netflow -q -O tstart -b -o 'fmt:%ts %te %sap %dap %byt' 'ip 192.168.11.104 and ip 192.168.11.101 and port 53613' | cut -c 12-19,24,35- 42,47- | awk 'BEGIN{ printf "%8s %8s %21s %21s %10s\\n", "Start", "End", "Source", "Dest", "Bytes"};{print};'
3691 bytes were sent from 192.168.11.101:445 to 192.168.11.104:53613. The attacker acting from the 104 PC (Sansa) used the account of John Snow (jsnow) for this communication. Hence, this account is compromised. Looks like a file \\svcctl was created and run:
For whatever reason, Wireshark’s File > Export Objects >SMB was unable to extract that file (pipe with zero bytes). Let’s see the DNS logs for our IoC for this PC to see, how his password could get compromised. We see ironislands.westeros.local lookup originating from 192.168.11.101 (grep '192.168.11.101' passivedns-ts.log), but no mail lookup. Hence, the compromise flow was different and didn’t involve the email we started with.
Since we know that the attacker is at 192.168.239.130 and John on 192.168.11.101, let’s filter the pcap accordingly:
nfdump -R /var/log/netflow -q -O tstart -b -o 'fmt:%ts %sap %dap %byt %fl' 'ip 192.168.239.130 and ip 192.168.11.101' | cut -c 12- | awk 'BEGIN{ printf "%12s %22s %20s %9s %5s\\n", "Start time", "Source", "Dest", "Bytes", "Flows"};{print};'
We see two conversations: from 4444 port and from 8082. In Wireshark both 4444 and 8082 traffic look like it was probably a download. Once agains it was an exe.
cat exe-03.txt | xxd -r -p > ex-03
md5sum ex-03
518afbf3bb3ccdf41b3523a743a16239 ex-03
cat exe-04-hex.txt | xxd -r -p > ex-04
md5sum ex-04
b8e9c33c0492be88d4ba4631c45956d1 ex-04
Make two copies and check against VT, the file identified as a Meterpreter. It’s probably a windows/meterpreter/reverse_tcp payload since:
- victim initiated the network traffic,
- traffic is TCP, and
- four-byte packet after the three-way TCP handshake is a characteristic of Metasploit’s Meterpreter
reverse_tcppayload.
Lessons Learned
References
[1] IBM course