Following MITRE's footsteps in analyzing malware behavior

The MITRE framework helps all defenders speak the same language regarding attackers' modus operandi. VirusTotal provides multiple data points where MITRE's Tactics and Techniques are dynamically extracted from samples when detonated in our sandboxes. In particular, samples' MITRE mapping can be found under the BEHAVIOR tab of a file's report. This data is searchable in VirusTotal Intelligence (VTI) with the help of a set of specific file search modifiers.

In this article, we'll illustrate how security analysts can leverage MITRE for malware detection and behavior-based hunting for ransomware and keylogger samples.

Hunting for Ransomware

The security industry historically identified a set of commonly used techniques in Ransomware campaigns, including inhibiting the system recovery and discovering local files and network shares for later data encryption, usually combined with exfiltration and/or Command and Control techniques.

Common TTPs of modern ransomware groups by Kaspersky

In VT Intelligence we can use 2 search modifiers to query files behavior mapped to MITRE ATT&CK:

• "attack_tactic" search modifier followed by the MITRE Tactic ID returns the list of files that, based on our sandboxes analysis reports, execute techniques under the specified tactic. For example:
  • attack_tactic: TA0040
  • attack_tactic: TA0007
  • attack_tactic: TA0010
  • attack_tactic: TA0011
• "attack_technique" search modifier followed by the MITRE Technique ID returns the list of files that, based on our sandboxes analysis reports, execute the specified technique. For example:
  • attack_technique: T1490
  • attack_technique: T1083
  • attack_technique: T1135
  • attack_technique: T1486

In addition to the "attack_tactic" and "attack_technique" modifiers, VirusTotal provides extra modifiers listed on the Appendix I - Behavior search modifiers for procedures-based queries at the end of this post.

Let's do an example. We want to find samples given a set of ransomware-related techniques combined with the "behavior:CryptEncrypt" operating system API call (check Appendix I for details). Additionally, we specify the entity we are interested in (files) and the first submission date (fs) to filter out files submitted before 2024-01-01.

The resulting query is as follows:

entity:file attack_technique:T1490 and attack_technique:T1083 and attack_technique: T1135 behavior:CryptEncrypt fs:2024-01-01+

Let's analyze in more detail one of the query's resulting files (35619594724871138875db462eda6cf24f2a462e1f812ff27d79131576cd73ab). According to the community, the file belongs to a BlackHunt Ransomware campaign threat that compromised multiple companies in Paraguay.

Its BEHAVIOR report tab, provides details on the techniques detected during sample's detonation:

• T1490 (Inhibit System Recovery), the sample deletes the shadow copies (as highlighted in the Capabilities section below) and it also modifies Windows boot settings via bcdedit.
  
• T1083 and T1135: The sample runs discovery processes to get system local files and directories, and also network shares.
  
• The encryption process is visible by the CryptEncrypt operating system API call, functionality provided by the Advapi32.dll, and visible under the file's DETAILS tab.
  

Hunting for Keyloggers

Keyloggers are a particular form of Spyware designed for stealing user data, that commonly share some MITRE Tactics, including collecting data and/or discovering data for later exfiltration and/or Command and Control communication.

For our VTI query we will specify the T1056.001: Input Capture: Keylogging sub-technique of the Collection tactic, which identifies keystrokes interception. Additionally, we use the first submitted time condition (fs) and both Command and Control or Exfiltration tactics (attack_tactic), since we are not really interested in restricting the way the data gets outside of the victim environment.

attack_technique:T1056.001 (attack_tactic:TA0011 OR attack_tactic:TA0010) fs:2024-02-15+

One of the retrieved files (975b67e75c046e95b1f418c2db85a726dc5d38c21853c5446393b9805c6d1bd5) with a 25 out of 71 AV detection ratio is cataloged as Remcos, a commercial Remote Access Tool with keylogger capabilities among many others, which has been used by several Threat Actors.

On its BEHAVIOR tab, we can see details on the keystrokes interception performed via polling method. The report also reveals additional functionality, including capturing screenshots, reading victims' clipboard and geographical location of the abused device.

Conclusions

