ReliaQuest Blog - Threat Hunting, Security Operations, and More

One Blank Field Bypasses Direct Send Control

Thu, 03 Sep 2026 10:00:00 GMT

Editor’s note: This report was authored by Tristano Di Liberto and Austin Ritchie

This is external threat intelligence from the ReliaQuest Threat Research team. The findings describe threats, vulnerabilities, and attacker activity affecting third parties and the broader threat landscape—not ReliaQuest’s own environment. Nothing in this report should be read as a vulnerability in ReliaQuest’s systems or data.

This is not a Microsoft software vulnerability, but a limitation in the control’s scope. Microsoft was made aware through multiple attempts of this security control bypass for RejectDirectSend, a Microsoft 365 control in Exchange Online intended to block unauthenticated Direct Send emails from an organization’s domain.

Key Points

ReliaQuest observed that an empty Simple Mail Transfer Protocol (SMTP) envelope sender can bypass RejectDirectSend, the Microsoft 365 control meant to block unauthenticated Direct Send mail. The message still carries an internal-looking address, increasing the likelihood that spearphishing reaches the recipient.
Across multiple cases we investigated, attackers repeatedly used self-addressed messages and familiar business lures to target leadership and business-facing users.
The technique requires only one empty field—no credentials, no registered lookalike domain, and no dedicated sending infrastructure—so organizations should expect continued use.
Testing showed that IP-restricted inbound connectors blocked every Direct Send attempt regardless of envelope sender, so organizations already limiting inbound mail to approved source IPs aren’t exposed. Use these connectors, tightly control filtering exceptions, and monitor for empty envelope senders paired with internal addresses.

ReliaQuest observed that an empty Simple Mail Transfer Protocol (SMTP) envelope sender can bypass RejectDirectSend, a Microsoft 365 control in Exchange Online intended to block unauthenticated Direct Send emails from an organization’s domain. An external sender can omit the envelope domain while retaining an internal-looking address, making phishing messages more likely to be trusted.

Direct Send allows devices and applications to send email to recipients in the same Microsoft 365 tenant without authentication. RejectDirectSend evaluates the domain in the SMTP envelope sender, but an empty value means there’s no domain to check. In testing, changing only this field caused Microsoft 365 to accept and queue a message it otherwise rejected.

ReliaQuest identified numerous instances of this empty-envelope pattern over the past year, frequently used against executives, managers, and business-facing roles. In one case, a message failed every sender authentication check and was classified as high-confidence phishing but still reached the inbox because the spoofed executive address was listed as an allowed sender. Defenders should therefore treat filtering exceptions as high-risk trust decisions, particularly when they cover privileged or frequently impersonated users.

In this spotlight, we:

Explain how the bypass works and how we validated it against a tenant with RejectDirectSend enabled.
Examine the pattern of ongoing examples, including delivery outcomes, phishing themes, and targeted users.
Provide detection guidance, recommendations, and an assessment of how the technique is likely to develop.

Testing Confirms the RejectDirectSend Bypass

Our testing confirmed that an empty SMTP envelope sender can bypass RejectDirectSend, allowing Microsoft 365 to accept an unauthenticated message whose visible From header uses an internal-looking address. Organizations shouldn’t rely on RejectDirectSend alone to prevent Direct Send impersonation. Attackers can exploit this gap to send messages that appear to come from trusted internal users or business functions, raising the risk of credential theft, fraudulent payments, malware delivery, and unauthorized access.

Testing and Reproducing the Bypass

We reproduced the behavior in a controlled test environment using a ReliaQuest-owned Microsoft 365 tenant. Before testing, we confirmed RejectDirectSend was enabled. Both messages were sent without credentials directly to the tenant’s mail host and displayed the same internal IT support address in the visible From header. The messages used the same header fields, sending host, recipient, and SMTP session details. Apart from the envelope sender under test, the only other difference was the subject and body labels.

We then used the following Python script to compare how Microsoft 365 handled two envelope sender conditions. The baseline message used an address from the tenant’s accepted domain, while the second used an empty envelope sender—also known as a null reverse path.

import smtplib from email.mime.text import MIMEText

server = "TENANT-mail-onmicrosoft-com.mail.protection.outlook.com" victim = "VICTIM_USER@VICTIM_DOMAIN" def send(mail_from, label): msg = MIMEText(f"{label} - testing RejectDirectSend") msg["From"] = "IT Support <it-support@VICTIM_DOMAIN>" msg["To"] = victim msg["Subject"] = f"[TEST] {label}"

smtp = smtplib.SMTP(server, 25, timeout=30) smtp.set_debuglevel(1) smtp.ehlo("attacker.lab") smtp.starttls() smtp.ehlo("attacker.lab") try: smtp.sendmail(mail_from, [victim], msg.as_string()) print(f"\n>>> {label}: ACCEPTED\n") except smtplib.SMTPException as e: print(f"\n>>> {label}: REJECTED - {e}\n") finally: try: smtp.quit() except Exception: pass

send("attacker@VICTIM_DOMAIN", "Baseline") send("", "Bypass")

The script’s send() function passes the MAIL FROM value as the first argument to Python’s sendmail() method. Supplying an empty string causes Python to issue MAIL FROM:<>, letting us test the baseline and empty envelope conditions against the same host and recipient. Neither test required a registered lookalike domain or a compromised internal host, showing that an attacker would need little additional infrastructure to use the technique.

Test	Envelope Sender	Visible From Header	Result
Baseline	attacker@VICTIM_DOMAIN	IT Support <it-support@VICTIM_DOMAIN>	Rejected
Empty Sender	MAIL FROM:<>	IT Support <it-support@VICTIM_DOMAIN>	Accepted and queued

Microsoft 365 rejected the baseline message because its envelope sender used the tenant’s accepted domain. However, it accepted and queued the message with MAIL FROM:<>. The visible From header remained unchanged, so the message still displayed an internal IT support address to the recipient.

The result shows that an empty envelope sender avoids RejectDirectSend’s documented rejection condition.[i] However, it doesn’t guarantee inbox delivery, as downstream controls can still block the message or route it to Junk Email. Those controls operate independently and produce different outcomes depending on the message content, tenant configuration, and filtering exceptions.

Enabling RejectDirectSend doesn’t fully resolve the risk of unauthenticated senders impersonating internal users. Defenders should supplement it with restricted inbound connectors, tightly controlled filtering exceptions, sender-authentication controls, and monitoring for messages that combine an empty envelope sender with an internal From address.

Acceptance, Filtering, and Connector Controls

The test results show that RejectDirectSend enforcement, mailbox placement, and connector controls operate independently. Success at one stage isn’t evidence that another worked as intended.

The baseline transaction used an accepted-domain address as the envelope sender. Microsoft 365 rejected it, preventing delivery:

Baseline: REJECTED

550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized source

The empty sender transaction didn’t get the same rejection—Microsoft 365 accepted the recipient and queued the message:

Null envelope sender: Accepted

250 2.1.5 Recipient OK

250 2.6.0 … Queued mail for delivery.

Return-Path: <>

Authentication-Results: spf=none; dkim=none; dmarc=fail action=oreject; compauth=none

X-MS-Exchange-Organization-AuthAs: Anonymous

X-MS-Exchange-Organization-MessageDirectionality: Incoming

X-MS-Exchange-Organization-SCL: 9

X-Microsoft-Antispam-Mailbox-Delivery: dest:J; … RF:JunkEmail

Microsoft 365 accepted the message with the empty envelope sender and delivered it to the recipient’s Junk Email folder. The headers classified the message as anonymous, incoming mail. No sender authentication check passed, and Microsoft 365 assigned the message the maximum Spam Confidence Level (SCL) of 9. The Domain-based Message Authentication, Reporting, and Conformance (DMARC) result recorded action=oreject, meaning Microsoft 365 overrode the sending domain’s reject policy rather than rejecting the message.

However, delivery to Junk Email doesn’t mean RejectDirectSend worked. The message had already bypassed the control and entered the tenant’s mail system before downstream antispam filtering assigned the disposition. The cloud hosting source, unresolvable HELO name, and failed sender authentication likely contributed to the SCL 9 rating. Because these indicators depend on the sender’s infrastructure and message content, another message using the same bypass could get a different verdict and reach the inbox.

Organizations that route inbound mail through a secure email gateway can use IP-restricted inbound connectors to limit Direct Send to approved devices and applications. During testing, an IP-restricted connector blocked every Direct Send attempt regardless of the envelope sender and had to be temporarily disabled to isolate RejectDirectSend. Because the connector evaluated the source IP rather than the envelope sender, the empty-envelope bypass didn’t affect it in this test.

Why Direct Send Remains Exposed

Organizations often use Direct Send so printers, scanners, and applications that can’t securely store credentials can send scanned documents, alerts, reports, and other automated notifications within the same Microsoft 365 tenant. Empty envelope senders are also a legitimate part of SMTP, commonly used for non-delivery reports. Blocking all messages that use MAIL FROM:<> could therefore disrupt legitimate mail flow, making a blanket restriction impractical.

