Using Google Threat Intelligence to create behavioral detections as a detection engineer

[Joseliyo_Jstnk]

Detection engineering is becoming increasingly important in surfacing new malicious activity. Threat actors might take advantage of previously unknown malware families - but a successful detection of certain methodologies or artifacts can help expose the entire infection chain. 

In previous blog posts, we announced the integration of Sigma rules for macOS and Linux into VirusTotal, as well as ways in which Sigma rules can be converted to YARA to take advantage of VirusTotal Livehunt capabilities. In this post, we will show different approaches to hunt for interesting samples and derive new Sigma detection opportunities based on their behavior.

Look for what is potentially interesting

As detection engineers, it is important to look for techniques that can be in use by multiple threat actors - as this makes tracking malicious activity more efficient. Prior to creating those detections, it is best to check existing research and rule collections, such as the Sigma rules repository. This can save time and effort, as well as provide insight into previously observed samples that can be further researched.

A different approach would be to instead look for malicious files that are not detected by existing Sigma rules, since they can uncover novel methodologies and provide new opportunities for detection creation.

One approach is to hunt for files that are flagged by at least five different AV vendors, were recently uploaded within the last month, have sandbox execution (in order to view their behavior), and which have not triggered any Crowdsourced Sigma rules.

p:5+ have:behavior fs:30d+ not have:sigma

This initial query can be adapted to incorporate additional filters that the researcher may find relevant. These could include modifiers to identify for example, the presence of the PowerShell process in the list of executed processes (behavior_created_processes:powershell.exe), filtering results to only include documents (type:document), or identifying communication with services like Pastebin (behavior_network:pastebin.com).

Another way to go is to look at files that have been flagged by at least five AV’s and were tested in either Zenbox or CAPE. These sandboxes often have great logs produced by Sysmon, which are really useful for figuring out how to spot these threats. Again, we'd want to focus on files uploaded in the last month that haven't triggered any Sigma rules. This gives us a good starting point for building new detection rules.

p:5+ (sandbox_name:"CAPE Sandbox" or sandbox_name:"Zenbox") fs:30d+ not have:sigma

Lastly, another idea is to look for files that have not triggered many high severity detections from the Sigma Crowdsourced rules, as these can be more evasive. Specifically, we will look for samples with zero critical, high or medium alerts - and no more than two low severity ones. 

p:5+ have:behavior fs:30d+ sigma_critical:0 sigma_high:0 sigma_medium:0 sigma_low:2-

With these queries, we can start investigating some samples that may be interesting to create detection rules.

Analyze the results

Now we have a bunch of samples that might be worth a deeper dive. Of course, some will be more interesting than others. The next step is to really dig into how each one behaves. We need to look at everything they do: what changes they make to the registry, what files they create or modify, what processes they launch, what network connections they make, what modules they load. 

By doing this during the creation of this blog post, we came across noteworthy examples that we will cover in the following sections.

Lummac

We identified a set of samples related to the Lummac (also known as Lumma Stealer, a malware designed to steal sensitive information from infected computers) family with behaviors that, from our perspective, are not usually observed in a benign context.

The high-level behavior involves the use of the legitimate Microsoft Windows More utility more.com (PID 1604) which is located in both C:\Windows\SysWOW64 and C:\Windows\System32 directories. Then, this process is responsible to launch the vbc.exe (PID 5504) binary that is part of the Microsoft .NET framework, which is stored in the C:\Windows\Microsoft.NET\Framework\v4.0.30319 path.

Vbc.exe is the Visual Basic Command Line Compiler of Microsoft Windows. In this case it was used to inject the Lummac code.

Using this Lummac binary as an example, we can download the memory dumps generated by the CAPE sandbox to expand more information on the execution, getting more context about the infection chain. To download the memory dumps we have to go to Behavior > Download Artifacts > Memdump > CAPE Sandbox.