In this post we have seen using a couple of examples how present the MITRE framework is on VirusTotal and how it can be used to search for files with a particular TTP-based behavior using VirusTotal Intelligence searches. MITRE-related data is based on behavior detected during samples' sandbox detonation.

We have additionally created an Appendix I (below) detailing some of the most interesting behavior-search modifiers you can use in your queries. This fits particularly well with other TTP-based modifiers, allowing you to refine results by adding particular technical characteristics specific for the malware under analysis.

We hope you found this post interesting and useful. For suggestions or feedback please feel free to reach out here, we will be happy to hear from you.

Happy hunting!

Appendix I - Behavior search modifiers

The following search modifiers provide a more granular way of searching files based on their behavior, allowing more restrictive queries while using Tactics/Techniques ("attack_tactic", "attack_technique") search modifiers.

• "behavior_processes": followed by the executable and parameters used to run during the sample dynamic analysis:
• behavior_processes:"\\vssadmin.exe delete shadows /all /quiet"
• behavior_processes:"wbadmin.exe delete catalog -quiet"
• behavior_processes:" tree c:\\"
• "behavior_injected_processes": followed by the executable name with or without extension:
• behavior_injected_processes:lsass.exe
• behavior_injected_processes:Wininit.exe
• "behavior_created_processes": followed by the executable name with or without extension:
• behavior_created_processes: Wininit.exe NOT name:Wininit.exe
• "behavior_services": followed by the service name to get files opening or deleting internal services:
• behavior_services: sysmon
• "behavior_registry": followed by a system registry key to check for new, deleted or modified registry keys:
• behavior_registry:"\Software\Microsoft\Windows\CurrentVersion\Run"
• "behavior_network": followed by an URL, domain or IP address to identify files communicating with those network elements:
• behavior_network:ip-api.com
• "behavior_files": followed by the file name with or without extension and/or path to identify files that were opened, written, deleted or dropped:
• behavior_files: "C:\ProgramData\Vaccine.txt"
• behavior_files: "\Microsoft\Windows\Start Menu\Programs\Startup\*"
• "behavior": all the previous search modifiers in the appendix can be replaced by this one. It matches against the whole file behavior report and provides a way to check for other data that doesn't have a specific search modifier assigned:
• API calls: Calls Highlighted subsection under Highlighted actions section of a file behavior report:
• behavior: CryptEncrypt
• behavior: IsDebuggerPresent
• behavior: IsWow64Process
• behavior: GetSystemMetrics
• behavior: GetAsyncKeyState
• Mutexes created or opened, under the Synchronization mechanisms & Signals section of a file behavior report:
• behavior:BLACK_HUNT_MUTEX
• Modules loaded section of a file behavior report:
• behavior:CRYPTSP.DLL
• "behavior_tags": followed by the tag of your interest to get files assigned with the indicated tag that you can check here.
• behavior_tags:detect_debug_environment

Read More

VT Livehunt Cheat Sheet

Today we are happy to announce the release of our “Livehunt Cheat Sheet”, a guide to help you quickly implement monitoring rules in Livehunt. You can find the PDF version here.

VirusTotal Livehunt is a service that continuously scans all incoming indicators and notifies you when any of them matches your rules. Livehunt not only monitors files, but also domains, URLs, and IP addresses. In this post we detail a few practical examples along with useful tips.

VT Module

This YARA module was created for VT Hunting services to provide all available context data, which is structured in two main sections: metadata and behaviour (sandbox execution). You can find more information about the VT module here.

Using metadata information in Livehunt rules

Analysts can create rules to hunt based on the metadata information that VirusTotal gathers and processes. We are referring to hunting files by characteristics (type, size, signatures), reputation (antivirus detections, submission patterns), and even contextual details (file names, tags, etc).

For example, this would allow analysts to detect files of a certain type that were submitted several times from a given country, and that more than 5 antiviruses have flagged as malicious. Here you have some detailed examples:

Example 1: Malicious DOCX files that use macros:

This example defines a rule focused on detecting potentially malicious DOCX files with macros.

First we check the file type with vt.metadata.file_type == vt.FileType.DOCX.

The next condition (vt.metadata.analysis_stats.malicious > 5) matches files flagged as malicious by more than 5 antivirus engines in VirusTotal. This filters out most of the benign files, and can be adjusted according to the investigation.

