Oftentimes, we overlook the value that crowd-sourced threat intelligence brings to a security team’s arsenal. For example, AlienVault’s Open Threat Exchange (OTX) is a fantastic tool to help you determine if some observed behaviour is malicious or not. In this article, we explore how malware can be detected on an old Windows XP client (believe it or not… they still exist on legacy networks) and how OTX data clinches the case in determining if the anomalous behaviour is malicious or not.
Scenario: DNS logs show some anomalous and apparently random requests being made by a particular client - requests which never resolve to an IP. An analyst is tasked with determining if the client is infected and is risky enough to be shut down and wiped. (P.S. This was a real scenario)
Below we follow the steps that the analyst took to determine this:
1. Windows by default comes with a “DNSClient” service. This service basically caches the DNS requests where possible; otherwise it will make DNS requests on behalf of other programs. This interferes with the investigation since all DNS requests will appear to come from this service (typically “svchost.exe”) rather than the actual program. So we first disable the "DNSClient" windows service so that all DNS lookups will be performed directly by the requesting program allowing us to trace them.
2. Next, we download “Process monitor” (procmon.exe) from Windows Sysinternals and monitor all DNS connections. This is done by adding a new filter with the following parameters:
Adding the filter above will restrict the program to displaying only DNS requests. In this case, "Winlogon.exe" popped up as soon as the random DNS request was made.
Tip: Install Wireshark on the PC under investigation and filter for DNS to know exactly when a request was made.
3. We opened “Process explorer” in Sysinternals and checked out the TCP/IP connections that the “Winlogon.exe” program is making.
We immediately notice something odd about the top connection...why would the login process be making a remote connection to an HTTPS server that isn’t in our domain?
4. To investigate further, we next run netstat -nao to find other anomalous established connections:
We can now match the connections being made to the program with their PID (those are the red lines drawn on the figure above) enabling us to identify that "winlogin.exe" and “regsvr32.exe” are anomalous.
At this stage, the question as to whether the process is malicious has still not been completely determined. The process is definitely acting in a strange manner; however, there is still a possibility that these IPs are legitimate. This is a common problem encountered when an investigator is not familiar with the environment.
At this point in our investigation, OTX comes in for the win. Using OTX data, we can check the IPs that the programs above are communicating with. OTX performs several checks, and the results indicate that the IP addresses we discovered in the above investigation have, indeed, been associated with malware:
Figure 1: OTX Antivirus results
Further searches in OTX also provide basic information about the IP addresses, such as country, BGP AS number, as so on. Running the above IPs though these checks, we observe that a seemingly legitimate MS Windows box is actually communicating with an IP in Russia:
Figure 2: OTX Basic IP Checks
Conclusion
The investigation turned up several questionable IP addresses, which OTX was used to research and validate. These OTX searches generated the following red flags to indicate malicious behavior:
- The IP was reported as being associated with malware by various antivirus vendors (Figure 1)
- IP address was located in an unusual country (Russia), in an AS that is not owned by Microsoft as would otherwise be expected (Figure 2)
- Initially, the rogue process (winlogin.exe) was deleted from the system and copied over from a trusted source, but the abnormal behaviour continued. After re-installing the entire system, the issue was able to be fully resolved.