The memory dump downloaded in this case is a ZIP that has two .dmp files inside. One of the .dmp corresponds to the process with PID 1332 (the initial Lummac sample) and the second .dmp corresponds to the process with PID 5504 related to vbc.exe. Those memory dumps can also be uploaded to VirusTotal, this way existing YARA rules that are designed to detect in-memory behaviors can identify patterns that might have been missed in the original sample.

After uploading the .dmp file from vbc.exe, a malware configuration related to Lummac was extracted from the memory dump, suggesting that the vbc.exe process was injected to load Lummac, and YARA rules created by the Elastic team were triggered.

It is also possible to verify that the vbc.exe process was injected with code to load Lummac by downloading the complete report for the original sample generated by CAPE, which contains more information. The CAPE report can be downloaded from Behavior > Full Reports > CAPE Sandbox, then you can go to the Payloads section to verify that vbc.exe was injected with Lummac code, and that payload was uploaded to our platform.

In the same CAPE report, we could also see how the more.com process was injected during its execution by the initial Lummac sample. Part of this shellcode was also uploaded to our platform to verify if it contains suspicious patterns, and a CAPE YARA rule detected the usage of Heaven's Gate technique, allowing the running of 64-bit code in a 32-bit process.

Now that we have a good idea of what this malware does, before moving on to creating detections, we need to figure out if this is something normal programs do, or if it's something we only see with Lummac and other malware. To do this, we can search for other files that also run more.com and vbc.exe.  We can use this query to find them (It is important to understand that the following query does not have the ability to declare parent and child in genealogy).

(behaviour_processes:"C:\\Windows\\System32\\more.com" or behaviour_processes:"C:\\Windows\\SysWOW64\\more.com") behaviour_processes:"C:\\Windows\\Microsoft.NET\\Framework\\v4.0.30319\\vbc.exe"

We obtained around 50 samples that launched these processes during their execution, and when we reviewed them, they met the parent-child patterns we mentioned above. In addition to all this, a large percentage of the results were related to Lummac. Finally, the samples identified were uploaded to the platform from November 11 to date, which could suggest a new behavior implemented by Lummac in recent campaigns.

Since Sigma is a generic format for writing detection rules, we decided to use it to create the detection of this behavior and share it with the community.

title: Detect The Execution Of More.com And Vbc.exe Related to Lummac Stealer
id: 19b3806e-46f2-4b4c-9337-e3d8653245ea
status: experimental
description: Detects the execution of more.com and vbc.exe in the process tree. This behaviors was observed by a set of samples related to Lummac Stealer. The Lummac payload is injected into the vbc.exe process.
references:
    - https://www.virustotal.com/gui/file/14d886517fff2cc8955844b252c985ab59f2f95b2849002778f03a8f07eb8aef
    - https://strontic.github.io/xcyclopedia/library/more.com-EDB3046610020EE614B5B81B0439895E.html
    - https://strontic.github.io/xcyclopedia/library/vbc.exe-A731372E6F6978CE25617AE01B143351.html
author: Joseliyo Sanchez, @Joseliyo_Jstnk
date: 2024-11-14
tags:
    - attack.defense-evasion
    - attack.t1055
logsource:
    category: process_creation
    product: windows
detection:
    # VT Query: behaviour_processes:"C:\\Windows\\SysWOW64\\more.com" behaviour_processes:"C:\\Windows\\Microsoft.NET\\Framework\\v4.0.30319\\vbc.exe"
    selection_parent:
        ParentImage|endswith: '\more.com'
    selection_child:
        - Image|endswith: '\vbc.exe'
        - OriginalFileName: 'vbc.exe'
    condition: all of selection_*
falsepositives:
    - Unknown
level: high

Another interesting finding we detected in the original Lummac sample is the use of the in-memory SHEmptyRecycleBinW API to empty the recycle bin. While this could be a generic API (and it is), if we search for other samples using the behavior modifier instead of imports, the results we get are unique to Lummac. 