Finally, it loops all tags given by security tools in the analysis pipeline and searches for the tag “macros”: for any tag in vt.metadata.tags:(tag == “macros”)

import "vt"

rule malicious_docx_macros {
  meta:
    description = "Detect malicious documents using macros."
  condition:
    vt.metadata.file_type == vt.FileType.DOCX and
    vt.metadata.analysis_stats.malicious > 5 and
    for any tag in vt.metadata.tags:(tag == “macros”)
}

Example 2: Possible LNK execution through CommandLineArguments Exif metadata field:

The following rule is designed to identify PowerShell execution by manipulating metadata fields of .lnk files. This technique is frequently utilized by malware to avoid detection and initiate attacks. For example, this malicious .lnk file report shows the target command line which will execute PowerShell code to download the “powercat.ps1” script.

In this case, the condition checks for the “powershell” string within two EXIF metadata fields usually used to store the powershell command line - “CommandLineArguments” and “RelativePath”:

vt.metadata.exiftool["CommandLineArguments"] icontains "powershell"
vt.metadata.exiftool["RelativePath"] icontains "powershell"

import "vt"

rule LNK_metadata_execution_powershell {
  meta:
    description = "Detect possible LNK execution through CommandLineArguments Exif metadata field"
  condition:
    vt.metadata.exiftool["CommandLineArguments"] icontains "powershell" or
    vt.metadata.exiftool["RelativePath"] icontains "powershell"
}

Using behaviour information in Livehunt rules

Dynamic analysis can bring great value on top of static one. In VirusTotal, we run executable files through multiple sandboxes and its output is normalized into a common format, which can be leveraged through the “vt” module.

Example 3: Malicious files that use persistence using VBScript:

The following rule identifies persistence under the "RunOnce" registry key using VBS files. This key allows programs to automatically execute once when a user logs in, often exploited by malware to maintain presence on a system.

For this rule, we iterate over vt.behaviour.registry_keys_set looking for "\\CurrentVersion\\RunOnce\\" with a value that ends with ".vbs".

import "vt"

rule persistence_runonce_vbs {
  meta:
    description = "Detect persistence by establishing a VBS file in the runonce key"
  condition:
    for any registry_key in 
     vt.behaviour.registry_keys_set: (registry_key.key icontains
     "\\CurrentVersion\\RunOnce\\") and (registry_key.value endswith ".vbs")
}

Example 4: Suspicious shell scripts in "profile.d" folder:

This rule detects activity involving the creation or modification of shell scripts (.sh files) within the "/etc/profile.d/" directory on Linux systems. This directory is often used to host scripts that automatically execute during user login, making it a common target for malware seeking persistence or automatic execution.

First condition iterates through files dropped (vt.behaviour.files_dropped) during execution as observed in VirusTotal's behavioral analysis and checks if the dropped file's path contains "/etc/profile.d/" and ends with ".sh" in order to match shell scripts.

The second condition is very similar but checks the file path for files written (vt.behaviour.files_written) during detonation.

import "vt"

rule profile_folder_shell_script {
  meta:
    description = "Detects shell script creation in "profile.d" path."
  condition:
    for any dropped in vt.behaviour.files_dropped :(
     dropped.path contains"/etc/profile.d/"
     and dropped.path endswith ".sh"
    )
    or
    for any file_path in vt.behaviour.files_written :(
     file_path contains"/etc/profile.d/"
     and file_path endswith ".sh"
    )
}

Wrapping up

The VirusTotal (vt) YARA module brings you unprecedented flexibility in crafting Livehunt rules combining traditional file content analysis with rich metadata information and behavioral patterns from dynamic analysis.

Our “VT Intelligence Cheat Sheet” provides a quick guide to implement some of the most used techniques. If you have any suggestions or want to share feedback please feel free to reach out here.

Happy Hunting!

Read More

Uncovering Hidden Threats with VirusTotal Code Insight

