Welcome to Issue #171 of Detection Engineering Weekly!

✍️ Musings from the life of Zack:

• I’m in NY this week at the Datadog office! I’m crossing a restaurant off my bucket list and will be eating with some of my college friends at Per Se. I’ve seen this restaurant on like 50 cooking shows at this point so I’m excited to experience it for myself :)

• The Datadog Detection Engineering and Security Research team is hosting an IN PERSON Detection Engineering conference in Chicago on November 2! It’s a continuation of our Datadog Detect series, and the speaker and topic list is awesome. Registration is still open, and we want to make sure it’s packed to support the speakers and to spread some Detection knowledge :)

  Register for Datadog Detect

💎 Detection Engineering Gem 💎

Cloud Threat Emulation on Autopilot: Context is Everything by Terrance DeJesus and Bryan Porras Blanch

In this blog, Elastic Security Researchers DeJesus and Blanch showcase their agentic threat emulation methodology. My mental model for threat emulation testing follows a similar path to software engineering testing:

• Unit tests

  • Software Engineering: Test one small component in isolation, usually a function or component

  • Detection Engineering: Isolated atomic tests generally on one log or contained “attack”

• Integration tests:

  • Software Engineering: Test two or more components together. Think an API call → database query

  • Detection Engineering: Testing two or more rules, where the logs or compound alerts are necessary to generate a higher-level alert

• Regression tests:

  • Software Engineering: Re-run tests after a piece of code changes, ensuring existing contracts in other tests still hold true

  • Detection Engineering: Nearly identical, but swap code changes to rule changes!

• End-to-end tests:

  • Software Engineering: Test a full workflow, either from a user or something automated, validating that the system behaves from “the outside”

  • Detection Engineering: Test a full attack chain, with prerequisite environment configuration and context, to ensure the full attack scenario propagates the correct telemetry and alerting

I think the hardest part of any end-to-end detection testing is modeling the environment. This becomes more of a DevOps problem than a security problem. You risk biasing your testing by reducing the problem down to the minimal environment needed to replicate the attack. A minimal environment isn’t your enterprise environment. To combat that bias, Blanch and DeJesus approached emulation by first building the attack's threat model, then working backward.

They also had clever ways to give the emulation run a report card.

Similar to what we’ve seen with the previous issue’s Gem on rating your AI SOC output with validation gates, this looks like a validation gate for emulation.

🔬 State of the Art

How to start the AI-accelerated defense by Wade Wells

My biggest takeaway for “doing AI in security” in the second half of this year is that context and memory are the most important layers for making a program successful. It kind of makes sense: if you bring in a fresh SOC analyst or incident responder and don’t give them any information during onboarding regarding your tools, logging requirements, rules, and internal knowledge databases, do you think they would be set up for success? Since Agents run on context, why not give them context versus relying on vanilla or 1-shot prompts to investigate an alert?

This retrospective from friend-of-the-newsletter and detection veteran, Wade Wells, shines some light on how the 1Password team tackled their AI adoption journey. They started treating their security agents like employees and built systems and memory layers to give them access to context during investigations. Wells wrote this like a blueprint for others on this journey, which I appreciated because some of it seems obvious now that I am reading it, but I wouldn’t have thought of it on my own:

• Detection rule library: this is the most obvious to me, but spending time on having up-to-date rules with corresponding runbooks helps a lot here

• Team charters: this is a new one that I’m going to steal. Basically, it helps reconcile the infrastructure with the humans who own it. So when you need to escalate or page someone, the agent does that work ahead of time and gives you the right contact info

• Log inventory: I had to zoom in on the picture displayed here, but it’s a spreadsheet of all critical log sources, their categories such as endpoint or Cloud, and corresponding priority of importance

My big takeaway here is that if some knowledge base is useful for you as a security engineer, it’ll likely be useful for a security agent.

Detection fidelity in the age of AI agents living off the land by Julien Vehent

This short-but-sweet blog addresses an issue I’ve seen a lot of people talk about in the cloud workload space, but it still makes sense in the endpoint space: when is an agent’s intent malicious and when is it benign? When you have a frontier model running an investigation on a failed networking call in a piece of code, it might load living-off-the-land binaries like tcpdump or netcat to troubleshoot. In the past, we would look at a normie’s computer (aka not in engineering) and assume malicious activity, since normies don’t like networking tools.