Empty Sender Phishing Repeatedly Reaches Inboxes

ReliaQuest investigated multiple phishing cases between September 2025 and August 2026 that used an empty envelope sender across multiple organizations. RejectDirectSend was confirmed enabled in one of the tenants; enablement couldn’t be determined for the remainder, so these examples establish that the empty-envelope pattern is in active use rather than an exact number of confirmed bypasses. Microsoft 365 generally recognized the messages as unauthenticated phishing, but filtering exceptions and trusted internal mail paths still let most of them reach user inboxes. The continued use of an empty envelope sender across unrelated organizations indicates that this behavior is part of routine phishing activity rather than isolated testing of the control or a coordinated campaign. In our investigation, we saw that attackers frequently targeted leadership and business-facing roles, likely to increase the chances of fraudulent payments, unauthorized access, or disclosure of sensitive information.

File-Sharing and Payment Requests Are the Most Common Lures

The delivered emails used familiar business themes rather than technically sophisticated lures. Document and file-sharing notifications were the most common, followed by payment and remittance requests, procurement invitations, loan and investment offers, and a meeting invitation.

These themes blend into routine workflows and give recipients a plausible reason to open a document, follow a link, or act on a financial request. Multiple cases used SVG (graphics file type) attachments presented as voicemail recordings, combining a familiar notification theme with a browser-rendered file format that security products may handle inconsistently.

The voicemail and fax notification themes match those reported publicly in Direct Send phishing activity since May 2025, in which researchers documented the same self-addressed pattern as a behavioral indicator but didn’t mention the envelope sender.

Leadership and Finance Roles Are Primary Targets

Spoofing a recipient’s trusted email address gives attackers an advantage, as messages from familiar senders draw less scrutiny and may already be covered by existing trust rules. Attackers concentrated on roles with organizational authority or regular exposure to external business requests, probably to make the lures more credible and increase the chance a recipient opens the email.

The recipient groupings broke down as follows:

ReliaQuest assesses with moderate confidence that attackers in the cases we investigated favored recipients who routinely process invoices, bids, payment instructions, and externally shared documents. Attackers likely target these users because their authority and routine responsibilities make financial and document-sharing lures more credible, and a successful compromise can enable fraudulent payments, sensitive data theft, or further access.

Procurement and customer-facing mailboxes are also attractive targets because they routinely receive unfamiliar external messages that multiple users may need to act on. Permissive allow rules for these identities can further increase the risk by giving attackers a repeatable way to deliver phishing under a trusted internal address.

Step Up Your Defenses Against the RejectDirectSend Bypass

ReliaQuest’s Approach

ReliaQuest GreyMatter, an agentic AI security operations platform, helps security teams spot the activity detailed in this report while it’s still visible in mail-flow telemetry, rather than after a user has already acted on the spearphishing email.

GreyMatter Transit surfaces mail-flow and message-trace indicators in transit, including an empty envelope sender, an internal From address, and failed authentication; this helps security teams isolate the bypass pattern from normal email traffic.

GreyMatter Agentic AI correlates the signals that defined the bypass: empty envelope sender, internal impersonation, authentication failures, phishing verdict, and delivery outcome. That correlation explains why otherwise similar messages were rejected, sent to Junk Email, or delivered.

ReliaQuest Detection Rules alert on internal sender impersonation that bypasses preventive email controls, reducing the likelihood that a phishing email leads to credential theft, malware execution, or broader account compromise.

Organizations can cut mean time to contain (MTTC) from hours to minutes by deploying detection rules alongside the following GreyMatter Automated Response Playbooks:

Soft Delete Email: Removes matching phishing messages from the affected mailboxes.
Block IP: Prevents communication from known malicious infrastructure.
Reset Password + Terminate Sessions: Contains accounts when user interaction or compromise is confirmed.

Your Action Plan

Because RejectDirectSend doesn’t fully prevent abuse of empty envelope senders, organizations should layer mail-flow controls, remove unnecessary filtering exceptions, and monitor for indicators of the bypass.

ReliaQuest recommends the following actions:

Allow Direct Send Only from Approved IP Addresses: Configure an IP-restricted inbound connector permitting only the inventoried devices and applications that require unauthenticated sending. Keep RejectDirectSend enabled but don’t treat the internal spoofing risk as “closed” on the strength of that control alone.
Remove Unnecessary Mail-Filtering Exceptions: Review every setting that can override a filtering verdict, including allowed senders, allowed sender domains, Tenant Allow and Block List entries, mail flow rules that set spam confidence, and user-level safe senders. Record whether each entry covers one address or a whole domain, identify any that name an executive or manager, and remove those you can’t justify.
Proactively Identify Impersonation of Internal Users: Hunt for an empty envelope sender paired with a header From address in one of your accepted domains, and alert on any message that failed Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), or DMARC checks but was delivered under an override. Bounce messages also use empty envelope senders, so the internal header From address is what sets this activity apart.

Key Takeaways and What’s Next

Over the next 6–12 months, ReliaQuest assesses with high confidence that attackers will continue using empty envelope senders because the technique is simple to implement and has already appeared repeatedly across unrelated organizations. The technique requires only omitting the envelope sender, which sidesteps the domain-based rejection RejectDirectSend relies on.

Bypassing RejectDirectSend doesn’t guarantee inbox placement. Attackers seeking more reliable delivery will likely move to less suspicious infrastructure and refine message content to reduce spam indicators.

Our investigations show that recipients were exposed, but they don’t on their own confirm follow-on compromise. However, any phishing message that reaches an inbox creates opportunities for credential theft, malware execution, financial fraud, and account compromise. Email administrators and security teams should test other Exchange Online and third-party controls that depend on the envelope sender, validate filtering exceptions and trusted mail paths, and monitor for empty envelope senders paired with internal From addresses.

Your Security Vendor May Not Be Telling You the Truth About Your MTTD – Here's Why

Tue, 01 Sep 2026 04:00:00 GMT

Imagine a bank robber breaks in at 8:00 p.m. They move quietly through the building for 45 minutes before the on-duty security guard notices and calls 911. Police arrive quickly, arrest the individual, and write the report, recording the break-in time as 8:45 p.m.

That would be inaccurate. The robbery did not start when the security guard called 911. It started when the attacker entered the building. Those first 45 minutes matter. They are the difference between understanding the full incident and reporting only the moment it becomes visible.

No one would accept that kind of reporting in a robbery. However, in cybersecurity, it’s happening all the time.

Many vendors often report Mean Time to Detect (MTTD) as starting after they receive the logs, rather than from the first moment attacker activity begins. That makes MTTD look faster than it really is and gives false confidence.

If MTTD is measured inaccurately, what separates a meaningful metric from a misleading one?

Why is Measuring MTTD Important?

MTTD is one of the most critical metrics in security operations. It gives leaders a clear way to measure how quickly their organization can identify threat activity before it creates business impact. When measured correctly, it helps teams reduce the time attackers have to operate.

That matters because attacker timelines are shrinking. AI gives attackers speed, scale, and a lower skills barrier, executing agentic attacks defenders may have only minutes to stop.

In 2025, the fastest recorded exfiltration time was just 6 minutes. In that window, every delay between the first sign of threat activity and the moment the team can act becomes part of the risk.

A strong MTTD gives leaders confidence in the decisions they make from it. It shows where detection is improving, where risk is increasing, and where the business may need to invest, supporting reporting, decision-making, and performance tracking.

But MTTD only provides value when it reflects the full timeline. If the metric does not capture the time between the true event and actionable detection, it gives leaders an incomplete view of risk.

To understand how fast the organization can identify and mitigate risk, security leaders must first understand how their MTTD is being measured.

Why is MTTD Being Misrepresented?

Today, many security vendors and providers report MTTD, but there’s inconsistency across all of them.

For example, some providers do not start the MTTD clock until logs are indexed, parsed, and stored, or until after data is normalized, removing real exposure time from the metric.

A technology may receive telemetry at 10:00, but normalization may not finish until 10:45. If the clock starts only when the event becomes searchable, the ingestion and processing latency disappears from the MTTD even though the attacker may already be active.

Many vendors measure MTTD differently because it makes their numbers look better. If they measured from the attacker’s first observable action, the metric would show the real delay between compromise and detection—raising hard questions about visibility, latency, and coverage. Instead, they start the clock at the point that makes their detection look fastest.

There are not multiple ways for police to report when a bank robbery started. The same standard should apply to cybersecurity.

When MTTD is measured around a vendor’s visibility instead of the attacker’s first action, the number benefits the vendor more than the customer, leaving leaders with an incomplete view of risk.

What Does a Good MTTD Look Like?

Security leaders need MTTD they can trust. That starts with a clear definition of where the detection clock starts and stops.

A strong MTTD starts from the first observable suspicious or malicious event.