In the constantly changing world of cybersecurity, generative AI is becoming an increasingly valuable tool. This blog post shows various examples that elude traditional detection engines yet are adeptly unveiled by Code Insight. We explore diverse scenarios, ranging from firmware patches in DJI drones that disable red flight lights, to the covert theft of WhatsApp session cookies, phishing targeting Tesla customers, automated login attempts on the Medtronic CareLink Network, Bitcoin wallet attacks, Tik-Tok viewbots, unauthorized Netflix account access, cheaters for Roblox, and automation of Tinder’s match-making, along with a range of other scenarios.

Code Insight, based on Google Cloud Duet AI, was unveiled at RSA Conference 2023 as a novel feature of VirusTotal. It's specialized in analyzing code snippets and generating reports in natural language from a cybersecurity and malware expert's perspective. Since its introduction, millions of files have been analyzed by Code Insight. The reports generated are readily accessible for consultation and can be leveraged through the VirusTotal Enterprise service for large-scale result aggregation and exploitation. This functionality allows security teams to quickly and efficiently examine vast amounts of code, pinpoint potential threats, and enhance their overall security posture.

Let's delve into some intriguing anecdotal examples that demonstrate how we can uncover threats by utilizing the reports generated by Code Insight. These instances not only showcase the tool's analytical strength but also illustrate the practical applications of its findings in real-world cybersecurity scenarios.

Imagine working on the cybersecurity team at Roblox and wanting to explore what Code Insight has discovered. A simple query in VT Enterprise, such as codeinsight:Roblox, would yield more than 2,000 related files.

Continuing from the previous exploration with Code Insight, let's focus even more closely. Say you're an Anti-Cheat Software Engineer at Roblox interested in the "Murder Mystery 2" game. By refining your search in VT Enterprise to codeinsight:Roblox AND codeinsight:"Murder Mystery 2" AND codeinsight:cheat, the results are much more specific. This refined query leads to a fascinating find - a single file.

Initially received by VirusTotal as a text file, Code Insight correctly classifies it as a Lua script and provides a detailed report on its functionality. This example demonstrates Code Insight's precision in identifying and analyzing content within a specific context, proving invaluable for targeted cybersecurity investigations.

6cc2daf625f329f10c0771eea5924d868edf5445de6565acdd2e02d9c89f70b6

Shifting our focus, let's say we are now investigating a technique used to modify the firmware of DJI drones that turns off LED lights during flight. To discover if Code Insight has identified such modifications, we could use a targeted VT Enterprise search: codeinsight:DJI AND codeinsight:firmware AND codeinsight:lights. Voilà, the search results reveal this:

eb252a56cdfe3c66ba45b4a87863d0dafb18dce49ea42bcbb766e769dbba9e6e

As the previous examples demonstrate, locating interesting samples through the “codeinsight:” operator is remarkably easy. This is largely due to the fact that the searches are conducted within the natural language reports generated by AI, which analyze the code and functionality of files. This approach significantly simplifies the task of finding relevant cybersecurity threats.

Next, we'll present more intriguing cases that have been detected using Code Insight, further showcasing its effectiveness in the cybersecurity landscape: .

Stealing cryptocurrency by replacing addresses from the clipboard

0cf3a43dca5fdb2df9fd6743c8ecac228c1b27823ad0134fc92f384c6b497245

Script that automates the process of logging into the Medtronic CareLink Network

56742933e6384a2911a4f27ab14c927941ece836f34e5fa7699caf17f4a1dd72

Script that steals WhatsApp session cookies

4d128460d2426ba0a47dfe70b3d54ee6e9d331c7889bef61974b3fd5af0e38c3

More examples:

• Script to to increase the number of views on a TikTok video
• Dictionary Attack on Netflix Accounts
• Tinder bot
• Brute-Force Attack on Instagram Accounts
• Phishing Message Script for Tesla Customers
• Brute-Force Bitcoin private key generator

These are just a few examples of how Code Insight can augment our threat intelligence processes and assist in identifying new targeted threats. We encourage you to try it in your investigations, experiencing its capabilities in enhancing your cybersecurity efforts. Stay tuned, as we will soon announce new features for Code Insight. Until then, happy hunting!

Read More

Monitoring malware trends with VT Intelligence

Please note that this blogpost is part of our #VTMondays series, check out our collection of past publications here.

