ReliaQuest Blog - Threat Hunting, Security Operations, and More

ReliaQuest's Agentic AI Uncovers New China-Linked Cluster OP-512

Fri, 05 Jun 2026 11:00:00 GMT

Editor’s note: This report was authored by Alexa Feminella

Key Points

ReliaQuest's Agentic AI surfaced a suspected new China-linked espionage cluster, “OP-512,” by correlating a high volume of seemingly unrelated events at machine speed into one high-priority incident that our threat research experts then validated.
OP-512 deployed a custom web shell framework to a compromised Internet Information Services (IIS) server. Each deployment is cryptographically unique, making signature-based detection ineffective.
OP-512 is at least the fourth China-linked cluster documented targeting legacy IIS servers in the past year. Organizations running end-of-life .NET frameworks on internet-facing servers should prioritize migration or segmentation immediately.

ReliaQuest’s Agentic AI recently surfaced what we assess with moderate-high confidence to be a new China-linked cluster, which we’re tracking as “OP-512.” Our AI agent stitched together a high volume of seemingly unrelated suspicious events across a customer’s environment into one high-priority incident, revealing a coordinated intrusion that manual review alone would have been unlikely to reconstruct at the same speed, if at all. ReliaQuest threat research analysts then reviewed and validated the findings.

OP-512 was highly likely conducting espionage through a compromised Internet Information Services (IIS) web server on an organization whose sector and geography align with China-linked intelligence priorities. Despite sharing techniques with broader China-linked threats, OP-512’s tools, infrastructure, and operational profile don’t match any known actor. It's at least the fourth China-linked cluster publicly documented targeting IIS web servers in the past year. But its tooling is built to evade the defenses that work against the other three.

At the center of the operation is OP-512’s custom web shell framework, consisting of three web shells (malicious files that give attackers remote access through a web browser). This framework combines capabilities we rarely see together: Each deployment is uniquely generated, access is restricted to the attacker through cryptographic controls, and compromised servers automatically report back for centralized management at scale.

The investigation also showed clear intent to stick around. The targeted server showed signs of access 75 days earlier. But rather than moving on, the attacker returned, a hallmark of state-aligned espionage. Within hours, the attacker deployed web shells, established multiple command channels, and escalated privileges.

In this report, we:

Map OP-512 against known China-aligned operations and explain our attribution assessment.
Walk through the full attack chain and show why endpoint prevention alone failed to stop it.
Analyze the web shell framework's design with detection guidance beyond traditional signatures.

Where OP-512 Fits In and Where It Stands Alone

OP-512 is at least the fourth China-linked cluster documented to be targeting IIS servers in the past year. It shares narrow tactical overlaps with each but matches none of them, making it highly likely to be a previously unseen addition to an already crowded attack surface. Espionage clusters aren’t smash-and-grab operations; they’re built for patience, maintaining access for months—or years—before acting on their objectives (commonly IP theft, communications monitoring, or future operations). Detection rules tuned to known groups likely won’t catch OP-512, and the longer it goes undetected, the deeper it embeds.

Figure 1 provides a high-level overview of the attack chain. In this section, we’ll first explain why we believe OP-512 is highly likely a new cluster, then dig into the technical details.

Figure 1: High-level attack chain

There's a reason these four China-linked clusters have converged on the same technology. IIS servers in a demilitarized zone (DMZ) sit at the boundary between internet-facing and internal networks. They often receive less monitoring than core infrastructure, which is why espionage operators looking to move inward to use them as pivot points.

So why do we think OP-512 is distinct? We compared this incident's tooling, infrastructure, and objectives against the three China-linked operations most active against similar targets over the past year.

Feature	OP-512	CL-STA-0048¹	GhostRedirector²	DragonRank³
Primary Motive	Espionage	Espionage	Search engine optimization (SEO) fraud	SEO fraud
Target Asset	IIS servers	Edge devices and servers	IIS servers	IIS servers
DNS Technique	Self-reporting via hex-encoded subdomain queries	Data exfiltration via hex-encoded subdomain queries	None documented	None documented
Privilege Escalation	GhostKit, BadPotato, EfsPotato SweetPotato	BadPotato, RasmanPotato	BadPotato, EfsPotato	BadPotato, GodPotato, PrintNotifyPotato
Custom Implants	Yes	Yes (PlugX, Cobalt Strike)	Yes (Rungan, Gamshen)	Yes (BadIIS, PlugX)

“CL-STA-0048” is the closest match. Both operations use DNS-based covert signaling with encoded data embedded in subdomain strings, a technique public reporting has highlighted as rare. But the two serve different purposes. CL-STA-0048 encodes stolen data into subdomain strings to exfiltrate it. OP-512 encodes each web shell's own URL into a DNS query to report its deployment location back to attacker infrastructure. The encoding method is the same, but the intent is different.

Hex-encoded subdomain queries are uncommon enough that their presence in both operations is unlikely to be coincidental. It suggests shared tooling, shared training, or a direct operational relationship. Researchers have noted connections across these clusters while continuing to track them separately, pointing to a broader ecosystem drawing from shared resources rather than a single coordinated operation.

Where OP-512 Breaks Away in a Crowded Hunting Ground

Where this cluster diverges is in sophistication. The web shell framework uses per-deployment cryptographic uniqueness, RSA and RC4 authentication, and timestomping (the deliberate manipulation of file timestamps to disguise when a file was created or modified). This ensures each instance evades signature-based detection, restricts access through layered encryption, and obscures forensic timelines. That combination of capabilities, especially the per-deployment cryptographic uniqueness, goes well beyond the commodity tools typically used by financially motivated groups like “GhostRedirector” and “DragonRank.”

It's realistically possible OP-512 represents an existing cluster that has entirely retooled, with CL-STA-0048 as the strongest candidate. The shared use of hex-encoded DNS subdomain queries makes that plausible. However, CL-STA-0048 has historically relied on widely available tools like “PlugX” and “Cobalt Strike.” OP-512's framework represents a fundamentally different level of investment in custom tooling and operational security, one that is difficult to reconcile with CL-STA-0048's documented capabilities.

It's also possible CL-STA-0048 developed these capabilities independently, but doing so without any continuity in infrastructure, implants, or targeting patterns would be unusual. Combined with the unique framework and dedicated infrastructure, we assess with moderate-high confidence that OP-512 is a distinct cluster operating independently.

With attribution established, the next section walks through how the intrusion unfolded and why endpoint prevention alone couldn't stop it.

75 Days of Patience, Then a Sprint

The compromised server was running Windows Server 2016 with end-of-life .NET Framework 4.0, a framework that hasn't received security updates since 2016. EDR telemetry had flagged web shell activity on the same host 75 days earlier, including DNS queries to a different attacker-controlled domain (ashx.lhlsjcb[.]com). The specific access path wasn't conclusively determined, though the legacy .NET 4.0 application on an internet-facing host presents a plausible attack surface.

What followed was fast and methodical.

Dual Notification Channels Established in Seconds

The web server's worker process (w3wp.exe) wrote the first of three web shells to the application's upload directory: a .aspx file manager with a built-in C2 notification channel. Within seconds, the self-reporting notification kicked in, transmitting the web shell’s location through two independent channels. The primary channel was a DNS query to an attacker-controlled domain. If the DNS query failed, the web shell fell back to an HTTP request to a separate command-and-control (C2) server, carrying the same encoded path. Community reporting has linked the fallback server's IP address to “Meterpreter” infrastructure.

These notifications are one-way. They report the location but don't receive commands. The actual command interface came next: Two .ashx cryptographic command handlers, each gated by the RSA+RC4 authentication (explored in detail later in this report), were deployed to the same directory shortly after. Together, the three web shells gave the attacker file management, authenticated command execution through two independent access paths, and automated reporting of the compromise, all before anyone had time to respond.

Privilege Escalation Tools Loaded Straight into Memory

With the web shells in place, the attacker moved to escalate privileges. They loaded four post-exploitation toolkits directly into the web server's process memory. Nothing was written to disk.

Three of these came from the publicly documented “Potato Suite” (“BadPotato,” “SweetPotato,” “EfsPotato”), a well-documented collection of Windows exploits that abuse built-in services to elevate access from a limited-service account to SYSTEM-level privileges. These tools appear frequently in China-linked operations, including CL-STA-0048 and GhostRedirector, making their presence here another attribution data point. A fourth toolkit was flagged in EDR telemetry as "GhostKit." No public documentation exists for a tool by this name, and it's likely a vendor-specific telemetry label rather than an established tool.

