Category Archives: Livehunt

COM Objects Hijacking

Posted on by
The COM Hijacking technique is often utilized by threat actors and various malware families to achieve both persistence and privilege escalation in target systems. It relies on manipulating Component Object Model (COM), exploiting the core architecture of Windows that enables communication between software components, by adding a new value on a specific registry key related to the COM object itself.
We studied the usage of this technique by different malware samples to pinpoint the most exploited COM objects in 2023.

Abused COM Objects

We identified the most abused COM objects by samples using MITRE’s T1546.015 technique during sandbox execution. In addition to the most abused ones, we will also highlight other abused COM objects that we found interesting.
The chart below shows the distribution of how many samples abused different COM objects for persistence:

You can find the most used COM / CLSIDs listed in the Appendix.

Berbew

One of the main malware families we have observed abusing COM for persistence is Padodor/Berbew. This Trojan primarily focuses on stealing credentials and exfiltrating them to remote hosts controlled by attackers. The main COM objects abused by this family are as follows:

  • {79ECA078-17FF-726B-E811-213280E5C831}

  • {79FEACFF-FFCE-815E-A900-316290B5B738}

  • {79FAA099-1BAE-816E-D711-115290CEE717}

The corresponding registry entries point to the malicious DLL. However, multiple samples of this family use a second registry key for persistence, which points to this previous CLSID we described, as in the following example :

In this case, the registry key …CLSID\{79ECA078-17FF-726B-E811-213280E5C831}\InProcServer32\(Default) points to the malicious DLL C:\Windows\SysWow64\Iimgdcia.dll. A second registry entry …Wow6432Node\Microsoft\Windows\CurrentVersion\ShellServiceObjectDelayLoad\Web Event Logger points to the previous CLSID {79ECA078-17FF-726B-E811-213280E5C831} which loads the malicious DLL.
The ShellServiceObjectDelayLoad registry entry (part of ShellServiceObjectDelayLoad), combined with the Web Event Logger subkey used here by Berbew, has frequently been utilized to initiate the loading of the genuine webcheck.dll. This DLL was tasked with monitoring websites within the Internet Explorer application.
The previously utilized CLSID by WebCheck registry key was {E6FB5E20-DE35-11CF-9C87-00AA005127ED} However, in certain instances today the CLSID {08165EA0-E946-11CF-9C87-00AA005127ED} is used. Both are responsible for loading the webcheck.dll DLL and are abused by malware samples.

RATs

The CLSID {89565275-A714-4a43-912E-978B935EDCCC} seems to be extensively used by various RATs . This CLSID has primarily been associated with families like RemcosRAT and AsyncRAT in our observations. However, we’ve also encountered instances where BitRAT samples have used it. Researchers at Cisco Talos found this CLSID activity associated with the SugarGh0st RAT malware.
In the majority of cases, the DLL used for persistence with this CLSID is dynwrapx.dll. This DLL was found in the wild in a GitHub repository, currently unavailable, however the DLL originates from a project named DynamicWrapperX (first seen in VirusTotal in 2010). It executes shellcode to inject the RAT into a process.
A similar case is CLSID {26037A0E-7CBD-4FFF-9C63-56F2D0770214}. The associated DLL for persistence is dbggame.dll. First uploaded to VirusTotal in 2012, this DLL is deployed by various types of malware, including ransomware such as XiaoBa.

RATs w/ vulnerabilities

To finish with RATs that use this technique, from late December 2023 to February 2024, there were various incidents linked to the CVE-2024-21412 vulnerability uncovered by the Trend Micro Zero Day Initiative team (ZDI). During these events, active campaigns were distributing the Darkme RAT. Throughout the infection process, a primary goal was to evade Microsoft Defender SmartScreen and introduce victims to the DarkMe malware.
The TrendMicro analysis highlights that the Darkme RAT sample utilizes the CLSID {74A94F46-4FC5-4426-857B-FCE9D9286279} to carry out the final load of the RAT. Yet, we’ve noted the utilization of other CLSIDs for persistence, including {D4D4D7B7-1774-4FE5-ABA8-4CC0B99452B4} in this sample.
Furthermore, to guarantee the DLL’s execution, they generate a registry key employing Autorun keys. This key’s objective is to initiate the CLSID using rundll32.exe and /sta parameter, which is used to load a COM object, in this case, the previous malicious COM object created. 
EventID:13 
EventType:SetValue
Details:%windir%\SysWOW64\rundll32.exe /sta {D4D4D7B7-1774-4FE5-ABA8-4CC0B99452B4} "USB_Module"
TargetObject:HKU\S-1-5-21-575823232-3065301323-1442773979-1000\Software\Microsoft\Windows\CurrentVersion\Run\RunDllModule

