Author Archives: Alexandra Martin

Following MITRE’s footsteps in analyzing malware behavior

Posted on by
The MITRE framework helps all defenders speak the same language regarding attackers’ modus operandi. VirusTotal provides multiple data points where MITRE’s Tactics and Techniques are dynamically extracted from samples when detonated in our sandboxes.
In particular, samples’ MITRE mapping can be found under the BEHAVIOR tab of a file’s report. This data is searchable in VirusTotal Intelligence (VTI) with the help of a set of specific file search modifiers.
In this article, we’ll illustrate how security analysts can leverage MITRE for malware detection and behavior-based hunting for ransomware and keylogger samples.

Hunting for Ransomware

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

Common TTPs of modern ransomware groups by Kaspersky

In VT Intelligence we can use 2 search modifiers to query files behavior mapped to MITRE ATT&CK:
In addition to the “attack_tactic” and “attack_technique” modifiers, VirusTotal provides extra modifiers listed on the Appendix I – Behavior search modifiers for procedures-based queries at the end of this post.
Let’s do an example. We want to find samples given a set of ransomware-related techniques combined with the “behavior:CryptEncrypt” operating system API call (check Appendix I for details). Additionally, we specify the entity we are interested in (files) and the first submission date (fs) to filter out files submitted before 2024-01-01.
The resulting query is as follows:
entity:file attack_technique:T1490 and attack_technique:T1083 and attack_technique: T1135 behavior:CryptEncrypt fs:2024-01-01+

Let’s analyze in more detail one of the query’s resulting files (35619594724871138875db462eda6cf24f2a462e1f812ff27d79131576cd73ab).
According to the community, the file belongs to a BlackHunt Ransomware campaign threat that compromised multiple companies in Paraguay.
Its BEHAVIOR report tab, provides details on the techniques detected during sample’s detonation:
  • T1490 (Inhibit System Recovery), the sample deletes the shadow copies (as highlighted in the Capabilities section below) and it also modifies Windows boot settings via bcdedit.
  • T1083 and T1135: The sample runs discovery processes to get system local files and directories, and also network shares.
  • The encryption process is visible by the CryptEncrypt operating system API call, functionality provided by the Advapi32.dll, and visible under the file’s DETAILS tab.

Hunting for Keyloggers

Keyloggers are a particular form of Spyware designed for stealing user data, that commonly share some MITRE Tactics, including collecting data and/or discovering data for later exfiltration and/or Command and Control communication.
For our VTI query we will specify the T1056.001: Input Capture: Keylogging sub-technique of the Collection tactic, which identifies keystrokes interception. Additionally, we use the first submitted time condition (fs) and both Command and Control or Exfiltration tactics (attack_tactic), since we are not really interested in restricting the way the data gets outside of the victim environment.
attack_technique:T1056.001 (attack_tactic:TA0011 OR attack_tactic:TA0010) fs:2024-02-15+

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

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





Conclusions

In this post we have seen using a couple of examples how present the MITRE framework is on VirusTotal and how it can be used to search for files with a particular TTP-based behavior using VirusTotal Intelligence searches. MITRE-related data is based on behavior detected during samples’ sandbox detonation.
We have additionally created an Appendix I (below) detailing some of the most interesting behavior-search modifiers you can use in your queries. This fits particularly well with other TTP-based modifiers, allowing you to refine results by adding particular technical characteristics specific for the malware under analysis.
We hope you found this post interesting and useful. For suggestions or feedback please feel free to reach out here, we will be happy to hear from you.
Happy hunting!

Appendix I – Behavior search modifiers

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

Continue reading Following MITRE’s footsteps in analyzing malware behavior→

The definitive VirusTotal’s admin guide

Posted on by

Check out our Walkthrough guide for VirusTotal group administrators!
VirusTotal administrators’ tasks are key for the good health of the groups they manage. Unfortunately it is not always clear the best way to do this or that task. But we heard our beloved community, and we created the definitive guide for everything a VirusTotal group administrator might need to know, including use cases, examples, where to find everything in the GUI and how to automate tasks using the API, including scripts ready to use in our GitHub repository.