VT Intelligence can be a powerful tool for monitoring malware trends, enhancing your detection capabilities and enabling proactive defense against evolving threats. To leverage it effectively, analysts can refine searches with threat indicators relevant to their business, technologies and to the malware trends occurring at the moment. Analysts can use this intelligence to identify and hunt emerging malicious samples and investigate new trends and capabilities.

To begin with a simple query we will search for new files (“entity:files”) first seen during the last week (“fs:7d+”) and detected by AV vendors as keylogger (“engines:keylogger”) with more than 5 positives (“p:5+”).

entity:file engines:keylogger p:5+ fs:7d+

In our second query we search for fresh (“fs:7d+”) Windows, Linux or MacOS files (“type:peexe or type:elf or type:macho”). To focus on popular/emerging malware, we will use the submissions modifier with a relatively high number (“submissions:10+”), these thresholds serve as illustrative examples and can be adjusted according to the investigation.

entity:file p:10+ (type:peexe or type:elf or type:macho) fs:7d+ submissions:10+

Finally, we will look for Zip files (“type:zip”) that potentially contain ransomware. For discriminating using verdict of AV engines we use the “engines” keyword (“engines:ransom or engines:ransomware”) and use both “ransom” and “ransomware” strings as some engines use different criteria for verdicts. An alternative way of detecting ransomware is through dedicated YARA rules (“crowdsourced_yara_rule:ransomware”).

entity:file type:zip fs:7d+ (engines:ransom or engines:ransomware or crowdsourced_yara_rule:ransomware)

You can learn more about file search modifiers in the documentation.

As always, we would like to hear from you.

Happy hunting!

Read More

Hunting for malicious domains with VT Intelligence

Please note that this blogpost is part of our #VTMondays series, check out our collection of past publications here.

Many cyberattacks begin by victims visiting compromised websites that host malware or phishing scams, threat actors use domains for different malicious purposes as part of their infrastructure, and malware communicates with external sites for command and control and exfiltration. Detecting suspicious domains and preemptively feeding corporate security systems can disrupt attacks before they happen, with VT Intelligence being the perfect platform to early detect them and monitor malicious campaigns’ evolution.

Let’s start by searching for domains (“entity:domain”) that use self-signed certificates (“tag:self-signed”). The use of these certificates raise some suspicion as they are unverified. This means anyone can create and issue a certificate for any domain, making it easier for malicious actors to impersonate legitimate websites. We will look for domains created no more than a week ago (“creation_date:7d+”) according to their whois information. Finally, we want samples with more than 5 detections to avoid false positives, however this is completely at your discretion.

entity:domain tag:self-signed creation_date:7d+ p:5+

Moving to the next stage, let’s look for C2 domains (“category:command and control”). Malware periodically contacts C2 servers to receive instructions, that’s why it is worth investigating any connection to them originating from our network. We will use (“lm”) modifier to look for domains updated in VT for the last week and (“detected_communicating_files_count:5+”) modifier to search for domains with at least 20 files in VirusTotal that have been observed trying to contact the domain during sandbox detonation.

entity:domain p:5+ category:"command and control" detected_communicating_files_count:20+ lm:7d+

Finally, we will hunt typosquatted (“fuzzy_domain:fedex.com”) domains to impersonate a given legitimate one, in this example we will use Fedex. In addition, we search for any suspicious domain containing "fedex" as a substring, which is typically used by attackers to confuse victims. The domain modifier (“domain:fedex”) searches for domains containing this word as a substring, and the depth modifier specifies how many subdomains to include in the search (“depth:5-”). This deep level would find subdomains up to this format “fedex.aaa.bbb.ccc.ddd.com”, where the word fedex could be contained in any of the blocks. We narrow down the results to domains with at least 5 detections (“p:5+”) to reduce noise from false positives.

entity:domain (fuzzy_domain:fedex.com or domain:fedex and depth:5-) p:5+

You can learn more about domain search modifiers in the documentation.

As always, we would like to hear from you.

Happy hunting!

Read More

Sigma rules for Linux and MacOS

TLDR: VT Crowdsourced Sigma rules will now also match suspicious activity for macOS and Linux binaries, in addition to Windows.

We recently discussed how to maximize the value of Sigma rules by easily converting them to YARA Livehunts. Unfortunately, at that time Sigma rules were only matched against Windows binaries.