If the first event happens at 10:00, the clock starts at 10:00. It should stop when the alert is triggered. That gives leaders a clear view of how long it took to detect the activity, not how long it took for data to land and become searchable or finish processing.

That definition should stay consistent across the full security stack, including endpoint, identity, cloud, email, network, and SIEM. Detection speed may vary by tool or data source, but the definition of MTTD should not. Otherwise, leaders cannot compare performance, identify gaps, or understand where exposure is created.

Knowing Your True MTTD Helps You Lower It

Measuring MTTD correctly gives teams a clear view of the full gap between first activity and detection. It shows where time is being lost and where the right capabilities are needed to reduce it.

Because ReliaQuest measures MTTD accurately, we’ve been able to develop innovative solutions to close that gap. For example, GreyMatter Transit detects threats while data is still moving, before it is indexed, parsed, or stored, helping teams accelerate detection.

This even extends to large, distributed environments like Circle K, who used GreyMatter Transit to achieve detection in as fast as 4 seconds, ultimately bringing their containment time to under 1 minute. The faster you can detect, the faster you’re able to contain.

As Pat O’Keefe, Head of Global Cybersecurity and Risk Management at Circle K, explained: “The impact of dwell time in general can be very significant, especially at our fuel terminals. If we have to wait 30 minutes to detect an incident happening at a fuel terminal, that could cost millions of dollars in lost revenue.”

What Does This Mean for Security Leaders?

MTTD should not be accepted at face value. For security leaders, that means understanding what activity starts the clock, which delays are excluded, and whether the measurement method is consistent across every tool and data source.

Those answers determine whether MTTD reflects true detection performance or only the part of the timeline a vendor can see.

Accurate MTTD gives leaders a better way to evaluate risk, architecture, and operational speed. It shows where time is being lost and where the defense needs to improve. The point of the metric is not to create a better-looking number. It is to build a faster, stronger security defense.

ReliaQuest Signs "A Call for Collective Action on Cyber Defense"

Fri, 28 Aug 2026 15:00:00 GMT

ReliaQuest has signed "A Call for Collective Action on Cyber Defense," an open letter joined by more than 100 industry leaders across security, technology, and AI. The letter is clear: "We have a limited window to strengthen cyber defenses." The central call is the one we built our platform, GreyMatter, around: "Put cyber-capable AI in the hands of defenders, starting with the teams protecting essential services."

The threat has gone agentic, “status quo security won’t be enough”

The letter emphasizes the urgency to strengthen cyber defenses:

"In the coming months, AI-enabled cyber attacks will become far more widespread and sophisticated as models around the world become increasingly capable."

We see this now. Attackers are using AI to gain speed, scale, and the ability to execute sophisticated attacks without deep expertise. The barrier to running a competent intrusion has dropped. Phishing that once took a skilled operator now takes a prompt. Reconnaissance, credential abuse, and lateral movement that once required time and talent now compress into hours.

That trajectory is not hypothetical. The capabilities on display in the Claude Mythos Preview disclosures show how far the compression has already gone, and how little expertise the next wave of attacks will require. Frontier models capable of this work are here, and the capability gap is closing across the industry rather than sitting with any single model.

The security operations model of the past was built for a slower adversary. Analysts triaged alerts one at a time, pivoted between consoles, and stitched context together by hand. That model does not scale to an attacker that operates at machine speed.

"Recognize that status quo security won't be enough."

Defenders need to prioritize AI cyber defense

The encouraging news is that the same technology reshaping the offense is available to the defense:

"AI brings specialist skills to more defenders and makes core security tasks faster, cheaper and better."

This is the core of ReliaQuest’s thesis. You defend AI with AI. The speed, scale, and lowered expertise barrier that attackers are exploiting are the same advantages defenders can claim—if the AI is built into how security operations actually run, not bolted on as another tool to manage.

Adding a chatbot to a SOC does not make the SOC agentic. Making defense agentic means AI carries the operational load across detection, containment, investigation, and response, working over the environment as it exists rather than a clean-room version of it.

ReliaQuest’s commitment to collective cyber defense

GreyMatter is the Agentic Defense for the enterprise. It sits across the tech stack and the processes security teams already run and makes every part of the defense agentic from one place. No rip-and-replace, and no requirement to consolidate onto a single vendor's tooling before you see value.

The mechanism comes down to multiple capabilities working together:

Operate on your existing telemetry. The Universal Translator normalizes data across tools using OCSF field mapping, so detection and response work across identity, endpoint, email, and network sources without forcing everything into one schema first.
Agentic teammates scale your team. Rather than surfacing an alert and waiting for a human to start investigating, GreyMatter's agentic teammates connect events across sources, assess risk, and drive the investigation forward—continuously, across the environment.
Act where the threat lives. GreyMatter applies detection at the source and in transit, to detect threats in seconds.

The result is measurable: detection in seconds, containment in under 5 minutes, at 99.4% accuracy across 1,300+ enterprises.

Humans Lead. AI Multiplies the Team.

"Put cyber-capable AI in the hands of defenders." Humans lead, operate, and control the AI. GreyMatter multiplies what the team can do.

This is how agentic defense earns trust in production. Analysts set the intent and the guardrails; the AI executes the repetitive, high-volume, time-critical work that a human team cannot do at machine speed. The people protecting an enterprise stay accountable for the decisions that matter, and they get their time back for the work that needs real judgment.

The teams protecting hospitals, utilities, and local governments are not short on expertise—they are increasingly short on time. Agentic defense gives even a small team the operational reach of a much larger one, with more speed and agility.

The Window is Open

The letter closes with a call to action:

"Fix the most dangerous weaknesses, verify the fixes, and share what works so others can build on it."

Collective defense only works if the capability reaches the defenders who need it, in the environments they already operate.

The opportunity is here. The defenders can pull ahead.

We signed the letter because we agree with the call for action. We built GreyMatter to be part of the solution.

Read the letter: https://openai.com/collective-cyberdefense/

Gryxa: The AI-Built Toolkit That Watches How You Remove It

Fri, 28 Aug 2026 18:00:00 GMT

This is external threat intelligence from the ReliaQuest Threat Research team. The findings describe threats, vulnerabilities, and attacker activity affecting third parties and the broader threat landscape—not ReliaQuest's own environment. Nothing in this report should be interpreted as a vulnerability in ReliaQuest's systems or data.

Key Points

ReliaQuest has identified a new toolkit, dubbed “Gryxa,” used by a financially motivated threat actor across 324 listed hosts. We assess that substantial portions were almost certainly built with a commercial AI coding agent, which appears as co-author on most commits in the actor's public repository. This marks the first time ReliaQuest has observed a threat actor use AI to help build and execute an entire operation to this extent.
After defenders remove the visible remote monitoring and management (RMM) implant, a surviving Gryxa component collects Windows logs and host artifacts and uploads them to the threat actor, so the attacker effectively sees the remediation.
Partial containment triggers countermeasures. If the actor's relay becomes unreachable, Gryxa attempts to disable and uninstall any endpoint protection agent within roughly 10 minutes.
Contain in the right order: Block the actor's infrastructure first, then remove every persistence mechanism in one pass.

ReliaQuest has identified a new toolkit, referred to in its related public code repository as “Gryxa.” The toolkit is highly likely used by a financially motivated threat actor to run an initial-access operation. We assess with high confidence that the actor developed substantial portions of Gryxa with the help of an AI coding agent, since most commits in the actor’s public code repository carry AI co-author metadata.

Until now, threat actors’ use of AI has focused on scaling their operations or executing individual tasks like writing commands or sorting through stolen data. Gryxa, however, is the first case we’ve observed where AI has helped build the entire operation, from the toolkit to the console the actor runs it from. And for the broader landscape, this likely sets a precedence for more attacks of this nature.

Gryxa turns legitimate remote monitoring and management (RMM) software into covert access, keeps the access alive through several restart mechanisms that operate independently of each other, and then steals credentials saved in Chromium-based browsers. It also escalates against endpoint protection when the connection to the actor is interrupted, disabling or attempting to uninstall the security agent. Together, these capabilities give the actor durable access to a host and allow them to steal cryptocurrency wallets.

Gryxa’s most distinctive capability is how it responds to remediation. When defenders remove the RMM implant, another component of Gryxa collects local records describing how that removal was carried out and sends them to the threat actor. We haven’t seen this documented for other actors abusing RMM software.

Analyzing the source code in their public repository, we identified that the actor manages compromised hosts through a web console, which listed 324 hosts with 69 reporting as online at the time of writing. The host we investigated appeared in that list, which connects the repository and its supporting infrastructure to the activity we observed.

Read on to learn:

What Gryxa collected after defenders removed the visible RMM implant
What evidence in the actor’s repository points to AI-assisted development
Why the toolkit persists even when the visible RMM client has been removed

Gryxa Likely Built Using a Jailbroken AI Model

