Category Archives: yara

Analysis of Elpaco: a Mimic variant

Posted on by

Kaspersky experts describe an Elpaco ransomware sample, a Mimic variant, which abuses the Everything search system for Windows and provides custom features via a GUI. Continue reading Analysis of Elpaco: a Mimic variant→

Unveiling Hidden Connections: JA4 Client Fingerprinting on VirusTotal

Posted on by

VirusTotal has incorporated a powerful new tool to fight against
malware: JA4 client fingerprinting. This feature allows
security researchers to track and identify malicious files based
on the unique characteristics of their TLS client communications.



JA4: A More Robust Successor to JA3

JA4,
developed by
FoxIO, represents a significant
advancement over the older JA3 fingerprinting method. JA3’s
effectiveness had been hampered by the increasing use of TLS
extension randomization in https clients, which made
fingerprints
less consistent. JA4 was specifically designed to be
resilient to this randomization, resulting in more stable and
reliable fingerprints.


Unveiling the Secrets of the Client
Hello

JA4 fingerprinting focuses on
analyzing the
TLS Client Hello packet, which is sent unencrypted from
the client to the server at the start of a TLS connection.
This packet contains a treasure trove of information that can
uniquely identify the client application or its underlying
TLS library. Some of the key elements extracted by JA4
include:

  • TLS
    Version: The version of TLS supported by the
    client.
  • Cipher
    Suites: The list of cryptographic algorithms the client can
    use.
  • TLS
    Extensions: Additional features and capabilities supported
    by the client.
  • ALPN
    (Application-Layer Protocol Negotiation): The
    application-level protocol, such as HTTP/2 or HTTP/3, that
    the client wants to use after the TLS
    handshake.


JA4 in Action: Pivoting and Hunting on
VirusTotal

VirusTotal has integrated JA4
fingerprinting into its platform through the behavior_network
file
search modifier. This allows analysts to quickly
discover relationships between files based on their JA4
fingerprints.

To find the JA4 value, navigate to the “behavior” section of
the desired sample and locate the TLS subsection. In addition
to JA4, you might also find JA3 or JA3S there.

Example Search: Let’s say you’ve encountered a suspicious
file that exhibits the JA4 fingerprint
“t10d070600_c50f5591e341_1a3805c3aa63” during VirusTotal’s
behavioral analysis.

You can click on this JA4 to pivot using the
search query
behavior_network:t10d070600_c50f5591e341_1a3805c3aa63
finding other files with the same fingerprint This search
will pivot you to additional samples that share the same JA4
fingerprint, suggesting they might be related. This could
indicate that these files are part of the same malware family
or share a common developer or simply share a common TLS
library.


Wildcard Searches

To broaden your search, you can
use wildcards within the JA4 hash. For instance, the search:

behaviour_network:t13d190900_*_97f8aa674fd9

Returns files that match the
JA4_A and JA4_C components of the JA4 hash while allowing
for variations in the middle section, which often corresponds
to the cipher suite. This technique is useful for identifying
files that might use different ciphers but share other JA4
characteristics.



YARA Hunting Rules: Automating JA4-Based
Detection

YARA hunting rules using the
“vt” module can be written to
automatically detect files based on their JA4 fingerprints.
Here’s an example of a YARA rule that targets a specific JA4
fingerprint:

This rules will flag any file submitted to VirusTotal that
exhibits the matching JA4 fingerprint. The first example only
matches “t12d190800_d83cc789557e_7af1ed941c26” during
behavioral analysis. The second rule will match a regular
expression /t10d070600_.*_1a3805c3aa63/, only matching JA4_A
and JA4_C components, excluding the JA4_B cipher suite. These
fingerprints could be linked to known malware, a suspicious
application, or any TLS client behavior that is considered
risky by security analysts.

JA4: Elevating Threat
Hunting on VirusTotal

VirusTotal’s adoption
of JA4 client fingerprinting will provide users with an
invaluable tool for dissecting and tracking TLS client
behaviors, leading to enhanced threat hunting, pivoting, and
more robust malware identification.

Happy Hunting.

Continue reading Unveiling Hidden Connections: JA4 Client Fingerprinting on VirusTotal→

Sigma rules for Linux and MacOS

Posted on by
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!

Continue reading Sigma rules for Linux and MacOS→

The path from VT Intelligence queries to VT Livehunt rules: A CTI analyst approach