Introducing the walkthrough guide for VirusTotal group admins

General notions

The guide begins with general notions and a quick overview of the VT Enterprise group web interface.

In particular, we need to know where to retrieve IDs for groups, users and service accounts, as they are required for any VirusTotal API v3 interaction. The administrator’s API key is required for VirusTotal API authentication/authorization.
  • Group ID: on the VT Enterprise group portal, the GROUP PREFERENCES section shows your Group ID.
  • User ID: on the VT Enterprise group portal, the Group members section lists the group’s users. By clicking on any of them, you automatically pivot to USER PROFILE where the user’s ID is shown near the user’s avatar.
  • Service account ID: on the VT Enterprise group portal, the Service accounts section lists the group’s service accounts by their IDs.
  • VirusTotal user API key: there are 2 ways of getting your API key from the landing page as in the below image.

Use cases

The second part of the guide describes every action a VirusTotal admin can perform, splitted by sections for easier reference:
  • Group members management
    In this section you will find how to manage users and service accounts by adding or removing them to/from the group, how to download a list of members and how to manage users privileges.
  • Group management
    This section focuses on group-level configurations that may also affect users, such as active session timings and Single Sign On (SSO) security features.
  • Consumption
    At this section you will find information about one of the most requested topics, which is quota and consumption.
Each use case has a descriptive title to easily identify what you are looking for, the Web interface section describing use cases in the GUI, and details on VirusTotal API v3 endpoints that can be used to automate the use case, including API examples linking to our GitHub repository for most cases.

Enforcing security – 2FA

As an example, and focusing on a security perspective, let’s say that we want to obtain all users in our group without 2FA enabled.
In the VT Enterprise group web interface you will find the USERS tab, and under the Group members section there is a Filter by dropdown with the View only users without 2FA option:
The same can be automated with the API with a simple script.
“””
**DISCLAIMER:**
  Please note that this code is for educational purposes only.
  It is not intended to be run directly in production.
  This is provided on a best effort basis.
  Please make sure the code you run does what you expect it to do.
“””

import requests

def get_users_without_2fa(apikey, group_id):
  “””
  Getting users objects related to a group by group ID, filtering by 2fa_enabled = false.
    Requested users attributes: first_name,last_name,email.
  VT API endpoint reference: https://developers.virustotal.com/reference/groups-relationships
  “””

  users = []
  url = f”https://www.virustotal.com/api/v3/groups/{group_id}/users?attributes=first_name,last_name,email&filter=2fa_enabled:false”
  headers = {“accept”: “application/json”, “x-apikey”: apikey}
  while url:
    res = requests.get(url, headers=headers)
    res.raise_for_status()
    res = res.json()
    for el in res[“data”]:
      users.append(
        f”username:{el[‘id’]},”
        f”first_name:{el[‘attributes’].get(‘first_name’,”)},”
        f”last_name:{el[‘attributes’].get(‘last_name’,”)},”
        f”email:{el[‘attributes’].get(’email’,”)}”
      )
    url = res.get(“links”, {}).get(“next”, None)
  return users

For this we used the /v3/groups/{group_id}/{relationship} endpoint, which refers to ‘users’ relationship, filtering by “2fa_enabled” as “false” and requesting “first_name”, “last_name” and “email” attributes for each of them.
Check it out on our GitHub repository!

Enforcing security – privileges are granted where required

It is very important to monitor that admin privileges are only granted to users who require them to perform their jobs. Tracking admin privileges on a regular basis is a very healthy task.
When using the VirusTotal web portal, the only difference to the previous example is the filter to be applied, which in this case is View only admin users.
This task can be automated. The following Python script compares the users with admin privileges against a given list of administrators and reports any anomalies:
“””
**DISCLAIMER:**
  Please note that this code is for educational purposes only.
  It is not intended to be run directly in production.
  This is provided on a best effort basis.
  Please make sure the code you run does what you expect it to do.