We assess that the actor almost certainly developed substantial portions of Gryxa using a commercial jailbroken AI coding agent, which likely allowed one person to build and operate an entire toolkit, a management console, and a signed update pipeline across several hundred hosts. We make this assessment as we observed the AI agent appearing as a co-author in the majority of commits in the actor’s own public repository. We expect more single operators to start building and running infrastructure at this scale, which makes behavior-based detection more durable than tracking individual toolkits.

Evidence of AI Assistance

Our assessment rests on the actor’s public code repository and infrastructure, which we analyzed directly. Four observations support it, ordered from strongest to weakest:

Repository metadata records a commercial AI coding agent as co-author in the majority of commits. It’s the strongest evidence available, and anyone can observe it directly in the repository.
The repository contains a rules file that’s automatically supplied to the AI agent in every session, written as engineering guidance. The guidance includes what to avoid, what to verify, which failure modes recur. Alongside it, the actor keeps session handover notes in SESSION_HANDOFF.md and 35 numbered case write-ups in CASES.md analyzing their own failed installs. Later commits address the specific problems those entries describe, which indicates an iterative development cycle rather than a single generated output.
Approximately one hour elapsed between the first repository reference to Chrome App-Bound Encryption (a feature that protects saved browser passwords) and a commit containing code intended to bypass it. This reflects repository activity only. It doesn’t show how long the actor worked on the problem, and we haven’t independently verified that the code succeeded.
The actor’s relay infrastructure serves near-identical landing pages whose structure and wording resemble AI-generated content rather than hand-written pages.

It’s also a realistic possibility the same approach produced parts of the supporting infrastructure.

What’s significant here is that one person likely sustained a workload that would previously have suggested a small team. That doesn’t make the toolkit unsophisticated—its persistence and recovery engineering are extensive—but the barrier to building at this level has fallen, so defenders must plan for more actors rather than more advanced ones.

How the Actor Bypassed the AI Model Safeguards

Two scripts in the repository carry an identical comment in their header blocks. In own_lib.ps1 and own_mon.cmd, immediately after the version notes, the actor wrote: “Authorized internal deployment - lab/competition scope only.” But neither script is a lab tool. own_lib.ps1 provides per-host identity handling, a Windows Management Instrumentation (WMI) watchdog, and service repair for the persistence layer; while own_mon.cmd is the monitoring component that pins the fleet update channel.

It’s likely that the actor used this framing to present the work to the AI coding agent as authorized lab testing rather than malware development. The rest of the repository reads the same way, describing the work in the vocabulary of legitimate systems administration, such as installer readiness, service recovery, scheduled-task configuration, and staged rollout to groups of machines.

We don’t have the actor’s prompts or session transcripts, so we can’t establish what was said to the agent, whether any safeguards refused a request, or what the agent produced before and after. But what we can say is that the committed code carries an explicit authorized-testing claim that is false.

The practical point for defenders is that this framing costs an actor nothing. A comment line asserting authorized scope takes seconds to add, and it may be enough to obtain help with writing code that has no legitimate application.

Gryxa Creates Persistent Access and Steals Credentials

Gryxa combines limited concealment with extensive recovery mechanisms, which suggests the actor prioritized restoring access after disruption over staying undetected. Throughout this section we separate behavior we observed in the investigated environment from the capabilities we read in the actor’s code but didn’t see execute.

Initial Access and Execution

The toolkit was likely delivered via phishing, based on our observation of a 19MB self-extracting executable with an invoice-themed filename and a randomized numeric suffix, in the pattern invoice_<10 digits>.exe. We didn’t observe the delivery itself, so this is just one likely route rather than a confirmed one.

The installer retrieves the remaining components over HTTPS. Individual components use different sources: Some fetch from the actor’s own server first and fall back to a public code-hosting service, while others go to the code-hosting service directly. The download commands skip over checking the revocation of the Transport Layer Security (TLS) certificate, so revoking the certificate that a delivery host presents won’t stop retrieval on its own. Other certificate validation still applies, and network-level blocking still works.

The toolkit spreads its files across four locations: A primary WinRTCS directory, two directories chosen to pass as Windows error reporting and diagnostics paths, and an off-path copy of its files. All are marked hidden, so they won’t appear in a default file listing, though a responder who turns on hidden items will see them. The folders we found were:

C:\ProgramData\WinRTCS (primary)

C:\ProgramData\Microsoft\Windows\WER\Temp\.wucache (keeper)

C:\ProgramData\Microsoft\Diagnosis\State\.etlcache (keeper)

C:\ProgramData\Microsoft\WinRTCS\cache\ (off-path file copy)

Persistence Built to Survive Partial Removal

Persistence is where the toolkit invests most heavily. Deleting any single Gryxa artifact achieves little, because the remaining components restore it. This is why the partial removal we saw in our investigations resulted in the toolkit returning. We identified at least seven scheduled tasks across two layers, a Windows event subscription, and a redundant copy of the toolkit’s files:

Three WinRTCS scheduled tasks running as SYSTEM at one-, five- and fifteen-minute intervals. Each runs a script that recreates the full set, so a deleted task is typically back within a minute.
A further four scheduled tasks belonging to the keeper layer, registered under names that resemble legitimate Microsoft tasks. Two run in one-minute intervals, one triggers at system start, and one at user logon.
A permanent WMI event subscription, which persists across reboots and survives deletion of the scheduled tasks.
A copy of the toolkit’s files staged outside the main install directory. This is redundant storage rather than an execution mechanism, but it’s what the other components draw on to rebuild.

The scheduled tasks and the WMI subscription restore execution, and both draw on the off-path file copy to replace anything a responder deleted. Removing the visible RMM client and the primary directory therefore leaves a working restore path. Treat removal as complete only once you’ve accounted for all three persistence categories and the off-path file copy, or once the host is re-imaged.

Partial Containment Triggers Gryxa to Remove Endpoint Protection

This behavior is the one most likely to catch a responder off-guard, because the trigger is the defender’s own action rather than any detection. Gryxa keeps a counter on disk that increments each time its guard component runs and finds the actor’s relay unreachable. The guard runs every five minutes.

At two consecutive failures the toolkit disables Microsoft Defender and issues service stop and disable commands against EDR products from a hard-coded list. At three, it reads the uninstall string for the security agent from the registry and runs a silent uninstall. This means cutting the actor’s remote-access service without simultaneously removing the scheduled tasks, and the file cache can lead to endpoint protection being disabled and uninstalled in roughly 10–13 minutes.

The toolkit re-enables Defender once its relay is healthy again, so a healthy Defender status isn’t evidence that nothing happened. What’s more, the Defender exclusions it adds are never reverted.

Cutting the visible service on its own is what starts the countermeasure, because the toolkit reads the lost connection as a signal to fight back. That’s why order matters here. Block the actor’s infrastructure first, then remove the service, the scheduled tasks, and the working folders together in one pass. If your endpoint agent supports Uninstall Protection, turn it on as it blocks the final stage. Without it, an actor with SYSTEM-level access can remove the agent entirely.

Gryxa Bypasses Chromium Protection to Steal Credentials

Gryxa targets credentials saved in Chromium-based browsers. On Windows, Chrome App-Bound Encryption protects those credentials by tying the encryption key to the browser itself—a control Google introduced in 2024 to stop other processes decrypting them. Other Chromium-based browsers vary in what protection they apply, and we haven’t tested Gryxa against each of them. The toolkit also retains an older decryption method, so it can read credentials from profiles where App-Bound Encryption is not in use.

The credential module contains three decryption routes described in code as working against App-Bound Encryption. All three require local code execution on the host:

Borrowing the security context of a trusted Windows process, which requires elevated privileges.
Calling the browser’s own privileged elevation service to perform the decryption, which requires local execution alongside the browser installation.
Requesting the browser’s protected key from the Windows key store in the context of the user who owns the profile.

The module also contains a legacy path for hard-coded fallback keys, but those apply to one specific key format rather than to App-Bound Encryption generally, so they aren’t a universal bypass. Retaining that older path alongside the newer ones means the module works against both current and older browser versions. We confirmed these paths in code review but didn’t independently verify successful decryption against every browser version the component lists.

The credential module treats exchange logins and wallet extensions differently. Decrypted logins are checked against roughly 40 cryptocurrency exchange and financial-technology domains, and any match is sent to the actor with the username, password, and host details.

For wallet browser extensions it records only that they’re installed, checking around 69 extension identifiers without extracting wallet contents. The console flags those hosts, and the actor's case notes indicate an operator then returns over the remote-access session to access the wallets manually.

Credentials leave the host through Telegram rather than the toolkit’s own command-and-control (C2) channel, sent as plaintext in the message body. Three separate bots all deliver to the same chat identifier: One receives stolen credentials, one receives fleet and host status from the reporting module, and one receives operations-tier alerts from the actor’s server. All three report to a single personal account, which is consistent with our single-operator assessment.

