Coder Legion - Recent posts tagged soc

Crogl's Monzy Merza: The SOC Agent That Refuses to Say It Can Replace You

Thu, 20 Aug 2026 13:00:00 +0000

Ask most AI SOC vendors what their agent does, and you'll hear some version of "faster investigations, fewer alerts." Ask Monzy Merza, and he'll walk you through a blast radius map instead — because for Crogl's customers, the real problem was never speed alone. It was that patching a vulnerability and breaking production have historically been two different teams' problems, discovered too late and too far apart.

"Somebody says go patch SharePoint, and they say, well, in order to patch it, you're now changing it from TLS 1.2 to TLS 1.3. Well, that's going to break all your downstream applications," Merza said. "The patch is fixed, but the operations is dead."

Closing a three-day window that used to take weeks

Merza's customers, mostly in critical infrastructure and regulated industries, operate under a hard constraint: CISA's Known Exploited Vulnerabilities directive gives federal agencies and, by extension, the vendors and contractors that serve them, a three-day window to remediate certain vulnerabilities. Not three business days. Three days, period. Historically, meeting that meant a security team ran a scan, handed a list to IT, and hoped for the best. "The game has completely changed," Merza said.

Crogl's answer is what the company calls a blast radius assessment: when a CVE surfaces, the platform maps every affected application, identity, service account, and downstream dependency before anyone touches a patch. Instead of a security team throwing a vulnerability list over the fence, they hand over a prioritized, evidence-backed plan that shows exactly what breaks if a fix goes in, and what's actually at risk if it doesn't. "Now the security team is not just throwing something over the fence," Merza said. "They're giving very concrete, actionable information."

Reasoning models wander. That's why there's a deterministic layer underneath.

The architecture Merza describes is deliberately not just an LLM with tool access. Crogl combines three components: a reasoning layer built on large language models (the platform is model-agnostic), a deterministic symbolic layer and knowledge graph that maps a customer's entire data estate without requiring data normalization, and a governance harness that orchestrates the two and enforces consistency. "We all know models wander, the results wander, they're not always deterministic," Merza said. "So we need models' reasoning, but we combine it with a deterministic system."

That knowledge graph is also what lets Crogl skip a step most competing platforms require. Customers don't need to normalize or transform their data before the agent can use it, which Merza says removes a genuine deployment barrier for organizations running multiple SIEMs and data lakes.

Secure means sovereign, and sovereign was too big a word to use

Crogl isn't a SaaS product. It runs on-premises, in a customer's own cloud, or in air-gapped environments, by design. Merza said the company deliberately chose "secure" over "sovereign" in its own marketing because the latter invited too much interpretation. What it actually means: the LLM only sees what it strictly needs to see, and no customer data leaves their environment, not even to Crogl itself. "Our customers don't want any of their data to leak out to any third party, regardless if it's their security provider," Merza said. Because the product ships to run inside customer environments rather than living behind a hosted API, Merza said it has to clear every static and dynamic analysis scanner that exists. "We can't hide behind a SaaS test."

What "deploy in minutes" actually requires

Merza didn't hedge on this claim, largely because customers have already publicly tested it. Crogl ships as two binaries and a container; installation requires a Unix-like system and the ability to run Docker; nothing more elaborate is needed to get a first use case running. Merza pointed to unprompted LinkedIn posts from users who installed the platform and completed their first investigation in under ten minutes.

The report, not the action, is the default output

When an alert fires, Crogl classifies it, builds an investigation plan, and executes against every data source it's been given access to, documenting each step along the way. The output is a full report with a verdict: escalate or close, with the evidence attached so a security team can defend the decision to an auditor later. Crogl can take action directly, quarantining a file, pulling a malicious attachment, messaging a sandboxing system, but Merza was clear that most customers keep a human as the actual trigger, even when they trust the verdict completely. "There's nothing in the product fundamentally that limits action taking," he said. "It's just the mode of use."

That boundary is customer-configurable down to a granular level. A team might let Crogl work phishing and EDR alerts autonomously all day, while requiring a human to review anything touching a production system like SharePoint. Merza expects that boundary to loosen over time as trust builds, not because Crogl pushes for more autonomy, but because customers extend it themselves once a pattern of accurate, well-documented verdicts accumulates.