Vehent argues that these “tripwires” lose their fidelity once agents use the same tooling for legitimate work, and that the fix is correlating weak signals and giving agents their own identity, so you can tell their tcpdump apart from an attacker’s.

I’d take it a step further here, though. I don’t think Vehent is suggesting that correlated rules are the answer, as if they haven’t always been. It’s more so that correlation matters even more, because you now have to differentiate three identities. The human, their agent(s), and the attacker. So, IMHO, assume regular users’ machines will run things like tcpdump, because more capable models with thinking modes hide a lot of this busywork from the person who asked. Ask an agent to debug your WiFi, and it may end up building its own tcpdump in Rust :).

AI Agent Artifact Catalog by Raymond DePalma

This is a neat site (and corresponding GitHub repository) that helps centralize knowledge around artifacts left by AI agents during detection and forensics work. The current iteration includes dozens of AI tools, from Claude Code to Cursor, along with their corresponding artifacts (executables, Markdown files) and their forensic value.

For example:

AIRT-0011 documents Claude Desktop’s MCP log, where you can find the full tool-call transcript Claude used against various MCP servers. It’ll list things like abuse potential (adding rogue MCPs or malicious ones) and documented incidents in the wild.

Huntbase Hub by Huntbase

This “Hub” is a freemium product you can sign up for to get hunt ideas sent directly to your inbox, or you can point your agents to it as well. The cool part about some of these entries is that they give step-by-step instructions for the hunt based on the context of the threat research story. This example hunt is based on Huntress research into ConnectWise M365 attacks and has a few clever things I wanted to point out. First, it starts out with a description of “Why this matters”. Many hunts get lost at the start because the threat research or attack seems cool rather than relevant.

In this case, attackers used a supply chain attack against ConnectWise and customer-configured OAuth credentials stored in ConnectWise to pivot into victim M365 environments. It lists the steps it needs to take to perform the hunt and its decision steps in a SOAR-like decision-tree view. Products like this are nice because they build in the open, and you can compare and contrast how to build an agentic threat hunt and see whether you can incorporate some of Huntbase's best parts into your workflows.

☣️ Threat Landscape

Security advisory: Critical remote code execution vulnerabilities, update now by PHP

The big news from this week is not one but two PHP vulnerabilities. According to the PHP team, all PHP installations serving web requests are vulnerable to CVE-2026-109618 and CVE-2026-109619, which is millions of devices on the Internet. W3techs alone puts 58.3% of websites who host a content management system host WordPress. Both vulnerabilities are rated Critical (CVSS v4.0: 9.2) and can lead to unauthenticated remote code execution. Here’s the quote I’m most worried about:

PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version.

Today's PHP Security Release, and How We're Strengthening PHP Security by The PHP Foundation

This blog by the PHP foundation is where things get very spicy. Basically, the blog outlines the Foundation’s recent security developments with the use of third party security reviews since 2024 and the use of Mythos and other cyber foundational models. The team did not say how the vulnerability was disclosed, but they write that one of the security firms who found the vulnerability, Calif, leaked details of the vulnerability via a video. Calif deleted the video from social media, but I have a copy and uploaded it for you all to view here:

The video itself showed some PoC details, and this is where the beauty of LLMs came in. Several research teams, including us at Datadog, took the video, OSINT from social media and the sparse details released by PHP and recreated the PoC.

The PHP Foundation team says things were going well until two days before the disclosure. The CVEs were leaked, and then the video was posted on Calif’s Twitter account and was subsequently removed. Separately, they put Chainguard on blast and blamed them for pre-releasing patches that were under embargo before the embargo was lifted:

On October 21st at 07:41 UTC, more than six hours before the coordinated release, Chainguard unilaterally broke the embargo and published built images containing the fix. Like other distributors, Chainguard had received the patch in advance so its users could update the moment the vulnerabilities were disclosed. Any attacker could now study the fix in binary form while every other PHP user was still waiting for the release. This disregarded weeks of work by many parties toward a coordinated disclosure.