“””

import requests

def get_possible_unauthorized_admins(apikey, group_id, authorized_admins):
  “””
  Getting users objects (administrators) related to a group by group ID.
    Requested users attributes: first_name,last_name,email.
  VT API endpoint reference: https://docs.virustotal.com/reference/get-group-administrators
  “””

  unauthorized_admins = []
  url = f”https://www.virustotal.com/api/v3/groups/{group_id}/administrators?attributes=first_name,last_name,email”
  headers = {“accept”: “application/json”, “x-apikey”: apikey}
  while url:
    res = requests.get(url, headers=headers)
    res.raise_for_status()
    res = res.json()
    for el in res[“data”]:
      if el[“id”] not in authorized_admins:
        unauthorized_admins.append(
          f”username: {el[‘id’]}, “
          f”first_name: {el[‘attributes’].get(‘first_name’, ”)}, “
          f”last_name: {el[‘attributes’].get(‘last_name’, ”)}, “
          f”email: {el[‘attributes’].get(’email’, ”)}”
        )
    url = res.get(“links”, {}).get(“next”, None)
  return unauthorized_admins

For this we have used /v3/groups/{group_id}/administrators endpoint referring to ‘administrators’ relationship where requested “first_name”, “last_name” and “email” attributes for each of them. Additionally, the ‘authorized_admins’ list is used to filter out authorized admins.
Check it out on our GitHub repository!

Wrapping up

With these new resources, we aim to assist VirusTotal group administrators in their day-to-day duties. The documentation is extensive enough to cover everything they can do on the web interface and provides ways of automation to get the same data as from the web portal, but through raw Python scripts when possible.
We hope you find this as useful as we do. If you have any questions, feedback or new use cases we can assist you with, please do not hesitate to contact us.
Happy management!

Continue reading The definitive VirusTotal’s admin guide→

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→

Actionable Threat Intel (II) – IoC Stream

Posted on by
Access to RELEVANT threat data is a recurring challenge highlighted by SOCs and CTI teams, at VirusTotal we want to help you understand your unique threat landscape. Indeed, tracking campaigns and threat actors in VirusTotal’s Threat Landscape module should be a smooth and simple experience. We are excited to announce that VirusTotal users can now subscribe to any Threat Actor or IoC Collection of their interest and get notified every time a new indicator of compromise (IoC) is added to them, acting as a fully tailored stream of activity relevant to their orgs.
This helps us in making sure we don’t miss any relevant activity and allows us to proactively protect ourselves. For example, is a given campaign that targeted us in the past evolving to leverage a new set of exploits spreading through attached documents? Let’s use this new intel to make sure our patches and detection capabilities are in place before we get hit.
Let’s see how we can build out our threat landscape.

Subscribing to threat cards to follow relevant activity

(1) The Threat Landscape module collections and actor listings are equipped with an Actions dropdown option that allows users to subscribe to (or unsubscribe from) selected items. In other words, to follow adversaries, toolkit and campaigns that are particularly interesting for them.
(2) Additionally, you will find a bell icon on the top right corner of both collections and actor cards to subscribe/unsubscribe.
When looking at the full list of collections and threat actors in VT Threat Landscape, subscribed items will be called out with the icon.

Where can I find new activity notifications? Enter IoC Stream

IOC Stream is our brand new centralized notification hub. It aggregates ALL IoCs coming from:
New IoCs from any of these sources will appear in your IoC Stream. Moreover, any new subscription to Threat Actors or Collections will automatically incorporate IoCs added to them in the last 7 days, this gives you a headstart. Note that you can always delete notifications you are not interested in.
IoC Stream provides several options for filtering IoC notifications, such as:
  • The matching date (or date when that IoC was added to the collection/threat actor)
  • The source type (whether the notification is coming from a collection/threat actor subscription or Retrohunt / Livehunt rule)
  • The IoC type (file, URL, domain or IP address)