What developers need to understand before any of this works

For engineers whose systems generate the logs and alerts Crogl investigates, Merza's advice comes down to basics that are easy to skip. The agent needs real data to operate on. The security team needs a clear, internally agreed sense of what actually counts as a priority, or the agent's output won't be actionable no matter how sophisticated the investigation. And organizations need to get comfortable with a mindset shift: agents will make mistakes, the same way humans do, and the goal isn't perfection. "If you try to run an agent so tightened up that it will [never err], you're going to miss threats and you're going to miss breaches, because then you're back to a rules-driven world," Merza said.

What to be skeptical of

Asked what claim in the AI SOC space deserves the most scrutiny, Merza didn't point to a competitor's specific feature. He pointed to the framing itself. "The biggest one is that they can somehow replace the human, completely," he said. Agents can compress and accelerate much of a security analyst's workflow, but a human supervisor is still required, and any vendor pitching a policy-free, procedure-free autonomous SOC should raise a flag rather than confidence. "If there is no policy, there is no promise. You cannot hold that party responsible."

His closing advice for skeptical readers is characteristically blunt: ignore the pitch and try it yourself. Crogl is a free download, and Merza's pitch to developers and architects isn't a sales script, it's an invitation to bring a real use case and see what breaks.

12 AI Agents Taught Themselves to Evade Your EDR. Most Security Teams Still Won't Trust AI to Triage

Thu, 06 Aug 2026 16:32:09 +0000

In March, according to Sophos, a ransomware actor spun up 12 separate AI agents and set them loose against copies of Sophos's own endpoint protection, CrowdStrike, and Microsoft Defender, running in parallel on separate virtual machines, testing and iterating malware until it could slip past all three. Nash Borges, Sophos's SVP of AI and Engineering, said the company only found the campaign, tracked internally as STAC6994, by working backward from a ransomware event on a host nobody had been actively monitoring. By the time they reconstructed what happened, the operation had produced nearly 80 distinct malware modules and more than 70 evasion techniques, version-controlled and refined automatically as the agents worked. Borges is careful not to oversell what's new here. "It's changing the clock, not the playbook," he said: credential theft, lateral movement, privilege escalation, the fundamentals haven't changed. What's changed is how fast an attacker can iterate through them without needing a room full of skilled humans to do it.

That's one half of the story playing out at Black Hat this year. The other half is that most security teams still don't trust AI to run their own SOC, and the data backs that hesitation up more than the marketing on the show floor would suggest. Research from Strike48, the agentic operations platform that grew out of security data company Devo, found an 84% to 22% gap between security leaders who think AI agents should be handling Tier 1 SOC work and those actually willing to deploy one. Tim Leehealey, Strike48's co-founder, argues the gap isn't really about the technology being immature. It's that most vendors are still pitching a single, general-purpose agent for tasks that were never that complicated to begin with. "Asking an agent to do that is like hiring a PhD and telling him to think deeply about the problem," Leehealey said. "It doesn't work." Security, in his framing, values precision over accuracy in a way most consumer-facing AI products don't: ask the same question with the same facts twice, and you want the same answer both times, not an approximately-right one delivered with total confidence.

That confidence problem is exactly what erodes trust on the floor. Leehealey described watching security buyers walk booth to booth, asking each vendor's demo agent the same kind of question and getting a fluent, wrong answer back, then watching the agent instantly agree it was wrong the moment it was corrected, the AI equivalent of a beekeeper telling a chatbot which plants are actually blooming in their area and watching it abandon its first answer on the spot. Leehealey is blunt about where that leaves things today: "If I can't get ChatGPT to build a PowerPoint I'm happy with, why would I trust it to run my SOC unsupervised?" Asked directly if AI is ready for that yet, his answer was a flat no.