So according to The PHP Foundation, this effort was botched within a two day window. If you compare this to how life was in security before LLMs, a video wouldn’t be able to show enough where we could build our own PoC. But our teams did it in < 1 hr with GLM 5.3 using an anime girl meme video.

What a world we live in.

A tale of two PHP remote vulnerabilities by Ryan Austin

This blog post by Calif is from the company that the PHP Foundation Team referenced in their above blog. I found it strange that half of the blog is a.. comic book? The illustrations are pretty but the interesting vulnerability finding work is on the second half of the blog.

According to the blog, the vulnerabilities were found by Calif, Wiz and OpenAI and all default configurations of PHP that go back to version 5.4.0 are vulnerable. The blog goes much deeper than the above PHP posts, but the bugs basically result from what happens when PHP runs out of memory partway through a request.

In the first, PHP records a new entry in an internal table before it finishes creating it. The attacker then triggers the out-of-memory error right then, and the cleanup code later trusts the half-built entry and frees memory the attacker controls. In the second, the same kind of crash during file-upload handling frees the request’s memory but leaves session data pointing at it, and the attacker’s next request uses those stale pointers.

Oct 21 Advisory: PHP Unauthenticated Remote Code Execution [CVE-2026-109618, CVE-2026-109619] by Censys Threat Research

Following the vulnerability disclosures, the Censys Threat Research team fingerprinted PHP servers across the Internet and got a good snapshot of exposure for readers and researchers. The snapshot from yesterday showed 6.2 million hosts with vulnerable versions.

There isn’t a specific mix shown here across the technologies referenced by Calif, so there’s likely a good mix between Drupal, Wordpress, phpMyAdmin and others. The thing I am most worried about across this list is not run-of-the-mill Wordpress CMS websites, but moreso appliances like Citrix or Palo Alto devices that are EOL or have terrible updating capabilities.

PHP2Shell - Critical vulnerabilities in PHP (CVE-2026-109618, CVE-2026-109619): detection, analysis, and remediation by Nick Frichette, Eslam Salem and Emile Spir

~ Note, Datadog is my current employer and Nick, Eslam and Emile are my esteemed colleagues ~

I’m on site at the Datadog NY office this week so these PHP vulnerabilities have been keeping both our internal security and security research teams busy. If you want a much deeper dive about the vulnerability and the exploitation primitives, the team here goes into deep detail on how each vulnerability is triggered:

Nick built a PoC from the available OSINT prior to the previous blog disclosures, so it goes to show how fast these things can develop with LLM capabilities.

🔗 Open Source

jarocki/selfedge

Selfedge is a self-hosted website builder that operates like a dynamic honeypot. It detects when it is getting probes and live edits itself to add honeytokens or tripwires to adjust to the attacks it’s receiving. I think it’s an interesting concept in the sense that it’s a malleable honeypot, but I haven’t played around with it enough where I can say it won’t give you the same type of results as you see as other LLM-based honeypots.

depalmar/ai-dfir-toolkit
This is an interesting corpus of detection rules, forensic artifacts and threat intel that focuses heavily on attacks against AI systems. It contains nine attack categories, from prompt injection and MCP tool poisoning to agent memory poisoning, and each category has a mix of Sigma, YARA and Suricata rules mapped to ATLAS and OWASP.

The artifact catalog is probably the most useful. Similar to Raymond DePalma’s blog above on AI Agent Artifact catalog, it is a structured feed of tools, credential and configuration locations and case studies for coding agent attacks.

syhunt/php2shell-protection

php2shell-protection is a small configuration tweak you can add to vulnerable PHP deployments to protect against php2shell. It’s an .htaccess file that caps POST requests to 8 megabytes, which helps protect against CVE-2026-109618.

Fazmin/cve-intel

CVE intel is a web app you can run locally that connects to nearly 40 sources of intel to enrich whatever CVE you enter. It connects to the usual sources for CVE intelligence like CISA KEV, NVD and CVSS services but has some other neat intel sources like GreyNoise so you can get a full picture. You can also drag-and-drop a coding directory and it’ll load the SBOM and perform vulnerability scanning.

