I got a call the other day that lead to a fast incident response relating to a C2 domain communication. I thought I would share the steps I took to investigate the event. Ultimately I learned that Google Chrome and its pre-fetch technology can be a bit of a trouble maker.
Our network incident response system posted an alarm that someone had triggered the domain reputation algorithm which compares domains requested from the DNS to a list of known bad domains. After drilling in on the alarm, I learned that the DNS Name requested was as shown below:
Notice the threat category in the above screen capture (C&C). I’ll come back to this in a moment. In the meantime, I went to VirusTotal who had the domain listed as malicious around the same time as the alarm.
Domain Reputation Lookup
Using FlowPro Defender with Full DNS IPFIX export I found the lookup. I suspected that the domain listed above might be involved with an alternated domain. I applied a CNAME traverse tool to the domain and learned that this user originally looked up www[.]arzika.com. When the user’s workstation looked up arzika, a CNAME record was returned for our known malicious domain. See below:
Why do we see two results listed above? FlowPro is properly configured with a SPAN of the DNS server traffic, which results in 1 lookup from the host to the DNS and a second lookup from the DNS server outbound to DNS root.
If you would like a full DNS export on the above events from FlowPro Defender, issue the following commands:
- to turn on,” touch /home/flowpro/sendall.txt”
- to turn off, “rm -f /home/flowpro/sendall.txt”
We looked it up, was there bidirectional traffic?
A quick search in Scrutinizer indicates that there was no one had actually made connection to 8.5.1.16. As a result, I have to ask: Why was the alarm was triggered?
Why did the PC request this name?
DNS resolution time can lead to a significant amount of user perceived latency when rendering a website. Google Chrome has a feature known as prefetch. It was designed to alleviate speed perception issues and Chrome added the feature to automatically make DNS requests for links on an HTTP site. This is done in anticipation that the user might click on a link imbedded in the page. With Chrome loading itself up with the IP addresses behind the domains in the links embedded on a page, the user often experiences a faster web page load time.
“By default, Chromium does not prefetch host names in hyperlinks that appear in HTTPS pages. This restriction helps prevent an eavesdropper from inferring the host names of hyperlinks that appear in HTTPS pages based on DNS prefetch traffic. The one exception is that Chromium may periodically re-resolve the domain of the HTTPS page itself.”
After pulling the packets via our Scrutinizer/Endace integration. I learned the user workstation that triggered this alarm was researching an organization on www.discoverydb.com which is one of our cloud services. The JSON object imbedded in the two pages (Company.php and orgchart.php) he visited contained a URL for a presentation. Below is the code that I pulled out that shows a hyperlink to arzika for a potentially fake presentation.
<a href=\”http:\/\/www.arzika.com\/Demery.pdf\” target=\”_blank\”>Presentation: Using Technology for Collaboration within the Enterprise<\/a>
Summary of Steps:
- The user visited the discoverydb.com web site which served up a page that had a link to arzika dot com.
- Google Chrome prefetched the arzika domain
- The DNS reached out to the authoritative DNS and received the CNAME of melbourneit[dot]hotkeysparking[dot]com
- FlowPro Defender captured this and sent it to Scrutinizer
- Scrutinizer performed Security Analytics on the event by checking the reputation of the domain.
- A positive match was made on melbourneit[dot]hotkeysparking[dot]com and an alarm was triggered.
What can be learned from this?
Ultimately, Google Chrome inadvertently triggered the alarm by performing a DNS lookup of a domain imbedded in a link on the web site. Although the user never clicked on the link, he could have! As a result, we contacted the user and others and instructed them to disable Prefetch.
DiscoverOrg was also contacted but has yet to correct the problem. Ultimately the false positive led to a great learning experience and we are improving our flow analytics. It also gave us a warning that we needed to beef up our defensive measures by disabling prefetch on all devices installed with Google Chrome.