Unit 7: Reading captures in Wireshark · Lesson 6 of 6 · 22 min
Case file: the monitoring server that called home
Find a trusted server making DNS lookups for random-looking names and connecting to one of them, then lock down what it may reach.
case file
SolarWinds Orion SUNBURST
SolarWinds · 2020
Attackers inserted a backdoor into SolarWinds Orion software builds, and digitally signed trojanized updates were distributed from March to May 2020. The backdoor stayed dormant for up to two weeks, then used DNS-based command and control disguised as normal Orion traffic, with selected victims receiving follow-on intrusions. CISA issued Emergency Directive 21-01 in December 2020, and the US government attributed the activity to Russia's SVR in April 2021.
What went wrong
The vendor's build pipeline was compromised so that signed, legitimate-looking updates carried a backdoor; customers ran a highly privileged monitoring platform with broad network reach and outbound internet access.
What would have stopped it
- Harden and monitor build systems (isolated, reproducible builds, integrity checks between source and shipped artifacts).
- Restrict outbound internet access from privileged management servers such as network monitoring platforms to only required destinations.
- Limit the privileges and credentials held by monitoring tools, and tier administrative access.
What defenders could have seen
- DNS queries from Orion servers to unusual generated subdomains (for example of avsvmcloud[.]com).
- Logins from unusual ASNs or impossible-travel patterns, and one source authenticating to many hosts with many accounts.
- Short-lived scheduled task or file replacements on servers (delete-create-execute-restore patterns).
sourcescisa.govcloud.google.com
mission
- You are
- The analyst reviewing traffic from server network tools.
- Situation
- nms01 runs the network monitoring platform and has broad access everywhere. Its egress policy is in
~/inventory/nms01-egress.txtand six hours of its traffic are innms.pcap. This lab is modelled on the SolarWinds SUNBURST case. - Goal
- Compare what nms01 contacts with what it needs, and describe anything unexpected.
- Hand in
- The unexpected domain, the IP it connected to, and the egress rule that would block it.
Signed update, unexpected behaviour
- Vendor buildcompromised before signing
- Signed updateinstalled on nms01 as normal
- DNS lookupsrandom subdomains of one domain
- Connectionto the one name that resolved
Read what nms01 is supposed to reach
Start from the approved list, as always.
cat nms01-egress.txt
nms01 (10.20.0.60) network monitoring server
needs to reach on the internet: updates.nms-vendor.example tcp 443
everything else outbound: not required
current firewall rule: nms01 to any, tcp 443, allow
you should see One vendor update host. Yet the firewall rule allows it to reach anything on 443.
Count every name it looked up
Normal software looks up the same few names. Generated names are different every time.
capinfos -c nms.pcap File name: nms.pcap Number of packets: 77 tshark -r nms.pcap -Y 'dns.flags.response == 0' -T fields -e dns.qry.name | sort | uniq -c 1 0hxosnibe8trgv3a.appsync-api.example.net 1 68mgtrcsa5nskcua7k7vu.appsync-api.example.net 1 b974dqem5x12so3r4ilrx5.appsync-api.example.net 1 eswvli1fcfuglx29tq52.appsync-api.example.net 1 p7xyyikcw87eg8457o9an.appsync-api.example.net 1 pjj5njpmu9niuriw928yn.appsync-api.example.net 6 updates.nms-vendor.example
you should see Six lookups for the vendor, and six one-off random subdomains of appsync-api.example.net.
See which ones resolved
Most generated names fail. The one that resolves is the one that matters.
tshark -r nms.pcap -Y 'dns.flags.response == 1 && dns.a' -T fields -e dns.qry.name -e dns.a | sort -u
0hxosnibe8trgv3a.appsync-api.example.net 203.0.113.88
updates.nms-vendor.example 198.51.100.90
you should see Only one random name got an address: 203.0.113.88.
Confirm the connection
TLS still shows the name a client asked for in the handshake.
tshark -r nms.pcap -Y tls.handshake.extensions_server_name -T fields -e ip.dst -e tls.handshake.extensions_server_name
198.51.100.90 updates.nms-vendor.example
203.0.113.88 0hxosnibe8trgv3a.appsync-api.example.net
you should see nms01 opened a TLS session to that address, using the random name.
defender tip An allowlisted egress rule (only updates.nms-vendor.example) would have stopped this connection even before anyone knew the update was bad.
nms01's outbound rule
nms01 -> any tcp 443 allow
A compromised update can reach any server on the internet.
nms01 -> updates.nms-vendor.example tcp 443 allow nms01 -> any drop, log
Unexpected destinations are blocked and logged.
What a defender takes away
- 1Highly privileged tools deserve the tightest outbound rules.
- 2Random one-off subdomains of a single domain are a classic sign of DNS-based command and control.
- 3Signed does not mean safe; watch behaviour too.
Questions
0 of 3 solved
Answer each one from what you find on your lab machine.