This second blog in the series on OPSEC for Blue Teams is about testing tools used to get context and/or OSINT on domains and IPs. While performing these tests it also showed results that can be interesting for Red Teams.

• Part 1: OPSEC for Blue Teams - Losing Defender's Advantage

• Part 3: OPSEC for Blue Teams - Sandboxes & Secure Communications

Tool testing - PassiveTotal & VirusTotal

Remember we want to have a tool that does not sent any signals that can be picked up by an adversary. If we must send signals, it has to be something the adversary expect to see.

I often use PassiveTotal for getting context and some OSINT. I wondered how passive it actually was. I started by asking a question about this to PassiveTotal for which I received the following response:

In order to perform "true" passive request you would need to adjust some account settings, which is under "Sources" in your Account Settings:
1) Disable third-party pDNS sources (VirusTotal, Kaspersky) - both do an active lookup for a domain that does not appear in their repository
2) Disable the Pingly source as this is RiskIQ / PassiveTotal Active resolver

I followed up by performing some tests, for which I first created a test infrastructure:

• I registered a new domain.

• Created two VPS instances with both a unique public IP address:

  • Installed the Apache webserver and let it listen on port 80.

  • Configured them to be an authoritative nameserver for my new domain using Bind in a master/slave setup.

  • Enable logging for Bind and adding the HTTP host header to the logs of Apache.

• I pointed the NS records for my new domain to my own nameservers.

• The PTR records for both VPS instances I pointed to a unique subdomain that will also be resolved at my own nameservers (rev1.example.com and rev2.example.com).

• For testing IP addresses I created a new VPS. I did this because I needed to be sure to have reliable results and therefore having an IP which had no recent relation to any of the subdomain names from previous tests.

For every test performed I created a unique subdomain and pointing the A record to one of my VPS instances. Then I used this subdomain within PassiveTotal and monitored the Bind and Apache logs for any activities related to the subdomain.

I was very pleased to see no activity at all when I disabled VirusTotal, Kaspersky and Pingly. When enabling all of them I immediately saw activities within the logs of Bind (for multiple type of DNS records) and none for Apache. Further testing showed enabling VirusTotal did not result in any activities within my logs. I asked a follow-up question on this to PassiveTotal, in which they provided the following answer:

While they do not do an on demand active lookup - if they have a miss - i.e. they don't have data on the domain or IP in question, they will trigger a lookup to close their collection gap, so it could take 24hrs to propagate. This may have changed over the years though.

In my logs I had not seen any DNS queries for domains used in my tests, for which the source VirusTotal was enabled in PassiveTotal, after 24 hours or even longer. This tells me the behaviour of VirusTotal has changed. I decided to perform more testing on VirusTotal itself:

• Of course, doing a scan on a domain or IP shows activities within the logs of Bind (query for the DNS A and AAAA record). Within the Apache logs it was pretty easy to track this to VirusTotal by having "virustotalcloud" included in the User-Agent.

• Doing a search with the web GUI of VirusTotal showed activities within the logs of Bind (only a query for the DNS A record).

• When executing a domain report using the API, I saw no activities at all. The same holds for the IP address report. As expected, I saw no DNS queries for the subdomain by VirusTotal after 24 hours and longer.

Based on the test results I am pretty sure PassiveTotal uses the domain/IP report API calls for getting info on domains and IPs. I also noticed when first doing a scan on a domain using VirusTotal, new data is shown in PassiveTotal having VirusTotal as the source.

Monitoring by an adversary

It would be interesting to perform more research on monitoring signals as an adversary. For example: see which behaviours are seen regarding DNS resolution when domains are not shared with any security vendor. Like I did on purpose during my testing.

I observed a great amount of DNS queries for the PTR records by a very large group of different IPs and parties. Therefore it may be less useful for an adversary to monitor on these. Or could this be turned into useful monitoring by focusing on IPs from security vendors? For now I did not look into this.

Another thing I noticed, is a great amount of DNS queries for subdomains that do not exist. Again, by a large number of IPs and parties. It can therefore be of great help to an adversary to use a subdomain that does look legit but has a very low chance in being guessed. It would also be interesting to research if there are good ways to filter out the noise (such as domain name scanners that come along).