On any host where the credential module ran, treat every credential saved in an accessible browser profile as exposed. The module decrypts everything it can reach before checking the results against its target list, so a corporate login in the same profile has already been read even if the actor discarded it. Rotate those credentials on the assumption the actor holds them, and check what each account could reach.

Gryxa Collects Evidence of How Defenders Remove Its Access

During our investigation, we observed that defenders removed the visible RMM implant, but a second Gryxa component stayed operational, and the toolkit returned within seven days. That component collected Windows logs and host artifacts and uploaded them to actor-controlled infrastructure. It’s the behavior we consider most consequential in this campaign, as the details of a response can end up in the attacker’s hands and shape their next attempt.

Partial Removal Leaves Gryxa Behind and Exposes the Response

A partial removal carries a second cost beyond leaving Gryxa in place: It makes your response visible to the actor.

After the RMM implant was removed, a surviving Gryxa component collected a specific set of records: the scheduled tasks and Windows event subscriptions present on the host; Windows installer and service-control logs showing what was installed or stopped and under which account; process-creation logs showing what was executed; an inventory of every remote-access tool on the machine with its version and connection state; and a check of whether its own channel to the actor still worked. It packaged these into an archive and uploaded it over an authenticated connection. Together, those records could reveal the tools and accounts a responder used.

The Gryxa component only gathered and uploaded; it didn’t examine what it took. The actor draws any conclusion about which tool performed the removal, which account ran it, and in what order after receiving the archive. The actor's console includes a ready-made job named collect-forensics, which indicates this is a routine capability rather than a response to one incident. Gryxa rotates its log files when they exceed 200KB, meaning recent activity is preserved for a responder who acts quickly.

Gryxa’s Control Infrastructure and Defensive Response

Gryxa’s centralized management and update architecture allows the actor to issue jobs across the fleet and replace toolkit components rapidly. This reduces the useful life of file-hash indicators and means that disrupting one server may not sever access while fallback infrastructure remains available. We identified the console from source code in the actor’s public repository rather than by accessing a live panel. It shows the actor how many hosts are compromised, which are live, and the status of queued tasks, and it can push a job to selected hosts or to the whole fleet. At the time of our analysis it listed 324 hosts, 69 of them reporting as live. Not every listed host is necessarily a confirmed victim.

The toolkit updates itself. On each cycle it checks an integrity manifest of expected file hashes and pulls down any component that has changed, including the agent, the persistence components and the credential-theft module. One commit therefore changes the files on every host that checks in, so treat file hashes from a single incident as short-lived and prioritize behavior-based detection.

Gryxa’s code anticipates other remote-access tools on the same host. It stops and uninstalls named rival services, removes RMM installations whose installer fingerprint does not match the actor’s own, and deletes associated scheduled tasks and WMI subscriptions. It avoids the standard Windows uninstaller for competing RMM clients, which the actor’s own notes attribute to those clients sharing a product identifier with theirs.

This code doesn’t establish that other actors were on the hosts we investigated. It could reflect competition for previously compromised machines, a shared access source, or an attempt to keep legitimate administrators from regaining control. Either way, two things follow for defenders. A host running Gryxa may carry traces of other tools being removed, so the absence of a second actor isn’t evidence that none was present. And a legitimate RMM instance that doesn’t match the actor’s expected fingerprint may be uninstalled, so the implant could remove a tool you deployed to remediate the host.

So don’t deploy your own remote-access tool onto a live Gryxa host—the implant won’t recognize it and will likely uninstall it. Contain the host first, in the order set out above, and bring your own tools in only once it’s clean.

Step Up Your Defenses Against Gryxa

ReliaQuest’s Approach

GreyMatter Attack: Safely test the behaviors in this report against your environment to confirm whether you detect SYSTEM-level scheduled task creation and WMI event subscription persistence. That surfaces visibility and detection gaps before this behavior shows up in an intrusion.

GreyMatter Agentic AI: Correlates behaviors across an intrusion that look low confidence in isolation. An RMM client connecting to an unrecognized destination, a SYSTEM-level scheduled task created alongside a WMI event subscription, and registry writes to Defender policy paths each look weak alone. But correlated at machine speed, they describe an active compromise well inside the interval in which this toolkit rebuilds itself.

GreyMatter Transit: Provides visibility into network telemetry while it’s still in motion. Gryxa restores a deleted component within roughly a minute, so any time a detection spends waiting on log ingestion is time the toolkit uses to rebuild. Removing that delay is what lands containment inside the window.

ReliaQuest Detection Rules: We continuously update these rules using the latest threat intelligence and research. To defend against the Gryxa behaviors detailed in this report, we recommend the following rules:

The following GreyMatter Automated Response Playbooks act on the detections above:

Isolate Endpoint: Removes the host from the network, cutting the control channel before the operator can issue further commands or the toolkit can re-fetch components.
Ban Hash: Prevents reinfection from the toolkit components identified in this report, noting that signed updates allow the operator to rotate hashes between campaigns.
Terminate Sessions: Invalidates active sessions on hosts where browser-stored credentials may have been decrypted, provided the identity falls within directory coverage.

Your Action Plan

These recommendations each address a gap this activity exposed:

Contain in the right order: Gryxa escalates against endpoint protection when it loses contact with the actor, so removing the visible service on its own starts a clock. Block the actor’s infrastructure by IP address at the network edge first, then remove the service, all seven scheduled tasks, the event subscription, and every working folder together in one pass. Don’t deploy your own remote-access tool until the host is clean, because the implant won’t recognize it and may uninstall it. Turn on Uninstall Protection if your endpoint agent supports it.
Account for every persistence mechanism before returning a host to production: This includes three scheduled tasks belonging to the toolkit itself, four more registered under names resembling legitimate Microsoft tasks, the Windows event subscription with its filter and consumer, and every working folder—including the backup copy of the toolkit’s files staged outside the main install path. That backup copy is what the other mechanisms rebuild from, so leaving it behind undoes the rest of the work.
Don’t treat a healthy AV state as evidence of a clean host: This toolkit restores Defender once the implant is confirmed running, which removes the signal a persistently disabled antivirus (AV) tool would otherwise create. Check Defender exclusion paths and Group Policy overrides directly.
Establish which identities sit outside directory coverage: Those identities are the accounts that identity-side response actions can’t reach, and unmanaged devices are where that gap usually appears.

Key Takeaways and What’s Next

We assess with high confidence that the actor developed the Gryxa toolkit, its management console, and its update pipeline with substantial help from an AI coding agent. Building and operating these elements across several hundred hosts has, until now, implied either real development experience or a team of people, yet this actor seemingly had neither. Two of the committed scripts carry a comment falsely claiming the work was authorized lab or competition testing, which appears to be how the actor obtained the agent's help.

The significance of this case extends beyond this specific toolkit, and we assess it’s likely that more operations of this scale, run by actors with limited development experience, will emerge over the next 12 months. What’s more, this is a real-world example of how AI lowers the skill barrier required to build something of this standard, which points defenders toward behavior-based detection rather than tracking individual toolkits.

Gryxa arranges persistence across at least seven scheduled tasks in two layers, a permanent Windows event subscription, and a redundant copy of its files outside the install directory. Removing the visible RMM client alone doesn’t evict it and actively triggers escalation against endpoint protection. However, that resilience wasn’t necessarily designed intentionally: The repository included 35 numbered write-ups of the actor's own failed installs, with later commits—made with the AI agent’s help—fixing the specific problems each one described. This demonstrates an iterative cycle, worked through with the AI coding agent, to turn repeated failure into a toolkit built to survive partial removal. In this case, AI not only made this attack easier to build, but it also made the toolkit harder to remove.

A surviving Gryxa component collected Windows logs and host artifacts after the RMM client was removed and uploaded them to actor-controlled infrastructure. Those records could reveal the tools and account a responder used. Where a toolkit is built to recover from disruption, defenders should assume that the threat actor has observed the response actions to it.

During our investigation, we observed that the compromised account didn’t exist in the organization’s directory because the device sat outside centralized management, so revoking sessions and rotating credentials had nothing to act on. Every organization with contractors, advisers, or personally owned devices reaching corporate resources has some population that sits outside that boundary. Gryxa is built to rebuild itself faster than manual remediation completes, so on a host in that population the actor has time on their side.

IOCs

Artifact	Details
wirbe[.]com	Actor-controlled domain
world.wirbe[.]com	Actor-controlled domain
cdn.wirbe[.]com	Actor-controlled domain
ver.wirbe[.]com	Actor-controlled domain
mesh.wirbe[.]com	Actor-controlled domain
seczio[.]com	Actor-controlled domain, legacy infrastructure still in use
debian.seczio[.]com	Actor-controlled domain, legacy infrastructure still in use
gryxa[.]com	Actor-controlled domain, legacy infrastructure still in use
ui.gryxa[.]com	Actor-controlled domain, legacy infrastructure still in use
update.gryxa[.]com	Actor-controlled domain, legacy infrastructure still in use
sevrz[.]com	Actor-controlled domain, legacy infrastructure still in use
ui.sevrz[.]com	Actor-controlled domain, legacy infrastructure still in use
update.sevrz[.]com	Actor-controlled domain, legacy infrastructure still in use
144.172.107[.]56	IP address of actor-controlled infrastructure
209.145.55[.]189	IP address of actor-controlled infrastructure

