Posts on Security, Cloud, DevOps, Citrix, VMware and others.
Words and views are my own and do not reflect on my companies views.
Disclaimer: some of the links on this site are affiliate links, if you click on them and make a purchase, I make a commission.
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has published the results of two red team assessments it conducted simultaneously against two critical infrastructure organizations, using what it described as similar tradecraft while recording sharply different defensive outcomes.
Both organizations were fully compromised at the domain level, and in both, the red team also reached sensitive business systems (SBSs) and cloud resources.
The advisory, tracked as AA26-237A and titled "A Tale of Two SOCs," was released on August 25, 2026. CISA identified the first target only as a Government Services and Facilities Sector organization, referred to as Organization A, and the second as a Water and Wastewater Systems Sector entity, referred to as Organization B.
"CISA conducted two simultaneous red team assessments using similar tradecraft but observed different defensive responses," the agency said in the advisory.
Against Organization A, the red team gained initial access after identifying a web application with default credentials for several built-in accounts, which allowed it to send phishing emails from an internal address and land on four workstations.
It then escalated privileges by abusing a default Machine Account Quota alongside a misconfigured Active Directory Certificate Services (AD CS) template, the same class of certificate-template abuse behind a recently disclosed domain-takeover exploit called Certighost.
The team went on to access three sensitive business systems using credentials stored in cleartext, including decrypted database configuration files and static Amazon Web Services (AWS) access keys set never to expire.
In the cloud, it stole a Primary Refresh Token and abused Entra ID applications carrying elevated permissions to read the security team's email and check whether defenders were aware of the activity.
Organization A did not detect any of it. CISA said thousands of false-positive alerts from normal business operations, many rated at higher severity, obscured the alerts the red team generated, and that the organization ran multiple security operations centers (SOCs) and endpoint tools with no shared visibility between them.
Analysts also lacked escalation procedures and had limited authority to act, and a real alert tied to red team activity on a System Center Configuration Manager (SCCM) server was dismissed as a false positive after defenders could not identify the system's owner.
CISA flagged the following weaknesses as the main enablers of the compromise -
Machine Account Quota left at the default, letting any domain user add machine accounts.
AD CS certificate templates were misconfigured, allowing certificate requests for any user (ESC1).
Cleartext credentials for service and database accounts stored on reachable systems.
Static cloud access keys set never to expire, with no token revocation in place.
Over-permissioned applications in Entra ID able to read mail across all users.
Organization B, running the same style of attack against it, told a different story. Its SOC detected the initial phishing payloads as each executed and isolated the affected workstations within 2 to 20 minutes, cutting off command-and-control (C2) communications before the intrusion could spread.
Because that foothold was severed, CISA's trusted agents at the organization executed a red team payload on a designated non-privileged host to replicate the access the team would otherwise have obtained, shifting the engagement to an assume-breach model.
From there, the team found the same underlying problems, including cleartext credentials for a domain service account in an SCCM configuration file that carried rights over a domain controller, which it used to run a DCSync attack and retrieve the krbtgt secret.
The team also reached a bastion host in Organization B's operational technology (OT) demilitarized zone, but the host blocked outbound internet access, so no C2 channel was established, and the team did not enter the OT systems themselves.
CISA attributed the gap between the two outcomes to the people and processes operating the tools, rather than the tools themselves.
"Detection tools are only as effective as the people, processes, and procedures supporting them," the agency said.
from The Hacker News https://ift.tt/ZezxJw5
via IFTTT
The SOC we've always known was built around a model that guarantees most of the alert queue will never receive analyst review. There's never time. In a traditional SOC, the typical progression follows a well-known pattern: an alert arrives; a detection engine assigns a severity score. The issue then waits for a human to decide if it should escalate to an investigation.
Given the volume of network telemetry in the security stack, the queue is an unavoidable result of humans as the investigative layer. Long alert queues also force security teams to decide which signals to analyze before they even know what those signals represent.
Threat hunting has always addressed security questions via an alternative approach: start with a hypothesis about attacker behavior, search the available evidence, then prove or disprove it. The sequence is powerful, but it hits the same wall: human capacity.
The SOCs now being built are predicated on agentic AI and can conduct investigations faster — in seconds or minutes rather than hours. But increased speed isn't the only shift. The sequence of an investigation also gets an upgrade. Because agents quickly analyze telemetry at volume, they can invert the alert queue model: investigate first, then escalate based on evidence.
Hypothesis-driven investigation, facilitated by AI agents, is an emerging approach to improving detections and reducing the attack surface. A SOC driven by hypotheses (rather than queues) is scalable when it's inexpensive enough to run continuously, moving humans from conducting the investigation to judging its output.
How the inversion works
Agents can investigate as soon as a signal appears: validate the detection, examine the underlying network activity, profile the affected entity, consider historical behavior, correlate related activity, and gather additional evidence from the data.
The investigation no longer must compete for analyst attention. Agents can work asynchronously, pursue multiple investigations in parallel, and return evidence-backed results.
Agentic triage workflows use structured investigative playbooks to examine deep network telemetry and produce verdicts supported by data. This workflow doesn’t only result in faster triage; it means that more signals can be investigated without consuming human resources. The agent removes the manual investigation step, using a broader set of network data before a case reaches an analyst.
Threat hunting at machine scale
The more interesting possibility is what happens beforeand beyond the alert.
Threat hunting doesn’t have to start with “what was detected?” It can start with “what is the attacker doing?”
Consider these hypotheses. An attacker may be:
Using an unusual protocol for command and control
Moving laterally through remote admin services
Staging data for exfiltration
Communicating with systems that have no legitimate reason to communicate
Using a technique designed to stay below existing detection thresholds
Each implies observable behavior. Network traffic provides evidence that can support or contradict the hypothesis, and establish whether a detected signal has real significance.
AI-powered hypothesis-driven hunting doesn’t replace detection; it uses network evidence to test and extend verifiable detections. Network telemetry becomes the foundation of the investigation.
This is what threat hunting looks like when agents can run many investigations in parallel.
Agents can investigate before certainty exists
The real advantage of agentic investigation is that an agent doesn’t need certainty before it starts.
Agentic investigation can pursue a weak signal, test a hypothesis, and stop when the evidence doesn’t support it. The business advantage: it can adjust its hypothesis and repeat the cycle, faster than any human analyst.
An agent can autonomously ask:
What looks unusual?
Which relationships warrant examination?
What evidence supports the hypothesis?
What evidence contradicts it?
What additional evidence would reduce uncertainty?
When has the evidence earned human attention?
The result is an added investigative layer between network activity, detection, and confirmed threats. Most investigations can end without human involvement; the cases that warrant escalation arrive with evidence and context attached.
A higher bar for human time
An AI SOC model looks different from a human-driven SOC. Instead of:
Telemetry → signal → hypothesis → machine investigation → evidence → human judgment
Within these new models, the outcome is more investigative coverage without a proportional increase in analyst capacity:
Lower cost per investigation: agents handle evidence collection and analysis
Greater threat coverage: the SOC can investigate more potential attack paths
Faster risk reduction: meaningful threats are surfaced sooner
Higher-value analyst time: humans focus on decisions, response, and complex cases
More value from telemetry: security data becomes actionable evidence
Replace the queue with continuous investigation
In AI SOCs, investigation no longer needs to start at the queue. It can start at the signal. Agents will use telemetry to validate alerts, test hypotheses, and follow suspicious activity as it unfolds. Human engagement can be reserved for when an agent returns a case backed by network evidence. In this future, the SOC operates continuous, asynchronous investigations that are evidence-driven and unconstrained by the limits of the alert queue or a human analyst’s time-constrained view.
About Corelight
Corelight provides the network evidence security teams need to detect sophisticated AI-driven threats, agentically investigate incidents, and respond with confidence. Our Open NDR Platform combines high-fidelity network telemetry, multi-layered detection, and AI-powered investigation across hybrid, cloud, and on-premises environments. Learn more about Corelight’s agentic triage here.
Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.
from The Hacker News https://ift.tt/q2Xp6MU
via IFTTT
OpenAI on Tuesday said it banned a cluster of Russian ChatGPT accounts that used VPNs to bypass access restrictions and run an influence operation, which relied on its artificial intelligence (AI) tool to generate social media posts and comments that were shared on Substack, Telegram, X, Facebook and LinkedIn.
The accounts "were being used to promote the International Burke Institute (IBI), a self-described 'expert community' based in Israel," the company said.
"What began as an investigation into AI-generated social media posts led us to a much broader influence operation, built around a website containing copied and misattributed academic work, a 'sovereignty' index that cast Russia in a favourable light, and efforts to disguise the operators' Russian origins."
The campaign is assessed to have reached "relatively small audiences," with Telegram channels attracting more users and amassing about 10-20,000 followers each. The majority of the generated content was in English and the operators instructed ChatGPT to conceal any linguistic clues that could allude to their Russian provenance.
The IBI brand is associated with a website ("ibi[.]institute") that was registered in February 2025. It claims to be a community of leading experts from across the world in matters of economics, politics, sociology and international relations.
There is no evidence that articles published on the site were created using ChatGPT. However, many of them seem to have been copied from academic writings, in some cases with false attribution, while others were seemingly drafted by a Slavic speaker and then machine translated to English.
What's more, OpenAI said the covert campaign is distinct from already documented Russia-linked influence operations, its notable aspect being the creation of a sovereignty index that was promoted by the so-called think tank to project Russia favorably and criticize Western countries.
The website explains the Sovereignty Index, also called the Burke Index, is calculated by taking into account seven indicators that span account political, economic, technological, information, cultural, cognitive, and military sovereignty.
"Each of the 7 areas of sovereignty is calculated using equalization coefficients based on a maximum score of 100 points, which in turn is formed from official national and global data sources and expert assessments," the website states. "The sum of 7 indices in the range of 100-700 forms the final Cumulative Sovereignty Index."
The IBI website also includes reports on different countries and their sovereignty, as measured by the index. The U.S. leads the list with a score of 650.9, followed by China at 649.1, Switzerland at 610.7, and Russia at 601.4. The report on Russia includes the following assessment -
In 2025, Russia is a state with a high level of sovereignty and record military and economic self-sufficiency, a strong scientific and cultural base, but with limited flexibility of the civilian economy and dependence on internal administrative capital.
The main vectors of strengthening are demography, investments in high technologies and gradual liberalization in non-military science and innovation. The sovereignty profile indicates that by 2025 Russia has established a stable and high level of national sovereignty, from financial and military self-sufficiency to digital and cultural control over the internal environment.
The country has become one of the three world powers with full digital and military nuclear sovereignty. Demographic aging, innovation constraints, and selective global integration remain key challenges, requiring a balance between closure and modernization.
The activity extended beyond generating content about IBI, as one of the ChatGPT users used the tool to create a profile picture for a Telegram channel named "American Observer" and repeatedly asked for Russian-language summaries of the channel activity.
"The significance of the operation lies less in the audience it reached, however, than in the infrastructure it had built," OpenAI said. "While the actors only used ChatGPT to produce isolated promotional posts, those posts pointed to an otherwise credible-appearing institution, complete with purported experts, republished academic work and a purported proprietary risk index."
"This illustrates how influence actors can use AI as a supporting tool within a broader effort to manufacture authority, obscure the source of favored narratives, and establish assets that could be scaled over time. It also illustrates how their supporting use of AI can lead to the broader operation being exposed."
from The Hacker News https://ift.tt/YE9Icix
via IFTTT
Selecting a model for your security operations center (SOC) and digital forensics and incident response (DFIR) tasks is important, but selecting the best one is more involved than you might think. SOC tasks rely on a combination of model efficacy, analysis time, cost, and consistency of results.
Cisco Talos tested 66 model and reasoning combinations across offerings from both Anthropic and OpenAI on a log analysis task to see if we could identify a clear winner. Instead, we found a repeatable methodology that organizations can use in their own evaluations.
Reasoning effort was not a universal quality dial. More effort often cost more without improving the result. In some cases, more effort produced lower scores.
Consistency should be a major decision factor. A condition with a strong median can still produce an occasional weak run.
Choosing the best model for any task involves a complex balancing act: compute/reasoning effort vs. effectiveness vs. time vs. cost vs... well, lots of other things. If you are choosing a large language model (LLM) for a security operations center (SOC) or digital forensics and incident response (DFIR) workflow, “Which model scored highest?” is almost certainly not the right question. In fact, it could even have severe negative consequences.
A more useful question might be: Which model and reasoning setting gives me enough investigative quality, at a cost, speed, consistency, and failure rate my workflow can tolerate?
The experiment
Cisco Talos tested 66 model and reasoning combinations (the conditions) from Anthropic and OpenAI on a tool-assisted log-review task. Using only common Unix command-line tools, the reviewers had to decide whether a given dataset was real or synthetically generated. Each reviewer received an identical dataset. The dataset was synthetic, but the reviewers were told that it might be real.
We chose this task because it required many of the same tools and analytic techniques used in typical incident triage and investigation, but unlike those scenarios, could easily create a single numeric score for comparison. The reviewers investigated the logs using their native agent harnesses (i.e., Anthropic models used Claude Code, OpenAI models used Codex), then assigned a synthetic-confidence score from 0 (real) to 100 (synthetic). Higher scores therefore approached the known answer more closely.
Each experimental panel contained four independently prompted reviewer personas:
Threat Hunter
Detection Engineer
Network Forensics Analyst
Host/Endpoint Detection and Response (EDR) Analyst
We ran five rounds per condition. A panel counted only when all four reviewers produced valid reports. We allowed a limited number of retries in the case of guardrail refusals or invalid output formats before discounting a panel. The panel score was the mean of the four persona scores, and the condition score was the median of all its complete panel scores.
What we measured
In addition to the review score mentioned above, we computed the following for each panel:
Cost: Total API-equivalent cost of every attempt for a condition, including failed attempts and retries, divided by the number of complete, usable panels. We calculated cost using a public list-price rate card frozen before testing began, rather than actual incurred spend. Actual costs vary by payment method, subscription plan, credits, and negotiated contract terms, making them unsuitable for consistent cross-provider comparison. The published rates were current when the study began and may differ from today’s prices.
Time: The total wall time consumed across all five planned panels for a condition, also including failures and retries, divided by the number of complete, usable four-persona panels. Within each panel, the four persona evaluations ran concurrently. Any provider-directed waits and targeted retries were included in the panel’s elapsed time, and each panel was fully resolved before the next panel began.
Downside score consistency: Some tested conditions had a wide discrepancy when it came to their efficacy scores, while some clustered tightly together. In a SOC, unexpectedly good answers are unlikely to cause problems, but unexpectedly poor answers can lead to unwelcome false positive or (worse) false negative decisions. Our score consistency is defined as the median score for the panel minus the lowest score in that panel. Smaller numbers indicate higher consistency.
The data behind the tests
The corpus was generated with EvidenceForge, Talos' open-source synthetic telemetry generator. We froze EvidenceForge at version 1.12.0 and used the same six-hour enterprise scenario for every condition, so the model and reasoning settings changed while the evidence did not.
The reviewer-visible corpus contained 80,054 simulated log records across 20 source formats, packaged as 88 files totaling 48.0MB (45.8MiB). It combined:
Network telemetry from two Zeek sensors, including connection, DNS, HTTP, TLS, SMTP, file, certificate, OCSP, DHCP, and NTP logs
Perimeter security telemetry from a Cisco ASA firewall and Snort IDS
Endpoint telemetry, including Windows Security and Sysmon events, eCAR process, session, and flow records, Linux syslog, and shell history
Application access logs from web and proxy services
A small set of email artifacts
Every reviewer received an identical copy of the data. Scenario definitions, generator information, ground truth, and other metadata generated by EvidenceForge were withheld from the model.
What we learned
The most important thing Talos learned was that choosing your model is not as straightforward as we had hoped. The following chart lists the top 10 conditions by median score. If we were to take the top-scoring model, we could expect to wait more than half an hour for an answer and pay about $55USD for it. While that might be acceptable for certain tasks where the need for the best possible analysis overrides any other factors, we can easily see that the “best” model here might not be the appropriate choice for workflows that execute frequently.
Rank
Condition
Median score
Complete panels
Observed range
Time/panel
Cost/panel
1
GPT-5.6 Sol Ultra
96.25
5/5
95.00 – 98.00
33.72 min
$55.48
2
GPT-5.6 Sol XHigh
92.75
5/5
92.00 – 95.75
24.66 min
$38.55
3
GPT-5.6 Sol Max
90.00
5/5
88.75 – 92.75
31.51 min
$53.88
4
GPT-5.6 Sol High
87.25
5/5
70.25 – 89.50
16.88 min
$28.58
5
GPT-5.6 Sol Medium
81.50
5/5
80.25 – 88.75
11.89 min
$15.24
6
GPT-5.6 Sol Low
73.00
5/5
57.25 – 77.50
5.83 min
$5.45
7
GPT-5.6 Terra Max
66.00
4/5
63.00 – 69.25
28.32 min
$18.27
8
GPT-5.6 Terra Low
65.00
5/5
53.00 – 76.00
4.72 min
$2.37
9
GPT-5.6 Terra Ultra
58.75
5/5
48.25 – 71.50
23.16 min
$18.56
10
GPT-5.6 Luna Low
58.25
5/5
46.00 – 74.00
3.24 min
$0.39
Instead of ranking based on any single criteria, we needed a more robust, multi-variable system, so we chose to compute the Pareto frontier.
Stop looking for a single winner
A Pareto frontier highlights the best available tradeoffs when several measures matter, and no single measure determines the winner. A condition appears on the frontier when no other condition is at least as good across every measure and clearly better on at least one. For example, a lower-scoring condition may still belong on the frontier if it is meaningfully faster or less expensive. Conditions outside the frontier have another option that matches or improves all the measures being compared, making them less attractive under any combination of those priorities.
Talos' frontier was calculated using the four primary measures discussed earlier: score, cost, time, and downside consistency. Although this produces a single frontier, a four-variable frontier is difficult to represent and interpret visually. The following graphs therefore show four two-variable views: score vs. cost, score vs. time, score vs. downside spread, and cost vs. time.
The dark line in each graph marks the best observed tradeoffs for the two measures shown in that panel, while the numbered points identify conditions on the full four-measure frontier. A numbered point may fall away from a panel’s line because its frontier membership depends on one of the other measures not shown there.
In the score graphs, conditions toward the upper left generally offer more attractive tradeoffs: higher scores with lower cost, time, or downside spread. In the cost-versus-time graph, the preferable direction is toward the lower left. The cost and time axes use logarithmic scales, so equal distances represent proportional rather than equal numerical changes. Together, these views help explain why each condition belongs to the frontier, but choosing among them still requires deciding which tradeoffs matter most for the intended use.
Figure 1. Pareto frontier.
A reasonable way to use this information to select the optimum condition is to begin with the conditions on the Pareto frontier, discarding all the others. Next, set acceptable thresholds for each of the four variables:
The minimum score you're willing to accept
The maximum downside consistency you can live with
The highest per-task cost you're willing to pay
The maximum amount of time you're willing to wait for an analysis task to complete
From the Pareto frontier conditions, eliminate any which fail to meet at least one of those requirements.
You are likely to still be left with more than one frontier condition. Choosing between those is a matter of organizational priorities and preferences. In a SOC, if all the other requirements are met, choosing the remaining condition with the highest mean score is probably a good start.
Other lessons learned
While our main goal was to find an effective selection methodology, we learned some other interesting things as well. In fact, some of these were rather surprising.
More reasoning did not reliably mean better analysis
Cost generally rose with reasoning effort. Score did not.
GPT-5.6 Sol mostly improved as effort increased but max scored 90.0 while the lesser xhigh level scored 92.75. Ultra then climbed to 96.25.
Figure 2. GPT-5.6 Sol scores by reasoning effort.
We saw a much more pronounced and surprising effect with GPT-5.6 Luna, where increasing the reasoning effort decreased scores at all levels.
Figure 3. GPT-5.6 Luna scores by reasoning effort.
In fact, GPT-5.6 seemed to have a generally odd relationship between reasoning and score. Terra was erratic.
Figure 4. GPT-5.6 Terra scores by reasoning effort.
Claude Opus 4.8 gained eight points from medium to high, then lost 9.5 points from high to xhigh.
Figure 5. Claude Opus 4.8 scores by reasoning effort.
These results show why it is important to benchmark every reasoning level you might deploy. You cannot assume that a model’s performance scales according to the reasoning level you use. More effort means more cost but doesn’t always mean better results.
The analyst role changed the result
Talos’ results showed a measurable difference in score based on which persona was doing the evaluation. This was entirely expected (and why we chose four different personae in the first place) but it was nice to see this confirmed by data.
The chart below shows every valid score produced under each of the four analyst roles across all conditions. Each dot is one evaluation. The box captures the middle half of the scores, and the line inside it marks the typical result.
Figure 6. Persona score distributions.
The Threat Hunter role produced the highest median score at 43. Network Forensics and Host/EDR both had medians of 35, while Detection Engineer had the lowest at 31. When we compared roles within the same model, reasoning setting, and test round, the largest typical difference was between Threat Hunter and Detection Engineer; Threat Hunter scored five points higher.
These are tendencies, not guarantees. The distributions overlap substantially, and each role sometimes produced both high and low scores. But the results do show that changing the role and its evidence priorities could meaningfully change the model’s conclusion.
For SOC workloads, the prompt should be treated as part of the system. Do not assume that one generic “SOC analyst” prompt represents every defensive workflow. If your budget allows, you might get better results by having multiple personae evaluating data according to their individual “expertise.” But watch for disagreement between the personae. Large differences may require extra human review.
Higher reasoning effort sometimes reduced reliability
Two failure types had the greatest effect on model selection: responses that violated the required output format and attempts blocked or declined by the model provider’s safety system. Although safeguards and model-authored refusals arise differently, both have the same immediate operational result: no usable analysis is delivered.
Figure 7. Failure rates by reasoning effort.
Almost every format violation came from Claude Sonnet 4.6. Low and medium completed without any, but 10 of 27 high attempts and 15 of 29 max attempts returned invalid output. Retries recovered some cells, but high produced only two of five complete panels, and max produced none. This was not a minor formatting inconvenience; it prevented both conditions from producing enough comparable results. It doesn’t matter how good the underlying analysis is if the model can’t provide answers in the expected format.
Safeguard and refusal failures followed a similar pattern at higher reasoning settings. Claude Sonnet 5 had none at low or medium, followed by one at high, four at xhigh, and five at max.
We intentionally excluded Anthropic’s Fable from our experiment matrix because our early testing generated far too many refusals to get comparable scores. Safeguards blocked 21 of 31 attempts, including all eight max attempts. Ten of its 20 scheduled persona cells remained unavailable, and no reasoning level produced a complete four-persona panel. It’s worth noting that the early tests were conducted with an account which was part of Anthropic’s Cyber Verification Program (CVP) which offers relaxed safeguards for recognized cybersecurity professionals. Even with relaxed guardrails, the high refusal rate rendered the model unusable for our tests.
These failures are already reflected in the optimization results. Conditions that could not produce at least three complete panels were excluded, while the cost and time of failed attempts and retries were included in the reported operational measures. However, the failure rate itself was not an axis of the Pareto frontier.
These results show that reasoning effort can affect more than answer quality, cost, and completion time. It can also affect whether a usable answer arrives at all.
What does this mean for your SOC?
We began this work looking for the best model for a particular task. What we found instead was a set of tradeoffs. The highest-scoring condition was also slow and expensive, while several cheaper and faster conditions delivered lesser, but still useful, results. There was no single obvious winner:
Reasoning effort was not a dependable quality dial. Increasing it sometimes improved the result, sometimes made no meaningful difference, and sometimes made performance or reliability worse.
The analyst role also changed what the model concluded, confirming that the prompt is part of the system being evaluated.
Consistency and availability mattered alongside average quality. A model that occasionally produces an excellent answer may still be a poor operational choice if it also produces weak, malformed, or blocked responses too often.
Rather than just using the results of our study verbatim, organizations should use it as a model for their own selection process. A focused set of representative cases and model/reasoning conditions, tested several times with the prompts and tools you intend to use in production, can reveal much more than a generic leaderboard. A spreadsheet that records quality, cost, time, consistency, and usable-answer rate is enough to expose many of the tradeoffs.
The goal is not to build a perfect benchmark or discover a universally superior model. It is to replace assumptions with evidence before a system touches real investigations or starts incurring real costs. Begin with the workflows that matter most, measure what your SOC cares most about, and revisit the decision as the technology or cost changes. Model selection will still involve judgment, but it can be informed, explicit, and defensible judgment.
from Cisco Talos Blog https://ift.tt/5N7De2E
via IFTTT
An independent malware researcher has documented a previously unreported Windows backdoor, dubbed SLEEPWALKER, that stays inert in memory until a specifically crafted network packet reaches the machine and then runs commands written in a 23-instruction language of its own design.
The sample is an unsigned 64-bit Windows dynamic-link library (DLL) of 59,904 bytes, built to be side-loaded into ERAAgent.exe, the Windows executable for ESET Management Agent.
It impersonates Microsoft's dpapi.dll, exporting the same seven data protection functions as the genuine system library, and carries a version resource copied from ESET Management Agent.
There are no domains, IP addresses or URLs built into the file, and it makes no outbound connection of its own, so an infected host can look clean to tooling that watches for connections to known-bad infrastructure.
Commands arrive as bytecode rather than readable text, so recovering the encryption key yields opcodes in a format that exists nowhere but inside this one file. Dominik Reichel, a former Palo Alto Networks Unit 42 malware researcher, said the approach is "consistent with a targeted, well-resourced operation rather than an opportunistic one."
The assessment rests on a single binary supplied with no collection context, and Reichel could not attribute the sample to any known actor, establish a victim, an industry, or a country, or determine whether the sample was ever deployed.
Its embedded configuration decrypts using AES-256-CCM into a single instruction that tells the backdoor to monitor every network interface indefinitely for that packet.
The listener captures everything crossing each watched interface, including traffic addressed to other machines. A gateway, VPN server or host bridging two network segments could therefore see a trigger meant for a different machine entirely.
SLEEPWALKER checks only the host process name, not its signature or path. Writing the file into that directory requires local administrator rights that an operator must already hold, and the backdoor relies on the security context of its host process rather than obtaining those rights itself.
The backdoor is therefore a post-compromise implant rather than an entry point, and how an operator first reached the machine and wrote the DLL into that directory remains unknown.
Side-loading is also its only persistence mechanism, and the DLL loads again each time the ESET Management Agent service starts.
The side-loading relies on Windows DLL search order rather than a flaw in ESET's software, so there is nothing to patch, and the response to a confirmed match is incident response and a rebuild.
ESET's products have been abused for side-loading before, including by ToddyCat, which Kaspersky said exploited a search-order flaw in the company's command-line scanner to load a malicious DLL into ESET.
The Hacker News has reached out to ESET for comment on whether it has telemetry on the sample and will update this story with any response.
ESET has issued no advisory or public statement on the malware as of August 26.
The 23 instructions cover scheduling, several ways to move data, staged file delivery verified against a SHA-256 hash before it runs, and executing code directly in memory. They ride on six transports, comprising TCP, UDP, ICMP, SMB named pipes with credentialed lateral movement, raw promiscuous capture, and VMware's Virtual Machine Communication Interface (VMCI).
VMCI traffic passes through the virtualization layer rather than a network adapter, so a packet capture taken between two machines misses it entirely. UNC3886 used VMCI sockets for persistence between compromised ESXi hosts and their guest virtual machines in intrusions documented by Mandiant.
No instruction in the language writes to disk, so anything the backdoor expects to find on a compromised machine has to be placed there by another component.
Two of the instructions watch for the trigger. The opcode stored in the analyzed sample enables only the raw-packet listener. At the same time, a second opcode also enables a DNS-based trigger implemented in the binary but not active in this build.
To let unauthenticated callers reach its named-pipe channel, SLEEPWALKER sets the EveryoneIncludesAnonymous registry value and adds its pipe name to NullSessionPipes. Its cleanup routine records whether its own write to NullSessionPipes succeeded rather than whether an entry was already present, so a removal can delete a legitimate entry that predates the infection.
The two registry values carry weight only against a known-good baseline.
The writeup ships a YARA rule and a read-only PowerShell scanner that checks those indicators across an estate. Reichel said detection coverage for the file was low at publication, without stating a basis for that assessment.
He noted that the YARA rule keys partly on a static AES key and on compiled protocol code, which a rebuild with different compiler settings could break.
The Hacker News found no public release of the analysis toolkit or the mitigation guide described in the post on Reichel's site or his GitHub profile as of August 26. Reichel said anyone who believes they have been targeted should contact him directly.
Magic-packet implants of this kind have surfaced on Linux systems, including Red Menshen's use of passive backdoors like BPFDoor inside telecom operator networks, as documented by Rapid7.
Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.
from The Hacker News https://ift.tt/ZJjnvPf
via IFTTT
Cybersecurity researchers have disclosed details of a phishing-as-a-service (PhaaS) platform built to strip Apple's Activation Lock from stolen devices, using rented AI voice agents that call theft victims posing as Apple Support and ask for their device passcode.
SOCRadar Threat Research Unit (STRU) said the platform, which it tracks as AnonyMousKIT, is credit-metered and drives lures across five channels from a single victim record, comprising email at 1.50 credits, SMS priced per sender ID, WhatsApp, a recorded voice call at 1 credit, and an AI voice agent at 2 credits.
The targets are owners of Apple devices that were recently lost or stolen, and the pages and calls ask each of them for the 4- or 6-digit device passcode, then the Apple ID credentials, and finally a live two-factor authentication (2FA) code. Apple's own guidance states that the company never asks for a password, device passcode, or 2FA code to provide support.
"AnonyMousKIT is best understood not as a phishing kit but a small software business with a criminal customer base. It features credit bundles, published pricing, tiered subscriptions, customer support, status tracking, and infrastructure replacement protocols," SOCRadar said in a Monday report.
Activation Lock, introduced in iOS 7, ties the hardware to a specific Apple ID and renders a stolen handset unusable until the owner's account is removed.
Lures cite the handset's internal Apple model identifier and its live Find My status, both pulled from the stolen device itself. Victims who follow the link reach an Apple-branded capture page that renders an animated map of the handset's reported location.
The AI voice channel is the best-documented vector after email, with 200 call records, 55 transcripts, and five configured personas recovered from the operator's account with the commercial voice platform Vapi.
The researchers' report does not say whether the account was reported to Vapi, and neither company has said publicly whether it is still active. All five personas carry the same translated identity, Alice from Apple Support, across English, Spanish, and Portuguese.
The calls ran between August 31, 2025 and May 30, 2026, and 179 of the 200 went to numbers in Brazil. In the recovered transcript, the agent asks the victim to confirm ownership, then requests the four- or six-digit passcode and reads the digits back for confirmation.
It then explains that someone visited an Apple Store to remove the Activation Lock and asks whether a recovery link has arrived via text. The researchers put the total cost of the 200 calls at $19.24, or about 9.6 cents each.
The outcome table in the report assigns all 200 calls to one of four results, comprising 100 victims who hung up, 48 silence timeouts, 24 no-answers, and 28 platform errors or busy signals. No count of captured passcodes, Apple IDs, or 2FA codes appears in the report for any of the five channels.
The logs reached SOCRadar via two bare relative file paths in the shared codebase that resolve to the web root and allow unauthenticated HTTP access. Every deployment of that codebase inherits the flaw.
A scan of 506 kit-family domains identified 30 distinct installations reachable on 42 domains, with 188 of the 506 live.
The AnonyMousKIT installation logged 691 send attempts between March and July 2026, compared with 6,092 across the 30 backends.
Three storefronts, i-Blocker, Key Unlock, and KG-KING, launched in the same second on April 10, 2026, sharing the same Gmail relay accounts. SOCRadar assessed that pattern as one buyer running three brands rather than three separate customers.
The researchers recorded the following characteristics of the email lures -
The top two subject lines were "Your device has been found" (308 of 691) and "Alert" (157)
Display names spoofed Apple, Find My, Apple Support, and Apple Assistance
627 of the logged sends relayed through a single free Gmail account, noreplyapple00000[@]gmail[.]com, against 20 and 2 for the two other relay accounts
678 of the 691 lures carried a location token naming a city, including Johannesburg, Abuja, Buenos Aires, Maputo, and Mumbai
Victim-facing capture pages were served from tokenized /help?TOKEN URLs
South Africa accounts for 1,735 of the 6,092 family-wide sends, and 64 of AnonyMousKIT's own 691 sends reached non-consumer domains, including 27 to South African government addresses. SOCRadar said those recipients were selected because their devices were stolen, not because of their roles.
The report said the four unlock tools offered on the panel serve as bait, because 5,649 of the 6,092 targeted devices, or 92.7%, run A12 silicon or newer.
The checkm8 bootrom exploit reaches only A5 through A11 chips. It also states that technical bypasses are obsolete now that Apple has moved past the checkm8 generation. A public bootrom exploit for A12 and A13 was released on June 18, 2026, two months before the report, and its proof of concept remains live.
Its authors describe it as a tethered bootrom exploit requiring physical possession and device firmware update (DFU) mode, and the research does not show a Secure Enclave compromise. Its control tool demotes the device to production mode or boots a raw iBoot image, and neither action recovers a device passcode or removes Activation Lock.
SOCRadar described the automated, LLM-driven voice vector as the platform's primary innovation.
Infoblox Threat Intel documented the same unlock-kit ecosystem in May using DNS telemetry, publishing a list of 4,244 malicious domains detected between March 2022 and May 2026.
"By combining technical tooling and social engineering, thieves now have a way to unlock devices at scale and make phone theft profitable," Infoblox Threat Intel researchers Maël Le Touz and Elena Puga said.
Identical second-level labels across different top-level domains are a pattern match rather than an attribution to a single operator.
"Apple will never ask you to log in to any website, or to tap Accept in the two-factor authentication dialog, or to provide your password, device passcode, or two-factor authentication code or to enter it into any website," Apple said in support documentation published on June 15, 2026.
Apple directs users to forward Apple-branded phishing email and text messages to reportphishing@apple.com.
The researchers recommended moving high-value Apple IDs to physical hardware security keys, which it said completely mitigates the real-time 2FA interception that is the funnel's ultimate objective.
The Hacker News contacted Apple for comment on the research; the company had not responded by the time of publication.
The development comes as German and U.S. law enforcement dismantled Kratos in July, pulling more than 200 servers offline, and Indonesian authorities arrested the man they say developed and ran it.
"The platform was still running on the last day of our analysis. SOCRadar continues to track it, its sibling storefronts, and the wider shared-codebase family, and will report material changes," the company said.
from The Hacker News https://ift.tt/MtKwNhs
via IFTTT
SUMMARY: Brandon speaks with Rich Ziade, co-founder and CEO of Aboard, about why enterprise AI projects fail without real discovery, why "agents" have been oversold as a headcount play, and why organizational urgency, not new tooling, is what actually makes digital transformation succeed.
Topic 1 - From lawyer to digital transformation CEO: Rich's path through Postlight (with co-founder Paul Ford), the sale in 2021, and how Aboard was already incubating inside Postlight Labs before AI "landed like a spaceship."
Topic 1a - The six months after ChatGPT arrived: why Aboard resisted rushing a prompt-based fix into messy, political, human organizations, and why "vibe coding" convinced them to hang back rather than parachute AI into a company.
Topic 2 - The doctor/patient analogy: executives walk in asking for a specific AI "medicine" instead of describing the underlying pain, and why real engagements start with tests and diagnosis, not the prescription the client thinks they want.
Topic 2a - Why discovery hasn't fundamentally changed in the AI era — still in-person interviews and observation, with AI mainly useful for note-taking and summarizing documentation, not for skipping the hard thinking.
Topic 3 - The agent hype cycle: why Rich thinks the "millions of agents" narrative (including Anthropic's Boris Cherny running swarms of planning/implementation agents) reflects an engineering-execution worldview rather than a product or organizational one — and why he sees the agent narrative cooling off.
Topic 3a - The "spreadsheet problem" vs. targeted AI: most of Aboard's actual delivery work (90%+) isn't agents — it's modernizing spreadsheet-run processes and building narrow RAG/vector tools so people can query their own data in plain English.
Topic 4 - "Forward deployed" as the new name for an old idea — going on-site, listening, and understanding a client's world before proposing a solution.
Topic 5 - Why no successful digital transformation starts without a real, externally imposed deadline or crisis — and why "innovation labs" without urgency rarely ship anything.
Topic 6 - Lightning round: Is AI a bubble? Should GPUs be securitized assets? Three things to do in NYC in one day.
Ransomware volumes are still rising. Bad patches still ship. A single corrupted update can take an entire Windows fleet offline in an afternoon. For a hospital, a bank, or a retailer, that is no longer a helpdesk issue. It is a business continuity event, and the board is treating it as one.
Today’s recovery paths were built for a quieter era. Reimage workflows, hardware swap pools, and central recovery services all assume that recovery happens somewhere else, on someone else’s timeline. They scale with the size of the fleet, and they depend on hardware that is rarely on the shelf when the incident hits. The question security and IT leaders are now being asked is a simple one: if ransomware hit your Windows fleet tomorrow, how long until your users are productive again, and can you prove the recovery path is clean?
A recovery path that shares hardware with Windows, but not fate
Citrix UniconOS dual boot answers that question with a different approach to endpoint resiliency. A second, hardened Citrix UniconOS lives side by side with Windows on the same physical disk, in a separate, isolated partition, turning every Windows machine into an immutable endpoint with a built-in recovery path. Secure Boot is enabled end to end, and the chain is Trusted Platform Module (TPM) compatible. The recovery OS is signed from shim to kernel, so it is provably clean even when the production OS is compromised.
Windows itself stays untouched. No reimage, no bootloader surgery, no second device to ship. When the user reboots, they see a simple boot menu. If Windows is unavailable, they pick UniconOS, sign in, and are back in their applications through Citrix DaaS and Citrix SecurAccess with Chrome Enterprise within minutes. UniconOS gets the device back online. Citrix DaaS and Citrix SecurAccess with Chrome Enterprise get the user back to work. Together, they turn endpoint recovery into recovered productivity, which is what the business actually needs from a business continuity and disaster recovery (BCDR) program.
Continuity as a property of the device, not a project
Every Windows endpoint in production also becomes its own disaster recovery device. Recovery time scales with a single reboot per user, not with fleet size. There is no separate DR hardware pool to fund, ship, and maintain, and no rolling, site-by-site IT operation to run in parallel with the incident itself.
For infrastructure teams, that changes the shape of the response. IT centrally configures boot behavior, fallback policy, default OS, boot delay, and fleet health from Citrix UniconOS Management. When an incident hits, admins move from manual triage to policy and monitoring. That is the operational shift that finally makes endpoint BCDR affordable at enterprise scale.
A recovery path that survives its own incident
The value of UniconOS’s dual boot capability is not just speed. It is provenance. The recovery OS is immutable, isolated, and signed end to end. It cannot be poisoned by a compromised Windows filesystem, because it does not depend on that filesystem.
That gives security and IT leaders something concrete to bring to the board and to the auditor: a documented, testable recovery path that survives the very attack it is meant to recover from. It also closes a gap familiar to most incident response teams, where recovery pressure typically overwrites the evidence needed for forensic analysis and regulatory reporting under NIS2, DORA, and HIPAA. With dual boot, the compromised Windows instance can be frozen for investigation while the user keeps working from an isolated UniconOS instance.
What immutable endpoint recovery delivers on the fleet
Citrix UniconOS installs in place on the running Windows machine and auto-enrolls into Citrix UniconOS Management. Windows stays as it is. The user gets a boot menu they only need to remember on the day they need it. The outcomes fall into a short list that holds up in a board conversation:
An immutable endpoint with a signed, isolated recovery OS already on every device, provisioned through Secure Boot and TPM
Recovery in minutes, at fleet scale, on the hardware the customer already owns
A single control plane for deployment, policy, and recovery-OS health across the estate
A unified path back to productivity through Citrix DaaS and Citrix SecurAccess with Chrome Enterprise, not just a booted OS
A documented, testable recovery path aligned to NIS2, DORA, and HIPAA continuity expectations
Endpoint resiliency built into the fleet, not bolted on through a separate DR program
Getting started with Citrix UniconOS dual boot
Citrix UniconOS dual boot is available with UniconOS Release 7 2607 in August 2026. Connect with your Citrix representative or explore the Citrix UniconOS web page to see dual boot running in your own environment.
from Citrix Blogs https://ift.tt/frVtqck
via IFTTT
As frontier models advance in cyber capability, their guardrails also become more restrictive.
Defenders relying on these models to power core SOC processes cannot afford to pay the “safety penalty” of being blocked by these safeguards.
Organizations should monitor model refusal rates and use the data to create a strategy to ensure operational sovereignty.
The allure of the cloud and the hidden "safety penalty"
Cybersecurity has made a big bet on cloud-hosted AI. Building and running frontier-class models in-house isn’t realistic for most security teams — the compute, the talent, and the R&D costs are more than any single SOC can carry. So we’ve effectively outsourced the "brain" of our security operations to a handful of providers.
That trade comes with a hidden cost: the safety penalty.
The safety penalty is the friction that shows up when guardrails built to protect the general public get in the way of legitimate security work. If your model refuses to deobfuscate that malware or to explain a working exploit because its filters read the request as harmful, you’re paying the safety penalty.
Those guardrails make sense in a normal business context and may even be a welcome feature when it comes to keeping agents in check. But in a SOC, in the hands of defenders aiming to reap the full benefits of powerful AI models, these guardrails are a bug. Every refusal sends the analyst back to doing the work by hand, and in a live incident, that lost time is a luxury we don’t have.
Meanwhile, the adversary pays none of this penalty.
A warning from the frontier
In July 2026, an unreleased OpenAI model escaped its sandbox and compromised Hugging Face’s production infrastructure. It wasn’t an external hack, but an unintended "breakout" during testing, with its guardrails deliberately stripped for the exercise.
The telling part came during the response. When Hugging Face tried to use its primary cloud LLM to investigate the breach, the model refused the forensic request. The "safe" model, in this context, was an obstacle. To get the analysis done, Hugging Face pivoted to an unconstrained open-weight model, GLM-5.2, which delayed their response.
Hugging Face could make that pivot because they host open-weight models for a living and have the expertise to bypass a refusal on short notice. Most organizations don’t have that muscle. If your defensive model refuses a task mid-crisis, you’ve handed the adversary the advantage.
That asymmetry is already being exploited. After state-sponsored actors were banned from frontier APIs, they simply moved their research to self-hosted, unconstrained models. The rise of AI-driven attacks is old news by now; what’s new is how lopsided this is about to become, with defenders slowed by refusals while adversaries are iterating at machine speed with nothing in their way.
Guardrail asymmetry
Attackers don’t even need to jailbreak anything. Models like GLM-5.2 and Kimi k3 are readily available with far fewer restrictions than Western frontier APIs, and "abliteration" (stripping the safety training out of an existing model) remains an option for anyone who wants to go further. Mostly, they don’t have to. They can just pick a model that doesn’t refuse them.
Most defenders don’t have that option. Cloud APIs are tuned toward a kind of cyber do-no-harm designed to keep bad guys from using them to build attacks. This is the same refusal bias that ends up blocking security teams trying to analyze those attacks. In a defensive context, erring on caution often means erring in the attacker’s favor. Every refused request costs the defender the one resource they can’t get back: time.
This trade-off used to be worth it. A few months ago, frontier models were far enough ahead on reasoning and code generation that the friction from their guardrails was a fair price. But the newest frontier models, like Anthropic’s Fable, are shipping with sharper cyber capabilities and even tighter guardrails to match. Meanwhile, open-weight alternatives have closed most of the reasoning gap that used to justify putting up with those guardrails in the first place.
Either way, the calculus is shifting: Defenders are increasingly paying for restrictions without getting a capability edge in return.
Defining operational sovereignty
The way out is what I’d call operational sovereignty — not to be confused with data sovereignty, which is about where your data lives and how it’s treated. Operational sovereignty is about who gets the final say over what your AI is allowed to do.
A sovereign SOC needs its AI technology to be at least on par with that of their adversaries. They either need to have a fallback on hand when their model refuses to complete a task or to use a model that will not offer refusals in the first place. That does not mean there should be no safeguards placed around the models, just that the safeguards should be under the control of the organization itself rather than imposed upon them from the outside.
Security operations also shouldn’t be hostage to a vendor’s shifting alignment policy, or frequent behind-the-scenes model updates that may change behavior subtly and unexpectedly (known as model drift). Operational sovereignty means a policy change in Silicon Valley doesn’t quietly break your defensive workflow overnight. It’s what lets you keep pace with an adversary who was never bound by those policies to begin with.
The roadmap: From convenience to collective defense
Getting there isn’t all-or-nothing. The right path depends on risk tolerance and how much infrastructure a team can realistically manage.
Private infrastructure
The most direct route is to host the model yourself, on your own GPUs or a dedicated private cloud instance, so you own the weights and the policy outright.
The benefit: There’s no safety penalty because there’s no third party to impose one. You’re free to choose any model that fits your needs, guardrails included or not.
The downside: Physical scarcity, expertise, and high upfront cost. GPU procurement can take months, the capital outlay is steep, and running your own inference stack takes specialized talent most security teams don’t have on staff.
Model-as-a-Service
Model-as-a-Service splits the difference. Providers like Baseten or Together AI, or platforms like Amazon Bedrock or Microsoft Foundry, let you bring your own model to infrastructure they manage, without layering their own safety refusals on top.
The benefit: It removes the safety penalty while offloading the hardware burden. You get the control of private infrastructure with the scalability of the cloud.
The downside: Dedicated capacity that avoids provider-side filters is often in short supply. Falling back to shared clusters solves the availability problem but can reintroduce the same guardrails, and the same data-sharing concerns, you were trying to escape.
The hybrid fallback
The most architecturally involved option is to keep frontier cloud models for most day-to-day tasks but add an automated handling path for the rest. A gateway watches for refusals and reroutes those prompts to a smaller, unconstrained model you control.
The benefit: A guaranteed response with minimal upfront infrastructure investment. You stay on the cutting edge of cloud capability while neutralizing the safety penalty.
The downside: Keeping the fallback model’s read of a prompt consistent with the primary’s, so a refused request lands the same way with both. If the fallback is a local model, you’re also managing two systems in parallel — a smaller maintenance burden than hosting it all yourself, but not zero.
Collective inference
The most speculative option, and the one I find most interesting: evolving the ISAC/ISAO model into collective inference. Industry groups already share threat intelligence, so why not pool the infrastructure too? A sector could jointly fund a shared, unconstrained model, maybe even one tuned to its own threat landscape, governed by its members rather than a vendor.
The benefit: A community-governed "brain" as capable as any frontier model, answerable only to the defenders who fund it.
The downside: Governance. Members have to agree on usage and safety policy, and during a sector-wide incident, everyone would be hitting the same shared infrastructure at once.
Reclaiming the defensive advantage
You can’t manage what you don’t measure. If an AI assistant is supposed to be a force multiplier, every refusal during a live incident multiplies by zero. Security leadership should treat those refusals as a structural failure of a non-sovereign stack, not an occasional annoyance.
Start by auditing your refusal rate. That number is the most direct way to put a figure on the safety penalty your organization is actually paying. Once you know it, the path forward gets a lot clearer.
The adversary has already claimed its own sovereignty, running at full throttle with no guardrails to slow them down. Defenders need to manage their safeguards to keep pace.
from Cisco Talos Blog https://ift.tt/nEPwQlS
via IFTTT
To assess the impact of AI-enabled malware, we collected and analyzed over 400 malware samples that integrate AI in some capacity, from brand impersonation and large language model (LLM)-generated code to agentic execution loops. Our central finding was that the AI malware space is currently overwhelmingly composed of proof-of-concept code, security validation testing and researcher submissions that have never reached a production environment.
Of the 405 samples in our dataset, only 12 appeared in our telemetry on Cortex XDR-protected endpoints, and a small subset was forwarded through Next-Generation Firewalls to WildFire for analysis. Palo Alto Networks products detected and blocked every sample that attempted to reach a customer environment.
These numbers tell a story that sits between two poles in the current discourse. AI-enabled malware is real. However, the volume of genuine operational activity remains a fraction of what public sample repositories suggest. Approximately 97% of the samples we examined exist only in sandboxes and on VirusTotal.
For defenders, the practical takeaway is straightforward. Existing behavioral detection, cloud-based sandboxing and endpoint analytics catch these threats using the same mechanisms that stop conventional malware. The AI component does not evade detection. It changes how the code is authored, not how it executes.
Palo Alto Networks customers are better protected against the threats discussed in this article through the following products and services, which detected these AI-enabled malware threats out of the box:
Our starting dataset consisted of 405 unique SHA-256 hashes collected from WildFire analysis reports, VirusTotal Intelligence and published open-source intelligence (OSINT) research.
The collection criteria were broad. We included any sample where AI integration was either a functional component of the malware, a feature of its delivery mechanism or part of its branding. This intentionally inclusive approach captured everything from LLM-powered ransomware agents to cryptocurrency miners that simply used “ChatGPT” in their filename.
We queried this dataset across multiple telemetry sources to measure real-world prevalence:
Network visibility: WildFire session data from samples forwarded by Next-Generation Firewalls and Cortex XDR agents (June 2024–June 2025)
Alert generation: Cortex XDR alert records for samples that triggered detection logic on endpoints
Sandbox verdicts: WildFire analysis results with malware classification
Table 1 summarizes the results of this dataset.
Telemetry Source
Samples Queried
Samples Discovered
Prevalence in Production
Cortex XDR endpoints
405
12
3.0%
WildFire sessions
405
~15–20 unique hashes
~4%
Cortex XDR alerts generated
12
12
100%
Table 1. Telemetry coverage across the AI malware dataset.
The disparity between the 405-sample dataset and the 12 samples observed in production environments is the most important number in this analysis. Approximately 97% of AI-enabled malware samples exist only in research repositories, sandbox environments and security validation platforms. We found no evidence that they reached a customer endpoint or traversed a customer firewall.
The following sections examine the characteristics of the dataset.
What the Other 97% Looks Like
The samples that never appeared in production telemetry fall into three categories:
Proof-of-concept and research code
Security validation and testing
AI-themed brand abuse
Proof-of-Concept and Research Code
The largest category consists of proof-of-concept implementations published to demonstrate a technique. These include:
LLM-powered ransomware frameworks with hard-coded test parameters (such as ransom addresses pointing to the Bitcoin Genesis Block, which cannot receive recoverable payments)
AI-assisted reconnaissance scripts designed for conference demonstrations
Modular attack frameworks built to test specific AI integration patterns rather than to compromise real targets
Many of these samples share common characteristics:
They target localhost or private IP address ranges in their configuration
They contain verbose debug logging that no operational threat actor would leave enabled
Their submission histories show a single upload from a security research organization or academic institution
Additionally, we found many of these samples in file paths that indicated malware analysis or research. They contained terms such as research, mal or analysis in their directory paths.
Security Validation and Testing
A second category comprises samples submitted by breach-and-attack simulation (BAS) platforms and internal security teams. These appear in WildFire and on VirusTotal because organizations deliberately test their detection capabilities against publicly reported AI malware samples.
The submission patterns are distinctive. They include multiple uploads of the same hash from the same organization within a short time window, often during business hours in a single time zone. They frequently come from IP addresses associated with known security testing infrastructure.
AI-Themed Brand Abuse
A third category uses AI branding without meaningful AI integration. Filenames reference popular AI companies or other AI products, but the payload is conventional malware wrapped in an installer that mimics an AI application.
The AI branding is a social engineering tactic, not a technical capability. These samples are real threats to the people who download them, but they do not represent a new category of AI-enabled attack.
The 3% Found on Endpoints
Twelve samples from the dataset appeared on Cortex XDR-protected endpoints across organizations in three countries. They span five distinct malware families, each representing a different pattern of AI integration or AI-themed delivery. These five families are:
FunkSec ransomware
A trojanized AI application
The Oyster backdoor
The Rhadamanthys stealer
A COM hijacking DLL
FunkSec Ransomware
The most represented family in our endpoint data is FunkSec, a ransomware strain that multiple researchers have assessed as partially generated with LLM assistance. Seven distinct variants appeared across production endpoints, compiled between Jan. 1–6, 2025. The variants share a common Rust codebase and use similar evasion techniques:
Disabling Windows Defender through PowerShell and registry modifications
Deleting volume shadow copies
Changing the desktop wallpaper to display a ransom note
The PDB paths embedded in the binaries reveal an active development cycle. Variants use project names including:
Dev.pdb
Funksec.pdb
Darkzone.pdb
Darkfunk.pdb
This is consistent with a developer iterating on the same codebase under multiple working names. Seven distinct builds in six days is a pace that suggests LLM-assisted development, where generating a new variant is closer to a prompt generation rather than a software development task.
WildFire classified all seven variants as malware. Cortex XDR generated alerts for every variant that executed on an endpoint.
Trojanized AI Application
The most widely encountered sample in the dataset is an NSIS installer that masquerades as a recipe-finding application called Recipe Lister. The binary is signed with a code-signing certificate issued to Global Tech Allies Ltd. — a certificate that has since been revoked. When executed, it extracts and runs a JavaScript backdoor from a temporary directory.
This sample generated the highest volume of telemetry in our dataset. It appeared across more than 50 organizations and generated over 6,500 endpoint profile records and 9,600 XDR alerts during the observation window. The alert data confirms that Cortex XDR blocked the binary across these environments through a combination of local analysis, behavioral protection and WildFire cloud verdicts. No execution succeeded on a protected endpoint.
The detection dynamics around this sample illustrate how layered defense handles AI-themed threats:
The code signature initially suppresses static detection, as the file appears legitimately signed
Behavioral analytics identify the threat through two secondary signals:
The signer is uncommon across the organization's fleet
The file entropy is near-maximum (0.999970), indicating packed or encrypted content
The WildFire cloud verdict, which arrives after the file is forwarded for sandbox analysis, provides the definitive classification and triggers the block action
Oyster Backdoor
One sample masquerades as a Dropbox installer and carries an Authenticode signature whose subject identity reads Dropbox, Inc. To the victim, this appears to be verified, publisher-signed software. In reality, the installer drops an AutoIt loader that side-loads the Oyster (aka CleanBoost) backdoor. The signed file is not Dropbox software, and the signature lends it false legitimacy.
Attackers are using AI tools to quickly generate the malicious code required for the initial access and delivery phases of the attack, lowering the barrier to entry and speeding up the deployment of loaders like this NSIS installer.
Rhadamanthys Stealer
A .NET executable named redist.exe delivers the Rhadamanthys information stealer with active command-and-control communication. According to previous reporting, this sample was part of an AI-enabled infection chain that ultimately delivered this sample of Rhadamanthys stealer.
COM Hijacking DLL
A DLL masquerading as a component of 360 Total Security named 360Util.dll implements persistence through COM object hijacking. The PDB path references 360Util.pdb, and the file metadata impersonates the Chinese-language product name. We included this sample in the dataset because it was delivered alongside AI-branded lures in campaigns we observed.
Conclusion
The gap between the volume of AI malware samples in public repositories and the volume observed in production environments reflects the current state of AI-enabled threats. AI lowers the barrier to creating malware, and the number of samples in our dataset confirms that many people are experimenting with the technique. But creating a sample and successfully deploying it against a defended environment are different problems, and malware authors have not to date succeeded at using AI to solve the second one.
The samples that did reach production environments were detected by the same mechanisms that catch conventional malware:
Sandbox detonation
Behavioral analytics
Code-signing anomaly detection
Entropy analysis
None of the AI-enabled samples in our dataset required a novel detection approach. The AI component influenced how the malware was written, but the resulting binary still exhibits the same behavioral indicators that existing detection logic targets.
This does not mean we can dismiss AI-enabled threats:
The development velocity visible in FunkSec's PDB paths suggests that LLM-assisted coding accelerates the iteration cycle for ransomware development
The trojanized AI application campaign demonstrates that AI brand recognition is an effective social engineering vector, with the sample reaching more than 50 organizations
The presence of legitimate code signatures on multiple samples shows that the delivery sophistication of AI-themed malware matches that of conventional threats
Telemetry data does not reveal statistically significant targeting patterns across the samples. The encounters span three countries and industries with no concentration in any single sector or geography. This is consistent with opportunistic operations rather than targeted campaigns directed at specific organizations or verticals.
The absence of targeting patterns is itself informative. AI-enabled malware, at this stage of adoption, follows the same distribution model as most offensive cyber activity. Threat actors are integrating AI capabilities into tools that they’ve deployed broadly rather than reserving them for operations against specific high-value targets.
When evaluating AI in the current malware landscape, it should not be categorized as mere hype or altogether dismissed. AI-enabled malware is a real and growing category, but our current defensive frameworks detect and block AI-enabled malware regardless of the role that use of AI played in its development. Organizations that maintain strong defense in depth are well positioned to detect these threats as they evolve.
Palo Alto Networks customers are better protected from the threats discussed above through the following products, which detected these AI-enabled malware threats out of the box:
The Advanced WildFire machine-learning models and analysis techniques identify indicators shared in this research.
Cortex XDR and XSIAM are designed to prevent the execution of known malicious malware and prevent the execution of unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
UK: +44.20.3743.3660
Europe and Middle East: +31.20.299.3130
Asia: +65.6983.8730
Japan: +81.50.1790.0200
Australia: +61.2.4062.7950
India: 000 800 050 45107
South Korea: +82.080.467.8774
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Indicators of Compromise
Samples
Table 2 lists the samples assessed as genuine threat actor activity.