The only telemetry that caught this was EDR behavioral analytics detecting reflective .NET assembly loading within the w3wp.exe process. Without it, the activity would’ve been invisible.

The attacker then ran whoami and whoami /priv to check their account context and privileges, both issued as base64-encoded strings. Interestingly, the encoded commands matched character-for-character with the same commands we documented in the “Flax Typhoon” ArcGIS compromise. Identical encoding across two separate China-linked operations points to highly likely shared tooling or playbooks circulating within this ecosystem. The commands ran under a limited-service account, confirming the privilege escalation hadn't yet succeeded.

Prevention Fired, but the Attacker Stayed

Endpoint protection terminated the malicious process through behavior-based prevention. However, IIS automatically restarts worker processes when they crash or are killed, so the attacker's tooling reloaded across multiple successive process instances within minutes. Killing the process without isolating the host created a loop. Prevention fired repeatedly, but the activity continued.

Malicious DLLs That Outlast the Web Shells

Four malicious Dynamic Link Library (DLL) files were recovered from the ASP.NET temporary compilation directory on the compromised host. These are compiled artifacts that the .NET runtime automatically generates when .aspx or .ashx files are first accessed—in this case, the three web shells. They were detected and quarantined approximately 19 hours after creation.

Critically, these compiled DLLs persist even after the original web shell files are deleted. For incident responders, that means removing the web shells alone isn't enough. The ASP.NET temporary compilation directories need to be hunted down and cleared separately, or the compiled artifacts will remain on disk as forensic evidence and potential reactivation points.

A Cryptographically Locked Web Shell Framework

In the previous section, we walked through what OP-512 did with these web shells. In this one, we break down how they work and why they're so difficult to detect.

Three samples were recovered, which fall into two categories:

Category	Format	Role	Key Feature
File manager with C2 channel	.aspx	Reconnaissance, file operations, self-registration	Automatically transmits its own URL to attacker infrastructure on first load
Cryptographic command handlers (×2)	.ashx	Authenticated command execution	RSA signature verification + RC4 encryption; each implant uniquely generated

All three web shells include timestomping, the deliberate manipulation of file timestamps to disguise when a file was created or modified. A common forensic technique is to sort files by modification date to spot recently written artifacts. A web shell dropped in 2026 among files last modified in 2022 would stand out immediately. To counter this, the web shells scan every file and subdirectory around them, calculate the median last-modified timestamp, and overwrite their own creation and modification times to match. As a result, the web shells look like they’ve been there for years.

The function also accepts an explicit timestamp as input, giving the operator the option to backdate a file to a specific event or patch window rather than relying on the automatic calculation.

Drop It and Forget It: The Web Shell That Phones Home

The .aspx file manager was the first web shell deployed and the only one with a built-in C2 notification channel. This web shell's C2 channel activates whenever the page is visited, whether by the operator, an automated scanner, or even a legitimate user navigating to the URL. On activation, it encodes the web shell's own URL and transmits it as a DNS query to an attacker-controlled domain. If the DNS query fails, it falls back to an HTTP request to a separate C2 server carrying the same encoded path. A five-minute cooldown prevents repeated transmissions.

Beyond the notification, the shell provides standard file system operations: directory listing, read/write, upload, delete, rename, and the timestomping described earlier.

The design decouples deployment from discovery. The operator drops the file and moves on, knowing their infrastructure will catalog its location automatically. For defenders, this means any access to the web shell, even during incident response, may alert the attacker. Treat suspected web shell files as already compromised before interacting with them.

Cryptographically Authenticated Command Handlers

The two command handlers (.ashx files) follow the same structural pattern but were generated with different cryptographic keys. Identical code structure, combined with randomized variable and method names across both samples, strongly suggests an automated builder producing unique instances from a shared template.