You can also manage the sources of your notifications by going to the Manage sources section at the top right corner. This view allows you to unsubscribe or disable notification sources, and to quickly pivot to all IoCs coming from that particular source by clicking on the matches number for any source – filtering modifiers will automatically be added to the search bar.
The IoCs Export option allows you to download IOCs in the most popular data formats: JSON, CSV and STIX, so that you can conveniently ingest or match them in 3rd-party technologies.
See it in action!

Automation and programmatic access

VirusTotal is about actionability and operationalization first. There are a few API v3 endpoints that will let you retrieve your IoC Stream notifications and related full-blown reports, allowing you to automate flows into third-party tools or matching against your own events.
As in the UI, you can also filter results combining criteria such as matching date, source type or entity type. Find all documentation here.
Let’s say we want to check all URL notifications from the last 3 days that come from any collection we are subscribed to. The filter would be “date:3d+ entity_type:url source_type:collection” and below is the raw Python code snippet:
import requests
import urllib
from pprint import pprint

filters = ‘date:3d+ entity_type:url source_type:collection’

def get_ioc_stream_notifications(filters):
  url = f’https://www.virustotal.com/api/v3/ioc_stream?filter={urllib.parse.quote(filters)}’
  headers = {
    ‘accept’: ‘application/json’,
    ‘X-Apikey’: API_KEY
  }

  res = requests.get(url, headers=headers)
  res.raise_for_status()
  return res.json()

pprint(get_ioc_stream_notifications(filters))

We also have a Python module that can be used to fetch the same information, or to regularly track what network infrastructure (URLs, domains and IP addresses) a threat actor of our interest is using (Kimsuky in this example):
import requests
from pprint import pprint

filters = ‘date:7d+ (entity_type:url OR entity_type:domain OR entity_type:ip_address) source_type:threat_actor “Kimsuky”‘
url = ‘/ioc_stream’

def get_ioc_stream_notifications(url,filters):
  try:
    vt_client = vt.Client(API_KEY)
    result = vt_client.get_data(url,params={‘filter’:filters})
    vt_client.close()
    return result
  except vt.error.APIError as e:
    print(e)
    return None

pprint(get_ioc_stream_notifications(url,filters))

Another option to interact with your IoC Stream is via our vt-cli. For example, we could check all files notified daily by both our LiveHunt and RetroHunt rules by using the filter “date:1d+ entity_type:file origin:hunting“, where “origin:hunting” refers to both notification sources (source_type:retrohunt_job or source_type:hunting_ruleset).
~$ vt iocstream list -f “date:1d+ entity_type:file origin:hunting”

Wrapping up

Subscriptions to collections and threat actors make it easier for users to stay focused on tailored/relevant intel, and IoC Stream serves as a single repository to centralise all your notifications, including any hunting rules you use.
This has a number of advantages, including having a better visibility of adversary activity by having all notifications in a single place, plus the ability to filter it out as needed before we export it for ingestion in 3rd-party tools. Additionally, the IoC Stream provides handy analysis capabilities, such as checking Commonalities for a set of samples or direct connection with VT Diff to generate YARA rules. This saves time and democratizes security expertise, whereby less experienced team members can act as advanced threat hunters.
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.
Happy hunting!

Continue reading Actionable Threat Intel (II) – IoC Stream→

Upgrading from API v2 to v3: What You Need to Know

Posted on by

The VirusTotal API is a versatile and powerful tool that can be utilized in so many ways. Although it is commonly used for threat intelligence enrichment and threat analysis, the potential uses are virtually limitless. The latest version, VirusTotal API v3, is continuously updated with new features to enhance its capabilities with every new release.

With this post we want to help you understand its potential and, in case you are a VT API veteran, help you migrate from API v2 to API v3 to unleash its full potential.

To simplify the process of adopting and migrating to VirusTotal API v3, we have updated the official documentation with a specific section dedicated to this purpose. We also created a GitHub repository with working examples. In the next few weeks we will host a webinar showing you cool use cases you can implement with VT API, so stay tuned!

Why use VT API v3?