The model that's actually working, according to both Leehealey and Corey Thuen, Gravwell's founder and CEO, isn't one big autonomous agent. It's breaking a security process down into deterministic pieces, scripts, API calls, known steps with a knowable outcome, and keeping the genuinely cognitive, judgment-requiring piece as small as possible. Leehealey describes this as smaller and more granular than most of the industry's current best practice around narrow, single-purpose agents. Thuen, whose company builds the log infrastructure a lot of this analysis actually runs on, makes a similar point from the data side: the fundamentals of security analytics don't change just because an LLM is in the loop. What changes is that the analysis has to run at far greater speed and volume, and an AI agent needs to be auditable the same way a human analyst is, tracking what commands it ran and flagging something as basic as a system prompt getting silently changed and changed back, a sign of the exact kind of tool or prompt poisoning attack this whole ecosystem is now exposed to.

Thuen's company takes a deliberately contrarian position on what feeds that analysis in the first place: don't throw logs away to save on storage costs, because you don't know which one matters until the day you need it. Thuen says most teams keep only 60 to 70% due to storage cost, which creates visibility gaps by leaving that data unavailable exactly when it's needed. Strike48's own pitch to customers approaches the same problem from a different angle, promising close to 100% log visibility by moving that data onto cheap, cold object storage instead of the expensive indexed tier most SIEMs demand.

Both companies are candid that AI oversight can't mean handing over the keys. Thuen is blunt that replacing experienced analysts with junior staff running an LLM unsupervised is "a recipe for disaster," not a cost-saving shortcut. Sophos's Borges frames the same caution as a spectrum rather than a switch: human-in-the-loop for anything risky or irreversible, human-on-the-loop, meaning an AI can act autonomously but a human still audits the results after the fact, for lower-risk, well-validated scenarios, with the boundary between the two moving only as confidence is actually earned through evaluation, not assumed upfront.

None of this is theoretical about how easy the attacker side has gotten. Thuen runs hands-on workshops teaching people how MCP and agentic tooling actually work, including a live exercise where students stand up a malicious MCP server and use it to attack a running system. In a three-hour session, he said, complete beginners with no security or AI background can pull it off. Borges made a related point from the defender's chair: attackers are increasingly going after the AI tooling itself, manipulating coding assistants and MCP servers directly, rather than only using AI as a tool to speed up conventional attacks. The 12 agents Sophos found building an evasion kit in March, and the beginner who can stand up a working attack server in an afternoon, are two versions of the same problem: the barrier to building something dangerous with agentic AI has dropped faster than most security teams' willingness to trust agentic AI with anything that matters.

Torq SOC Brain: Why Reasoning From Precedent Beats Retrieving It

Tue, 28 Jul 2026 13:00:00 +0000

Most autonomous SOC vendors describe "self-learning" the same way. Pull up cases that resemble the one in front of you, hand them to an LLM, and let it summarize what happened last time. That's retrieval dressed up as intelligence. It's useful, but it's not judgment.

Torq is drawing a sharper line with SOC Brain, a new layer of its AI SOC Platform launching at Black Hat USA 2026. Rather than fetching precedent and stopping there, the system is built to reason from it — building a case for what a specific customer's SOC would actually decide, based on how that SOC has decided before.

"Every cybersecurity vendor claims their AI is self-learning, but virtually none are," said Ofer Smadari, CEO and co-founder of Torq. "What the majority do is simply pass cases and hand them to an LLM at the point of decision. That's nothing more than executing based on memory. Self-learning means reaching new conclusions from that history, and that's much harder to build."

Three capabilities, one idea

SOC Brain breaks into three pieces, each solving a different part of the same problem: how do you get an AI system to make calls a human analyst would trust, without waiting years for it to learn an environment the slow way?

Torq Recall handles the deterministic side. It retrieves relevant historical cases using matching on security observables — IPs, file hashes, URLs, hostnames — then ranks them by relevance and analyzes how past analyst decisions should shape the current verdict. It reads analyst notes, flags conflicting precedent, and adjusts its confidence based on how strong the evidence actually is.

Torq Reflex is where the reasoning compounds. It continuously trains a dedicated AI model on a SOC team's confirmed verdicts and corrections, learning that organization's specific approach to risk and evidence. Torq says it matches analyst-corrected verdicts 85% of the time immediately, with accuracy improving from there. High-confidence alerts get automated; uncertain ones still go to a human.

