yara – WindowsTechs.com

Sigma rules for Linux and MacOS

Posted on December 20, 2023 by Joseliyo Sánchez

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→

Examining linux memory dump with signs of compromise in yarascan

Posted on December 18, 2023 by Zzgooloo

I have captured a memory dump of recent Ubuntu 22.04 kernel 6.2.0-39-generic.
captured image with LiMe and analyzed with volatility3.
did a yarascan against all known rules and found a suspicious amount of matches for spyeye.
Here is the o… Continue reading Examining linux memory dump with signs of compromise in yarascan→

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

Posted on October 17, 2023 by Joseliyo Sánchez

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.

https://www.virustotal.com/gui/file/1ea9e9ecd0e5b0ac4aedc1b5515484a372dd8aefb1dbeb00f243a0a3ce40fab9/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.

https://www.virustotal.com/gui/threat-actor/1e9bd6fe-e009-41ce-8e92-ad78c73ee772/summary

https://www.virustotal.com/gui/collection/alienvault_627ce58306cce7d0a5ae037a

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.

First, we only want DLLs, EXE or MSI files.

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

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.

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.

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.

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.

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

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

IP address search modifiers: https://developers.virustotal.com/docs/ip-address-search-modifiers
Domain search modifiers: https://developers.virustotal.com/docs/domain-search-modifiers
File search modifiers: https://developers.virustotal.com/docs/file-search-modifiers
Network hunting: Writing YARA rules for Livehunt: https://developers.virustotal.com/docs/nethunt
File hunting: Writing YARA rules for Livehunt: https://developers.virustotal.com/docs/writing-yara-rules-for-livehunt

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 September 21, 2023 by Joseliyo Sánchez

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 August 1, 2023 by Alexandra Martin

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 July 24, 2023 by Alexandra Martin

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 July 13, 2023 by Alexandra Martin

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 June 26, 2023 by Karl Hiramoto

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→

Is malware abusing your infrastructure? Find out with VirusTotal!

Posted on February 2, 2023 by Alexandra Martin

Any organization’s infrastructure might inadvertently be abused by attackers as part of a malicious campaign. It is therefore important to monitor any suspicious activity. VirusTotal can help you identify these threats and improve your threat detection and protection capabilities. In this post we will first analyze different available search modifiers and then we will provide different templates to quickly deploy infrastructure monitoring rules.

Hunting for infrastructure abuses

VirusTotal Intelligence allows you to search VT’s extensive dataset for domains, URLs, IP addresses and files. You can find some examples on using search modifiers in our previous blog post.

You can use entity: domain or entity: url along parent_domain (entity:domain parent_domain:file.io or entity:url parent_domain:file.io) search modifiers to find VT details on your infrastructure. You can always adjust the results with the antivirus detection ratio (positives or p keyword).

For IP addresses we can use the ip search modifier, also valid for IP ranges:

Specific IP addresses: entity:ip (ip:34.125.68.133 OR ip: 34.125.118.189 ) p:20-
IP range: entity:ip ip:34.120.0.0/13 p:13+

The domain/URL/IP report shows the assigned category by antivirus vendors along with the detection ratio. One of the most interesting tabs is “Relations”, where we can check any suspicious samples communicating with it.

Indeed, we can use some additional modifiers to find networking entities having interesting relationships. We can also use them to immediately flag if there is any domain or IP in our infrastructure communicating with any suspicious file.

Search modifier	Description
detected_communicating_files_count	# of detected files contacting the given domain or IP address when executed in a sandbox
communicating_files_max_detections	maximum # of detected files communicating with a given domain or IP address
detected_downloaded_files_count	# of detected files downloaded by VirusTotal from a URL hosted under a given domain or an IP address
downloaded_files_max_detections	maximum # of detected files downloaded by VirusTotal from a URL hosted under a given domain or an IP address
detected_referring_files_count	# of detected files containing the given domain or IP address in their strings
referring_files_max_detections	maximum # of detected files containing the given domain or IP address in their strings
detected_urls_count	# of detected URLs hosted under a given domain or IP address
urls_max_detections	maximum # of detected URLs hosted under a given domain or IP address

Files

The most generic (although noisy) way to find files potentially targeting your infrastructure is the static one checking files’ content. This returns any file matching your IP addresses, domains or URLs in its content’s strings. In this case it is not possible using IP ranges.

❗Please notice that the content search modifier can’t be used in combination with the entity modifier in the same query.

