Intro Lab 3: Getting Personal

Starting by looking at the VT Hunting Dashboard we see there’s a VT Malicious Hashes table with an entry that has 38 hits. The culprit is C:\Users\lab-admin\AppData\Local\Microsoft\Credentials\MediaPlayer\ddpp.exe, which has a SHA256 value of 25C119A7EE5B53212B5992992907A7772610B491CE2992C860DC206D0F3F844D.

Similar to previous labs, we’ll start from the VT Hunting Dashboard, create a filter on C:\Users\lab-admin\AppData\Local\Microsoft\Credentials\MediaPlayer\ddpp.exe in the VT Malicious Hashes table, pin it, and navigate to Discover.

In Discover we should have three hits, all associated to the same process ID (PID) 2812, which had the following activity captured:

• 2020-09-19T16:22:58.022Z - Process create (event ID 1)
• 2020-09-19T16:22:38.925Z - DNS query (event ID 22)
• 2020-09-19T16:21:55.059Z - Process terminated (event ID 5).

If we expand the DNS query, we can see a request was made to telefx[dot]net, and there were 6 VirusTotal hits flagging it as malicious.

If we expand the process create (event ID 1) for PID 2812, we can see that the parent process was: C:\windows\system32\svchost.exe -k netsvcs -p -s Schedule. The schedule flag provides us a hint that this execution was…scheduled.

Unfortunately, there’s a number of ways scheduling can occur on a Windows machine (the MITRE - ATT&CK - Scheduled Task/Job page is a good place to start looking into some of the methods available). However, it never hurts to start by having a closer look at the processes that are directly related to your malicious activity, or occurred around the same time. In this case, we’re going to use the following query to see what else that svchost.exe did (make sure to remove or temporarily disable your pinned filter!): winlog.event_data.ProcessId:1312 OR winlog.event_data.ParentProcessId:1312

As we go over the results, we should a file create (event ID 11) for C:\Windows\System32\Tasks\Dolby Selector Task that occured at 2020-09-19T16:20:55.813Z, which is roughly one minute prior to our process create for ddpp.exe.

A word of warning here, be very mindful of confirmation bias. Although the Dolby Selector Task is odd and within close range of our malicious process being created, it could very well be coincidental. You should absolutely take note of it, but during an investigation it’s easy to fall into the trap of thinking that anything strange is related to your malicious activity.

Taking our filename that we identified in the first question, we’re going to do the following query: winlog.event_data.TargetFilename:"C:\\Users\\lab-admin\\AppData\\Local\\Microsoft\\Credentials\\MediaPlayer\\ddpp.exe"

This results in one hit on PID 8304. Let’s create a filter for that, and remove our TargetFilename query to get all of the process activity that was captured.

Going over the results, we find the process create event and see the command line was: C:\Windows\System32\cscript.exe" "C:\Users\lab-admin\AppData\Local\Microsoft\Credentials\MediaPlayer\VideoManager\media.js. We also see the following file creation and deletion events were captured:

• 2020-09-19T16:20:24.676Z
  • File Deletion (event ID 23)
  • Target Filename: C:\Users\lab-admin\AppData\Local\Microsoft\Credentials\MediaPlayer\VideoManager\media.js
• 2020-09-19T16:20:55.645
  • File Create (event id 11)
  • Target Filename: C:\Users\lab-admin\AppData\Local\Microsoft\Credentials\MediaPlayer\main.exe
• 2020-09-19T16:20:55.740Z
  • File Deletion (event ID 23)
  • Target Filename: C:\Users\lab-admin\AppData\Local\Microsoft\Credentials\MediaPlayer\main.exe
• 2020-09-19T16:20:55.833Z
  • File Deletion (event ID 23)
  • Target Filename: C:\Users\lab-admin\AppData\Local\Temp\1.lnk

For this question, we can start working our way backwards from PID 8304. First, let’s remove or disable all of our filters, and do a query for winlog.event_data.ProcessId: 8304. We can see from the process create event that its parent PID was 9572. Let’s add that to our query to make it winlog.event_data.ProcessId: 8304 OR winlog.event_data.ProcessId: 9572.

For PID 9572, we see it had a parent PID of 7640, so we’ll add that to our query as well winlog.event_data.ProcessId: 8304 OR winlog.event_data.ProcessId: 9572 OR winlog.event_data.ProcessId: 7640.

You can keep repeating this process to make your up the process tree. If you go to the VERY beginning you should have the following:

• 2020-09-19T16:19:54.306Z
  • PID: 8304
  • Command Line: “C:\Windows\System32\cscript.exe” “C:\Users\lab-admin\AppData\Local\Microsoft\Credentials\MediaPlayer\VideoManager\media.js”
• 2020-09-19T16:19:51.782Z
  • PID: 9572
  • Command Line: wscript “C:\Users\lab-admin\AppData\Local\Temp\0.js”
• 2020-09-19T16:19:51.543Z
  • PID: 7640
  • Command Line: “C:\Windows\System32\cmd.exe” /c path=C:\windows\system32&move “PersonalKYC.pdf.lnk” “C:\Users\lab-admin\AppData\Local\Temp\1.lnk”&type “C:\Users\lab-admin\AppData\Local\Temp\1.lnk”|find “END2”>“C:\Users\lab-admin\AppData\Local\Temp\0.js”&wscript “C:\Users\lab-admin\AppData\Local\Temp\0.js”
• 2020-09-19T16:18:56.294Z
  • PID: 5584
  • Command Line: C:\windows\Explorer.EXE
• 2020-09-19T16:18:56.034Z
  • PID: 5552
  • Command Line: C:\windows\system32\userinit.exe
• 2020-09-19T16:18:52.286Z
  • PID: 1028
  • Command Line: winlogon.exe
• 2020-09-19T16:18:52.226Z
  • PID: 3416
  • Command Line: \SystemRoot\System32\smss.exe 000000d0 00000084

Based on the logs, the process that started the malicious activity was PID 7640 at 2020-09-19T16:19:51.543Z on 30218972-wsw10.windomain.local by 30218972-wsw10\lab-admin. Although the process tree continues past 7640, the rest is just benign Windows activity. It is possible more sophisticated malware could hook into those processes (for instance maybe a rootkit or using DLL hijacking), or the logs were manipulated. However, before I would start going down those rabbit holes, I would try to determine where PersonalKYC.pdf.lnk came from and begin attempting to get copies of the various files that we’ve identified throughout the analysis.

Process trees are incredibly useful and something you will find yourself looking at frequently to determine if something was malicious or not. Unfortunately, as we saw above, enumerating them through Kibana can get tedious. Instead, it’s worth looking at doing that sort of analysis outside of Kibana, potentially by creating a script that interacts with Elasticsearch directly.

Spending some time getting comfortable with scripting and interacting directly with things like APIs will pay huge dividends in terms of your analysis capability. Often if you find yourself doing lots of copy and pasting, or repeating the same steps over and over, it’s worth thinking about if there might be a way you could automate some of that workflow instead.

With some web searching for the malicious hash and domain that were identified you should be able to find your way to a Cybereason report called No Rest for the Wicked: Evilnum Unleashes PyVil RAT. If the title didn’t give it away, the group suspected is Evilnum.