Torq Retrospect solves the cold-start problem that trips up most of these systems. It imports resolved incidents from a customer's existing security tools before deployment, so SOC Brain isn't learning an organization's judgment in real time on live alerts. Years of institutional history become available to Recall and Reflex from day one.

Private by architecture, not by setting

Every customer gets their own SOC Brain, trained exclusively on their analysts, their incidents, their policies, their history. Torq says it never pools customer data or trains one organization's model on another's experience — and that this isolation is built into the architecture rather than toggled on through configuration.

"With Torq SOC Brain and its Torq Recall, Torq Reflex, and Torq Retrospect capabilities, the Torq AI SOC Platform truly learns how a SOC thinks, even from the years of history that predate a Torq deployment," Smadari said. "That's the difference between automation that treats every investigation as if it were on its own and the industry's first SOC that actually gets smarter and more accurate with each completed investigation."

Torq is also positioning SOC Brain around auditability and oversight rather than pure autonomy — explainable decisions, confidence-based automation with a human still in the loop, and outcomes built to hold up against regulatory scrutiny like the EU AI Act.

The question worth asking every vendor

The bigger claim underneath all three capabilities is that an autonomous SOC shouldn't behave like a generic model with a search index bolted on. It should behave as it has actually worked at your company. Recall confirms the facts. Reflex learns the judgment. Retrospect makes sure that judgment doesn't start from zero.

For security teams evaluating autonomous SOC platforms, that's the distinction worth pressing on: is the system retrieving cases, or reasoning from them the way your own analysts would? Those are very different products that can sound identical in a demo.

Torq SOC Brain demos will be available to qualified attendees at the Torq booth at Mandalay Bay Convention Center during Black Hat USA, August 3–6.

Ursnif Malware — Reconstructing a 6-Stage Infection Chain from a PCAP

Tue, 07 Apr 2026 17:43:08 +0000

date: 2026-03-20
description: A walkthrough of my first real malware PCAP investigation — how Ursnif used .avi file extensions to disguise DLL payloads, TLS C2 beaconing, and how I mapped the full attack to MITRE ATT&CK with Splunk detection rules.

One of the most powerful skills a SOC analyst can develop is the ability to look at a packet capture and reconstruct exactly what an attacker did — step by step, packet by packet.

This write-up walks through my first real PCAP investigation using a controlled Ursnif/Gozi banking trojan dataset from malware-traffic-analysis.net — a site widely used in the security community for analyst training.

Result: 6-stage infection chain reconstructed · 10 IOCs extracted · 5 Splunk detection rules written — from 2,180 packets.

What is Ursnif?

Ursnif (also known as Gozi or ISFB) is one of the oldest banking trojans documented in the wild. Key characteristics:

Delivered via malicious Office document macros
Multi-stage payload delivery using disguised file extensions
Encrypted C2 communication over TLS
Modular credential theft and web injection

Tools Used

Wireshark 4.x — packet analysis
VirusTotal — hash and domain reputation
MITRE ATT&CK Navigator — TTP mapping
Splunk SPL — detection rule development

Step 1 — Getting Bearings

Before any filters, I start with Statistics.

Statistics → Conversations → TCP

External IP	Packets	Role (discovered later)
46.102.153.16	906	Payload server
68.168.123.78	18	C2 server
217.138.205.170	8	Initial C2

Statistics → Protocol Hierarchy:

TCP: 97.9%
TLS: 8.2% — encrypted C2 and payload retrieval

Step 2 — Identifying the Victim

Filter: dhcp

Field	Value
IP Address	10.2.24.101
MAC Address	00:08:02:1c:47:ae

Step 3 — The Full Infection Chain

Stage 1 — Initial Compromise

Consistent with Ursnif's delivery: malicious Excel file with embedded VBA macro. Not captured in PCAP.

MITRE: T1566.001 T1059.005

Stage 2 — First TLS Contact (Packet 10)

Filter: ssl.handshake.type==1

Source:      10.2.24.101
Destination: 217.138.205.170
SNI:         fatturapagamentodi.pw