Posted on by
This post will explain the process you can follow to create a VT Livehunt rule from a VT Intelligence query. Something typical in threat hunting and threat intelligence operations.
Let’s assume that, as a threat hunter, you created robust VT intelligence (VTI) queries getting you reliable results without false positives. Your queries are so good that you run them daily to obtain fresh new samples, which is a tedious job to do manually (pro tip – you can automate using the API).
A good alternative would be converting your VTI query into a LiveHunt rule, so you will be immediately notified every time any uploaded indicator matches your criteria. Unfortunately, there is not an automated way to convert intelligence queries into LiveHunt rules (and vice versa), and in some cases it is not even possible to obtain exactly the same results (technical tldr – due to limitations of the stored data structure).
But do not despair. In this post we are going to show many practical cases showing LiveHunt rules based on VT intelligence queries, how you can do it yourself, and pros, cons and limitations for this approach.

The perfect query ̶d̶o̶e̶s̶n̶’̶t̶ exist

Bitter APT
Bitter APT is a suspected South Asian cyber espionage threat group. Security researchers like StopMalvertisin, among others, regularly publish information about this actor in both X and VirusTotal community.

To start hunting for files related to Bitter APT, you probably want to subscribe to any attributed VirusTotal collection or the threat actor profile itself.

You can also search for what the community is discussing about this APT directly by searching on community comments. For example, the next query returns samples related to Bitter APT.
entity:file comment:“Bitter APT”

When checking these samples’ behavior we can find interesting patterns that can be used to hunt for other similar ones. For instance, Bitter seems to specially like the “chm” file format, as seen in the initial Twitter/X reference and when calculating Commonalities among these files, along with the use of scheduled tasks to achieve persistence on targeted systems, and run the %comspec% environment variable through the scheduled task created to execute msiexec.exe followed by an URL.

All these behavioral characteristics will help us create good LiveHunt rules and queries to detect additional samples. For example:
behavior_processes:“%Comspec%” behavior_processes:“schtasks.exe” tag:chm
The query returns 39 different samples, most of them apparently related to Bitter based on behavior similarities.

Now it’s time to translate our query into a LiveHunt rule. Certain functionalities available for VTI queries are not ready (yet) in VT LiveHunt and vice versa. We are working to maximize the integration between both systems, and we will get back with more details as we progress in this.
As we published, we can create a LiveHunt rule from a sample by simply clicking – we are going to create a rule based on 7829b84b5e415ff682f3ef06b9a80f64be5ef6d1d2508597f9e0998b91114499.
First, we are interested in identifying the use of the process “schtasks.exe” during sample detonation. In the behaviour details of this sample, we can find “schtasks.exe” in the “Process Tree” and “Shell Commands” sections.

At the moment, it is not possible to use “Process Tree” in LiveHunt rules, however we can search for processes in “Shell Commands” and “Processes Created” sections to start creating the logic of our rule. In future updates, we will integrate more fields to be used in the creation of LiveHunt YARA rules.

There is no “Processes Created” section, maybe sandboxes were unable to extract such information. But this does not mean it will be the same for future uploaded samples. We will add both the “Shell Commands” and “Processes Created” fields to the condition.
We will follow the same steps to detect the use of the environment variable “%comspec%” in the command line during detonation.

We look for the same information in the two sections (shell and processes) and in two different ways as Bitter used upper and lower case letters to spell %coMSPec%. We can simplify this with the “icontains” condition to enforce case insensitiveness.

Finally, we want to add two extra conditions. The first is that samples have the “chm” tag since it is the format we look for. The second is to get notifications exclusively for new uploaded files.

And that’s it! You can download and use this YARA rule from our public GitHub, to be integrated into our Crowdsourced YARA Hub in the future.
RomCom RAT
BlackBerry Threat Research and Intelligence team published about Targeting Politicians in Ukraine using the RomCom RAT. During the campaign, threat actors used a trojanized version of Remote Desktop Manager.
Taking a look at the behavior of the samples provided in this publication, we can find interesting behavioral indicators to generate a VTI query.

Different samples related to RomCom RAT seem to usually drop DLL files in the path “C:\Users\Public\Libraries” with different extensions, and execute them using “rundll32.exe”. That means there are also file creation events in the same path.

All of these indicators, along with others used by RomCom RAT in different intrusions, can be used to create a potential query that can later be translated into a LiveHunt.
These samples export up to three different functions:
  • fwdTst
  • #1
  • Main
