Welcome to Issue #157 of Detection Engineering Weekly!
Every week, I read, watch and listen to all the Detection Engineering content so you can consume it all in 10 minutes. Subscribe and get a weekly digest of the latest and greatest in threat detection engineering!
✍️ Musings from the life of Zack:
Spring in Maine is finally here, and it feels like a Disney movie at the Allen household with all of the animals coming out. We have two bird nests, a family of deer, and now a woodchuck named Chippy prancing around
Speaking of Maine, I had the most Maine dinner with some friends the other night. They hunted a Moose and cooked Moose steaks for the family. Afterward, we had dessert with maple syrup tapped from trees in their yard. Moose was not that gamey, and I’d try it again!
Sabres lost :( But I’m super excited to watch this young team in the coming years, so if you are a hockey fan, don’t tease me too much because I’m still hurting from the loss
The best threat intelligence is generated by your coworkers
Security Operations teams rely heavily on detection rules and threat intelligence to stay ahead of threats. But, the AI of today focuses on social engineering your coworkers, such as deep fake interviews, voice phishing, and impersonating executives. Training your employees to spot and report AI attacks can provide valuable signals that no security product can match.
Adaptive trains your organization to spot, report, and stop these AI threats before they reach your perimeter.
Shai-Hulud Goes Open Source by Ryan Simon, Sebastian Obregoso and Greg Foss
~ Note, Datadog is my current place of employment, and the authors here are my colleagues ~
I’ve covered several supply chain attacks linked to TeamPCP and one of their worm-based toolsets, Shai-Hulud. This week, GitHub repositories popped up and were quickly taken down, hosting the potential source code for Shai-Hulud.
The team here did a deep dive on its architecture, how it deploys loaders and malware, its C2 infrastructure, and its credential exfiltration techniques.
The Mutator step, which enables Shai-Hulud’s propagation and worm-like capabilities, is super interesting. There are three propagation mechanisms: one I was familiar with, npm credential publishing, and two I wasn’t familiar with, cache poisoning and developer environment poisoning. Every stolen secret can be used to propagate malware across various developer environments and IDEs, such as Claude Code and VSCode.
The two npm-related techniques rely on insecure configurations for publishing npm packages. For example, if you store npm publishing tokens in your GitHub Actions pipeline, it’ll automatically download the latest version of your release, increment the semver to make it the latest branch, then deploy it, causing the post-install hooks to run, which contain the malware.
“Leaks” of malware source code like this help provide insight into how threat actors think about exploiting misconfigurations and security gaps in their targets. It’s hard to say whether this is the “real one”, but there is threat intelligence floating around social media that TeamPCP & cybercriminal forums are teaming up for a Supply Chain Competition to see who pulls off the most impactful breach with Shai-Hulud.
Wiring Live Threat Intel into Sigma Detection with Dynamic Pipelines by Mostafa Moradian
Most SIEMs let you manage threat intelligence as lookup tables or reference lists that detection rules can query against. A rule checks a destination IP against a known C2 list; the list is updated by a feed; the rule stays the same. It is one of the more practical parts of how enterprise detection pipelines handle the IOC lifecycle. It’s also VERY hard to manage, and without understanding the underlying engineering required to handle dynamic tables, you can produce stale IOCs for your detections, or worse, miss emerging IOCs and fall victim to false negatives.
Moradian has been building toward the same capability in his RSigma project. I first covered the project in #149, when it was a Rust CLI for evaluating Sigma rules against JSON logs without any infrastructure. By #154, it had grown into a streaming daemon with NATS and HTTP log inputs, stateful correlation windows, and Prometheus metrics.
The latest addition here is dynamic pipelines: instead of hardcoding IOC values in rule YAML, you declare external sources in the pipeline config, and RSigma fetches and injects them at evaluation time. This works very similarly to how I’ve seen SIEMs implement threat intelligence pipelines, but since it’s RSigma, it’s self-contained within its ecosystem.
The practical demo is a firewall detection rule with a single field: DestinationIp: “%c2_ips%”. The pipeline pulls the Feodo Tracker C2 blocklist, a public JSON feed covering Emotet, Dridex, TrickBot, and QakBot updated every five minutes, extracts the IP array, and expands that placeholder before the rule evaluates. If the feed is unreachable, RSigma falls back to the last cached data so you do not lose coverage during a transient outage. The rule author never touches an IOC value again.
I thought this was a neat video by the Anthropic team, featuring a friend of the newsletter, Jackie Bow, on how their internal detection & response team uses Claude! They built a tool called CLUE, which they first featured at BSides SF in 2025. It looks similar to a co-pilot tool from AI SOC vendors, but it's their own internal version. I think it helps make the case for those who choose to go build versus buy, by offering control over which features go in and out of the tool, an integration catalog focused on systems you deploy for your organization, and a tighter feedback loop.
The case against is a capacity-and-cost problem. It is attractive to buy AI SOC-like tools if you are budget-constrained or don’t have the talent to build and maintain one.
Ok, a lot of media on this issue, but hear me out. Odd Lots is a Top 3 podcast for me, and its focus is Finance topics. They bring on amazing guests that talk about everything from the economics of milk to tarriff refunds at shipping ports and even cybersecurity.
I chose this episode because its about the history and economics of deep-sea cables, with a particular focus on Internet cabling. We seriously don’t appreciate how complicated and opaque this process is for the end user. So, if you want to learn about Internet-scale issues, you must learn about the physical nature of operating the Internet!
The Ultimate Guide to Detection Engineering with Censys by Alex Gartner
In this post, Censys detection engineer and security researcher Alex Gartner helps readers understand how to integrate detection engineering concepts into Censys’ internet-wide scanning data. This is especially interesting to me in a few ways:
I’ve rarely read posts on how to integrate Internet scan data as correlation rules with traditional telemetry from the endpoint or network
Understanding how attacker infrastructure can be fingerprinted is a valuable skill in itself; it’s not all just IP address and domain matching
Speaking of IP addresses: threat intelligence is much more useful when it’s clustered and used as an enrichment, and we leave out a lot of interesting threat intelligence indicators
I’ve been a big fan of Censys since they started their company several years ago. And luckily, many of the concepts Gartner discusses are available in community edition accounts. I typically don’t link to vendor blogs that talk about their products unless they offer free or community-edition access, so you can try these concepts out by signing up.
Grafana, an observability company with a large open-source following, disclosed a security breach in which attackers obtained an administrative-level GitHub access token. They don’t specifically say if it’s a long-lived token, which GitHub has urged customers to use, but it’s likely if it survived a CI/CD build run. The group behind the incident, Coinbase Cartel, also likely used a pwn request to take the token and subsequently exfiltrate their entire codebase.
The group tried to extort Grafana with a ransom demand, but Grafana said in their tweet that they refused to pay. This is the right approach, since paying doesn’t guarantee that the thiefs won’t sell it to someone else.
Oh look, a VPS I purchased 8 months ago. by Jonathan Canlas
In this post, Canlas, a detection engineer, stumbled upon a VPS they had purchased several months ago and had accidentally left running. They turned it into a honeypot to understand what kinds of attacks it attracts, using subsequent telemetry to learn more about the research and detection workflow. I appreciated reading this post because most honeypot stories I read follow a formula: a lab that deploys a honeypot. This one, in particular, offers much more insight into Canlas’ experience as a detection engineer and how they approached the deployment through a lens of hypothesis-driven research.
Novel Evilginx Frontend - Lowering the barrier for token theft reuse by Paul Newton
Evilginx is a legitimate open-source framework that helps red-teamers build and deploy phishing pages with easy-to-use templates. There is a pro version where the company behind Evilginx vets prospects to ensure they aren’t evil, but the open-source version gets a lot of traction from bad guys. In this post, Newton was hunting for M365-related phishing kits and found a cleverly built M365-themed management interface. IMHO, it makes the post way more interesting since it’s about this peculiar management tool.
The potential threat actor built this front end to manage stolen M365 tokens at scale. They can switch between victim tokens within a single interface, import stolen tokens from their Telegram bot, and execute attacks with a single click.
A single stolen token grants the operator access to several products in the M365 suite, up to and including pivoting to take over the Entra environment.
When AI doomers or marketers post about the onset of dangerous, vibe-coded malware at scale, I roll my eyes because most malware is a commodity at this point. Evilginx is so good, so why switch how it works? I worry more about the organizational scale that vibe-coding offers threat actors.
Before Claude Code, creating an interface like this would have taken months, either with a professional front-end developer or with someone who spent a lot of time learning front-end coding. Front-end coding with coding agents is AWESOME, so it’s now much more accessible for people to build things like this without spending their capacity on learning.
Project Glasswing: what Mythos showed us by Grant Bourzikas
Cloudflare ran Mythos Preview on more than 50 of its own repositories as part of Project Glasswing and published the results. Much like what Anthropic noted about Mythos in their Glasswing blog, Cloudflare said it was excellent at generating exploit chains and generating proof, via a PoC, that it found a bug. The harness architecture they built around it is worth reading too: they created narrowly scoped parallel agents, each focused on a single attack class, and then used an independent adversarial agent whose only job is to disprove the original finding.
Nothing in here really surprised me regarding the applicability of Mythos to real-world code environments. An agent is only as good as its harness, and although Mythos has fewer guardrails and is tuned for security findings, it still requires work to operationalize.
KQLab is a self-hosted platform for storing, protecting, and indexing KQL rules. It has an impressive full-stack architecture and is built to provide strong authentication and verification measures for users, and even includes RBAC capabilities to scope certain rule sets to specific teams.
DockSec is an OWASP Incubator project that builds a vulnerability scanning report from several open-source tools and generates human-readable reporting leveraging an LLM harness. It’s smart enough to prioritize vulnerabilities based more on CVSS scores, and you can stick it in your CI/CD pipeline so it can recommend fixes that developers understand, rather than a massive findings report.
Gabo is a Nebula:Fog hackathon project built for threat intelligence analysts. It uses the CIA’s Structured Analytical Techniques playbook to provide users a tool where they can ask it questions, and it’ll provide rigorous feedback based on their analysis. It has an MCP server as well, so you can point your local coding agent or stack at it.
AntiSSRF is a security component library from Microsoft that helps developers deploy apps without worrying about the underlying techniques used to prevent SSRF attacks. It has a robust URL parsing library, which are always a headache to work with, to validate incoming HTTP requests and reject any that look like SSRF attacks.
Every week, I read, watch and listen to all the Detection Engineering content so you can consume it all in 10 minutes. Subscribe and get a weekly digest of the latest and greatest in threat detection engineering!
Mozilla has published release notes for Firefox browser version 151.0, and this update includes several genuinely meaningful privacy and security improvements.
Three changes stand out in particular:
Note that Mozilla says several Firefox 151 features are “part of a progressive roll out,” meaning they will appear for some users first and be expanded over time. So, you may not see all of them immediately.
One of the more visible additions is a new “end private session” control in Private Browsing Mode. Instead of closing every private window to clear your traces, you now get a dedicated fire‑icon button next to the address bar that wipes the current private session’s data and immediately starts a fresh one.
Under the hood, this clears the usual private browsing artifacts for that session, including history, cookies, cached files, and other site data that would normally disappear only when the last private window closes.
For people who routinely mix normal and private windows, this is safer and less error‑prone than hunting down every private tab before you walk away from the machine.
Firefox 151 also tightens its defenses against browser fingerprinting in the default “Standard” Enhanced Tracking Protection (ETP) mode. Mozilla says Firefox now limits the amount of device and browser information exposed to websites in a way that reduces the number of uniquely identifiable users by about 14% overall, and by roughly 49% on macOS.
This makes it harder for trackers to pick you out of the crowd, especially on platforms with fewer users to begin with (like certain macOS configurations). This reduces the privacy risk surface by default, which makes it harder for phishing and landing pages that redirect visitors to “categorize” you.
Another important change is Firefox’s “local network access restrictions,” which are now rolling out to all users, not just those who turned Enhanced Tracking Protection to Strict.
This means that when a website wants to communicate with devices on your local network, or with apps and services running on your machine, Firefox now asks for permission first. Chrome and Edge have been rolling out similar permission prompts.
Firefox 151 also quietly fixes several security vulnerabilities.
The most notable example is CVE‑2026‑8953, a sandbox escape due to a use‑after‑free in the Disability Access APIs component. While there are currently no reports of in‑the‑wild exploitation for this specific bug at the time of writing, this is the kind of bug cybercriminals love.
A use-after-free (UAF) is a software memory vulnerability where a program attempts to access a memory location after it has been freed. If the program fails to clear the pointer to that freed memory, attackers can manipulate the error to crash the system or execute arbitrary code. A memory corruption leading to a sandbox escape is exactly the kind of link attackers want to complete a browser exploit chain.
If you’re running Firefox in a home or small‑office environment, we recommend updating to Firefox 151 as soon as possible to get the fingerprinting protections, local network access prompts, and security patches.
To update Firefox:
Once your Firefox browser has been updated, it will show a green checkmark along with the message: “Firefox is up to date.”
Let’s face it, an incognito window can only do so much.
Breaches, dark web trading, credit fraud. Malwarebytes Identity Theft Protection monitors for all of it, alerts you fast, and comes with identity theft insurance.
Unit 42 analyzes TamperedChef malware clusters that use trojanized productivity apps and malvertising to deliver stealthy payloads to targets.
The post Tracking TamperedChef Clusters via Certificate and Code Reuse appeared first on Unit 42.
The AWS Customer Incident Response Team works with customers to help them recover from active security incidents. As part of this work, the team often uncovers new or trending tactics used by various threat actors that take advantage of specific customer configurations and designs.
Understanding these tactics can help inform your architecture decisions, improve your response plans, and detect these situations if they occur in your environment.
This post examines a new approach we’re seeing threat actors use after they gain control of a customer account, which is to remove it from the customer’s AWS Organizations implementation and the policies and protections that structure provides.
The described tactic doesn’t take advantage of vulnerabilities within AWS services, instead it uses an unexpected opportunity created by a specific configuration or design to make unauthorized use of resources within an AWS account.
This approach starts with the threat actor using credentials that have the organizations:LeaveOrganizationpermission grant. This permission provides access to the LeaveOrganizations API call, which, when called from a member account, attempts to remove that account from the organization.
It’s important to remember that while this approach might use a compromised root credential, threat actors can also use other methods to elevate their access until they have the required permission or the ability to assume a role that has this permission, or they have the ability to grant their current credential this permission. This is why a least privilege approach to authorization is critical to protect your environment. To learn more, see AWS Identity and Access Management (IAM) documentation and the AWS Organizations guidance on organizational unit (OU) design and service control policy (SCP) implementation.
After the account is removed from the organization, the restrictions inherited as a part of that organization—such as SCPs that were preventing destructive actions, limiting which AWS Regions could be used, or blocking specific API calls—no longer apply. The account is also no longer part of consolidated billing, so the organization’s billing alerts and cost anomaly detection will no longer cover activity in that account. AWS CloudTrail organization trails stop capturing events from the departed account, and Amazon GuardDuty findings managed through a delegated administrator will stop flowing to the central security account.
The result is frequently that the organization loses visibility into the account while it still contains resources for the organization. Related threat technique catalog entries:
When an account attempts to leave an organization, at least two API calls are logged in CloudTrail: organizations:AcceptHandshake and organizations:LeaveOrganization. If you have centralized logging configured, these might be among the last events you see from the compromised account. After it leaves the organization, it might default to logging events within the account to its own CloudTrail logs. The following CloudTrail events are associated with accounts joining or leaving an organization. These should be investigated unless they’re part of an approved operational workflow that’s used by your teams to manage AWS Organizations.
| CloudTrail event | What it indicates |
organizations:LeaveOrganization |
A member account is leaving the organization |
organizations:AcceptHandshake |
The account is accepting an invitation to join a different organization |
organizations:InviteAccountToOrganization |
An organization is inviting the account |
organizations:RemoveAccountFromOrganization |
The management account is removing a member account (different from a member leaving on its own) |
Implement an SCP that denies the organizations:LeaveOrganization action. AWS Organizations provides detailed guidance on implementing this control, including the specific SCP policy JSON and advice on how to design your OU structure to accommodate legitimate account migrations while keeping the protection in place for production and development accounts.
SCPs act as guardrails that limit what any IAM policy can permit within member accounts. We strongly encourage every customer using AWS Organizations to verify whether this SCP is in place today and take steps to implement it if it is not. This SCP is quick to deploy and has minimal operational impact, providing a process to carefully manage and consider separating a member account from an organization.
Because this action can originate from any compromised IAM principal with the organizations:LeaveOrganization—not just root—the principle of least privilege for IAM permissions is an important complementary control. Limiting which users and roles can add, remove, or change policies, assume other roles, or modify their own permissions reduces the paths available for unauthorized permission changes. Regularly reviewing IAM policies for overly broad permissions—particularly iam:AttachRolePolicy, iam:AttachUserPolicy, iam:PutRolePolicy, and sts:AssumeRole with wide trust policies—will help reduce the scope of what a compromised principal can do.
Root account security remains important, because root compromise is a common entry point for this pattern. Enabling multi-factor authentication (MFA) on every root user, deleting any root access keys, and adopting centralized root access management to remove root credentials from member accounts entirely, will help reduce the risk.
This technique highlights a broader theme that we see across engagements: threat actors are increasingly aware of how AWS governance controls work, and they’re taking deliberate steps to separate accounts from the controls that an organization provides. Disabling AWS CloudTrail, deleting Amazon GuardDuty detectors, and removing accounts from organizations are all variations of the same strategy: removing your accounts from the guardrails and visibility that would otherwise constrain their activity and help the customer respond.
The controls to prevent this are available today and straightforward to implement. We encourage teams to start with the AWS Organizations service team’s guidance and implement the DenyLeaveOrganizationSCP—it’s the single highest-impact, lowest-effort control for this technique. Beyond that, reviewing SCP coverage across your OU structure, verifying that both root credentials and IAM permissions are properly secured across all member accounts, and ensuring that your detection and response processes account for this technique will contribute to a stronger posture. The Threat Technique Catalog for AWS includes detection guidance for the underlying techniques.
If you have feedback about this post, submit comments in the Comments section below.
A monthly analysis of how artificial intelligence is used in illicit communities, based on Flashpoint proprietary intelligence and direct visibility into real threat actor environments.
Table Of ContentsA finance employee joins a video call with their CFO and several colleagues. The request is routine. The faces match. The voices sound authentic. Minutes later, $25 million is transferred—only to be discovered later that every participant on the call, except one, was AI-generated.
Techniques behind incidents like this—synthetic video, voice cloning, scripted interactions—are now being discussed openly in the same environments where threat actors exchange tools and methods. In April 2026 alone, Flashpoint analysts identified 2,328,958 posts discussing artificial intelligence in the context of illicit activity.
This volume reflects a larger shift: artificial intelligence is now deeply embedded across cybercrime ecosystems, influencing fraud, impersonation, social engineering, and access operations at scale. It shows up in how content is generated, how identities are replicated, and how workflows are executed and refined over time.
That’s why we created the monthly AI Threat Report to examine how threat actors are using artificial intelligence in real-world illicit environments. Drawing on Flashpoint proprietary intelligence and direct visibility into primary source communities across forums, marketplaces, and chat services, the report analyzes the tactics, tools, and operational patterns shaping malicious AI use. Analysis of April’s activity shows a focus on prompt-sharing, jailbreak methods, and alternative models that support fewer safeguards or moderation controls.
In April 2026, Flashpoint analysts identified 2,328,958 posts discussing artificial intelligence in the context of illicit activity across forums, marketplaces, and chat services.
The underlying activity was concentrated around a familiar set of use cases and workflows:
However, the emphasis within those discussions shifted in several places in April.
This activity points to a more mature stage of adoption. The focus is less on building entirely new tooling and more on improving reliability, portability, and ease of use within workflows that already exist.
That pattern shows up repeatedly across monitored sources. Users exchange prompts, repost working methods, and refine outputs through direct feedback. In many cases, the same underlying techniques continue circulating with only minor changes between platforms or communities.Looking across April activity helps identify which methods continue to generate demand, where threat actors are adapting around platform restrictions, and which workflows remain active across multiple environments.
AI-related activity in April remained concentrated on a small number of platforms, though the distribution shifted noticeably compared to March.
Telegram accounted for the majority of observed activity, with 1,395,075 posts tied to AI services and discussions. Reddit, GitHub Gist, Pastebin, Discord, and smaller forums accounted for significantly lower volumes.
The lower Telegram volume does not indicate reduced interest in AI-enabled activity. The platform continues to function as a primary distribution layer for prompts, jailbreak methods, fraud tooling, and service advertisements.
Across April, the same prompts, offers, and workflows appeared repeatedly across channels, often reposted with only minor adjustments. Sellers updated listings based on user feedback, while buyers requested revisions tied to specific outputs or platforms.
Other platforms served more targeted roles:
The activity remains connected across environments. Methods introduced in one community frequently reappear elsewhere, particularly when they produce reliable outputs or help users work around moderation controls.Tracking how these discussions move between sources helps identify which workflows continue to gain traction and which techniques are becoming more broadly operationalized.
Across April, Flashpoint analysts observed 63,763 posts advertising or discussing KYC bypass methods using artificial intelligence, including deepfake-enabled verification workflows.
The methods were active across Telegram channels dedicated to identity verification bypass services.
Posts continued to advertise:
Some offerings included guidance on how to adapt responses for specific platforms or verification requirements. Others promoted combinations of synthetic video, matching fake documentation, and AI-generated scripts designed to support impersonation attempts from start to finish.
The broader workflow remains consistent. AI supports how identities are replicated, how verification checks are navigated, and how fraud operations are scaled across different services.
This activity connects directly to the wider access ecosystem already observed across illicit communities. Stolen credentials, session tokens, phishing infrastructure, and AI-enabled impersonation methods increasingly operate alongside one another within the same workflows.
Across April, posts tied to these methods continued to show active refinement through user feedback, reposting, and platform-specific variations.
For security teams, this activity remains relevant at the control layer. Verification systems, onboarding workflows, and account recovery processes continue to be tested in the same environments where these methods are exchanged and improved.
Across April, discussions tied to malicious or unrestricted LLM usage focused heavily on jailbreak methods, prompt-sharing workflows, and access to alternative models perceived as less restricted than mainstream platforms.
Flashpoint analysts observed a significant increase in discussions related to VeniceAI, driven in part by newly created Reddit and Discord communities dedicated to the platform. The increase highlights continued interest in models that users believe operate with fewer safeguards or moderation controls than services like ChatGPT or Gemini.
The activity centers on usability and output reliability.
Posts reference:
Many of these prompts are shared in collections that include updates, revisions, or support channels. Users exchange feedback when prompts stop working, outputs degrade, or platforms introduce new restrictions. Updated versions frequently follow within short timeframes.
This type of activity reinforces how prompt engineering has developed into its own service layer across illicit communities. The focus is not limited to the underlying model itself, but to the ability to generate repeatable outputs that can be applied directly within fraud, phishing, or impersonation workflows.
Across April, the same prompt structures and jailbreak methods appeared repeatedly across multiple sources, often with only small adjustments tied to platform or target.
The emphasis remains on accessibility, portability, and ease of use rather than custom model development.
Across April, the same behaviors continued to appear across different environments with only minor variation.
Prompt libraries, jailbreak methods, phishing workflows, and identity verification bypass techniques circulated across Telegram channels, forums, Discord communities, and paste sites. The wording changed slightly between platforms, though the underlying structure and outputs remained consistent.
This reuse is visible in how content moves between sources. A jailbreak prompt shared in one channel appears elsewhere with revised wording or additional instructions. A phishing workflow posted to a forum is copied into a paste site and redistributed through Telegram. Users request modifications, test outputs, and repost updated versions when restrictions change or methods stop working.
That cycle appeared repeatedly throughout April.
The activity also showed strong feedback loops tied to usability. Discussions focused heavily on which prompts generated reliable outputs, which models produced fewer restrictions, and which workflows required the least adjustment before use.
Across monitored sources, the same operational priorities appeared consistently:
Looking across April activity reinforces how AI-enabled methods continue to mature through repetition, iteration, and distribution across connected communities.
The activity tracked in this report shows how artificial intelligence is being used in environments where techniques are developed, tested, and shared before they surface elsewhere.
Across these communities, methods tied to fraud, impersonation, and access are reused, adjusted, and circulated in forms that others can apply directly. That process does not require significant change to move from discussion into use.
For security teams, the priority is maintaining visibility into how these methods are evolving and where they are being applied. That visibility supports earlier detection, more focused response, and a clearer understanding of which techniques are actively in circulation.
Monitoring these sources provides that context. It connects observed activity to the methods behind it and helps teams track how those methods develop over time.
If you want to see how this activity maps to your environment, request a demo.
The post AI Threat Report: How Artificial Intelligence Is Used Across Illicit Communities appeared first on Flashpoint.
Organizations often struggle to enforce security and compliance requirements consistently across their cloud infrastructure. In one environment, a workload might be deployed in an AWS Region that was never approved for that class of data. In another, a security group might allow broader access than intended. Required tags might be missing. Encryption might be assumed but not configured. These gaps create risk, increase review effort, and make audits harder than they need to be.
Many organizations already have standards that describe what good infrastructure looks like. The more difficult problem is making sure those expectations are checked the same way across repositories, environments, and teams before infrastructure is deployed. Manual review helps, but it doesn’t scale when delivery moves faster and more teams provision infrastructure directly.
Policy as code helps address this problem. It turns control intent into preventive checks that run in delivery workflow.
A pattern-based policy model makes those checks more straightforward to review, maintain, and explain. Teams can organize policy checks around recurring control patterns such as required metadata, allowed configuration, exposure restriction, protection enforcement, and privilege constraint, as shown in Figure 1. This structure simplifies policy coverage across security, governance, risk, and compliance (GRC), and engineering teams.
This post shows you how to use Open Policy Agent (OPA) in continuous integration and continuous delivery (CI/CD) pipelines to validate Amazon Web Services (AWS) infrastructure changes before deployment. You will learn how to structure policy checks around recurring control patterns, fit those checks into a gated delivery workflow, and retain validation artifacts that support both release decisions and later audit review.
The Compliance Engineering and Automation team from AWS Security Assurance Services (AWS SAS) frequently helps customers implement policy as code as part of broader control design and compliance automation efforts. This post focuses on the pre-deployment layer. Runtime monitoring and post-deployment controls still matter, but they are outside the scope of this article.
Figure 1: Pattern-based policy as code in a gated delivery workflow
Teams sometimes build rules one service at a time, which can make policy as code libraries difficult to review and extend as the library grows. Similar control requirements can be expressed differently across repositories, and teams lose a common way to discuss what the policies are enforcing.
A pattern-based approach organizes policies around recurring control intent rather than service-specific checks, as shown in Figure 2. This makes coverage more straightforward to review, explain, and evolve as infrastructure changes.
A practical set of patterns includes:
Figure 2: Recurring control patterns used to organize policy as code checks
This post focuses on the preventive layer. You still need runtime controls, drift monitoring, remediation workflows, and compliance reporting. On AWS, AWS Organizations, AWS Control Tower, AWS Config, and AWS Security Hub remain important after resources exist.
OPA fits earlier in the process and validates that infrastructure changes align with expectations. OPA evaluates structured input (HashiCorp Terraform plan JSON) against policy logic. It doesn’t replace AWS governance services that provide organizational guardrails, continuous monitoring, and resource level enforcement after resources exist.
As shown in Figure 3:
Figure 3: OPA validates changes pre-deployment; AWS services enforce guardrails, monitoring, and controls post-deployment
Use the following steps to integrate OPA policy evaluation into your delivery workflow:
Submit a change through a pull request or merge request.
Quality gates provide automated pass or fail results based on defined criteria. Approval gates control whether a change moves into a protected environment. This separation matters—manual approval isn’t the first place where anyone notices missing tags, a disallowed AWS Region, or public ingress. Automated checks identify those issues earlier. OPA belongs in the automated gate layer. Its output also feeds the approval process.
A pattern-based library structure, as shown in the following sample, keeps the policy model closer to how teams talk about controls.
Login
opa-policies/
├── patterns/
│ ├── baseline/ # Foundational security
│ ├── tagging/ # Required tags
│ ├── networking/ # Network controls
│ ├── logging/ # Logging enablement
│ ├── encryption/ # Encryption at rest and transit
│ └── iam/ # IAM best practices
├── shared/
│ ├── helpers.rego
│ └── messages.rego
├── tests/
├── fixtures/
└── docs/A compliance engineer might describe a requirement as mandatory metadata. A cloud engineer might describe the same requirement as a tagging standard. The pattern structure helps both teams talk about the same thing.
This example demonstrates the protection enforcement pattern for Amazon Simple Storage Service (Amazon S3). The goal is to verify that S3 bucket access is protected in transit by requiring a bucket policy that denies requests when aws:SecureTransport is set to false.
The policy checks two things: whether an S3 bucket policy includes a deny statement that blocks non-encrypted requests, and whether an S3 bucket has any corresponding bucket policy at all. The rule evaluates both create and update actions in the Terraform plan JSON.
This example uses an explicit deny rather than an allow statement for secure transport. An explicit deny overrides allow statements that might exist elsewhere in the policy set, making it the stronger enforcement pattern.
package compliance.amazon_s3.ssl
import future.keywords.in
import future.keywords.contains
import future.keywords.if
# Deny: S3 bucket policy missing SecureTransport deny statement
deny contains msg if {
resource := input.resource_changes[_]
resource.type == "aws_s3_bucket_policy"
is_create_or_update(resource.change.actions)
policy_value := resource.change.after.policy
policy := json.unmarshal(policy_value)
not has_secure_transport_deny(policy)
msg := sprintf(
"[S3-OPA-1] Resource '%s' does not enforce SSL/TLS. Bucket policy must include a Deny statement with Condition Bool aws:SecureTransport set to \"false\".",
[resource.address]
)
}
# Deny: S3 bucket created without any corresponding bucket policy
deny contains msg if {
resource := input.resource_changes[_]
resource.type == "aws_s3_bucket"
is_create_or_update(resource.change.actions)
bucket_name := resource.change.after.bucket
not has_bucket_policy(bucket_name)
msg := sprintf(
"[S3-OPA-1] Resource '%s' (bucket '%s') has no bucket policy. A bucket policy with a Deny statement for aws:SecureTransport \"false\" is required.",
[resource.address, bucket_name]
)
}
is_create_or_update(actions) if { actions[_] == "create" }
is_create_or_update(actions) if { actions[_] == "update" }
has_bucket_policy(bucket_name) if {
bp := input.resource_changes[_]
bp.type == "aws_s3_bucket_policy"
is_create_or_update(bp.change.actions)
bp.change.after.bucket == bucket_name
}
has_secure_transport_deny(policy) if {
stmt := policy.Statement[_]
stmt.Effect == "Deny"
stmt.Condition.Bool["aws:SecureTransport"] == "false"
stmt.Principal == "*"
action := stmt.Action
action == "s3:*"
}
When you adapt this example, decide whether you want to require one exact policy shape or support several equivalent forms of enforcement. A strict rule is more straightforward to reason about, but it might create false positives if teams already use alternate policy structures that achieve the same outcome.
This example implements the exposure restriction pattern. The goal is to identify Amazon Virtual Private Cloud (Amazon VPC) security group configurations that allow public ingress on sensitive ports before those rules are deployed.
The policy evaluates both inline aws_security_group ingress rules and standalone aws_security_group_rule resources, because customer repositories often use both modeling styles.
This example checks directly for public ingress on sensitive ports rather than trying to infer whether later controls might reduce actual exposure. Security group rules are a direct expression of intended network reachability, making them the right place to enforce this pattern early.
package compliance.amazon_vpc.ingress
import future.keywords.in
import future.keywords.contains
import future.keywords.if
# Sensitive ports that must not be open to the internet
sensitive_ports := {22, 3389, 5432}
# Deny: aws_security_group with inline ingress open to 0.0.0.0/0 on sensitive ports
deny contains msg if {
resource := input.resource_changes[_]
resource.type == "aws_security_group"
is_create_or_update(resource.change.actions)
ingress := resource.change.after.ingress[_]
ingress.cidr_blocks[_] == "0.0.0.0/0"
port := sensitive_ports[_]
ingress.from_port <= port
ingress.to_port >= port
msg := sprintf(
"[VPC-OPA-1] Resource '%s' allows ingress from 0.0.0.0/0 on port %d. Restrict access to specific CIDR ranges.",
[resource.address, port]
)
}
# Deny: aws_security_group_rule with type "ingress" open to 0.0.0.0/0 on sensitive ports
deny contains msg if {
resource := input.resource_changes[_]
resource.type == "aws_security_group_rule"
is_create_or_update(resource.change.actions)
resource.change.after.type == "ingress"
resource.change.after.cidr_blocks[_] == "0.0.0.0/0"
port := sensitive_ports[_]
resource.change.after.from_port <= port
resource.change.after.to_port >= port
msg := sprintf(
"[VPC-OPA-1] Resource '%s' allows ingress from 0.0.0.0/0 on port %d. Restrict access to specific CIDR ranges.",
[resource.address, port]
)
}
is_create_or_update(actions) if { actions[_] == "create" }
is_create_or_update(actions) if { actions[_] == "update" }
When you adapt this example, review which ports to treat as sensitive, whether both IPv4 and IPv6 exposure need checking, and how to handle approved exceptions.
This example implements the privilege constraint pattern for IAM role trust policies. The goal is to identify trust relationships that allow overly broad principals to assume a role. The policy inspects the assume_role_policy document for aws_iam_role resources and looks for wildcard principals in three valid representations: Principal is "*", Principal.AWS is "*", and Principal.AWS is an array containing "*". A wildcard principal allows a broader set of callers than most environments intend to permit. By treating wildcard principals as the prohibited pattern, the rule enforces a safer default and returns a clear result that reviewers can understand quickly.
package compliance.amazon_iam.trust
import future.keywords.in
import future.keywords.contains
import future.keywords.if
# Deny: IAM role with wildcard principal in trust policy
deny contains msg if {
resource := input.resource_changes[_]
resource.type == "aws_iam_role"
is_create_or_update(resource.change.actions)
policy_value := resource.change.after.assume_role_policy
policy := json.unmarshal(policy_value)
stmt := policy.Statement[_]
stmt.Effect == "Allow"
has_wildcard_principal(stmt)
msg := sprintf(
"[IAM-OPA-2] Resource '%s' has a wildcard principal in its trust policy. Specify explicit account ARNs, service principals, or federated providers instead of \"*\".",
[resource.address]
)
}
# Principal is directly "*"
has_wildcard_principal(stmt) if {
stmt.Principal == "*"
}
# Principal.AWS is "*"
has_wildcard_principal(stmt) if {
stmt.Principal.AWS == "*"
}
# Principal.AWS is an array containing "*"
has_wildcard_principal(stmt) if {
stmt.Principal.AWS[_] == "*"
}
is_create_or_update(actions) if { actions[_] == "create" }
is_create_or_update(actions) if { actions[_] == "update" }
When you adapt this example, decide what least privilege means for your IAM trust model. The key design choice is whether your policy checks for a single prohibited pattern or validates trust relationships against an approved set of trusted principals and conditions.
AWS Labs provides IAM Policy Autopilot, an open-source Model Context Protocol (MCP) server and command-line tool that helps generate baseline identity-based IAM policies from application code. That is adjacent to the pattern shown here —IAM Policy Autopilot helps with policy generation, while this example focuses on validating whether IAM role trust policies are scoped appropriately in infrastructure changes.
The following examples show the same operating model in two common CI/CD systems. The syntax changes, but the sequence stays the same: validate, plan, evaluate policy, retain the artifact, and use the result during promotion and approval. These examples assume OPA is installed in your CI/CD environment, the opa-policies directory contains your policy library, and Terraform is configured with appropriate credentials.
stages:
- validate
- plan
- policy_check
variables:
TF_IN_AUTOMATION: "true"
terraform_validate:
stage: validate
script:
- terraform fmt -check
- terraform init
- terraform validate
terraform_plan:
stage: plan
script:
- terraform plan -out=tfplan
- terraform show -json tfplan > tfplan.json
artifacts:
paths:
- tfplan.json
opa_policy_check:
stage: policy_check
script:
- opa eval --format pretty --data opa-policies --input tfplan.json "data.terraform.deny"
- opa eval --format json --data opa-policies --input tfplan.json "data.terraform.deny" > policy-report.json
artifacts:
paths:
- policy-report.json
name: Terraform Policy Check
on:
pull_request:
jobs:
policy-check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: hashicorp/setup-terraform@v3
- name: Terraform Format Check
run: terraform fmt -check
- name: Terraform Init
run: terraform init
- name: Terraform Validate
run: terraform validate
- name: Terraform Plan
run: terraform plan -out=tfplan
- name: Convert Plan to JSON
run: terraform show -json tfplan > tfplan.json
- name: Run OPA Policy Check
run: |
opa eval --format pretty --data opa-policies --input tfplan.json "data.terraform.deny"
opa eval --format json --data opa-policies --input tfplan.json "data.terraform.deny" > policy-report.json
- name: Upload Validation Artifact
uses: actions/upload-artifact@v4
with:
name: policy-report
path: policy-report.json
In mature delivery workflows, policy results don’t disappear into pipeline logs but are retained as validation artifacts. Those artifacts help reviewers decide whether a change is ready for approval, supports exception handling by showing which controls failed and why, and can stay with the change record for later audit discussions. At a minimum, the artifact identifies the change or pipeline run, the evaluated scope, the policy package or version, the checks that ran, and the pass or fail results.
The first few rules are usually straightforward.The real work starts when the library grows and multiple teams depend on it. Testing includes:
If developers stop trusting the results, they stop treating policy as a useful mechanism.
You don’t need broad coverage on day one. A phased rollout works better than an all at once enforcement approach.
Phase 1: Assess and pilot
Phase 2: Begin enforcement
Phase 3: Operationalize and expand
Policy as code helps narrow the distance between what an organization says it expects and what its delivery system checks. By implementing these OPA patterns in your CI/CD pipelines, you can build a preventive layer that evaluates infrastructure changes before deployment. With a pattern-based library, validation artifacts, and clear ownership, policy as code becomes a repeatable way to help translate control intent into day-to-day delivery, while AWS governance services continue to provide visibility and monitoring after resources exist.
To learn more about policy as code and AWS governance capabilities, see:
If you have feedback about this post, submit comments in the Comments section below.
NYC Health + Hospitals (NYC H+H) posted a data breach notice about a months‑long breach via a third‑party vendor that exposed highly sensitive patient and employee data for at least 1.8 million people, including medical records, government IDs, geolocation data, and even fingerprint and palm‑print biometrics.
NYC H+H detected suspicious activity on February 2, 2026, and later confirmed that an unauthorized actor had access to parts of its network from roughly late November 2025 through February 2026.
During this window, attackers copied files containing personal, medical, financial, and biometric information. The incident was reported to the US Department of Health and Human Services (HHS) on March 24, 2026, and currently affects at least 1.8 million individuals, making it one of the largest healthcare breaches of 2026 so far.
NYC H+H attributes the intrusion to a breach at an unnamed third‑party vendor that had access to its systems. This fits the current pattern of supply-chain compromises, where a vendor becomes the entry point for attackers to gain access to their clients’ systems or data.
Incidents like these are a textbook example of how deeply personal health data can fuel long‑term fraud, stalkerware‑like abuse, and permanent privacy loss.
According to NYC H+H’s notice and related write‑ups, the exposed dataset is unusually broad and detailed.
We can divide the data into three distinct layers:
Unfortunately, this is part of a broader pattern. The FBI’s Internet Crime Complaint Center (IC3) reports that healthcare was the most targeted critical infrastructure sector for ransomware in 2025, with 460 ransomware incidents and 182 reported healthcare data breaches.
The Change Healthcare ransomware attack alone exposed medical and billing data for more than 190 million Americans, highlighting how a single healthcare intermediary can disrupt an entire system.
If you’ve interacted with NYC Health + Hospitals, there’s a possibility your personal information could be affected.
NYC Health + Hospitals is making identity theft prevention and mitigation services, including credit monitoring, available through Kroll Information Assurance, LLC for a period of 24 months at no cost to all individuals who have worked for or been a patient of NYC Health + Hospitals. For more details check its data breach notice.
If you think you’ve been affected by a data breach, here are steps you can take to protect yourself:
Let’s face it, an incognito window can only do so much.
Breaches, dark web trading, credit fraud. Malwarebytes Identity Theft Protection monitors for all of it, alerts you fast, and comes with identity theft insurance.
Fox Tempest is a financially motivated threat actor that operates a malware-signing-as-a-service (MSaaS) used by other cybercriminals to more effectively distribute malicious code, including ransomware. The threat actor abuses Microsoft Artifact Signing to generate short-lived, fraudulent code-signing certificates to appear legitimately signed, allowing malware to evade security controls.
Fox Tempest has created over a thousand certificates and established hundreds of Azure tenants and subscriptions to support its operations. Microsoft has revoked over one thousand code signing certificates attributed to Fox Tempest. In May 2026, Microsoft’s Digital Crimes Unit (DCU), with support from industry partner Resecurity, disrupted Fox Tempest’s MSaaS offering, targeting the infrastructure and access model that enables its broader criminal use.
Microsoft Threat Intelligence observed Fox Tempest’s operations enabling the deployment of Rhysida ransomware by threat actors such as Vanilla Tempest, as well as the distribution of other malware families including Oyster, Lumma Stealer, and Vidar. The consistency, scale, and downstream impact of the resulting attack activity demonstrate that Fox Tempest is a vital operator within the broader cybercrime ecosystem.
In this blog, we examine how Fox Tempest’s MSaaS operation functioned and how it enabled the delivery of trusted, signed malware across the cybercrime ecosystem. We also provide Microsoft Defender detections, indicators of compromise (IOCs), and mitigation recommendations to help organizations identify and disrupt similar activity.
Fox Tempest doesn’t directly target victims but instead provides supporting services that enable ransomware operations by other threat actors. Microsoft Threat Intelligence has tracked Fox Tempest since September 2025. Microsoft Threat Intelligence has linked the actor to various ransomware groups including Vanilla Tempest, Storm-0501, Storm-2561, and Storm-0249, who have all leveraged Fox Tempest-signed malware in active intrusions. Malware delivery in these attacks have included use of legitimate purchased advertisements, malvertising, and SEO poisoning.
Cryptocurrency analysis associated with Fox Tempest has identified clear links tying the actor to ransomware affiliates responsible for delivering several prominent ransomware families, including INC, Qilin, Akira, and others, with observed proceeds in the millions. Based on the scale of the MSaaS offering, Microsoft Threat Intelligence assesses that Fox Tempest is a well-resourced group handling infrastructure creation, customer relations, and financial transactions.
The downstream impact of these operations has resulted in attacks against a broad range of industry sectors, including healthcare, education, government, and financial services, impacting organizations globally including, but not limited to the United States, France, India, and China.
Fox Tempest’s MSaaS capability was available through the website signspace[.]cloud, a now defunct service that was disrupted by DCU, which enabled other threat actors to fraudulently obtain short-lived Microsoft-issued certificates that were valid for only 72 hours, obtained through Artifact Signing (previously named Azure Trusted Signing). This use of short-life certificates from a trusted source allowed malware and ransomware to masquerade as legitimate software (like AnyDesk, Teams, Putty, and Webex) to bypass security controls, significantly increasing the likelihood of execution and successful delivery. Fox Tempest offered this MSaaS capability to the ransomware ecosystem since at least May 2025.
To obtain legitimate signed certificates through Artifact Signing, the requestor must pass detailed identify validation processes in keeping with industry standard verifiable credentials (VC), which suggests the threat actor very likely used stolen identities based in the United States and Canada to masquerade as a legitimate entity and obtain the necessary digital credentials for signing. The SignSpace website was built on Artifact Signing and enabled secure file signing through an admin panel and user page, leveraging Azure subscriptions, certificates, and a structured database for managing users and files. A GitHub repository, called code‑signing‑service, included configuration files and technical details that directly linked it to the infrastructure behind signspace[.]cloud.
The signspace[.]cloud service has two unique modeling groupings: the admin and the customers. The admin is responsible for maintaining the tooling, account creation, and infrastructure, while the customers provide files to be fraudulently code signed. Customers who accessed the service could upload malicious files to be signed using Fox Tempest-controlled certificates.
Below are examples of the signspace[.]cloud portal as seen by Fox Tempest’s customers:
In February 2026, Microsoft Threat Intelligence observed a notable shift in Fox Tempest’s operational infrastructure. Fox Tempest transitioned to providing customers with pre-configured virtual machines (VMs) hosted on US-based virtual private server provider Cloudzy’s infrastructure, allowing threat actors to upload their malicious files directly to Fox Tempest‑controlled environments and receive signed binaries in return. This infrastructure evolution reduced friction for customers, improved operational security for Fox Tempest, and further streamlined the delivery of malicious but trusted, signed malware at scale. Microsoft’s Digital Crimes Unit (DCU) disrupted this infrastructure and continues to partner with Cloudzy to identify and disrupt related infrastructure.
Below is an example of the Fox Tempest-provided VM environment as seen by customers:
Inside the VM, Fox Tempest provided files that are used to sign code:
Threat actors using Fox Tempest’s MSaaS offering paid thousands of dollars to get their malicious code signed, as shown below with the Google Form detailing the service’s pricing model. Actors filled out the form before being added to a queue to submit payment and gain access to a VM. The form (written in both English and Russian) asks the user to choose a selected plan from a price list of $5000 USD, $7500 USD, or $9000 USD, with a mention that higher paying plans receive priority in the queue sequence.
Fox Tempest engaged directly with customers using a Telegram channel, EV Certs for Sale by SamCodeSign under the user account arbadakarba2000. All signing activity occurred using a Fox Tempest-provided email address associated with a very small number of IP addresses.
Vanilla Tempest began using Fox Tempest’s MSaaS service as early as June 2025. Through this service, Vanilla Tempest uploaded malicious payloads such as trojanized Microsoft Teams installers, which Fox Tempest would fraudulently signed to appear legitimate. Vanilla Tempest would then distribute these signed binaries through legitimately purchased advertisements that redirected users searching for Microsoft Teams to attacker‑controlled advertisements and fraudulent download pages.
Victims were presented with a malicious MSTeamsSetup.exe in place of the legitimate client, reflecting a broader pattern of Vanilla Tempest frequently abusing trusted software brands to lure victims and establish initial access. Execution of the counterfeit installer resulted in the deployment of the Oyster backdoor (also known as Broomstick), a modular, multistage implant that establishes persistent remote access, initiates command‑and‑control (C2) communications, collects host‑level information, and enables the delivery of additional payloads. By masquerading as a widely deployed enterprise collaboration tool hiding behind a fraudulently signed binary, Vanilla Tempest’s Oyster payload was likely able to evade casual detection and blend into normal enterprise activity. In some observed cases, Vanilla Tempest also deployed Rhysida ransomware within victim environments using the same process.
To defend against Fox Tempest tactics, techniques, and procedures (TTPs) and similar activity, Microsoft recommends the following mitigation measures:
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.
| Tactic | Observed activity | Microsoft Defender coverage |
| Persistence | Threat actors distributed malware families including using Fox Tempest‑signed binaries | Microsoft Defender for Antivirus – Trojan:Win64/OysterLoader – Trojan:Win64/Oyster – Trojan:Win32/Malcert – Trojan:Win32/LummaStealer – Trojan:Win32/Vidar – Backdoor:Win32/Spyder – Trojan:Win32/Malgent – Trojan:Win64/Tedy – Trojan:Python/MuddyWater – Trojan:Win64/Fragtor Microsoft Defender for Endpoint – Vanilla Tempest activity group – User account created under suspicious circumstances – New group added suspiciously – New local admin added using Net commands – ‘LummaStealer’ malware was prevented – ‘Malcert’ malware was prevented – ‘Vidar’ malware was prevented |
| Impact | Analysis of Fox Tempest MSaaS identified links to the enablement of several ransomware families | Microsoft Defender for Antivirus – Ransom:Win64/Rhysida – Ransom:Win64/Inc – Ransom:Win32/Qilin – Ransom:Win32/BlackByte Microsoft Defender for Endpoint – Ransomware-linked threat actor detected – ‘BlackByte’ ransomware was prevented – ‘INC’ ransomware was prevented – ‘Qilin’ ransomware was prevented – ‘Rhysida’ ransomware was prevented – A file or network connection related to a ransomware-linked emerging threat activity group detected |
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.
Customers can also deploy AI agents, including the following Microsoft Security Copilot agents, to perform security tasks efficiently:
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.
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.
| Indicator | Type | Description | First seen | Last seen |
| signspace[.]cloud | Domain | Attacker-controlled domain hosting MSaaS | 2025-05-29 | 2026-05-05 |
| dc0acb01e3086ea8a9cb144a5f97810d291020ce | SignerSha-1 | Certificate | 2026-03-18 | 2026-05-11 |
| 7e6d9dac619c04ae1b3c8c0906123e752ed66d63 | SignerSha-1 | Certificate | 2026-03-21 | 2026-05-11 |
| f0668ce925f36ff7f3359b0ea47e3fa243af13cd6ad9661dfccc9ff79fb4f1cc | SHA-256 | File hash | 2026-03-19 | 2026-05-04 |
| 11af4566539ad3224e968194c7a9ad7b596460d8f6e423fc62d1ea5fc0724326 | SHA-256 | File hash | 2026-03-21 | 2026-05-07 |
| f0a6b89ec7eee83274cd484cea526b970a3ef28038799b0a5774bb33c5793b55 | SHA-256 | File hash | 2026-03-12 | 2026-04-19 |
For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.
To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky. To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
The post Exposing Fox Tempest: A malware-signing service operation appeared first on Microsoft Security Blog.
Every day, we decide what software to trust in seconds guided by simple labels such as “verified,” “secure,” and “safe to install.” The problem is that those signs can be manipulated.
Today, Microsoft unsealed a legal case in the US District Court for the Southern District of New York targeting a cybercrime service known as Fox Tempest, which, since May 2025, has enabled cybercriminals to disguise malware as legitimate software. The malware-signing-as-a-service (MSaaS) worked by fraudulently accessing and abusing code signing tools, such as Microsoft’s Artifact Signing, a system designed to verify that software is legitimate and hasn’t been tampered with. Cybercriminals used the service to deliver malware and enable ransomware and other attacks, infecting thousands of machines and compromising networks worldwide.
For the first time, Microsoft is taking public action against a powerful, but often unseen, enabler within the cybercrime ecosystem, targeting how cybercriminals prepare and employ techniques to optimize their rate of success. To disrupt the service, we seized Fox Tempest’s website signspace[.]cloud, took offline hundreds of the virtual machines running the operation, and blocked access to a site hosting the underlying code. This action builds upon persistent internal efforts to revoke fraudulently obtained code‑signing certificates and enhance our defenses and employ new security features to detect and thwart such malicious activity. It’s already having an impact: cybercriminals are complaining about challenges accessing the current service.
Our impact extends beyond one actor. The lawsuit targets Fox Tempest’s infrastructure and also names Vanilla Tempest as a co-conspirator, a prominent ransomware group that used the service to deploy malware like Oyster, Lumma Stealer, and Vidar, and ransomware, including Rhysida, in multiple recent cyberattacks. Vanilla Tempest has targeted schools, hospitals, and other critical organizations worldwide, while Rhysida, a highly evolved ransomware variant that both encrypts files and steals data, often used for double extortion, has been used by various actors in numerous high-profile attacks globally, including to steal and leak internal documents from the British Library and to disrupt operations at Seattle-Tacoma International Airport. Microsoft’s investigation further linked Fox Tempest to various additional ransomware affiliates and families, including INC, Qilin, Akira, and others.
More broadly, this case points to how cybercrime is changing. What once required a single group to carry out an attack from start to finish is now broken into a modular ecosystem where services are bought and sold and work interchangeably with one another. Some services are inexpensive and widely used. Others, like Fox Tempest, are highly specialized and expensive because they remove friction or bypass obstacles that make attacks fail, making them both more reliable and harder to detect. As seen with Fox Tempest, when these services are combined with AI-powered tactics, attacks can scale more easily, reaching more people and becoming more convincing.
Illicit code-signing certificates have been sold and trafficked for more than a decade. That includes its use by nation-state actors to target critical infrastructure organizations in Europe. What’s changed is how this activity is marketed, packaged, and sold as a service, along with the scale at which it is now used across ransomware campaigns. Instead of buying certificates one-by-one, criminals upload their malware to a service that signs it for them.
What also makes this model notable is the level of investment. Unlike lower-cost services like RedVDS, a cybercriminal infrastructure provider that costs as little as $24 per month, which Microsoft disrupted earlier this year, Fox Tempest shows that more sophisticated actors are willing to pay thousands of dollars for advanced capabilities that make attacks easier to carry out, harder to detect, and more likely to succeed.
Fox Tempest’s business model was straightforward: sell fraudulent code-signing capability, let others package malware, and enable attacks downstream. The model has generated millions in proceeds, demonstrating significant financial profit.
Behind the scenes, the operators built access at scale. Using fabricated identities and impersonating legitimate organizations, they created hundreds of fraudulent Microsoft accounts to obtain real code-signing credentials in volume. Customers who paid for Fox Tempest’s services could then upload malicious files via an online portal for them to be signed using Fox Tempest-controlled certificates. Cybercriminals paid thousands of dollars for the service, reflecting how valuable this capability was.
Once signed, their malware appeared legitimate. Attackers then distributed the signed malware through tactics such as search manipulation and malicious ads, where users are more likely to trust what they encounter. AI then helped generate and refine these campaigns to reach a broader audience.
That changed the odds. Malicious software that should have been blocked or flagged by antivirus and other safeguards was more likely to be opened, allowed to run, or pass security checks—essentially allowing malware to hide in plain sight. Instead of forcing their way in, attackers could slip through the front door by masquerading as a welcomed guest.
As Microsoft disabled fraudulent accounts, revoked fraudulently obtained certificates and introduced enhanced protections, the Fox Tempest operators continually adapted. In February 2026, they ultimately shifted to networks of third-party-hosted virtual machines to maintain and scale operations. That kind of rapid change is part of the model: these services evolve quickly in response to pressure and friction. In fact, Microsoft has observed further adaptations in response to our layered disruption efforts, with Fox Tempest attempting to shift operations and customers to another code-signing service.
In addition to seizing the core infrastructure behind the operation and degrading its ability to function at scale, we have taken further steps to prevent similar abuse, removing fraudulent accounts, strengthening verification, and limiting how this type of access can be reused. More technical details on the operation and the steps we’re taking to prevent similar abuse are available in this Microsoft Threat Intelligence blog.
This action wasn’t about stopping one actor. It sought to strategically neutralize a vital service that many attackers, particularly ransomware groups, rely on. When legitimate code signing services are weaponized, everything downstream gets easier: malware looks legitimate, security warnings are less likely to trigger, and attacks are more likely to succeed. Degrading that capability adds friction and forces a reset. The success rates of attacks decrease, and attackers have to rebuild, find new ways in, and accept more risk with each attempt—driving up both the cost and the time required to operate.
Importantly, disruption actions don’t happen in isolation and are never one-and- done. Collaboration is critical, as different organizations and sectors have visibility into different parts of the cybercrime ecosystem. In this case, we are working closely with cybersecurity company Resecurity, whose insights help us better understand how Fox Tempest operates. We are also collaborating closely with Europol’s European Cybercrime Centre (EC3) and the Federal Bureau of Investigation (FBI). As we’ve seen in previous efforts, we expect actors to try to rebuild. Collectively, we will continue to take action and keep the pressure on. That also means strengthening the code signing ecosystem through intelligence sharing and partnering with other code signing services, so it’s harder for malicious actors to regain that ground in the first place.
When attackers can make malicious software look legitimate, it undermines how people and systems decide what’s safe. Disrupting that capability is key to raising the cost of cybercrime. As threats evolve, the Microsoft Digital Crimes Unit will continue working with partners across industry and law enforcement to persistently identify and cut off the services that enable them.
For more than a decade, the Microsoft Digital Crimes Unit (DCU) has persistently disrupted cybercrime and nation-state threats targeting people, organizations, and critical infrastructure. Explore major disruptions—and the ongoing cases and operations behind them here: Disrupting cyberthreats since 2008 | Microsoft
The post Disrupting Fox Tempest: A cybercrime service that turned “verified” software into a pathway for ransomware appeared first on Microsoft On the Issues.
Sometimes you spot posts on social media that make you wonder if any moderation takes place at all.
Which is concerning, because two–thirds of all online shopping scams now start on Facebook and Instagram. Online shopping scams are alarmingly common and have become one of the most frequently reported scam types in Australia. The Dutch police have also warned specifically about fake ads promising steep discounts.
Apparently, and this is an issue we’ve flagged before, social media platforms could stop scams, but they don’t because it hurts their revenue.
This Facebook post immediately rattled my cage:
This promotion is not from Aldi and is not endorsed by the company. A random account, which may be compromised or completely fake, posts:
“My son works at Aldi and told me about something almost nobody knows. To be honest, I thought he was joking at first. If you’re over 40, you can get a meat box from Aldi for under $10. Sounds crazy, but it actually worked. They’re clearing out excess stock and, instead of throwing it away, they’re basically letting people have it for next to nothing. All I did was fill out a short form , I left the link in the comments in case it’s useful to anyone. I signed up for my husband (he’s 59 and loves a good steak), and when the box arrived, he opened it like it was his birthday. Everything looked fresh, neatly packed, and honestly there was more inside than we expected. It took me about a minute to fill out the form. If you’re over 40, definitely give it a go , worst case you lose a minute, best case you get a great box of meat almost for free.”
There are several red flags here. Malwarebytes Scam Guard flagged:
As it turns out, the possible risk, or “worst case” as the Facebook post calls it, is a lot worse than losing a minute of your time.
The link was posted as the first comment and used the link shortening service cutt[.]ly (and here’s why you should beware of those):
The first redirect sent me to a website where my device was fingerprinted using an embedded JavaScript before redirecting me to https://gifts-survey[.]life/click?key={identifier}, a site designed to mimic the Aldi website. I had my VPN set to the US.
The scam page immediately creates urgency with messages like “only 1 spot left” and “you only have 2 minutes to complete the survey,” trying to stop visitors from thinking things through.
The survey itself only asks basic questions, so there wasn’t much harm in clicking through it on my virtual machine.
As a reward, I got to pick three out of nine boxes to win a prize. I’m happy to report that I “aced” that test.
So, I was forwarded to the scammers’ real goal. On the domain hyperbargainsflow[.]shop, visitors are prompted to enter payment details for their discounted meat box, plus an optional upsell for faster delivery.
The final page asks victims to hand over personal details, including their full name, contact information, and home address, along with payment details for the fake “delivery” fee.
The site also uses tricks like more than 1,000 fake 5-star ratings and attempts to auto-complete and auto-submit the form if fields are detected as pre-populated. Saves you the trouble of submitting all your data yourself. Isn’t that nice of them?
We found that similar campaigns have targeted Woolworths customers in South Africa and Australia using fake butcher profiles, and the Aldi angle has appeared in other countries as well.
If a post promises a box of premium meat for the price of a sandwich, assume it is a scam until you can prove otherwise.
The same simple checks will help you avoid this Aldi meat box scam and the next look‑alike campaign that pops up tomorrow.
Pro tip: Malwarebytes Scam Guard recognized the Facebook post as a scam and could have saved somebody’s day.
Let’s face it, an incognito window can only do so much.
Breaches, dark web trading, credit fraud. Malwarebytes Identity Theft Protection monitors for all of it, alerts you fast, and comes with identity theft insurance.
It’s now a question I get daily: “What is Recorded Future doing about Mythos?”
It's a fair question. Anthropic's Project Glasswing announcement, paired with the vulnerability research benchmarks coming out of OpenAI's GPT 5.5, has made AI-driven vulnerability discovery a board-level topic in a matter of weeks.
To answer that question, first we need to discuss the operational problem defenders actually face and why threat intelligence can be the best way to counter it at machine speed. Then we'll get into what Recorded Future is already deploying to solve it: our agentic processing.
Even before AI and the news of Mythos’ capabilities and speed, defenders were struggling. Signal volume was outpacing analyst capacity. Coverage gaps widened daily as long-tail vendors and niche platforms went unmonitored. Raw findings arrived without root cause, threat-actor relevance, or vetted remediation paths. Producing one analyst-grade enrichment took hours of senior researcher time. The math didn't work at enterprise scale.
The data point that should anchor any conversation about the AI vulnerability surge: The NVD disclosed approximately 50,000 CVEs in 2025. Recorded Future Intelligence observed only 446 actively exploited in the wild — less than 1%.
Finding vulnerabilities is one thing, but knowing which ones matter, to which environments, against which adversaries, and with which compensating controls already in place is a whole different matter. Forrester put it directly: “The limiting factor in security is no longer the ability and knowledge to find problems — it's the ability to absorb, prioritize, and act on them before adversaries do.” The bottleneck has always been on the absorb-prioritize-act side. The find side was never the problem.
Frontier AI models accelerate the finding side. Threat intelligence is what helps close the prioritization gap on the fixing side.
Threat intelligence is operational, not philosophical. It comes down to four signals that distinguish the small fraction of CVEs adversaries actually weaponize from the overwhelming majority that they don't. These four signals are non-negotiable to be able to get to the prioritizing at speed and scale:
Together, these four signals are how you prioritize what actually matters for any given defender.
If attackers are moving at Mythos speed, your defenses need to keep up using agentic processing and Autonomous Threat Operations. This is my answer to the question we started with about what Recorded Future is doing about the new world we live in.
Agentic processing is the production system that turns exposure signals into deployable intelligence. The pipeline reads descriptions, vendor advisories, and patch diffs the moment they appear. It produces production-ready detection signatures — documented detection logic, evidence specification, passive fingerprinting strategy. It writes analyst-grade enrichment for every finding — root cause, exploit mechanics, threat-actor associations, prioritized defensive controls with deploy-time and false-positive estimates, validated remediation tasks with acceptance criteria and rollback plans.
It’s end-to-end target: identification to deployment in customer environments in only 31 minutes. Internal averages run lower. No security team operating manual triage workflows is matching that throughput.
That content can reach every relevant control point in your environment through Autonomous Threat Operations (ATO).
ATO turns agentic-processing outputs and correlated intelligence into operational action across over 100 integrations spanning SIEM, SOAR, EDR/XDR, NGFW, vulnerability management, threat intelligence platforms, identity and access management, email and cloud security, GRC, and threat-informed defense. It continuously deploys priority intelligence, runs autonomous threat hunts, pushes detection rules, and takes preventive action without analyst hours spent on manual correlation. The 8-to-12 hours of weekly correlation work most analyst teams perform manually is almost entirely eliminated. The hunting cadence becomes 24/7.
Soon, ATO will do this across your attack surface and third parties, as vendor exposure has been the most common path to breach for the past three years.
The five-stage pipeline that produces all of this — threat signals, intelligent enrichment, validation and verification, structured output, and customer workflow — runs continuously. Production-ready content is in customer environments within minutes of the originating disclosure across every category of threat the platform detects.
Four things distinguish agentic processing from anything a security team can build manually:
These benefits represent the difference between preventing threats pre-attack and absorbing the damage after.
Let’s look at an example of what agentic processing does at machine speed.
Take CVE-2025-55182 — React2Shell, a pre-authentication remote code execution vulnerability in React Server Components. Within minutes of disclosure, agentic processing produced:
In this new Mythos age, this type of agentic processing and speed is going to be required as the new baseline.
Vulnerability disclosure is the most visible trigger for the intelligence-at-speed pattern, but it isn't the only one. The same operational logic applies wherever a new threat signal surfaces and a defender needs to act on it before the adversary monetizes it.
When a brand impersonation site is stood up, the defensive sequence is the same: detection, intelligence enrichment (registrant, registrar, hosting infrastructure, historical campaign association), prioritized defensive controls (takedown coordination, blocking at email and web layers, alerting affected employees), and verification that the takedown landed. Recorded Future's Digital Risk Protection runs this loop continuously across the open, deep, and dark web.
When a stolen credential surfaces in an infostealer log market, Identity Intelligence runs the same pattern: detection of credentials tied to your environment, enrichment with infection context (malware family, device, other credentials in the same log, MFA cookie capture status), prioritized response (force password reset, revoke active sessions, alert the user), and verification.
The pattern is the posture. Apply intelligence at machine speed wherever the adversary is acting, across every category of threat surface. Vulnerabilities are one trigger. The work generalizes. Recorded Future is operationalizing intelligence at machine speed across our four solutions, Cyber Operations, Digital Risk Protection, Third-Party Risk, and Payment Fraud Intelligence.
The operational response to AI-driven vulnerability discovery is what separates organizations that contain exposures from those that wake up to incident response calls.
We are seeing customers set up automation to move faster in response to this new reality. A large enterprise in the financial services sector used Recorded Future to transform their vulnerability management workflow. Following a major patching effort across the organization, the team built out automation between their vulnerability scanning and IT service management tools. The result: a streamlined, repeatable process and an estimated weekly time savings of over 20 hours for the team.
We recommend taking these five actions so you can respond as well:
AI-driven vulnerability discovery is here. The big question is whether your systems can operate at attacker speed, with a depth of intelligence that survives executive scrutiny. If the answer isn’t a confident yes, then Mythos and the category behind it have already shifted the math against you.
See it in production. Request a demo to see Recorded Future Intelligence and Autonomous Threat Operations turn a vulnerability disclosure into deployable detection and action across your stack within minutes.
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.
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.
A useful way to reason about agent security is through the following mitigation layers:
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.
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.
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.
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.
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:
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.
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.
Focusing on the application layer does not diminish the importance of the other layers. Instead, it clarifies their roles.
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.
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.
The post Defense in depth for autonomous AI agents appeared first on Microsoft Security Blog.
Logs and telemetry are the foundation of modern cybersecurity. They enable threat detection, incident response, forensic investigation, and compliance across endpoints, networks, and cloud environments. Yet, despite their importance, high‑quality security attack logs are notoriously difficult to collect, especially at scale.
Real‑world security telemetry is often composed of repeated benign activity occurring across environments and with very rare malicious activity. Gathering, labeling, and maintaining datasets with real attack logs is costly and operationally challenging. It requires not only labeling malicious activities, but also fully reconstructing attack scenarios. These challenges significantly slow detection engineering and limit the quality of both the rule-based detection authoring and anomaly-detection approaches.
In this post, we explore a different path: using AI to generate realistic, high‑fidelity synthetic security attack logs. By translating attacker behaviors, expressed as tactics, techniques, and procedures (TTPs)—directly into structured telemetry, we aim to accelerate detection development while preserving realism and security.
Why is this work important for Microsoft Defender customers?
For Microsoft Defender customers, this work is crucial because it directly addresses the challenge of obtaining high-quality, realistic security attack logs needed for effective threat detection and response. By leveraging AI-driven synthetic log generation, organizations can accelerate the development of detection rules and AI-based automation approaches, while ensuring privacy and reducing operational overhead. Synthetic logs enable customers to simulate a broader range of attack scenarios—including rare and emerging threats—without exposing sensitive data or relying on costly lab-based simulations. Ultimately, this approach enhances the agility and effectiveness of Microsoft Defender detection and response capabilities, helping customers stay ahead of evolving cyber threats.
Why Synthetic Security Logs in addition to Lab Simulations?
Synthetic data has been widely adopted in various fields as a privacy-conscious substitute for real data, and it offers even greater advantages in cybersecurity. It enables the creation of safe, shareable datasets that avoid exposure of sensitive customer information, allows simulation of rare or emerging attacks that are challenging to observe in real environments, accelerates the process of detection engineering and testing, and supports reproducible experiments for benchmarking and evaluation.
While synthetic logs are not a replacement for all lab-based validation, they can complement lab simulations by speeding up early-stage detection design, testing, and coverage expansion. Traditionally, generating realistic attack telemetry requires executing real attacks in controlled lab environments. While accurate, this approach is slow, labor‑intensive, and difficult to scale. It also limits agility for the security teams responsible for defending our systems and delays the rollout of new threat detections into production. This blog examines whether AI-assisted synthetic log generation can provide similar fidelity, without the operational overhead of lab‑based attack execution.
Attackers can abuse TTP through various actions that exploit different processes. At a high level, the proposed workflow consumes “TTP + Action” as input and produces structured security logs as output.
Input: High‑level attacker TTPs from the MITRE ATT&CK framework [1], a widely used knowledge base of adversary tactics and techniques, and concrete attacker actions. See the example below.
| Tactic | Technique | Action |
| Stealth | T1202 – Indirect Command Execution | The attackers executed forfiles and obfuscated their actions using variable expansion of %PROGRAMFILES and hex characters (for example, 0x5d). They obfuscated the use of echo, open, read, find, and exec to extract file contents, then passed the output to a Python interpreter for execution. |
Output: Realistic log entries with correctly populated fields such as “Command Line”, “Process Name”, “Parent Process Name”, and other relevant telemetry fields.
Goal: The goal is not to reproduce logs verbatim, but to generate realistic, semantically correct logs that would accurately trigger detections, mirroring real attacker behavior.
We explore three increasingly sophisticated techniques for generating logs.
As depicted in the following image, the prompts explicitly instruct the model to reason like a cybersecurity researcher, leverage MITRE ATT&CK knowledge, and produce coherent attack narratives.
As depicted in the image below, these agents collaborate in an iterative loop (generate, evaluate, improve), allowing the system to correct errors, fill gaps, and refine details over multiple turns. This collaborative process significantly improves log completeness and fidelity, especially for complex attack chains.
While this direction of research shows a lot of promise, it is heavily dependent on the amount of labeled training data. To address this limitation, we applied data augmentations, including:
This allowed us to scale from hundreds to thousands of training examples.
To ensure our approach generalizes across environments and attack types, we evaluated it on three complementary datasets:
Note: The external datasets from the Security Datasets Project and ATLASv2 are used strictly for research and validation of our log generation methods. These datasets are not used in the development, training, or deployment of any commercial products.
Methodology: We evaluated the prompt engineering and agentic workflow approach on the three datasets across multiple reasoning and non‑reasoning models, using recall as our primary metric. Recall measures the model’s ability to generate semantically relevant log instances (true positives) expected for a given attack scenario. Our LLM‑as‑a‑Judge performs flexible matching, focusing on:
For example, a synthetic log containing “forfiles.exe” can successfully match a ground‑truth entry with the full path “D:\Windows\System32\forfiles.exe”.
Key Results: The results in experimental evaluation demonstrate that prompt-only approaches establish a baseline but show inconsistent performance. The agentic workflows deliver dramatic recall improvements across all datasets. Reasoning models, combined with agentic refinement, achieve the highest fidelity.
Finally, our experiments training reinforcement learning approaches conclude that while it shows a significant promise, a substantial amount of labeled data will be required for the agent to learn effective policies to make the synthetic data identical to benign logs.
Table 1 and Table 2 report the performance of the prompt-based and agentic workflow-based approaches, respectively. For reasoning models (o1, o3 and o3-mini), we report the recall values using a Medium reasoning effort. Overall, agentic collaboration emerges as the most effective technique for high‑quality synthetic attack logs generation.
Across the evaluation datasets we used, AI‑driven synthetic log generation shows strong potential to produce semantically meaningful logs from TTPs and attacker actions. It can capture multi‑event sequences, preserve parent‑child process relationships, and generate realistic command lines.
This capability can accelerate detection engineering by reducing dependence on costly lab setups and enabling rapid experimentation, without sacrificing realism or safety. Our early experiments with reinforcement learning with verifiable rewards also look promising and could improve verbatim alignment when sufficient training data is available.
This research is provided by Microsoft Defender Security Research with contributions from Raghav Batta and members of Microsoft Threat Intelligence.
For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.
To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.
The post Accelerating detection engineering using AI-assisted synthetic attack logs generation appeared first on Microsoft Security Blog.