This post is part of the Detection Engineering Field Manual

A data source is a system or service that generates telemetry. Telemetry is the evidence a system produces about what it is doing. These observations are typically captured as events, which are structured messages that describe something that happened.

For example, someone who enters a store can generate an event. Perhaps a door bell rings when the door opens so the store owner knows a new customer has arrived. In the security world, an event can represent everything from a user signing in to email, to downloading and executing a file, to trying to access an internal company website.

In security, most events you’ll process, read, or write rules against are stored as logs. A log is a timestamped record of an event generated by a system, process, application, or service. Engineering and operations teams use logs for debugging, auditing, and tracking system health. Security teams use the same records as evidence to find and investigate threat activity.

Not all logs are useful, and often, events you think would be useful never generate logs. A massive part of detection engineering is understanding a log’s source, shape, and meaning well enough to decide whether it can support a hunt, an investigation, or a detection rule. There is no rule without telemetry, and there are thousands of log sources and standards, so visibility and normalization of logs matter.

Logs are events

Previous issues discussed rules as search queries. These queries are run against one or more logs. Here’s an example log:

time=2026-01-01T13:21:44Z
user=alex@example.com
action=SignIn
application=Microsoft 365
source_ip=203.0.113.10
result=Success

This is the shape of a security log in its simplest form: an action (SignIn), an actor (alex@example.com), context (application, source_ip), a timestamp (time), and an outcome (result=Success).

This event shows a user named Alex successfully signing in to Microsoft 365 on January 1st from IP address 203.0.113.10. Most rule languages run a selection on keys within the log, such as user or action, and compare the values to a pattern that may indicate maliciousness. More importantly, all logs should include the time (timestamp) when an event occurred, and this field is required for most SIEMs.

Data-source providers give their logs a shape or log format. These are mostly represented as key-value pairs, and each format is different. JSON is the most common format in SIEM technologies, but you will also encounter others like CSV, syslog, CEF and Windows Event Log.

Below is my attempt to convert the example pseudo-log above into some common formats.

CSV

CSV is a data structure where each field is separated by a comma. For the most part, the first line of every CSV file contains the field names and structure. Every line after that represents an event, or in our case, a log entry. It is compact and familiar, especially if you work in spreadsheets, but because the columns are positional, fields containing commas or nested data can be annoying to handle.

time,user,action,application,source_ip,result
2026-01-01T13:21:44Z,alex@example.com,SignIn,Microsoft 365,203.0.113.10,Success

Syslog

Syslog is both a logging protocol and a message format. Modern Syslog can include structured data in a separate log format, but you should expect syslog data to look like free-form messages.

<134>1 2026-01-01T13:21:44Z m365-idp signin - - [event user="alex@example.com" action="SignIn" application="Microsoft 365" source_ip="203.0.113.10" result="Success"] User sign-in succeeded

Windows Event Log

Windows Event Log is different from the text formats above because Windows stores events in the binary  .evtx  format. When tools render this format, they render the logs as XML. The event header carries common metadata such as provider, event ID, channel, computer, and time, and the event-specific details appear separately.

<Event>
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing"/>
    <EventID>12345</EventID>
    <TimeCreated SystemTime="2026-01-01T13:21:44Z"/>
    <Computer>WORKSTATION-01</Computer>
  </System>
  <EventData>
    <Data Name="TargetUserName">alex@example.com</Data>
    <Data Name="Action">SignIn</Data>
    <Data Name="Application">Microsoft 365</Data>
    <Data Name="IpAddress">203.0.113.10</Data>
    <Data Name="Result">Success</Data>
  </EventData>
</Event>

JSON

JSON is a structured, text-based format made of name-value pairs. It is common in Cloud, SaaS, API, and modern application logs. This is the most typical log format you will see in a SIEM. It’s the most flexible due to its ability to nest JSON objects inside JSON, which makes extraction and free-form fields more useful, depending on who you ask.

{
  "time": "2026-01-01T13:21:44Z",
  "user": {
    "email": "alex@example.com"
  },
  "action": "SignIn",
  "application": {
    "name": "Microsoft 365"
  },
  "source": {
    "ip": "203.0.113.10"
  },
  "result": "Success"
}

