Static Analysis Showcase
Assemblyline Blog Entry #3
⚠️⚠️⚠️ 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.
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.
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.
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
anddocument/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.
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.
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:
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.
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:
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.
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:
We have a OneNote service that should have done the job on this file, so let’s check out its output:
The above information is data extracted from the header of the OneNote document, but in this case we are looking for something else from the OneNote service. Let’s minimize this particular ResultSection
by clicking on the title.
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):
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.
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:
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 commanddefault.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:
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:
We see extracted_wscript.bat
which contains the following:
Yes, this makes sense, that was the command run by wscript.shell
. We also seedefault.bat
! Let’s check it out.
Batch
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 argumentnDLL
will propagate wherever%1
is in the batch file. So whendefault.bat nDLL
is called with these contents, line 5 becomesRunDLL32 %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 theWind
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:
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!
The next blog entry by my colleague gdesmar is the first part of a write-up leveraging Assemblyline to solve forensic challenges that were part of the HackTheBox Business CTF 2023 competition.
Sample Hashes
document/office/onenote
1fc8c811303e4fd19b3921fced69757d21133d928a51b7fbdc9b696d2e5a6954
code/vbe
9d0270c93c27c24c5bc8e0ffb26f84a0fb8c55318738eb3d085441d727be6ec2
code/jscript
3b72f2d001a4190efb0a1d448e3c1573995d4d4bd15033d506c9474f86345e10
code/batch (default.bat)
af3f4e2e9e007ff1fad6edaebe67a58e495c7cf81abad5e18adc2f2267577f9f
code/batch (extracted_wscript.bat)
beca5f817a8befe6020633f113d54d16856ecaf594e95a2f527461f339e6e63d
All images unless otherwise noted are by the author.