“Main” is probably the most common function exported by many other legitimate DLLs, so we will ignore it. The VTI query we use is as follows:
((behavior_processes:“.dll,fwdTst”) OR (behavior_processes:“dll\”,#1″ behavior_processes:“\\Public\\Libraries\\”) OR (behavior_processes:*.dll0* behavior_processes:“\\Public\\Libraries\\”)) AND ((behaviour_files:*\\Public\\Libraries\\*) AND (behavior:*rundll32.exe*))
Even if you don’t know that the “Main” function is common in the use of DLLs, when building our query we would observe a large number of samples matching our logic. For this reason, it is important that before creating a rule we use a query when possible to understand if results align with our expectations, and iterate the condition until we are satisfied with it.
The last query provides samples related both to RomCom RAT and Mustang Panda. This might indicate that both threat actors are using similar procedures during their campaigns.

To convert this query to LiveHunt, we will split the original query into different sections and adapt them to the rule. As previously explained, the rule will be slightly different from the original query for compatibility reasons.
  1. First, we only want DLLs, EXE or MSI files.

  2. As a precaution to minimize false positives, we want to skip samples that are not detected as malicious by AntiVirus vendors.

  3. Something that we can’t do in VT intelligence queries is determine behavioral activity related to file write actions. VTI behavior_files modifier performs a generic search for any literal within file activity, including creation, modification, writing, deletion… LiveHunt gives us more precision to specify our search only for written files during detonation.

  4. Rundll32.exe is used during execution since this DLL should be executed along this sample’s process. We will search for it in different fields.

  5. Finally, we are interested in obtaining the functions exported by the observed DLLs, which are written in the command lines. We are also interested in the existence of a .DLL extension, which will indicate that there is some type of activity involving libraries.

You can also find this rule in our public Github repository. Feel free to modify it based on your needs!
Gamaredon
Our last example is related to the Gamaredon threat actor. As per MITRE “Gamaredon Group is a suspected Russian cyber espionage threat group that has targeted military, NGO, judiciary, law enforcement, and non-profit organizations in Ukraine”.
The use of the remote template injection technique is common by this threat actor. This feature involves making connections to a remote resource to load a malicious template. The external domains used to host it generally use some URL pattern. According to publications from different vendors, this actor usually registers domains in the “.ru” TLD.
Gamaredon also uses the DLL “davclnt.dll” with the “DavSetCookie” function. This behavior is related to flags that may be connected to exfiltration or use of WebDav to launch code. In other words, this is used to load the remote template. We can quickly check this with the following query:
threat_actor:“Gamaredon Group” behavior:“DavSetCookie”
Putting all this information together, we can create the next VT intelligence query to get samples related to Gamaredon:
(behavior_processes:*.ru* and behavior_processes:*DavSetCookie* and behavior_processes:*http*) and (behavior_network:*.ru* or embedded_domain:*.ru* or embedded_url:*.ru*) (type:document)
The query is designed to discover file-type documents where the following strings are found during execution:
Behavior_processes:
  • First we want to identify the use of the string “.ru” in the command line. This will be related to domains with this TLD.
  • Another string that we want to match in the command line is “DavSetCookie”, since it was used by Gamaredon to accomplish remote template loading.
  • Finally the string “http” must be in the command line as well.
Behavior_network:
  • See if there are communications established with domains having the “.ru” TLD.
Embedded_domain:
  • Domains embedded within the document containing the TLD “.ru”. It is not necessary that a connection has existed. We do it this way in case our sandboxes have had problems communicating or the sample has simply decided not to communicate.
Embedded_url:
  • URLs embedded within the document containing the TLD “.ru”. It is not necessary that a connection has existed. We do it this way in case our sandboxes have had problems communicating or the sample has simply decided not to communicate

This VT intelligence query provides results that seem to be consistent with known Gamaredon samples, based on the previously discussed patterns. It is always possible we get false positives among the results.
Let’s convert this VT intelligence query to a LiveHunt to receive notifications for new interesting files.
  1. First, we want to make sure the exported DLL function is found for any command line or process-related behavior, as well as finding traces of the “.ru” TLD is found for http communication. It is important to mention that we look for information about the TLD “.ru” and the string “http” in the command lines because it could be the case that the connection is not established, but there was an intention to establish it.

  2. Communications are important, for that reason we need to check if there were connections established with domains having the TLD .ru. Remember the next block will match only if communications existed

  3. And for this example, we are just interested in document files, although you can change it to any other file type to adapt it to your needs.

As usual, you can find and download the YARA rule in our public repository.

Actual limitations

We are aware of the limitations that currently exist when translating fields from VT intelligence to LiveHunt rule and vice versa, and we are working to obtain maximum compatibility between both systems. However, for the moment this could be an advantage as they complement each other.
VTI modifiers such as behavior_processes, behavior_created_processes or even behavior are somewhat more generic than the possibilities that LiveHunt currently offers, allowing us to specify whether we want information about the processes created, completed or commands executed.
However, something that cannot be used yet in LiveHunt rules is the process tree. On some occasions, dynamic executions of our sandboxes only offer information at the process tree level, which means that this information is not available for our rules. But if you want to search information within the process tree with VT intelligence queries, you can use the “behavior” file modifier. The “behavior” modifier the process tree could be consulted to find information.

Wrapping up

Converting VT intelligence queries to LiveHunt rules is getting easier. The recently added “structure” feature in LiveHunt allows creating rules in a much simpler way by clicking on the interesting fields, creating the rule conditions for you and eliminating the need to know all available fields in the VT module.
This post describes with examples a potential approach that analysts might use for their hunting and monitoring. In particular, using VT Intelligence queries before starting working on a YARA rule is really helpful during the initial fine tuning stage of our condition. This practice minimizes noise and ensures we get quality results before we go for our LiveHunt rule. Finally, a quality VTI query can be translated into a YARA with just a few minor changes.
We hope you find this useful, and as always we are happy to hear from you any ideas or feedback you would like to share. Happy hunting!
References that could be interesting

Continue reading The path from VT Intelligence queries to VT Livehunt rules: A CTI analyst approach→

It’s all about the structure! Creating YARA rules by clicking

Posted on by
Since we made our (extended) vt module available for LiveHunt YARA rules we understand it is not easy for analysts to keep in mind all the new potential possibilities – too many of them! Our goal is to make YARA rule creation as easy as possible while providing security experts everything they need to make even more powerful rules. Our recently published new YARA editor, which incorporates full syntax coloring and auto-complete while you develop your rule, is a first step.
However, we wanted to go further. We already discussed how you can use predefined templates (additionally you can check our Threat Hunting with VirusTotal – Episode 4 for further examples and ideas), but in this post we want to focus on a terrific new feature when creating rules using the “Structure” of any given object (file, URL, domain or IP).
“Structure” provides the full JSON containing all details VirusTotal knows for any given indicator. For instance, you can paste a file hash and you will get full details about its behaviour and metadata. What is better, you can simply click on any field you are interested in, and it will automatically included in a fresh new YARA rule in the editor – no need to remember how to get that particular field in the VT module anymore.
In case you are wondering, this also deals with all kinds of loops. If any of the selected fields needs to be iterated, the correct syntax will automatically be added to your rule.
Let’s check the different object types.

Files

For a file object you will find two different branches in the resulting JSON – behaviour and metadata.
The behaviour key is based on the sample execution in the sandbox. For example, you can create rules based on files written by the malware, files dropped, mutexes created, processes created, sigma results or ATT&CK MITRE results, among others.
Let’s suppose that we are interested in creating a new detection logic focused on some specific file written. In that case, we want to open the files_written section and then click on the file that we have observed as suspicious for our rule. Automatically, a new rule pops up with that condition (note that the loop condition was conveniently created for us too).
We can keep editing the rule to adapt it to our needs, like adding additional conditions to detect a specific string or path, another file name, etc.
If your security posture takes into account the ATT&CK MITRE matrix, maybe you want to create rules adding these fields in your logic, available under the key mitre_attack_techniques branch.
In addition to vt.behaviour, it is also possible to use vt.metadata to create a rule based on file metadata. Under the metadata key, we have a lot of interesting information that we can use to create our rule.
Probably one of the most interesting fields is “itw”. Under this key, we can create rules based on ITW communications that we are interested in detecting whether related to IPs, domains or URLs.
For example, we may be interested in files that were downloaded ITW with response code 200, from the Discord CDN and that download binaries but more specifically DLLs.
Another interesting approach could be to hunt for files that are downloaded ITW, but with characteristics that could interest us in the whois of the domain from which it was downloaded. This could be interesting if we are monitoring certain domains that are being registered.
Metadata gives us multiple ways to play to create livehunt rules. From more complex rules using ITW applying filters related to domains, IPS or URLs to more basic things where we can include information from exiftool, submitters, fuzzy hashing, etc.
Combining the power of metadata and behaviour will result in a quality YARA rule!

URL

For URLs, under the “net” section in the VT module, you have the possibility to use the keys url, ip and domain as shown on the Netloc summary table. Any field available under these keys can be used to create your URL hunting rule.
Some of the features you can use to create your rule include URL response headers, downloaded and communicating files, URL path, domain whois, IP ASN, among others. Just by clicking on the fields you are interested in and adapting them to your needs, you can create a robust rule that helps you follow a campaign you are interested in investigating.
A use case could be that we were interested in discovering new URLs seen in VirusTotal, where the path meets a certain pattern, resolves to a certain network block and the domain registry is a registry known as commonly used to register malicious domains. Finally, to avoid noise we are interested just in new URLs.
Last rule can match for example an URL used by Gamaredon threat actor.

IP

The fields available for the IP entity can be found under the the ip key in VT.net. Here you can play with fields such as IP whois, communicating files, netblocks and others.
From here, we can add as much information as we are interested in to identify new ip addresses from suspicious campaigns. The following image is the result of a few clicks on fields containing a specific IP address.
Let’s suppose we want to identify new IP addresses that belong to a certain ASN (here we explain how to calculate a network range) and have some type of communication with PEEXE binaries.
This type of use case could even be used to monitor certain network ranges that may belong to our organization or customers to identify if a new IP address has any files that carry out communications.

Domain

Last but not least, we can also use the new Structure functionality with domains. In this case, domains include information about both the domain itself and the IP address it resolves.
And the same process that we have followed with the other entities that we have taken as an example, it would only be enough to click on the fields that interest us and shape our rule.
Within the information that we can find within the domains, there is an interesting field called categories. Within these categories we can identify if the domain could be linked to malware, phishing, spyware…
To create a use case with this field, let’s say that we want to discover new domains that are related to phishing, and that the value of the not_before field of the HTTPS certificate is greater than a specific date that we want to search for information.
Another case that we can do also related to phishing is to monitor a specific favicon that is using our brand image. Subsequently, we are also interested in whether it includes a pattern in the domain name or in the alternative name in the certificate.

Wrapping up

At VirusTotal we continue trying to include the greatest number of functionalities that are useful for analysts for threat hunting. Our goal is to make work easier and spend time intelligently when using the platform.
The idea of this new feature is to continue to add new fields that can be consumed through VirusTotal intelligence to make livehunt rule creation more powerful. It is not easy to remember or know which fields are available within the files to create livehunt rules, so the new “Structure” functionality can help us.
We want livehunt rules to be a great tool to detect campaign patterns and to be able to track players more powerfully.
We would also like to announce that we have opened a GitHub where the community can publish their YARA rules and contribute! During the following weeks we will be posting new rules https://github.com/VirusTotal/vt-public-crowdsourced-yara.
We hope you liked this functionality. Happy hunting!

Continue reading It’s all about the structure! Creating YARA rules by clicking→

Actionable Threat Intel (V) – Autogenerated Livehunt rules for IoC tracking

Posted on by
As we previously discussed, YARA Netloc uncovers a whole new dimension for hunting and monitoring by extending YARA support to network infrastructure. All VirusTotal users have already access to different resources, including templates, a GitHub repository, and the official documentation to quickly get started on writing network YARA rules.
You can also find excellent external resources, like this blog post from SentinelOne’s Tom Hegel, which discusses the use of YARA Netloc in a real investigation.
And as we highlighted in our previous post, this is just the beginning. We are playing with new ideas and features that leverage YARA Netloc, and we couldn’t resist implementing a few of them already. In this blog, we will discuss a new functionality that uses YARA Netloc to help us track indicators of compromise (IoCs) and their related infrastructure with just a few clicks.

IoCs subscription

You might have noticed that all IoC reports in VirusTotal have a new Follow dropdown menu in the top right corner, which offers a few options.
The idea of this new feature is to offer VirusTotal’s users easy ways to track any IoCs’ activity. For instance, as shown in the previous screenshot, we are offered to monitor any infrastructure that this malware interacts with in the future (URLs, domains or IPs), or being notified when we see it being downloaded from anywhere.
When clicking any of these options, we are creating a one-click Livehunt rule based on a template. We can customize the resulting rule as needed, or simply deploy it as suggested, although we highly recommend renaming it to easily identify it.
For example, by clicking URLs downloading it in the previous sample’s report, the following rule will be automatically generated and deployed in our Livehunt:

import “vt”

rule UrlDownloadsFile {
  condition:
    // vt.net.url.new_url and // enable to restrict matches to newly seen URLs
    vt.net.url.downloaded_file.sha256 == “2cb42e07dbdfb0227213c50af87b2594ce96889fe623dbd73d228e46572f0125”
}

This rule will simply track and notify any new URL VirusTotal observes downloading that particular sample.

Livehunt dashboard

The Livehunt dashboard consolidates all your team’s and your own Livehunt YARA rules in one place. We added three filtering options to help you quickly move around.

  • The first one filters rules created by yourself, created by other users in your VirusTotal group and shared with you, or “Autogenerated” with the IoC’s report Follow option, as previously explained.
  • The second filter allows you to search for rulesets containing a specific substring in its name or anywhere else in the ruleset, including comments. For example, if we use the hash of the file in the previous example (2cb42e07dbdfb0227213c50af87b2594ce96889fe623dbd73d228e46572f0125), we get the rule we previously created. Please note VirusTotal will automatically add tags corresponding to the to the names of the rules in a ruleset, plus the “Autogenerated” tag if the ruleset was generated with the Follow option:
  • The third one allows you to filter by ruleset status (active or inactive).

The dashboard also shows whether rulesets are active, as well as the entity that ruleset matches against. You can also find which users and groups that ruleset was shared with and, lastly, the number of matches – which lists all matching IoCs in the IoC Stream by clicking it.

Wrapping up

In the previous posts in our “Actionable Threat Intel” series we showed how to use the new YARA editor, deploying Livehunt rules from the editor either using templates or from scratch, using Netloc for creating network hunting rules, and how to track IoCs of interest with automatically generated hunting rules.
All these elements help us to set the monitoring rulesets we need to be on top of our investigations or any malicious activity set of our interest. IoC Stream serves as a single repository to centralize all our notifications, including Hunting rules, IoC Collections and Threat Actors subscriptions.
Last but not least, we would like to specially thank our colleagues from Mandiant and all the security researchers who kindly offered to help during early stages and beta testing to help make Netloc hunting as good as possible:
    Paul Rascagneres (@r00tbsd), Volexity
    Ariel Jungheit (@arieljt), Kaspersky
    Marc Green (@green0wl), eBay
    Vitor Ventura, Cisco
    Markus Neis (@markus_neis), Arctic Wolf
    Matt Pierce, CrowdStrike
    Pasquale Stirparo (@pstirparo), Independent Researcher
    Tom Hegel (@TomHegel), SentinelLabs
We hope you find these features as useful as we do. If you have any questions or requests please do not hesitate to contact us.
Happy hunting!

Continue reading Actionable Threat Intel (V) – Autogenerated Livehunt rules for IoC tracking→

Actionable Threat Intel (IV) – YARA beyond files: extending rules to network IoCs

Posted on by
We are extremely excited to introduce YARA Netloc, a powerful new hunting feature that extends YARA supported entities from traditional files to network infrastructure, including domains, URLs and IP addresses. This opens endless possibilities and brings your hunting to a whole new level. Let’s get started!

Creating Network rules

YARA Netloc is based on extended functionality implemented for the “vt” YARA module. In particular, you will find now a new “.net” attribute specifically for network related entities such as URLs, domains and IP addresses. Here you can find the full documentation. Remember you can use the “vt” YARA module for any of your LiveHunt YARA rules.
Before we start working on a few examples it is important to highlight what resources you have available to get you quickly up to speed. First, our new YARA editor has available several templates you can use to build your rules. Second, the whole community can benefit from VirusTotal’s community rules in our new crowdsourced YARA GitHub repository. The repository is split into four folders, each of which with rules matching different entities (file, domain, IP or URL).
Let’s start with a first example rule. The “New Livehunt Ruleset” dropdown on the Livehunt section now allows us to select what kind of YARA we want to create, depending on the entity we want to match against.

Let’s select “New ruleset matching against Domains” to deploy a rule to track if any of our domains is serving malware without our knowledge. We will use the “Domain serving malicious files” template available on the YARA editor.

import “vt”

rule malware_distribution {
  meta:
    description = “Detects if my infrastructure is being used to distribute malware or malicious domains are impersonating my legitimate domain with the same purpose.”
    category = “infra-monitoring”
    references = “https://www.virustotal.com/gui/search/entity%253Adomain%2520domain%253Atelegram.com%2520downloaded_files_max_detections%253A5%252B/domains”
    creation_date = “2023-07-19”
    last_modified = “2023-07-19”
    target_entity = “domains”
  condition:
    vt.net.domain.raw icontains “telegram.com” and
    vt.net.domain.downloaded_file.analysis_stats.malicious >= 5
}

In this case we can easily see how the new “.net” attribute is used in this rule. First we use “domain.raw” to specify our domain by comparing it to a given string (“telegram.com” in this example). Then we simply check if any new downloaded file from that domain looks suspicious by having five or more antivirus verdicts. We will keep this rule running as a Livehunt, and will be notified through IoC Stream in case VirusTotal sees our domain downloading anything suspicious.

Let’s see another example.
Now we are going to reuse one of the rules available in our repository, in this case to track Cobalt Strike’s infrastructure. The rule tracks IP addresses serving a well-known Cobalt Strike certificate, which we check with the “ip.https_certificate.thumbprint” condition. We could easily create similar rules for all kinds of suspicious infrastructure serving https certificates identified as malicious.
import “vt”

rule Cobalt_Strike_Default_SSL_Certificate
{
  meta:
    name = “Default CobaltStrike self-signed SSL Certificate”
    description = “Find IP addresses serving the default SSL certificate used out of the box by Cobalt Strike for C2 comms”
    reference = “https://www.mandiant.com/resources/blog/defining-cobalt-strike-components”
    target_entity = “IPs”
  condition:
    vt.net.ip.https_certificate.thumbprint == “6ece5ece4192683d2d84e25b0ba7e04f9cb7eb7c”
}

For our final example we will create a rule from scratch.

In this case we are inspired by the Zaraza bot credential stealer that exfiltrates stolen data using Telegram channels so we will use VirusTotal to hunt for fresh infrastructure (URLs) used in that way. Our rule will check for known patterns in the URLs for a given domain (“api.telegram.org”), and then check if the last file seen communicating with them (“communicating_file”) seems suspicious (“analysis_stats.malicious”>5) and it has a particular AV verdict (“steal” or “exfilt”) looping its “signatures” .

import “vt”

rule telegram_bot_stealer {

  meta:
    description = “Detects Telegram channels that bots potentially use to exfiltrate data to.”
    category = “MAL-infra”
    malware = “Stealer”
    reference = “https://www.uptycs.com/blog/zaraza-bot-credential-password-stealer”
    examples = “https://www.virustotal.com/gui/file/2cb42e07dbdfb0227213c50af87b2594ce96889fe623dbd73d228e46572f0125/detection, https://www.virustotal.com/gui/url/f4abd85188b86df95c7f8571f8043d92ad033b6376a113fd0acd8714bd345798/detection”
    creation_date = “2023-07-06”
    last_modified = “2023-07-06”
    target_entity = “url”

  condition:
    vt.net.url.raw icontains “https://api.telegram.org/bot” and
    (
      (
        vt.net.url.raw icontains “/sendMessage?” and
        vt.net.url.query icontains “text=”
      ) or
      vt.net.url.raw icontains “/sendDocument?”
    ) and
    vt.net.url.query icontains “chat_id=” and
    vt.net.url.communicating_file.analysis_stats.malicious > 5 and

    for any engine, signature in vt.net.url.communicating_file.signatures : (
      signature icontains “steal” or signature icontains “exfilt”
    )
}

Wrapping up

YARA rules are no longer limited only to tracking files. The new “.net” attribute in the “vt” YARA module empowers users with the ability to discover suspicious network infrastructure and combine it with VirusTotal’s metadata for a huge range of use cases.
The YARA “vt” module provides standardized syntax for files and network detection rules and allows combining attributes of different entities for highly customized monitoring rules. Additionally, it replaces the need of periodic (manual, but specially automated) lookups by allowing the deployment of Livehunt rules for monitoring.
Although this blog post shows some of the new YARA Netloc capabilities using a few examples, there are infinite possibilities. You can use it to track threat actors’ infrastructure, to monitor your own infrastructure (including IP ranges) or to detect phishing campaigns targeting your company, amongst many other use cases. You can find many more ideas by checking the YARA editor templates, checking the official documentation or the YARA rules GitHub repository.
We will be back soon with more details, use cases and examples for YARA Netloc hunting capabilities, but in the meantime do not hesitate to contact us for anything you need.
Happy hunting!

Continue reading Actionable Threat Intel (IV) – YARA beyond files: extending rules to network IoCs→

Actionable Threat Intel (III) – Introducing the definitive YARA editor

Posted on by
One of VirusTotal’s biggest strengths is its Hunting capabilities using YARA rules. In addition to matching all files against a big set of crowdsourced YARA rules, it also allows users to create their own detection and classification rules.
YARA was originally intended to support file-based rules. VirusTotal’s “vt” module extended YARA’s capabilities with file’s metadata and behavior. This allows our users to create advanced Livehunt and Retrohunt rules and get notified via IoC Stream every time new or re-scanned files match our rules.
Designing good YARA rules requires some level of expertise and time investment. That’s why we have reengineered our built-in YARA editor to make it easier for our users to create, test and deploy rules. In this post we will provide details for all its new capabilities!
Other than making YARAs look glorious with full syntax coloring and auto-complete, there is much more this editor offers. But first let’s clarify how to find the new editor.
The new YARA editor can be accessed from the Livehunt or Retrohunt dashboards over the Hunting dropdown on the top left menu of the landing page. From the Livehunt dashboard, the “New Livehunt Ruleset” dropdown has 4 options that link you to the YARA editor for the specific entity of your interest.
This post will focus on file rules – but stay tuned for future posts detailing all other options.
Ok, now let’s see in more detail all the big new features!

Feature #1 – YARA rule templates

The YARA editor provides you with pre-defined self-descriptive rule templates (here you can find full details). We will keep adding more templates in the future and refreshing existing ones.
For instance, let’s say that you are interested in new samples, detected as malicious by AntiVirus engines, and hosted on a certain domain or URL. You can filter out templates available using keywords such as: “URL”, “download” and “positive”, and select the one that fits you better based on its description, as shown in the image below.
Now it’s easier to build your own rules by making use of the suggested templates. You just need to replace the placeholders with your specifics. Additionally, it is very important to rename the predefined rules so you can easily identify the source of the notifications you’ll receive in your IoC Stream. In this case, the target URL and the number of detections for new files.
We will create a new rule based on these templates, with a few extra details: [1] we want to get PDF files only, [2] check if the file was seen hosted in a given domain, and [3] add a couple of extra domains to check if the file resolved them when executed in any of our sandboxes. Here is the resulting rule:
import “vt”

rule malware_hosted_on_strikinglycdn {

  meta:
    description = “Detects malicious files hosted on strikinglycdn.com domain.”
    category = “MAL”
    examples = “https://www.virustotal.com/gui/search/p%253A5%252B%2520itw%253Astrikinglycdn.com%2520(behaviour_network%253A%2522oyndr.com%2522%2520or%2520behaviour_network%253A%2522fancli.com%2522)/files”
    creation_date = “2023-07-11”
    last_modified = “2023-07-11”

  condition:
    // combining existing templates
    vt.metadata.analysis_stats.malicious > 5 and
    vt.metadata.new_file and
    // [1] checking filetype
    vt.metadata.file_type == vt.FileType.PDF and

    // [2] check if the file was hosted in this domain
    (
      vt.metadata.itw.domain.raw iendswith “.strikinglycdn.com” or
      vt.metadata.itw.domain.raw == “strikinglycdn.com”
    ) and

    // [3] check if it resolves these domains during sandbox detonation
    for any dns_lookup in vt.behaviour.dns_lookups : (
      dns_lookup.hostname == “oyndr.com” or
      dns_lookup.hostname == “fancli.com”
    )
}

Feature #2 – YARA playground

When designing a rule it is always very hard to find the right balance between over and under fitting. Is our rule detecting the samples it is based on? How many other samples are being detected by it? Does our rule detect any unintended legitimate samples? Given this is the first thing every security expert would do, we decided to make it easier to test your fresh new rule against a set of IoCs.
In the bottom of the editor you will find 3 tabs. In the TEST tab you can add a set of IOCs you want to test your rule against, as shown below.
Then we are ready to Run test and find TEST RESULTS in the next tab, showing how the tested IoCs matched our rule.
If anything happens, the PROBLEMS tab will give you details.
Additionally, when working with multiple rulesets in multiple web browser tabs at the same time, the YARA editor displays a


message on the top right corner to help you to always keep in the spotlight the entity you are targeting with your rules.

Wrapping up

The new YARA editor is integrated with both Livehunt and Retrohunt, so basically will be our default editor for anything YARA-related in VirusTotal. The goal is making writing rules easier and faster, and finding everything you need, from templates to testing, in one place.
You may have noticed that the ITW feature is not included in the official documentation, and that it was not previously possible to perform this type of check. This is because it is part of our ongoing improvements to the “vt” module for YARA, which we will be introducing to you very soon.
We hope you find all these new features as useful as we do. If you have any questions or requests please do not hesitate to contact us.
Don’t forget to stay tuned, Netloc Hunting is coming! And as always, happy hunting!

Continue reading Actionable Threat Intel (III) – Introducing the definitive YARA editor→

Threat hunting converting SIGMA to YARA

Posted on by

Malware threat hunting is the process of proactively searching for malicious activity. It is a critical part of any organization’s security posture, as it can help to identify and mitigate threats that may have otherwise gone undetected.

… Continue reading Threat hunting converting SIGMA to YARA→