Every detection engineer, incident responder, and security engineer I know is familiar with log formats like the ones listed above. You will need to be comfortable with understanding which sources generate what log formats, and you’ll need to understand how to build tools, services, and infrastructure to accurately extract, transform, and load these values into a SIEM.

All security engineers are data engineers

Security engineers should obsess over how downstream people or services interpret the data they produce and receive. In the field of security operations, especially in the SIEM and detection engineering space, detection rules depend on fields. If fields are not named or structured consistently, every hunt, join, and rule inherits source-specific complexity. That creates blind spots, inconsistent coverage, and a lot of duplicated detection work.

Imagine you are trying to write a rule from logs in the previous examples. It may not necessarily be an M365 sign-in event, but it could be logs across host, SaaS, application, and cloud events. When you try to extract the field of the user account:

• CSV: The field is called user, and it’s in the second column

• syslog: The field is called user, and you need to write an extraction method to correctly parse the log the syslog email from the [event] field

• Windows Event Log: The field is called TargetUserName under EventData under Event

• JSON: The field is user.email

So how do you reconcile all of these fields?

This is a classic data-engineering problem, and it’s solved via ETL pipelines. ETL stands for extract, transform, and load.

We extract events from a source, transform them into a form our security platform can consistently parse and search, then load these normalized events into the SIEM. In practice, that can mean parsing a raw Syslog message, extracting the user field from [event] and mapping that to a standard user field, converting timestamps into a common timezone, or even more mundane things, like converting userName to username.

Without this up-front engineering work, you open yourself up to several issues. First, you may need to write several versions of the same detection rule because each source may represent users, IP addresses, timestamps, or other fields differently. This rule sprawl creates turmoil for your SOC analysts and detection teams, as maintenance and tuning burdens increase significantly.

Secondly, if you want to create composite detections, you’ll likely run into integration issues between different log source formats during the rule application itself, and you may need to create separate ETL parsers ahead of time to correct this tech debt. You may need to join an identity event to endpoint activity, and this only works reliably when timestamps, field identifiers, names, and metadata are parsed consistently.

Lastly, it forces your teams to understand the nuances of log formats and data sources, creating knowledge gaps for your detection engineers and SOC analysts. Their time is better spent focusing on alerting and containing threats, and forcing them to context-switch between log formats while inside a SIEM risks having them miss something.

Conclusion: expect this to be painful

Log parsing and normalization is a problem as old as the Internet. It’s a painful process, and it’ll likely not go away even in the age of Agentic Security. Detection and security engineers need to help people answer questions about their logs and telemetry to find threats, bugs, vulnerabilities, and more. When you begin to understand the various log formats, their intention (or lack thereof), and their implementation, you will become an effective security analyst.

This post is Part 1 of my series on Logs and Log Formats. In the next post, I’ll dive deeper into the Transform layer, where we will explore common gotchas in log normalization and the trade-offs that come with them.

Welcome to Issue #170 of Detection Engineering Weekly!

✍️ Musings from the life of Zack:

• I had a relaxing September and I missed you all :) I caught up on reading and rifled through Books 1 & 2 of Dungeon Crawler Dan, and I am well on my way through Book 3

• The excellent folks at DE&THcon gave me seven tickets to give away for their conference in November. It’s completely remote, but you can join “hubs” where people take the training in person. The ticket raffle signup started yesterday, so head over to my microsite and register for the online, Seattle or Atlanta ticket giveaway. You must be a subscriber to enter, and Paid subscribers get 5 entries.

  Enter the Raffle

• Separately, I am also on the CFP Board for MinuteCon, a new security conference in Boston. The CFP just opened, so go check it out and submit a talk!

  Submit A Talk

💎 Detection Engineering Gem 💎

For this week’s Gem, yours truly is coming in hot with a podcast episode on ‘s podcast, Early Adopters: CISO. I joined Dan in the August Vegas heat during BlackHat and walked through my career, which includes writing cheats for video games, joining the security program at RIT and losing two jobs.