Since then, our engineering team worked hard to provide a better experience to Sigma lovers, increasing Crowdsourced Sigma rules value by extending matches to macOS and Linux samples.

Welcome macOS and Linux

Although we are still working to implement Sysmon in our Linux and macOS sandboxes, we implemented new features that allow Sigma rule matching by extracting samples’ runtime behavior.

For example, a process created in our sandbox that ends in “/crontab” and contains the "-l" parameter in the command line would match the following Sigma rule:

logsource:

  product: linux

  category: process_creation

detection:

  selection:

    Image|endswith: '/crontab'

    CommandLine|contains: ' -l'

  condition: selection

We have mapped all the fields used by Sigma rules with the information offered by our sandboxes, which allowed us to map rules for image_load, process_creation and registry_set, among others.

This approach has limitations. However, about 54% of Crowdsourced Sigma rules for Linux and 96% for macOS are related to process creation, meaning we already have enough information to match all these with our sandboxes’ output. The same happens for rules based on file creation.

Let’s look at some examples!

Linux, MacOS and Windows examples

The following shell script sample matches 11 Crowdsourced Sigma Rule matches.

For every rule, it is possible to check what triggered the match by clicking on "View matches”. In the case of Windows binaries, it would show what Sysmon event matched the behavior described in the Sigma rule, as we can see below:

In the case of the shell script mentioned above, it shows the values that are relevant to the logic of the rule as you can see in the following image:

Interestingly, Sigma rules intended for Linux also produce results in macOS environments, and vice versa. In this case, the shell script can be interpreted by both operating systems. Indeed, one of the matching rules for the sample called Indicator Removal on Host - Clear Mac System Logs was specifically created for macOS:

while a second matching rule, Commands to Clear or Remove the Syslog , was created for Linux:

To get more examples of samples with Sigma rules that match sandboxes’ output instead of Sysmon, you can use the following queries:

(have:sigma) and not have:evtx type:mac

(have:sigma) and not have:evtx type:linux

A second interesting example is a dmg matching 8 Sigma rules, 5 of them originally created for Linux OS under the “process_creation” category and 2 rules created for macOS. The last match… is a Sigma rule created for Windows samples!

The new feature matching Sigma rules with Linux and macOS samples helped us identify some rules that are maybe too generic, which is not necessarily a problem as long as this is the intended behavior.

In this case, the Usage Of Web Request Commands And Cmdlets rule was originally created to detect web request using Windows’ command line:

The rule seems a bit too generic since it only checks for a few strings in the command line, although it can be highly effective for generic detection of suspicious behavior.

To understand why our Macintosh Disk Image sample triggered a detection for this rule, we checked the matches:

As we can see, the use of the string “curl” in the command line was enough to match this sample.

This sigma rule had about 9k hits last year only, with more than 300 of the files being Linux or macOS samples. You can obtain the full list using the following query:

sigma_rule:f92451c8957e89bb4e61e68433faeb8d7c1461c3b90d06b3403c8f3d87c728b8 and (type:linux or type:mac)

Creating Livehunt rules from Sysmon EVTX outputs

So far we have mainly focused on samples that do not have Sysmon (EVTX) logs. Now let's see how it is possible to create a Livehunt rule based on Sysmon logs. For this, we are going to use the “structure” functionality provided in the Livehunt YARA editor, as we explain in this post.

The sample we will use in this example is associated with CobaltStrike and matches multiple Sigma rules that identify certain behaviors. It is important to note that for every Sigma match, we will see in the file “structure” the context that matched but not the full EVTX logs. These can be downloaded from the sample’s VT report behavior section under “Download Artifacts” or using our API (available for public and privately scanned files).

The following image shows the matching raw EVTX generated by our sample:

From the sample’s JSON Structure, Sigma_analysis_results is an array that contains objects with all the relevant information related to the matching Sigma rules, including details about the rule itself and EVTX logs. From the previous image, the first highlighted section is related to process creation and the second one is a registry event (value set).

As explained in our post, by just clicking on the fields that you are interested in you can start building your Livehunt rule, and adjust values accordingly. In this case, our rule will identify files creating registry keys under \\CurrentVersion\\RunOnce\\ with a .bat or .vbs extension:

