Information Security Blog

June 3, 2016

Detecting PowerShell Attacks with the On-Point Forensics Platform

The information technology website "ComputerWeekly.com" recently published an article stating that Windows PowerShell has been tied to more than a third of cyber-attacks. 2015 was certainly the year that penetration testers and attackers alike fully embraced the power that the scripting language provided. The use of PowerShell as an attack platform has been discovered in both commodity malware (ransomware, click-fraud, banking trojans) and targeted attacks. Because PowerShell is built into almost all modern Windows products and is considered a "trusted process", its abuse is difficult to detect by traditional automated processes.

The On-Point Forensic Platform service provides all the tools necessary for 10-D Security's analysts to rapidly respond to incidents on your network and quickly determine the extent of possible network intrusions.

In this fictional scenario we will be recounting the steps taken by an analyst located in a NOC several hundred miles away from the actual incident location. The incident starts with a call from the corporate helpdesk, they are working a ticket opened up by a user who stated that he was checking his personal email and he clicked on something he thinks was suspicious. The helpdesk has looked at the machine and ran a full antivirus scan only to come up empty. The helpdesk tech was about to close the ticket when he decided to escalate it to the Network Operations Center (NOC) to see if anyone there had any other ideas. The analyst picked up the ticket and groaned, "Great, another needle-in-the haystack call where there is literally no actionable intel to work with". The ticket summarizes the general timeline of events:

  1. The user (Scott Larson) was checking his personal email when he saw an email he was not expecting, but decided to open it anyway.
  2. The email contained tracking number (hyperlinked) of a parcel he did not order, but was curious.
  3. The user clicked the link and was presented with a popup he hadn't encountered before, but clicked through because he was committed to finding out what he was getting.
  4. To the user's dismay, nothing happened. No webpage, no message, just blank desktop.
  5. The user then calls helpdesk after realizing he did exactly what the network security staff had trained him not to do.
  6. The helpdesk technician ran through their somewhat limited checklist for such scenarios, checking the task manager for abnormal processes and running a full antivirus sweep. A quick check of the log server revealed no firewall or IDS alerts either.
  7. The helpdesk technician decides to escalate the ticket to the NOC for further review.

Now neither the helpdesk technician nor the NOC analyst have access to a visual recording of the actual events, only the recounting of events from the user. But since this is a fictional (although common in the real world) exercise, here is what the user experienced in events 1 through 4.

  1. The user (Scott Larson) was checking his personal email when he saw an email he was not expecting but decided to open it anyway.



  2. The email contained tracking number (hyperlinked) of a parcel he did not order, but was curious.



  3. The user clicked the link and was presented with a popup he hadn't encountered before, but clicked through because he was committed to finding out what he was getting.





  4. To the user's dismay, nothing happened. No webpage, no message, just a blank desktop.

Meanwhile on the attacker's console, a new remote access session appears from the user's workstation. In this scenario we are using the popular Metasploit Framework, this software is designed to aid penetration testers and red teams in mimicking real-world attacks. At this point the attacker has remote access capabilities to the compromised workstation and has successfully bypassed the organization's antivirus and intrusion detection system.





Back in the NOC, the analyst has fired up his web browser and logged into the forensic server, ready to get to work. The analyst issues a query to verify that the endpoint agent is communicating with the server and it appears to be doing so, checking into the server every ten minutes. The analyst issues a collection job to the workstation, asking for items typically required to perform this type of investigation. In this instance the analyst directs the endpoint agent to collect from the workstation the following list of items:

  1. Current list of processes and their startup parameters.
  2. Current list of network connections.
  3. Contents of the most common Windows startup locations.
  4. Full capture of the running memory on the workstation.

Within minutes the results start to appear on the server, the process list comes back first revealing forty-nine active processes. Examining the process list several processes jump out as unusual, processes 1088 and 2724. Both these processes are identified as PowerShell instances, and while the use of PowerShell on workstations is not unusual, the manner in which they were launched is highly suspicious. Both instances are related, process 1088 was spawned from process 2724 and both were launching obfuscated code through the "-enc" parameter. This technique is a known and popular technique for executing shellcode on a system without having files written to disk, and this is a simple and effective way to bypass antivirus software. In these two instances, the shellcode for a basic Metasploit payload has been encoded as a base-64 string and then launched as a process through a PowerShell process.









By this time the network connection information has arrived, looking at the two processes that the analyst has already identified, the analyst notes that one of the processes has an open connection to an external IP address on TCP port 443, this another major red flag that these processes are likely malicious. A basic IP lookup reveals that it is an IP address belonging to a U.S. based ISP and has not been flagged as malicious by any reputational services.





At this point the next logical step would be to pull these processes from the memory image and analyze them, but since the memory image is still being transferred across the network and we actually have the full PowerShell script already, the analyst simply copies the script to the malware sandbox and executes the code. As expected, the script launches and immediately tries to connect to the same external IP address, but the analyst also notes that a registry entry has been created at "/HKEY_USERS/S-1-5-21-3686121837-3244647070-3786357183-1000/Software/Microsoft/Windows NT/CurrentVersion/Windows/Load" and a Visual Basic script (flash_updater.vbs) has been dropped on to disk in the "C:\Users\Public" folder. The analyst immediately recognizes this as a common persistence mechanism, allowing the malware to be executed every time the user logs into the workstation. The analyst checks the output from the "common startup locations" task and sure enough the same registry key and file are present on the compromised workstation.









At this point the analyst has several unique "indicators of compromise" that he can use to determine if other hosts on the network are compromised in a similar way. The analyst pulls the last three months' worth of firewall logs to determine if any other hosts have communicated with the malicious external IP address and none were found. Next on the list is to see if any other hosts in the network (roughly 900 Workstations and servers) are running similar looking PowerShell processes. This is where the power of an endpoint based forensic process shines, the analyst can issue a job to all hosts to report back their process listing and search through the results at once. After issuing the job (which is commonly called a "hunt") the analyst grabs another cup of coffee and waits for the results to stream in.

Roughly twenty minutes later the analyst gets an email from the forensic server letting him know the results of his hunt are in, pulling up the results he sees that apart from a few laptops that are typically out of the office all endpoints have checked in successfully with cumulative total of 73,040 processes. The analyst, unfazed by the amount of data returned, issues a simple filter of "-enc" knowing that this will drastically cut down on the results. The analyst sits and stares at his console, a single process in a sea of processes matches his query and that workstation just happens to belong to Bob Jones the VP of Accounting.





The analyst takes a large gulp from his coffee and lets out a deep sigh, "This is going to be a long day."

Authored By: Scott Burkhart GCIA, GCFA





PDF Icon ImageBlog PDF Download