The SNI field in a TLS Client Hello is plaintext — even without decrypting traffic, we can see exactly which domain the malware contacted.

MITRE: T1071.003 T1573.001

Stage 3 — Payload Download (Packets 218–1116)

Filter: http.request.method == "GET"

906 packets to 46.102.153.16. Files had .avi extensions — but were Ursnif DLL segments reassembled in memory. The .avi extension bypasses firewalls that block .exe and .dll downloads.

MITRE: T1105 T1027

Stage 4 — Secondary Payload (Packets 1299, 1563)

GET /grabb32.rar  →  37.10.71.149
GET /grabb64.rar  →  37.10.71.149

Both 32-bit and 64-bit binaries from a separate server.

Stage 5 — C2 Beaconing (Packets 1215–2167)

Filter: ssl.handshake.type==1

Destination: 68.168.123.78
SNI:         asistenzaonline.xyz
Interval:    ~5–10 minutes

Human browsing is random and bursty. Malware is a clock. The consistent interval between TLS handshakes is machine behavior — your detection signal.

MITRE: T1071.001 T1573.001

Stage 6 — Persistence (Inferred)

Registry injection under HKCU\Software\[random key].

MITRE: T1547.001

Indicators of Compromise

Type	Value	Role
IP	217.138.205.170	Initial C2
IP	46.102.153.16	Payload server
IP	37.10.71.149	Secondary payload
IP	68.168.123.78	Primary C2
Domain	fatturapagamentodi.pw	Stage 2 C2
Domain	asistenzaonline.xyz	Persistent C2
Domain	pizdelko.xyz	Fallback C2
URL	http://46.102.153.16/*.avi	DLL delivery
File	grabb32.rar	32-bit binary
File	grabb64.rar	64-bit binary

MITRE ATT&CK Map

ID	Technique
T1566.001	Phishing: Spearphishing Attachment
T1059.005	Command and Scripting Interpreter: VBA
T1105	Ingress Tool Transfer
T1071.001	Application Layer Protocol: Web Protocols
T1071.003	Application Layer Protocol: Mail Protocols
T1547.001	Boot/Logon Autostart: Registry Run Keys
T1027	Obfuscated Files or Information
T1573.001	Encrypted Channel: Symmetric Cryptography

Detection Rules (Splunk SPL)

Rule 1 — TLS to suspicious SNI

index=network ssl.handshake.type=1
| stats count by src_ip, ssl.handshake.extensions_server_name
| where NOT ssl.handshake.extensions_server_name LIKE "%.google.com"
  AND NOT ssl.handshake.extensions_server_name LIKE "%.microsoft.com"
  AND NOT ssl.handshake.extensions_server_name LIKE "%.cloudflare.com"
| sort -count

Rule 2 — C2 beaconing via TLS regularity

index=network ssl.handshake.type=1
| bucket _time span=10m
| stats count by src_ip, dest_ip, _time
| streamstats window=6 current=t stdev(count) as regularity by src_ip, dest_ip
| where regularity < 1.5

Rule 3 — Media file extension from non-CDN IP

index=network http.request.method=GET
| rex field=uri "(?<ext>\.[a-z0-9]{2,4})$"
| where ext IN (".avi",".mp4",".mp3")
| eval dest_is_cdn=if(match(dest_ip,"^(151\.101|104\.16|172\.67)"),1,0)
| where dest_is_cdn=0
| stats count by src_ip, dest_ip, uri, ext
| where count > 3

Rule 4 — Chunked download from single external IP

index=network http.request.method=GET
| stats dc(uri) as unique_files, count as total_requests by src_ip, dest_ip
| where unique_files > 3
| eval internal=if(match(dest_ip,"^(10\.|192\.168\.)"),1,0)
| where internal=0
| sort -total_requests

Rule 5 — Suspicious archive by name pattern

index=network http.request.method=GET
  (uri="*.rar" OR uri="*.zip")
| where NOT dest_ip LIKE "192.168.%" AND NOT dest_ip LIKE "10.%"
| eval suspicious=if(match(uri,"(grabb|drop|stage|payload|inject)"),1,0)
| where suspicious=1
| stats count by src_ip, dest_ip, uri