import "vt"

rule sigma_example_registry_keys {

  meta:

    target_entity = "file"

  condition:

    for any vt_behaviour_sigma_analysis_results in vt.behaviour.sigma_analysis_results: (

      for any vt_behaviour_sigma_analysis_results_match_context in vt_behaviour_sigma_analysis_results.match_context: (

        vt_behaviour_sigma_analysis_results_match_context.values["TargetObject"] icontains "\\CurrentVersion\\RunOnce\\" and

        (vt_behaviour_sigma_analysis_results_match_context.values["Details"] endswith ".vbs" or vt_behaviour_sigma_analysis_results_match_context.values["Details"] endswith ".bat")

      )

    )

}

Running this YARA using a Retrohunt finds multiple files:

daef729493b9061e7048b4df10b71fdba2e11d9147512f48463994a88c834a30 141e87e62c110b86cf7b01a2def60faab6365f6391eb0d4a7cbad8d480dd4706 814b2cab7c5a12ec18f345eb743857e74f5be45c35642dc01330e7a0def6269a 31b0e9b188fe944d58867bbfc827d77c7711c3a690168a417377fe6bf1544408 dd6051509ed8cf3d059b538fa8878f87423c51b297b49a12144d3d2923c89cce 647323f0245da631cef57d9ca1e3327c3242fe1cbbf6582c4d187e9f5fbfb678 40a90dd3b2132a299f725e91a5d0127013b21af24074afb944d8bc5735c1bd53 b44c6d2dd8ad93cecd795cecde83081292ee9949d65b2e98d4a2a3c8a97bd936 710b0cca7e7c17a3dd2a309f5ca417b76429feac1ab5fb60f5502995ebbd1515 50c098119ce41771e7a3b8230a7aa61ebea925e8eda46c33f0dd42b8950b92fe

Here you can see some interesting matches:

The next rule focuses on file creation events related to Sysmon (EVID 11) under the “C:\Windows\System32” directory, with a “.dll” extension and having any “cve” tag (flagging potential CVE exploitation). Remember we can always include any additional details related to the samples we want to hunt, such as positives, metadata, tags, engines, … in addition to EVTX fields:

import "vt"

rule sigma_rule_evtx_cve {

  meta:

    target_entity = "file"

  condition:

    for any vt_behaviour_sigma_analysis_results in vt.behaviour.sigma_analysis_results: (

      for any vt_behaviour_sigma_analysis_results_match_context in vt_behaviour_sigma_analysis_results.match_context: (

        vt_behaviour_sigma_analysis_results_match_context.values["TargetFilename"] startswith "C:\\Windows\\System32\\" and

        vt_behaviour_sigma_analysis_results_match_context.values["TargetFilename"] endswith ".dll" and

        for any vt_metadata_tags in vt.metadata.tags: (

        vt_metadata_tags icontains "cve-"

        )

      )

    )

}

Sysmon EVTX fields - overlaps

Some of the details found in Sysmon EVTX fields (found in the VT JSON samples’ structure) can be redundant with details provided in other more traditional fields that you use for your Livehunt rules through the YARA VT module.

For example, instead of: vt_behaviour_sigma_analysis_results_match_context.values["TargetFilename"] from vt.behaviour.sigma_analysis_results

you could use: vt.behaviour.files_written to identify file creation events.

When that’s the case, we recommend using traditional fields found in VT samples’ structure for the following reasons:

• Sysmon information is fully stored/indexed only the part matching the Sigma rule, which will limit any YARA hunting.
• We mapped most Sysmon fields into YARA VT module for simplicity.
• Linux and MacOS samples do not have any Sysmon information related to Sigma rules. Similar details about the match can be found under the “behaviour” JSON structure entry.

The new Sysmon-like details offered in the file “structure” also make VT an excellent platform for researchers and Sigma rule creators, allowing them to leverage this information without the need to create their own lab.

The following table helps mapping VT Intelligence queries, YARA VT module fields, Sigma Categories, and Sigma fields:

VT Intelligence	YARA VT module field	Sigma Category	Sigma Field
behavior_created_processes	vt.behaviour.processes_created	process_creation	Image CommandLine ParentCommandLine ParentImage OriginalFileName
behavior_files	vt.behaviour.files_attribute_changed vt.behaviour.files_deleted vt.behaviour.files_opened vt.behaviour.files_copied vt.behaviour.files_copied[x].destination vt.behaviour.files_copied[x].source vt.behaviour.files_written vt.behaviour.files_dropped vt.behaviour.files_dropped[x].path vt.behaviour.files_dropped[x].sha256 vt.behaviour.files_dropped[x].type	file_access file_change file_delete file_rename file_event	TargetFilename
behavior_injected_processes	vt.behaviour.processes_injected	process_access create_remote_thread process_creation	CallTrace GrantedAccess SourceImage TargetImage StartModule StartFunction TargetImage SourceImage
behavior_processes	vt.behaviour.processes_terminated vt.behaviour.processes_killed vt.behaviour.processes_created vt.behaviour.command_executions vt.behaviour.processes_injected	process_access create_remote_thread process_creation	CallTrace GrantedAccess SourceImage TargetImage StartModule StartFunction TargetImage SourceImage Image CommandLine ParentCommandLine ParentImage OriginalFileName
behavior_registry	vt.behaviour.registry_keys_deleted vt.behaviour.registry_keys_opened vt.behaviour.registry_keys_set vt.behaviour.registry_keys_set[x].key vt.behaviour.registry_keys_set[x].value	registry_add registry_delete registry_event registry_rename registry_set	EventType TargetObject Details
behavior_services	vt.behaviour.services_bound vt.behaviour.services_created vt.behaviour.services_opened vt.behaviour.services_started vt.behaviour.services_stopped vt.behaviour.services_deleted	registry_set process_creation	Image CommandLine ParentCommandLine ParentImage EventType TargetObject Details
behavior_network	vt.behaviour.dns_lookups vt.behaviour.dns_lookups[x].hostname vt.behaviour.dns_lookups[x].resolved_ips vt.behaviour.hosts_file vt.behaviour.ip_traffic vt.behaviour.ip_traffic[x].destination_ip vt.behaviour.ip_traffic[x].destination_port vt.behaviour.ip_traffic[x].transport_layer_protocol vt.behaviour.http_conversations vt.behaviour.http_conversations[x].url vt.behaviour.http_conversations[x].request_method vt.behaviour.http_conversations[x].request_headers vt.behaviour.http_conversations[x].response_headers vt.behaviour.http_conversations[x].response_status_code vt.behaviour.http_conversations[x].response_body_filetype vt.behaviour.smtp_conversations[x].hostname vt.behaviour.smtp_conversations[x].destination_ip vt.behaviour.smtp_conversations[x].destination_port vt.behaviour.smtp_conversations[x].smtp_from vt.behaviour.smtp_conversations[x].smtp_to vt.behaviour.smtp_conversations[x].message_from vt.behaviour.smtp_conversations[x].message_to vt.behaviour.smtp_conversations[x].message_cc vt.behaviour.smtp_conversations[x].message_bcc vt.behaviour.smtp_conversations[x].timestamp vt.behaviour.smtp_conversations[x].subject vt.behaviour.smtp_conversations[x].html_body vt.behaviour.smtp_conversations[x].txt_body vt.behaviour.smtp_conversations[x].x_mailer vt.behaviour.tls	network_connection	DestinationHostname DestinationIp DestinationIsIpv6 DestinationPort DestinationPortName SourceIp SourceIsIpv6 SourcePort SourcePortName
behavior (too generic)	vt.behaviour.modules_loaded	image_load	ImageLoaded Image OriginalFileName

Wrapping up

At VirusTotal, we believe that the Sigma language is a valuable tool for the community to share information about samples’ behavior. Our objective is to make its use on VT as simple as possible. Our addition of MacOS and Linux is just the start of what we are working on, as we aim to add Sysmon for Linux to obtain more robust results, including the ability to download full generated logs.

Remember that here you have a list of all the Crowdsourced Sigma rules that are currently deployed in VirusTotal and that you can use for threat hunting.

We hope you join our fan club of Sigma and VirusTotal, and as always we are happy to hear your feedback.

Happy Hunting!

Read More