(content:”google.com” or content:”162.125.248.18″ or content:”https://teleline.site/m/br/ppt4/”) p:20+

This type of query is useful when malware’s infrastructure is not obfuscated and statically found in the sample, which is not common.

There is a better way through dynamic analysis. All samples in VirusTotal are detonated in several sandboxes, which produces valuable data on how it behaves dynamically. Many samples implement anti-sandboxing techniques, so it is not always possible to get all the details.

The best search modifier to find samples communicating with a given URL, domain or IP through sandbox detonation is behaviour_network:

Communicating to a domain. Eg: entity: file behaviour_network: google.com
Communicating to a url. Eg: entity: file behaviour_network: www.virustotal.com/gui/
Communicating to an IP address. Eg: entity: file behaviour_network: 8.8.8.8

The contacted_ip search modifier also allows specifying IP address ranges:

Specific IP address communication. Eg: entity: file contacted_ip: 8.8.8.8
Range communication. Eg: entity: file contacted_ip: 173.194.0.0/16

Besides dynamic execution, you can check if VirusTotal has ever seen any particular suspicious samples being downloaded from your infrastructure. For this you can use the “In the Wild” (itw) search modifier: entity:file itw:file.io p:1+

Do it yourself!

Let’s say you are interested in tracking fresh suspicious samples submitted to VirusTotal communicating your company’s infrastructure (in this case consisting of 2 IPs resolving to our file.io domain). The “first submission” (fs) search modifier gets us files submitted since december last year:

entity:file (contacted_ip:107.23.246.142 or contacted_ip:34.197.10.85) p:10+ fs:2022-12-01+

This query returns 4 files that are detected as malicious by at least 12 antivirus engines.

All samples work in the same way, let’s focus on the first one – 5dd5394ffb7b363a23ba93b7d78d626a133d39e4ea93486bbb8e150db6ff4757. In the Behavior tab -> Network Communication section, we confirm the file resolves “file.io” to one of the IP addresses used in our query.

The Content tab shows an encoded Powershell.

In short, this dropper downloads another sample from https://file[.]io/DseDcCxBoGyr, renames it as MicMute_0.1.8.4_Beta_Setup.exe and executes it.

Automated monitoring

We can automate monitoring our infrastructure in two ways.

1. Using the VT API

With VT API v3 you can use the Advanced corpus search endpoint to use VTI queries like the ones described above. This endpoint requires your premium API key and your URL Safe encoded VT Intelligence query. The example below uses CURL for the the previous query:

curl –request GET –url ‘https://www.virustotal.com/api/v3/intelligence/search?query={entity%3Afile%20behaviour%5Fnetwork%3Afile%2Eio%20%28contacted%5Fip%3A107%2E23%2E246%2E142%20or%20contacted%5Fip%3A34%2E197%2E10%2E85%29%20p%3A10%2B%20fs%3A2022%2D12%2D01%2B}’ –header ‘x-apikey: <your API key>’

The result will be a JSON with the results of the query.

You can also use the official VirusTotal Python client library. The following is an example for the same query:

import “vt”

QUERY = “entity:file behaviour_network:file.io (contacted_ip:107.23.246.142 or contacted_ip:34.197.10.85) p:10+ fs:2022-12-01+”

with vt.Client(API_KEY) as client:
it = client.iterator(‘/intelligence/search’, params={“query”: QUERY })
for file_obj in it:
print(f'{file_obj.id}’)

Please note that queries using “In the Wild” (itw) search modifier cannot be translated (yet) to YARA rules. To automate these queries we encourage you to use the VirusTotal API.

2. Using YARA

YARA allows creating file matching rules based on textual or binary patterns. Each rule consists of a set of strings and a boolean condition. You can deploy Livehunt YARA rules in VirusTotal and get a notification every time a new submitted file matches your rules. Let’s learn how to create basic YARA rules for monitoring your infrastructure.

The first example is based on file content. It will match files containing any of the declared IP addresses, domains or URLs.

import “vt”

rule infrastructure_monitoring {

meta:
description = “Description of the logic of the use case and its goal.”
author = “VT Team”

strings:
  // assets
  $ip1 = “X.X.X.X”
  $ip2 = “Y.Y.Y.Y”
  $url1 = “companyexampledomain.com/url?p=5”
  $url2 = “companyexampledomain.es/url2”
  $domain1 = “companyexampledomain.com”
  $domain2 = “companyexampledomain.es”

condition:
any of ($ip*,$domain*,$url*)
}

By its very nature YARA works only on static file properties, which would be limiting as we have discussed. Happily, we can use VirusTotal’s custom YARA VT module, which extends the common capabilities of YARA to allow you to check sample behavior, metadata, signatures, submissions, etc. When it comes to network activity, this module exposes information about DNS resolutions, established IP connections, HTTP requests, and even SMTP traffic. The following is a list of the most interesting properties we can use for hunting:

vt.behaviour.dns_lookups: this field is a list of DNS resolutions performed by the sample. For each item or resolution in the list, it provides the hostname and the resolved IP address (resolved_ips). We could use this to detect if a sample dynamically tries to contact with a given domain, for example:
dns_lookup.hostname contains “companyexampledomain.com”
vt.behaviour.ip_traffic: this field is a list of established IP connections and it provides the destination IP address, the port and the transport layer protocol (destination_ip, destination_port, transport_layer_protocol) for each connection.
ip_traffic.destination_ip == “X.X.X.X”
vt.behaviour.http_conversations: this field is a list of HTTP requests performed by the sample. Every item in the list provides context information such as request URL, method and headers (url, request_method, request_headers), and response headers, status code and body filetype (response_headers, status_code, response_body_filetype).
http_conversations.url contains “companyexampledomain.com/url?p=5”
vt.behaviour.smtp_conversations: this field is a list of SMTP requests. It provides many features for every item in the list such as the recipient and the sender (message_from, message_to, message_cc, message_bcc), email’s subject and body (subject, html_body, txt_body), and SMTP server related information such as the host name, IP address and port (hostname, destination_ip, destination_port) among others.

smtp_conversations.hostname contains “companyexampledomain.com”

We can now replicate in YARA the search query we used to find samples dynamically communicating with certain IPs:

import “vt”

rule infrastructure_monitoring {

meta:
  description = “Description of the logic of the use case and its goal.“
  author = “VT Team”
  // assets
  ip1 = “34.197.10.85”
  ip2 = “107.23.246.142”

condition:
  // Match only samples detected as malicious by more than 9 AVs
  vt.metadata.analysis_stats.malicious > 9 and (
   // Check the list of established IP connections
   for any ip_traffic in vt.behaviour.ip_traffic : (
    // Match samples communicating to any of my IP addresses
    ip_traffic.destination_ip == “34.197.10.85” or
    ip_traffic.destination_ip == “107.23.246.142”
   )
  )
}

Please note the above YARA also takes advantage of the VT module to check the minimum number of antivirus detections.

Unfortunately, ther’s no easy way to check for IP ranges in YARA. We will cover more advanced cases in our next post on this topic. Additionally, the use of the VT module is limited to Livehunts, but we hope will be soon available for Retrohunts too.

Conclusions

As a takeaway material, we have prepared a YARA rule template you can use to monitor suspicious samples interacting with your infrastructure. You can edit and fine tune it based on your needs by removing conditions or adding new ones.

import “vt”

rule infrastructure_monitoring {

meta:
description = “Description of the logic of the use case and its goal.”
author = “VT Team”

condition:
  // First it checks for strings in sample content
  // This can be potentially noisy, you can consider comment this line
  any of them or

  // Match only samples detected as malicious by more than 10 AVs
  vt.metadata.analysis_stats.malicious > 10 and (
   // Check the list of DNS resolutions performed by the sample
   for any dns_lookup in vt.behaviour.dns_lookups : (
    // Match samples that perform DNS requests for any of my domains
    dns_lookup.hostname contains “companyexampledomain.com” or
    dns_lookup.hostname contains “companyexampledomain.es” or
    // Match samples that resolve to any of my IP addresses
    for any ip in dns_lookup.resolved_ips: (
     ip == “X.X.X.X” or
     ip == “Y.Y.Y.Y”
    )
   ) or

   // Check the list of established IP connections
   for any ip_traffic in vt.behaviour.ip_traffic : (
    // Match samples communicating to any of my IP addresses
    ip_traffic.destination_ip == “X.X.X.X” or
    ip_traffic.destination_ip == “Y.Y.Y.Y”
   ) or

   // Check the list of HTTP requests performed
   for any http_conversations in vt.behaviour.http_conversations : (
    // Match samples communicating to any of my IP addresses
    http_conversations.url contains “companyexampledomain.com/url?p=5” or
    http_conversations.url contains “companyexampledomain.es/url2”
   )
  )
}

❗Please note that YARA doesn’t allow you to implement 2 separate loops consuming the same list of objects.

VirusTotal helps you to automatically monitor and detect samples that target or make use of your network infrastructure. The examples above help you understand the most useful modifiers you can use, but please feel free to explore alternatives you find relevant to filter out noisy results. We recommend a first exploratory manual approach to make sure your searches provide accurate results. After that you can automate your searches using VT API v3, or use Livehunt for deploying YARA rules.

We hope you find this useful, and if you have any suggestions or just want to share feedback please feel free to reach out here. We will be back with a second post with more advanced cases.

Happy hunting!

Continue reading Is malware abusing your infrastructure? Find out with VirusTotal!→

YAIDS execution error without further error log information

Posted on December 11, 2021 by Maiwand

I`m trying to execute YAIDS (installed on ubuntu with quickinstall script) regarding to the general documentation usage in order to analyse a malicious pcap file with the standard ruleset of index.yar from the official rules-master reposit… Continue reading YAIDS execution error without further error log information→