Why use one when you can use many?

Some samples (like this Sality one) use multiple CLSIDs:

  • {EBEB87A6-E151-4054-AB45-A6E094C5334B}

  • {57477331-126E-4FC8-B430-1C6143484AA9}

  • {241D7F03-9232-4024-8373-149860BE27C0}

  • {C07DB6A3-34FC-4084-BE2E-76BB9203B049}

The sample drops two different DLLs during execution, three of the registry keys point to one of them, the remaining one to the other. The sample also turns off the Windows firewall and UAC to carry out additional actions while infecting the system.

The Allaple worm family deploys multiple COM objects pointing to the malicious DLL during execution, like in this example:

Adware

Citrio, an adware web browser designed by Catalina Group, uses in its more recent versions a COM object for persistence with CLSID {F4CBF20B-F634-4095-B64A-2EBCDD9E560E}. It drops several harmful DLLs, one masquerades as Google Update (goopdate.dll), also observed as psuser.dll, that possesses the capability to establish services on the system along using a COM object for persistence.

Common folders used to store the payloads

Most malicious DLLs we saw so far are typically stored in the C:\Users\<user>\AppData\Roaming\ directory. It’s also common to create subfolders within this directory, the most frequently found include:

  • \qmacro

  • \mymacro

  • \MacroCommerce

  • \Plugin

  • \Microsoft

In addition to these, we also found the following folders being frequently used to hide malicious DLLs:

  • The C:\Windows\SysWow64 is a folder found in 64-bit versions of Windows, containing legitimate 32-bit system files and
    libraries, and is oftenly used to conceal malicious DLLs. Its prevalence makes it an attractive
    hiding place, complicating detection efforts. However, permissions are required to create files in
    it.

  • The
    C:\Program Files (x86)
    folder is another legitimate directory used to store malicious COM hijacking payloads. Similar to
    \AppData\Roaming, in this case we have observed that the malicious DLLs are stored under specific
    subfolders, such as “\Google”, “\Mozilla Firefox”, “\Microsoft”, “\Common Files” or “\Internet
    Download Manager”.

  • C:\Users\<user>\AppData\Local
    is another folder used for storing these payloads, including the “\Temp”, “\Microsoft” and “\Google”
    subfolders.

Detection

In order to detect unusual modifications to registry COM objects, there are a couple of crowdsourced Sigma rules to identify this behavior.

These rules will detect uncommon registry modifications related to COM objects. You can use the following queries to retrieve samples triggered by the previous rules, respectively: VTI query for sigma1 and VTI query for sigma2.
You can also identify this behavior using Livehunt rules that target the creation of registry keys utilized for this purpose, for instance with the vt.behaviour.registry_keys_set modifier. 
import "vt"

rule CLSID_COM_Hijacking:  {
  meta:
    target_entity = "file"
    hash = "a19472bd5dd89a6bd725c94c89469f12cdbfee3b0f19035a07374a005b57b5e0"
    author = "@Joseliyo_Jstnk"
    mitre_technique = "T1546.015"
    mitre_tactic = "TA0003"

  condition:
    vt.metadata.new_file and vt.metadata.analysis_stats.malicious >= 5 and 
    for any vt_behaviour_registry_keys_set in vt.behaviour.registry_keys_set: (
      vt_behaviour_registry_keys_set.key matches /\\CLSID\\{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}\}\\InProcServer32\\\(Default\)/
    )  
}
The rule above might generate some noise, so we suggest considering polishing it by excluding certain common families like Berbew, which as mentioned, heavily relies on this technique: 
and not 
    (
        for any engine, signature in vt.metadata.signatures : (  
        signature icontains "berbew"  
        )  
    )
You can also use the paths listed in Appendix to identify suspicious samples using them.
A final idea is including interesting existing Sigma rules into our Livehunt. Given that these rules already cover the targeted registry keys, we don’t need to use vt.behaviour.registry_keys_set in our condition. 
import "vt"