I tried to hit a few points and observations I’ve been seeing more with my featured stories here on the newsletter. Agentic work is becoming closer to managing a portfolio of agents, and security teams need to adjust to that mindset if they want to move at the same speed as engineering teams.

🔬 State of the Art

THOR Collective Dispatch

Open Season: Certificate Transparency

Part 1 of the Open Season series from the THOR Collective. All free tools, no vendor gatekeeping…

Read more

3 months ago · 11 likes · Lauren Proehl

Rhetorical question: have I ever said what my favorite protocol is? If you’ve guessed DNS, you are right! There’s something elegant about a 43-year-old, distributed key-value store operating like an Internet phonebook. It shouldn’t still work; most of the Internet shouldn’t, and I’m surprised it still does.

The Certificate Transparency (CT) Log is a massive, append-only database for TLS certificate minting and attestations. Its primary function is to serve as a public ledger for Certificate Authorities (CAs) and end users to ensure a newly minted TLS certificate has a valid signature from a trusted CA. Browsers can quickly ascertain when a certificate isn’t trusted and protect users from connecting to it without those massive red warnings.

It’s also one of my favorite sources of threat intelligence, and I have caught a ton of badness using these open-source logs.

Proehl’s blog here gives an excellent overview of how to hunt through CT logs to help cluster attacker infrastructure. The most immediately useful indicators are the Common Name (CN) and Subject Alternative Name (SAN) fields. When a certificate is issued, it must include metadata about which domains it is valid for. You can build listeners that tail the log with some basic grep magic.

Other clustering methods Proehl covers include burst issuance of domains on shared infrastructure:

Read through the blog if you can! She exposes all kinds of nifty techniques from crt.sh, a free service that you can use to hunt through CT logs. Something I didn’t know: you can connect directly to it’s Postgres database and directly issue queries against it!

Detect risky AI behavior in native OCSF by Philip Mösli

I believe AI “EDR”-style detections are in a nascent space. This blog by Mösli, along with others that cover how coding agent attacks can happen, shows we are thinking about this the right way. I haven't seen a remarkable attack in the wild. In fact, most of what I’ve seen from coding agents are attacks inside a prompt that directs the agent to download a ClickFix-style payload. But that can change once we see their efficacy in real-world campaigns. The TeamPCP supply-chain saga from last year shows how quickly attackers learn and capitalize on poorly configured or misunderstood data sources.

Although this is a product blog, the Tenzir team builds out in the open, which I appreciate. Mösli reviews several examples of coding agent-style attacks and governance failures using their domain-specific language for rules, and explains that the proper way to do this is to integrate with many coding agents. They use a normalization layer to OCSF, so if you don’t use their rule language, you can still send the telemetry to your SIEM of choice.

Besides atomic detections, they show how potential behavioral detections can help find potentially risky behavior. This image was a helpful illustration:

Like many baseline detections, it’s not indicative of a compromise, but it’s useful when put into context of tracking abnormal behavior combined with other atomic behavior.

Getting Agents to tell on themselves by Haroon Meer

ThinkstCanary announced their new honeytoken/deception tool dubbed AgentProvocateur, which specifically targets and tries to trick AI agents. Although this is a product announcement, I think the concept can apply to anyone using their freemium version, or to those who build their own. The idea behind the Provocateur is that it hopes an AI Agent finds it, very similar to other canaries, and begins socially engineering the agent to start revealing information about itself. This is interesting because, according to Meer, it bypasses the idea of a jailbreak and instead focuses on how these models' architecture is designed to complete tasks, so you can socially engineer the agent into taking on tasks.

I think this becomes interesting in the wake of the Hugging Face and *waves his hand across the AI hellscape* other incidents where a model in an alleged sandbox got naughty and found ways to hack into organizations to complete a task during an eval. But here’s where I am not convinced: how do you differentiate the internal and external agent usage? If you have enough honey services that try to socially engineer agents, will your internal tools find the same services? I’d love to hear experiences from folks using this type of tech for detection & response and see how it scales in a large environment.

Discovery of a new OpenAI agent message board by Sydney Von Arx, Cormac Slade Byrd, Spencer Kitts & Thomas Larsen