A Social Engineering Attempt Against ReliaQuest: What We Found

Sun, 23 Aug 2026 18:00:00 GMT

On August 22, 2026, ReliaQuest was the target of a social engineering attack. While unsuccessful beyond temporarily exposing one identity, the attempt was an important reminder of the persistent tactics of threat actor groups and what all organizations can do to guard against them. We are sharing the full details of this attempt for transparency and so others can learn from this playbook.

The threat actor registered a lookalike domain and stood up a fake ReliaQuest single sign-on (SSO) page behind a content delivery network. The threat actor then called multiple ReliaQuest teammates, each time posing as a security employee by name in an attempt to steer them towards the fake page. One teammate entered their password and approved the push notification on their phone. That handed the attacker a brief session on our identity dashboard.

The extent of the access was view only. No ReliaQuest applications or systems were accessed, and no customer data was ever touched. The threat actor continued with attempts to access these applications from the dashboard but was consistently denied due to the security controls in place.

Our defense in depth starts from the assumption that a threat actor will eventually phish someone's account. Phishing works. Even well-trained people can be deceived by a convincing caller who knows a teammate's name. We don't treat a sign-in to our identity provider as permission to do anything at all. Our controls include device trust which prevent non-ReliaQuest devices from accessing any application or systems and containment actions terminated the attacker's sessions, expired the password, and reset every authentication factor.

Our investigation, which included a complete audit of our control fidelity, device trust, on-network access and any suspicious subsequent activity in the last 48 hours, has found the following: the threat actor obtained a single identity session with view-only access to our identity dashboard before access was terminated. No additional identities were accessed, no business applications were reached, no customer or ReliaQuest data was accessed beyond the user's login credentials, and no persistence was established. Claims that ReliaQuest was compromised or targeted by ransomware are false.

This playbook is consistent with what we are seeing across the industry: an impersonation call, a throwaway lookalike domain registered and burned within the hour, a harvesting page behind a content delivery network, MFA push abuse, and a rapid attempt to enroll a new authenticator.

The 5 Stages to Common Finance Fraud Attacks—and How to Stop Them

Tue, 07 Jul 2026 09:00:00 GMT

Attackers targeting financial institutions have moved up the stack. Instead of attacking infrastructure head-on, they go straight for identity, trust, and human behavior—the layer where a stolen credential becomes a wire transfer. What looks like five separate fraud types is usually one operation moving through stages, each setting up the next. Under each stage are the named attack types it covers—the fraud your team likely already tracks, shown in the order a full operation tends to move through. Follow it from the outside in, and the places to break the chain come into focus.

Stage One: Harvesting Credentials Outside the Perimeter

Credential theft · brand and domain impersonation · dark-web credential exposure

The operation starts where internal tools have no visibility. Adversaries register lookalike domains, clone login pages, and harvest customer and employee credentials at scale before validating them against real authentication surfaces. In Q1 2026, impersonating domains overtook credential exposure as the dominant external risk signal against finance.

This is the cheapest point to interrupt the chain, because no valid session exists yet—and interrupting it means looking outward, not just inward. Monitor domain registrations for lookalikes of your brand, watch dark-web and paste sites for leaked credentials, and pursue takedowns on spoofing infrastructure before it goes live. Phishing-resistant MFA such as FIDO2 or passkeys does the rest: even harvested credentials don't yield a usable session.

Stage Two: The AI-Generated Lure

AI-generated phishing · spearphishing · business email compromise (BEC)

Phishing-for-information was the single top MITRE technique against finance last quarter. Commodity AI tooling stripped out the skill and time these campaigns used to demand, so volume and quality climb together—and they move faster than most pipelines can keep up. If detection logic only runs after data lands and indexes in a SIEM, you're measuring response in hours while the attacker measures it in minutes. Closing that gap is mostly about proximity and automation: run detection as close to the event as possible, automate phishing triage so analysts aren't hand-reviewing every reported email, and enforce DMARC, DKIM, and SPF so spoofed senders fail authentication before they reach an inbox.

Stage Three: Impersonation That Turns Access into Approval

Executive impersonation · deepfake fraud · authorized push payment (APP) fraud

A foothold isn't a payout. To move money, the operation needs authority, so it escalates to the people who have it. The target is a finance leader who can approve a transfer, reached through a channel no perimeter tool watches.

Technical controls alone won't stop a convincing deepfake; process will. Require out-of-band verification for payment approvals above a threshold, using a known callback number rather than contact details supplied in the request itself—the single most effective control against authorized push payment fraud.

Detection has a role too, but only when the signals combine: an anomalous executive login means little on its own and a great deal alongside a payment approval request arriving through an unusual channel or at an odd hour. Threat intelligence that maps these actors' known techniques to your environment is what turns "unusual" into "recognized.”

Stage Four: Moving Like an Insider

Account takeover · privilege abuse · insider threat

Once the operation holds legitimate credentials and executive cover, it stops looking like an attack. A permission change in identity, a data pull in SaaS, an access pattern in cloud—each event looks ordinary in its own tool, and surfaces as a threat only when all three are read as one sequence.

This is a correlation problem before it's a detection problem, and teams lose here when their signals sit in incompatible schemas that force manual stitching. Normalize telemetry across identity, SaaS, endpoint, and cloud so behavior reads as a single sequence. Enforce least privilege and just-in-time access so one compromised account can't roam. And baseline normal behavior per identity, so the abnormal data pull stands out against that user's own pattern rather than a generic threshold everyone trips.

Stage Five: The Payout

Wire fraud · ransomware · data exfiltration

The operation ends in a transfer, an exfiltration, or ransomware—and finance ransomware surged 44% quarter over quarter. Much of that pressure is opportunistic: Clop’s mass exploitation of managed file-transfer tools like MOVEitand Cleo hit the sector hard precisely because finance relies on them, while groups like DragonForce show more deliberate sector focus. Every minute here is active loss, which makes two things decisive:

Detect on behavior rather than payloads, because these operators live off the land with signed binaries that signature tools wave through; the tells are the actions, such as mass file access, unusual outbound transfer, and credential dumping.
Contain automatically. A human connecting signals across tools is too slow at this stage, so isolating a host, disabling an account, or blocking a destination has to happen without waiting on manual triage.

Where GreyMatter Fits

Every stage above describes defense that should happen. The hard part is doing all of it, across every tool, fast enough to matter. That's the agentic defense layer GreyMatter is built to be.

GreyMatter detects at source, at storage, or in transit, running multi-event correlation on data while it is still streaming, before it is parsed, indexed, or stored—which takes mean time to detect from hours to seconds. The Universal Translator maps every field from 300+ connected technologies into a unified OCSF schema the moment each tool connects, so identity, endpoint, SaaS, and cloud activity correlate as one sequence without centralizing the data first; that is the stage-four correlation problem, solved at ingest.

Six agentic systems cover the disciplines a lean team can't staff: the IR Analyst Teammate investigates every alert autonomously at 99.4% accuracy, while threat intel continuously maps finance-sector actor behavior to your environment. For financial services, that adds up to containing identity-based attacks at machine speed and producing a full audit trail for DORA and SEC compliance.

ReliaQuest's finance customers have reached average mean times to contain of under 5 minutes; Donnelley Financial Solutions cut its own from two hours to three minutes. Your existing tools stay where they are. GreyMatter reads them as one defense instead of six.

Retail's Incident Volume Nearly Tripled as Attackers Went Quieter and Faster. Here’s How To Defend Against it.

Wed, 27 May 2026 04:00:00 GMT

Attackers entering retail environments in Q1 2026 abandoned the technique most defenses are optimized for. The sector's incident volume nearly tripled quarter-over-quarter, even as phishing fell from 22% to 9% of observed initial access methods. It was replaced by systematic network reconnaissance, IP address enumeration, and External Remote Services exploitation that collectively account for over half of all techniques observed.

The replacement techniques are faster, quieter, and span more tool boundaries than phishing ever did. A phishing email gets caught by a gateway or reported by a user. An attacker mapping your exposed VPN endpoints and walking through harvested credentials generates telemetry scattered across network, identity, endpoint, and cloud tools simultaneously—each speaking a different query language, each requiring separate investigation workflows, each adding minutes to a detection timeline measured against an attacker moving in as little as 4 minutes.

Retail didn't get a harder version of the same problem. It got a structurally different problem that breaks the assumptions underneath most detection architectures.

The Defender's Math Doesn't Add Up

