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

Protecting the perimeter with VT Intelligence - malicious URLs

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

One of the main attacking vectors attackers use for credential theft and malware deployment are malicious link-based attacks leveraging impersonated websites or distributing malware. By studying malicious campaigns, defenders can learn attacker tactics and refine their defensive arsenal. They can also use suspicious URLs preemptively, updating deny lists and searching for any suspicious internal or perimetral activity.

VT Intelligence provides a powerful toolset for this mission and can be used to improve URL filtering in your firewalls. Now, we will dive into a series of VT queries progressively increasing their complexity, and dissect the added modifiers for each step. Feel free to experiment and refine these examples to build your own customized queries.

To begin, we will start by searching for URLs (“entity:url”) categorized as phishing according to the content category of its domain (“category:phishing”) or labeled as phishing by AntiVirus engines (“engines:phishing”). We will use the “p” modifier (“p” is short for “positives”, referring to the number of engines detections) to discard benign URLs. In this case, we want URLs with more than 15 detections to avoid false positives, however this is completely at your discretion. Finally, we will look for URLs first seen (“fs” as short for first submission) in the last 7 days (7d+).

entity:url (category:phishing or engines:phishing) p:15+ fs:7d+

The following query hunts new malicious URLs submitted to VirusTotal in the last 7 days distributing Microsoft document or PDF files (“tag:downloads-doc or tag:downloads-pdf”). We use the “p” modifier to search for URLs with a high number of detections (“p:15+”). Malicious URLs used for phishing are likely to distribute this kind of files to compromise the victim's system.

entity:url (tag:downloads-doc or tag:downloads-pdf) p:15+ fs:7d+

Finally, we will hunt URLs impersonating a corporate service provider, such as Office365. We will use the “url” modifier to match substrings contained in the URL string (“url:office365”). In this scenario, we want to find URLs used by attackers to impersonate Office 365 built using Wordpress (“path:wp-content”), and filter the ones with at least 5 detections (“p:5+”). This kind of malicious URLs impersonate legitimate service providers and commonly redirect users to another location after providing their credentials, typically the legitimate site to avoid suspicion. We will check for this behaviour with the “have:redirects_to” modifier.

entity:url url:office365 have:redirects_to path:wp-content p:5+

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

As always, we would like to hear from you.

Happy hunting!

Read More

Protecting the perimeter with VT Intelligence - Email security

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

One of the most common attack vectors to gain access to your network is through phishing emails with attachments containing malware, usually the first stage in a cyberattack kill chain. By gathering intelligence related to the latest phishing campaigns targeting our country or industry, we can prevent emails with malicious attachments reaching our company’s inboxes. This adds a security layer by reducing the burden on employees and not solely relying on their intuition to identify threats.

For this we will use VT Intelligence to hunt threats targeting our email gateway. Our approach starts with a simple example and we will gradually increase its complexity. For each VT Intelligence query we provide a detailed breakdown of the new added modifiers. We encourage you to test the examples provided and to further explore new queries.

Our first basic query searches for documents (“type:document”) tagged as attachments (“tag:attachment”) and submitted from Spain (“submitter:ES”). We will use the “p” modifier (“p” is short for “positives”, referring to the number of AntiVirus detections) to discard benign attachments. In this case, we want samples with more than 5 detections to avoid false positives, however this is completely at your discretion. Finally, we will look for files first seen (“fs” as short for first submission) in the last 14 days (14d+).

type:document tag:attachment submitter:ES p:5+ fs:14d+

Moving to the next stage, we will explore the submissions modifier to identify large-scale attacks, in this case “submissions:50” indicates the minimum number of submissions for a given file which may flag a massive phishing campaign. We use the name of an AntiVirus engine as a modifier to narrow down the results to potential blindspots. In this case, our strategy is searching for files flagged as “clean” by our AntiVirus and detected as malicious by at least 5 other engines.

type:document tag:attachment p:5+ fs:14d+ AhnLab:clean submissions:50+

Finally, we will create a bit more complex condition by combining boolean operators like OR and NOT. We search for specific document types such as docs and spreadsheets, and exclude other document types to narrow to a particular suspicious dynamic behaviour, particularly those actions associated with early stages of an attack. In this example we are searching for office documents either executing powershell or executing macros running additional files when detonated in the sandbox.

(type:doc or type:docx or type:xls or type:xlsx) p:5+ fs:7d+ (behaviour:powershell or (tag:macros and tag:run-file))

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

As always, we would like to hear from you.

Happy hunting!

Read More

VTMondays

Welcome to VTMondays! A weekly series of bite-sized educational pills exploring the use of VirusTotal in real-world scenarios. Here's what you'll get:

• Short lessons: VTMondays are packed with valuable info in under 5 minutes read.
• Real-world scenarios: We're not talking theory, we're talking hunting malware, using intelligence to build up your defenses and staying ahead of the curve.
• Actionable tips & best practices: We'll equip you with practical hacks you can use right away.
• Community connection: Ask questions, share your experiences, and connect with other VirusTotal enthusiasts.

Below you can find the link to the published and upcoming articles.

• Threat detection - Email gateway - 11th Dec
• Threat detection - Malicious URLs - 18th Dec
• Threat detection - Malicious Domains - 25th Dec
• Threat detection - Monitoring malware trends - 1st Jan

Read More