The comparison (See Figures 2 & 3) shows the RC4 decryption function from both handlers. The algorithm is identical, but every variable and method name has been randomized. The builder also injects dead variables (_nkkspqwc = 1534 in one, _nbgrzrak = 6392 in the other) and junk comments (// rmluimqjmidu) that serve no functional purpose. The result: two files that perform the same operation but produce completely different file hashes, rendering signature-based detection useless.

Figure 2: RC4 decryption function — Command Handler 1

Figure 3: RC4 decryption function — Command Handler 2

When a command is received, the web shell processes it through four stages:

Base64 decode the HTTP request body
RC4 decrypt the resulting payload
Verify the RSA signature against the embedded public key
Execute the command only if verification succeeds

Each handler embeds a unique RSA public key. Without the corresponding private key, no-one can issue commands, not defenders, nor threat actors, not even another OP-512 operator using a different key pair. The layered encryption and signature verification also make command traffic difficult to inspect or replay at the network layer.

The two handlers on this server were deployed with different RSA keys, meaning they require different private keys to operate. This could represent separate operator access, distinct access tiers, or key rotation. Regardless, it reflects deliberate compartmentalization. Compromising one key doesn't grant access to the other implant.

Behavioral Telemetry Is the Only Path Forward

By now the pattern is clear. Nothing about this framework is static. The hashes change every deployment, code is obfuscated, and command traffic is encrypted. Signature-based detection may not catch it, but here’s what will:

What to Look For	Why It Matters	Prerequisites
`w3wp.exe` initiating outbound DNS queries with abnormally long, hex-segmented subdomains	This is how the self-reporting notification transmits the web shell's location. Normal web server DNS queries don't contain long hex strings as subdomains.	DNS sensor coverage or resolver logging at the network edge. Baseline normal DNS behavior from web server hosts first, as some content delivery network (CDN) and analytics services generate long subdomains.
ASP.NET content (`.aspx`, `.ashx`, `.asmx`) loading cryptographic components through reflective loading rather than direct code references	Legitimate handlers reference cryptographic libraries directly. Loading them at runtime through reflection is unusual and designed to evade static analysis.	EDR telemetry monitoring .NET events within `w3wp.exe`.
ASP.NET temporary compilation directories generating DLLs from newly created .`aspx` /`.ashx` files outside normal deployment cycles	New DLL compilation outside deployment windows is a high-confidence indicator of web shell deployment.	File integrity monitoring on ASP.NET temporary compilation paths. Baseline normal compilation in active development environments first.
HTTP responses from `.ashx` endpoints returning encrypted or non-standard content	Encrypted response bodies from endpoints that should return standard content types indicate a covert command channel.	Web application firewall (WAF) or application-layer inspection with knowledge of the application's normal response patterns.

Step Up Your Defenses Against China-Linked Espionage

ReliaQuest’s Approach

The critical window in this intrusion was minutes, not hours. By the time endpoint protection generated an alert, the attacker had already multiple access paths in place. In fast-moving intrusions like these, where early detection depends on speed and correlation, ReliaQuest GreyMatter—especially GreyMatter Agentic AI—helps security teams detect, contain, investigate, and respond to threats before they escalate.

GreyMatter Agentic AI connects what would otherwise look like isolated, low-fidelity events into a single intrusion narrative—faster than any human analyst could. In this case, web shell creation, outbound DNS activity, dynamically loaded cryptographic components, a command shell spawned from a web server process, and outbound C2 connections all happened within a narrow window. Individually, each event might not trigger an alert, but together, they reveal the full attack chain. As attackers move faster, the ability to correlate complex activity at machine speed and subsequently automatically contain threats is what makes the difference between stopping an intrusion early and responding after damage is done.

GreyMatter Transit detects the self-reporting C2 channel at the earliest possible stage. The web shell transmits its location via abnormally long, hex-segmented DNS queries the moment the page loads. Transit catches these before data reaches storage, provided DNS telemetry is routed through it with visibility into outbound queries from web server hosts.

ReliaQuest Detection Rules: ReliaQuest detection content is continuous updated using the latest relevant threat intelligence.

GreyMatter Automated Response Playbooks address the specific problem we saw in this intrusion when endpoint prevention killed the malicious process, but IIS automatically restarted it. Automated containment removes the window attackers depend on. Organizations can reduce their mean time to contain (MTTC) to five minutes or less by deploying detection rules with the following Automated Response Playbooks:

Isolate Host: Quarantines the affected server at the first confirmed sign of web shell activity, triggered by w3wp.exe spawning cmd.exe or reflective .NET assembly loading. In this intrusion, earlier isolation would have stopped the attacker from re-establishing access through IIS process restarts.
Terminate Active Session: Kills active sessions on the compromised host, forcing the attacker to re-establish access. This matters here because IIS automatically restarts worker processes, so killing the process alone isn't enough. Most effective when paired with host isolation.

For faster containment, these Playbooks can be configured to execute automatically upon detection, removing the manual approval step and reducing response time to seconds.

Your Action Plan

These steps directly address the gaps this intrusion exploited.

Retire or isolate end-of-life .NET frameworks on internet-facing servers: The compromised server was still running .NET Framework 4.0, which has been unsupported since 2016. Prioritize migration or decommissioning. Where that's not immediately feasible, segment these servers from higher-value network tiers, restrict upload functionality, apply web application firewall (WAF) rules, and disable unnecessary IIS handler mappings.
Harden and monitor upload directories and compilation paths: Disable script execution in upload directories via IIS handler mappings for .aspx, .ashx, .asp, and .asmx files, and verify with a dedicated web.config. Monitor ASP.NET temporary compilation directories for new DLL creation outside normal deployment windows.
Don't close incidents until the root cause is fixed. Blocking outbound traffic or removing a web shell addresses the symptoms, not the entry point. Espionage clusters count on this, knowing they can return if the underlying vulnerability is still there. Incident closure should require confirmation that the exploited access path has been remediated.

Key Takeaways and What’s Next

Four China-linked clusters targeting the same technology in under a year is unlikely to be a coincidence. Internet-facing IIS servers running legacy, unsupported software remain a preferred entry point across this threat ecosystem and show no signs of slowing down.

What should concern defenders most is what makes OP-512 different. This threat cluster isn't using commodity tooling and recycling it across campaigns. It's using a purpose-built framework designed to defeat the detection methods that work against the other three clusters. Organizations that have tuned their defenses to known actors are likely not covered here.

ReliaQuest assesses that attacks on legacy IIS infrastructure will likely continue through 2026 and 2027, as long as these servers remain online. Organizations still running end-of-life .NET frameworks on internet-facing servers should treat this as a direct signal to fast-track migration plans and prioritize behavioral monitoring in the interim.

IOCs

These indicators are specific to this intrusion and may not appear in future OP-512 operations. Behavioral detections should take priority. The patterns most likely to persist across deployments are the self-reporting C2 structure (hex-encoded URL segments transmitted as DNS subdomains), IIS worker processes initiating outbound DNS or HTTP immediately after web shell file creation, and RSA+RC4 authentication in .ashx handlers.

Artifact	Details
ashx.lhlsjcb[.]com	DNS C2 domain observed during earlier activity on the same host, approximately 75 days before the primary incident. The use of a different domain from the later intrusion (hcgos[.]com) suggests infrastructure rotation between visits.
hcgos[.]com	DNS C2 domain used by the self-reporting notification channel. In logs, look for the subdomain pattern `a.<hex>.c.hcgos[.]com`
43.160.202[.]246:8053	Meterpreter C2 server on non-standard port
140.206.161[.]227:443	Outbound connection from compromised host
124.156.129[.]151	Source IP for web shell interaction. High-signal due to the combination of `python-requests/2.33.0` user agent, POST requests to upload paths containing `.aspx` files, and timing aligned with the web shell deployment window. The user agent alone is not a reliable indicator

Sources

¹ hxxps://www.imda.gov[.]sg/assets/a5395ab6-7388-4c1e-97db-18bdf654e163.pdf ²hxxps://thehackernews[.]com/2025/09/ghostredirector-hacks-65-windows.html ³ hxxps://thehackernews[.]com/2025/02/dragonrank-exploits-iis-servers-with.html

Beyond Point-in-Time Testing: 5 Use Cases for Agentic Red Teaming

Wed, 23 Sep 2026 06:00:00 GMT

Attackers have automated their attacks and are moving at machine speed. Defenders need to do the same to test their defenses against these automated, agentic AI attacks. That is why agentic red teaming and continuous attack path mapping are becoming increasingly important. Defenders need to move faster than the threat actors attacking them. Knowing you need continuous, autonomous testing is one thing. Knowing where to start with it is another. The shift is happening because testing once a year is no longer enough.

That's the fundamental problem with traditional red teaming: It's a snapshot. Red teams and penetration testers spend weeks probing your environment to deliver a point-in-time report. By the time remediation is underway, new assets, identities, integrations, and exposures may have already changed your attack surface. The report is a photograph of an environment that no longer exists.

Agentic red teaming closes that gap. Rather than a human team testing within a fixed window, autonomous AI agents reason continuously within your environment. They map how an attacker could move through it and validate whether your defenses actually hold, at machine speed and machine scale. It's the same class of agentic AI that attackers are weaponizing, except it's turned around and pointed at your own environment, so you find and fix the paths first. Below, we've highlighted the five use cases we see security teams adopting first.

1. Continuous Attack Path Discovery and Validation

The first and most common use case for agentic red teaming is mapping real, exploitable routes from an exposed entry point all the way to your tier-zero assets. Attackers do not think in vulnerability lists; they think in paths. A “medium” severity misconfiguration that no scanner flags as urgent can be the exact pivot that links an exposed edge device to a domain admin account. Agentic red teaming can then rerun that analysis continuously as your environment changes.

This is fundamentally a scale problem. Reasoning across thousands of possible combinations of exposures, permissions, and connections is exactly the kind of large-scale task that autonomous agents handle well. Just as importantly, running it continuously means you're testing the environment as it exists today, not as it looked during last quarter's red team test. The output is a visual attack path from initial access to impact, along with the specific recommendations and automatic remediations when it comes to detections and automated response plays.

2. Alert and Detection Validation

Most detections are written once and revisited only when they fail or create too much noise. A rule may fire in a known test, but attackers don’t operate through isolated techniques. They chain tactics, use valid credentials, and switch tools when controls get in the way. Even when an alert fires, it may lack the context an analyst needs to understand and stop the attack. The real test is whether your detections can see attackers as they actually operate.

Agentic red teaming closes that gap by validating alerts and detection logic against real attack paths rather than individual techniques. Starting from a known detection gap or an alert you want to test, the agent safely runs representative activity through the environment and checks whether the expected detection fires and where an attacker could change tactics to avoid detection. When the activity evades detection, the agent gives security teams the exact path and the specific gap to close, then runs the attack again to see if that gap has been closed. You get proof of what fired, what was missed, and what needs to change.

3. Identity Blast Radius Testing

Anyone who has worked in security has heard someone say, "the weakest link in an organization's defenses is the end user". Attackers only need stolen credentials or a hijacked active login session to get where they want to go. A compromised user, executive account, service identity, or forgotten administrator can be enough to reach far beyond its intended access. What matters is understanding how those permissions connect to the rest of the environment and what they make possible for an attacker.

Agentic red teaming starts with that single identity and follows the same question an attacker would: if this identity were compromised, how far could I get? Agents reason across identities, permissions, exposures, and controls. They map how one account inherits privilege, chains into other identities, and reaches a meaningful target through service accounts and forgotten admins, then validate whether the path is real. The output is a visual attack path showing the blast radius of one compromised identity, along with the specific changes that break the route. In practice, it means teams can harden the identities that create real exposure rather than eyeballing every permission that looks risky or waiting for the next point-in-time red team engagement.

4. Keeping Pentest Findings Current

Every pentest report starts to age the moment it is delivered. The team closes one finding, but a new asset comes online, a user is created, or an employee switches departments. A cloud permission changes. A new SaaS integration is added. By the time remediation is complete, the environment the testers assessed may no longer exist. The real question is whether its findings still describe the environment you have today.

Agentic red teaming ensures that report stays useful. Upload the findings from a recent penetration or red team test and let the agent test how those techniques would play out now, against the controls and infrastructure that exist today. It validates which findings remain exploitable, which remediations closed the gap, and where the environment has created a new route around the original fix. You get an up-to-date view of what still matters and what can be deprioritized. By retesting the report against today's environment, you no longer have to spend your team's limited resources confirming whether a vulnerability from a red team report two months ago still exists, and you don't have to chase down lower-priority findings that may no longer be relevant.

5. Threat-Informed Adversary Emulation

Threat actors do not all attack the same way. The groups targeting your industry have preferred entry points, tooling, techniques, and objectives. Testing against a generic attacker produces a generic answer. Testing against the threat actor most likely to target you shows where the real risk is. Most teams have plenty of threat intelligence. The catch is that it too often becomes a report someone reads instead of a test someone runs.

Agentic red teaming turns that intelligence into a running adversary. With agentic red teaming, you can mimic a specific threat actor's behavior, using the tactics associated with that group to map how a campaign could play out in your environment. It tests the routes that actor would be most likely to use, validates which controls are working, and identifies the areas where the group could have success. The output is a clear picture of how a threat actor targeting organizations like yours could reach its objective.

Putting Agentic Red Teaming into Practice

The teams getting the most out of agentic red teaming are treating it as a tool for continuous improvement rather than a single project. Testing happens again whenever the environment changes, whether it is a new asset, a new identity, or a new AI feature, so that change window is caught before an attacker can exploit it. Because the testing is fast and repeatable, it can run as often as needed instead of waiting for the next scheduled engagement. These teams prioritize by path rather than by score, fixing the chokepoints that break the most attack paths first. Finally, they close the loop, ensuring every validated finding becomes a detection, a hardening change, or a remediation ticket, automatically wherever possible.

None of this removes the human from the equation. Agents do the reasoning and execution at scale, but your experts still set the scope, approve the actions that matter, and own the strategy. This keeps your red team in control while giving it the speed and reach to keep up with adversaries who have already automated their attacks.

Validate and Close Attack Paths with GreyMatter Attack

These use cases are why we built GreyMatter Attack. It puts the same class of frontier AI that attackers use into the hands of defenders, so your team can map, validate, and close attack paths across the environment you have today.

You decide what to test and how to run it. Describe an attack in natural language, run a scenario built by our Red Team, or pull directly from GreyMatter Intel to turn a threat advisory into a live test. From there, GreyMatter Attack tests that attack against your environment, runs representative techniques to prove what is actually exploitable, and shows the full path from initial access to impact.

Mapping the path is only half the job. GreyMatter Attack turns each validated finding into actionable remediation, deploying detections and enabling automated response playbooks, so the gap closes rather than landing in a backlog. Then, you can retest and confirm that the gap is remediated. Your team stays in control of scope and strategy while GreyMatter Attack handles the reasoning and execution at scale.

The Bottom Line

Attackers have proven that AI reduces the amount of time it takes to go from initial access to business impact down to minutes. Point-in-time red teaming can't keep up with that, and it never sees the environment as it actually is on any given day. Instead of a human team testing within a fixed window, autonomous AI agents continuously reason within your environment. They map how an attacker could move through it, validate whether your defenses actually hold, and do it at machine speed and machine scale. The only way to fight AI is with AI, and that is as true for offensive testing as it is for defense.

ReliaQuest Recognized as a Strong Performer in The Forrester Wave™: External Threat Intelligence Service Providers, Q3 2026

Tue, 22 Sep 2026 11:00:00 GMT

In sports, a great defense must understand the offense. It is no different in security operations. It is not enough to just know threat intelligence—it needs to be acted on. Forrester recognizes ReliaQuest in The Forrester Wave™: External Threat Intelligence Service Providers, Q3 2026, where ReliaQuest was named a Strong Performer.

At ReliaQuest, we believe that threat intelligence delivers the most value when it provides holistic context that drives action across security operations. In 2025, the fastest data exfiltration time we observed was just six minutes, down from over four hours the previous year. To keep up, security leaders must go beyond just collecting intelligence and use it to power automated action across detection, containment, investigation, and response.

Over the past two decades, we’ve built GreyMatter with the future of security operations in mind. By unifying threat intelligence into a single, actionable view, teams can take faster defensive action before adversaries complete their objective.

Threat Intelligence Must Drive Action

When threat intelligence is used as an operational tool, it becomes an active input into how security operations run.

Proactive security operations are rooted in threat intelligence. Without it, detection rules fall behind, investigations miss context, and response actions stay generic. With it, security teams can move from reacting to alerts toward proactive, Agentic Defense, where intelligence continuously gives the team the insight and action to outpace adversary speed.

When attackers are moving faster than ever, intelligence becomes the signal that helps every part of the defense move faster and with more precision.

GreyMatter Turns Intelligence into Agentic Defense

For us, threat intelligence is one discipline that strengthens agentic defense. GreyMatter makes defense agentic by running threat intelligence across your connected tech stack in plain language. This allows analysts to move from intelligence discovery to investigation to response in one place.

It continuously collects threat intelligence from more than 50 feeds across deep, dark, and open web sources, combined with proprietary collection systems and human-led research. It correlates intelligence with assets, identities, vulnerabilities, and IOCs in a unified model, giving teams the context needed to take defensive action.

From there, GreyMatter turns intelligence into operational action. It runs detection logic, enrichment, and response natively across existing security tools, without forcing teams to pivot between systems or rewrite workflows. It also builds and tunes detections continuously, removing the need for manual rule-writing and helping coverage stay current as threats change.

When intelligence serves as the connective tissue across the platform, teams can shift away from a reactive SOC, and towards a proactive and predictive security operation.

What Forrester’s Evaluation Found About ReliaQuest

Forrester’s evaluation reflected the following findings regarding ReliaQuest’s External Threat Intelligence Services:

1. Threat intelligence as the nervous system of the agentic SOC

Forrester’s report noted "ReliaQuest’s vision positions threat intelligence as the nervous system of the agentic SOC, reflecting where security operations is headed, rather than threat intelligence.” This aligns with our belief that intelligence should not sit apart from security operations, but help drive detection, containment, investigation, and response.

2. Data normalization and correlation at scale

Forrester’s evaluation found that “ReliaQuest’s SecOps-centric platform excels at normalizing and correlating security data at scale through its Universal Translator and adoption of the Open Cybersecurity Schema Framework." We believe this gives teams a unified view across connected technologies without forcing them to centralize all data first.

3. Practical AI agents with appropriate validation controls

Forrester’s assessment noted that ReliaQuest “offers a range of practical AI agents built on robust architectures with appropriate testing and validation controls.” ReliaQuest also scored a 5 out of 5 in criteria including AI agent maturity, product security, and roadmap in the Forrester Wave™: External Threat Intelligence Service Providers. These capabilities are core to how GreyMatter delivers Agentic Defense across security operations: breaking work into focused tasks, so teams can act at the speed and accuracy of attackers.

4. A “forward-looking roadmap” aligned to its ambition

Forrester’s report also recognized ReliaQuest’s “forward-looking roadmap”, which “addresses multiple threat intelligence use cases and evolving customer needs.” To us, that direction reflects how we are building GreyMatter to not only support threat intelligence, but to operationalize it as part of Agentic Defense.

5. A strong fit for enterprise customers with limited security personnel

Forrester’s take is that ReliaQuest is “a strong fit for enterprise customers with limited security personnel, particularly those seeking a consolidated security operations platform as an alternative to traditional SIEM-centric deployments.”

In The Forrester Wave: External Threat Intelligence Service Providers, Q3 2026, ReliaQuest was named a Strong Performer. For us, this recognition reflects the role threat intelligence plays within GreyMatter: a platform where threat intelligence functions as the connective tissue between detection engineering, alert triage, and response orchestration. GreyMatter Agentic Teammates autonomously investigate and respond to 100% of alerts across 300+ technologies with 99.4% accuracy—more than 74 million times a year—while GreyMatter customers contain threats in under 5 minutes.

For us, our placement reflects our belief that the future of security operations depends on threat intelligence being operationalized across the entire lifecycle—from detection engineering to investigation and response.

Today, GreyMatter customers use this model: a platform where threat intelligence is imbedded into how the security operations runs, so every detection, investigation, and response action is backed by context, executed at speed, and scaled across the enterprise. That operational reality is what we'll continue to build on.

Forrester does not endorse any company, product, brand, or service included in its research publications and does not advise any person to select the products or services of any company or brand based on the ratings included in such publications. Information is based on the best available resources. Opinions reflect judgment at the time and are subject to change. This report is part of a broader collection of Forrester resources, including interactive models, frameworks, tools, data, and access to analyst guidance. For more information, read about Forrester’s objectivity here.

The GreyMatter Threat Hunting Teammate: Elevate Your Strongest Threat Hunters

Mon, 09 Feb 2026 05:00:00 GMT

ReliaQuest expands its GreyMatter Agentic Teammates with the release of its new AI persona, the Threat Hunting Teammate.

Your best threat hunters are exceptional at connecting the dots, understanding attacker behavior, and finding what shouldn't be there. Yet their potential is limited by time-consuming tasks: context-switching between tools, managing query languages, and writing reports—work that creates a barrier to effective threat hunting.

As threat actors increasingly leverage AI to accelerate the speed and complexity of attacks, you cannot afford inefficiency.

Make Your Strongest Threat Hunters Stronger With AI

Despite their talent, a manual threat hunting team struggles to validate security impact, drive improvement, and scale their security program. By leveraging agentic AI, your threat hunting team can scale your security program at the speed of your business.

What you need is your existing threat hunters to accomplish exponentially more, faster.

With the release of the GreyMatter Threat Hunting Teammate, ReliaQuest makes it possible for every analyst to hunt efficiently, faster, and with more precision.

Meet Your New Threat Hunting Teammate

The GreyMatter Threat Hunting Teammate is an Agentic AI persona that empowers security teams to launch and analyze cross-telemetry hunts using threat intel to identify gaps and correlate trends, saving you time and multiplying your impact.

Create and Execute Hunts in Minutes with Agentic AI

Start the conversation with your Threat Hunting Teammate.

Speak to the Threat Hunting Teammate just as you would to a real colleague. For example, you could direct your Teammate to “dig deeper on this user’s activity in the past 7 days," or ask, "What are the emerging threats in healthcare that I should be hunting for?"

Regardless of how you phrase it, the Threat Hunting Teammate understands your intent, identifies available telemetry sources in your environment, and recommends an appropriate hunt package or builds a custom one tailored to your infrastructure.

Your recommendations adapt to your specific environment.

The Teammate prioritizes hunts based on your industry, your environment, and the current threat landscape, then adjusts recommendations as it learns from the results of previous hunts.

Hunt results are automatically analyzed and summarized.

The platform identifies patterns and anomalies, assesses severity, contextualizes findings with the MITRE ATT&CK framework based on the hunt package used, and recommends next steps for investigation or remediation. Teams receive actionable findings instead of raw log volumes.

Specialized agents work together through a multi-agentic architecture.

The Threat Hunting Teammate orchestrates specialized skill agents with SQL execution, data analysis, and time series analysis capabilities to collaboratively execute complex hunts. The system connects with your Detection Engineering and Threat Intel Research Teammates to surface findings and inform broader security operations in real time.

Threat Hunting Teammate in Action: Hunting Scattered Spider

A security team receives intelligence about Scattered Spider activity targeting their industry. Instead of manually building queries across multiple tools over days, the human analyst tasks the Threat Hunting Teammate to:

Build a custom hunt package aligned to Scattered Spider tactics, techniques, and procedures, mapped to the available telemetry.
Execute a hunt that produces millions of logs and events with automatically analyzed results.
Identify the findings: ten exposures, with 3 SaaS applications showing unauthorized access patterns.
Report to the CISO with an executive summary: findings are contextualized within the MITRE ATT&CK framework based on the Scattered Spider hunt package, with recommended investigation and remediation steps.

What would have taken weeks of manual correlation was completed in hours. The team moved from hunting blind to hunting with precision.

Key Benefits

The Threat Hunting Teammate helps SOC teams to:

Hunt efficiently: Accelerate hunting with conversational workflows and built-in expertise.
Stay precise: Contextualize every hunt to your geography, industry, telemetry, and threat intelligence.
Respond faster: Automate hunt analysis and quickly move from findings to response.

One Hunt Cascades Across Your Team

The Threat Hunting Teammate works together with a collaborative team of AI personas—each specialized in intelligence, hunting, and detection.

The GreyMatter Agentic Teammates, a team of role-based AI personas built with 15 years of frontline security operations experience, collaborate with each other and your analysts to shift your team toward predictive security operations.

When the Threat Hunting Teammate discovers suspicious activity, Threat Intel enriches findings with personalized, actionable intelligence. The Detection Engineering Teammate builds and validates new rules to catch similar activity. This integration transforms a single hunt into organization-wide improvement, with each finding strengthening the entire security program.

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

The Security Metrics CISOs Use Every Day

Wed, 11 Oct 2023 19:46:42 GMT

In the dynamic world of cybersecurity, where threats are ever evolving, the role of a Chief Information Security Officer (CISO) is essential in protecting the business. Not only must CISOs establish programs to do this, but they must also effectively measure and communicate the value they bring to the organization. Using the objective “metrics that matter” supports this mandate. In this blog post, we will explore the practical security metrics CISOs use every day and how they use them to demonstrate their impact on the business.

Seeking the Story Behind the Numbers

As with any leadership role, CISOs must also justify their program spend by showing program progress and corresponding risk reduction over time. When they use the proper security metrics, they can more effectively tell that story.

CISOs have an abundance of security tools at their disposal, each providing a different capability within their security program. However, relying solely on individual tool outputs can be limiting. It’s like looking at a pixelated picture, where each tool represents just one pixel. To truly understand the bigger picture, CISOs need to stitch these pixels together to form a coherent narrative—a story.

In this blog, we’ll share the big picture of the security metrics CISOs use every day, starting at the top and zooming in. First, we’ll discuss the metrics that CISOs use at the strategic level, then the operational level, and finally at the tactical level.

Strategic Security Metrics

A CISO’s role extends far beyond the walls of a security operations center. Strategic conversations with the C-suite executive team, audit committees, risk committees, and board of directors are integral to aligning risk with business objectives.

Engaging in strategic conversations with diverse stakeholders requires adaptability and nuance, as each enterprise has its own unique set of priorities and driving factors that provide context to raw numbers. The most effective CISOs tailor their communication to a specific audience. For example, discussions with the C-suite may need to focus on the potential impact of security incidents on the organization’s reputation and financial stability. In contrast, meetings with risk committees may require a more analytical approach, emphasizing the identification and mitigation of emerging risks.

Depending on who’s in the room, a CISO might cite:

Risk acceptance vs. risk deference
Revenue, budget, and top- and bottom-line numbers
Something like a security "credit score," to showcase the program’s overall state and progress over time

An essential component of these conversations involves analyzing security incident trends. CISOs often present overarching trends to showcase the organization’s security posture. For example, an increase or decrease of true-positive incidents on a quarterly basis provides valuable insights into the effectiveness of security measures and helps drive decision-making at the organizational level.

Operational-Level Security Metrics

Outside the boardroom, a CISO manages the operational aspects of an organization’s security program, requiring them to consider different metrics. At the operational level, decisions revolve around strategic investments, program maturation, and aligning security initiatives with the organization’s roadmap

Some of the metrics that CISOs lean on for clarity at the operational level include:

Visibility and detection coverage: It’s important to consider these two metrics in tandem: Visibility does not equal detection. You may have an EDR agent employed across your environment, but if you never deploy detections within that EDR agent, you'll miss critical alerts.
Compensating controls and prevention capabilities: Operational-level metrics also assess the effectiveness of compensating controls, which act as backup measures when primary controls fail or are bypassed. Assessing the ability of compensating controls to effectively mitigate risks is critical. Additionally, measuring prevention capabilities helps determine the effectiveness of security measures in stopping potential threats before they cause harm.
Program maturity: Metrics like mean time to resolve (MTTR), threat hunting activity, and use of automation provide insights into security program maturity. MTTR at the operational level helps CISOs assess the health of their security operations: An increasing MTTR may indicate potential resource constraints or training needs for the security analyst team. Understanding successful or partially successful threat hunts helps evaluate program proactivity while automation through functionality like playbooks can help measure program efficiency and effectiveness.

On a CISO’s top-10 priorities list, there are always 11 items to cross off. These operational-level metrics can help CISOs identify the areas that offer the greatest return on investment in terms of risk reduction and overall program effectiveness.

Tactical-Level Security Metrics

Tactical-level security metrics provide visibility into the day-to-day happenings of their organization’s security operations. These metrics empower CISOs to optimize resource allocation at a team level and proactively address emerging risks.

The tactical metrics for CISOs include:

MTTR: While this also applies at the operational level, at the tactical level, MTTR helps CISOs assess the effectiveness of their security operations teams in responding to incidents. Understanding the MTTR trendline can help CISOs answer questions like “Are attacks increasing in sophistication?” and “Is there a process improvement or investment that will help decrease MTTR?” By monitoring and reducing MTTR, CISOs can ensure that their teams are equipped to handle security events promptly and minimize the potential impact on the organization.
Event count and true-positive count: Event count and true-positive count provide insights into the volume and quality of alerts being generated. Evaluating the true-positive count can help assess the efficiency of alert tuning and identify the need for further refining detection capabilities.
Criticalities: Analyzing the criticality of alerts is essential for identifying potential risks. If all alerts being worked on are of low criticality, there may be an opportunity to automate, or it could indicate the need for further tuning.

The most critical use of tactical-level metrics is to glean insights about what’s going on in your environment. For example, if an analyst on one shift sees a significant increase in alerts compared to the previous shift, it could indicate an ongoing attack or the need for tuning newly implemented security controls. By closely monitoring these shifts, CISOs can proactively identify potential problems and take swift action to mitigate risks.

Conclusion

By utilizing a comprehensive range of security metrics across strategic, operational, and tactical levels, CISOs can gain a holistic understanding of their security program. These metrics provide valuable insights, enabling them to make data-driven decisions, prioritize actions, and drive continuous improvement. Ultimately, the effective use of security metrics empowers CISOs to build robust security programs that align with business objectives, mitigate risks, and protect the organization from cyber threats.

Learn More

No matter where you are in your security operations journey, ReliaQuest can help guide you in the right direction. To learn about how GreyMatter and the Security Model Index can help you overcome security challenges and improve performance, reach out to request a demo.

Top 9 Cybersecurity Metrics to Track in 2024

Wed, 11 Oct 2023 18:49:28 GMT

In today’s digital landscape, organizations continuously face cybersecurity threats. With ever-evolving cyber risks, it is critical for security and business leaders to understand and effectively communicate the true state of their cybersecurity posture to drive decisions.

By tracking and monitoring the right cybersecurity metrics around detection, investigation, and response (DIR) workflows, organizations can accurately assess their security posture and optimize their security operations. Measuring key performance indicators (KPIs) and analyzing relevant data enables organizations to gain actionable insights into their security landscape and identify areas for improvement.

In this blog, we will delve into the critical security operations metrics that matter. These metrics offer a comprehensive view of an organization’s proficiency in the DIR workflow, enabling them to efficiently identify, analyze, and counter potential cyber threats.

Why Track Metrics

CISO Perspective

CISOs leverage metrics to effectively communicate the state of their cybersecurity program, enabling informed discussions among executive and board conversations around business and cyber risk. By providing comprehensive information, CISOs help organizational leadership understand the trendlines and gauge the maturation and performance of their security program relative to company peers. For example, is the Mean Time to Resolve (MTTR) security incidents trending downward? Is the organization performing better than peer companies?

Leader Perspective

Security leaders typically use metrics to establish and refine security strategy and maturity, particularly around the threat detection, investigation, and response process. The right metrics inform investment decisions or resource allocations to control risk. For instance, evaluating MITRE ATT&CK detection coverage can reveal opportunities where additional visibility or more detection capability might be required.

Analyst Perspective

Security practitioners and analysts need metrics to inform tactical decisions to better manage day-to-day security operations decisions as they investigate and respond to incidents. For example, tracking the use of response playbooks can uncover opportunities to automate response and remediation actions and processes. If analysts frequently encounter a particular phishing alert, they can implement an automated response play leveraging existing tools. This accelerates response and saves analysts from swiveling between consoles.

9 Cybersecurity Metrics to Track

Detection

1. Data Source Visibility: This metric enables organizations to understand the percentage of your environment that you can see compared to all the data sources you might expect to see. Improving data source visibility enables organizations to strengthen their ability to proactively detect and respond to potential security incidents.

To help you gain an understanding of your visibility level, consider the following questions:

Do you have holistic visibility into your environment?
Do you have the right level of visibility into threats?

2. Data Source Diversity: Data source diversity ensures comprehensive threat visibility by tracking the distinct data source functions that are available and enabled to improve monitoring fidelity. Leveraging these data sources provides a broader view of attack patterns, reduces false positives, and enables a proactive approach to your cybersecurity.

To determine the diversity of your data sources, reflect on the following questions:

Are you missing detection coverage?
How well are your existing tools functioning?

3. MITRE ATT&CK Coverage: By aligning with MITRE ATT&CK, organizations can comprehensively assess their detection capabilities and identify areas for improvement. MITRE ATT&CK covers several attack techniques, enabling organizations to prioritize defense measures based on real-world scenarios and known adversarial behaviors and strengthen their detection capabilities against a variety of cyber threats. This coverage allows you to compare deployed techniques against total possible techniques available based on the technologies that you own.

Consider the following questions when assessing if your organization aligns with MITRE:

Are we utilizing the MITRE ATT&CK framework to guide our detection capabilities?
Have we mapped our existing detection mechanisms to the MITRE ATT&CK techniques?

Investigation

4. False-Positive Rate: Measuring your false-positive rate can help you assess alert noise. Eliminating false-positives saves time during investigations and ensures resources are focused on real threats rather than false alarms triggered by benign events. This metric can enhance the effectiveness of security teams by reducing alert noise and improving incident response.

Answering the following questions can help you get a good sense of how your team is performing:

Is our current false-positive rate within an acceptable range?
Is there more we can do to reduce false positives?

5. Anomalous Safe Rate (ASR): ASR is a key investigation metric measuring the accuracy of alerts. Anomalous-safe alerts are alerts where the activity has been judged to be safe, but the same activity can sometimes be malicious.

A low ASR score reduces false alarms, allowing security teams to prioritize legitimate threats and allocate resources efficiently. Monitoring ASR helps organizations evaluate system reliability and make necessary improvements.

To help you gain an understanding of your ASR level, consider the following questions:

Is the current anomalous safe rate at an acceptable level?
Are we miscategorizing alerts that should be anomalous safe?

6. Threat Hunting Success Rate: Threat hunting metrics can uncover patterns and trends in malicious activities, allowing teams to move from reactive to proactive. They serve as a measure of proactive security, identifying weaknesses or holes in a security program.

Consider the following questions when assessing your threat hunting metrics:

How do we measure and track the effectiveness of our threat hunting activities during investigations?
What is the story underlying a successful threat hunt that can inform changes in our protective security layers or security policies?

Response

7. Mean Time to Resolve (MTTR): These metrics evaluate the time it takes an organization to resolve an incident. It is worth noting that some people measure “respond” rather than “resolve” and you should be clear on your definition. “Resolve” typically means “incident closed,” where “respond” may mean “my security provider responded by notifying me of an incident.” By tracking MTTR, you can reduce the amount of time an attacker can dwell in your environment. Comparing MTTR scores across time periods helps assess the effectiveness of response strategies and demonstrate incident response capabilities.

To gain insight on how your MTTR affects your response efforts, consider the following:

Where is your team spending its time during the threat detection, investigation, and response process?
Are there any process improvements we can make to drive down MTTR?

8. Close Rate: Close rate metrics measure the percentage of incidents successfully closed within a given timeframe, allowing organizations to evaluate the performance of their response teams and where they’re spending their time. By analyzing incidents with lower close rates, organizations can understand the underlying causes of delays or challenges, leading to the identification of process inefficiencies, resource gaps, and training needs.

To determine the effectiveness of your close rate during response, consider the following questions:

Is the current close rate at an acceptable level?
How can we improve our close rate?

9. Playbook Execution: Response playbooks can reduce threat dwell time and speed MTTR. To assess the effectiveness of executing predefined response playbooks during incident response, organizations need to consider playbook execution metrics. This metric helps uncover opportunities to automate response and remediation actions and processes. By tracking playbook execution, organizations can improve response processes, identify areas for further automation, and effectively communicate their incident response capabilities to stakeholders.

Answer the following questions to evaluate the effectiveness of your playbook execution:

What was the total execution time of the playbook?
Are there frequent alerts where we can deploy automated response playbooks?

How these Metrics Improve Your Overall Security Operations

Tracking the right cybersecurity key performance indicators (KPIs) offers benefits to various audiences, from the board to cybersecurity leadership to the analyst team. These metrics provide a clear overview of an organization’s security posture, measure the effectiveness of cybersecurity initiatives, and facilitate tactical process improvements, ultimately enabling strategic and tactical decision-making. Leveraging the right cybersecurity KPIs promotes continuous improvement by tracking progress, identifying areas for enhancement, and managing risk.

Benefits of a Cybersecurity Dashboard

Cybersecurity dashboards offer an intuitive and consolidated view of the organization’s security posture, providing clarity and communicating the effectiveness of their security operations. They empower you to communicate risk by highlighting emerging threats, enabling the team to stay ahead of potential security incidents. Dashboards present risk data concisely, making it accessible and relevant to board members, bridging the gap between technical details and strategic decision-making.

Gain Clarity with the GreyMatter Security Model Index

As a dashboard, the GreyMatter Security Model Index helps improve reporting and gives security leaders real-time views into critical areas of security operations. Model Index metrics are benchmarked against previous quarters and industry peers, giving measurable insights into how your program is performing comparatively and maturing over time. It ensures effective communication of the value your security operations bring to the organization and helps you to improve your security maturity over time.

Three Critical Tenets for Effective Managed Detection and Response

Mon, 06 Jan 2025 21:55:41 GMT

In a world where cyber threats are growing in scale and sophistication, Managed Detection and Response (MDR) services have become a cornerstone of enterprise security. MDR provides organizations with the expertise, tools, and processes needed to detect, investigate, and respond to threats effectively.

However, not all MDR services are created equal. Among the challenges organizations face and the evolving role of traditional MDR providers, there are the critical tenets that make MDR services effective: transparency, consistency, and speed.

Before we talk about the three critical tenets, let’s dive into the real-world challenges and solutions for organizations seeking to enhance their security posture with MDR.

Challenges Driving the Need for MDR

Every organization has unique security challenges, but some common pain points drive many to seek MDR services. From skill shortages to burnout, internal teams often lack the resources or expertise to keep pace with today’s dynamic threat landscape.

Internal Gaps in Expertise

Organizations often face challenges like lacking the experience to identify threats beyond their internal environment. While internal teams may excel at monitoring their own systems, they often miss emerging or global threats, leaving blind spots in detection.

Response Delays

When security operations analysts rely on manual processes, response times lag. Decisions are delayed, escalating potential threats into bigger issues. One of the most significant contributors to these delays is the inefficiency of having to pivot between multiple tools and consoles during investigations. In many organizations, the security stack is composed of a variety of standalone tools. While each provides critical information, they often lack seamless integration, forcing analysts to jump between dashboards to piece together the full picture of an incident.

Coverage Gaps and Burnout

Smaller teams (e.g., 7-10 people handling security monitoring, managing infrastructure, configuring tools, and handling other IT responsibilities) struggle with 24/7 coverage. This juggling act becomes even more overwhelming when faced with the hundreds or even thousands of daily alerts generated by today’s security tools.

While all alerts are potential threats, they often include a significant number of false positives or low-priority notifications, all of which still need to be reviewed. For small teams, this quantity of alerts creates an almost insurmountable workload, leading to alert fatigue. After-hours monitoring also suffers, which can lead to undetected attacks.

Challenges in Hiring

The competitive job market for skilled cybersecurity professionals exacerbates these issues. Searches for qualified personnel can take months, leaving critical gaps in security operations. The demand for qualified security experts has surged across industries, while the supply hasn’t kept pace, all while threats have become more sophisticated and frequent.

Transitioning to New MDR Solutions

For organizations facing the challenges above, transitioning to a modern MDR solution is often a necessary step. There is now a greater need for the benefits of automation and integration in enhancing their security operations.

Switching MDR Providers

Organizations frequently outgrow their initial MDR providers, especially those that rely heavily on manual processes. Traditional Managed Security Service Providers (MSSPs) often lack the advanced capabilities of modern MDR solutions, prompting organizations to seek providers that offer automation and deeper integration.

Automation

Modern MDR providers use automation to reduce the manual burden on internal teams. This allows organizations to focus on strategic security tasks while the MDR provider handles routine monitoring and alert triage.

Impact of Workforce Changes

The skills gap and employee retention has left many organizations short-staffed. MDR services enable these understaffed teams to continue operating efficiently by providing external expertise and round-the-clock monitoring. This ensures that security operations can continue uninterrupted, even with limited internal resources.

Three Critical Tenets of MDR

MDR services are only as effective as the principles that underpin them. Transparency, consistency, and speed are the three critical tenets that define a successful MDR provider. By adhering to these principles, providers can build trust, deliver reliable results, and respond to threats with the urgency they require.

1. Transparency

Transparency is essential for building trust between organizations and their MDR providers. Gone are the days of “black-box” approaches, where organizations had little visibility into how their providers operated.

A transparent MDR provider allows organizations to participate in investigations and gain insight into how threats are detected and mitigated. This collaboration enables better alignment between the provider and the organization’s unique needs.

2. Consistency

Standardized workflows and repeatable processes are critical to effective incident response. Without consistency, organizations risk inefficiencies and errors that can lead to missed threats.

Consistent communication ensures that organizations know what to expect, especially during critical incidents. From clear instructions to automated response plans, consistency simplifies operations.

3. Speed

Speed is a defining benefit of MDR. Reducing an organization’s mean time to respond (MTTR) can prevent small incidents from becoming major breaches. Automation and optimized workflows play a significant role in delivering faster response times.

Key Capabilities and Features of MDR Providers

When selecting an MDR provider, it’s crucial to evaluate their capabilities and how well they align with your organization’s needs. Here are the key features that define an effective MDR provider.

Scalability

As organizations grow, so do their data sources and attack surfaces. MDR providers must be able to scale their services to handle this growth without overwhelming internal teams. Organizations have often spent significant resources implementing and fine-tuning their security tools. These investments include licensing costs, deployment efforts, and training internal teams to use the tools effectively. Rather than asking organizations to replace these tools with proprietary or third-party systems, MDR providers should focus on maximizing the value of the tools already in place with security integrations.

Dedicated Teams

Providers should assign teams familiar with the organization’s specific needs, such as regulatory requirements (e.g., for banks, compliance with financial regulations).

Avoiding a “round-robin” support model ensures continuity and avoids the need to repeatedly explain the same context to new support staff. Dedicated teams act as an extension of the internal security team, ensuring continuity and deeper collaboration.

Automation

Automation eliminates repetitive tasks, such as triaging, alert enrichment, and response actions allowing internal teams to focus on high-priority threats.

Automation directly impacts two critical metrics for security operations: Mean Time to Detect (MTTD) and Mean Time to Respond (MTTR). By automating key steps in the detection and response lifecycle, MDR providers can dramatically reduce the time it takes to identify and mitigate threats.

Conclusion

By embracing these three tenets, organizations and MDR providers can foster a partnership built on trust, collaboration, and shared goals. An effective MDR provider becomes more than just a vendor; they become an extension of the internal security team, working side-by-side to protect the organization’s assets. This partnership enables security teams to focus on strategic initiatives, knowing that their MDR provider is well-equipped when it comes to monitoring, detecting, and responding to threats.

Top Cyber-Threat Techniques in Q4 2023: What We’re Seeing

Thu, 25 Jan 2024 13:00:02 GMT

The final quarter of 2023 brought many of us festivities, time off work, and warm memories. Simultaneously, cyber-threat actors were busy finding new and innovative ways to wage attacks. As it turns out, innocent employees were actually (unknowingly) helping those threat actors: In Q4 2023 user behavior proved a key factor in opening the door to attackers.

Below we explore that trend, and others that affected ReliaQuest customers in Q4, including the MITRE ATT&CK techniques used for initial access, command-and-control (C2), defense evasion, and impact. Spoiler alert: They’re all likely to be seen again in the coming months. And we’ve got tips to stay one step ahead.

Initial Access: PEBKAC Alert

Your network security is only as strong as your weakest link, and organizations are full of these weak links…we’re all familiar with the “problem existing between keyboard and chair” (aka PEBKAC). Our data showing threat activity against our customers in Q4 2023 revealed that the vast majority of initial-access activity was aided by user actions during social engineering. These attacks exploit features typical of human beings: curiosity, naivety, and occasional carelessness.

Most attacks began with an unsuspecting employee clicking on a phishing link. This trend is consistent with the findings from our Q3 2024. Luckily for attackers, phishing and similar techniques are the easiest and cheapest of all ways to gain initial access to a target system, thanks to resources like phishing-as-a-service (PhaaS) toolkits.

We saw spearphishing in abundant use, but also drive-by compromise. Often referred to as drive-by download, this is when a person visits a seemingly-benign-but-compromised website, and malware is immediately downloaded to their computer.

Figure 1: Initial-access TTPs observed in Q4 2023 ReliaQuest customer incidents

To counter these techniques, ReliaQuest protects customers by using numerous detection rules and a specialized Phishing Analyzer. You can also protect yourself from the above initial-access techniques by:

Educating employees on cybersecurity best practices, including reporting any potential phishing emails immediately
Ensuring secure email gateways (SEG) are effectively filtering out spam, malicious content, and potential phishing attacks
Detecting drive-by activity, by continuously monitoring network traffic for suspicious patterns and using intrusion detection systems plus antivirus software

Defense Evasion: Lurking in the Shadows

With one foot in the door of a targeted system, a threat actor typically does everything in their power to make the most of it. But they need to work undetected, bypassing, or eluding security measures.

In Q4 2023, command obfuscation was the defense-evasion technique most used in our customers’ environments. The attackers increased the complexity of their command code to make it less intelligible to security tools (which are trained to identify certain patterns). Just like a student might add white text to a Word document to trick the word-count feature, hackers add whitespace and special characters to confuse your expensive anti-malware tools.

Figure 2: Defense evasion TTPs observed in Q4 2023 ReliaQuest customer incidents

We’ve created a set of detection rules in our GreyMatter platform to keep our customers safe from even the most obfuscated commands. You can also take the following steps:

Deploy and regularly update antivirus and anti-malware software to detect and block known obfuscation techniques.
Use Endpoint Detection and Response (EDR) and detection solutions that can employ behavioral analysis.
Regularly monitor and analyze command-line activity, to help identify and investigate suspicious or obfuscated commands.

Command-and-Control: A Special C2 Connection

After evading detection tools, the attacker wants to set up a C2 system to communicate with compromised systems. In most of the activity observed within ReliaQuest customer environments, C2 was established through HTTPS (Hypertext Transfer Protocol Secure), the primary protocol used to send data between a web browser and a website. To an attacker’s advantage, it does so in an encrypted manner and typically slips past firewalls. Suspicious traffic blends with everyday traffic, and security teams are none the wiser.

Figure 3: C2 TTPs observed in Q4 2023 ReliaQuest customer incidents

GreyMatter can help with detection rules aimed at high-risk HTTPS and suspicious traffic, but here’s what you can do:

Implement Deep Packet Inspection (DPI) technologies that analyze the content of encrypted network traffic, including HTTPS.
Regularly monitor SSL/TLS (Secure Sockets Layer/transport layer security) certificates used by your organization, checking: certificate issuance, expiration dates, and any abnormal or unauthorized certificate activity.
Deploy behavior-based analysis tools that can detect suspicious activities and communication patterns within your network.

Impact: The Great Cost of Cyber Attacks

Q4 marked a final blow in an already costly year for the cyber-compromised; financial theft was, overwhelmingly, the most common way attackers created an impact on our customers. Whether they used ransomware, business email compromise, data theft, or cryptocurrency network exploitation, one goal was always in mind: get rich quick(ly).

Figure 4: Impact TTPs observed in Q4 2023 ReliaQuest customer incidents

Our data shows an overall increase in extortion activity, particularly in ransomware and data theft extortion—2023 was a record-breaking year in that regard.

What’s to Come

Unlike January gym rats, threat actors are unlikely to abandon their plans in 2024. Many of the techniques seen in Q4 2023 will probably continue to be widely used this year. (Get the full picture of 2023 threats in our year-end blog.)

By staying one step ahead of attackers, ReliaQuest will continue pursue the most up-to-date and forward-looking means of protection, keeping our customers informed and responsive along the way. If you’d like a slice of this cybersecurity pie, find out more about our GreyMatter platform and request a demo today.

The Detection Model Is Upside-Down

Fri, 03 Apr 2026 09:00:00 GMT

Brian Murphy on the Great Re-Architecture of Cybersecurity | EXPONENT 2026

At EXPONENT 2026, hundreds of security leaders gathered in Tampa around a single problem: the SOC model most enterprises rely on wasn't built for a world where attackers move at machine speed. The fastest intrusion-to-exfiltration we observed last year took 6 minutes. The average SIEM detection time across our customer base is 51 minutes.

The gap between attacker speed and detection speed keeps widening, and this outdated approach to detection isn’t helping. While your SIEM indexes, attackers are mapping your infrastructure with your own tools—watching you onboard employees, launch products, and expose new attack surfaces in real time.

As ReliaQuest founder and CEO Brian Murphy put it: "We are in the middle of the great rethink—the great re-architecture of cybersecurity. The adversary has gotten faster. Our environments have gotten more complicated. And speed and simplicity are the order of the day."

Brian Murphy, ReliaQuest Founder and CEO

Much of EXPONENT focused on what the agentic AI-powered SOC looks like in practice—how GreyMatter's agentic Teammates orchestrate detection, investigation, and response autonomously across enterprise environments, and what separates real agentic architecture from the marketing version. But agentic AI is only as fast as the architecture it runs on. And for most organizations, that architecture is still the bottleneck.

Flip the Detection Model or Fall Behind

The SIEM was designed for log aggregation and compliance—a system of record, not a system of action. But when the industry needed a place to run detection logic, the SIEM was the only thing with all the data. So detection got bolted on.

That decision calcified into an entire operating model. Detection rules run at storage. Analysts query storage. Response workflows start from storage. The SIEM became load-bearing not because it was the right architecture, but because it was the only one available.

The cost of that decision is now measurable. Across our install base of 1,300+ enterprise environments, 76% of detection use cases don't require a SIEM at all. Three-quarters of what security teams are paying to ingest, index, and search could be detected earlier, cheaper, and faster somewhere else.

Detection Should Follow the Threat, Not Wait for the Data

Threats originate at endpoints, in identity systems, across cloud workloads, at the network edge, but not at the SIEM. By the time that telemetry reaches storage, the attacker has already moved.

The answer isn’t a faster SIEM. It still puts detection at the end of the pipeline. Detection logic needs to run where threats actually appear—at the source and while data is in motion.

At-source detection means pushing detection rules directly to the tools generating telemetry: your EDR, your identity provider, your cloud platform. No centralization delay. No indexing overhead. The rule fires where the event happens.
In-transit detection means evaluating data as it moves through your pipeline, before it reaches any storage destination. This is what we built GreyMatter Transit to do. At EXPONENT, we showed Transit firing detections in under five seconds, closing the 51-minute gap before the data even reaches storage.

Under this model, the SIEM doesn’t disappear, it gets right-sized to one layer among three, handling compliance-driven queries while speed-critical detections fire earlier. But operating detection across three layers—each with different speeds, data formats, and response requirements—isn't a workflow humans can manage manually at scale. SOCs need an agentic AI architecture to orchestrate detection, investigation, and response across all three layers so security teams can run faster without multiplying headcount.

The Detection Architecture Your AI SOC Needs

Every major security vendor is shipping AI. But most of those AI capabilities sit on top of the same SIEM-centric architecture — which means the AI is still waiting for data to be ingested, indexed, and made searchable before it can act. If your detection fires at 51 minutes, your AI-powered investigation starts at 51 minutes. You've automated the wrong side of the problem.

The detection re-architecture changes what AI can actually do. When detection fires at source or in transit, agentic AI can begin investigation and response in seconds—not because the model is faster, but because the data arrived faster.

This isn't a rip-and-replace argument. Most enterprises can't—and shouldn't—abandon their SIEM overnight.

Start with a different question: which detection use cases require storage-based search, and which ones are paying a speed and cost penalty for no reason?

Murphy's prediction at EXPONENT was direct: "The most advanced companies, the most advanced cybersecurity teams, will not use a SIEM in the next 24 months in the way we think about it today. There's hot storage, cold storage—but they're both cheap, dumb storage. We do not have time to wait for a SIEM to re-index for hours. We just don't."

The Re-Architecture Is Already Underway

The organizations moving fastest have already started the shift to three-layer detection architecture and are now running agentic AI across all three layers to investigate and respond, giving their teams an edge in the race against attackers.

Murphy closed with a line that applies to every security team: "We can't cling to the past while working on the future at the same time."

The question for every security leader is the same: does your detection model follow the threat, or does it wait for the data?