The migration guide describes in detail most API v3 benefits, including:

  • Endpoints for all VirusTotal products and scanners. VT users can access all of VirusTotal’s tools through a single API, simplifying the integration process.
  • User and group management helping administrators to automate managing access and accounts, as well as tracking usage across your team.
  • Extra relevant information for file, URL, domain and IP reports. VT API v3 provides additional information for all file, URL, domain and IP reports, including metadata and context.
  • REST-based, with predictable, resource-oriented URLs. VirusTotal API v3 uses a RESTful architecture, following a standard set of design principles for building web services with HTTP methods accessed through predictable, resource-oriented URLs, making it easier to use and integrate with other tools.
  • MITRE related tactics and techniques seen in file behavior. API v3 provides information on TTPs used by malware samples, as defined by the MITRE ATT&CK framework. This helps understanding the potential impact of a sample and how to respond to any threats.
  • More extensive documentation and code examples based on the Python module. V3 has more extensive documentation and code examples which make it easier for users to get started with the API and integrate it into their workflows.

API v2-v3 Migration Guide

Our migration guide outlines the differences between VT API v2 and v3, touching on aspects such as data formats, available integration with other VT products and features, and what are the API Scripts and client libraries available for each one.

It also details the differences between v2 and v3 endpoints, including differences in requests and responses. The table below summarizes endpoint correspondence between v2 and v3:

Description VT API v2 VT API v3
Submitting samples, getting file reports, and rescanning files
Submit file (<= 32MB) /file/scan /files
Submit file(> 32MB) /file/scan/upload_url and /file/scan /files/upload_url and /files
Get file report /file/report (allinfo parameter) /files/{id}
Rescan file /file/rescan /files/{id}/analyse
Getting file behaviour reports and downloading network traffic files
Get file behavior report /file/behaviour /files/{id}/behaviours and /file_behaviours/{sandbox_id}/html
Download PCAP /file/network-traffic /file_behaviours/{sandbox_id}/pcap
Scanning URLs, getting reports for URLs, domains, and IP addresses
Scan URL /url/scan /urls
Get URL report /url/report /urls/{id}
Get domain report /domain/report /domains/{domain}
Get IP address report /ip-address/report /ip_addresses/{ip}
Feeds for enrichment
Get file feed /file/feed /feeds/files/{time} and /feeds/files/hourly/{time}
Getting URL feed /url/feed /feeds/urls/{time} and /feeds/urls/hourly/{time}
Getting file clusters and downloading files
Get file clusters /file/clusters /stats/vhash_clusters
Download file /file/download /files/{id}/download
VT Intelligence via API
Advanced search /file/search (only for files) /intelligence/search

One more thing

In addition to the examples provided in the GitHub repository, the official API documentation offers additional cool features.

First of all, it provides code examples for every endpoint! The 3 dots button shows a list of available programming languages you can get examples. Select any of them and the code is automatically updated to that language.

Additionally, the ‘Try It!’ button executes the request for you and shows the JSON result in the ‘RESPONSE’ section under the code snippet.

Conclusions

API v2 served VirusTotal users well for many years, but it lacks some features required to any modern professional API. Don’t panic, you can still continue using API v2 if you really have to. We want to make sure you understand the advantages of using v3 and provide you with everything needed to make v2 to v3 transition as smooth as possible.

Probably the main advantage is that API v3 is VirusTotal’s standard, and some day in the future we will have to sunset v2. Nevertheless, in v3 we make sure that every service and feature has its corresponding endpoint. That includes many functionalities not available in v2, like user and group management, threat landscape, Graphs or Private Scanning, among others. Moreover, API v3 provides extended data on VT reports for any observable!

We hope the extensive documentation and code examples will help you master API v3 very soon! If you have any suggestions or just want to share feedback, please feel free to reach out here.

Happy hunting! Continue reading Upgrading from API v2 to v3: What You Need to Know→

Is malware abusing your infrastructure? Find out with VirusTotal!

Posted on by

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:

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:

The contacted_ip search modifier also allows specifying IP address ranges:

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”

 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:
  // 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!→