Identifying Malicious Code

We are supporting incident response by assessing indicators to determine whether a case should be escalated to senior analysts. We have two script samples that server managers have flagged as suspicious. We'll identify the type of code used in both cases and decide whether they should be escalated to the senior response team.

We have duplicates of the DC1 and MS1 servers installed to an isolated network segment to use for sandbox analysis. The code samples have been supplied to us on an optical disc. The first sample is named "iam_accounts_staged.ps1". This sample was found on a secure admin workstation (SAW). The script was intended to provision temporary user accounts and a shared folder on domain computers.

Using our MS1 VM, we load the RSH iso and open the DVD Drive through File Explorer to view the files. We'll then select both files and scan them with Windows Defender.

While the quick scan is being performed, we click on the Update tab and see that the definitions were last created on 5/19/2016. This indicates that our scan results will be unreliable as the anti-virus definitions are out-of-date.

Anti-virus signatures this far out of date will be of very limited value. While signature-based detection is fallible, it is still capable of detecting a wide range of threats if correctly configured and maintained. It would be unwise to assume that the scan results are accurate. We should not assume a result on the basis of a single test.

We'll close Windows Defender and run Powershell ISE as an administrator. Next, we'll open the iam_accounts_staged.ps1 in the DVD Drive.We can see a small piece of the code below and we see that malware seems to have been appended to a legitimate script.

The first part of the code performs the actions as described by its comments (denoted by the # symbol). Given the circumstances of the project, it is fair to assume that this section is legitimate. The final part of the code contains no comments, cryptic function names, and a binary byte sequence. In combination, these features have no place in code developed for a legitimate purpose. Its exact function requires further investigation to determine, but we can confidently identify it as suspicious.

Since we are confident in the integrity of our sandbox environment, we decide to execute the code to determine its function and gather some additional information to send to the senior analyst team.

While running procexp64.exe we can monitor the host.

After running the netstat -ano command in Powershell ISE, we see which socket the malicious process is attempting to establish a connection with. We know it's suspicious because the foreign address is attempting to use a non-standard port 4444. The malware is trying to establish a reverse shell. This means that the malware tries to establish a connection. There is no listener at or route to 192.168.2.192, so the port remains in the SYN_SENT state until the process times out and terminates.

We'll run the following command to export the netstat output to a file

After locating the 1032 PID in Process Explorer, we can see the image name of the process that is hosting the malware is powershell_ise.exe

Note user name and integrity level. The malware has high permissions because the host PowerShell ISE process was launched as  an administrator. This shows the risk of running accounts and processes with high privilege levels when it's unnecessary.

We'll save this file as procexp.txt onto the desktop for now.

The second sample was retrieved from a web server's common gateway interface (CGI) folder and marked as executable.

We'll open this sample in Powershell ISE. First, we need to navigate back to the DVD Drive and we see the other file labeled get.py. When opened in Powershell ISE, we see that it is a single long line of code written in python.

This script is obfuscated by Base64 encoding. We'll use Powershell to decode this back to a recognizable script syntax by editing the code to appear as such:

[Text.Encoding]::Utf8.GetString([Convert]::FromBase64String('aW1wb3J0IHNvY2tldCAgLC

...output omitted...

W4vYmFzaCIp')) > $env:USERPROFILE\desktop\get_decoded.py

Next, we'll save this file on the desktop and then execute the modified script. Then we'll perform the following steps to make the code more readable: 

• Select the sequence of spaces between the comma and the word "subprocess". 
• Press CTRL+H to open the Find and Replace dialog. 
• Select in the Replace with box and type \r\n. 
• From the Search Mode box, select Extended. 
• Select Replace All. 
• Close the dialog.
  
  Below is the result. We can see that the function of the script is to establish a bash reverse shell, trying to contact the host at ip address 192.168.2.192 over port 4444.

There is correlating information that might indicate a single culprit behind both scripsts. We can see that both scripts use the same ip address and port number.  While this example is only a private IP address, in the real world the use of the same address (or range of addresses) could be useful data in determining whether attacks are linked to the same threat actor. Access to privileged hosts might suggest an insider attack that would in all likelihood have been launched by the same person, but is not quite as strong a correlating indicator. Most threat actors are skilled in multiple scripting languages, so this is not an appropriate conclusion.

Considering the legitimate purpose of the iam_accounts_staged.ps1 script the serious security vulnerability that is exposed by the code is user credentials. Line 1 contains the default user credential as a variable. While the script sets the account properties to force a password change, this is often not done in a timely manner. A threat actor could also try this default credential against other accounts in the hope that it is widely used. The script does not accept any input, so cannot contain a validation vulnerability. Many scripts perform actions that require elevated privileges. Care must be taken in executing such scripts, but it is not a vulnerability of the script itself.

The location in which the code was discovered indicates that a threat actor probably has ongoing privileged access to high value assets. Identifying, containing, and eradicating this threat is the top priority. A breach notification may be required, but additional information will have to be gathered first to confirm what data has been compromised. While important, this is not as high priority as preventing additional damage or loss. Regular anti-virus updates should be performed and the reasons for missing updates needs to be investigated, but again this is not at quite the same level of priority. Dismissing the incident would be negligent.