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.
This week feels dumb in the worst way — bad links, weak checks, fake help desks, shady forum posts, and people turning supply chain attacks into some cursed little game for clout and cash. Half of it feels new. Half of it feels like crap we should have fixed years ago.
The mess keeps getting louder: users get tricked, boxes get popped, tools meant for normal work get used for bad stuff, and nobody seems shocked anymore. Great. Love that for us.
Palo Alto Networks has released the first round of fixes to address CVE-2026-0300, a critical buffer overflow vulnerability in the User-ID Authentication Portal service of PAN-OS software that could allow an unauthenticated attacker to execute arbitrary code with root privileges by sending specially crafted packets. The company said it has observed the flaw being exploited in limited attacks since at least last month, with unknown threat actors leveraging it to drop payloads like EarthWorm and ReverseSocks5.
Meta has announced Incognito Chat with Meta AI in its namesake app and WhatsApp. Incognito Chat is "a completely private way to interact with AI, similar to how end-to-end encryption means no one can read your conversations, even Meta or WhatsApp," CEO Mark Zuckerberg said. "Incognito Chat handles all AI inference in a Trusted Execution Environment that ensures your messages are not accessible to us. The conversations on your phone also disappear when you exit the session." The feature is powered by Private Processing, which already underlies its message summarization and composition tools.
A defense technology company with Department of Defense contracts exposed user records and military training materials through API endpoints that lacked meaningful authorization checks. The issue affected Schemata, an AI-powered virtual training platform used in military and defense settings. According to Strix, an ordinary low-privilege account was able to access data across multiple tenants, including user listings, organization records, course information, training metadata, and direct links to documents hosted on Schemata’s Amazon Web Services instances. In a statement posted on the company’s website, Schemata said it did not have "evidence that any third party exploited the vulnerability to access customer data."
The U.S. Federal Communications Commission (FCC) has extended the deadline for owners of banned internet routers to provide security updates to U.S.-based users by two years. In March 2026, the FCC banned the import and sale of all "consumer-grade" internet routers produced in a foreign country, citing unacceptable national security risks. In a new public notice published last week, the Commission's Office of Engineering and Technology (OET) said it is extending this deadline until "at least" January 1, 2029. That said, the extension only applies to software and firmware updates so as to ensure the continued safety of already deployed routers in the U.S. and mitigate potential harm. "These include all software and firmware updates to ensure the continued functionality of the devices, such as those that patch vulnerabilities and facilitate compatibility with different operating systems," per the FCC.
A new state-sponsored threat cluster dubbed Operation GriefLure has been observed targeting Vietnam's telecom and the Philippines' healthcare sectors with a RAR archive distributed via spear-phishing emails to deploy a remote access trojan on compromised hosts, while leveraging credible decoy documents to give them a veneer of legitimacy and trust. The malware is capable of process enumeration, screenshot capture, file and directory listing, credential harvesting, and file execution capabilities.
A multi-stage intrusion campaign has been observed leveraging a weaponized PowerShell payload disguised as a legitimate JPEG image file to deliver a trojanized instance of ConnectWise ScreenConnect to stealthy remote access. "The intrusion likely originated through social engineering techniques such as phishing emails, malicious attachments, deceptive file-sharing interactions, or fake update lures involving a malicious file named sysupdate.jpeg," CYFIRMA said. "The payload was specifically crafted to exploit user trust and bypass conventional file-extension validation mechanisms while blending malicious activity with legitimate enterprise software."
A targeted cyber espionage campaign is leveraging social engineering and trusted infrastructure to establish persistent access to victim systems. The activity, which employs lure themes centred around humanitarian aid, is assessed to target Russian-speaking individuals or entities. "The attack is delivered via phishing emails containing a malicious LNK file disguised within a RAR archive, using a Russian humanitarian aid request form to exploit contextual trust," Cyble said. "Execution triggers a stealthy, multi-stage infection chain in which a decoy document is presented to the user while a heavily obfuscated, fileless (PE-less) Python-based implant is silently deployed." The payload is retrieved from GitHub Releases, allowing the operator to blend in with legitimate enterprise activity. The implant operates as a "full-spectrum surveillance platform," facilitating credential harvesting, keystroke logging, clipboard and screenshot capture, sensitive data exfiltration, and covert remote access.
A new proof-of-concept (PoC) tool dubbed GhostLock, created by Kim Dvash of Israel Aerospace Industries, has revealed that it's possible for a domain user with read access to a file share to deny access to files without the need for deploying any ransomware or requiring elevated privileges. "By calling CreateFileW with dwShareMode = 0x00000000 across a target share, a low-privileged user holds files in an exclusively locked state indefinitely," Dvash said. "Other clients receive STATUS_SHARING_VIOLATION (0xC0000043) on every access attempt. ERP systems fail. Workflow queues stall. The impact is indistinguishable from encrypted ransomware. The attack produces none of the signals that encrypted ransomware produces." The disruptive technique is not a vulnerability, but rather documented behavior required for data integrity. GhostLock affects "any organization running SMB-backed shared file infrastructure where users have standard domain credentials and network access to file shares."
cURL developer Daniel Stenberg said that Anthropic Mythos model's scan of the utility five "confirmed security vulnerabilities," out of which one was a low-severity bug, while the rest were false positives. "The single confirmed vulnerability is going to end up a severity low CVE planned to get published in sync with our pending next curl release 8.21.0 in late June," Stenberg said. "The flaw is not going to make anyone grasp for breath. All details of that vulnerability will ofcourse not get public before then, so you need to hold out for details on that." Stenberg, however, acknowledged that artificial intelligence powered code analyzers are significantly better at finding security flaws and mistakes in source code than any traditional code analyzers.
The Indian Cyber Crime Coordination Centre (I4C), along with the Ministry of Home Affairs, and Reserve Bank Innovation Hub (RBIH), have signed a Memorandum of Understanding (MoU) to "facilitate cooperation in the areas of fraud-risk intelligence sharing, analytical support, and operational coordination for strengthening proactive fraud detection and prevention mechanisms." The goal is to combat cyber-enabled financial fraud and curtail mule accounts across the banking and digital payments ecosystem.
Attackers are enticing users seeking "free OnlyFans accounts" to download a seemingly harmless ZIP file that contains the crpx0 ransomware. The activity targets both Windows and macOS systems. "Inside that ZIP file is a small trick, a malicious shortcut disguised as something legitimate. When the user clicks it, it quietly executes hidden commands," Aryaka said. "A VBScript loader prepares the system and silently installs the components needed to run Python-based code. This is where the attack becomes more flexible. Rather than relying on a single static payload, the attackers now have a programmable environment. Once the Python script is running, it connects to a remote server." The Python-based malware allows the attackers to send commands, update the malware, or deploy new payloads. This enables system profiling, clipboard hijacking to conduct cryptocurrency theft, seed phrase harvesting, andransomware deployment.
A new ClickFix campaign carried out via a compromised website has been observed using scheduled tasks for persistence and PySoxy, an open-source Python SOCKS5 proxy, to establish encrypted proxy access. "In the observed chain, one user-executed command led to persistence, domain reconnaissance, an initial PowerShell-based command-and-control (C2) channel, and a second C2 path through PySoxy, giving the attacker encrypted proxy access without relying on well-known malware or remote monitoring and management (RMM) tools," ReliaQuest said. "This development shows ClickFix moving beyond one-time user execution into modular post-exploitation, where older open-source tools can create redundant access paths that are harder to classify and contain."
HiddenLayer has demonstrated a technique called tokenizer tampering that details how modifying the "tokenizer.json" file in Hugging Face AI models can give an attacker direct control over model output, enabling an attacker to exfiltrate sensitive data via, say, stealthy tool call injections. The attack works across Safetensors, ONNX, and GGUF formats. "Tokenizer.json ships with the model in a HuggingFace repository, as shown above, and is loaded automatically when the model is initialized for inference, making it a direct attack surface," HiddenLayer said. "This can affect conversational responses, tool-call arguments, and any other generated text, without weight modifications, adversarial input, or knowledge of the model’s architecture."
Threat actors are sending Microsoft Teams messages from a fake IT Support account to trigger an attack chain that enables remote access, malware deployment, privilege escalation, credential theft, lateral movement, and exfiltration. "By abusing Teams external access, the threat actor delivered a Dropbox-hosted Python payload [called ModeloRAT] that established command-and-control, deployed multiple backdoors, and began mapping the internal environment," Rapid7 said. "The attacker then escalated privileges to SYSTEM using CVE-2023-36036 before deploying a fake Windows lock screen designed to harvest the user's domain password." The attackers then moved laterally to a second host, used legitimate tooling such as DumpIt to gather system memory, and likely exfiltrated the data via an anonymous file-sharing service. ReliaQuest has attributed the activity to a financially motivated initial access broker (IAB) tracked as KongTuke.
The notorious threat actor known as TeamPCP, which was recently linked to the compromise of TanStack's npm packages, has teamed up with Breached forum to announce a supply chain attack competition with a $1,000 prize in Monero. As part of the announcement, the Shai-Hulud worm has been open-sourced and hosted on the forum's content delivery network. While it was also made available on GitHub, it has since been removed. According to screenshots shared by Dark Web Informer on X, the competition rules require participants to use the worm in their attacks and submit proof that they have obtained access to a target's environment. "The biggest supply chain based on the amount of weekly/monthly downloads will win," the threat actor said. "If you compromise many small packages, it will be added up." The development marks a newfound escalation of TeamPCP's tradecraft.
An unknown threat actor has been spotted using a NATS server as a command-and-control (C2) channel rather than relying on traditional HTTP-based panels or chat platforms. The novel technique has been codenamed NATS-as-C2 by cloud security company Sysdig. The activity relates to the exploitation ofCVE-2026-33017, an unauthenticated remote code execution (RCE) vulnerability in Langflow. "Over roughly 30 minutes of hands-on activity, the operator at 159.89.205.184 (DigitalOcean) downloaded a Python worker and a Go binary," the company said. While threat actors have adopted legitimate platforms and services as covert communication channels, this is the first time NATS, a high-performance communications system, has been leveraged for this purpose.
That’s it. Attackers keep winning with simple crap: fake prompts, trusted tools, weak checks, and old systems nobody wants to fix.
Do the boring work. Patch. Change keys. Check users. Test backups. Block the obvious junk. We’ll be back when the fire moves.
from The Hacker News https://ift.tt/KFBs75q
via IFTTT
Cisco Talos is tracking the active exploitation of CVE-2026-20182, an authentication bypass vulnerability in Cisco Catalyst SD-WAN Controller, formerly SD-WAN vSmart, and Cisco Catalyst SD-WAN Manager, formerly SD-WAN vManage.
Successful exploitation of CVE-2026-20182 allows an unauthenticated, remote attacker to bypass authentication and obtain administrative privileges on an affected system.
The exploitation of CVE-2026-20182 appears to have been limited so far and Talos clusters this activity under UAT-8616 with high confidence.
Talos is also aware of a series of threat actors, distinct from UAT-8616, that have been observed to be exploiting a different, previously disclosed set of vulnerabilities, in a new way than previously identified, beginning March 2026 - specifically CVE-2026-20133, CVE-2026-20128 and CVE-2026-20122. It is important to note that those vulnerabilities are distinct from and pre-date CVE-2026-20182. Cisco released software updates and a security advisory addressing those vulnerabilities in February 2026, strongly recommending customers to upgrade.
We have identified multiple clusters of post-compromise activity, beginning March 2026, associated with the exploitation of CVE-2026-20133, CVE-2026-20128 and CVE-2026-20122 that deployed webshells and other malicious tooling, described in this post.
We observed the vast majority of this exploitation involved the use of ZeroZenX labs’ proof-of-concept and accompanying JSP-based webshell which we track as “XenShell.”
UAT-8616 in-the-wild (ITW) exploitation of CVE-2026-20182
Talos is aware of the active, in-the-wild (ITW) exploitation of CVE-2026-20182 in Cisco Catalyst SD-WAN Controller and Manager, that allows log in to the affected system as an internal, high-privileged, non-root user account. Talos clusters the exploitation of this vulnerability and subsequent post-compromise activity under UAT-8616, whom we assess is a highly sophisticated cyber threat actor. UAT-8616 previously exploited a similar vulnerability in Cisco Catalyst SD-WAN Controller, CVE-2026-20127 to gain unauthorized access to SD-WAN systems.
UAT-8616 performed similar post-compromise actions after successfully exploiting CVE-2026-20182, as was observed in the exploitation of CVE-2026-20127 by the same threat actor. UAT-8616 attempted to add SSH keys, modify NETCONF configurations, and escalate to root privileges. Our findings indicate that the infrastructure used by UAT-8616 to carry out exploitation and post-compromise activities also overlaps with the Operational Relay Box (ORB) networks that Talos monitors closely.
Customers are strongly advised to follow the guidance and recommendations published in Cisco's Security Advisory on CVE-2026-20182. Customer support is also available by initiating a TAC request. Please refer to the Recommendations and Detection Guidance section for additional coverage information. We also recommend referring to Rapid7’s disclosure on CVE-2026-20182 for additional details.
In-the-wild (ITW) exploitation of CVE-2026-20133, CVE-2026-20122, and CVE-2026-20128
Talos is also aware of the widespread in-the-wild active exploitation of three vulnerabilities in unpatched Cisco Catalyst SD-WAN Manager infrastructure (CVE-2026-20133, CVE-2026-20128, and CVE-2026-20122) that, when chained together, can allow a remote unauthenticated attacker to gain access to the device. Cisco released software updates and a security advisory addressing these vulnerabilities in February 2026. Following the public release of proof-of-concept code exploiting these vulnerabilities by ZeroZenX Labs in March, we observed the exploitation of the unpatched systems from March to April 2026.
Talos has observed several other threat clusters, separate from UAT-8616, leveraging publicly available proof-of-concept exploit code to deploy webshells to affected systems. Following successful exploitation, the webshells would allow the attacker to execute bash commands on the affected system.
The vast majority of observed exploitation attempts involved the use of the ZeroZenX Labs proof-of-concept code and accompanying JavaServer Pages (JSP) shell, which we are calling “XenShell.” However, we observed several other JSP-based webshell variants, which are outlined below.
Note: The CVE referenced in the ZeroZenX Labs proof-of-concept is incorrectly attributed to CVE-2026-20127. Talos’ analysis indicates that the targeted CVEs in the proof-of-concept are in-fact CVE-2026-20133, CVE-2026-20128 and CVE-2026-20122.
So far, Talos has observed the following clusters of malicious activity being conducted post successful exploitation of CVE-2026-20133, CVE-2026-20122, and CVE-2026-20128: Cluster #1 to Cluster #10.
Cluster 1
This cluster has been actively exploiting CVE-2026-20133, CVE-2026-20128 and CVE-2026-20122 since at least March 6, 2026. Following the exploitation of these CVEs, the threat actor deployed a variant of the Godzilla web shell under the filename “20251117022131.jsp”. This variant is associated with a publicly available GitHub project.
The following IPs were used to carry out the exploit and subsequently interact with the shell:
38.181.52[.]89
89.125.244[.]33
89.125.244[.]51
Figure 1. Tas9er Godzilla shellcode deployed in Cluster #1.
Cluster 2
This cluster has been actively exploiting CVE-2026-20133, CVE-2026-20128, and CVE-2026-20122 since at least March 10, 2026. Following their exploitation, the threat actor deployed a variant of the Behinder webshell under the filename “conf.jsp”. This variant has been modified to only use Base64 for encoding, as opposed to AES encryption commonly observed in other variants.
The IP “71.80.85[.]135” was used to carry out the exploit and interact with the shell.
Figure 2. Behinder webshell deployed in Cluster #2.
Cluster 3
This cluster has been actively exploiting CVE-2026-20133, CVE-2026-20128, and CVE-2026-20122 since at least March 4, 2026. Following successful exploitation, the threat actor deployed XenShell under the name “sysv.jsp”, before returning hours later to deploy a variant of the Behinder webshell under the filename “sysinit.jsp”.
The IP “212.83.162[.]37” was used to carry out the exploit and interact with the shell.
Figure 3. Behinder webshell deployed in Cluster #3.
Cluster 4
This cluster has been actively exploiting CVE-2026-20133, CVE-2026-20128 and CVE-2026-20122 since at least March 3, 2026. Following successful exploitation, the threat actor deployed a variant of the Godzilla webshell under the filename “vmurnp_ikp.jsp”.
The following IPs are attributed to this cluster:
38.60.214[.]92
65.20.67[.]134
104.233.156[.]1
194.233.100[.]40
Figure 4. Godzilla webshell deployed in Cluster #4.
Cluster 5
Talos observed the deployment, beginning March 13, 2026, of a malware agent compiled off the publicly available AdaptixC2 red team framework. The filename was “systemd-resolved” and the agent’s command and control (C2) is “194[.]163[.]175[.]135:4445”.
The authors have changed the default TCP banner for the sample from “AdapticC2 server” to “shadowcore”. Hosted on Contabo GmbH, this is likely a VPS. As of March 28, 2026, this C2 IP, “194[.]163[.]175[.]135” hosted:
A Mythic C2 server on port 7443, along with a Mythic C2 server certificate with serial number: fece5b954e69b2c6a8d0a1029631a0d7
Another AdaptixC2 server on port 31337
An open SSH service on port 22, likely for administration of server
Cluster 6
In another cluster of activity, since at least March 5, 2026, Sliver, an open-source adversarial emulation framework (aka red-teaming implant), was deployed with the filename “CWan”. The Sliver sample’s C2 is “mtls://23.27.143[.]170:443”.
Cluster 7
In this cluster of activity, since at least March 25, 2026, an XMRig sample and its accompanying configuration file were downloaded and deployed via a shell script from the remote location “83.229.126[.]195”.
Activity observed in Cluster 8 began as early as March 10, 2026. This cluster consisted of a few key malicious tools. The first tool is KScan, an asset mapping tool, that can port scan, TCP fingerprint, capture banners for specified assets, and obtain as much port information as possible without sending more packets. It can perform automatic brute-force cracking and brute-force RDP. The tool’s filename and Go packages have been renamed to “QScan” by the authors, but it is essentially the same implementation as the open-source GitHub version.
The second tool, named “agent1”, is a Nim-based implant. It is most likely based on the open-source tools, Nimplant, but is further modified to include:
Additional commands/capabilities, such as cd to directories; cat files; download and upload files; execute files using bash; and collect system information such as username, hostname, hwid, process listings, etc.
C2 endpoints for communication, registration/check-ins, obtain tasks, provide results, and more:
/api/v1/handshake
/api/v1/results
/api/v1/payloads
/api/v1/exfiltrate
/api/v1/tasks
/api/v1/init
An RSA public key to be used by the agent to communicate with the C2 hosted on “hxxp://13[.]62[.]52[.]206:5004”.
This tool was downloaded and executed post-compromise from the remote location “replit[.]dev”:
Figure 6. Download and startup script for the Nim-based implant.
The attackers executed this command on the compromised system while connected from the source IP “79[.]135[.]105[.]208”. This is likely a ProtonVPN node.
Replit is an AI platform that facilitates building applications using AI. It is therefore likely that the backdoor was created with the help of AI to resemble Nimplant’s functionality with the additional capabilities and deviations listed above.
Cluster 9
In this cluster, since at least March 17, 2026, Talos observed the deployment of an XMRig miner and a peer-based proxying and tunneling tool.
This tool, gsocket, is a peer-based proxying and tunneling tool that allows peers to connect to each other within the Global Socket Relay Network (GSRN). GSRN allows peers to connect to each other using node IDs, which are unique 16-byte identifiers for nodes with the network.
This sample obtains the peer or C2 node to connect to by reading and Base58 decoding the accompanying “defunct[.]dat” file. The C2 peer ID is:
78 c4 a2 37 56 27 7b b7 de 20 06 76 34 d2 63 c9
The tool is activated by placing a malicious command in the .profile file:
This decodes to:
XMRig Miner
Accompanying gsocket was a Monero miner and its scripts and configuration files. The miner is also activated via the user profile (.profile):
The “miner.sh” will find all processes named XMRig, kill them, and then start its own copy of XMRig:
Cluster 10
This cluster of activity, since at least Mar 13, 2026, consisted of a credential stealer deployed along with accompanying scripts. The main script, named “loot_run.sh”, attempted to obtain:
The admin user’s hashdump
JSON Web Tokens (JWT) key chunks that are used for REST API authentication
AWS credentials for vManage: AccesKeyId, SecretAccessKey and Token
Two other helper scripts were also deployed in this cluster to check if the current user could escalate to root. The scripts contained a hardcoded password and used it to execute the command su root –c id. The output is checked for the string “uid=0(root)” to verify successful escalation.
Recommendations and detection guidance
Customers are strongly advised to follow the guidance and recommendations published in Cisco's Security Advisory on CVE-2026-20182. Customer support is also available by initiating a TAC request. Talos strongly recommends that customers and partners using Cisco Catalyst SD-WAN technology follow the steps outlined in this advisory to help protect their environments. We also recommend referring to Rapid7’s disclosure on CVE-2026-20182 for additional details.
Designing Secure Autonomous AI Agents with Defense in Depth
AI agents are moving beyond assistance and into action. Instead of generating content, they invoke tools, modify data, trigger workflows, and operate across systems with increasing autonomy. This shift changes the security problem fundamentally. When an agent can act autonomously, mistakes propagate faster, blast radius increases, and rollback becomes harder.
Security for agentic AI relies on defense in depth. What changes with autonomous agentic AI is where security decisions matter most. As autonomy increases, the center of gravity moves away from the model alone and toward how agents are assembled, constrained, and governed inside real applications. To build agentic AI applications that can be operated safely at scale, you need to deliberately design how agents are assembled, constrained, and governed within real applications. In return, you increase the likelihood of predictable behavior, controlled blast radius, and the confidence to deploy autonomy in production.
Defense in depth for agentic AI systems
Agentic AI systems are vulnerable to the existing security risks of software systems, and introduce new threat classes: agent hijacking, intent breaking, sensitive data leakage, supply chain compromise, and inappropriate reliance. Any weakness in permissions, data protection, or access control that exists today is amplified when an agent is added to the system.
Model layer: Influences how the agent reasons through training data, fine-tuning, and refusal behaviors.
Safety system layer: Provides runtime protections such as content filtering, guardrails, logging, and observability.
Application layer: Defines what the agent can do and how it does it through application architecture, permissions, workflows, and escalation paths.
Positioning layer: Shapes how the system is presented to users through transparency documentation and UX disclosure.
Each layer reinforces the others, and no single layer is sufficient on its own. The model layer is probabilistic by nature. The safety system layer observes and intervenes at runtime. The positioning layer shapes perception. But for organizations building agentic AI applications, the application layer is the decisive one because it is the only layer builders fully control. The application layer translates probabilistic model behavior into deterministic system outcomes. This is also where customers turn generic components into differentiated systems: two organizations can start with the same model and tools and end up with very different security outcomes depending on how they constrain agent behavior at this layer.
Why the application layer matters most when building agentic AI applications
Most organizations build agentic AI applications by combining off-the-shelf models, tools, and business data into systems that perform specific tasks. The application layer is where they decide which actions an agent is allowed to take, which tools and data it can access, how permissions are scoped and enforced, how failures are handled, and when humans must be involved.
Getting these decisions right requires thinking through several specific design patterns. Each one addresses a distinct failure mode. Together, they form the practical expression of defense in depth at the application layer.
Here are some recommended design patterns for building a more resilient application layer for your agents.
Pattern 1: Design agents like microservices
The most consequential application layer decision is action scope: how broadly you define an agent’s responsibilities. A common and dangerous failure mode is the “everything agent,” a single agent with broad permissions, many tools, and loosely defined responsibilities. Every additional tool expands the attack surface. Every ambiguous instruction increases the risk of error or task drift. As autonomy and tools increase, these risks compound quickly.
A more resilient approach is to design agents the way distributed systems have been designed for decades: as carefully scoped components with bounded capabilities. Agents should have isolated permissions, clear interfaces, and narrow responsibilities. More complex behaviors emerge from orchestration rather than from granting a single agent broad authority. Building agents like microservices, with constrained responsibilities and scoped permissions by design, is one of the most effective structural controls available at the application layer.
Pattern 2: Least permissions
Bounded scope defines what an agent is responsible for. Progressive permissioning governs what actions are permitted within that scope. As a rule, permissions should always start at zero (“zero trust”).
For safe design, no actions should be permitted by default. Actions are enabled explicitly, based on role and system needs. Least-privilege and zero-access principles apply to agents just as they do to human users.
Permissions granted loosely at design time become exploitable surfaces at runtime.
In practice, this means every tool call, data access, and external integration an agent can invoke should be the result of a deliberate authorization decision, not an implicit one. The question is not “should we restrict this?” but “have we explicitly permitted this?”
The general rule is to scope capabilities to the duration of a specific task. If task-based limits aren’t feasible, implement time-based limits. Task-focused permissions are preferred because they naturally “expire” when the task completes; temporal permissions help limit blast radius.
Pattern 3: Deterministic human-in-the-loop design
Even well-scoped, well-permissioned agents need a governance backstop for high-stakes decisions. Human-in-the-loop (HITL) review is often discussed as a trust mechanism: a way to keep humans informed. In agentic systems, it is better understood as a governance mechanism: a structural control that prevents agents from self-authorizing consequential actions.
The critical design mistake here is letting the model decide when human review is required. If escalation is left to probabilistic reasoning, an adversarial prompt or an ambiguous instruction can bypass review entirely. A model that reasons its way out of escalating is exhibiting exactly the behavior the escalation mechanism was supposed to catch.
In secure agentic systems:
HITL review ideally is enforced deterministically by the application layer, or orchestrator, not delegated to the model.
Escalation triggers are defined in code.
An orchestrator enforces HITL review triggers.
Intervention can occur mid-execution — including during tool calls — rather than only before or after an action completes.
This design removes ambiguity about when review is required, supports auditability for oversight and compliance, and ensures that as agents move toward greater autonomy, the separation between reasoning and enforcement remains intact.
Pattern 4: Agent identity as a security primitive
It is an unfortunate reality that human users are routinely over-permissioned (“give them access to everything”). To implement Pattern 1: Agents as Microservices and Pattern 2: Least permissions, agents must never have the same identity as the user. This sounds obvious, but it requires deliberate design: When an action is taken, you need to know if it was executed by the user, the agent was acting on its own behalf, or the agent acting on the user’s behalf. Each agent must be assigned a unique, verifiable identity which allows assignment of explicit and narrowly scoped permissions, lifecycle controls, and accountability.
Agent identity enables least-privilege enforcement, because you cannot scope permissions to a specific agent if you cannot distinguish that agent from other agents or a human user. It also enables lifecycle governance, because revocation actions won’t be invoked when many agents are affected. Finally, separate agent identity enables meaningful observability, because actions can be traced back to a specific agent rather than being attributed vaguely to “the system.”
As enterprises manage agent sprawl (with more agents, more deployments, and even more integrations), identity clarity becomes operationally critical. Identity is not a feature you add later. It is a prerequisite for operating autonomous agents responsibly at scale, and it ties together every other application layer pattern: permissioning, escalation, and logging all depend on knowing which agent is acting.
How the Other Layers Reinforce Application‑Layer Design
Focusing on the application layer does not diminish the importance of the other layers. Instead, it clarifies their roles.
The model layer – the model chosen to enable the application – shapes how an agent reasons, but remains probabilistic. It can be tuned toward safer behavior, but it cannot guarantee it.
The safety system layer – platform tools like content filters and groundedness detection – compensates for what models alone cannot prevent: it detects anomalies, filters harmful outputs, and fulfills the observability teams’ need to respond when something goes wrong.
The positioning layer – how the UI and UX explains that AI is in use, what it can do, and what it can’t do
Each layer addresses failure modes the others cannot fully cover. A strong safety system cannot compensate for an agent with unlimited scope. A well-tuned model cannot substitute for deterministic escalation triggers. The application layer is where the load-bearing decisions are made. The other layers make those decisions more resilient.
Designing for Secure Autonomy
The four patterns described here — agents as microservices, least permissions, deterministic human-in-the-loop design, and agent identity — are mutually reinforcing. Scope containment limits blast radius. Permissioning limits what a contained agent can do. Deterministic escalation ensures that neither scope nor permissions can be circumvented by adversarial input. Identity makes all of it auditable.
The application layer is where customers have the most power to shape how their agent behaves. It is where off‑the‑shelf models become real agentic AI applications. It is where security decisions shape both business value and risk. Defense in depth remains the right strategy. As agents take on more responsibility, the application layer becomes the place where that strategy succeeds or fails.
As organizations deploy more agentic AI systems, the question is not whether agents will make mistakes. They already have and will continue to. The question is whether those mistakes are minimized, identified, and contained. Secure autonomous agentic AI systems are achieved by designing systems where autonomy is bounded by architecture, permissions, identity, and deterministic oversight from the start.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.
Kazuar, a sophisticated malware family attributed to the Russian state actor Secret Blizzard, has been under constant development for years and continues to evolve in support of espionage-focused operations. Over time, Kazuar has expanded from a relatively traditional backdoor into a highly modular peer-to-peer (P2P) botnet ecosystem designed to enable persistent, covert access to target environments.
This upgrade aligns with Secret Blizzard’s broader objective of gaining long-term access to systems for intelligence collection. The threat actor has historically targeted organizations in the government and diplomatic sector in Europe and Central Asia, as well as systems in Ukraine previously compromised by Aqua Blizzard, very likely for the purpose of obtaining information supporting Russia’s foreign policy and military objectives.
While many threat actors rely on increasing usage of native tools (living-off-the-land binaries (LOLBins)) to avoid detection, Kazuar’s progression into a modular bot highlights how Secret Blizzard is engineering resilience and stealth directly into their tooling. By separating responsibilities across Kernel, Bridge, and Worker modules and restricting external communications to a single elected leader, Kazuar reduces its observable footprint. It also maintains flexible tasking, data staging, and multiple fallback channels for command and control (C2). Understanding this architecture helps defenders move beyond single sample analysis and instead focus on the behaviors that keep the botnet operational: leader election, inter-process communication (IPC) message routing, working directory staging, and periodic exfiltration.
Kazuar’s capabilities and tradecraft have been widely documented by the security research community, and prior reporting, including Unit 42’s write-up and a recent deep dive into its loader capabilities, remains relevant today. This blog is an in-depth analysis of Kazuar’s progression from a single, monolithic framework into a modular bot ecosystem composed of three distinct module types, each with clearly defined roles. Together, these components distribute functionality across the P2P botnet, enabling flexible configuration, lower observability, and broad tasking while minimizing opportunities for detection.
Delivery
Kazuar is delivered through multiple dropper variants. In one observed method, the Pelmeni dropper embeds the encrypted second-stage payload directly within the dropper as an encrypted byte array. The payload is often bound to the target environment (for example, encrypted using the target hostname) so it only decrypts and executes on the intended host.
In another method, the dropper deploys a small .NET loader alongside the final payload. The dropper then invokes the loader (often configured as a COM object) and supplies the decrypted payload, allowing it to load and execute the Kazuar modules.
Figure 1. Example delivery chain: a dropper deploys a lightweight .NET loader and supplies the decrypted Kazuar payload for in-memory execution.
Module types
There are three distinct types of modules: Kernel, Bridge, and Worker. The next sections explain the functionality contained in each type and how they interact with each other.
This diagram shows the general interactions between a set of modules on a single host. Each infected host needs to have all three modules to create the full P2P network:
Figure 2. Overview of Kernel, Bridge, and Worker module interactions on a single host, showing internal IPC and external C2 routing through the Bridge.
Note: We use ALL CAPS when referencing identifiers taken verbatim from the malware (for example, internal module and thread names, message types, configuration keys, or mode/flag values).
Type: Kernel
The Kernel module serves as the central coordinator for the botnet. It issues tasks to Worker modules, manages communication with the Bridge module, and maintains logs of actions and collected data. Early in execution, the Kernel module performs extensive anti-analysis and sandbox checks. These behaviors are well documented in the Unit 42 write-up and include standard checks such as:
Checking for running processes containing analysis tools
Checking for canary files on the desktop
Checking the loaded process for sandbox-related DLLs
Module configuration
Once these checks are passed, the Kernel module sets up the environment based on numerous configuration options. Previous versions of Kazuar have used separate files containing the configuration information, but these are now embedded in the samples and have significantly increased the number of configurations available to the malware family.
The configuration set can vary across 150 different configuration types, C2 communication infrastructures, or tasking options generally defined by eight functional categories. Any operational configuration in use can be updated at any time from the C2 server. The following table contains some examples and descriptions of the categories.
Controls how the malware communicates with C2 infrastructure, including HTTP and WebSocket transports, Exchange Web Services (EWS) email-based C2, heartbeat intervals, and connection parameters
Defines how the malware executes and persists in memory, including process injection techniques (inject/remote/zombify/combined/single), module loading, and process hosting strategies
Configures evasion techniques to avoid detection by security tools, including bypasses for Antimalware Scan Interface (AMSI), Windows Lockdown Policy (WLDP), Event Tracing for Windows (ETW), and anti-debugging/anti-dump protections
Controls when and how collected data is exfiltrated, including working hours restrictions (8:00 AM – 8:00 PM default), weekend behavior, chunk sizes, retry limits, and rate limiting to blend with normal network traffic
Manages execution of received tasks/commands, including timeouts, thread pool sizing, retry logic, deadlock detection, and task queuing/storage parameters
Maintains agent identity and operational state, including unique identifiers, working directories, startup tracking, shutdown flags, and initial reconnaissance behavior
Controls active surveillance capabilities, including keylogging (buffer size, flush intervals), screenshot capture, credential theft, Messaging Application Programming Interface (MAPI) email monitoring, and configurable monitoring rules/intervals.
Table 1. Configuration options
This configuration exposes three internal communication mechanisms:
Window Messaging
Mailslot
Named pipes
There are also three different communication protocols for external communication:
Exchange Web Services (EWS)
HTTP
WebSockets (WSS)
They typically contain redundant or fallback communications to maintain access in the event of the failure of a single point of contact.
Leadership election
One of the methods that Kazuar uses to limit external communication is to use a single Kernel leader per botnet. In this architecture, the Kernel leader is the one elected Kernel module that communicates with the Bridge module on behalf of the other Kernel modules, reducing visibility by avoiding large volumes of external traffic from multiple infected hosts.
There are several conditions that determine whether a new leader needs to be elected among participating Kernel modules:
There currently is no leader.
The leader announces it is shutting down.
The leader announces it is logging off.
If an election does not result in a leader due to an error, a new election will be called.
Elections occur over Mailslot, and the leader is elected based on the amount of work (length of time the Kernel module has been running) divided by interrupts (reboots, logoffs, process terminated). Once a leader is elected, it announces itself as the leader and tells all other Kernel modules to set SILENT.
Figure 3. Kernel leadership election overview showing a single active leader and multiple client Kernel modules operating in SILENT mode
Only the elected leader is not SILENT, which allows the leader Kernel module to log activity and request tasks through the Bridge module. Client Kernel modules still participate in internal IPC (for elections, status, and delegated work), but they don’t independently request tasks from the Bridge module. Before entering SILENT mode, each client Kernel module sends a CLIENT announcement, which causes the leader to add it to the maintained agent list.
With the hierarchy established, the work can be done. Several threads and communication types are initialized to perform the work and communicate between modules.
REMO thread
The REMO thread sets up a named pipe channel between Kernel modules so the leader can exchange messages with other Kernels. By default, the pipe name is the MD5 hash of pipename-kernel-<Bot version>, which results in a pipe path such as \\.\pipe\82760B84F1D703D596C79B88BA4FAC1E. The name could be modified through additional strings passed into the name-building function, but this pattern is the default. This channel lets the leader target specific client Kernel modules when delegating work.
Messages over this pipe are AES-encrypted and begin with a PING/PONG handshake. After that, the leader could:
Request another Kernel module’s logs
Assign tasks to a client Kernel module
Because only the Kernel leader is allowed to request tasks through the Bridge module, it distributes work to the other Kernel clients over named pipes. If the leader receives a task destined for a different bot, it forwards the task to the appropriate client Kernel module through this channel.
MSGW thread
For Kernel-to-Worker and Kernel-to-Bridge communication, Kazuar uses one of two IPC mechanisms:
Window Messaging [default selection]
Registers a hidden window
Mailslot
Registers a Mailslot
Based on its initial configuration, Kazuar selects one of these communication types to listen for incoming communication, with the default being Windows Messaging.
Window Messaging setup
This technique involves creating a hidden window and registering a ClassName and WindProc. The ClassName is simply the module name (for example, Bridge), and the WindProc is the general-purpose message handler.
This allows other processes to look up the window by ClassName and use several different APIs to send a message to that window. When the window receives a message, the WindProc is executed to parse it and carry out the requested action.
Mailslot setup
The Mailslot name is derived by hashing the string “mailslot-” plus the module name (Bridge/Kernel/Worker). The configuration can optionally append an additional identifier (empty by default), which allows deployments to create distinct Mailslot namespaces when needed.
Figure 4. Example IPC message type identifiers used for inter-module communication within the botnet.
The string is hashed and used as the name to create the Mailslot: \\.\mailslot\<generated hash>.
A thread is created that checks every three seconds for new messages using the API GetMailslotInfo, and when it finds one, it parses the incoming message.
Message types
Regardless of what message delivery system is selected, the message is parsed by the same handler function. For the Kernel module, this message parsing function has numerous expected communication messages, since it controls all the modules execution flows.
The following message table describes the incoming and outgoing messages for the Kernel, what actions precipitate a message, and what the Kernel does when it receives each message:
Kernel outgoing MsgType
MsgType reason
Module(s)
Kernel incoming MsgType
Kernel actions
TASK
– Issue task to worker
Worker
TASK_RESULT
– Response message is logged by the Kernel – Result file is created with results of the task
CHECK
– Only the leader can send this – Request new tasks from remote C2
Bridge
CHECK_RESULT
– If the C2 has tasks, the Kernel creates a task file – Can also receive alternate C2 URLs that are added to the stored configuration
SYN
– Target module needs to request a new config
Bridge, Worker
GET_CONFIG
– Kernel sends its configuration to the requesting module
(Worker thread – PEEP)
– Configuration-based
Worker
PEEP
– PEEP result file is written unless it has reached its configured max PEEP number
SEND
– Send result file to be forwarded to C2
Bridge
SEND_RESULT
– Result file is deleted
(Worker thread – KEYL)
– Configuration-based
Worker
KEYLOG
– Writes keylog data to keylog output file
(Multiple Filesystem Worker threads)
– Configuration-based
Worker
AUTOS
– Writes AUTO data to AUTOS output files
Table 2. Message types
SEND thread
The configuration specifies an external communication method from the available communication modes
HTTP [default selection]
Web Socket Server (WSS)
Exchange Web Server (EWS)
These configurations can be changed at any point when the C2 sends a new configuration, or a change communication task is issued to it. It also contains a heartbeat timer that is defined in the configuration for the SEND actions to occur with the default timer being every hour. There are also working timers that can install a blackout period on communications to blend in with the target environment.
Figure 5. External communication (SEND) configuration, including transport selection, timers, and blackout/heartbeat controls.
Note: Only the elected Kernel leader can perform the following actions:
If the Kernel has task results
Read in the task file
Send SEND message to Bridge with the task result file
Get new tasks from Bridge
Send CHECK message to Bridge
Table 2 describes what the Kernel expects in return for these messages. The messages are sent asynchronously and recorded as tasks by the Kernel.
There is also a failsafe communication method that allows the Kernel to directly contact the remote C2 if the Kernel is unable to communicate with the Bridge module. Essentially, if all communication attempts fail and a certain amount of time has elapsed, the Kernel module requests tasks directly from the remote C2.
SOLV thread
This thread executes when the heartbeat timer expires to handle any tasks that the Kernel is tracking. This thread performs several functions related to the current task list:
Loop through the list of current tasks
Check if aborted flag is true
Issue TaskKill message to the worker (Window Messaging)
Remove task from task list
Check if task has exceeded the configured max working time for task
Issue TaskKill message to the worker (Window Messaging)
Set aborted flag for task to true
Remove task from task list
Read in all task files from the working directory
If the task is new
Add task to task list
Type: Bridge
The Bridge module provides the botnet’s external communications layer, acting as the proxy between the leader Kernel module and the C2 server regardless of the transport method selected. Since each Kernel module has its own Worker and Bridge module, if a new leader is elected, then that new leader Kernel module uses its Bridge module for communication. It typically has the same default configuration as the Kernel module but does contain a few different operations that set up the initial infection.
The Bridge module initializes its core object with basic metadata and instantiates two supporting components that provide the module’s primary functionality:
Server Communication module
Task Handling module
The module registers handlers for two system-level events. These handlers define how the module should respond when specific system events occur:
SystemEvents.SessionEnded
SystemEvents.PowerModeChanged
When an event is triggered, the corresponding handler function is invoked, allowing the module to determine the appropriate action for that event. Events are typically ignored unless they require explicit handling.
The module only terminates when the system is shutting down; all other events do not affect its lifetime. Based on its initial configuration, which should match the Kernel module configuration, it selects either Mailslot or Windows Messaging as the IPC mechanism used for communication between modules. Once the setup steps is completed, the module is ready to proxy communication between the leader Kernel module and the C2 server.
Type: Worker
The initial Worker configuration mirrors the structure of other module configurations and follows the same overall layout. Based on its initial configuration, the Worker module selects either Mailslot or Windows Messaging as the IPC mechanism used to communicate between modules. The default configuration for this botnet uses Windows Messaging; further details on the window setup are described below.
During initialization, the Worker configuration instantiates several objects responsible for the module’s primary functionality. Each object is executed within its own named thread. These components include:
Task Solver
Handles task tracking
Peep
Hooks windows events
Has a max number of windows to hook set by the configuration
Keylogger
Filesystem
GINFO – Gather system info
GFIL – Gather file listings
Recent files
Desktop
Malware working directory
GHOO – Window information
GMAP – Gather MAPI info
Email information
Data collected by these components is aggregated, encrypted, and written to the malware’s working directory, where it is staged for subsequent exfiltration to the C2 server.
Botnet operations
With the botnet setup complete, configurations instantiated, and a leader elected, Kazuar transitions into its steady state operational phase. In this state, the elected Kernel leader centrally coordinates tasking and data collection across participating modules while maintaining a deliberately low observable footprint. Worker modules execute tasks asynchronously based on configuration and assignments received from the Kernel, collecting system, file, window, and user activity data according to defined schedules and limits.
Module-to-module messaging
When one module needs to communicate with another, all required information is assembled into a structured message packet. Multiple packet formats are defined, with the specific format determined by the message type and intended action.
These message packets are constructed using Google Protocol Buffers (Protobuf), which provides a structured, schema‑based format similar in concept to JSON. Using Protobuf allows the malware to efficiently serialize, transmit, and parse messages through standard library functions.
Messages destined for the Bridge module include additional fields that describe how the request should be forwarded to the remote C2 infrastructure. These fields specify transport level details, including the external communication mechanism to be used.
Figure 6. Protobuf-based message structure used to route requests between modules and describe how the Bridge should forward traffic to C2.Figure 7. Additional message fields and transport parameters that influence delivery method (e.g., HTTP vs. EWS) and destination module.
The TransportType field can specify one of three supported communication methods. The default transport is typically HTTP, using the C2 URLs in the default configuration.
When sending a message, the dispatch function examines the contents of the message packet to determine the appropriate delivery mechanism, resolves the corresponding Mailslot name or window class identifier, and routes the packet to the intended module.
For example, if the TransportType is set to EWS, the packet is delivered to the Bridge module, which then uses its Exchange communication component to encapsulate the data and deliver it to the remote C2 server via email.
Figure 8. Example routing flow when TransportType is set to EWS, where the Bridge encapsulates data and delivers it to C2 via email-based communication.
Messages originate from the Kernel leader, except for a couple of worker tasks that send messages to the Kernel module based on their configuration.
Figure 9. High-level module messaging map showing how the Kernel leader coordinates Worker tasking and uses the Bridge module for external C2 communications.
Working directory
Kazuar uses a dedicated working directory as a centralized on‑disk staging area to support its internal operations across modules. This directory is defined through configuration and is consistently referenced using fully qualified paths to avoid ambiguity across execution contexts. Within the working directory, Kazuar organizes data by function, isolating tasking, collection output, logs, and configuration material into distinct locations. This design allows the malware to decouple task execution from data storage and exfiltration, maintain operational state across restarts, and coordinate asynchronous activity between modules while minimizing direct interaction with external infrastructure. Collected artifacts are typically written incrementally, encrypted before staging, and retained locally until explicitly forwarded to the C2 infrastructure through the Bridge module.
Within this working directory, Kazuar maintains separate storage locations for the following functional data types:
Peeps
Autos
Files
Hashes
Result files
Task files
Config files
Common wordlist
Common exe
Logs
Keylogger
This structured use of the filesystem enables Kazuar to operate modularly, maintain persistence state across leadership changes or reboots, and blend malicious activity into routine file system usage.
Module tasks
The list of commands available for the Worker modules to perform is extensive and has many features, from arbitrary command/script execution to preformatted forensic data collection functions, as described in the Unit 42 blog.
The Kernel module task handler has a few additional functions that handle commands issued from the leader Kernel module.
Task
Description
kernel
A list of commands to be executed by the Kernel module
delegate
Send command via Named pipe to targeted Kernel module
modules
Handles the list of agents maintained by the Kernel module list – List modules in the agents list clear – Clear list of agents add – Add an agent to the list by ID remove – Remove an agent from the list by ID
autoslist
Gets list of hashes and files collected by autos
autosget
Sends all of the autos files to requesting module and deletes autos files
autosdel
Deletes all autos files
Table 3. Module tasks
System info gathering
System info gathering is often enabled by default in the configuration. This causes an initial collection of system information when the agent starts up. This task collects an extensive amount of information about the system and its user.
Optional OS features Installed AV AMSI provider Security packages AppLocker setting Logical drives USB devices Network adapters ARP tables Network connections Network shares RDP hints Running processes Loaded modules (current process)
Pipe list Active windows Recent documents Outlook downloads Recent items OS info System Boot events Hardware info User info Local users Logon sessions User profiles Special folders Explorer Run command history
Explorer typed paths Explorer search history Environment variables UAC settings Internet settings DNS cache Network PowerShell versions WSUS settings Installed software Hot patches Update history Services Drivers
Table 4. List of system info gathered
Screenshots are also taken through various methods and saved for exfiltration both automatically through the configuration or when a task is issued.
Who is Secret Blizzard?
The United States Cybersecurity and Infrastructure Security Agency (CISA) has attributed Secret Blizzard to Center 16 of Russia’s Federal Security Service (FSB), which is one of Russia’s Signals Intelligence and Computer Network Operations (CNO) services responsible for intercepting and decrypting electronic data as well as the technical penetration of foreign intelligence targets. Secret Blizzard overlaps with activity tracked by other security vendors as VENOMOUS BEAR, Uroburos, Snake, Blue Python, Turla, WRAITH, and ATG26.
Secret Blizzard is known for targeting a wide array of verticals, but most prominently ministries of foreign affairs, embassies, government offices, defense departments, and defense-related companies worldwide. Secret Blizzard focuses on gaining long-term access to systems for intelligence collection using extensive resources such as multiple backdoors, including some with peer-to-peer functionality and C2 communication channels. During intrusions, the threat actor collects and exfiltrates documents, PDFs, and email content. In general, Secret Blizzard seeks out information of political importance with a particular interest in advanced research that might impact international political issues.
Mitigation and protection guidance
To harden networks against the Secret Blizzard activity listed above, defenders can implement the following:
Strengthen Microsoft Defender for Endpoint configuration
Microsoft Defender XDR customers can implement attack surface reduction rules to harden an environment against techniques used by threat actors.
Ensure that tamper protection is enabled in Microsoft Defender for Endpoint.
Run endpoint detection and response (EDR) in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus does not detect the threat or when Microsoft Defender Antivirus is running in passive mode.
Configure investigation and remediation in full automated mode to let Microsoft Defender for Endpoint take immediate action on alerts to resolve breaches, significantly reducing alert volume.
Strengthen Microsoft Defender Antivirus configuration
Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving threat actor tools and techniques.
Encourage users to use Microsoft Edge and other web browsers that support SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that host malware.
Implement PowerShell execution policies to control conditions under which PowerShell can load configuration files and run scripts.
Microsoft Defender customers can refer to the list of applicable detections below. Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.
Microsoft Defender for Endpoint – Secret Blizzard actor activity detected
Microsoft Security Copilot
Microsoft Security Copilot is embedded in Microsoft Defender and provides security teams with AI-powered capabilities to summarize incidents, analyze files and scripts, summarize identities, use guided responses, and generate device summaries, hunting queries, and incident reports.
Security Copilot is also available as a standalone experience where customers can perform specific security-related tasks, such as incident investigation, user analysis, and vulnerability impact assessment. In addition, Security Copilot offers developer scenarios that allow customers to build, test, publish, and integrate AI agents and plugins to meet unique security needs.
Threat intelligence reports
Microsoft Defender XDR customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.
Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
