Jack HammThe recent impact of the Department of Homeland Security (DHS) Binding Operational Directive (BOD) 17-01 requires Federal agencies to “take actions related to the use or presence of information security products, solutions and services supplied directly or indirectly by AO Kaspersky Lab or related entities.”[1]
For a security operations (SecOps) team, this requirement means three things:
- You need to detect Kaspersky products in your environment.
- You need a plan of action to remove and validate the removal of the Kaspersky products.
- You must be able to verify that Kaspersky has been removed.
The Gigamon GigaSECURE® Security Delivery Platform can help identify Kaspersky products on your network. Using the GigaSECURE NetFlow/IPFIX Engine, SecOps can identify traffic communicating with Kaspersky servers and generate metadata for logging into a Security Information and Event Management (SIEM) system. In this blog, we will demonstrate detection of Kaspersky traffic using Domain Name System (DNS) queries, Uniform Resource Locator (URL) requests and Secure Sockets Layer (SSL) certificate negotiation.
The GigaSECURE Security Delivery Platform in Action
As all traffic will first generate some DNS signatures, our first stop is to collect queries against well-known Kaspersky domains. On the NetFlow/IPFIX side, we create a NetFlow Record for DNS. Of particular interest will be the Query Name and the Response Name. In my environment, our collects always include the 5-tuple and as a result, I can quickly identify the requesting machine.
From here, I’ll be using my Splunk instance to search for hosts that are querying for *.kaspersky.com. In my environment, I’m going to create a search that considers a few parameters:
- Query name is *.kaspersky.com.
- The requester is in my LAN (192.*).
- The requester is not one of my DNS servers. Note: I do this because not only do I see the client request, but I also see the iterative request from my DNS servers – this is very powerful.
GigaSMART® DNS NetFlow/IPFIX Collects used:
- query_name
- src_ip
The query I’m using is:
| index=ipfix query_name=”*.kaspersky.com” AND src_ip=”192.*” AND (src_ip != “192.168.1.20” OR src_ip != “192.168.1.22”) | dedup src_ip | table src_ip |
We can also generate a list of query names to understand what Kaspersky hosts are being queried. This can help differentiate from visits to the website versus actual update fetches. The query I used is:
| index=ipfix query_name=”*.kaspersky.com” | stats count(query_name) by query_name |
Another strategy I can use is to watch for URLs that include Kaspersky in them. Since I have a decrypted flow of our SSL traffic using the SSL decrypt features of the GigaSECURE Security Delivery Platform, I can identify these requests even if they use SSL.
GigaSMART HTTP NetFlow/IPFIX Collects used:
- url
- src_ip
The query I’m using to generate this is:
| index=ipfix url=”*.kaspersky.com/*” AND src_ip=”192.*” | stats count(url) by src_ip |
This results in a count of hosts that are fetching URLs from *.kaspersky.com.
Additionally, we can use the URL to actually see what files are being GET requested form Kaspersky using:
| index=ipfix url=”*.kaspersky.com/*” | stats count(url) by url |
Finally, I can answer the question: On my network, what hosts have negotiated an encrypted request with Kaspersky?
GigaSMART SSL NetFlow/IPFIX Collects used:
- ssl_subject
- dest_ip
I’m using this query – note, the use of dest_ip since I’m interested in who was offered a Kaspersky cert:
| index=ipfix ssl_subject=*”kaspersky”* AND ssl_subject!=”” | dedup dest_ip | table dest_ip, ssl_subject |
Using these strategies, you can triangulate Kaspersky-related traffic as it transits your network regardless of how it’s flowing. This powerful strategy allowed me to quickly identify machines running Kaspersky on my network. Now, on to removing it!
Also, here’s a list of all the Kaspersky domains I turned up on my network:
| query_name: |
| dnl.17.geo.kaspersky.com |
| dnl.15.geo.kaspersky.com |
| dnl.00.geo.kaspersky.com |
| dnl.02.geo.kaspersky.com |
| dnl.18.geo.kaspersky.com |
| dnl.05.geo.kaspersky.com |
| dnl.16.geo.kaspersky.com |
| dnl.07.geo.kaspersky.com |
| dnl.08.geo.kaspersky.com |
| dnl.19.geo.kaspersky.com |
| dnl.11.geo.kaspersky.com |
| dnl.09.geo.kaspersky.com |
| dnl.01.geo.kaspersky.com |
| dnl.03.geo.kaspersky.com |
| dnl.12.geo.kaspersky.com |
| dnl.10.geo.kaspersky.com |
| dnl.04.geo.kaspersky.com |
| dnl.13.geo.kaspersky.com |
| ml.kaspersky.com |
| go.kaspersky.com |
| dnl.14.geo.kaspersky.com |
| dnl.06.geo.kaspersky.com |
| activation.v2.kaspersky.com |
| activation.v2.geo.kaspersky.com |
| ksn.url.geo.kaspersky.com |
| ksn.a.p2p.geo.kaspersky.com |
| ksn.kas.geo.kaspersky.com |
| ksn.file.geo.kaspersky.com |
| ksn.a.stat.geo.kaspersky.com |
| ksn.verdict.geo.kaspersky.com |
| ksn.info.geo.kaspersky.com |
| touch.kaspersky.com |
| autocomplete.kaspersky.com |
| tr2.kaspersky.com |
| www.usa.kaspersky.com |
| redirect.geo.kaspersky.com |
| ksn.crypto.a.stat.geo.kaspersky.com |
| ksn.crypto.info.geo.kaspersky.com |
| ksn.crypto.url.mobile.geo.kaspersky.com |
| ksn.crypto.ipm.geo.kaspersky.com |
| ksn.cinfo.geo.kaspersky.com |
| ksn.crypto.verdict.geo.kaspersky.com |
| ksn.crypto.a.p2p.geo.kaspersky.com |
To learn more, don’t miss our webinar “SOC Talk: Phantom Automation for Faster Response Time.” We will walk you through how to use the GigaSECURE Security Delivery Platform to determine if, for example, Kaspersky has been removed and show how the Phantom Platform can automate the identification and removal process.
[1] https://www.dhs.gov/news/2017/09/13/dhs-statement-issuance-binding-operational-directive-17-01
