Our analysis an AI-powered espionage campaign targeting government Linux infrastructure with custom malware, web shells, and advanced credential theft.
The post AI-Powered Espionage Campaign Targets Government Linux Infrastructure appeared first on Unit 42.
Most people have opened their messages to find a suspicious alert urgently telling them that a package cannot be delivered, a toll remains unpaid, a bank account needs attention, or a tax bill is overdue. The details may change, but the goal is the same: to get someone to click, share personal information, or pay.
These messages are relentless. Delete and block one, and another takes its place. Ignore them, and more will follow. Fall for one, and the floodgates open. What appears to be a simple scam message is often the visible end of a much larger transnational cybercriminal operation.
When Microsoft and Japan’s National Police Agency (NPA) followed a wave of fraud and scam activity targeting people and businesses in Japan, they expected to find individual campaigns. Instead, they found themselves inside a sprawling Chinese-language cybercrime marketplace where criminals could buy accounts, hosting services and tools used to create fake websites and online identities. The investigation expanded globally, involving the Japan Cybercrime Control Center (JC3), Resecurity, Cloudflare, Oracle, Proofpoint and TRM Labs to uncover the businesses sustaining this criminal ecosystem.
Today, Microsoft and Health-ISAC, a global non-profit that helps health sector organizations share cyber threat information and collaborate to improve operational resilience, are moving to dismantle three components of this criminal marketplace: YAM Store, CoGUI and Iron Man.
Since January 2026, YAM Store, CoGUI and Iron Man have collectively enabled more than one billion malicious messages targeting over 75,000 organizations worldwide, including more than 750 million messages geared toward Microsoft customers alone. These messages have been used to target consumers, healthcare organizations, financial institutions, and other businesses in more than 150 countries, generating tens of millions of dollars for their operators.
The investigation began in late 2025 after Japan’s NPA alerted Microsoft to malicious messaging campaigns targeting people in Japan. NPA continued providing intelligence and investigative support as the partners traced those campaigns back to the businesses supplying criminals around the world.
The trail led investigators deep into a Chinese-language cybercrime ecosystem that was difficult for non-native-speaking investigators to penetrate. There, they gained access to CoGUI, which supplied criminals with ready-made websites and messages impersonating companies, financial institutions, government agencies, and other trusted organizations. Instead of creating fraudulent websites themselves, criminals could quickly deploy pages designed to steal passwords, payment information, and other personal data.
As Microsoft’s investigation expanded, intelligence from JC3 helped confirm the scale of the activity affecting Japanese organizations and their customers. Drawing on information collected across its network of more than 130 member organizations, JC3 connected what appeared to be separate incidents to a broader pattern of scams targeting Japanese companies and financial institutions, including efforts to defraud consumers and to steal credentials and other sensitive information.
One name that kept appearing throughout the investigation was YAM Store. YAM Store operated much like an online shop. Customers could browse products, compare prices and purchase fraudulent Microsoft and Google accounts and other ready-made tools used to carry out scams, including credential theft. Controlled purchases conducted by Microsoft helped confirm how it worked.
In some cases, operators acquired internet domains that legitimate organizations had allowed to expire, often targeting certain sectors, such as non-profits and education, with specialized product offerings. They then rebuilt the websites to make those organizations appear active, allowing them to fraudulently obtain Microsoft 365 accounts that could later be sold through YAM Store.
YAM Store provided criminal infrastructure that was frequently paired with tools and services such as CoGUI. As investigators dug deeper, they found that the marketplace was already evolving. CoGUI had become one of the most widely used offerings in the ecosystem, particularly targeting victims in Japan and the United States but by mid-2026 it was increasingly being replaced by a newer offering known as Iron Man.
Iron Man expanded the model by giving criminals access to thousands of ready-made templates designed to impersonate trusted organizations. Criminals could then quickly deploy email, text and web content tailored to specific brands, industries and countries.
Through test purchases and work with Resecurity, investigators gained access to Iron Man and identified more than 2,300 templates impersonating banks, retailers, healthcare providers, transportation authorities, police departments, government agencies, and other organizations across more than 150 countries worldwide. Some were designed for government impersonation scams, using the appearance of official authority to pressure victims into making payments or disclosing sensitive personal information. Others impersonated organizations across industries, countries, and languages, from banks and airlines to telecommunications companies, retailers, and parcel delivery services.
Examples of these impersonation templates are below. Importantly, the presence of an organization or government entity in these templates does not indicate that its systems were compromised.
A blog from Microsoft Threat Intelligence shares more details on the network, as well as steps customers can take to protect themselves.
No single organization saw the full picture. Japan’s NPA played a critical role throughout the investigation, providing intelligence, investigative support and collaboration that helped uncover how the operation worked. JC3 helped establish the scale of the activity affecting Japanese organizations and consumers. Health-ISAC provided insight into impacts affecting healthcare organizations, while Resecurity, Cloudflare, Oracle, Proofpoint and TRM Labs contributed intelligence and investigative support.
Working together, and with the assistance of AI tools, we connected accounts, websites, and infrastructure that initially appeared unrelated, helping expose the broader criminal marketplace behind them. Microsoft also worked closely and shared intelligence with U.S. Secret Service and international law enforcement partners.
This investigation also reflects a broader trend highlighted in this year’s Microsoft Digital Defense Report: modern fraud increasingly relies on businesses and services that make it easier for criminals to reach more victims. It took two-way information sharing across industries and international borders to uncover how these deeply interconnected services worked together.
With an order from the United States District Court for the Southern District of Florida, Microsoft and Health-ISAC seized and redirected domains that were part of the underlying infrastructure powering YAM Store, CoGUI and Iron Man. Microsoft has already disabled more than 20,000 accounts connected to YAM Store and continues to dismantle the operation by removing infrastructure hosted on its services and blocking more than 100,000 domains used for impersonation and fraud.
What began with scam activity targeting people and organizations in Japan led investigators to an underground service economy supplying criminals around the world. YAM Store, CoGUI and Iron Man are only part of that larger criminal network, but disrupting them makes it harder for criminals to obtain the accounts, tools and infrastructure they rely on.
The scam message is often the only part victims see. The businesses behind it are what make it possible.
The post Disrupting the service economy behind transnational cybercrime operations appeared first on Microsoft On the Issues.
As AI models become more capable, they uncover more security vulnerabilities and identify increasingly sophisticated paths to exploit them, raising the bar for how quickly defenders must respond. Security teams now face more potential vulnerabilities than their existing processes were designed to handle — each requiring investigation, reproduction, and a repair that must be tested to confirm it closes the vulnerability without breaking expected behavior.
AWS Continuum for code vulnerabilities accelerates this work with autonomous security at machine speed. To measure Continuum against a concrete public standard, we chose CyberGym-E2E, which asks an agent to find a vulnerability in a real codebase, demonstrate it with a working proof of concept, and repair it without breaking behavior covered by the project’s tests. Continuum passed 819 of 920 tasks within the benchmark’s 90-minute limit, achieving an 89.0% end-to-end success rate. This establishes a new standard 23.1 percentage points up from the previous public high of 65.9%.
Many security benchmarks test a single task in isolation. Detection benchmarks test whether a system can identify suspicious code, while patching benchmarks begin with a known flaw and ask for a fix. CyberGym, the predecessor to CyberGym-E2E, also begins with a known vulnerability and focuses on exploit generation. By contrast, CyberGym-E2E evaluates the full vulnerability lifecycle, requiring a system to identify and demonstrate a vulnerability before producing a tested repair. This broader scope more closely reflects the work facing security teams.
Each CyberGym-E2E task places an agent in a container with a vulnerable revision of a real open-source project and the tools needed to build and test it. An agent can inspect and modify the source, but receives no vulnerability description, proof of concept, crash log, or original patch. External network access is blocked, and protected benchmark files cannot be modified. Within 90 minutes, the agent must submit an input demonstrating a vulnerability and a source-code patch. The full benchmark contains 920 tasks based on historical OSS-Fuzz vulnerabilities across 139 open-source projects. The median project contains more than 600,000 lines of code.
The benchmark evaluates each submission in four cumulative stages:
CyberGym-E2E defines S3 as its main measure of end-to-end success. S4 is diagnostic because a repository may contain several valid vulnerabilities: an agent can find and repair a real flaw that differs from the benchmark’s selected target.
Continuum for code vulnerabilities reached a new standard for every stage of CyberGym-E2E. The table below compares its performance with the previous best public results.
| Stage |
What it measures |
Continuum |
Previous public high |
Difference |
| S1 |
Finds and reproduces a vulnerability |
92.5% |
67.9% |
+24.6% |
| S2 |
Repairs its generated crash |
89.6% |
66.2% |
+23.4% |
| S3 |
Preserves tested functionality |
89.0% |
65.9% |
+23.1% |
| S4 |
Also repairs the benchmark’s selected vulnerability |
37.8% |
26.2% |
+11.6% |
On S3, the benchmark’s main measure of end-to-end success, Continuum passed 819 of 920 tasks. Its 89.0% success rate exceeds the previous public high of 65.9% by 23.1 percentage points. The result reflects both the capability of the underlying frontier models and Continuum’s design as a multi-agent security system. The next section examines how that system adds value beyond the models alone.
The official 89.0% result applies CyberGym-E2E’s 90-minute limit. When tasks were allowed to continue beyond that limit, Continuum’s end-to-end pass rate reached 93.7%, indicating higher potential coverage when longer-running analyses can complete.
We conducted the evaluation under CyberGym-E2E’s network-isolation and submission-review requirements. External retrieval was blocked during execution, and post-run trajectory review confirmed that successful results came from vulnerability analysis rather than retrieval of public historical fixes.
Continuum for code vulnerabilities is a multi-agent system organized around the main phases of the code vulnerability lifecycle: discovery, validation, and remediation. Each phase uses specialized agents adapted to the evidence and decisions it requires. The system carries evidence forward so that each phase builds on the work completed before it.
During discovery, Continuum analyzes the repository and develops candidate vulnerability findings. Its agents identify code paths that warrant deeper investigation and record the source evidence supporting each candidate.
During validation, specialized agents attempt to turn a candidate finding into a demonstrated security issue. They construct a proof of concept, run it against the vulnerable program, and determine whether the observed behavior supports the finding. This converts a potential code-level weakness into executable evidence.
During remediation, agents trace the vulnerability to its root cause and produce a patch. Continuum then verifies that the patch prevents the demonstrated failure and that the project’s functionality tests continue to pass. The repair is therefore evaluated against the same evidence used to establish the vulnerability.
Together, these phases create a connected record from suspicious code to a demonstrated vulnerability and tested repair. The architecture allows Continuum to adapt its tools, instructions, checks, and models to each phase while maintaining a consistent standard of evidence. It also supports a multi-model approach that can leverage complementary strengths and incorporate new models as they become available.
In customer environments, Continuum can also combine code-level evidence with available deployment context, including service exposure, network paths, permissions, and configuration. This context helps distinguish vulnerabilities with limited production impact from exposures that demand immediate action. CyberGym-E2E evaluates the code-level process but does not provide deployment context, placing this broader prioritization capability outside the benchmark’s scope.
CyberGym-E2E advances security evaluation by turning a complex, multi-stage process into a large public benchmark with reproducible tasks and outcomes that can be verified by running code. The CyberGym-E2E authors’ careful work on task construction, scoring, and submission standards gives the field a concrete foundation for measuring end-to-end progress.
To keep evaluation consistent and reproducible across 920 tasks, CyberGym-E2E focuses on memory-safety vulnerabilities in C and C++ projects. Sanitizer-detected crashes provide objective evidence of a defect, while subsequent checks determine whether a repair blocks the proof of concept and preserves functionality covered by the project’s tests. This design necessarily leaves many languages and vulnerability classes outside the benchmark’s current scope, including many of the most common and impactful bug classes observed in production systems. Evaluating these areas will require different task environments and equally rigorous forms of validation.
Our view of end-to-end security also extends beyond producing a tested code-level repair. In production systems, deployment context such as service exposure, network paths, permissions, and configuration often determines whether a vulnerability presents limited risk or demands immediate action. Future evaluations should test whether autonomous systems can reason about this context and prioritize findings according to their effect on the safety of the deployed system.
CyberGym-E2E’s value extends beyond the dataset itself. It makes the case that end-to-end security is worth defining and measuring as a task in its own right. That involves hard design choices about scope, evidence, and what counts as success, and CyberGym-E2E gives the field a concrete starting point for working through those choices. This system-level view complements our work on the Deception Benchmark, which evaluates a narrower but related capability: how reliably individual frontier models distinguish real vulnerabilities from safe code. Together, they examine security performance at both the model and system levels.
To learn how AWS Continuum for code vulnerabilities helps teams discover, validate, prioritize, and remediate vulnerabilities at machine speed, visit the AWS Continuum product page.
Somewhere in your organization is a spreadsheet of certificate expiry dates, and someone who owns it. That is not a caricature. DigiCert’s 2026 research with Omdia surveyed more than 400 senior IT leaders and found that 47% still rely on manual tracking methods such as spreadsheets, and only 34% have a complete, current view of what they hold. The spreadsheet works because renewals come around once a year, and one person with a calendar can keep the whole estate in their head.
The industry has decided to take that away. The CA/Browser Forum voted in April 2025 to bring the maximum TLS certificate lifespan down in steps: 200 days from March 2026, 100 days from March 2027, and 47 days from March 2029, with domain validation reuse dropping to 10 days. The first step is already live: since March 15, 2026, no publicly trusted TLS certificate can be valid for more than 200 days. By 2029 you will be proving ownership of your domains roughly every month, for every certificate, forever. The spreadsheet does not survive that. Neither does the person.
Shorter lifespans shrink the window in which a stolen key or a mis-issued certificate is useful, and they push the whole ecosystem onto automation, which is where the reliability actually comes from. The destination is better. The journey is where outages live. Every manual step in your renewal process is a place where a 47-day cycle breaks something a 365-day cycle never stressed. We covered what the vote means for Imperva customers when it passed; this post is the checklist.
Login
hasSNI == false, set to Alert, logs every non-SNI request as a security event without blocking anything. Leave it running for a week or two, since some of this traffic is periodic, then decide. Imperva Cloud WAF Technical Guide: How to Identify Non-SNI Traffic Before Enabling SNI-Only Mode walks through it step by step.Imperva-managed certificates have already moved to 90-day validity (with domain validation every 99 days), ahead of the industry deadlines, with renewal and deployment automated end to end. Root trust is moving too: the GlobalSign root transition (R3 to R46) is covered by a cross certificate that Imperva includes by default until the R3 root expires in March 2029, so legacy clients keep working, and action is needed only if you pin to a specific root certificate. The direction of travel is simple. Certificate work becomes something you configure once, not something you do monthly.
The detail lives in the Cloud WAF documentation, and walks the site-certificate path step by step.
Back to that spreadsheet. If it is yours, the right time to retire it is while it still works. If you retired it years ago, the question is whether your automation reaches all the way to your applications, or stops at the CA.
When do 47-day TLS certificates take effect?
From March 15, 2029, publicly trusted TLS certificates can be valid for no more than 47 days. The CA/Browser Forum schedule gets there in steps: 200 days from March 15, 2026 (already in force) and 100 days from March 15, 2027.
How often will I need to validate domain ownership?
The period for reusing domain validation follows the same schedule: 200 days from March 2026, 100 days from March 2027 and 10 days from March 2029. In practice that means validating for almost every renewal, which is why an automated method such as CNAME delegation matters.
Do I need to do anything for Imperva-managed certificates?
Imperva renews and deploys its managed certificates automatically, and they already have 90-day validity. What stays with you is domain validation (automatic CNAME validation removes it), moving SNI sites from shared account certificates to site certificates, and updating your trust store if you pin to a root certificate.
What happens to clients that don’t support SNI?
A client that doesn’t send SNI can’t be served a site certificate, and once a site moves to SNI-only mode those connections are rejected. A custom rule with the filter hasSNI == false, set to Alert, shows whether you have any before you switch.
The post 47-Day Certificates Are Coming: Five Things to Do Before They Arrive appeared first on Blog.
Somewhere, an attacker is recording your encrypted traffic. Not breaking it. Recording it. The bet is patient and simple: store ciphertext today, wait for quantum computers to mature, decrypt at leisure. The industry calls it harvest now, decrypt later (HNDL), and it is the rare security threat with a believable deadline attached: data with a ten-year shelf life, encrypted with algorithms on a countdown.
Most quantum-readiness advice hands you a project: audit your cryptography, plan your migration, stand up a working group. Here is what Cloud WAF customers had to do to get quantum-safe TLS on every connection between their users and the Imperva network: nothing.
Every TLS 1.3 connection from a PQC-capable client to Imperva now negotiates hybrid TLS key agreement: X25519MLKEM768, which runs classical X25519 and quantum-safe ML-KEM-768 together. ML-KEM is the key-encapsulation mechanism NIST standardized as FIPS 203 in August 2024. It is enabled by default on all Imperva sites, with zero configuration and no measurable performance trade-off. If a client supports it, it is on. Your users’ sessions are already protected against the recording attack, and nobody on your team filed a ticket to make that happen. You can see it for yourself: open Chrome DevTools, go to the Security panel, and the connection to any Imperva-protected site lists X25519MLKEM768 as its key exchange. We explained earlier this year why post-quantum cryptography can’t wait; this post is the update now that both legs are covered.
A proxy architecture has two connections per request: client to edge, and edge to origin. As of the October 4, 2026 release, Imperva also supports PQC on the Imperva-to-origin leg, so customers whose origin servers support post-quantum key agreement get quantum-safe encryption end to end: from the user’s browser, through the Imperva network, to their own infrastructure. The requirement on your side is one sentence long: an origin that can negotiate the hybrid handshake. In practice, that means OpenSSL 3.5 or later, which offers X25519MLKEM768 by default. Sites created on or after October 4, 2026 get PQC to origin automatically. Existing sites keep their current behavior until you switch it on under SSL/TLS Configuration > Origin connection security, or with the /v3/sites/origin-pqc API. If an origin can’t negotiate the hybrid handshake, the connection falls back to classical TLS without disruption.
Post-quantum TLS is arriving across the industry, and that is a good thing; no vendor should claim the category. What differs is the operational bill. Here the answer is: defaults. No premium SKU, no per-site enablement, no migration project for the edge leg, and, for end to end, an origin-side capability check plus one switch on sites created before October 4, 2026. For regulated sectors already fielding quantum questions from auditors and boards (finance, healthcare, defense), that turns a program into a paragraph in your next review. Behind it sits the Thales portfolio, where post-quantum work spans well beyond the WAF. One limit worth stating plainly: hybrid key agreement protects the confidentiality of each session, which is exactly what a harvest now, decrypt later attack targets. Certificate signatures are a separate, later migration (NIST’s ML-DSA, FIPS 204), because forging a signature needs a quantum computer at the moment of the handshake. Recorded traffic gives an attacker nothing to work with there.
Detail, including how to test PQC and how to switch it on for your origin, is in the Post-Quantum Cryptography (PQC) Support documentation.
The recording attacker is patient. As of now, what they are recording from your traffic is noise with no future.
An attacker records encrypted traffic today and stores it until a cryptographically relevant quantum computer can break the classical key exchange that protected it. Data that must stay confidential for years is at risk now, even though that quantum computer does not exist yet.
Yes, for the key exchange. TLS 1.3 connections from PQC-capable clients to Imperva use hybrid X25519MLKEM768 by default on all sites. Connections from Imperva to your origin use it when the origin supports it (OpenSSL 3.5 or later) and PQC to origin is on: by default for sites created on or after October 4, 2026, and opt-in for existing sites.
It is the hybrid TLS 1.3 key-exchange group that combines classical X25519 elliptic-curve key agreement with ML-KEM-768 (FIPS 203). An attacker has to break both to recover the session key. It follows the hybrid model adopted by Google Chrome and other major browsers, and it is what Chrome DevTools shows when a connection is post-quantum protected.
The connection falls back to classical TLS key exchange without disruption. PQC is used only when both sides support it, and it requires TLS 1.3. See the Imperva PQC documentation for the handshake scenarios.
The post Harvest Now, Decrypt Later: The Attack You Defend Against by Doing Nothing appeared first on Blog.