rule CLSID_COM_Hijacking:  {
  meta:
    target_entity = "file"
    hash = "a19472bd5dd89a6bd725c94c89469f12cdbfee3b0f19035a07374a005b57b5e0"
    author = "@Joseliyo_Jstnk"
    sigma_authors = "Maxime Thiebaut (@0xThiebaut), oscd.community, Cédric Hien"
    mitre_technique = "T1546.015"
    mitre_tactic = "TA0003"

  condition:
    vt.metadata.new_file and vt.metadata.analysis_stats.malicious >= 5 and 
    for any vt_behaviour_sigma_analysis_results in vt.behaviour.sigma_analysis_results: (
      vt_behaviour_sigma_analysis_results.rule_id == "7f5d257abc981b5eddb52d4a9a02fb66201226935cf3d39177c8a81c3a3e8dd4"
    )
}

Wrapping up

The T1546.015 – Event Triggered Execution: Component Object Model Hijacking is just one of several techniques employed for persistence. Leveraging COM objects for this task is frequently straightforward for threat actors. The analysis of how malware abuses this technique helps us get a better understanding in how to identify different families and develop protection methods. Although the technique is not the most popular for persistence (that would be T1547.001 – Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder), it is widely abused by many malware families.

Identifying some of the most abused CLSIDs can help us generate detection rules that identify possible malware abuses in our infrastructure. It can also serve as a good guide for prevalence in order to detect any anomalies for new suspicious activity.
The use of VirusTotal sandbox reports provides a very powerful tool to translate TTPs into actionable queries and monitoring. In this example we used it to better understand how attackers use COM objects, but could be used for any techniques employed by different threat actors.
We hope you join our fan club of Sigma and VirusTotal, and as always we are happy to hear your feedback.

APPENDIX

Abused CLSIDs

Next, you’ll find a list of the main CLSIDs described in the blog, along with a chart to show which ones were used the most.

CLSID
– COM Objects

79FAA099-1BAE-816E-D711-115290CEE717

EBEB87A6-E151-4054-AB45-A6E094C5334B

241D7F03-9232-4024-8373-149860BE27C0

C07DB6A3-34FC-4084-BE2E-76BB9203B049

79ECA078-17FF-726B-E811-213280E5C831

22C6C651-F6EA-46BE-BC83-54E83314C67F

F4CBF20B-F634-4095-B64A-2EBCDD9E560E

57477331-126E-4FC8-B430-1C6143484AA9

C73F6F30-97A0-4AD1-A08F-540D4E9BC7B9

89565275-A714-4a43-912E-978B935EDCCC

26037A0E-7CBD-4FFF-9C63-56F2D0770214

16426152-126E-4FC8-B430-1C6143484AA9

33414471-126E-4FC8-B430-1C6143484AA9

23716116-126E-4FC8-B430-1C6143484AA9

D4D4D7B7-1774-4FE5-ABA8-4CC0B99452B4

79FEACFF-FFCE-815E-A900-316290B5B738

74A94F46-4FC5-4426-857B-FCE9D9286279

Common paths

Below you will find a list with some of the most common paths used during the creation of the COM objects for persistence. The table contains the ‘parent’ paths as well, while the chart includes only the ‘subpaths’.

Common
paths used during COM object persistence

C:\Users\<user>\AppData\Roaming

C:\Users\<user>\AppData\Roaming\qmacro

C:\Users\<user>\AppData\Roaming\mymacro

C:\Users\<user>\AppData\Roaming\MacroCommerce

C:\Users\<user>\AppData\Roaming\Plugin

C:\Users\<user>\AppData\Roaming\Microsoft

C:\Windows\SysWow64

C:\Program
Files (x86)

C:\Program
Files (x86)\Google

C:\Program
Files (x86)\Mozilla Firefox

C:\Program
Files (x86)\Microsoft

C:\Program
Files (x86)\Common Files

C:\Program
Files (x86)\Internet Download Manager

C:\Users\<user>\AppData\Local

C:\Users\<user>\AppData\Local\Temp

C:\Users\<user>\AppData\Local\Microsoft

C:\Users\<user>\AppData\Local\Google

C:\Windows\Temp

Continue reading COM Objects Hijacking→

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→