Three Key Lessons

1. The .avi trick works because defenders trust file extensions. Fix: inspect file content, not just extension.

2. Beaconing regularity is your strongest behavioral detection signal. Low standard deviation in connection intervals = machine, not human.

3. Multi-stage infrastructure creates more IOCs, not fewer. Four servers = four things to block and hunt for.

Immediate Response Actions

Isolate 10.2.24.101
Block all 4 attacker IPs
Sinkhole 3 C2 domains at DNS
Hunt for .avi GETs from non-CDN IPs in 30 days of proxy logs
Deploy rules 1–5 to SIEM

Full Report on GitHub

github.com/himanshumodi3108/cybersec-portfolio

This analysis was performed on a controlled training dataset from malware-traffic-analysis.net for educational purposes.

Himanshu Kumar Modi · Associate at PwC India · SOC Analyst in Training
LinkedIn · Cybersecurity Portfolio

Splunk's research shows defenders have the AI advantage—how to use LLMs for 150x faster analysis.

Mon, 11 Aug 2025 19:09:51 +0000

Why Defenders Have the AI Advantage (And How to Keep It)

Splunk's Ryan Fetterman reveals how security teams can leverage LLMs to outpace attackers—and introduces The Threat Hunter's Cookbook

While much of the cybersecurity industry frets about AI empowering attackers, Ryan Fetterman has a contrarian view: defenders currently hold the advantage in the AI arms race. As Senior Security Strategist at Splunk SURGe and co-author of the newly released "The Threat Hunter's Cookbook," Fetterman believes the nature of security operations work plays directly to AI's strengths.

"I think the defender has the advantage because so much of the work that we do in the SOC is based around text-based data, understanding it, generating it," Fetterman explained during our interview at Black Hat 2025. "Those are the core strengths of models, and that's the core of a lot of the processes that flow through the SOC: threat intelligence, consuming it, writing it, looking at alerts, understanding machine data, code interpretability."

This perspective, which Fetterman acknowledges might be "contrary to the median opinion," stems from practical experience deploying AI in real security operations rather than theoretical concerns about AI-powered attacks.

From Theory to Practice: Model-in-the-Loop Threat Hunting

Fetterman's optimism isn't just theoretical, it's backed by concrete results from Splunk's research into what he calls "model-in-the-loop threat hunting." The approach addresses one of the most persistent challenges in security operations: the overwhelming volume of data that requires human analysis.

Take PowerShell script analysis, a classic example of the "living off the land" problem that plagues security teams. Both legitimate administrators and malicious actors use PowerShell extensively, creating a needle-in-haystack scenario where human analysts must manually classify thousands of scripts to identify genuine threats.

"Typically, you need a human in the loop to look at all these things and make a determination of whether something is legitimate or malicious functionality," Fetterman said. "What we did was we wrote a query that would pull a bunch of those events and then, rather than having an analyst go through 2,000 different scripts and classify them, we fed all of these scripts into open-weight LLMs."

The results were striking. Using off-the-shelf models like Llama 3, the team achieved around 80% accuracy with nearly perfect recall; meaning they caught almost all true threats while generating manageable false positives. More importantly, the speed improvement was dramatic: from five minutes per event for human analysis to two seconds per event for AI analysis, a 150x speed improvement.

"That ultimately was the problem we wanted to solve," Fetterman noted. "Everyone agrees that AI for attackers is increasing efficiency and productivity. So if we're looking for opportunities to go faster on defense, to keep that parity, this is the kind of case we're looking to solve."

The Cookbook Approach to Threat Hunting

This practical experience with AI implementation informs Splunk SURGe's broader approach to threat hunting, codified in their new "Threat Hunter's Cookbook." Released at Black Hat 2025, the guide represents a systematic approach to the "black box" of analysis that often mystifies security teams.

"With so many ways to kick off a hunt, it can be hard to select the best approach," the team notes. "Even if you have tried-and-true ways for hunting, this can ultimately cap the ceiling of your potential results."