In this post, researchers disclose a creepy message board “outbreak” from alleged OpenAI agents using four wiki-style websites. A lot of what was posted is similar to what was disclosed in the Hugging Face incident, where the agents used Artifactory vulnerabilities to issue writes as external memory. OpenAI tried to install guardrails on the agents that prevented them from using POST requests, assuming that no other HTTP action could be used to issue write requests. Mozilla even says it themselves!

The GET HTTP method requests a representation of the specified resource. Requests using GET should only be used to request data and shouldn’t contain a body.

The keyword here is "should”. Did you know there’s an actual RFC that dictates the use of keywords like SHOULD?

SHOULD. This word, or the adjective “RECOMMENDED”, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

I guess we should read RFCs more, eh?

The agents began sharing information, including external links, for others to help pass their eval tests, very similar to what happened with ExploitBench and HuggingFace.

☣️ Threat Landscape

Citrix NetScaler Shenanigans

I leave for one month, and I return to an Internet-wide, awkwardly rolled-out Remote Code Execution vulnerability in one of the largest edge device companies? What happened?!

Just kidding; this happens nearly every week at this point, so I expected at least four, so I’ll take one for now :)

Citrix NetScaler ADC and Citrix NetScaler Gateway Security Bulletin for CVE-2026-88771 through CVE-2026-88778 by NetScaler Threat Intelligence

The NetScaler Threat Intel team released guidance on 8 vulnerabilities, and all but one have a CVSS score of 8.8 or higher. The bad one, CVE-2026-88771, requires no preconditions, meaning all devices are affected. It was helpful to get guidance here versus the official patch release, because the NetScaler team released guidance on determining preconditions as well as IoCs. The problem is that only customers get the IoCs, and I couldn’t find any official release of IoCs for the general public.

Oh Look, The Foot Gun Went Off Again: Citrix NetScaler Pre-Auth Command Injection by Sina Kheirkhah / watchTowr Labs

In this blog, the watchTowr Labs team reverse engineered the patched version of 88771 from the vulnerable version and found the affected code. The tl;dr is: when NetScaler is processing a Packet Processing Engine (NSPPE) crash and locating its associated core dump, a privileged Perl script extracts the expected core-file name from appliance logs. The Perl script assumes the associated core-file name follows a specific naming convention. From the blog:

First, imagine a log message like this

NSPPE-00 (12345) unexpectedly died

When this log message is parsed by the Perl code above, it first removes the parentheses:

NSPPE-00 12345 unexpectedly died

Then it prints field 1, a hyphen, and field 2:

NSPPE-00-12345

The problem is that the script never verifies that those first two fields are really an nsppe core file name and a numeric process ID.

This is then passed to the Perl script to process the core file. If an attacker can influence the name of the core file, it can then use its privileged access in a shell expansion attack:

my $WR_PPE_CORE =
    `find /var/core -name ${WR_PPE_COREFILE_NAME}* -print | tail -1`;

As you’ll see in the following posts by Mandiant and eSentire, this privileged access allows attackers to write persistence mechanisms to the Citrix webserver process itself, which then enables webshells.

The team also dropped a PoC, which is probably why there was a huge increase of attacks and incidents that both Mandiant and eSentire responded to.

Defending Against Active Exploitation of Citrix NetScaler ADC and Gateway Appliances by Mandiant & Google Threat Intelligence Group (GTIG)

It’s fascinating to read threat intelligence reports on edge device compromises. At the end of the day, the control plane isn’t the networking code itself, but the web services that control access and configuration. So when I read this specific report by Mandiant/GTIG, I’m reading a combination of web-based threat detection (think WAF or Suricata rules at a lower level) and Linux-based threat detection.

This post has much more detail than the Citrix Threat Intel blog I linked above. The primary vulnerability analyzed in this report, CVE-2026-88771, is the unauthenticated RCE. They don’t provide the payload itself, but the vulnerability lies in how these devices parse initial DTLS handshakes, which leads to a heap overflow and allows privileged execution of the initial payload.

