Static Analysis Showcase

Malware Analysis
1

Assemblyline Blog Entry #3

Photo by Sergey Pesterev on Unsplash

⚠️⚠️⚠️ CAUTION ⚠️⚠️⚠️

This document describes malware analysis in Assemblyline. Malware analysis must be performed in an isolated environment.

In the previous blog entry of the Assemblyline series “A Little Bit of History”, my colleague Steve discussed how Assemblyline started and grew into the product it is today!

In this post, we will be illustrating the power of Assemblyline’s static analysis services when analyzing a malware sample! This article requires an understanding of how to interpret Assemblyline results, which can be gained by reading the documentation.

The Sample of Choice

1fc8c811303e4fd19b3921fced69757d21133d928a51b7fbdc9b696d2e5a6954

File details as per Assemblyline:

MD5
de597174596fe0920f1ac8b3af29c89a

SHA1
6dc22acff5333e416ab71ffa5ef37dda2e6ca220

SHA256
1fc8c811303e4fd19b3921fced69757d21133d928a51b7fbdc9b696d2e5a6954

SSDEEP
3072:4yi7CxuGD55YnfrnL1BapaY5+qBp5GzrSAoEr5pCVc9MUcOecy3c/Zb:43fGD55YnDLiBhtGKipCm9MplU

TLSH
T1A034F19BB7A15CDED5F2037AC6B293A35141FF23A357462F1498270D69202C8EA4D36F

Size
252232 (246 KB)

Type
document/office/onenote

Mimetype
application/octet-stream

Magic
custom: document/office/onenote

Entropy
6.33412944670478

This OneNote sample was selected for this article because it demonstrates the power of Assemblyline regarding recursive analysis of extracted files, the advantage of having a variety of static services tailor-made for certain file types, and how we can pull out the IoCs without having to run the file in a sandbox.

How to submit

We are submitting this sample through the UI with the SHA256 hash. We are selecting the VirusTotal external source to be queried for this file since our Assemblyline instance has been configured to use an API key to pull files from VirusTotal by SHA256 hash.

Submitting a SHA256 hash to Assemblyline

We are only going to be submitting this sample to the “Extraction” and “Static Analysis” categories under “Service Selection” in the OPTIONS tab.

Once the submission has been completed, let’s look at it!

Head to the /submission/detail/<sid> endpoint for the submission because we are going deep into the details!

Submission Details

We’re going to skip past the “Submission Information” section of this view since that is not very interesting for this article.

Heuristics

Heuristics are specific features/behaviours that a service is looking for in a file that can generate scores and alert the analyst of potentially malicious intent.

For this submission, the following heuristics are displayed.

Heuristics Section for the Submission

Some heuristics are more interesting than others, and this is indicated by the colour of the heuristic card. For instance, the yellow heuristic card for “Suspicious File Ancestry” is interesting and the neutral-coloured “OleID Indicator Found” is not very interesting.

We can click on the “Suspicious File Ancestry” heuristic card to expand it and reveal the details behind this heuristic being raised.

“Suspicious File Ancestry” heuristic details

Interesting. It looks like this heuristic was raised for two suspicious ancestry paths found in this submission (orange indicates suspicious-ness):

  • document/office/onenote ➡️ code/vbe ➡️ code/jscript and
  • document/office/onenote ➡️ code/vbe ➡️ code/jscript ➡️ code/batch

We can click on the “Heuristic details” icon in the top right of the expanded card to reveal the exact heuristic name and signature if applicable.

Displaying signature for “Suspicious File Ancestry” heuristic

Looks like the Ancestry service has a signature called “code_from_jscript_from_office_document”.

Continue to scroll through this view to the “Indicators of Compromise” section and the “Files” tree.

IoCs and File tree view

Looks like Assemblyline was able to pull out some IoCs! That’s great!

We can click on the files[.]delivrto[.]me domain to enable “tag highlighting”, which shows which files in the file tree have ResultSections where that domain is tagged:

Tag highlighting in the file tree

Looking at this file tree, we can see that the initial file was identified as document/office/onenote and was named after the SHA256 hash we used to submit it.

The second level in the file tree is a code/vbe that is named a variety of names, separated by the | character. This means that multiple services were able to extract the same file based on file contents but named the extracted file something different. This isn’t an issue per se, although it does clutter the user interface a bit.

The third level is a code/jscript file and is our first suspicious file in the file tree. If we scroll back up to the “Heuristics” section to the “Suspicious File Ancestry” card, we can click on the “Toggle Highlight” icon to show which files contain ResultSections where that heuristic was raised.

Heuristic highlighting in the file tree

That explains why those files in the file tree are all flagged suspicious with the orange “S” square preceding them in the tree.

It should be mentioned that this file tree is a condensed file tree that only shows files that scored. To see all extracted files from a certain file in the file tree, select the arrow next to the top-level file:

Condensed file tree

There are a few image files that were pulled out of the OneNote file but did not score, so they were not included in the condensed output of the file tree.

Expanded file tree

After this code/jscript file, there are a bunch of code/batch files, so let’s move on from this view and dive into the service results for each interesting file in the file tree, starting with the OneNote file. Click on the top-level file.

OneNote

A side drawer will appear with the file details for this file. Let’s scroll down to the “Service Results” section:

Service results for OneNote file

We have a OneNote service that should have done the job on this file, so let’s check out its output:

OneNote service output

Oh my, that’s a bunch of information that I don’t know how to interpret. Let’s minimize this particular ResultSection by clicking on the title.

OneNote service’s Embedded Files ResultSection and Extracted files

Ah, much better. Interpreting this output, it appears that the OneNote service was able to extract four embedded files: two .jpg, one .png, and one .jse. The files were extracted for further analysis and re-submitted to Assemblyline, so that is why they all appear in the file tree on the “Submission Detail” page.

Close this side drawer and select the code/vbe file in the file tree.

Encoded Visual Basic

Let’s view the file contents in the File Viewer (scroll to the top of the “File Details” page and select the magnifying glass icon):

Viewing the encoded Visual Basic file contents with the File Viewer

I don’t know about you but I cannot make sense of encoded Visual Basic. Fingers-crossed an Assemblyline service was able to do something with this .

Head back to the “Service Results” section and select the Extract service results drawer.

The Extract service extracted a decoded VBE file called vbe_decoded, which is great! I’m excited to see what that file contains.

Extract service’s output for Encoded Visual Basic file

Click back to the “Submission Details” page and select the vbe_decoded file in the file tree, identified as code/jscript.

JScript

Let’s use the File Viewer again to see what the decoded VBE file contains:

Viewing the JScript contents with the File Viewer

Fantastic! We can actually make sense of this!

By the looks of this JScript:

  • The variable ajFCNY contains a large encoded blob
  • The scripting.filesystemobject object is being used so expect some manipulation of the host’s file system
  • The wscript.shell object is being invoked so expect some commands to be run on the host
  • A text file is created called default.bat
  • The variable containing the large encoded blob is being sent to a method that most likely performs some deobfuscation. After deobfuscating, this value is then added as a line in the text file.
  • The wscript.shell object is running a command default.bat nDLL

Interesting stuff. I wonder what contents the default.bat will contain…

If you are not well-versed in reading malicious JScript, that’s totally okay because Assemblyline has your back with a service specializing in JavaScript called JsJaws.

JsJaws is a Swiss army knife for JavaScript and HTML files. It uses two emulators in Box.js and MalwareJail, as well as SAST scanning in JS-X-Ray, plus has a signature set that looks for suspicious activity. The signatures are run on the static contents of the file as well as the output from the emulators.

Head back to the “File Details” page for this code/jscript file, select the JsJaws service results:

JsJaws service output for the JScript file

What is interesting here is that JsJaws, when analyzing the JScript file, saw PowerShell commands being run and flagged this in the signatures “RunsPowerShell” and “PowerShellDownloader”. After looking at the code in the JScript file in the File Viewer, this must be what was in the encoded blob.

Under the “Extracted Files” section there are some files of interest:

Extracted files from the JsJaws service

We see extracted_wscript.bat which contains the following:

“extracted_wscript.bat” file contents in the File Viewer

Yes, this makes sense, that was the command run by wscript.shell. We also seedefault.bat! Let’s check it out.

Batch

“default.bat” file contents in the File Viewer

Oh interesting, looks like JsJaws was able to emulate that encoded blob and write its contents to default.bat for our viewing pleasure.

At a high level, this batch file does the following:

  • Turns echo capabilities off, then tests it with a classic “hello, world!”
  • Uses PowerShell’s Invoke-WebRequest commandlet (iwr) to download a .gif file to a .tmp file in the %temp% directory
  • This next line, line 5, requires something to know about when calling batch files. You can call a batch file to run and pass it arguments in the command line, like default.bat nDLL for example, and this argument nDLL will propagate wherever %1 is in the batch file. So when default.bat nDLL is called with these contents, line 5 becomes RunDLL32 %temp%\aTgzWLspf.tmp,Wind. This is a classic obfuscation technique for batch files that use RunDll32. Also since RunDll32 is being used to execute that .gif that was downloaded to a .tmp file with the Wind export, I’m beginning to wonder if this is a .gif file to begin with?!
  • And finally with line 6, some cleanup, because organization is 

Select the default.bat file from the file tree in the “Submission Details” view, let’s see how Assemblyline did. Scroll to the “Service Results” section to view the Batchdeobfuscator service results:

Batchdeobfuscator service output for the batch file

Nice! We can see that the batch script tried to download an external file, but due to the obfuscation of the argument passing nDLL when run from the parent file, we miss out on any detection in Batchdeobfuscator that looked for RunDll32 . There’s always room for improvement!

Enhancements

The static analysis services like OneNote, Extract, JsJaws, and Batchdeobfuscator are great, but other than the Ancestry service, there were no heuristics in other services that scored particularly high enough to flag any of the files in the file tree as suspicious.

This is where services with external sources come into play:

  • The Yara service can play a key role in flagging files as malicious assuming you use solid signature sets that are updated frequently.
  • If you have an API key for VirusTotal, you can use the VirusTotal service to perform hash lookups to determine if any antivirus engines have flagged the file.
  • Speaking of antivirus engines, there is the AntiVirus service which is useful if you want to scan files with antivirus engines that you manage.

Conclusion

This is as deep as we are going to dive into this sample for this article and we illustrated what analyzing a malicious sample in the Assemblyline UI looks like for users!

All images unless otherwise noted are by the author.

Article Link: Static Analysis Showcase. Assemblyline Blog Entry #3 | by Kevin Hardy-Cooper, P.Eng | Medium