behavior:SHEmptyRecycleBinW

The behavior modifier could give us results based on memory strings, not just based on the imports. As an example, the SHEmptyRecycleBinW API did not appear in the original sample's import table.

VenomRAT

Another study case that caught our attention was a set of VenomRAT samples that were uploaded during the last two months. VenomRAT is a remote access Trojan RAT designed to allow attackers to remotely control Windows systems. 

Observing all the activity related to this sample that we identified, we saw that during its execution it created the C:\Users\user\AppData\Roaming\DataLogs\DataLogs.conf file.

Looking at the content of the .conf file, we saw that it does not contain malicious content per se (since it is a file related to the RAT configuration), but we were able to verify that it was a file dropped primarily by malware samples by looking at its execution parents in the Google Threat Intelligence report.

To determine if this was a detection opportunity, we performed two different searches. The first was to identify other files that created a similar file without the user directory (C:\Users\<user\). We got around 38 samples, most of them related to known RATs.

behaviour_files:"\\AppData\\Roaming\\DataLogs\\DataLogs.conf"

The next query was created to see if just with the file name, we were able to see only RATs in the results or some false positives. After analyzing the results, we obtained many more malicious samples than from the previous query.

behaviour_files:"DataLogs.conf"

Even in an attempt to obtain files that create the DataLogs.conf file with 0 AV detections on the platform, this still resulted in samples that were identified as VenomRAT, Lummac and AsyncRAT.

To have better coverage by the detection, we checked if the configuration file has been created under different names or paths, and found additional unique values.

At this point we know that the \AppData\Roaming\ directory is always present, as it appears to be the directory where the file is created. However, we see different subdirectories that are created later to generate the .conf file, including the filename. The following query can help us to identify new samples creating the .conf file related to the RATs samples.

behaviour_files:"DataLogs.conf" or behaviour_files:"hvnc.conf" or behaviour_files:"dcrat.conf"

And also we have created the next rule that we think might be interesting.

title: File Creation Related To RAT Clients
id: 2f3039c8-e8fe-43a9-b5cf-dcd424a2522d
status: experimental
description: File .conf created related to VenomRAT, AsyncRAT and Lummac samples observed in the wild.
references:
    - https://www.virustotal.com/gui/file/c9f9f193409217f73cc976ad078c6f8bf65d3aabcf5fad3e5a47536d47aa6761
    - https://www.virustotal.com/gui/file/e96a0c1bc5f720d7f0a53f72e5bb424163c943c24a437b1065957a79f5872675
author: Joseliyo Sanchez, @Joseliyo_Jstnk
date: 2024-11-15
tags:
    - attack.execution
logsource:
    category: file_event
    product: windows
detection:
    # VT Query: behaviour_files:"\\AppData\\Roaming\\DataLogs\\DataLogs.conf"
    # VT Query: behaviour_files:"DataLogs.conf" or behaviour_files:"hvnc.conf" or behaviour_files:"dcrat.conf"
    selection_required:
        TargetFilename|contains: '\AppData\Roaming\'
    selection_variants:
        TargetFilename|endswith:
            - '\datalogs.conf'
            - '\hvnc.conf'
            - '\dcrat.conf'
        TargetFilename|contains:
            - '\mydata\'
            - '\datalogs\'
            - '\hvnc\'
            - '\dcrat\'
    condition: all of selection_*
falsepositives:
    - Legitimate software creating a file with the same name
level: high

Wrapping up

Detection engineering teams can proactively create new detections by hunting for samples that are being distributed and uploaded to Google Threat Intelligence. Google Threat Intelligence is a valuable source of information for this purpose, as it provides access to the latest threat intelligence.

During the last defcon we had the opportunity to give a workshop on detection engineering. Stay tuned to our social media for future similar workshops!

We hope you found this blog interesting and useful, and as always we are happy to hear your feedback.