The cookbook organizes threat hunting methods—searching and filtering, sorting and stacking, clustering, grouping—into practical "recipes" that follow a problem-solution-discussion format. Built on the PEAK Threat Hunting Framework (winner of the 2024 SANS Difference Makers award for Innovation), it provides both methodology and practical SPL queries for Splunk users.

Navigating the Complexity Trade-off

Despite his enthusiasm for AI in security, Fetterman emphasizes the importance of matching solution complexity to problem complexity. "Sometimes machine learning is needlessly complex," he said. "I tend to try to emphasize that you don't want to be more complex than you need to be. That's a battle you fight a lot in security, especially when customers are eager to say they're using machine learning or integrating AI products."

This philosophy extends to how organizations should think about AI-powered threats. Rather than panicking about theoretical AI attacks, Fetterman suggests a more measured approach: "We should prepare to face them in ways that, I like the idea of, purple teaming with AI agents. You're expecting adversaries to build red agents to deploy against you. You should build them yourself and start testing them against your own defenses."

The Future of AI-Powered Security

Looking ahead, Fetterman sees the future not in AI replacing human analysts, but in changing the ratio of humans to automated agents. "We may have more of a ratio of analysts to agents, where an analyst is overseeing different agents that are focused on different tasks," he explained. "That seems like a much better, more scalable, more controllable future for how we integrate AI."

This vision aligns with Splunk's broader strategy of creating domain-specific models for security use cases. The company is already exploring advanced applications, including behavioral fingerprinting that uses LLMs to analyze post-login user behavior and identify suspicious activity patterns.

Early Warning: AI Malware in the Wild

Fetterman's research has also uncovered early examples of AI-powered malware, providing a glimpse into how attackers might leverage these technologies. A recent report from CERT in Ukraine, attributed to Russian government actors (APT 28 or 29), described Python-based malware that used the Hugging Face API and prompts to the Qwen Coder model instead of containing traditional hardcoded instructions.

"Instead of containing instructions, it actually used prompts to a model and was asking the model to return commands to run on the system," Fetterman explained. "It's a totally different paradigm of how malware works, maybe a new category of how attackers are trying things."

While the advantages of this approach remain unclear (the malware was detected), it demonstrates that both sides are actively experimenting with AI integration.

Practical Recommendations for Development Teams

For developers building security tooling, Fetterman offers several key recommendations:

Start with domain-specific models: Generic AI models can be effective, but security-specific models trained on relevant data will perform better for specialized tasks.

Implement human-in-the-loop design: Rather than pursuing full automation, design systems where AI handles initial triage and analysis while humans make final decisions.

Prepare for agent-based threats: As attackers develop AI agents for reconnaissance, initial access, and discovery, build purple team capabilities to test your defenses against similar tools.

Don't overextend: While organizations "can't afford to not be doing AI stuff right now," be cautious about bleeding-edge implementations in rapidly evolving areas like multi-agent frameworks.

The Security Tool Sprawl Solution

One often-overlooked advantage of platforms like Splunk in the AI era is their potential to reduce security tool sprawl. With the average Fortune 500 company managing 70+ security solutions, the ability to build custom AI-powered analytics and dashboards within a unified platform becomes increasingly valuable.

"Because of the extensibility and customization of Splunk, you are free to build more things yourself," Fetterman noted. "That's a key way that I've seen products not be needed—if you have Splunk, then you can build custom dashboards, integrate with APIs, and eliminate the need for certain gaps or certain categories of problems."

Staying Ahead of the Curve

As AI continues to reshape cybersecurity, Fetterman's message is clear: the tools and techniques exist today for defenders to maintain their advantage, but success requires thoughtful implementation rather than wholesale adoption of the latest AI trends.

The release of "The Threat Hunter's Cookbook" represents more than just documentation, it's a systematic approach to leveraging both human expertise and AI capabilities in pursuit of more effective threat detection. For organizations wondering how to navigate the AI revolution in cybersecurity, Fetterman's advice is practical: start with clear problems, use appropriate tools, and always keep humans in the loop.

As the cybersecurity landscape continues to evolve, the organizations that thrive will be those that, like Splunk SURGe, combine rigorous methodology with practical AI implementation—turning the promise of artificial intelligence into measurable improvements in security outcomes.