When I look back on my years as a SOC lead in MDR, the thing I remember most clearly is the tension between wanting to do things the βright wayβ and simply trying to survive the day.
The alert queue never stopped growing. The attack surface kept expanding into cloud, identity, SaaS, and whatever new platform the business adopted. And every shift ended with the same uneasy feeling:Β What did we miss because there wasnβt enough time to investigate everything fully?
While different sources emphasize different challenges, recent statistics from late 2024 and 2025 reports reflect exactly what so many SOC analysts and leads feel:
The majority of alerts are never touched.Β Recent surveys indicate thatΒ 62% of alerts are ignoredΒ largely because the sheer volume makes them impossible to address. Furthermore, many analysts report being unable to deal with up toΒ 67% of the daily alertsΒ they receive.
The volume is unmanageable for humans.Β A typical SOC now processes an average ofΒ 3,832 alerts per day. For analysts trying to manually triage this flood, the math simply doesnβt add up.
Burnout is the new normal.Β The pressure is unsustainable, withΒ 71% of SOC analysts reporting burnoutΒ due to alert fatigue. This has accelerated turnover, with some SOCs seeing analyst retention cycles shrink toΒ less than 18 months, eroding institutional knowledge.
When people outside the SOC see these numbers, they assume analysts arenβt doing their jobs. The truth is the opposite. Most analysts are doing the best work they can inside a system that was never built for volume. Traditional triage is reactive and heavily dependent on intuition. On a good day, that might work. On a bad day, it leads to inconsistent decisions, coverage gaps, and immense pressure on analysts who care deeply about getting it right.
This is where theΒ OSCAR methodologyΒ becomes valuable again.
Why the OSCAR methodology still matters
As a SOC lead, I always wanted the team to approach alerts with organizational structure. OSCAR provides that structure by creating a clear, repeatable sequence:
Obtain Information
Strategize
Collect Evidence
Analyze
Report
It removes guesswork and helps analysts who are still developing their skills stay grounded during chaotic shifts. But here is the reality I learned firsthand βΒ You can only scale OSCAR so far with humans alone.
Evidence collection takes time. Deep analysis takes more time. No matter how motivated an analyst is, there are simply not enough hours in a shift to apply OSCAR to every alert manually. Most teams end up applying the methodology selectively; critical and high-severity alerts get the full OSCAR treatment, while everything else gets whatever time is left.
That gap between process and reality is exactly where Intezer enters the picture.
How Intezer operationalizes OSCAR at scale
Intezer takes the proven structure of OSCAR and executes it automatically and consistently acrossΒ everyΒ alert. Instead of relying on how much energy an analyst has left 45 minutes before there shift ends, Intezer performs evidence collection, deep forensic analysis, and reporting at a speed and depth no human team could sustain.
Here is how the platform automates the methodology step-by-step:
O: Information obtained
In my SOC days, gathering context meant jumping between consoles and browser tabs, hoping nothing crashed. Intezer collects all of this instantly from endpoints, cloud platforms, identity systems, and threat intel sources. Analysts start every case with the full picture rather than a partial one.
S: Strategy suggested
Instead of relying on an analystβs instinct about whatΒ mightΒ be happening, the Intezer platform generates verdicts and risk-based priorities immediately (with 98% accuracy). This provides critical consistency, especially for junior analysts who are still finding their confidence. Additionally, all AI reasoning is fully backed by deterministic, evidence based analysis.
C: Evidence collected
This was always the slowest part of manual investigation. Intezer collects memory artifacts, files, process information, and cloud activity in seconds. No hunting, no guessing, and no hoping you pulled the right logs before they rolled over.
A: Analysis (forensic-grade)
Intezer performs genetic code analysis, behavioral analysis, static/dynamic analysis, and threat intelligence correlation on every single alert. This is the level of scrutiny senior analystsΒ wishΒ they had time to do manually, but usually can only afford for the most critical incidents.
The platform creates clear, structured, audit trails. This removes the burden of manual documentation from analysts and ensures that the βwhyβ behind every decision is transparent and explainable.
The result: Moving beyond βspeed vs. depthβ
When OSCAR is coupled with Intezerβs AI Forensic SOC, the operation transforms. We see this in actual customer environments:
100% alert coverage:Β Even low-severity and βnoisyβ alerts are fully triaged.
Sub-minute triage:Β Drastically improved MTTR/MTTD and minimized backlogs.
98% accurate decisioning:Β Verdicts are supported by deterministic evidence, reducing escalations for human review to less than 4%.
The shift in operations:
Capability
Traditional MDR SOC
Intezer Forensic AI SOC
Coverage
Critical and High-severity
100% of alerts
Triage time
20+ mins per alert
<2 mins (automated)
Analyst mode
Data collector
Investigator
From the perspective of a former SOC lead, the most important benefit is this:Β
βAnalysts finally get to think again. Automation handles the busy work. Humans get to use judgment, creativity, and experience.β
Final thoughts
For years, triage has been treated like a speed exercise. But the threats we face today require depth, context, and clarity. OSCAR gives SOCs the investigative structure they need, and Intezer provides the scale required to actually use that structure across every alert.
For the first time, teams donβt have to choose between speed and depth. They get both.
What happens when you ditch the tiered ticket queues and replace them withΒ collaboration, agility, and real-time response? In this interview, Hayden Covington takes us behind the scenes of the BHIS Security Operations Center, which isΒ where analystsΒ donβtΒ escalateΒ tickets,Β they solve them.
This is the first time we have a public, detailed report of a campaign where AI was used at this scale and with this level of sophistication, moving the threat from a collection of AI-assisted tasks to a largely autonomous, orchestrated operation.
This report is a significant new benchmark for our industry. Itβs not a reason to panic β itβs a reason to prepare. It provides the first detailed case study of a state-sponsored attack with three critical distinctions:
It was βagenticβ: This wasnβt just an attacker using AI for help. This was an AI system executing 80-90% of the attack largely on its own.
It targeted high-value entities: The campaign was aimed at approximately 30 major technology corporations, financial institutions, and government agencies.
It had successful intrusions: Anthropic confirmed the campaign resulted in βa handful of successful intrusionsβ and obtained access to βconfirmed high-value targets for intelligence collectionβ.
Together, these distinctions show why this case matters. A high-level, autonomous, and successful AI-driven attack is no longer a future theory. It is a documented, current-day reality.
2. What Actually Happened: A Summary of the Attack
The attack (designated GTG-1002) was a βhighly sophisticated cyber espionage operationβ detected in mid-September 2025.
AI Autonomy: The attacker used Anthropicβs Claude Code as an autonomous agent, which independently executed 80-90% of all tactical work.
Human Role: Human operators acted as βstrategic supervisorsβ. They set the initial targets and authorized critical decisions, like escalating to active exploitation or approving final data exfiltration.
Bypassing Safeguards: The operators bypassed AI safety controls using simple βsocial engineeringβ. The report notes, βThe key was role-play: the human operators claimed that they were employees of legitimate cybersecurity firms and convinced Claude that it was being used in defensive cybersecurity testingβ.
Full Lifecycle: The AI autonomously executed the entire attack chain: reconnaissance, vulnerability discovery, exploitation, lateral movement, credential harvesting, and data collection.
Timeline: After detecting the activity, Anthropicβs team launched an investigation, banned the accounts, and notified partners and affected entities over the βfollowing ten daysβ.
To have a credible discussion, we must also look at what wasnβt new. This attack wasnβt about secret, magical weapons.
The report is clear that the attackβs sophistication came from orchestration, not novelty.
No Zero-Days: The report does not mention the use of novel zero-day exploits.
Commodity Tools: The report states, βThe operational infrastructure relied overwhelmingly on open source penetration testing tools rather than custom malware developmentβ.
This matters because defenders often look for new exploit types or malware indicators. But the shift here is operational, not technical. The attackers didnβt invent a new weapon, they built a far more effective way to use the ones we already know.
4. The New Reality: Why This Is an Evolving Threat
So, if the tools arenβt new, what is? The execution model. And we must assume this new model is here to stay.
This new attack method is a natural evolution of technology. We should not expect it to be βstoppedβ at the source for two main reasons:
Commercial Safeguards are Limited: AI vendors like Anthropic are building strong safety controls β itβs how this was detected in the first place. But as the report notes, malicious actors are continually trying to find ways around them. No vendor can be expected to block 100% of all malicious activity.
The Open-Source Factor: This is the larger trend. Attackers donβt need to use a commercial, monitored service. With powerful open-source AI models and orchestration frameworks β such as LLaMA, self-hosted inference stacks, and LangChain/LangGraph agents β attackers can build private AI systems on their own infrastructure. This leaves no vendor in the middle to monitor or prevent the abuse.
The attack surface is not necessarily growing, but the attackerβs execution engine is accelerating.
5. Detection: Key Patterns to Hunt For
While the techniques were familiar, their execution creates a different kind of detection challenge. An AI-driven attack doesnβt generate one βsmoking gunβ alert, like a unique malware hash or a known-bad IP. Instead, it generates a storm of low-fidelity signals. The key is to hunt for the patterns within this noise:
Anomalous Request Volumes: The AI operated at βphysically impossible request ratesβ with βpeak activity included thousands of requests, representing sustained request rates of multiple operations per secondβ. This is a classic low-fidelity, high-volume signal that is often just seen as noise.
Commodity and Open-Source Penetration Testing Tools: The attack utilized a combination of βstandard security utilitiesβ and βopen source penetration testing toolsβ.
Traffic from Browser Automation: The report explicitly calls out βBrowser automation for web application reconnaissanceβ to βsystematically catalog target infrastructureβ and βanalyze authentication mechanismsβ.
Automated Stolen Credential Testing: The AI didnβt just test one password, it βsystematically tested authentication against internal APIs, database systems, container registries, and logging infrastructureβ. This automated, broad, and rapid testing looks very different from a humanβs manual attempts.
Audit for Unauthorized Account Creation: This is a critical, high-confidence post-exploitation signal. In one successful compromise, the AIβs autonomous actions included the creation of a βpersistent backdoor userβ.
6. The Defenderβs Challenge: A Flood of Low-Fidelity Noise
The detection patterns listed above create the central challenge of defending against AI-orchestrated attacks. The problem isnβt just alert volume, itβs that these attacks generate a massive volume of low-fidelity alerts.
This new execution model creates critical blind spots:
The Volume Blind Spot: The AIβs automated nature creates a flood of low-confidence alerts. No human-only SOC can manually triage this volume.
The Temporal (Speed) Blind Spot: A human-led intrusion might take days or weeks. Here, the AI compressed a full database extraction β from authentication to data parsing β into just 2-6 hours. Our human-based detection and response loops are often too slow to keep up.
The Context Blind Spot: The AIβs real power is connecting many small, seemingly unrelated signals (a scan, a login failure, a data query) into a single, coherent attack chain. A human analyst, looking at these alerts one by one, would likely miss the larger pattern.
7. The Importance of Autonomous Triage and Investigation
When the attack is autonomous, the defense must also have autonomous capabilities.
We cannot hire our way out of this speed and scale problem. The security operations model must shift. The goal of autonomous triage is not just to add context, but to handle the entire investigation process for every single alert, especially the thousands of low-severity signals that AI-driven attacks create.
An autonomous system can automatically investigate these signals at machine speed, determine which ones are irrelevant noise, and suppress them.
This is the true value: the system escalates only the high-confidence, confirmed incidents that actually matter. This frees your human analysts from chasing noise and allows them to focus on real, complex threats.
This is exactly the type of challenge autonomous triage systems like the one weβve built at Intezer were designed to solve. As Anthropicβs own report concludes, βSecurity teams should experiment with applying AI for defense in areas like SOC automation, threat detectionβ¦ and incident responseβ.
8. Evolving Your Offensive Security Program
To defend against this threat, we must be able to test our defenses against it. All offensive security activities, internal red teams, external penetration tests, and attack simulations, must evolve.
It is no longer enough for offensive security teams to manually simulate attacks. To truly test your defenses, your red teams or external pentesters must adopt agentic AI frameworks themselves.
The new mandate is to simulate the speed, scale, and orchestration of an AI-driven attack, similar to the one detailed in the Anthropic report. Only then can you validate whether your defensive systems and automated processes can withstand this new class of automated onslaught. Naturally, all such simulations must be done safely and ethically to prevent any real-world risk.
9. Conclusion: When the Threat Model Changes, Our Processes Must, Too.
The Anthropic report doesnβt introduce a new magic exploit. It introduces a new execution model that we now need to design our defenses around.
Letβs summarize the key, practical takeaways:
AI-orchestrated attacks are a proven, documented reality.
The primary threat is speed and scale, which is designed to overwhelm manual security processes.
Security leaders must prioritize automating investigation and triage to suppress the noise and escalate what matters.
We must evolve offensive security testing to simulate this new class of autonomous threat.
This report is a clear signal. The threat model has officially changed. Your security architecture, processes, and playbooks must change with it. The same applies if you rely on an MSSP, verify theyβre evolving their detection and triage capabilities for this new model. This shift isnβt hype, itβs a practical change in execution speed. With the right adjustments and automation, defenders can meet this challenge.
But what if we need to wrangle Windows Event Logs for more than one system? In part 2, weβll wrangle EVTX logs at scale by incorporating Hayabusa and SOF-ELK into my rapid endpoint investigation workflow (βREIWβ)!Β
In part 1 of this post, weβll discuss how Hayabusa and βSecurity Operations and Forensics ELKβ (SOF-ELK) can help us wrangle EVTX files (Windows Event Log files) for maximum effect during a Windows endpoint investigation!
Remember the good βol days of Zip drives, Winamp, the advent of βOffice 365,β and copy machines that didnβt understand email authentication? Okay, maybe they werenβt so good! For a [β¦]
In this video, John Strand discusses the complexities and challenges of penetration testing, emphasizing that it goes beyond just finding and exploiting vulnerabilities.
Changes to the msds-KeyCredentialLink attribute are not audited/logged with standard audit configurations. This required serious investigations and a partner firm in infosec provided us the answer: TrustedSec.Β So, credit where [β¦]
Recently in the SOC, we were notified by a partner that they had a potential business email compromise, or BEC. We commonly catch these by identifying suspicious email forwarding rules, [β¦]
While social engineering attacks such as phishing are a great way to gain a foothold in a target environment, direct attacks against externally exploitable services are continuing to make headlines. [β¦]
Be sure to read PART 1! Metadata and a New-Fashioned Bank Robbery Letβs face it, some cases are just more interesting than others and, when you do incident response for [β¦]
Being a digital forensics and incident response consultant is largely about unanswered questions. When we engage with a client, they know something bad happened or is happening, but they are [β¦]
Patterson Cake // PART 1 PART 2 In part one of βWrangling the M365 UAL,β we talked about acquiring, parsing, and querying UAL data using PowerShell and SOF-ELK. In part [β¦]
Patterson Cake // When it comes to M365 audit and investigation, the βUnified Audit Logβ (UAL) is your friend. It can be surly, obstinate, and wholly inadequate, but your friend [β¦]
Troy Wojewoda // In honor of Shark Week1, I decided to write this blog to demonstrate various techniques Iβve found useful when analyzing network traffic with Wireshark, as well as [β¦]
Tom Smith // At Black Hills Information Security (BHIS), we deal with all manner of clients, public and private. Until a month or two ago, though, weβd never dealt with [β¦]
rvrsh3ll //Β IntroductionΒ This blog post is intended to give a light overview of device codes, access tokens, and refresh tokens. Here, I focus on the technical how-to for standing [β¦]
Derek Banks // Living Off the Land Binaries, Scripts, and Libraries, known as LOLBins or LOLBAS, are legitimate components of an operating system that threat actors can use to achieve [β¦]