This script attempts to automate some of the checks from the SANS Know Good / Find Evil poster ( http://digital-forensics.sans.org/media/poster_2014_find_evil.pdf ). It requires and may be made obsolesced by Dave Hull's Kansa project ( https://github.com/davehull/Kansa ). The functions available are descibed below. A video illustrates possible use cases ( http://youtu.be/69mI6CU2zPk ).
This function is available to simply obtain a list of processes associated with common browsers that are running on the PC. It takes as argument a list of running processes and returns the ones that match common browsers.
This function takes a ‘netstat’ output as argument and returns data about browsers that are talking or listening on non-web ports. In this case, non-web ports is taken to be anything other than 21 (FTP, occasionally initiated from a browser), 80 (HTTP), 443 (HTTPS), 8080 (occasionally used for HTTP), 8443 (occasionally used for HTTPS). This is relevant because typically the browser is the initial point of infection. Often malware will hook the browser process via an unpatched vulnerability in Java or Flash or the browser itself. In the course of testing this function, I noticed that false positives will be frequently generated by both the auto-update feature and various browser extensions and plugins in modern browsers. Note that the netstat listing is provided in object form thanks to the Kansa project.
This function can be seen as the functional opposite of the previous CheckBrowsers. It takes a netstat output as argument and checks processes other than browsers for communication on standard web ports (21, 80, 443, 8080, 8443). As these ports are often allowed out through a firewall, malware will often attempt to use these to either communicate with its command and control (C2) server or to exfiltrate data.
Here the script checks for processes that are communicating on port 22. TCP 22 is often allowed out through firewalls and is used by malware for both C2 traffic and exfiltration. Processes that are not obviously SSH clients may be malicious and deserve further scrutiny. Also, SSH clients on typical end user’s systems are unlikely and may be suspicious as well. The function takes a netstat listing as argument.
This function takes netstat as an argument and checks for processes communicating on TCP 53 AND UDP 53. These are used for DNS traffic, and would be limited to specific processes on a Windows system. In a corporate environment, DNS traffic going to anything other than the corporate DNS servers is likely malicious in nature.
Malware will frequently attempt to masquerade as other known processes. This function takes a process listing as argument and returns the paths associated with the browsers running. Discrepancies here can quickly be investigated.
Here is a function where I’d envisioned more usability. In attempt to masquerade, malware will attempt to use misspellings of common windows processes or alternate character sets for process names. This function removes takes a processlist and filters out the list of common Windows processes known to be spelled correctly. In practice, this still returns a large amount of data and isn’t as useful.
This function takes a process list and matches the paths of common windows service processes against known good paths. Since malware often masquerades as these services, showing processes named System, smss.exe, wininit.exe, taskhost.exe, lsass.exe, winlogon.exe, iexplore.exe, csrss.exe, services.exe, svchost.exe, lsm.exe, or explorer.exe that are launched from non-standard locations is incredibly fruitful.
Another useful check is to determine the parent process for common Windows processes. This function takes a process list and checks the parent process of common windows processes against known good list. It also checks for any processes spawned by cmd.exe and powershell.exe as these are unlikely on average end user systems.
This function takes a list of processes and validates the user that spawned common windows processes to be correct. For example, svchost.exe running as the logged on user is highly unusual and indicative of malicious activity.
Several common Windows processes start at boot time or shortly thereafter. Processes named the same that start later can be indicative of masquerading malware. Taking a process list, this function validates the start time of certain common processes in relation to boot time.
This function checks all processes for communication on 20 (FTP Control),21 (FTP), 22 (SSH), 23 (Telnet), 25 (SMTP), 3389 (RDP),4444 (default for Meterpreter). Processes using these ports may indicate data exfiltration. This list is by no means complete, but attempts to quickly zoom in on potential suspicious activity.
The decision was made to allow the script to use potentially stale data and only to refresh when specifically requested. This is useful in an incident response situation as an analyst may need to look at a specific snapshot in time versus constantly updating process and network data. This function refreshes the data being analyzed.