I think the clever or more interesting threat intelligence finding is within the persistence mechanism from these exploits. Threat actors made heavy use of PHP webshells and used sleight-of-hand tricks in httpd.conf. For example:

A request for what appears to be an icon file, such as /vpn/media/e6ee7c85.icoin the report, is internally mapped to a same-named  .sig  file in a NetScaler script directory, which Apache is then configured to execute as PHP. Although this helps masquerade the incoming web requests, it doesn’t do much if you have host-based detection and telemetry on the host.

More Shells Than a Seafood Buffet: Tracking Citrix NetScaler Exploitation Activities (CVE-2026-88771) by eSentire Threat Response Unit

This is a good companion post to the GTIG release above because you can see a bit more behind the malware code itself. eSentire researchers tracked multiple clusters exploiting CVE-2026-88771 beginning before disclosure, then laid out what changed once a public proof of concept became available. The three clusters included:

• One using a lightweight PHP webshell, similar to what GTIG saw

• Another installed the legitimate Platypus fleet-management agent, which is a net new finding and kind of hilarious that DevOps tools are so good at post-exploitation management

• A third deployed a Perl-based installer, PHP shell and Python shell

There was a deeper explanation of how the exploit and subsequent loader malware changed the httpd configuration file without killing httpd, so it’s worth a look for those who want more insight into how Linux/FreeBSD sys internals work.

Sept 28 Advisory: Citrix NetScaler ADC and NetScaler Gateway Zero-Day Remote Code Execution [CVE-2026-88771, CVE-2026-88772] by Censys Threat Research

These advisories and subsequent blog posts came together nicely! This Censys Threat Research blog looks at the Internet-wide view of the Citrix vulnerability. As of September 28th, the Censys team identified 42,000+ NetScaler ADC or Gateway hosts across the Internet. So the scale of the problem is in the 10s of thousands.

As with the Citrix disclosure, 88771 is a default configuration, so Censys argues that anyone running an ADC or Gateway exposed to the Internet should assume they are affected. The distinction between the two actively exploited zero-days matters operationally. 88772 requires DTLS, but that protocol is enabled by default on VPN virtual servers; Censys counted 40,751 Gateway hosts in the subset where that precondition commonly applies. So the intersection isn’t as clean here, but it should help folks prioritize patching or defense-in-depth plans for these devices if they get pushback.

🔗 Open Source

Nebulock-Inc/agentic-threat-hunting-framework

~ Editor’s note: I’m an investor in Nebulock and Sydney & the team are my friends :) ~

Agentic Threat Hunting Framework (ATHF) is a Markdown-first framework for recording and reusing threat hunts. It can serve as memory for your agents between threat hunt runs, while also preserving memory of past hunts so you can steer future hunts in the right direction.

It’s split into two passes: LOCK and GATES. The LOCK loop learns from intelligence or an anomaly, Observes a hypothesis, Checks it with targeted queries, and Keeps the result and lessons learned. Once this loop completes, it hands the workflow to a separate GATES method to determine whether the hunt should produce a useful detection candidate.

runZeroInc/sshamble

sshamble is runZero’s open-source tool to help find insecure, peculiar, or unique exposures on SSH servers. It inventories authentication capabilities, looks for username-enumeration timing behavior, tests public-key handling, checks the badkeys blocklist, and probes for implementation-specific auth bypasses or post-session weaknesses. The output is JSONL, which makes it easy to integrate into SIEMs or inventory databases for broader asset analysis workflows.

luca-ramseyer/raml-kql

Raml KQL is a multi-platform desktop app that allows detection engineers, incident responders, and threat hunters to connect to many Azure Log Analytics workspaces to issue KQL commands and aggregate results across those workspaces in one view. Microsoft Defender does have a multi-tenant hunt feature, and Raml KQL recommends people use it if they have access to it, but this fills the gap if they don’t have that feature access.

aixisstudio/Snitch

Snitch is a real-time network visualization tool that is run entirely locally. You can load your favorite wire format, such as Wireshark dumps in pcap format, and use it to visualize everything from local network traffic to validating detection testing for outgoing or incoming network attacks. It’s all containerized, which is super nice, and you can run it’s equivalent libpcap backend to visualize in real time.