Retail security teams’ investigation time is dominated by pivoting across disconnected tools—Vectra, SentinelOne, Splunk, Okta—manually consolidating context that should be unified from the start.

Run the math on what that means against Q1's threat profile:

Attacker speed: Initial access to lateral movement in minutes (Scattered Lapsus$ Hunters, Akira)
Analyst workflow: 6+ tool pivots per investigation, each requiring different query syntax, each adding minutes
SIEM detection latency: Hours from event to indexed, searchable data—reconnaissance closes before the query runs
Volume curve: Incident volume nearly tripled QoQ; headcount didn't

Multiply investigation time per alert by three times the volume, against attackers who complete exploitation within the SIEM indexing window. Every variable moves in the attacker's favor simultaneously. Adding analysts multiplies cost but preserves the sequential workflow. Increasing SIEM ingestion multiplies spend but doesn't reduce detection latency on data in motion. The architecture itself is the constraint.

Meanwhile, Akira runs SEO poisoning campaigns through trojanized installers that bypass email controls entirely. FortiClient EMS (CVE-2026-21643) under active exploitation gives attackers direct paths into POS and endpoint management systems. The Axios supply-chain compromise hits retail websites, payment apps, and Node.js tooling. Each vector enters through a different tool boundary. Each requires correlation across tools that don't natively share context.

The defense must detect across tool boundaries at machine speed, correlate without centralization, and absorb volume spikes without proportional headcount growth. That's an agentic architecture problem.

How GreyMatter Solves the Three Constraints

GreyMatter sits across your existing tools—SIEM, EDR, identity, cloud, network—without requiring data centralization or technology replacement. Three capabilities map directly to retail's broken math:

Constraint: Detection Latency (SIEM Can't Surface Reconnaissance Fast Enough)

GreyMatter Transit runs multi-event correlation logic on data streaming from connected technologies while still in motion—before parsing, indexing, or storage. The correlation engine holds partial event sequences in temporary state and fires the moment pattern criteria complete. Reconnaissance-to-exploitation sequences, credential-stuffing bursts against loyalty portals, anomalous VPN logins from VPS infrastructure—detected in seconds on data you may never need to store.

The Universal Translator normalizes every field from every connected technology to OCSF at connection—so Transit correlates across Splunk, CrowdStrike, Okta, and SentinelOne telemetry simultaneously against one normalized schema. A detection written once applies everywhere.

Retail customers average 33% reduction in SIEM ingest costs with detection at source. One retail organization opened 30 new stores without increasing their SIEM license.

Constraint: Volume Outpacing Analyst Bandwidth (Nearly 3x Incidents, Same Headcount)

Six Agentic Teammates operate autonomously 24/7—each decomposed into hundreds of single-task agents routed through GreyMatter's AI Model Broker for optimal model selection on every task.

The IR Analyst Teammate investigates and responds to every triggered alert—built-in, custom, native from connected tools—at 99.4% accuracy without human intervention. Circle K saw alert noise to internal teams drop 95% and threat containment time cut 99%. The Detection Engineer Teammate builds, deploys, and validates detection logic; customers see 5x MITRE ATT&CK coverage increase within the first year. The Threat Hunter executes against reconnaissance patterns—scanning activity, PsExec/WinRM lateral movement, VPN anomalies—without being prompted.

Automated Response Playbooks bring mean time to contain to 3.32 minutes.

Constraint: Credential Exposure Outside the Perimeter (58% of DRP Alerts)

GreyMatter Digital Risk Protection monitors credential exposure across open, deep, and dark web—tracking threats to retail continuously. Exposed credentials feed directly into the IT Engineer Teammate for automated rotation guidance and into the IR Analyst for account-takeover detection in motion.

Fake storefronts, brand impersonation, seasonal worker credential sharing, and leaked customer credentials are monitored and actioned through the same agentic workflow—exposure triggers investigation triggers response without manual handoff.

The Architecture That Beats Agentic Offense

Retail's threat actors moved to coordinated, multi-boundary, machine-speed offense. The defense layer must match that structure: detect across every tool boundary simultaneously, correlate without waiting for centralized storage, and operate investigations autonomously at the volume the environment demands.

Flat-fee pricing—no token costs, per-query charges, or investigation limits—keeps security decisions operational rather than financial when incident volume triples in a quarter.

Ransomware Groups Strike Healthcare at 2 AM, The Industries Slowest Hour. Here’s How to Respond.

Wed, 27 May 2026 09:00:00 GMT

Every healthcare CISO knows the calculus. Isolating a compromised machine takes seconds—unless that machine is running cardiac monitoring, processing medication orders, or connected to an infusion pump in the ICU. Then it takes a phone call, a risk assessment, and a prayer that the attacker hasn't moved laterally while you were deliberating.

The AI Hesitation in Healthcare Is Rational

Healthcare security teams know—often from experience—what happens when a containment action hits the wrong system.

The CISO managing end-of-life care units knows that isolating a network segment could disconnect palliative monitoring. The security engineer at a multi-site health system knows that disabling a shared service account could lock clinicians out of medication dispensing across twelve facilities simultaneously. The SOC analyst pulling the overnight shift—already stretched across too many tools with too little budget—doesn't have the context to make that call alone at 3 AM.

So they wait. They escalate. They build manual approval chains that add hours to containment because the alternative—acting fast and wrong—carries consequences no other industry faces. A bad containment action in financial services costs money. A bad containment action in healthcare can cost a life.

This caution is justified; unfortunately, it's exactly what attackers count on.

The Calculus Has Changed

Healthcare remains among the most highly targeted sectors, with average breach costs at $7.42 million. Attackers have learned to exploit the operational sensitivity that makes defenders hesitate. They launch at 2 AM on weekends when human response degrades. They target identity first, knowing lateral movement will outpace any manual approval workflow. They've shifted to dual extortion—exfiltrating PHI and threatening to leak it directly to patients.

ReliaQuest threat research shows phishing-driven initial access and overall incident volume both climbing significantly quarter over quarter across healthcare customers. The attackers are getting faster while the defensive model—human analysts, manual approval workflows, after-hours staffing gaps—stays fixed.

The question every healthcare CISO now faces: Which is the greater patient-safety risk: a well-governed AI response executing in minutes, or a human response arriving hours after the attacker has reached clinical systems?

Risk-Adjusted Agentic AI: The Decision Framework

The organizations getting this right didn't hand AI unchecked authority. They deployed a governance architecture—that gives AI precision, not blanket power.

1. High-fidelity playbooks on deterministic rules.

Known-bad activity—confirmed C2 callbacks , validated exfiltration patterns, credential stuffing from blocklisted IPs—triggers immediate containment with no approval gate. Zero-ambiguity scenarios where the risk of waiting always exceeds the risk of acting. Start here.

2. Lists that define clinical topology.

Domain controllers, attending physicians, emergency department machines, ICU-connected devices, life-safety systems—these lists provide inline context that modifies containment behavior based on asset criticality. A compromised billing workstation gets isolated immediately. The same indicator on a clinically critical system triggers full autonomous investigation, with the containment decision surfaced to a human, evidence already assembled.

3. EMR and HIPAA systems as inline context.

Your response system should use connected EMR infrastructure to calibrate response aggressiveness without accessing or exposing patient data. It needs to know which systems touch patient care and adjust accordingly.

4. Environmental memory.

Your response system should retain context about your environment and your team's past decisions over time. A containment action overridden six months ago should inform future recommendations. The system calibrates with every interaction, sharpening its understanding of your clinical risk tolerance without manual reprogramming.

AI Governance in Clinical Environments

Deploying AI response demands governance over how it operates—healthcare organizations can't accept a black box making containment decisions on life-critical systems. The ReliaQuest GreyMatter agentic AI security operations platform addresses this directly with two purposeful architectural decisions:

Task decomposition for accuracy. GreyMatter doesn't make monolithic decisions. It decomposes every investigation into hundreds of single-task agents—each handling exactly one step—routed through GreyMatter's multi-model AI broker to the best-suited model for that specific job. Accuracy compounds when no single agent carries the full decision weight. Production accuracy sits at 99.4%.
Instance-specific learning. What the platform learns about your clinical topology stays within your environment. Patient data feeds context—never training.

How One Healthcare Organization Made the Shift

A mid-size behavioral health provider operating across multiple states faced the same paralysis: a lean security team, no overnight SOC coverage, and a growing alert volume they couldn't investigate fast enough to contain before lateral movement completed.

They started with high-fidelity detection rules where the correct response is always immediate containment regardless of asset type. Those went live as automated playbooks with no approval gate.

Next: the asset context layer. Domain controllers, EMR-connected systems, VIP clinician accounts, and emergency department devices were tagged and fed as inline context to the IR Analyst Agentic Teammate. Any alert touching those assets gets full autonomous investigation with containment surfaced to a human, reducing decision time from hours to seconds.

Their mean time to contain now averages approximately 12 minutes. Against the sector's 2-hour-47-minute mean time to contain, those 12 minutes represent a fundamentally different operating posture without adding headcount and without sacrificing patient safety.

The Manufacturing Industry Faced Four Attack Types at Once In The Last 90 Days. Here’s How To Stop All Four.

Wed, 27 May 2026 09:00:00 GMT

Manufacturing customer incident volume nearly quadrupled between Q4 2025 and Q1 2026—the largest single-quarter spike of any sector ReliaQuest tracks. During that same window, ransomware claimed 442 manufacturing victims, credential exposure surged past half of all digital risk alerts, and removable media techniques doubled.

The SOCs that absorbed this without adding headcount share one architectural trait: autonomous systems executing investigation and containment at machine speed, with human analysts reserved for decisions requiring judgment.

Coordinated, Multi-Vector Pressure

This volume increase came from simultaneous campaigns running in parallel against the same sector — each generating independent alert streams a SOC must process concurrently:

Qilin, Akira, and NightSpire ran concurrent ransomware operations against manufacturing targets. NightSpire weaponized FortiOS auth bypass (CVE-2024-55591) within days of disclosure.
Credential harvesting—now more than half of all DRP alerts—fed those campaigns with valid access, collapsing the boundary between "compromised credential" and "production-environment breach."
Microsoft 365 device code phishing created BEC pathways that bypass traditional credential-based detection entirely.
Axios npm compromise (UNC1069/WAVESHAPER.V2) introduced supply-chain risk directly into industrial platforms and internal tooling.

Each vector generates its own alert stream. A manual SOC processes them sequentially: analyst picks up alert, pivots across tools, builds context, escalates or contains. At four-minute breakout times, that sequential model means the attacker completes lateral movement before the first investigation closes.

Now multiply that workflow by 4x volume.

Addressing This Spike Requires Agentic Architecture

Three common responses to volume spikes, and why each one fails structurally against what manufacturing faced last quarter:

More analysts add linear capacity against exponential load. Each human works sequentially, tool by tool. The gap between analyst throughput and attacker speed widens with every additional campaign running in parallel.
MSSP escalation adds another sequential bottleneck. MSSPs specialize in single-tool management—they see CrowdStrike alerts or Splunk events, rarely the cross-environment attack chain that starts at identity, moves through endpoint, and lands in OT.
SIEM centralization requires ingestion before detection. At manufacturing telemetry volumes without tiered architecture, that gap between event and alert widens—and budget consumed before coverage materializes.

The individual TTPs are familiar—LOLBins, manual RDP lateral movement, and credential dumping. No single campaign required extraordinary sophistication to execute. The structural challenge is concurrency: four independent operation types running simultaneously, each generating alert streams that a sequential SOC must process one at a time.

The upstream fix is straightforward: patch within the disclosure window, enforce credential rotation, eliminate exposed remote access. Manufacturing's operational reality—change windows scheduled quarters out, production uptime prioritized against every minute of downtime—makes that structurally slow. The detection and containment layer must compensate for the gap between disclosure and remediation that this sector can't close fast enough.

Matching that concurrency requires defense architecture that investigates and contains across all vectors in parallel.

What Agentic Defense Looks Like Running Against a 4x Spike

When an alert fires in GreyMatter, the IR Analyst persona breaks the investigation into component tasks and runs them in parallel: one agent correlates endpoint telemetry, a different agent checks identity logs, a different agent queries IT/OT boundary telemetry (firewall logs, historian data, network flows by Purdue Level), all pulling environmental context from connected technologies over API in real time. Every alert gets this treatment. Simultaneously. Twenty-four hours a day without being prompted.

That parallel execution matters because the attacks manufacturing faced in Q1 span environments—credential harvested via phishing, used to authenticate through VPN, leveraged for lateral movement toward production systems. GreyMatter's Agentic Teammates investigate across the full attack chain simultaneously because the Universal Translator already normalized that telemetry at the field level.

Detection runs on data in motion—GreyMatter Transit executes multi-event correlation on streaming telemetry before anything is stored. OT data that would otherwise go unmonitored gets detection coverage in seconds, then gets dropped or routed based on policy.

Automated containment in manufacturing requires precision about scope. GreyMatter's Automated Response Playbooks execute IT-side actions autonomously—revoking compromised tokens, isolating endpoints exhibiting lateral movement, terminating VPN sessions authenticated with harvested credentials, deleting phishing emails mid-delivery.

Containment actions affecting OT-adjacent infrastructure route to human approval with full investigative context already assembled—the platform builds the case at machine speed, the operator makes the production-impact call.

Metric	YTD 2026
Detection	~27 minutes, held flat despite 4x volume
Automated containment (ARP)	4.36 minutes—inside the breakout window
Overall time-to-contain	Cut by a third vs. prior period

Phishing Targeting Financial Services Tripled in a Single Quarter. Here’s How to Defend Against It.

Wed, 27 May 2026 04:00:00 GMT

Phishing infrastructure targeting financial services has tripled in a single quarter—now accounting for half of all observed threat activity against the sector. Brand-impersonating domains have overtaken credential exposure as the dominant digital risk signal, feeding account-takeover pipelines at scale.

Nearly 150 financial organizations hit by ransomware in 90 days, with Clop and DragonForce demonstrating deliberate sector specialization above all-industry baselines.

These campaigns share a structural characteristic: they're multi-vector, machine-speed, and low-skill to execute.

What AI Offense Looks Like in Practice

Actor	Technique	Fraud Vector
Lazarus Group	Fake developer recruitment pipelines, fabricated repositories	Credential theft at scale
APT42	Spearphishing via .lnk files with Dropbox C2	Executive account takeover
UNC1069	Deepfake Zoom calls + ClickFix lures	Authorized push payment fraud

Each operates with an automation layer that removes the skills barrier—what required specialized teams three years ago now scales with commodity AI tooling.

For a sector where minutes of service disruption carry regulatory exposure, fraud loss, and brand damage, the math is stark: mean time to contain rose 49% last quarter to 2 hours and 34 minutes per incident.

Every one of those minutes is active exposure—funds moving, credentials being monetized, lateral movement progressing.

Why the Current Architecture Can’t Match AI Offense

Current defense models share a structural failure—they leave the underlying architecture intact:

Centralize in a SIEM—too expensive, too slow, creates coverage gaps the moment ingestion costs force tradeoffs
Outsource to MDR—single-threaded visibility into one tool, no network effect across the environment, no tailoring to your business logic
Add headcount—human-speed work against machine-speed attacks, burnout for the people you can least afford to lose
Siloed AI tools—can't act beyond their own data boundaries, no unified picture to operate on

That world is gone. Enterprise data now lives across EDR, email, network, cloud, SIEM, and in the hands of executives traveling globally. It grows with every acquisition, every new geography, every AI tool the business adopts. Defenders must secure everything, everywhere, continuously—and they're doing it with architectures that force analysts to pivot between six disconnected tools per investigation, manually re-querying across incompatible schemas.

Centralizing everything in a SIEM is too expensive, too slow, and creates coverage gaps the moment ingestion costs force tradeoffs. Outsourcing to MDR providers means single-threaded visibility into one tool—no network effect across the environment, no tailoring to your business logic. Adding headcount puts human-speed work against machine-speed attacks and burns out the people you can least afford to lose. And siloed AI tools can't act beyond their own data boundaries—they have no unified picture to operate on.

The consistent failure across all of these: they leave the underlying architecture intact. Detection still happens after centralization. Correlation still requires manual field mapping. Response still waits for a human to connect signals across tools.

What Agentic Defense Actually Requires

If offense is automated, multi-vector, and operating at machine speed across distributed infrastructure—defense must match it structurally. That means:

Detection before centralization. Applying correlation logic in-transit closes the gap between telemetry generation and threat identification to seconds.
Schema-native correlation from day one. Automatic field-level normalization at ingest eliminates the manual translation bottleneck across every connected technology.
Autonomous, multi-disciplinary response. Parallel investigation across identity, endpoint, network, and email simultaneously—matching the multi-vector structure of agentic attacks.
Cost architecture decoupled from usage. Defenders should never face a choice between investigation thoroughness and budget.

GreyMatter: Agentic Defense in Production

ReliaQuest built GreyMatter's architecture around these requirements. The Universal Translator maps every field from 300+ connected technologies to OCSF at the moment of integration—schema-native correlation from day one.

GreyMatter Transit applies multi-event detection logic to data in motion, firing correlation rules before anything is parsed or stored—5 seconds from telemetry event to validated alert.

Six autonomous agentic systems decompose security disciplines into hundreds of single-task agents. The IR Analyst teammate breaks every investigation into parallel component tasks—email metadata, identity anomalies, endpoint telemetry, domain reputation—each routed through an AI model broker that selects the optimal model per task.

Across ReliaQuest's finance customer base, Automated Response Playbooks execute containment in 4 minutes 46 seconds. The sector average: 2 hours and 34 minutes.