Litter

Scenario

A commonly used off-network host, which serves as a testing ground for various purposes, has been breached. The host, while not on the corporate network, has extensive access to numerous resources, making it a significant vulnerability point. It has come to light that company information, which should not have been on this host, has been stolen.

As the forensic investigator, your mission is multi-fold: you must unearth how this breach occurred, what company data has been exfiltrated, and whether the attacker employed any form of tunneling for the intrusion or data theft. This task demands your advanced understanding of cybersecurity, particularly network tunneling techniques, and your ability to perform thorough digital forensics to restore security and prevent further data loss.

Executive Summary

An off-network test host talked almost exclusively to one internal peer over DNS, with long hex-encoded labels under a fake Microsoft-looking domain. That pattern is dnscat2: the pcap holds a complete tunnelled shell session, and no dnscat2 decoder was at hand, so the labels were extracted with tshark and decoded with a small script. Replaying the stream shows the operator opening a shell, listing the working directory, and renaming the dnscat2 client they had left on disk to something installer-like. They then probed the user’s OneDrive folder, found it empty, and went after a customer PII CSV in a Documents subfolder, which was downloaded and printed back through the tunnel.

Artifacts

• suspicious_traffic.pcap: evidence/suspicious_traffic.pcap → tshark for conversation stats and field extraction, then a Python decoder for the dnscat2 payload

Decoding note: dnscat2 packs a 9-byte header (packet id, type, session id, sequence, ack) in front of the data, all hex-encoded into the DNS labels of the query name. Responses carry data back in the same encoding, so both directions of the shell have to be decoded and ordered by sequence number.

Command and Control

Protocol hierarchy on the capture shows DNS far out of proportion for a single workstation. Query names are long strings of hex under one parent domain (microsofto365.com), which is a typosquat of a Microsoft service rather than a real resolver lookup.

tshark -r suspicious_traffic.pcap -q -z io,phs

IP conversation stats rank one pair far above everything else: the client 192.168.157.144 and one peer. That peer answers the hex queries with hex in its responses, which makes it the DNS tunnel server rather than a normal resolver.

tshark -r suspicious_traffic.pcap -q -z conv,ip

Execution

Extract the DNS fields to a TSV and decode the hex labels, ordering by dnscat2 sequence number. Past the session setup and the client’s command (DESKTOP-...) banner, the first operator input sent down the shell session (frame 13937) is an identity check.

tshark -r suspicious_traffic.pcap -Y dns -T fields -e frame.number -e ip.src -e dns.flags.response -e dns.qry.name -e dns.resp.name > work/dns.tsv

python3 -I dnscat_decode.py work/dns.tsv > /tmp/d.txt

Tip: The early command (DESKTOP-UMNC...) string is the client announcing itself, not an attacker command.

The decoded shell output includes a dir listing of the working directory. It contains the dnscat2 client binary the attacker dropped, and the version is part of its filename.

grep -i dnscat2 /tmp/d.txt

Defense Evasion

Further into the decoded stream the operator issues a ren against the client executable (frame 18707) to give it a plausible installer name. A later dir confirms the new name is on disk.

grep -iE 'ren |win_installer' /tmp/d.txt

Discovery

The operator lists the OneDrive folder under the test user profile. The dir output ends with a summary line giving the file count.

grep -A8 -i 'OneDrive' /tmp/d.txt

Collection

Search the operator input for the dnscat2 download command (frame 59992). It names the full path of the file pulled back through the tunnel.

grep -i 'download' /tmp/d.txt

Exfiltration

The file contents also come back through the shell via type user details.csv. Reassemble that response by dnscat2 sequence number and count the records. The CSV holds records indexed 0 to 720, so the total is the index count, not the last index.

python3 -I dnscat_decode.py work/dns.tsv > /tmp/d.txt

Gotcha: The last record index is 720. Zero-based indexing means 721 records.

Attack Summary

Phase	Action
Command and Control	dnscat2 session established over DNS to 192.168.157.145 under a typosquatted Microsoft domain
Execution	Shell opened; first command whoami
Discovery	dir of the working directory reveals the dnscat2 0.07 client binary
Defense Evasion	Client renamed to win_installer.exe
Discovery	OneDrive folder enumerated, empty
Collection	Customer PII CSV located under Documents
Exfiltration	CSV downloaded and printed through the tunnel, 721 records

IOCs

Type	Value
IP (DNS C2)	192.168.157[.]145
IP (victim)	192.168.157[.]144
Domain (tunnel)	microsofto365[.]com
File	dnscat2-v0.07-client-win32.exe
File (renamed)	win_installer.exe
File (stolen)	C:\Users\test\Documents\client data optimisation\user details.csv

MITRE ATT&CK

Technique	ID	Description
Application Layer Protocol: DNS	T1071.004	C2 carried in DNS queries and responses
Protocol Tunneling	T1572	dnscat2 shell tunnelled over DNS
Command and Scripting Interpreter: Windows Command Shell	T1059.003	whoami, dir, ren, type run through the dnscat2 shell
Masquerading: Match Legitimate Name or Location	T1036.005	dnscat2 client renamed to an installer-style name
File and Directory Discovery	T1083	dir of the working directory and the OneDrive folder
Data from Local System	T1005	Customer CSV read from Documents
Exfiltration Over C2 Channel	T1041	File contents returned through the DNS tunnel

Defender Takeaways

Long, high-entropy DNS labels under one parent domain are a tunnel signature. Hex queries hundreds of times against a single lookalike domain stand out in query-length and unique-subdomain-count analytics. Alert on both per client, and on newly seen domains that resemble a Microsoft brand.

An off-network host with broad access needs egress DNS control. The test host could reach the tunnel server directly. Forcing all DNS through an inspected internal resolver, and blocking direct outbound port 53, removes the channel.

Pcap-only evidence still reconstructs the whole session. dnscat2 carries commands and output unencrypted by default, so the shell transcript and the stolen file were recoverable from the capture. Retain DNS logs or full packets for hosts with access to company data.

Company data did not belong on this machine. The PII CSV sat in a user Documents folder on a lightly managed host. Data-loss controls and a policy against copying customer data to test systems would have left nothing to take.

Conclusion

The attacker ran an interactive shell and walked off with 721 customer records without a single non-DNS connection. The traffic was unencrypted and trivially decodable, but only if someone looked at DNS as a data channel.