Intezer

Loop engineering comes to the SOC: Introducing the Intezer Org Brain July 21, 2026 Written by Itai Tevet Last month (June), one idea took over the AI conversation: stop prompting your agent, and start designing the loop that prompts it. Boris Cherny, the creator of Claude Code, said he doesn’t prompt Claude anymore. Loops do. Within days the industry had a name for it: loop engineering. Coding agents got there first. But the loop that matters most for security teams doesn’t run in a code editor. It runs in your SOC, where the real question is what your AI analyst remembers after each investigation. Think about the best analyst on your team. Three years in, they just know things. That CrowdStrike alert on the build servers fires every time DevOps pushes a release. Dave from finance logs in from Portugal, and it’s fine. None of it is written down anywhere. And the day they resign, all of it walks out the door. We built Org Brain so it doesn’t. Context was table stakes. This is something else. Let’s be clear about what we’re not claiming. Organizational context in an AI SOC is table stakes. Every serious AI SOC product has some version of it, and Intezer has used org context in investigations for years. If a vendor is still pitching “we understand your environment” as the headline, that’s a 2024 announcement. Org Brain is different in kind, not degree. It’s a memory system, not a context store. It doesn’t just hold what someone loaded into it during onboarding. It learns, it recalls, it fetches what it’s missing, and it gets sharper with every alert it touches, all autonomously. Here’s how. Two memory systems, one brain Today we’re releasing Org Brain, built from two main components, modeled on the two kinds of memory a real SOC team runs on: how you work, and who you are. Muscle memory — the how (procedural knowledge) Every SOC develops its own way of doing things, mostly without documenting it. Which query an analyst runs when an identity alert hits a domain controller. Which detections get closed on sight because they’ve been benign four hundred times in a row. What the tuning history says about that noisy DLP rule. Where an investigation goes next after a suspicious login, and where it doesn’t bother going. This knowledge lives in your analysts’ hands. For Intezer customers, it has also lived in the Tuning Center, as memory you had to create yourself. Org Brain now captures it autonomously and applies it, so an investigation at 3am runs the way your best analyst would run it at 10am. Self-awareness — the who (declarative knowledge) Your assets and what they’re for. Your users, their roles, what their normal login behavior looks like. The tickets they’ve opened before. And one layer deeper: your data itself. How your SIEM is structured, which fields exist, what the columns actually mean, where the truth about an entity lives. This is declarative knowledge. The facts an investigation stands on. An AI agent that doesn’t know your schema is a tourist with a phrasebook. One that does can ask your environment the right question, in your environment’s own language, mid-investigation. Put together, this is the difference between an AI that has context and an AI that knows your organization. Context answers “what is this server?” Org Brain answers “what is this server, is that login normal for this user, and what would our team do about it?” Engineered as a loop Org Brain is built the way loop engineering prescribes. The agent alone isn’t the system; the loop around it is. Act, verify, learn, repeat. Org Brain runs that loop across your SOC’s past, present, and future. It learns from your past. A brain that starts empty would take months to become useful. Org Brain doesn’t start empty. Intezer can now ingest the history your SOC already has: the cases and tickets sitting in your case management tool, years of resolutions, escalations, and quiet decisions to close without action. That history becomes muscle memory and self-awareness before the first new alert arrives. It fetches your present. When memory isn’t enough, Org Brain doesn’t guess. It knows what it knows, and it knows where to look. Mid-investigation, it pulls live context from your environment on demand, just in time, so a verdict rests on what’s true right now, not on what was true when someone last synced a database or refreshed a graph. We’ve been investing in developing more integrations to fetch just-in-time organizational context, and customers can expect an increasingly rich context ecosystem. It learns for your future. After every investigation, autonomous or alongside your analysts, the loop closes. Following frontier AI system design, a superior model, what AI labs call an auditor, or critic, reviews what happened. What the investigation found, what your analysts corrected, which path led to the verdict. The conclusions are written back into the brain. A tuning decision or an analyst’s feedback becomes muscle memory. A newly seen asset becomes self-awareness. The next investigation starts smarter than the last one finished. What this means for Intezer customers Org Brain is rolling out gradually, and parts of it are already working for you. Some capabilities live in the backend. You won’t see a new button immediately, but you’ll notice richer context in results and more accurate verdicts. When Org Brain appears in your menu bar, you’re officially in the rollout. Some of it will also look familiar. Alert tuning, feedback, and custom queries are now part of Org Brain, which means every tuning decision and correction your team has made was, in effect, training it before it had a name. More capabilities will land under the Org Brain umbrella in the coming months. A superior way to run an AI SOC Context is critical to every investigation. That was true before AI entered the SOC, and it’s table stakes now. No AI analyst should be making verdicts blind to the environment it works in. But holding context and understanding an organization are not the same thing, and the gap between them shows up exactly where it hurts: in accuracy, in speed, in how complete an investigation really is. Org Brain is our answer to that gap, and it reflects how we build: staying at the frontier of AI development and turning what’s proven there into outcomes for security teams. A brain that knows how your SOC works and who your organization is. One that learns from your past, fetches your present just in time, and gets smarter with every investigation. If you want to see what your SOC looks like with a brain, book a demo. Itai Tevet Co-founder and CEO of Intezer, Itai is on a mission to revolutionize how SOC teams investigate and respond to cybersecurity incidents. He previously led the cyber incident response team for one of the world's most targeted organizations. Itai combines his expertise in AI and security to advise security leaders at Fortune 500 companies on how to defend against threat actors in the AI era.

The conversation around AI-powered threats has focused heavily on the attacker side. What models can do, what vulnerabilities they can find, how fast they can chain exploits together. But the more important question for security practitioners is simpler and harder. Is your detection posture ready for what’s already happening? AI has lowered the barrier to entry for sophisticated attacks. Threat actors don’t need to be experts to leverage LLMs for obfuscation, exploit development, or chaining attack steps that previously required deep manual skill. The speed and volume of attacks is increasing as a result. Detection engineering is part of how defenders respond. And most organizations are further behind than they realize, especially because many detection engineering programs live in their own siloed “ivory tower”, detached from the realities of what SOC analysts are handling. At Intezer, AI-powered detection engineering runs as part of a closed loop with automated, forensic triage and investigation. Every alert investigated across the environment feeds new signal back into detection logic, so coverage improves continuously instead of drifting between quarterly tuning cycles. Detection working in concert with triage and investigation is what a fully optimized security environment looks like against AI-powered attackers. In this article, we’ll focus on how to improve detection engineering practices in general. Why your current detection posture isn’t keeping pace The fundamental problem is that most detection programs were built for a world where attack volume was bounded by attacker expertise. That constraint is being removed. LLM-augmented attacks can move faster, produce more permutations, and adapt more readily to your environment than traditional campaigns. A detection posture built on static indicators and periodic tuning cycles can’t keep up. There are three places this shows up in practice. Covering one sub-technique doesn’t cover the technique First, most organizations are only covering technique-level MITRE ATT&CK mappings, not sub-techniques. When you claim T1059 is covered because you have a rule for T1059.001, you’re exposing yourself to real risk hiding beneath that coverage number. Sub-techniques carry distinct behaviors that may exist in your environment and go completely undetected. High-level coverage scores look good in reports and obscure what’s actually happening. The risk lives at the sub-technique level. IOCs are brittle indicators Second, IOC-based detections are becoming a liability at scale. IP addresses, file hashes, domains are valuable in incident response but brittle as primary detection logic. Their half-life is short, adversaries burn them readily, and maintaining a large list of active IOCs creates noise without proportionate signal. Organizations that lead with IOCs end up toggling rules on and off constantly, adding friction without improving coverage. The maintenance cost compounds without a meaningful security return. Pulling logs is not the same as pulling useful logs Third, telemetry that looks healthy often isn’t. A Windows Event ID 4688 without command-line logging enabled is an example. You’re paying to ingest it, it shows up in your coverage maps, but it provides no actionable data when something fires. Unmapped or broken telemetry creates the appearance of coverage where none actually exists. Before you write a new rule, validate that the data it depends on actually contains what you think it does. What behavioral detection actually means in practice Behavioral detections are built around what attackers do across a campaign, not what artifacts they happened to leave behind in a specific incident. Techniques, sequences, tool patterns, execution chains persist across campaigns, across threat actors, and even across malware families. A behavioral detection written well today has a much longer useful life than any IOC-based rule. The shift to behavioral detection isn’t just a philosophy, it requires specific changes to how rules are built and maintained. Score based detection Score-based detection logic is one of the most underused approaches in enterprise SIEMs. If you’re running Splunk, Sumo Logic, or Cortex XDR, score-based rules let you assign weighted values to individual signals and alert when combinations cross a threshold. Individual signals that are weak in isolation, a process executing from an unusual path, a network connection to an uncommon destination, a scheduled task created outside business hours, become meaningful together. Noise goes down. True positive rate goes up. And the system stays tunable as your environment changes. Permutation testing Permutation testing is the other discipline most detection programs skip. LLMs make it straightforward to generate attack variants at volume. Defenders should be doing the same before releasing rules. If a detection rule only catches one specific implementation of a technique, an attacker using a slightly different toolchain or execution order will evade it. Testing rules against a range of permutations before production deployment closes gaps that post-deployment tuning will miss. The detection engineering cycle has to get faster The traditional cycle, write a rule, deploy it, wait for something to fire, tune reactively when it generates too many false positives, is too slow for the current threat environment. By the time you’ve finished tuning a rule for last quarter’s threat, new attack patterns are already in the wild. The cycle needs to compress at every stage. Prototype rules should be tested in isolated environments before they reach production. Sandboxes and virtual machines can be spun up quickly in the same pipeline as rule development, giving you a controlled validation environment. Rules that are tuned before deployment don’t flood the SOC on their first day, and analysts who aren’t buried in false positives from new rules are analysts who can actually investigate real threats. Continuous monitoring closes the loop. Every alert that fires, every verdict and every outcome feeds information back into the detection posture. Which rules are generating signal? Which ones are generating noise? Where are the coverage gaps that no existing rule addresses? Without this feedback loop, detection engineering becomes a periodic exercise rather than a continuously improving system. A well integrated feedback loop investigates every single alert a detection creates, resolves false positives from critically important detections while continuously tuning the behavioral model to secure your organization and security detection pipeline. Coverage benchmarks worth using Coverage benchmarks help set realistic expectations and give teams a concrete target. Based on what we see across enterprise environments: Less than 30% MITRE ATT&CK coverage is immature. Organizations in this range typically have out-of-the-box rules, minimal customization, and significant gaps across Initial Access, Execution, and Lateral Movement. 30 to 45% represents a decent in-house SOC. Rules exist, there’s some customization, but detection engineering is not a dedicated discipline and tuning is reactive. 45 to 60% is strong. Dedicated attention to detection posture, some behavioral logic, and active management of the detection lifecycle. 60 to 70% is top-tier. Behavioral detection is primary, coverage is continuously maintained, and the feedback loop between investigation and detection is functioning. Anything above 70% is usually inflated. Scores at this level typically reflect mapping sprawl across multiple MITRE versions, technique-level claims that obscure sub-technique gaps, or rules that are mapped but broken. Validate the underlying data before trusting the number. The goal isn’t 100% coverage. That number isn’t achievable or meaningful. The goal is systematic, maintainable coverage of the techniques most relevant to your environment and your crown jewels, with the sub-technique depth to catch how those techniques are actually executed. How AI changes things for attackers and defenders Mythos focused attention on a specific capability and that is autonomous chaining of exploit steps that previously required human guidance at each stage. A skilled researcher can still walk an LLM through finding a vulnerability, reaching exploit code, and overtaking an instruction pointer, but that process requires human direction at each transition. What makes autonomous chaining meaningful is that it removes the human from the loop on the attacker side. The detection engineering response isn’t a new category of rule. It’s the same disciplines applied with more rigor and at higher speed. Attackers using LLMs are still executing against endpoints, still writing to disk or running in memory, still making network connections, still creating processes. The behaviors are recognizable. What changes is the volume of variants and the speed at which new campaigns emerge. Score-based logic handles volume well because it doesn’t require a rule per variant. Permutation testing handles new variants better than reactive tuning because gaps are found before deployment rather than after. Behavioral coverage handles campaign evolution better than IOC maintenance because the underlying techniques persist even as the tooling changes. This is where an integrated model matters most. AI-powered detection engineering delivers the most value when it doesn’t operate in isolation, and at Intezer it runs on the same loop as automated triage and investigation. The platform investigates 100% of alerts across endpoint, identity, cloud, network, and SIEM, and every verdict feeds directly back into detection, surfacing noisy rules, broken telemetry, and coverage gaps as they happen rather than at the next review. Detection, triage, and investigation reinforcing one another is what produces a fully optimized security environment, one that keeps pace as attacker AI accelerates. The organizations that fare best against AI-powered threats will be the ones that already had a functioning detection engineering program, one built on behavioral logic, continuous feedback, and validated telemetry, before the threat landscape changed. Catching up under pressure is possible, but it’s harder and slower than building the discipline now. The attacker’s AI is getting faster. The detection engineering cycle should be too. Learn more about Intezer’s AI-powered detection engineering.

Introducing Custom Agents: Automate your SOC, your way July 2, 2026 Written by Intezer Intezer already investigates 100% of your alerts and escalates fewer than 2% of them for human review. That part is handled. The work does not stop there, though. Every SOC has its own routines wrapped around the investigation itself. The incident reports written in a particular format, the closure notes, the shift handoffs, the rules that decide who picks up which case. When we looked at how teams actually use AI Chat, our in-product investigation agent, more than a third of those conversations turned out to be the same repetitive tasks asked again and again. The same summaries. The same reports. The same closure notes. Intezer's AI SOC already runs agents around the clock to triage, investigate, and respond to your alerts on their own. Custom Agents is the next step. Now you can shape how that AI SOC works for your team. Add your own agents and automations on top of the ones Intezer runs out of the box, take more of the manual work off your analysts, and tailor the whole thing to the way your team actually operates. Meet Custom Agents Intezer ships with a set of agents and automations that handle triage, investigation, and response from day one. Custom Agents lets you build your own on top of them. An agent is made up of three components: Your instructions A trigger The tools it is allowed to use You describe what you want done in plain language, choose when it should run, and pick what it can touch. It then runs on its own inside your Intezer environment, on the same engine that powers our investigation Agent (Chat). Build an agent in minutes 1. Tell it what to do, in plain language. Write the instructions the way you would brief a new analyst. "Every morning, review the open case queue, close the clear false positives per our playbook, and leave a handoff note on the rest." That is an agent. 2. Choose when it runs. Three trigger types cover most workflows: On a schedule: every day, week, or month. For example, a 9:00 report. On an event: the moment a case is closed, a verdict is set, or an alert meets your conditions. On demand: run it yourself, or call it from the API. 3. Give it the right tools. Agents work across your whole stack which includes Intezer's built-in toolset plus the SIEM, EDR, and identity tools you have already connected, including CrowdStrike, SentinelOne, Splunk, Microsoft Sentinel, and Entra ID. They do more than summarize. They take action by updating, commenting on, closing cases, and emailing a finished report to your team. See it in action Take an Incident Report Writer agent illustrated above. We deliberately never shipped a single "Generate report" button, because no two teams want the same report. One team wants an executive summary up top, another wants the full timeline, another has a compliance format it has to match. So instead of a button, you put your format into the agent's instructions, and it writes every report that way, every time. The agent triggers on every escalated case an analyst has confirmed as a real threat. It reads the case, writes the report in your format, and emails it to your team's inbox. The analyst makes the call. The paperwork writes itself. That's one agent. The point of Custom Agents is that you decide what they are. Nothing runs blind Security teams do not trust black boxes, and they are right not to. Custom Agents is built so you can see and control everything an agent does. Every run is visible. You see the agent's reasoning, every tool call and its result, and the final output. Each run is logged, and you can export it. Test safely with Dry Run. Dry Run executes the agent for real but mocks every write action, so you can watch exactly what it would do before it does anything. Iterate on the instructions until it is right, then turn it on. Guardrails are built in. Action tools are limited by design. An agent can only email active members of your organization, for example. It cannot reach outside your walls. You stay in control. You choose which tools an agent gets, you review its output, and you can switch it off in one click. This is how everything at Intezer works. AI executes, humans supervise. Custom Agents lets you decide what it executes. What security teams are already building with it We opened Custom Agents to a small group of alpha customers, and the best part has been watching what they build. Alongside the Incident Report Writer above, a few of the agents already running in production: SLA Monitor (daily): a morning email listing every escalated case that has been sitting too long, so nothing critical slips past its deadline. Tuning Advisor (weekly): takes the alerts your detection tools fired that Intezer judged to be false positives and turns them into suppression recommendations for the week ahead. Threat Hunter (weekly): proactively sweeps your environment for the latest threats instead of waiting for an alert to fire. It pulls the new malware families, campaigns, and indicators Intezer is tracking, queries your connected SIEM and EDR for matches across historical data, and opens a case for anything it surfaces. Smart Triage and Routing: for organizations with multiple entities, subsidiaries, and stakeholders, the agent reads each case and works out which team should own it, using your own escalation rules. It either leaves a comment with the routing, or assigns the case to the right analyst directly. Analysts stop digging through a separate list or knowledge base to figure out where a case goes. End of Shift Handoff: built to match what a real SOC handover looks like. At the end of a shift the agent compiles the open items, the escalations still waiting for attention, the shift's statistics, and any open system events or configuration issues, then writes the handoff so the next shift starts with the full picture. The AI SOC, built for your team We are on a mission to build the AI SOC the industry has been promised but never delivered. One that does the work and earns the trust to do it. It runs autonomously, around the clock. It works alongside the people who supervise it, not over their heads. And it is never a black box. You can always open it up, question what it did, and change how it behaves. Custom Agents is central to that vision. Triage, investigation, and response come built in. Everything particular to how your team operates, you build yourself. Because the strongest security teams have always run on their own playbooks, their own logic, and their own standards, and an AI SOC should be no different. It should not ship the same to everyone. No two SOCs are the same, and no two should be. That is the point of Custom Agents. You decide what they are. Available now Custom Agents is available now in beta to Intezer customers, and it is free during the beta period. This is the moment to build, test, and tell us what you want it to do next.

The other half of the AI SOC: Intezer, now inside your AI workspace June 18, 2026 Written by Itai Tevet Two kinds of work you want AI to do in a SOC Work you want off your plate. Alert triage is the obvious example: every alert deserves a real investigation, most of them turn out to be noise, and they arrive at 3am as happily as at noon. Nobody wants help with this work. They want it gone. That’s the half Intezer has spent years building. Autonomous triage that investigates every alert at forensic depth, around the clock, and only interrupts a human when something actually needs human judgment. Work you want to keep, but accelerate. Deciding what to do with an escalation. Writing the incident report. Picking apart the weird binary someone found on a build server. Chasing a hunch across five systems. For this work you don’t want a replacement. You want to be a 10x version of yourself. Today we’re shipping the second half. We rebuilt the Intezer MCP server from the ground up, and it turns the AI platform your team already lives in, Claude, Codex, Cursor, or any MCP client, into a full security workspace: your cases, your alerts, file and URL verdicts, live SIEM and EDR telemetry, tuning rules, all of it. We had an MCP server before, and it was a fine way to ask Intezer questions from a chat window. This one is built around a bigger idea: your AI workspace should be able to do everything you can do in Intezer, then combine it with everything else you have access to. If you read our piece on making sense of the 2026 SOC stack, this release is the missing connection between the top two layers. Detection tools are the hardware. The AI SOC is the operating system that turns raw signals into investigated verdicts and institutional memory. AI platforms like Claude are the applications where people actually work. This release plugs the operating system into the applications. Watch one investigation, end to end The video walks through one escalated case, but the pattern behind it is the real story. Intezer's autonomous triage investigates every alert to forensic depth and resolves what it can on its own. What lands in front of a human is the residue. Cases where the technical facts are settled but the decision still needs judgment, usually because it turns on business context no security tool can see. Was this data share authorized? Is this vendor one we actually work with? Escalating those isn't a triage failure, rather it's the line where execution ends and judgment begins. Putting Intezer inside your AI workspace is what makes that handoff productive. Pick up a case in Claude, Codex, or Cursor and you inherit the full investigation Intezer already ran, plus its recommendation, with a partner that can reach the context security tools never had: your email, Slack, the ticket queue. You keep the decision; it does the legwork around you at machine speed, pulling the case, cross-referencing your systems, documenting the verdict, writing a tuning rule. What used to be an afternoon of pivoting between consoles becomes a short, supervised exchange. That's the point of the combination: the autonomous half absorbs the scale, the assistive half carries the judgment, and every call you make feeds back as logic that makes the autonomous half smarter. You're not handing off your work; you're making judgment calls with the context, evidence, and follow-through already assembled around you. The same question, with and without Intezer Same alert, two ways to handle it. On the left, Claude on its own takes the impossible-travel sign-in and works it by hand. It reasons well and gets close. Managed device, MFA passed, probably real travel, but it can't collect evidence from the endpoint to confirm, so the last step falls back to a human checking the laptop. And that's one alert; almost 4,000 more are still waiting behind it. One analyst, one alert at a time, with no way to run it across the whole team. On the right, the same alert inside the AI SOC: Intezer triages every alert around the clock, closes the ~98% that need no action, and escalates only the ~2% that genuinely need a person. Claude is where you pick those up so you can stop grinding the queue and start supervising the few cases that actually need you. Most of the org knowledge an investigation needs is already centralized in Intezer. That's the whole point of the platform. But some context only ever lives with you: a procurement thread in someone's inbox, a Slack message from three weeks ago, a calendar invite. With Intezer connected on one side and your IT and communication stack on the other, your AI workspace can cross-reference both in a single investigation. Why not plug Claude into all security tools directly? You could also wire your AI client straight into each security tool yourself. Most of them ship an MCP these days. Two things make that a worse deal than it looks. First, the integration work is now yours: stitching a dozen connectors together, learning each product's query quirks, and getting back a pile of disconnected results instead of one correlated picture. Second, raw tool access still isn't investigation. With every EDR, SIEM, and intel feed wired in, the model can read your data, but it can't collect evidence off an endpoint, run memory forensics, or weigh conflicting signals into a verdict it will actually stand behind, which is exactly where Claude stalls on the left in above image. Intezer already did both jobs. One connector hands the model a SOC's worth of normalized cases, verdicts backed by real forensic evidence, and cross-tool correlation. An AI platform does its best work standing on a real foundation of security knowledge, not on a dozen raw feeds it has to assemble itself. Investigate and close the cases Intezer escalates to you This is where analyst hours should go, so it's where the MCP goes deepest. Whatever the alert type, the shape is the same: pull the case, build on everything the autonomous triage already found, cross-reference your other systems, decide interactively with you, and close with evidence. And "pull the case" carries real weight here. A case from Intezer is not a bare ticket. It arrives with everything triage already did: the evidence it collected, the SIEM and EDR queries it ran, the forensic analysis of each artifact, the verdicts it reached. You're not starting from a blank page; you're picking up a deep investigation and taking it the last mile. "Pick up the oldest escalated open case and let’s investigate it together." The clip above takes an impossible-travel alert. The MCP brings the full login history including every IP and geo, and who else touched the same address as well as your AI workspace cross-references calendar and Slack for travel context. When the evidence still isn't conclusive, it can ask the user directly and close on their answer, so the one human check that actually mattered takes seconds instead of becoming a follow-up ticket. Make tomorrow's autonomous triage smarter If a case should never have reached you, closing it is half the job. The other half is making sure it never reaches you again. "We keep getting this exact false positive. Write a tuning rule so it never escalates again, then retriage the case." Claude inspects the alert's triage indicators, drafts a narrowly scoped tuning rule, and tests the pattern against the real alert object before proposing anything. It checks whether an existing rule should be extended instead of creating a near-duplicate. It asks the question every detection engineer should ask: could an attacker hide inside this rule? Then it pushes the rule to Intezer for your approval and retriages the affected alerts so the fix applies immediately. Tuning runs both directions, too. The same mechanism can tell the autonomous triage to always escalate a pattern it can't yet call malicious with confidence, so the genuinely ambiguous cases land in front of a human by design, not by luck. This is where the two halves of the AI SOC meet. Every rule your AI workspace writes makes the autonomous half smarter, which means fewer escalations next month, which means the time you spend supervising keeps shrinking. The system compounds. From case to incident report in one prompt When a case turns into a real incident, the hours after containment go to reconstruction: which alerts were related, which machines were touched, what happened first, and what to tell leadership. "Write an incident report for the latest case we worked on with timeline, affected assets, and an exec summary I can send to the CISO." Your AI workspace pulls the case and its full activity trail from Intezer, expands across the users, devices, and IPs involved, and rebuilds the timeline from the forensic evidence already on file. Then it writes the report with an executive summary up top, technical detail below, in your template if you have one, and finally exports it to a clean, brand-styled PDF you can send as-is. The data was always in Intezer; the report was just assembly. Now assembly is one prompt. Threat hunting: start from a lead, not an alert Not every investigation starts in the queue. Sometimes it starts with your CISO forwarding an article about a campaign that's hitting your industry. "Here's a writeup of a new campaign [link]. Check whether any of these IOCs appear anywhere in our environment, and analyze anything you find." Your AI workspace extracts the indicators and techniques from the writeup, sweeps your environment through Intezer's SIEM and EDR query tools, and returns the matching assets, alerts, and artifacts for analysis. When you find something worth a closer look, you can fire deep forensics to go one step further with your hunt. How it works The Intezer MCP server is hosted by us. You authorize over OAuth from any MCP client: Claude (Desktop, Code, or claude.ai), ChatGPT, Codex, Cursor, or anything else that speaks the protocol. Under the hood it exposes 66 tools covering the full case lifecycle: search and fetch cases and alerts, file and URL analysis, live queries against more than a dozen SIEM and EDR products in their native query languages (KQL, SPL, XQL, SDL, and the rest, with per-vendor syntax guides built in so the model gets them right), tuning rules and AI instructions, retriage, and case editing. This architecture is what makes the two halves described above work as one system: the autonomous half clears work off your plate, while the assistive half accelerates the tasks where you still want to stay in the loop. Getting started If you're already an Intezer customer, an Intezer admin creates an MCP OAuth application under Account Settings → MCP OAuth Applications. Add Intezer as a custom connector in your AI client such as Claude, ChatGPT, or any MCP client. Point it at the hosted server, and authorize with your own Intezer login over OAuth. Open with one prompt: ask it to pick up your oldest open escalation. The autonomous half investigates everything, around the clock, so your team only sees what matters. The assistive half makes the time you spend on what matters dramatically shorter. One system of record and detection logic underneath both: your cases, your verdicts, your tuning rules, your institutional memory, working for you whether the investigation runs inside Intezer or inside your AI workspace. AI executes. Humans supervise. And now the supervising got a lot faster too. If you're not an Intezer customer yet, book a demo and we'll show you both halves at once: autonomous triage working every alert around the clock, and a co-pilot that helps your analysts close the escalations that do reach them 10x faster. Itai Tevet Co-founder and CEO of Intezer, Itai is on a mission to revolutionize how SOC teams investigate and respond to cybersecurity incidents. He previously led the cyber incident response team for one of the world's most targeted organizations. Itai combines his expertise in AI and security to advise security leaders at Fortune 500 companies on how to defend against threat actors in the AI era.

This article is based on joint research with Eran Segal, researcher at Kodem Security. The most capable commercial AI models are now useful enough to attackers that they have become an integral part of their kill chain, in multiple steps. The Cybench benchmark tests models on offensive cyber tasks. Its current top performers (Claude Opus 4.6, Claude Sonnet 4.5, Grok 4) can write functional exploit code, reason through credential chains, and sustain complex reconnaissance workflows: multi-step offensive work that previously required human expertise. Malware families are already using this. Instead of generating a payload offline and shipping it, they wire a live LLM API into the malware itself so it can adapt its behavior at runtime on the infected host. Commercial providers run abuse detection and terminate accounts linked to malicious activity. A payment method creates a paper trail that investigators can follow. So attackers solve the access problem the same way they solve any resource problem: they steal it, find it free, or find it unguarded. This post covers five routes threat actors use to reach LLM inference without paying for it: buying offensive models on underground forums, using front-end models using 3rd party LLM service that allows paying in bitcoin, using free-tier or keyless public APIs, hunting for leaked API keys in developer artifacts, and exploiting self-hosted LLM servers left open on the internet. Method 1: Offensive LLMs and Anonymous Payment Cyber-oriented LLMs sold on underground forums are the most visible route. WormGPT, GhostGPT, KawaiiGPT, and Xanthorox are the most cited examples, covered in depth by Unit 42. These are returned open-weight models or jailbroken wrappers over commercial APIs, marketed specifically as having no content filter. They solve the moderation problem but not the cost problem: access is sold on a subscription basis, and the capability ceiling sits well below that of frontier commercial models. So they are useful for generating phishing content or simple malware stubs, but less so for the kind of autonomous multi-step offensive work that the frontier models in the Cybench ranking are capable of. Method 2: Using Frontier Models Through a Third-Party Service If a threat actor would like to use the frontier models to achieve top performance, they can still use these models using 3rd party services such as PayWithMoon and AIMLAPI. These services sit between the attacker and a commercial LLM provider, accepting cryptocurrency without identity verification and then funding a legitimate provider account on the attacker's behalf. The account itself reaches frontier models, but the funding trail stops at the middleman. The account will still get burned once abuse detection triggers, but replacing it is cheap. The upstream provider has no usable identity to pursue. This is how attackers buy frontier-model access while skipping the paper trail a normal commercial account would leave behind. Method 3: Free-Tier and Keyless Public Inference APIs A cheaper alternative to underground subscriptions exists in plain sight. Most major inference providers publish permanent free tiers that require nothing more than a disposable email address, and a handful of services accept requests with no credentials at all. An attacker who registers for a pool of free-tier accounts gets as meny tokens as he wishes without paying a dime. The scale of the free-tier ecosystem is easy to measure because the community has cataloged it. Public curated lists such as cheahjs/free-llm-api-resources and mnfst/awesome-free-llm-apis explicitly filter for providers that offer a permanent (not trial-credit) free tier with no credit card. Representative entries, with numbers pulled from each provider's own rate-limit documentation: Groq: 30 requests/minute (RPM) on all free-tier models, with requests/day (RPD) caps ranging from 1,000 (for the 70B llama) to 14,400 (for the 8B llama). Cerebras: 30 RPM, 14,400 RPD, and roughly 1M tokens/day on three of the four free-tier models (gpt-oss-120b, llama3.1-8b, qwen-3-235b). Cohere: 20 RPM on the Chat API and a hard cap of 1,000 total API calls/month on a trial key. Mistral La Plateforme: 1B tokens/month on the Experiment plan. No credit card is required, but a verified phone number is required, which is the highest sign-up friction in this group. HuggingFace: Free accounts are rate-limited on both the Hub API and the Inference API per 5-minute window. Anonymous per-IP access exists but is stricter than the free-account path. OpenRouter: 50 free model RPD with no deposit at all, and 1,000 RPD after a one-time $10 top-up that is never spent against model usage. SambaNova: 20 RPM and 20 RPD, with a 200,000 tokens/day cap. The tightest daily request ceiling in this group by a wide margin. These providers differ in rate limits, models, and throughput. What they share is that a usable credential requires nothing more than a disposable email address (a phone number in Mistral's case) and no payment method. Credentials can simply be rotated when limits are reached. The fully keyless end of the spectrum is thinner, but it exists. Pollinations.ai exposes an OpenAI-compatible endpoint that accepts requests with no authentication for basic use. DuckDuckGo's Duck.ai anonymizes browser-based access to Claude 3.5 Haiku, Llama 4 Scout, Mistral Small 3, GPT-5 mini, and GPT-4o mini with no account at all. These services are not designed for bulk programmatic use, but they are reachable from any HTTP client, and the only cost is rate-limit friction. Among the malware families in the intro table, LameHug/PROMPTSTEAL is the cleanest example of this route in the wild: it calls HuggingFace's Inference API for Qwen 2.5-Coder-32B-Instruct to drive reconnaissance and data theft, with no embedded credentials reported by Splunk. Whether the malware carries a token or registers one at runtime is not established, but either way, the enabling property is HuggingFace's no-credit-card free tier. Method 4: Exposed API Keys The fourth route to free model access doesn't require finding an exposed server at all. Developers routinely hardcode credentials directly into apps, config files, and scripts. These credentials can be found in GitHub in open-source projects, while closed-source projects contain the credentials in the app itself. These artifacts are submitted to VirusTotal when apps are submitted for malware analysis. It can be an APK, ELF, EXE, or any type of artifact shipped with the product. To find them systematically, we wrote a YARA rule targeting the key formats of the major AI providers: Google Gemini (AIzaSy…), OpenAI (sk-…), Anthropic (sk-ant-…), HuggingFace (hf_…), Replicate, Mistral, Cohere, Groq, and several others. We ran the rule as a retrohunting query across the VirusTotal corpus, collected the matching sample hashes, then pulled the raw files and ran a regex extraction pass to extract every key-value pair, provider, and surrounding code context. From there, we enriched each sample with VirusTotal metadata to understand detection rates and file types. The final step was validation: a lightweight GET request against each provider's model-list or whoami endpoint. No prompts sent, just a check of whether the key authenticates. The corpus yielded 647 unique keys across all providers. Roughly 62% were Google Gemini (AIzaSy…) keys. That concentration traces back to the Android developer ecosystem, where apps built for translation, search, or chatbot features commonly bundle the key directly in compiled resources or Java code. HuggingFace keys made up about 11%, Replicate about 8%, OpenAI sk- keys about 7%, and the remaining share was split across Voyage (5%), Mistral (3%), and Cohere (3%), with trace amounts of Anthropic, Groq, and OpenAI environment-style keys. The Mistral and Cohere keys concentrated heavily in a single file: a cracked "Collins Italian Dictionary MOD" Android APK that bundled 20 Mistral keys and 15 Cohere keys alongside 2 Gemini keys, with the small remainder scattered across two versions of a Ubisoft game APK. About 65% of the 659 unique samples are confirmed Android by VirusTotal's type classification. Another 18% are ZIP archives that follow the same submission pattern but were not explicitly tagged as Android. The true APK share sits between 65% and 84%. The remainder consisted of Windows PE files (5%), HTML pages, Python scripts, plain-text credential dumps, and a handful of Mach-O and ELF binaries. That Android skew isn't surprising. APKs are frequently submitted to VirusTotal for modding and repackaging, and their keys remain intact after decompilation. We submitted research samples to Intezer Analyze for code-based attribution, and three entries stand out. Four samples whose filenames suggested Akira ransomware are three Mimikatz binaries (1, 2, 3) and one malicious binary without family attribution, all credential-dumping tools that happened to carry API keys. The sample with a HuggingFace key is SolarMarker, an SEO-poisoning backdoor with infostealer capability. A Windows binary named SystemSettings.exe contained OpenAI, Replicate, and Voyage keys; the multi-key combination is more consistent with theft from a developer's machine than with intentional hardcoding. When we ran the validation, almost all the keys were dead. The revocation rate was approximately 99.5%, consistent with a corpus skewed toward older samples that had been on VirusTotal long enough to be detected, rotated, or simply expired. The small fraction that remained live consisted entirely of Google Gemini keys from Android APKs. All appeared to be genuine developer mistakes rather than exfiltrated credentials: a key embedded in a const in bundled JavaScript, one in a logging module in a compiled Android class, and one in a utility app's APK resources. Those three keys have been reported to Google. The method also illustrates why embedding API keys in client software is a particularly bad idea. Extracting a key from an APK requires a decompiler, and APKs have a reliable path to VirusTotal: users submit them for malware checks, repackaged versions circulate through third-party stores, and cracked builds get flagged automatically. The near-total revocation rate strongly suggests that LLM providers scan VirusTotal for their own key formats and automatically revoke matches. The three keys that were still live were all recent submissions, not yet caught by that sweep. If that pipeline exists, embedding a key in client-side code is not just a security mistake, but a futile one, and the key will likely be dead before it can be abused at scale. The takeaway for an attacker is that hunting VirusTotal for hardcoded keys is low-effort but low-yield. The more durable access method is the exposed LLM server. A server running vLLM (a popular open-source LLM inference framework) or an open Ollama instance requires no authentication, doesn't rotate anything while in use, and the owner usually doesn't know it's happening. Method 5: Hack Public LLM Hosting Servers Self-hosted LLM platforms make it easy to run your own models on your infrastructure, and that same ease extends to anyone who can access the port. Most ships have no authentication by default and expose administrative endpoints that let a stranger list installed models, queue inference jobs, load new models from remote URLs, or, in several cases, execute code on the host. When the server is exposed to the public internet, the attacker does not need a stolen key or a forum subscription. The victim is paying the GPU bill, carrying the API-key spend, or hosting the RCE. We scanned roughly 4,500 hosts across eleven of them. Every service had open instances, and 14 LocalAI hosts showed active compromise based on attacker-loaded model names consistent with a single automated campaign. The sections below cover what each platform is, how exposure gets abused, and what the scan found in the wild. Ollama Ollama runs open-weight LLMs locally. By default, it binds to 127.0.0.1, and the authentication is disabled. But setting OLLAMA_HOST=0.0.0.0 is a common step when accessing it from another machine on the network or from a frontend app running in a separate container. It exposes all interfaces, and anyone reaching it’s port gets full API, model management, and hardware access. SentinelOne Labs and Censys already published the definitive survey, documenting 175,000+ hosts chained into anonymous AI networks for free text, embedding, and bulk content generation on victim hardware. That pattern is now commercialized by Operation Bizarre Bazaar, which sells subscription access to a unified LLM gateway fronted by stolen Ollama endpoints, turning ad-hoc LLMjacking into a growing concern. LocalAI LocalAI is an OpenAI API-compatible model server supporting LLMs, image generation, speech, and transcription. Authentication is disabled by default. It also supports remote model installation, P2P distributed serving, and a built-in agent platform with support for MCP. Of all the services in this research, it has the widest attack surface. Of all the hosts scanned, 55% were confirmed open, the highest absolute count in this group. About 24% are API proxies with live upstream keys for OpenAI, Anthropic, and Google accessible to anyone who can reach the host. The most striking finding is evidence of automated exploitation at scale. About 21% of confirmed hosts carry model names with a consistent signature tied to ProjectDiscovery's nuclei scanner templates, with per-run timestamps mapping to late March and early April 2026. The pattern is consistent with automated scanning for an unauthenticated remote code execution path, in which a malicious URL supplied during model installation triggers server-side code execution. The exploit payload appears to load a small publicly available Italian-language model as a "hello world" confirmation, which recurs on every affected host. The markers not being cleaned up argue against mature attacker tradecraft. Operators running LocalAI can open /v1/models on their own host: any nuclei-rce-* or rce_ identifier is not human-chosen and indicates this campaign hit them. Langflow Langflow is a visual builder for multi-agent AI pipelines, widely used to prototype RAG systems and chatbots. Flows routinely embed hardcoded credentials: OpenAI and Anthropic API keys, database connection strings, Slack tokens, and webhook secrets. Anyone who can reach the host and read a flow config has all of them. Unlike the previous examples, this app does not have a known major misconfiguration, but it does not prevent attackers from being able to hack and gain access to this service. For example, two unauthenticated RCE bugs make reaching the config trivial: CVE-2025-3248:on the CISA KEV list, reliably patched only in 1.6.4+ CVE-2026-33017: fixed in 1.9.0, exploited in the wild within 20 hours of disclosure. Every confirmed host in our scan ran a version vulnerable to CVE-2026-33017; about 72% were also vulnerable to CVE-2025-3248. Several hosts didn’t authenticate at all, with flows, credentials, and both RCE paths openly accessible. Code execution on the Langflow host is the small prize. The keys inside the flows pivot to everything the workflows connect to. n8n n8n is a low-code workflow automation platform with 400+ service connectors and code execution nodes (workflow steps that run arbitrary scripts). It has the strongest default auth posture of any service in this research: User Management is enforced on fresh installs. But it does not prevent attackers from actively gaining access to n8n. Vulnerabilities such as CVE-2026-21858 ("Ni8mare", CVSS 10.0, fixed in 1.121.0), which is a vulnerability in the web hooks request handling that turns exposed endpoints into a full unauthenticated RCE surface via content-type confusion, with a public PoC already out. Prior research estimates the exposed n8n population at tens of thousands of hosts. The post-exploitation story mirrors Langflow. Workflows carry hardcoded API keys, database connection strings, and webhook secrets. RCE on the n8n host effectively gives access to every system the automations touch. vLLM vLLM is a high-throughput LLM serving engine with GPU acceleration, commonly used to self-host open-weight models in production. It exposes an OpenAI-compatible REST API. Authentication requires an explicit --api-key flag; without it, the API is open. The interesting finding from our scan was not vLLM itself but the adjacent deployments surfaced by the same query: OpenAI-compatible HTTP proxies, specifically LiteLLM-style gateways that aggregate multiple paid providers behind a single endpoint. These proxies store live API keys for OpenAI, Anthropic, Google, Groq, and Cohere. None had protection on the model list endpoint. One host exposed 35 models across multiple providers; several listed exclusively Anthropic Claude models. A proxy returns a model list only when the upstream provider authenticates, so every successful response confirms the underlying keys are live and billable. The abuse path is trivial: point any standard OpenAI SDK client at the proxy, enumerate the models, and, on hosts where prompt submission is also unprotected, send requests billed to the operator's accounts. It is the same credential-pivot pattern as Langflow and n8n. ComfyUI ComfyUI is a node-based workflow UI for Stable Diffusion, video generation, and multimodal image models. It runs on high-end GPU hardware with no authentication by default, making it a direct target for attackers looking to steal GPU compute. Our scan found open instances across a wide range of versions (v0.2.2 to 0.19.0), all of which were fully unauthenticated. The hardware exposure is the headline finding. Open hosts reported a combined ~4.3 TB of GPU VRAM, with cards ranging from RTX 4090s and RTX 5090s to datacenter-grade A100S and L40S units, each worth tens of thousands of dollars. An attacker can queue generation jobs against any of them at no cost. Beyond compute theft, 95% of open hosts expose a job history endpoint that leaks previously executed workflows, local file paths, and prior user content. About 12% advertise URL-loading nodes that act as server-side request forgery primitives: usable for internal network reconnaissance or cloud metadata credential theft. llama.cpp server llama-server is the HTTP server shipped with llama.cpp, commonly used to serve a single open-weight model in production. It has no authentication by default, no access controls on the inference endpoint, and a metadata endpoint that advertises exactly what the host is running. Anyone who reaches the port can submit prompts, watch active jobs, and burn the operator's GPU on their own workload. Classic LLMjacking, with the bonus of knowing exactly which model they are running. Of scanned hosts, 59% were confirmed open, more than any other platform in the scan. Everyone exposed its model name and hardware configuration, and about 37% also leaked real-time job state, confirming the host was actively serving users at the time of the scan. The models observed were standard open-weight builds rather than anything exotic, which is the point. An attacker is not looking for a rare model, just an unattended GPU. Jan Jan is an Electron desktop AI app with an optional OpenAI-compatible API server on port 1337. When enabled, it binds to all interfaces with no authentication. Jan is a useful example of how exposure surfaces unexpected content rather than how common it is. Our scan confirmed only two genuine Jan hosts. Both had gone offline by the rescan a week later. While one was live, it exposed a 35-model library that included miqu-70b; a leaked Mistral Medium prototype that was never officially released. When a desktop app binds its API server to the public internet, whatever model (or file path metadata) sits on the operator's disk becomes visible. Gradio Gradio is a Python framework for building ML demo apps: image classifiers, code interpreters, document Q&A, or anything a researcher can wrap in a web UI. Exposure risk depends entirely on what the underlying app does. A sentiment-analysis demo is low-stakes. An app that accepts file uploads, runs user code, or queries a database is a direct path to exploitation. The Gradio queue keeps processing submitted requests whether the operator is watching or not, so abuse can run quietly for days. Three unauthenticated bugs make unpatched instances worse: CVE-2024-47084: CORS validation bypass, fixed in 4.44.0; a malicious website can reach a locally running Gradio server while the victim is still logged in Ranking the Five Routes Each route carries operational trade-offs. The table below scores each on five dimensions, ranging from 0 (least favorable) to 5 (best for attacking): non-resistance (refusal behavior in response to offensive prompts), model capability (coding ability and parameter count), tool and MCP support, and effective token quota. Offensive LLMs score highest on non-resistance. But the underground-forum variants sit well below frontier models in capability and tool support, and subscriptions cap the quota. The crypto-middleman variant reaches frontier models via real provider accounts, but those accounts burn quickly once abuse is detected. Crypto payment for frontier models is for sure the best way to gain access for the most capable models with the ability to connect the model to any interface, such as MCPs, but it comes with some risks that the model might resist the action or the user will be blocked. Free-tier and keyless public APIs score well in capability and tool support, with full-function calling across most providers. The per-account quota is modest, tens of RPM, thousands of RPD, but trivial account rotation pushes the effective quota well above the face value. Stolen or leaked API keys, in principle, offer the best combination of capability and tool support; the retrohunt's 0.5% live rate shows the real-world quota is near zero. Exposed LLM servers score highest on non-resistance and token quota. Non-resistance is unconstrained: the attacker controls model selection, and our scan found at least one LM Studio host actively serving llama3.3-8b-instruct-thinking-heretic-uncensored-claude-4.5-opus-high-reasoning-i1. Token quota is equally unconstrained, bounded only by the victim's hardware rather than a billing cap. Capability and tool support vary by host, but that variance is what makes the route durable at scale. No individual host needs to run a frontier model. The scoring explains why exposed servers are the most durable route, even though they don't top every dimension. They are the only route where non-resistance and token quota both max out. The other three are each compromised on at least one of those two axes. Cases Found in the Wild Threat actors are now wiring malware to live LLM APIs, using them to generate malicious logic at runtime rather than embedding static code in the payload. Instead of scripting separate execution flows for different host conditions, the malware queries an LLM while running, determines whether the target appears to be a personal machine, a server, or an industrial controller, and then generates tailored commands or code accordingly. This shift matters because dynamically generated logic has no fixed signature to detect. Researchers have identified five malware families doing this. MalTerminal and PROMPTFLUX both use a hardcoded API key to connect to a commercial provider when needed. MalTerminal uses OpenAI GPT-4 via the now-retired chat-completions endpoint to create reverse shells or ransomware. PROMPTFLUX connects to Google gemini-1.5-flash-latest to rewrite its own VBScript source code between runs, making it harder to detect. LameHug, also known as PROMPTSTEAL, uses HuggingFace's Inference API to run Qwen 2.5-Coder-32B-Instruct for Windows commands to support reconnaissance and data theft. HuggingFace requires an API token for each request, but free accounts don't need a payment method and allow a few hundred requests per hour per API token. Attackers can easily create and rotate these API tokens, giving them the same access as stolen keys but with less hassle. PROMPTLOCK is a proof-of-concept AI-powered ransomware prototype, often called "Ransomware 3.0," developed by researchers at NYU's Tandon School of Engineering. The Go binary invokes gpt-oss-20b via a local Ollama API running on the infected host to generate Lua scripts that perform file listing, encryption, exfiltration, and (unfinished) wipe logic. This is a bring-your-own-model: no outbound calls, no provider-side billing trail, and no way to scale beyond the victim's own hardware. QUIETVAULT is a credential-theft variant. The JavaScript stealer exfiltrates GitHub and NPM tokens to an attacker-controlled GitHub repo and then hands off the filesystem search for additional secrets to whatever AI CLI is already installed on the victim, so the stolen credentials are an active on-host AI session rather than a bare API key. Looking at the four main routes discussed in this post, LameHug/PROMPTSTEAL is the best example of the free-tier method, since it calls HuggingFace's Inference API directly. MalTerminal and PROMPTFLUX both use hardcoded API keys, but it's unclear where those keys came from, so they could fit into the free-tier, crypto-middleman, or stolen-keys categories. QUIETVAULT is a twist on the stolen-credential method, using an on-host AI session instead of just a key. PROMPTLOCK is different because it uses a local model and only works on one victim at a time, so it doesn't fit into the four main routes and isn't discussed further. Across four routes: offensive LLMs for sale, free-tier and keyless public APIs, hardcoded keys in distributed artifacts, and exposed LLM servers on victim infrastructure, the most durable access is the last one. The precondition for abuse is almost never a sophisticated exploit. It is an unauthenticated port facing the internet. AI is the defining technology of this moment. It extends what a single person or small team can do and accelerates work that used to take weeks. AI is being integrated into more and more areas, from personal agents and email writing to some vulnerability research. The wow factor is real. But an LLM server is still a service running on a host. It listens on a port, speaks a protocol, and has an attack surface. The failure modes in this report; misconfiguration, leaked credentials, unpatched CVEs, open ports, are the same ones that produced years of incidents on Docker, Kubernetes, cloud storage, Redis, Elasticsearch, and bare Linux servers. The tooling is new. The mistakes are not. Two things follow. The operator is still responsible for the basics: authenticate the service, keep it off the public internet unless there is a reason to expose it, patch the known CVEs, and audit what is running. These are not AI-specific requirements. They are the same ones we have been making for every networked service. An exposed Ollama instance serving a stranger's prompts is not a failure of the model or the vendor that shipped it. It is a failure of whoever put it on the internet without a password. You broke it. You pay for it. IOCs Nicole Fishbein Nicole is a senior security researcher and malware analyst at Intezer. Prior to this, she was an embedded researcher in the IDF Intelligence Corps.

Gartner's research note, The Impact of AI on MDR Services, arrives at a moment when the security operations landscape is shifting faster than most organizations realize. The report's central argument is clear. AI is fundamentally reshaping what MDR services can deliver, but the benefits are accruing unevenly. Service providers gain operational efficiency. Buyers, meanwhile, are being told not to expect lower costs, and to brace for a more complex relationship with their providers. For CISOs navigating this transition, the question is no longer whether AI will change the SOC. It is whether the current service model is the right vehicle for that change. What Gartner is really saying Gartner's analysis centers on three impacts. First, AI-enabled MDR services will expand capabilities and claim higher quality, but organizations will face real discrepancies in delivered value across providers. Second, the cost savings that leadership expects from AI in the SOC will largely go unrealized, since MDR providers will absorb efficiency gains rather than pass them through as lower prices. Third, and perhaps most significant, more organizations will consider insourcing MDR functions altogether as AI tools mature. That third point deserves attention. Gartner explicitly notes that advances in AI SOC agents and existing security tools are "increasing the security team's internal competition for traditional MDR services." In other words, the technology that once justified outsourcing detection and response is now making it feasible to bring those functions back in-house. The report also strikes a cautious tone about trust. It warns that SOC managers become frustrated when their only option is to "talk to an AI chatbot instead of a live person or security engineer." And it urges buyers to demand transparency with verified outputs, human validation of AI findings, and measurable improvements in speed and accuracy. These are not minor caveats. They point to a structural tension at the heart of the AI-augmented MDR model. The tension Gartner identifies, and where it leads Gartner's recommendations to buyers are telling. They advise organizations to challenge MDR providers to demonstrate tangible value, to refuse machine-driven deliverables that lack context, and to refactor service metrics so they measure actual outcomes rather than volume of AI-processed alerts. The message, read between the lines, is that AI in the hands of an MDR provider benefits the provider first. This is a reasonable observation, but it raises a deeper question. If the primary advantage of AI accrues to the service provider's operational efficiency, and the buyer still needs to invest in internal staff, updated processes, and careful oversight of the provider's output, then what exactly is the buyer paying for? Gartner stops short of answering that question directly. It recommends that organizations "do the research" to determine whether an AI tool or an MDR service better matches their needs. It even suggests that for certain use cases, like after-hours coverage with no remediation requirement, an AI tool may be sufficient on its own. The case for a different operating model At Intezer, we believe the answer to Gartner's implicit question is becoming clearer by the quarter. The MDR model was built for a world where skilled analysts were scarce and automation was rudimentary. In that world, outsourcing triage and investigation to a provider with deeper expertise and broader staffing made sense. But AI has changed the economics and the capabilities. What organizations actually need is not a service that wraps AI around a human-labor model. Organizations need AI that executes investigation at a depth and scale that was never possible with human analysts alone, while keeping the security team in control of outcomes. That means every alert is investigated at forensic depth. It means transparent, evidence-based verdicts that analysts can verify and trust. And it means the security team supervises the AI rather than managing a vendor relationship. Gartner's insistence on transparency and measurable outcomes aligns with this direction. When the report warns against tolerating "machine-driven deliverables" without context, it is describing the exact failure mode of bolting AI onto a legacy service model. The alternative is an AI SOC platform that makes its reasoning visible, produces evidence behind every verdict, and earns trust through verifiable results rather than vendor assurances. What this means for security leaders Gartner's research validates what many CISOs are already experiencing. The MDR relationship is becoming more complex, not simpler. Costs are not coming down. And the organizations that are moving fastest are the ones exploring how AI can augment their own teams directly, not just enhance a provider's backend operations. The practical path forward is not about choosing between AI and human expertise. It is about choosing an operating model where AI handles the investigative work that humans cannot scale, while analysts focus on the judgment calls, escalations, and strategic decisions that require human context. That is the model Gartner's data points toward, even if the report frames it as a future possibility rather than a present reality. For organizations still early in this transition, the Gartner report offers a useful framework. Demand transparency. Measure outcomes, not activity. And ask the hard question about where AI-driven value should live: inside a provider's margin, or inside your own SOC. Learn more about how Intezer AI SOC delivers can help your SOC maximize the benefits of AI combined with human supervision.

OrBit (Re)turns: Tracking an open-source Linux rootkit across four years of forks and deployments May 14, 2026 Written by Nicole Fishbein In July 2022, we published the first analysis of OrBit, a then-undocumented Linux userland-rootkit that stood out for its comprehensive libc hooking, SSH backdoor access, and PAM-based credential harvesting. At the time, OrBit appeared as a single sample with a single operator fingerprint, and the codebase itself looked customized. It wasn't. As we will show below, OrBit is a repackaged and selectively weaponized build of Medusa, an open-source LD_PRELOAD rootkit published on GitHub in December 2022. The story of OrBit's four-year evolution is not one of novel development; it's the story of how a publicly available rootkit was forked, configured, and redeployed. Nearly four years later, OrBit is still in the wild, and it has not stood still. Hunting across VirusTotal, we pulled more than a dozen samples spanning 2022 through 2026 and walked each one through static and differential analysis. We discovered two parallel lineages: a full-featured "Lineage A" build that tracks closely with the 2022 original, and a lite "Lineage B" fork that drops entire capability domains (PAM, pcap, TCP-port hiding) in exchange for a smaller footprint. Along the way, the operators rotate XOR keys, shuffle install paths, swap backdoor credentials, add auditd-evasion hooks, and eventually bolt on a service-side PAM impersonation primitive. This blog picks up where the 2022 analysis left off. We focus on what changed, when, and why it matters for defenders. For each epoch, we enumerate the samples, call out the lineage, and break down the meaningful changes: credential changes, hook-set diffs, new evasion behavior, and operator tradecraft. Background: What is OrBit? For readers unfamiliar with the original analysis, OrBit is a Linux userland-rootkit deployed as a shared library (.so) that achieves persistence by patching the dynamic linker, specifically modifying ld.so to ensure the malicious library is loaded into every process on the system. It operates as a passive implant with no command-and-control communication; instead, the attacker connects in through an SSH backdoor. Once installed, OrBit hooks into PAM functions to harvest credentials from SSH and sudo authentication attempts, storing the captured passwords locally. Its evasion capabilities are comprehensive, hooking over forty libc functions to hide files, processes, and network connections from administrators and security tools alike. The malware stores its harvested credentials and configuration data in /lib/libntpVnQE6mk/, a directory that remains invisible to standard enumeration thanks to the rootkit's own hooks. July 2022 We will refer to this variant as Lineage A "Full" build of OrBit. OrBit variants through the years In our research, we collected samples from VirusTotal. Unlike PE files, ELF files don’t include a compilation timestamp, so we started by aggregating the samples by the date they were submitted to VirusTotal. To track the samples on the blog, we use the first 8 characters of each sample's SHA-256. At the bottom of the blog, you can find the full list of IOCs. December 2022 The first version shows a slight change: the username and password for the SSH connection, and the exported functions. Credential mechanism shift: 40b5127c resolved the backdoor username dynamically via the getpwuid hook; ec7462c3 dropped that hook entirely and hardcodes adm1n directly in the XOR-encrypted string table. The working folder was changed to libseconf. For the most part, the later variants will use this path. All other capabilities are identical: file I/O interception, stat hiding, PAM credential capture, TCP port hiding (alloc_tcp_ports/remove_port/tcp_port_hidden), load monitoring (.showload/.maxload), pcap sniffing, LD_PRELOAD management, log suppression, and process hiding. The transition from 2022 to 2023 is essentially a redeployment with new credentials and a more convincing install path, plus a minor simplification (dropping dynamic UID lookup in favor of a hardcoded username). The rootkit's hook surface stayed stable. Samples From 2023 The d419a9b1 sample stands out for the operator's choice of the install path (/lib/fuckwhitehatshome/) and the SSH username and password. No other known samples use these strings, suggesting a different operator or persona authored this particular build rather than it simply being a different deployment of the same toolkit. Functionally, it carries the full 2022-era hook set, with 65 exports. The 296d28eb sample is a full-featured build that uses the libseconf path and the same SSH credentials as ec7462c3. But this sample also has an evolutionary step: dropped TCP port hiding, added the exported xread function. This is not an LD_PRELOAD hook on a system library; it's a wrapper that calls syscall(SYS_read) directly, bypassing the rootkit's own hooked read(). The rootkit hooks the libc read() function; the hook filters out rootkit artifacts from files such as/proc/net/tcp and directory listings. Some C programs, such as Git, define their own internal xread() helper that wraps read() to handle partial reads and EINTR. Normally, these internal helpers call libc read(), which the rootkit intercepts and filters. By exporting its own xread, which directly calls syscall (SYS_read), the rootkit shadows these program-internal helpers with a version that bypasses its own read hook entirely. This is a compatibility fix: without it, any program that defines xread would receive the rootkit's filtered output through its core I/O path, potentially corrupting SSH protocol streams, breaking git operations, or causing other malfunctions that could expose the rootkit's presence. The hook ensures that programs continue to function normally while the rootkit's read interception remains active for standard libc callers. Both files, 3ba6c174 and 4203271c, represent the first appearance of Lineage B, a deliberately lite fork of the OrBit rootkit. Both are dynamically linked shared objects using the standard 0xA2 XOR key and installed in /lib/libseconf/, but they export only 54 functions, compared to the 67 in their closest Lineage A contemporaries (d419a9b1, ec7462c3). The 13 removed exports strip out three entire capability domains: network port-hiding (alloc_tcp_ports, remove_port, tcp_port_hidden, clean_ports), PAM credential interception (pam_authenticate, pam_acct_mgmt, pam_open_session, pam_get_password), and packet capture (pcap_loop, pcap_packet_callback). The string table reflects this (.logpam and .udp are absent), though .ports, .hosts, and sshpass2.txt are retained. This reduced feature set suggests they were purpose-built for different target environments where a smaller footprint or more limited functionality was either sufficient or preferred. The most notable change is the complete absence of a backdoor password. Every Lineage A sample embeds a password in its XOR-encrypted string block, but in both 3ba6c174 and 4203271c, the password field is missing. Each sample carries a distinct username (adm1n and b4ph0m3t0, respectively), and these are the only byte-level differences between the two binaries. This pattern of 54 exports, no password, no PAM/pcap hooks, held consistent across all subsequent Lineage B samples through 2024. Samples From 2024 2024 is the most diverse epoch in OrBit's timeline, with both lineages active simultaneously and an encryption key change in the Lineage A branch. eea274ed / a6138638: Lineage A, 0xAA key rotation These two samples belong to the same lineage: identical XOR key (0xAA is a break from the long-standing 0xA2), identical credentials (Y0u4reCu6e / 1qaz@WSX3edc123), and identical hook count (54). The only structural difference is the install path: /lib64/libseconf/ versus /lib/locate/. This is probably a deliberate path rotation to evade detections anchored on the previously documented /lib/libseconf/ directory. Credentials are stored inline in the XOR-encrypted block rather than written to sshpass.txt, representing a shift in the credential storage model. Both samples also have a reduced hook for the' execve' function: the execve hook handles persistence maintenance (apt/yum), output sanitization (dmesg), and ldd defeat. Compared to other samples in the lineage, it is a reduced feature set: no strace interception, no IP/iptables hooks, no command logging. Despite sharing the same hook count, the two samples do not share the same hook set. a6138638 swaps read/write for readdir_r/readdir64_r, indicating a targeted adjustment to the directory-hiding mechanism. A string-level diff reveals more changes: Credential harvesting is saved in remote.txt. This variant captures only SSH logins, not sudo sessions ([sudo] pass is missing). The result is 52 decoded XOR strings in eea274ed versus 47 in a6138638. Both samples retain .udp, .pts, and the credential pair, preserving the core backdoor functionality. The removals target logging and forensic-capture features, suggesting a6138638 was tailored for a deployment where a lighter footprint was preferred. a34299a1 / b1dd18a6 / 989f7eb4: Lineage B continuation These samples continue the 54-export lite build lineage that first appeared in 2023 with 3ba6c174/4203271c. The hook set is identical (49 hooks), the XOR key remains 0xA2, and the same capability domains are absent: no PAM credential interception, no pcap sniffing, no TCP port hiding. The password field is still missing from the binary. Each sample carries a distinct username (rebel, Gestuff, adm1n, respectively), consistent with the Lineage B pattern of per-deployment username rotation, with no corresponding password. 989f7eb4 is the payload extracted from the 48a68d05 dropper. It was not on VT; we uploaded it. Samples From 2025 The 2025 epoch marks two significant capability additions to Lineage A and confirms the rootkit's return to the 0xA2 encryption key after the 2024 0xAA experiment. Two distinct rootkit .so builds are present in 2025, both Lineage A: 8e83cbb2 represents the most capable build to date. Its 66-export set includes a significant new hook not seen in any prior variant: pam_sm_authenticate. This is the PAM service-side authentication function, meaning the rootkit now hooks both sides of the PAM stack. Where earlier variants could only passively capture credentials via client-side pam_authenticate, this build can also forge authentication outcomes, allowing the attacker to approve or deny login attempts at will. The export set also includes xread, first seen in 296d28eb (2023). 2b2eeb22 is a second Lineage A payload with 64 exports. XOR 0xA2 decode confirms credentials adm1n/asdfasdf, the same operator behind ec7462c3 (2022), 296d28eb (2023), and the 26082cd3 inner payload (2024), now spanning four years. 84828f31 is a truncated copy of 2b2eeb22 (same BuildID: cbc9724027399723a27daa4114ffcdf906cb802f, identical bytes up to 107KB, missing the trailing 102KB containing section headers and symbol tables), it is likely an incomplete extraction or download artifact. It is not a distinct sample. XOR 0xA2 string decode of both payloads confirms the full Lineage A string set is restored: sshpass.txt and sshpass2.txt both present, plus .logpam, .udp, .ports (×2), /proc/net/tcp. The string removals introduced by the 2024 0xAA cluster (a6138638's missing local.txt, sniff.txt, etc.) were not carried forward, and both builds return to the comprehensive logging and credential-capture model. Dropper Samples 090b15fd, 64a3ebd3, and b85ed157 are statically linked ELF executables that carry 8e83cbb2 as an embedded .so and share the same Build ID: da256c78910c552eb334814ada85c7655b717c4f. d3d204c1 is the same type of dropper carrying 2b2eeb22. All four share the same architecture first seen in f1612924 (from 2022). 73b95b7d: A New Dropper Architecture 73b95b7d is not just a dropper, it is an infector that carries the dropper as an embedded payload. This creates a two-stage delivery chain: infector → dropper → rootkit. The inner binary (090b15fd, embedded at file offset 0x20d7) is the dropper we previously saw. The infector's role is propagation and persistence; the dropper's role is to extract and install the rootkit .so via ld.so.preload. The infector scans the filesystem for ELF binaries and injects the second-stage payload into them. An infection marker bongripz4jezuz (stored in base64 encoding as: Ym9uZ3JpcHo0amV6dXoK) is checked before each infection attempt to avoid re-infecting the same target. The injected binaries include: /bin/ls All 64-bit ELF files in the current working directory that have read/write access. Additionally, /etc/cron.hourly/0 is created as a persistence mechanism (to download and execute a remote payload), though it is a shell script rather than an ELF injection target. This is the first OrBit component with any form of C2 communication. Every previous version was a purely passive implant, meaning the attacker connected via the SSH backdoor. This introduces an external command channel that can deliver updated payloads or instructions, adding a reinfection mechanism on top of ld.so.preload persistence. The earlier droppers stored all paths and commands as plaintext. 73b95b7d is the first dropper to implement string protection: a custom substitution cipher using two lookup tables at .data offsets for the cipher and plain, each with 88 entries, defining a character-by-character mapping. Notably, this is a different scheme from the XOR encryption used by the previous rootkit payloads. The structure of this dropper, which delivers the OrBit payload in the final stage, is identical to that described in this APNIC blog that analyzed a dropper that delivered RHOMBUS malware. Rhombus is a Linux-based botnet malware first reported in February 2020 by the MalwareMustDie research group, which analyzed and shared samples of it. It acts as an installer/dropper that persists on infected devices, drops a second-stage payload, and then uses the compromised system for DDoS activity. The target systems are VPS and IoT devices. (SHA256 of the dropper: b982276458a85cd3dd7c8aa6cb4bbb2d4885b385053f92395a99abbfb0e43784). Interestingly, the dropper 73b95b7d that delivers the OrBit payload in the final stage is identical to the one used in the Rhombus campaign 6 years ago. Coincidentally, both droppers use the same domain to download the payload as part of the cron-job-based persistence. The current resolution of the domain is to 109.95.212[.]253. The host has a unique BANNER_0_HASH-IP value, ba0c31785465186600a76b7af2a37aa6, that is shared with only one other IP, 109.95.211[.]141, as shown in the screenshot below from Validin. Based on the ASN resolution, both IP addresses are located in Russia. The fact that the OrBit dropper shares the same domain as malware from 6 years ago can also be interpreted as an attempt to mislead researchers; therefore, we are not taking this evidence into account for attribution at this moment. However, it is worth noting that this connection exists. Samples From February 2026 These two samples are confirmed to be identical in structure: the same 54-hook set, the same XOR key (0xA2), and the same working directory (/lib/libseconf/). The only difference is credentials: jokerteam/HACK89SERVER versus 57ill4Cu63/1qaz@WSX3edc098. XOR 0xA2 decode confirms the full Lineage A string set. No Lineage B samples have surfaced since 2024, suggesting the lite build may have been retired or consolidated back into the main branch. Connection to BLOCKADE SPIDER In CrowdStrike’s 2026 Global Threat Report, they mention that BLOCKADE SPIDER used the OrBit backdoor to maintain persistence and stealthy access to virtualization environments. BLOCKADE SPIDER is a CrowdStrike-tracked eCrime adversary that has been active at least since 2024. They are known for running Embargo ransomware campaigns using sophisticated, multi-domain attack techniques. Origin: OrBit is a fork of the Medusa open-source rootkit Mandiant's reporting on UNC3886 espionage operations identifies MEDUSA and its installer, SEAELF, as tools used by this state-sponsored actor against Juniper and VMware infrastructure. Essentially, OrBit is built from Medusa, an open-source LD_PRELOAD rootkit published on GitHub (github.com/ldpreload/Medusa) in December 2022. Mandiant's MEDUSA configuration table matches our 2024 Lineage A 0xAA-key cluster exactly across four independent fields: the XOR key 0xAA, the backdoor credentials Y0u4reCu6e and 1qaz@WSX3edc123, the install path /lib/locate/, and a modification to the rootkit that redirects strace output to /tmp/orbit.txt. That literal orbit filename, preserved as a plaintext artifact inside UNC3886's MEDUSA binary, is direct cross-attribution: Mandiant's "MEDUSA" sample set and our "OrBit" 2024 cluster are the same builds. We compiled Medusa from source and compared the resulting binaries byte-for-byte against our OrBit corpus. The match is unambiguous, and it rewrites the attribution and evolution story. Evidence of the fork The first is a function-set and export match. Compiling Medusa's src/rkld.c against the default Makefile recipe produces a shared object whose function set, hook list, and XOR-obfuscated string table are a direct superset match for OrBit Lineage A samples. The 2022 OrBit baseline (ec7462c3) shares all core exports with the Medusa build and reuses the identical XOR 0xA2 string obfuscation scheme driven by Medusa's build-time xor_dump() pipeline, with the XOR key itself hardcoded in config.c. The second is a source-filename fingerprint that is present in almost every sample we analyzed. Some of the samples ship with an unstripped ELF .symtab. The resulting filenames are preserved verbatim: rootkit samples carry rkld.c and, when Lineage A is linked in, rknet.c, while loader samples carry rkload.c. Those are the exact names of Medusa's source files, src/rkld.c, src/rknet.c, and src/rkload.c. The filenames themselves are not secret, since the Medusa repository is public, but their verbatim presence in the compiled binary is a strong attribution anchor: every unstripped sample directly identifies the upstream tree it was built from. Of the samples in our corpus, only three are fully stripped (the 2025 dropper 73b95b7d, and the rootkit binaries a6138638 and b9822764). Three representative samples are shown below: a full Lineage A rootkit (ec7462c3, 2022), a Lineage B lite rootkit (3ba6c174, 2023), and the SEAELF loader (26082cd3, 2024). 1: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c 9: 0000000000000000 0 FILE LOCAL DEFAULT ABS rkload.c 14: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c The Lineage A rootkit carries both rkld.c and rknet.c; the Lineage B rootkit, which omits the advanced hook set, carries only rkld.c; and the loader carries rkload.c. The same pattern holds across the wider corpus. Alongside the filename fingerprint, the loader's entry-point dispatch, its build_root() filesystem layout (.boot.sh, .logpam, sshpass.txt, sshpass2.txt, .ports), and its SELinux setxattr sequence all map one-to-one to the Medusa source. The third is an embedded inner ELF produced by xxd -i. Medusa's Makefile embeds build/rkld.so into the loader using the xxd -i build/rkld.so > build/rkld.h step, which is then included by the loader compiled at Makefile line 33. OrBit's loader binaries follow this pattern: a rkld.so blob embedded as a C byte array within the loader ELF, dropped to disk at runtime. The embedding technique, offset layout, and post-drop execution flow are identical. Per-Module Source Mapping Medusa's source tree maps cleanly onto the OrBit binary set we have tracked: The Medusa default Makefile compiles only src/rkld.c. Every Lineage A capability that appeared to "arrive" in OrBit between 2023 and 2025 was already present as source in Medusa's src/rknet.c on day one of the public release. The operators' work was to modify the Makefile to link rknet.c into their build, not to author those functions. Timeline Anomaly Our analysis shows that an initial OrBit sample (40b5127c) appeared in July 2022, predating the repository's publication by approximately 5 months. Based on this information, there are two options: either the Medusa author published a privately-circulated rootkit source that had already been deployed operationally, or the earliest OrBit sample was built from a pre-publication snapshot of the same tree. Either way, the 2022 OrBit sample and the December 2022 Medusa source tree are the same codebase. The question is only which commit was made public first. Implications The appearance of a single rootkit family across four years does not imply a single operator. OrBit and Medusa have been built and deployed by at least three unrelated actor clusters we can presently distinguish, including the state-sponsored espionage activity attributed to UNC3886, the eCrime ransomware operations run by BLOCKADE SPIDER, and the 2025 cron-dropper campaign previously linked to RHOMBUS infrastructure. Attribution at the family level is therefore not enough, and defenders tracking an OrBit infection should separate the questions of which codebase was used from which operator configured and deployed it. Tracking version-over-version changes in OrBit reads less like an active malware development project and more like a record of build-flag toggles, credential rotations, and install-path swaps against a stable upstream. The capability ceiling is set by the Medusa source tree as it existed in December 2022, and every apparent new feature we observed between 2023 and 2025 was already present in that tree, waiting for an operator to link it in. The xread read-hook bypass we first flagged as a 2023 compatibility shim is a function in src/rknet.c. The auditd evasion pair we called out as a 2024 addition, audit_log_acct_message and audit_log_user_message, sits in the same file. The PAM stack we noted as gradually expanding across versions, including pam_authenticate, pam_acct_mgmt, pam_open_session, and the 2025 service-side impersonation hook pam_sm_authenticate, is all present in the same rknet.c, as is the pcap_loop packet hook that appears in full Lineage A builds. None of these files is linked in by the default Makefile recipe, which compiles only src/rkld.c. Their arrival in individual OrBit samples corresponds to an operator modifying the build to include rknet.c, not to new code being written. Signatures based on invariants of the Medusa build pipeline will also flag builds from operators we have not yet seen. Three such invariants are worth calling out. The string table produced by Medusa's xor_dump() routine, which emits every protected string as a contiguous block of single-byte XOR-obfuscated byte arrays within the compiled binary. Operators change the key value (0xA2 in most builds, 0xAA in the 2024 UNC3886 cluster) and some paths, but the table's shape and the majority of its entries are fixed by the source. A YARA rule that decodes the table with a variable single-byte key and matches on a threshold count of known plaintext strings catches any build, regardless of which key was chosen. The filesystem skeleton that the loader's build_root() writes into its install directory. Operators vary only the parent directory (/lib/libseconf/, /lib/locate/, /lib/libntpVnQE6mk/), so host-based detection can alert on the co-occurrence of that filename set inside any directory, and binary-level signatures can match the embedded filename constants and the setxattr call pattern directly. The nested-ELF structure produced by the xxd - +i build/rkld.so > build/rkld.h step in the Makefile, which bakes a full secondary ELF into the loader's .rodata. Every Medusa loader therefore carries a second ELF magic inside its own image, followed by a length constant, and, if the binary is not stripped, two xxd-generated symbols (rkld_so and rkld_so_len ). The nested-ELF shape on its own is not specific enough to be a detection signature: plenty of legitimate software and unrelated malware use xxd -i or equivalent techniques to embed a payload, and any such binary will match a naive "second ELF at non-zero offset plus length constant" rule. The Medusa-specific part is the pairing of that structural pattern with (a) the symbol names rkld_so and rk +ld_so_len in the loader's symbol table when the binary is not stripped, and (b) the inner ELF itself, matching the rootkit fingerprint described earlier in this section, which gives both a family-level anchor and a structural one. Conclusion The analysis of OrBit variants from 2022 through early 2026 reveals a Linux rootkit whose code later surfaced in an open-source codebase named Medusa. This suggests that the backdoor was created before its public release and has since been selectively forked, configured, and redeployed by multiple operators over four years. We identified two parallel build paths: the comprehensive Lineage A ("Full" build), which links in Medusa's src/rknet.c advanced hook set, and the temporary Lineage B (lite build), which ships only the src/rkld.c core and was retired after 2024. Apparent "milestones" in Lineage A are the xread wrapper (2023), the audit_log_* auditd-evasion hooks (2024), and the 2025 addition of the pam_sm_authenticate hook, which corresponds one-to-one with functions already present in Medusa's published source. The operator work is in the build configuration and deployment, not the C code. Our analysis of the OrBit samples also discovered that at least 3 different operators are using the backdoor. A major operational shift occurred in 2025 with the introduction of a new two-stage infector architecture, marking one operator's transition from a purely passive SSH-backdoor implant to malware with its first direct C2 capability. This infector utilizes a cron job to fetch external payloads from the domain cf0[.]pw. The architecture of this new dropper is identical to one used in the 2020 RHOMBUS botnet campaign, suggesting shared tooling or operator overlap, a link further cemented by the C2 domain resolving to infrastructure located in Russia. In parallel, the same Medusa codebase was weaponized upstream by the state-sponsored espionage actor UNC3886 (tracked by Mandiant). The 2024 0xAA-key cluster we tracked as Lineage A corresponds exactly to UNC3886's MEDUSA configuration, including the backdoor credentials, the install path, and a strace artifact that retains the literal "orbit" string. The rootkit has also been adopted by the CrowdStrike-tracked eCrime adversary BLOCKADE SPIDER since at least 2024, who leverage OrBit for stealthy persistence against VMware vCenter infrastructure to facilitate the deployment of Embargo ransomware. The continued emergence of new Lineage A samples in 2026, accompanied by operator-specific credential rotation, confirms that a single public rootkit codebase is being cloned and configured by multiple unrelated actor groups. IOC Table Nicole Fishbein Nicole is a senior security researcher and malware analyst at Intezer. Prior to this, she was an embedded researcher in the IDF Intelligence Corps.

Many security leader are asking the same question right now. We already pay for Microsoft Copilot, ChatGPT Enterprise, or Claude. Why buy anything else? It is a fair question. These are genuinely impressive platforms. And the honest answer is that they can help with some things. Just not the things that matter most for most SOC teams. This post is a practical guide to where generalist AI earns its place in a SOC and where it runs out of road. Where generalist AI platforms actually add value Let's be direct about what generalist AI platforms do well in a security context. They are good at drafting, incident summaries, policy documentation, communication templates, and post-mortems. If an analyst needs to translate a technical finding into plain language for an executive, a general-purpose LLM can accelerate that substantially. They are useful for on-demand research. Asking a question about a CVE, looking up MITRE ATT&CK techniques, or getting a quick primer on an unfamiliar attack class. These are real productivity wins. They can assist with simple scripting and query construction. Writing a KQL query for a Sentinel rule, generating a Python snippet to parse a log format. Useful, time-saving work. The common thread is that these are assistance tasks. A human still needs to initiate the process while the AI is a capable co-pilot. And for these use cases, a general-purpose tool is perfectly appropriate. Where generalist AI runs out of road The problem is that none of those use cases address the actual constraint facing most SOC teams. Security teams are not failing because analysts lack knowledge or work too slowly. They are constrained by investigative capacity. Alert volumes are rising. Environments are growing. Attacks are moving faster. And the operating model still assumes humans will triage and investigate the majority of what comes in. When that assumption breaks down, investigation becomes selective. High-severity alerts get attention. Medium alerts accumulate. Low-severity alerts are deferred or auto-closed. And the uncomfortable truth is that real attacks frequently begin as weak signals. Credential misuse, living-off-the-land techniques, early-stage lateral movement. They rarely present as critical alerts. They appear ordinary until someone actually investigates them. Generic AI does not fix this. Here is why. Generalist AI is built for breadth, not depth ChatGPT and Microsoft Copilot are built for general-purpose text generation. Forensic investigation of a suspicious process execution chain, or a cloud misconfiguration alert at 3am, requires domain-specific knowledge and structured reasoning those platforms were not designed to provide. Generalist AI assists but does not execute Even with a great prompt, a general-purpose AI is accelerating an analyst's workflow, not replacing the need for one. The investigation still depends on human capacity. And human capacity does not scale as fast as the alert surface grows. Generalist AI KPIs are increased token usage Microsoft's KPI, for example, is token usage. More engagement equals more revenue, regardless of whether your security outcomes improved. That is not a subtle difference. It shapes every product decision, every definition of success. And this can result in very high costs for SOC teams heavily relying on these platforms. This is in stark contrast to Intezer AI SOC which selectively uses LLMs while primarily executing forensic investigations with highly scalable tools and processes. Read more about how Intezer Forensic AI SOC follows Anthropic’s best practices. A practical AI decision framework Use generalist AI when: The task requires drafting or synthesizing text and security context is not critical to the output An analyst is researching something unfamiliar and needs a starting point The work is advisory and a human will validate and act on every output Speed of completion matters more than forensic accuracy Consider purpose-built AI when: You need investigation to happen without an analyst driving every step Alert volume has outpaced the team's capacity to investigate manually Medium and low-severity alerts are going uninvestigated because there simply is not time You need verdicts accurate enough to act on, not just suggestions to review The line between these two categories comes down to one question. Do you need AI assistance, or do you need AI execution? What autonomous execution actually requires This distinction matters because it shapes what you need from a platform. Assistance is achievable with a good LLM and a capable prompt. Execution requires something harder: accuracy and forensic depth at investigation time. General-purpose AI tools and many first-generation AI SOC products rely primarily on LLM analysis and SIEM queries. That is not enough to produce verdicts you can trust without a human checking every one. Intezer AI SOC is built for the execution side of that line. Automated evidence collection, threat intelligence correlation, network forensics, endpoint forensics, and reverse engineering. That additional depth is what generates the high-confidence verdicts that allow organizations to trust the outcome without a human reviewing every decision. Below a certain threshold of accuracy and depth, AI assists humans. Above it, organizations can safely offload Tier 1 and Tier 2 work entirely. The threshold is not crossed through breadth. It is crossed through domain specialization and forensic rigor. Intezer's investigations produce evidence-based verdicts with 98% accuracy. Up to 2% of alerts are escalated as real incidents while the rest are resolved automatically. That is not a productivity improvement. That is a fundamentally different operating model. The closed loop of triage and detection engineering There is one more dimension where general-purpose tools fall short and that is detection engineering. When a generic AI tool helps an analyst triage an alert, that interaction is largely isolated. The outcome does not feed back into your SIEM rules. It does not surface coverage gaps. It does not help you get better at detecting the same class of threat next time. Intezer's investigation outcomes feed directly into detection engineering at the source, continuously identifying broken or noisy rules, flagging coverage gaps against the MITRE ATT&CK framework, and generating deployment-ready detection rules informed by real investigation results. The system improves with every alert it processes. Detection gets better based on evidence, not assumptions. That closed loop is the difference between a productivity tool and an operating model. Is a single generalist interface with multiple plugins the answer? There is also an important architectural point worth making. Generalist AI platforms are increasingly effective at consolidating workflows into a single interface, and in theory, you could extend them into security operations through plugins and MCPs. The building blocks exist. But in practice, stitching together the specialist capabilities needed for real alert triage such as forensic evidence collection, threat intelligence correlation, reverse engineering, network analysis, etc. means sourcing, integrating, and maintaining a patchwork of plugins across multiple providers. Each one has its own update cycle, its own failure modes, and its own gaps. The integration burden falls on your team, and keeping it all working reliably over time is its own operational overhead. At some point the question becomes whether the effort of assembling and maintaining a DIY investigation pipeline inside a generalist platform is worth it — or whether it makes more sense to use a purpose-built system where those capabilities are already unified, tested, and working together out of the box. The bottom line Generalist AI platforms have a real role to play in the SOC. Use them for drafting, research, and analyst-driven assistance tasks. It is good at those things and it is likely already paid for. But do not confuse that with solving the capacity problem. When investigation still depends on human bandwidth, the alert backlog does not disappear. It just accumulates more slowly. The future SOC is one where AI executes investigation and humans supervise outcomes. Getting there requires technology purpose-built for that job. Learn more about Intezer AI SOC.

AI SOC Live at Nasdaq: Real conversation about modern security operations April 20, 2026 Written by Zev Schonberg UPDATED: On April 27, 2026 security leaders gathered at the Nasdaq in Times Square for Intezer's first AI SOC Live, and the response was AMAZING! More than 100 CISOs, SOC leaders, and security practitioners filled the room, and we kept the guest list intentionally tight so every conversation felt like a real exchange rather than a conference crowd. Itai Tevet, our CEO and founder, opened the day with a candid look at why the SOC model is broken and what it takes to fix it. From there, the sessions kept the energy high. A CISO panel on the role of humans in the SOC brought together leaders from Salesforce, ServiceNow and Blackhawk Network for an unfiltered debate about AI, automation, and where human judgment still matters most. Later sessions covered data-first approaches to AI SOC, cloud security in the AI era, and what CISOs need in their board decks to make the case for change. The feedback since the event has been overwhelmingly positive. Attendees told us it was one of the few events where they left with practical takeaways instead of more AI hype. We're grateful to everyone who joined us, to our sponsors and to every speaker who brought an honest perspective to the stage. Here are some photos from the event. ORIGINAL POST: The SOC is broken. Not because of a lack of talent or effort, but because human capacity does not scale. Alert volumes keep rising. Attacks move faster. And the operating model still assumes analysts will investigate most of what comes in, which means the vast majority of alerts never get looked at. Our AI SOC Report 2026, based on analysis of 25 million alerts across our global customer base, put a sharp number on the problem. Over 60% of alerts are never reviewed by SOC and MDR teams. Nearly 1% of all incidents trace back to alerts classified at the lowest severity levels, signals most teams never touch. With average enterprises generating around 450,000 alerts annually, that equates to roughly one real threat per week hiding in the backlog, undetected. That is not a tool problem. It is an operating model problem. On April 27, we are bringing together the security leaders who are doing something about it. What is AI SOC Live AI SOC Live is a monthly, online event where security leaders discuss the latest issues facing the cyber industry. This month, AI SOC Live will be a full-day, invitation-only event at the Nasdaq in New York City. It is designed for CISOs, security directors, SOC managers, and MSSPs who are not just watching AI transform security operations from the sidelines, but are in the middle of it, making decisions about how their teams operate, what they invest in, and where the humans actually need to be. This event is a full day of sessions, panels, and conversations built around the people, processes, and technology required to run a world-class SOC in 2026. Who you will hear from at AI SOC Live Nasdaq The speaker lineup reflects how seriously we have curated this event. Itai Tevet, CEO and Founder of Intezer, will open the day with a session on the new SOC operating model, what it means when AI executes investigation and humans supervise outcomes, and why that shift changes security results structurally, not incrementally. Alon Cohen, Founder and Executive Chairman of both Intezer and CyberArk, will speak to the broader impact of AI on security, drawing on decades of experience building foundational security companies. Pavi Ramamurthy, Global CISO & CIO at Blackhawk Network as well as a founding member of the Professional Association of CISOs, and a venture advisor at YL Ventures. She will be speaking about the role of humans in the SOC. David Spark, Founder and Executive Producer of the CISO Series Podcast, will host a live recording of the show featuring Nick Vigier, CISO at Oscar Health, digging into AI SOC beyond the hype. You will also hear from CISOs at WCG Clinical, and ION Group, alongside practitioners from Realm Security, Legato Security, Upwind Security, and Monad. Sessions cover cloud security for the AI era, the blueprint for AI SOC success, and what every CISO needs to manage not only their security, but their executive board as well. And Mitchem Boles, Field CISO at Intezer, and Marcus Mingo, Detection Engineer at Intezer, will be there all day, available for the kind of real, technical conversations that rarely happen at larger conferences. See the full list of speakers. What the day looks like The agenda moves quickly and stays practical. The morning opens with sessions on the new operating model and AI's impact on security, followed by a CISO panel on the role of humans in the SOC and a session from Realm Security on building a data-first AI SOC. After a working lunch with interactive product demos, the afternoon covers cloud security, a live CISO Series recording, and a panel on advancing SOC outcomes at the C-suite level. The day closes with a photo opportunity in front of the iconic Nasdaq billboard, followed by a cocktail reception overlooking New York City. Attendees also earn CPE credits through the event's partnership with ISC2. Why this conversation matters now The 2026 data makes the stakes clear. Our report found that more than half of confirmed compromised endpoints had been marked as "mitigated" by the EDR vendor, meaning teams believed those machines were clean when they were not. The gap between what organizations believe is covered and what is actually investigated is where real risk lives. Closing that gap requires a different operating model, one where AI investigates every alert, including the low-severity signals that human teams deprioritize, and humans supervise outcomes instead of grinding through queues. That is the conversation happening at AI SOC Live. Who should attend This event is designed for CISOs, VPs and Directors of Information Security, SOC managers, and MSSPs from large enterprises who are responsible for security strategy, risk decisions, and operational outcomes. Whether you are evaluating AI for the first time or scaling capabilities you already have deployed, the sessions and conversations are built for leaders making real decisions, not attendees collecting swag. Space is limited and invitations are by request. Zev Schonberg Zev Schonberg is a product marketing manager with years of experience in deep tech. As a lead contributor at Intezer, Zev authors research-driven analysis and thought leadership that explores how modern security operations centers can better detect, investigate, and respond to threats at scale.

The question isn't whether to build. It's what's worth building. Nearly every security organization with strong engineering resources is running some kind of internal AI project right now. That's not a problem to be solved, it's a sign of a healthy, capable team. The question worth asking isn't "build or buy?" It's a more precise one: which parts of this problem are worth your engineers' time, and which parts aren't? That distinction changes the conversation entirely. Intezer's approach isn't to compete with your internal roadmap. It's to handle the commodity layer, common alert sources like CrowdStrike for example, so your engineers can focus on the security challenges that are actually unique to your organization. Some companies with very strong engineering teams are getting tremendous value from Intezer, precisely because they understand exactly what they'd rather not build themselves. One Fortune 100 company started with Intezer for phishing triage, which removed a significant chunk of their internal DIY roadmap and freed their team to focus on their unique, internal use cases. Another F500 company went further as they expanded their Intezer contract while building their own custom internal AI for their own security use cases. Build and buy, working together, each doing what it does best. So with that framing in mind, here's an honest look at the parts of the AI SOC problem that are genuinely worth building and the parts that usually aren't. The maintenance treadmill nobody talks about The first thing you encounter when you start building AI-driven alert triage is that the initial integration is only a fraction of the long-term work. SIEM integrations break when vendors push updates. EDR APIs change without notice. New alert formats appear. Security tools version, deprecate endpoints, and shift data schemas on their own timelines. Keeping those integrations alive requires constant reverse engineering, work that is generic across every security organization in the world, but still consumes real engineering hours every single week. Intezer already handles all of that. The integrations are built, maintained, and updated as the ecosystem evolves. When you offload the commodity layer, you skip the maintenance treadmill and get straight to what actually requires your organization's specific knowledge. Vendor alerts share many similarities even in different customer environments Every security team knows their environment has its own complexity with unique infrastructure, specific tooling, particular workflows that took years to build. That's real, and it matters. But when it comes to the triage logic itself like investigating a suspicious lateral movement event, assessing a phishing alert, working through a cloud misconfiguration, the patterns tend to look remarkably similar across organizations. These are problems the industry has collectively solved thousands of times over. That doesn't diminish the work your team has done. It does raise a practical question: is rebuilding that common triage baseline the best use of your most capable engineers? The time spent recreating what already exists everywhere is time not spent on the challenges where your team's knowledge is genuinely irreplaceable for your specific threat model, your particular infrastructure, and the edge cases no vendor has seen before. Plugging into Intezer for the common alert sources isn't a concession. It's a way to protect your team's time for the work that only they can do. The integration challenge One objection that comes up reliably, “we'll need to do the integration work regardless”. That's true. Connecting any automated system to your production security stack is environment-specific work that no vendor can fully do for you. But here's the distinction. With Intezer, that integration challenge is the only technically demanding part remaining. You're not also building the investigation engine, the forensic analysis layer, the case correlation logic, the noise reduction system, and the detection feedback loop from scratch. Building everything yourself means doing all of that foundational work and the integration. You spend months getting to a starting line that Intezer has already crossed, backed by years of operational learning across more than 150 enterprise deployments. What the ROI actually looks like There's a headcount dimension here that often gets underweighted. Building and maintaining your own AI SOC automation means dedicating engineering resources to it indefinitely. Those people aren't available for other priorities. Their output is difficult to measure in security terms. And at the end of it, you've built something that performs commodity triage work, the same work Intezer has already productized and is continuously improving. Buying Intezer converts that into a measurable line item with clear security outcomes attached: investigation accuracy, alert volume handled per analyst, time to resolution, escalation rate. RSM reported saving approximately 21,000 analyst hours per month, the equivalent of around 130 analysts, by running Intezer as their AI SOC layer. That's not a soft productivity argument. It's a concrete operational ROI story. Continuous learning One more dimension worth considering. What happens after an alert is triaged? When Intezer investigates an alert, that outcome feeds back into detection engineering at the source, surfacing noisy or broken rules, mapping coverage gaps to MITRE ATT&CK, and generating deployment-ready detection rules informed by actual investigation results. The system gets smarter with every alert it processes. Detection improves based on evidence, not assumptions. Homegrown automation rarely achieves this systematically. You triage the alert, close the ticket, and move on. The learnings don't automatically improve your SIEM rules or extend your detection coverage. The system runs, but it doesn't compound. The practical frame Think of it less as build vs. buy and more as what's the right division of labor? The commodity layer, common alert sources, standard triage logic, integration maintenance, detection lifecycle management, is worth offloading. That's where Intezer operates. Your engineers stay focused on what's actually differentiated: the security challenges that are specific to your environment, your risk profile, your business. The teams that figure out this division early move faster, cover more, and build the things that actually matter. Learn more about Intezer.

For teams that have outgrown their MDR, the answer isn’t a better MDR. It’s a different operating model. MDR works. For a lot of teams, it’s the right solution at the right time. It brings experienced analysts, established processes, and investigation capacity that most organizations can’t build internally overnight. But as environments grow and alert volumes climb, many teams start to feel the limits of the model itself. Investigation quality depends on analyst availability and shift coverage. Low and medium severity alerts get deprioritized because the queue demands it. And the security team watching from the other side can’t always tell whether the backlog is safe to ignore or hiding something real. That’s not a failure of MDR. It’s a ceiling built into any operating model that scales investigation through human labor. Today, we’re announcing expanded capabilities in the Intezer AI SOC platform, powered by ForensicAI™. Built for teams who’ve reached that ceiling and are ready for what comes next. The risk in the backlog Across enterprise SOC environments, roughly 60% of alerts go unreviewed. Not because teams aren’t working hard. Because there are only so many hours in a day, and the alert stream doesn’t stop. “Many organizations handle millions of security events per year. There’s no possible way you can go through 100% of your alerts and resolve them completely, unless you rely on an AI platform.” — Cecil Pineda, 4x CISO, Healthcare Industry Our analysis of more than 25 million alerts found that nearly 1% of real threats originate from low-severity signals, alerts that most teams deprioritize or skip entirely. For a large enterprise, that’s an average of 54 true threat alerts per year. More than one per week. Hiding in the noise tier that nobody gets to. Read our full AI SOC research report. There’s also a second gap that rarely gets discussed. Because investigation and detection engineering are siloed within most MDRs, real investigation outcomes almost never feed back into SIEM and EDR rule tuning. Noisy detections stay noisy. Coverage gaps stay gaps. The system doesn’t learn from its own work. What’s new in the Intezer AI SOC The Intezer AI SOC platform was built on a simple premise. If you can’t investigate every alert, you can’t meaningfully reduce risk. Intezer AI SOC handles the investigative execution (triage, correlation, forensic-depth analysis) across 100% of alerts, regardless of severity. Humans supervise outcomes and engage at the decision point. With this expansion, we’re adding three capabilities that close the remaining gaps between autonomous AI SOC operations and the full-service coverage teams expect. AI-driven detection engineering Investigation outcomes now feed directly into a closed-loop detection engineering process. SIEM and EDR rules are tuned or created, at the source, based on real verdict data, threat intelligence, and observed attacker behavior. Broken detections, noisy rules, and coverage gaps are identified and addressed continuously. This is the connection that siloed MDR roles have historically missed. Triage informs detection, better detection shortens the triage process, and the system gets smarter over time. On-demand security experts When the AI surfaces a high-confidence incident and you want a second set of eyes, or you’re mid-response and need expert judgment, Intezer’s security researchers and analysts are available directly through the platform. You can request expert analysis of artifacts, alerts, and logs, get guidance during an active incident, or validate suspicious activity the AI flagged. A dedicated expert is always on call for urgent requests, with Customer Success tracking every engagement through to resolution. Continuous feedback and model tuning Every time your team reviews a verdict, marks a false positive, or flags a result that doesn’t fit, that signal improves the system. Intezer’s experts review edge cases, adjust tuning rules, and add custom AI instructions calibrated to your environment and risk profile. Tuning also happens proactively through continuous platform monitoring and improvements, with no periodic review project required. Learn more about Intezer’s QA process. The shift “Security operations have reached a structural limit. Human teams, whether internal or outsourced to MDR providers, cannot realistically investigate the volume of alerts enterprises now face. Our analysis of more than 25 million alerts makes the risk clear: Real threats are often buried in the low-severity signals that never get investigated. AI SOC changes the model by making full forensic investigation possible across every alert, continuously improving detection based on real outcomes, and allowing human experts to focus on the incidents that truly require judgment and response.” — Itai Tevet, CEO and Co-Founder, Intezer Together, these capabilities shift security teams away from manual alert processing and toward supervising outcomes. Organizations that have outgrown their MDR can now investigate 100% of alerts at forensic depth, trust the evidence behind every verdict, close the loop between investigation outcomes and detection quality, and bring in expert analysts when it matters most. The result is stronger security outcomes, broader alert coverage, and the ability to operate at enterprise scale without the constraints of a human-scaled model. AI executes. Humans supervise. RSA Conference is where the security industry sets its direction. This year, AI in the SOC is the conversation happening on every floor of Moscone. But there’s a meaningful difference between AI that helps analysts work faster and AI that takes on the investigative function entirely. This announcement draws that line with data. 25 million alerts analyzed, 60% going unreviewed in enterprise environments, real threats hiding in the low-severity tier at a rate of more than one per week. These aren’t hypotheticals. They’re findings from production environments at scale where Intezer is not simply delivering better analyst productivity, but rather measurable improvements in enterprise security. For teams that have been thinking about what comes after MDR, this is the moment to see it working. Visit Intezer at Moscone South, Booth #555

Security operations is undergoing a fundamental shift. As alert volumes continue to rise and environments grow more complex, enterprises are moving away from security models built on manual triage, fragmented automation, and are looking to decrease their reliance on outsourced MDR services. More enterprises are adopting AI SOC as the new model for running security operations, one that can triage and investigate all alerts at machine scale while keeping internal teams focused on judgment and response. That shift was reflected clearly in Intezer’s momentum over the past year. In 2025, Intezer processed more than 25 million security alerts across live enterprise SOC environments, as adoption expanded across large and complex organizations looking for a more scalable way to run security operations. A year of strong growth Over the past year, Intezer achieved several major company milestones: Multiplied revenue year over year Achieved 126% net revenue retention Expanded adoption across Fortune 500 organizations Scaled the team across key functions to support a growing enterprise customer base These milestones reflect more than company growth. They reflect a broader market transition toward AI SOC as enterprises look for ways to investigate every alert, reduce hidden risk, and operate beyond the limits of human investigation capacity. Growing industry recognition Intezer’s momentum is also being recognized by media, industry analysts and practitioners. Here is a sampling of recent coverage. Reuters covered Intezer’s research team’s work on uncovering novel cyber attacks this past December, that were targeting Russian defense organizations. Well known industry analyst Richard Stiennon recently included Intezer in the 2026 Cyber 150, an independently compiled list based on IT-Harvest data, and has also included Intezer in his new book, Guardians of the Machine Age. At the same time, practitioners are taking notice. In his write-up on Intezer’s 2026 AI SOC Report, Darwin Salazar highlighted the report’s forensic depth, auditability, and practical value in a crowded AI SOC market. Why this momentum matters Traditional SOC and MDR models are constrained by human investigation bandwidth. As alert volumes increase, teams are forced to prioritize only a subset of alerts, often based on severity labels before full context is available. That leaves real risk hiding in uninvestigated alerts. Enterprises are increasingly adopting AI SOC to remove that bottleneck. Intezer investigates 100% of alerts at forensic depth across endpoint, identity, cloud, network, phishing, and SIEM sources, escalating only the incidents (less than 2%) that require human judgment. This allows security teams to stay in control while scaling operations far beyond what manual investigation models can support. What the numbers show The business results from the past year point to strong validation in the market. Doubling revenue year over year signals accelerating demand. 126% net revenue retention reflects strong customer expansion and continued platform adoption. Growth across Fortune 500 organizations shows that large enterprises are increasingly embracing this operating model. And continued team expansion across key functions ensures Intezer can support customers as adoption grows. Looking ahead The market is moving toward a new SOC operating model, one where AI executes investigations at scale and human teams focus on decisions, response, and strategy. Intezer’s momentum over the past year reflects that shift clearly. As more enterprises look to eliminate investigation bottlenecks and reduce cyber risk, AI SOC is moving from emerging category to operational reality. Learn more about Intezer.

Introducing the 2026 Intezer AI SOC Report for CISOs For years, security leaders have lived with an uncomfortable truth. It has been to date, simply impossible to investigate every alert. As alert volumes exploded and teams failed to scale, SOCs, whether in-house or outsourced, normalized “acceptable risk” with the deprioritization of low-severity and informational alerts. Our latest research shows that this approach is no longer defensible. Intezer has just released the 2026 AI SOC Report for CISOs, based on the forensic analysis of more than 25 million security alerts across live enterprise environments. The findings reveal a critical disconnect between how security teams prioritize alerts and where real threats actually originate, and the cost of that gap is far higher than most organizations realize . Why “acceptable risk” is no longer acceptable Across endpoint, cloud, identity, network, and phishing telemetry, Intezer found that nearly 1% of confirmed incidents originated from alerts initially labeled as low-severity or informational. On endpoints, that figure climbed to nearly 2%. At enterprise scale, that percentage is not noise. For a typical organization generating roughly 450,000 alerts per year, this translates to ~50 real threats annually, about one per week, never investigated by a SOC or MDR team. These are not theoretical risks. They are real compromises hiding in plain sight, dismissed not because they were benign, but because teams lacked the capacity to look. What the data revealed across the attack surface Because Intezer AI SOC investigates 100% of alerts using forensic-grade analysis, the report exposes how attackers actually operate once you remove triage bias from the equation. Endpoint security is more fragile than reported More than half of endpoint alerts were not automatically mitigated by endpoint protection tools. Of those, nearly 9% were confirmed malicious. Even more concerning, 1.6% of endpoints undergoing live forensic scans were still actively compromised despite being reported as “mitigated” by EDR tools. See the full endpoint threat data → Download the 2026 AI SOC Report Low-severity does not mean low-risk Within endpoint alerts alone, 1.9% of low-severity and informational alerts were real incidents, the exact alerts most SOCs never review. Attackers favor stealth over noise Cloud telemetry was dominated by defense evasion and persistence techniques, reflecting a shift toward long-term access, token abuse, and misuse of legitimate services rather than overt exploitation. Phishing has moved into trusted platforms and browsers Fewer than 6% of malicious phishing emails contained attachments. Most relied on links, language, and abuse of legitimate services such as cloud file sharing, code sandboxes, CAPTCHA mechanisms, where traditional controls have limited visibility. Cloud misconfigurations persist as silent risk multipliers Most cloud posture findings stemmed from legacy or default configurations, especially in Amazon S3, including missing encryption, weak access controls, and lack of logging—issues often classified as “low severity,” yet repeatedly exploited once attackers gain a foothold. To read the full report and all the findings, download the CISOs guide to AI SOC 2026 here. Why traditional SOCs fail: capacity, fragmentation and judging alerts by their severity Modern SOC failures are rarely the result of a single broken tool or negligent team. They are the outcome of structural tradeoffs that every traditional SOC—internal or MDR—has been forced to make. Capacity is the first constraint. Human analysts do not scale linearly with alert volume. As telemetry expands across endpoint, cloud, identity, network, and SaaS, SOCs hit a hard ceiling. The only way to cope is aggressive triage: close most alerts automatically, investigate only what looks “important,” and hope severity labels align with reality. The 2026 AI SOC Report shows that this assumption is false at scale. Tool fragmentation compounds the problem. Most SOC stacks are collections of siloed detections, EDR, SIEM, identity, cloud posture, email, each optimized for a narrow signal. Severity is assigned locally, without cross-surface context or forensic validation. As a result, alerts are scored based on abstract rules, not evidence of compromise. When SOCs trust these labels blindly, they inherit the tools’ blind spots. Process tradeoffs lock risk in place. Once triage rules are defined, they become institutionalized. Low-severity alerts are ignored by design. MDR providers codify this into SLAs. Internal SOCs bake it into runbooks. Crucially, there is no closed-loop feedback: missed threats do not automatically improve detections, because they were never investigated in the first place. The outcome is not an occasional failure. It is systematic, repeatable risk, embedded directly into how SOCs operate. Real-world examples of missed threats hiding in plain sight The data in the 2026 AI SOC Report makes clear that missed threats are not exotic edge cases. They are ordinary attacks progressing quietly through environments because no one looked. Endpoints marked “mitigated” but still compromised In over 1.6% of live forensic endpoint scans, Intezer found active malicious code running in memory even though the EDR had already reported the threat as resolved. These cases included stealers, RATs, and post-exploitation frameworks, often originating from low-severity alerts that never triggered deeper inspection. Without memory-level forensics, these compromises would have remained invisible. Phishing hosted on trusted platforms Attackers increasingly host phishing pages on legitimate developer platforms like Vercel and CodePen, or abuse trusted cloud services such as OneDrive and PayPal. The parent domains appear reputable, so alerts are downgraded or ignored. Yet behind them are live credential-harvesting pages that bypass email gateways and browser-based defenses alike. Cloud misconfigurations as delayed breach accelerators Many cloud posture findings such as unencrypted S3 buckets, missing access logs and permissive cross-account policies rarely trigger action. But once an attacker gains any foothold, these long-standing misconfigurations dramatically accelerate lateral movement, persistence, and data exposure. In every case, the failure was not detection. The signal existed. The failure was investigation. How attackers deliberately exploit SOC blind spots Attackers understand SOC economics better than most defenders. They know which alerts generate fatigue. They know which detections are noisy. They know which categories are deprioritized by default. As a result, modern attackers design their campaigns to blend into the backlog, not trigger alarms. Stealth over speed Cloud intrusions favor defense evasion, persistence, and token abuse over loud exploitation. These behaviors generate alerts, but rarely high-severity ones. The report shows cloud telemetry dominated by exactly these tactics, indicating attackers are optimizing for long-term access rather than immediate impact. Living off trusted infrastructure Phishing campaigns increasingly abuse legitimate brands, file-sharing services, CAPTCHA frameworks, and developer platforms. These environments inherit trust by default, allowing attackers to operate under severity thresholds that SOCs routinely ignore. Multi-stage loaders and memory-only execution On endpoints, attackers rely on layered loaders, in-memory payloads, and obfuscation techniques that evade static detections. Initial alerts may look benign or incomplete. Without forensic follow-through, SOCs miss the actual compromise entirely. Attackers are not evading detection systems alone, rather they are exploiting SOC decision-making models. What this means for your SOC operations For CISOs and SOC leaders, the implication is stark: Risk is no longer defined by what you detect, but by what you choose not to investigate. If your SOC: Ignores low-severity alerts by default Relies on severity labels without forensic validation Limits investigations based on human capacity Operates without a feedback loop between outcomes and detections Then missed threats are not anomalies, they are guaranteed. The organizations that will reduce risk in 2026 are not adding more dashboards or rewriting triage rules. They are adopting operating models where investigation is no longer a scarce resource. This is why AI-driven, forensic-grade SOC platforms fundamentally change the equation. When every alert is investigated: Severity becomes evidence-based, not assumed Detection quality improves through real-world validation Attackers lose the ability to hide in “acceptable risk” SOC teams regain control without scaling headcount This is the shift behind the Intezer AI SOC model and why the concept of acceptable risk must be redefined for the modern threat landscape. This all changes when you can investigate everything The data in the 2026 AI SOC Report points to a different reality, one where AI-driven forensic analysis removes investigation capacity as a constraint. When every alert is investigated: “Low severity” stops being a proxy for “safe” Detection quality improves through real-world validation Missed threats drop from dozens per year to near zero Escalations fall below 2%, without sacrificing coverage Risk tolerance is defined by evidence, not exhaustion This is the operating model behind Intezer AI SOC, powered by ForensicAI™ and it is why the definition of acceptable risk must be reset. Download the report and join the discussion The 2026 AI SOC Report for CISOs is grounded in: 25 million alerts analyzed 10 million monitored endpoints and identities 82,000 forensic endpoint investigations, including live memory scans Telemetry from 7 million IP addresses, 3 million domains and URLs, and over 550,000 phishing emails All data was aggregated and anonymized across Intezer’s global enterprise customer base. 👉 Download the full report to explore the findings in detail, and 👉 Join Intezer’s research team on Wednesday, February 4th at 12 p.m. ET for a live webinar breaking down what this data means for SOC leaders and CISOs. Because in 2026, the biggest risk is no longer what you detect, it’s what you choose not to investigate.

How AI brings the OSCAR methodology to life in the SOC January 21, 2026 Written by Girish Mukhi 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: 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. Girish Mukhi is a Senior Security Engineer at Intezer, where he helps shape an autonomous SOC platform that empowers organizations to detect and respond to threats faster. A people-driven leader with over a decade of experience, including scaling SOC operations and guiding analyst teams at Expel and Stratascale, he has firsthand experience turning operational chaos into clarity. Today, he focuses on bridging the gap between technology and the people it protects, helping security teams move from reactive survival to strategic defense.

Building effective AI for the SOC: How Intezer Forensic AI SOC follows Anthropic’s best practices January 14, 2026 Written by Zev Schonberg One of the most influential publications on real-world AI system design is Anthropic’s guide, Building Effective Agents. Its core message is simple: Effective AI requires structure first, adaptability second. Anthropic emphasizes that AI agents work best when: A deterministic workflow does all the structured work up front The agent only activates when uncertainty remains The agent begins with full context, not an empty slate Tool usage is controlled and evidence-driven Human-in-the-loop remains central for oversight and trust These principles ensure accuracy, avoid hallucinations and keep investigations reproducible, all critical requirements for cybersecurity. Intezer Forensic AI SOC is built on exactly this philosophy. Our platform uses a dual-mode design with Intezer AI Workflow and AI Agent, completely aligning with Anthropic’s best practices to deliver fast, scalable and highly accurate investigations across a broad range of alerts, all while keeping analysts in the loop. Here is how Intezer implements Anthropic’s best practices for agents. Structured first: Intezer AI Workflow handles the majority of alerts Anthropic advises that AI systems should begin with deterministic workflows instead of free-form reasoning. In cybersecurity, this is essential for accuracy, auditability, trust and scalability (when handling huge volumes of alerts). Intezer’s AI Workflow mode is a structured triage process designed by security experts and executed with strict consistency. It applies AI only at key decision points, not as the driver of the entire investigation. This approach provides: Deterministic, reproducible results High speed due to streamlined, parallelizable steps Lower costs because heavy reasoning is used sparingly No drift or unexpected branching Clear human oversight points Most alerts, especially well-defined ones, are fully resolved at this stage, giving SOCs broad alert coverage at low cost. Adaptive only when needed: Intezer AI Agent extends the investigation Anthropic states that agents should activate only when the structured workflow reaches uncertainty, and only after they inherit the full context. Intezer follows this exactly. AI Agent mode activates only when the Workflow cannot reach a high-confidence verdict. At that point, the agent: Starts with all evidence collected so far Avoids premature assumptions Uses tools deliberately and contextually Expands the investigation where human analysts would Surfaces deeper behavioral patterns or cross-asset correlations This ensures the agent is guided, not free-floating, and its decisions remain grounded in evidence, not guesswork. Tools the AI Agent can leverage once activated Dynamic SIEM queries EDR/XDR telemetry lookups Identity provider (IDP) investigation Behavioral analysis of processes and command lines User activity mapping Process ancestry and parent-child correlation Intezer’s historical alert database Code DNA similarity and malware lineage tracking Additional host, memory, or file-based forensics The result is deeper investigation where it matters, without unnecessary cost. Human-in-the-loop by design Intezer keeps human analysts at the center so they can review and override conclusions, and trace every decision made by Intezer. Of course, all evidence and reasoning is grounded in forensic data and is fully transparent and explainable for beginners and advanced analysts alike. This aligns with Anthropic’s principle that humans remain final decision-makers, especially in high-stakes domains like cybersecurity. How this architecture improves SOC performance Intezer’s adherence to Anthropic’s best practices produces measurable outcomes across the three most important SOC metrics: accuracy, coverage, and speed, while also reducing cost. Accuracy Intezer’s approach of combining deterministic forensics + adaptive AI = best-in-class verdict quality. The structured workflow prevents hallucinations The AI Agent only activates with strong guardrails Context inheritance ensures consistent reasoning Analysts always have visibility and control This hybrid approach dramatically reduces false positives and prevents premature conclusions. Triage of all alerts, including low-severity (where threats often hide) Because AI Workflows handle the bulk of alerts inexpensively and AI Agents only run when needed, heavy and expensive reasoning calls are minimized This frees SOCs from cherry-picking which alerts to ingest allowing them to triage and investigate them all. This is crucial for: High-volume enterprise environments MSSPs with strict SLAs Cloud-scale detection pipelines 24/7 monitoring teams You get broad alert coverage without inflating compute costs. Speed: Structured steps + adaptive depth Workflow mode resolves most alerts within seconds Agents accelerate investigations that normally take analysts hours No bottlenecks, no backlog, no manual evidence gathering The result is a SOC where every alert is investigated quickly, consistently, and with forensic depth. Table of how Intezer’s design reflects Anthropic’s guidance Conclusion: Anthropic’s Agent principles in a real SOC Anthropic’s framework for building effective agents is now influencing industries far beyond general AI research. Intezer Forensic AI SOC might be one of the strongest real-world implementations of these practices in cybersecurity. By combining: Deterministic workflows for reliable baseline investigations Zev Schonberg is a product marketing manager with years of experience in deep tech. As a lead contributor at Intezer, Zev authors research-driven analysis and thought leadership that explores how modern security operations centers can better detect, investigate, and respond to threats at scale.

I recently participated in a security leader roundtable hosted by Cybersecurity Tribe. During this session, I got to hear firsthand from security leaders at major organizations including BNP Paribas, the NFL, ION Group, and half a dozen other global enterprises. Across industries and maturity levels, their priorities were remarkably consistent. When it comes to AI-powered SOC platforms, these are the seven capabilities every CISO is asking for. 1. Trust and traceability If there was one theme that came up more than anything else, it was trust. Security leaders don’t want “mysterious” AI. They want transparency. They repeatedly insisted that AI outputs must be auditable, explainable, and reproducible. They need to show the work, for compliance auditors, for internal governance boards, and increasingly to address emerging legal and regulatory risk. Black-box decisions won’t cut it. AI must generate evidence, not just conclusions. 2. Reduction of alert fatigue (operational efficiency) Every leader I spoke with is wrestling with alert overload. Even mature SOCs are drowning in low-value notifications and pseudo-incidents. A measurable reduction in alerts escalated to humans is now a top KPI for evaluating AI platforms. Leaders want an environment where analysts spend their time on exploitable, high-impact threats, not noise. If AI can remove repetitive triage work, that’s not just helpful, it’s transformational. 4. Safe automation with human-in-the-loop for high-impact actions Most leaders are open to selective autonomous remediation, but only in narrow, well-defined, high-confidence scenarios. For example: Rapid ransomware containment Isolation of clearly compromised endpoints Automatic execution of repeatable hygiene tasks But for broader or higher-impact actions, CISOs still want human review. The tone was clear: AI should move fast where appropriate, but never at the expense of control. 5. Integration and practical telemetry coverage Every leader emphasized that an AI platform is only as good as the data it can consume. The must-have list included: Cloud telemetry (AWS, Azure, GCP) Identity providers (Okta, Entra ID, Ping) EDR/XDR SIEM logs Ticketing/ITSM Custom threat intelligence feeds They don’t want a magical AI that promises answers without good data. They want a connected system that can see across the entire environment. 6. Executive & board alignment with demonstrable ROI CISOs aren’t implementing AI in a vacuum. Their boards and executive leadership teams are pressuring them from two very different angles: Some are mandating AI adoption as a strategic priority. Others are slowing everything down with extensive governance, risk, and compliance processes. To navigate this dynamic, CISOs need clear, defensible ROI: Reduced operating costs Faster mean-time-to-respond Fewer escalations More predictable outcomes AI without measurable value is no longer acceptable. They need something they can put in front of the board and say, “Here’s the impact.” 7. Accountability and legal clarity Before enterprises allow AI to autonomously take security actions, CISOs need a fundamental question answered: “Who is accountable when the AI acts?” This isn’t just a theoretical concern. It's a gating requirement for adoption. Until there is clear guidance on liability, responsibility, and governance, many organizations will keep AI on a tight leash. Closing thoughts Across all of these conversations, the message was consistent: AI in the SOC is inevitable, but it must be safe, transparent, integrated, and measurable. CISOs aren’t looking for science fiction. They’re looking for credible, operational AI that enhances their teams, strengthens their defenses, and aligns with business realities. Mitchem Boles is the Field Chief Information Security Officer at Intezer, where he advises enterprises across industries on threat trends and modern security strategies. With nearly 20 years of experience, including leadership roles at GuidePoint Security, Critical Start, and Texas Health Resources, he has overseen complex security operations for healthcare systems, utilities, and global SOCs. Mitchem strongly advocates AI-driven security, supporting Intezer’s mission to automate alert triage and investigation so analysts can focus on high-impact threats.

Tracing a Paper Werewolf campaign through AI-generated decoys and Excel XLLs December 19, 2025 Written by Nicole Fishbein An XLL is a native Windows DLL that Excel loads as an add-in, allowing it to execute arbitrary code through exported functions like xlAutoOpen. Since at least mid-2017, threat actors began abusing Microsoft Excel add-ins via the .XLL format, the earliest documented misuse is by the threat group APT10 (aka Stone Panda / Potassium) injecting backdoor payloads via XLLs. Since 2021, a growing number of commodity malware families and cyber-crime actors have added XLL-based delivery to their arsenals. Notable examples include Agent Tesla and Dridex, researchers observed an increase of these malware being dropped via malicious XLL add-ins. Attackers typically embed their malicious code in the standard add-in export functions, such as xlAutoOpen. When a user enables the add-in in Excel, the malicious payload executes automatically, dropping or downloading a malicious payload. Some malware families use legitimate frameworks to create XLL (Excel Add-in) files. One common example is Excel-DNA, a popular open-source framework. These frameworks make it easier for attackers to build and load malicious XLLs. In some cases, they also allow threat actors to pack and execute additional payloads directly in memory. In late October 2025, a 64-bit DLL compiled as an XLL add-in was submitted to VirusTotal from two different countries. The first submission came from Ukraine on October 26, followed by three separate submissions from Russia beginning on October 27. The Russian-submitted samples were named Плановые цели противника.xll (“enemy’s planned targets”) and Плановые цели противника НЕ ЗАПУСКАТЬ.xll, which depending on context can mean either “Do NOT release the enemy’s planned targets” or “Do NOT activate the enemy’s scheduled targets.” This DLL contains an embedded second-stage payload, a backdoor we named EchoGather. Once launched, the backdoor collects system information, communicates with a hardcoded command-and-control (C2) server, and supports command execution and file transfer operations. While it uses the XLL format for delivery, its execution chain and payload behavior differ from previously documented threats abusing Excel add-ins. Through pivoting on infrastructure and TTPs we were able to link this campaign to Paper Werewolf (aka GOFFEE), a group that has been targeting Russian organizations. An XLL is an Excel add-in implemented as a DLL that Excel loads directly, usually with the .xll extension. Microsoft explicitly describes XLL files as a DLL-style add-in that extends Excel with custom functions. When a user double clicks the file with the .xll extension, Excel is launched, loads the DLL and calls its exported functions such as xlAutoOpen, initialization code, or xlAutoClose, when unloading. Often malicious XLLs embed their payload inside xlAutoOpen or through a secondary loader, so that code runs immediately once Excel imports the DLL. Excel XLL add-ins and macros differ mainly in how they execute and the level of control they provide an attacker. Macros, VBA or legacy XLM, run as scripts inside Excel’s macro engine and are constrained by Microsoft’s security model, which now includes blocking macros from the internet, signature requirements, and multiple user-facing warnings. XLLs, on the other hand, are compiled DLLs that Excel loads directly into its own process using LoadLibrary(), giving them the full power of native code without going through macro security checks. While macros rely on interpreted scripting and COM interactions, XLLs can call any Windows API, inject into other processes, or act as full-featured malware loaders. This makes XLLs far more capable and harder to analyze, and it may explain why some threat actors chose XLL-based delivery methods rather than macro-based. Loader behavior The DLL exports two functions, xlAutoOpen and xlAutoClose, both of which return zero. This behavior differs from that of legitimate XLL add-ins as well as from previously documented threats abusing the XLL format, such as those described in the most recent CERT-UA publication. In this case, the malicious logic is not tied to the typical export functions but instead is triggered through dllmain. The main function of the loader is called when fdwReason > 2 meaning that dllmain_dispatch was called with DLL_THREAD_DETACH (=3). Essentially the main function will be called when any thread in Excel that previously called into the XLL (even Excel’s own threads) exits. Triggering the malicious payload during DLL_THREAD_DETACH helps the malware evade detection by delaying execution until a thread exits. This bypasses typical behavior-based detection, which focuses on early-stage activity like PROCESS_ATTACH, making the execution appear benign at first and allowing the second-stage payload to activate covertly after the sandbox times out or AV heuristics complete. The embedded file is dropped as mswp.exe in %APPDATA%\Microsoft\Windows, then executed as a hidden process using CreateProcessW with CREATE_NO_WINDOW. Standard Output and Error is captured and redirected via anonymous pipes. If process creation succeeds, the function returns true otherwise, it cleans up and returns false. The backdoor: EchoGather We refer to this backdoor as EchoGather due to its focus on system reconnaissance and repeated beaconing behavior. The dropped payload is a 64-bit backdoor with hardcoded configuration and C2 address. It collects system information and communicates with the C2 over HTTP(S) using the WinHTTP API. The data collected by EchoGather consists of: IPv4 addresses OS type (“Windows”) Architecture NetBIOS name Username Workstation domain Process ID Executable path Static version string: 1.1.1.1 Next, EchoGather encodes that data using Base64 and sends it to the C2 using POST method. The C2 address is constructed from hardcoded strings. In the analyzed sample the C2 address was: https://fast-eda[.]my:443/dostavka/lavka/kategorii/zakuski/sushi/sety/skidki/regiony/msk/birylievo This transmission occurs in an infinite loop with randomized sleep intervals between 300–360 seconds. In all of its C2 communications, EchoGather uses the WinHTTP API. It supports various proxy configurations and is designed to ignore SSL/TLS certificate validation errors, allowing it to operate in environments with custom or misconfigured proxy and certificate settings. Supported commands EchoGather supports four commands. All outgoing communication with the C2 is encoded using standard Base64. When a command is received from the C2 the first 36 bytes contain the request ID, it’s a unique identifier that is being used when the backdoor needs to send the information is several packages. 0x54 Remote Command Execution EchoGather first extracts the request ID, followed by the command that needs to be executed. It then decrypts the string cmd.exe /C %s using a hardcoded XOR key (0xCA), which serves as a template for command execution. Using this template, it executes the specified command via cmd.exe. The output of the command is captured through a pipe and sent back to the C2 server, with the request ID prepended to the response. 0x45 Return Configuration Sends the embedded configuration structure to the C2. 0x56 File Exfiltration The backdoor begins by extracting a request ID and the name of the file to be exfiltrated. It opens the specified file, determines its total size, and calculates how many 512 KB chunks are required for transmission. A transfer header containing metadata about the chunk count and size is then sent to the C2 server. In response, the backdoor receives the request ID used to identify the session. The file is read and transmitted in chunks, with each chunk containing the request ID, chunk index, file tag, data length, and raw file data. 0x57 Remote File Write EchoGather receives a filename from the C2 and writes the incoming data chunks to the system, reconstructing the file as the chunks arrive. Infrastructure analysis During our research we found two domains that were used by the threat actors. IP Resolutions for fast-eda.my The domain was registered on September 12, 2025. The very first resolution was between September 12th and 14th, the domain was resolved to 199.59.243[.]228. After that and until November 26th all of the resolutions were on Cloudflare instances. From September 18th to November 24th the domain was resolved to 172.64.80[.]1 On November 27th it was resolved to 94.103.3[.]82 the address is connected to Russia based on geolocation. When we looked up the related files to this domain on VirusTotal, we found 7 files. Two of them are powershell scripts that load the backdoor: mswt.ps1 and the second one wasn’t submitted with a name. The two scripts are identical, including their execution flow. Both first decode two Base64-encoded files: a PDF document and the EchoGather payload. The PDF is opened, while the payload is executed in the background. The document appears to be an invitation, written in Russian, to a concert for high-ranking officers. However, the PDF is AI-generated and contains several noticeable inconsistencies. For instance, the stamp in the lower right corner appears to be an AI-generated attempt at recreating Russia’s national emblem, the double-headed eagle, but the result resembles a distorted or bird-like figure rather than the intended symbol. The text also includes several errors. Some Cyrillic letters are incorrect, for example, the letter Д is used in place of Л in multiple instances, and the word праздиика is a misspelled version of праздника. Additionally, the phrase «с глубоким уважением приглашает» (translated as “with deep respect invites (you)”) is unnatural and not idiomatic in the context of formal Russian invitations. IP Resolutions for ruzede.com First seen on 2025-05-21, resolved to 162.255.119[.]43 and later to 5.45.85[.]43 until October 2nd. On October 2nd it was resolved to IP addresses in Cloudflare. From October 4th to November 26th the domain was resolved to the same address seen in the previous domain: 172.64.80[.]1 On November 26th it was resolved to 193.233.18[.]137 in Russia based on geolocation. The ip address is linked to different malicious domains. Using VirusTotal, we pivoted on the domain ruzede[.]com, and we identified a RAR archive that exploits a known vulnerability, CVE-2025-8088, a vulnerability in WinRAR that involves the abuse of NTFS alternate data streams (ADSes) in combination with path traversal. This flaw allows attackers to embed malicious content within seemingly harmless filenames by appending ADSes that include relative path traversal sequences. The archive contains a file named Вх.письмо_Мипромторг.lnk:.._.._.._.._.._Roaming_Microsoft_Windows_run.bat When the archive is opened, WinRAR fails to properly sanitize these ADS paths and extracts the hidden data streams, placing them in unintended or sensitive locations such as %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup. The phrase “письмо Мипромторг” is misspelled; the correct form is “письмо Минпромторга.” This term refers to an official letter or communication issued by the Ministry of Industry and Trade of the Russian Federation (Минпромторг России). The same misspelling error is in the archive file name: Вх.письмо_Мипромторг.rar. Essentially the file in the archive is a batch script that launches a hidden PowerShell process. This process navigates to a user-specific AppData directory, then downloads a PowerShell script named docc1.ps1 from a remote URL (https://2k-linep[.]com/upload/docc1.ps1) and saves it to the current working directory. The script is then executed via a new PowerShell instance with execution policy restrictions bypassed. The downloaded script (docc1.ps1) extracts both a PDF file and an EchoGather payload, using a technique similar to the one described previously. However, in this instance, the embedded PDF differs from earlier samples. This document is allegedly sent from the deputy of the Ministry of Industry and Trade of the Russian Federation, asking for price justification documentation under the state defense order, focusing on violations of deadlines and reporting on pricing approval processes. The companies listed with their emails on the top right side of the first page (Almaz-Antey, Shvabe, and the United Instrument-Making Corporation) are major Russian defense-industry and high-technology enterprises, and they might be the intended recipients of this decoy document. The same vulnerability was used by several threat actors including RomCom (Russia-aligned) and Paper Werewolf, a cyberespionage group targeting Russian organizations and active since 2022. In early August, BI.ZONE Threat Intelligence published a report about an ongoing campaign of Paper Werewolf that exploits CVE-2025-6218, affects WinRAR versions up to and including 7.11 and enables directory traversal attacks that allow malicious archives to extract files outside their intended directories. A second zero-day, at the time, vulnerability that abuses ADSs for path traversal. The report doesn’t mention CVE-2025-8088, but based on the description we assume that is the same vulnerability. The interesting part is that we can see similarities between the decoy documents from the report to the document above. First, the filename of the decoy document in the report is запрос Минпромторга РФ.pdf (Request of the Ministry of Industry and Trade of the Russian Federation.pdf) no misspellings in the filename. It refers to the same office. The document asks to assess the impact of a specific government resolution on production capacities of subsidy recipients. Next, both documents share the same template and structure: red stamp on the left side, followed by the same information about the office, the date and the request id. Both documents contain a request for information to be submitted to a government-affiliated organization. Attribution Based on the shared infrastructure, such as the ruzede[.]com domain, as well as notable similarities in decoy document construction and the exploitation of the WINRAR vulnerability that leverages ADSs, we attribute this campaign to the Paper Werewolf (aka GOFFEE) threat group. The recent use of XLL files suggests that the group is experimenting with new delivery methods while continuing to rely on established infrastructure, possibly in an attempt to evade detection. In addition, the use of a new, yet simple, backdoor may indicate an effort to improve and evolve their toolset. Summary It’s less common to see public reporting on threats targeting Russian organizations, which makes this campaign worth highlighting. The threat actor appears to be actively exploring new methods to evade detection, including the use of XLL-based delivery techniques and newly developed payloads. These changes suggest an effort to enhance their capabilities. However, there are still clear gaps in both technical execution and linguistic accuracy, indicating that their tradecraft is still developing.

Security teams that rely on Microsoft know the power of a deeply integrated security stack. Today, we’re proud to announce an important milestone that further strengthens that ecosystem. Intezer has been named a top-tier Solutions Partner in the Microsoft AI Cloud Partner Program (MAICPP), a designation reserved for solutions that meet Microsoft’s highest standards for security, architecture, and seamless cloud integration. This recognition follows a successful Microsoft technical audit and certifies the Intezer Forensic AI SOC platform as trusted, Microsoft-validated software designed to deliver real security outcomes for modern SOC teams. Join AI SOC Live on January 6th to see how to maximize your Microsoft Security investment with Forensic AI SOC. January 6th | 9am PT | 12pm EST. Strengthening Microsoft-driven SOCs with Forensic AI Microsoft security tools generate powerful signals, but signals alone don’t equal outcomes. SOC teams still face alert overload, limited context, and the constant risk that real threats hide in low- or medium-severity alerts. The Intezer Forensic AI SOC platform was built to solve this problem. Intezer strengthens the outcomes of Microsoft-driven SOCs by combining agentic AI with automated forensic investigation, enriching Microsoft alerts with deep technical evidence and cross-platform context. The platform investigates alerts from and across: Microsoft Defender for Endpoint Microsoft Defender for Identity (Entra ID) Microsoft Defender for Office 365 and reported phishing Microsoft Sentinel Microsoft Defender for Cloud Non-Microsoft security tools across endpoint, identity, cloud, email, and network environments Instead of triaging only “high severity” alerts, Intezer investigates every alert with automated querying of Microsoft Sentinel, whenever needed, to enrich alerts, correlate logs, and validate activity. This provides visibility into every incident without manual lookups or switching tools. How Intezer delivers better SOC outcomes on Microsoft 24/7 AI-powered triage and investigation Intezer automatically triages and investigates 100% of alerts, including low- and medium-severity alerts that are commonly ignored. By mirroring how expert human analysts investigate incidents, using multiple AI models combined with deterministic forensics, Intezer delivers speed without sacrificing accuracy. Less than 4% alerts escalated, higher confidence decisions Across Microsoft and non-Microsoft alerts, fewer than 4% are escalated to human analysts. Each verdict is backed by forensic evidence, reducing noise, eliminating guesswork, and enabling analysts to focus only on what truly matters. Faster response with native Microsoft actions Intezer enables automated remediation directly through Microsoft tools, including: Device isolation via Defender for Endpoint User lockout through Entra ID Email quarantine in Defender for Office 365 Interactive response via Microsoft Teams This tight integration allows teams to move from alert to action in minutes, without switching tools or workflows. Built to maximize the value of Microsoft security investments “This designation reflects our commitment to helping organizations get the most out of their Microsoft security investments,” said Itai Tevet, CEO and co-founder of Intezer. “As a top-tier Solutions Partner in the Microsoft AI Cloud Partner Program, we deliver AI-powered, forensic-grade investigations that strengthen the security outcomes of SOC teams using Defender, Sentinel, and the broader Microsoft Security Suite. We help teams move from alerts to clear, confident decisions in minutes.” Intezer customers can also purchase directly through the Microsoft Azure Marketplace and apply existing Azure credits, simplifying procurement and accelerating time to value. What the MAICPP designation means for security teams The Microsoft AI Cloud Partner Program recognizes partners whose solutions are proven to work at scale across the Microsoft Cloud. Achieving top-tier Solutions Partner status signals that Intezer: Meets Microsoft’s highest standards for security, reliability, and architectural excellence Integrates deeply and natively across the Microsoft Security Suite Delivers validated customer impact for organizations operating on Microsoft infrastructure For customers, this designation provides confidence that Intezer is not just compatible with Microsoft security, but purpose-built to extend and elevate it. Why this matters now As SOCs face increasing alert volumes, tighter budgets, and a growing shortage of skilled analysts, automation alone is no longer enough. Security teams need forensic-grade AI that can explain why an alert matters, not just label it. The MAICPP designation confirms that Intezer delivers exactly that: Enterprise-grade accuracy Microsoft-validated integrations Proven SOC efficiency at scale For organizations running on Microsoft, Intezer is now officially recognized as a trusted partner to help transform alerts into outcomes. Learn more about Intezer Forensic AI SOC for Microsoft or get started today through the Azure Marketplace.

A practical checklist for discovery, migration, and operational success, designed for CISOs and SOC leaders evaluating a move to Google SecOps. The post Google SecOps migration checklist appeared first on Intezer .

Top 16 AI SOC Tools for 2026: SOC Automation Compared April 6, 2026 Written by Intezer TL;DR: AI SOC platforms use agentic AI to triage, investigate, and respond to security alerts across the stack. Best for enterprise coverage: Intezer; broad autonomous investigation: UnderDefense and 7AI; endpoint-native SOCs: SentinelOne. The Security Operations Center (SOC) has always been the heart of enterprise defense, but in 2026, it’s evolving faster than ever. The rise of AI-driven SOC platforms, often referred to as Agentic AI SOCs , is redefining how enterprises detect, investigate, and respond to threats. For years, security teams relied on a mix of SIEM, EDR, and MDR vendors to stay ahead of attacks. But these stacks often created their own problems: endless alert noise, long investigation times, and an overworked analyst team stuck in repetitive triage. The new generation of AI SOC platforms changes that. They leverage large language models (LLMs), enabling SOCs to automatically triage and investigate every alert in minutes, not hours. In this guide, we’ll break down the Top 16 AI SOC platforms to watch in 2026, ranked by how they balance speed, accuracy, explainability, and coverage across modern enterprise environments. “Agentic” AI refers to systems that don’t just respond, they act. In cybersecurity, anAgentic AI SOC is capable of performing end-to-end investigations, drawing conclusions, and recommending (or executing) responses based on forensic evidence and reasoning. These platforms are trained not only to summarize alerts but to understand their context, correlating data across endpoints, identities, networks, and cloud systems. The best AI SOCs of 2026 are explainable, autonomous, and fast, providing the confidence enterprises need to trust machine-led decision-making. ➡️ Learn more in our detailed guide to the agentic SOC AI SOC Platforms at a Glance The table below summarizes the key differences between the 16 platforms covered in this guide, grouped by category. We explore each one in more detail in the sections that follow. How we selected these tools: We shortlisted AI SOC platforms based on how well they autonomously triage, investigate, and respond to security alerts across an existing stack, the breadth and explainability of their coverage, and their fit for enterprise, mid-market, and specialized security operations. Enterprise Agentic AI SOC Platforms Purpose-built, vendor-neutral platforms that autonomously triage, investigate, and respond to alerts across an existing security stack, proven at enterprise and MSSP scale. 1. Intezer: Best AI SOC platform for enterprise SOCs Best for: Enterprise SOCs and MSSPs that need full alert coverage. Strengths: Forensic-depth investigation across 100% of alerts. Things to consider: Some screens present a large amount of information at once. Intezer AI SOC investigates every security alert at forensic depth and returns evidence-based verdicts. It combines a proprietary forensic toolset, including endpoint forensics, memory scanning, reverse engineering, network artifact analysis, and sandboxing, with multiple AI models and agentic reasoning. The platform triages alerts across endpoint, identity, SIEM, phishing, network, and cloud sources. It resolves most alerts autonomously, escalates fewer than 2% to analysts, and feeds investigation outcomes back into detection engineering. Intezer uses per-endpoint pricing rather than a per-alert or data-ingest model, so every alert can be investigated regardless of severity. Key features include: Endpoint alert triage: Integrates with CrowdStrike, SentinelOne, and Microsoft Defender to collect and analyze files, logs, command lines, and memory images, resolve false positives, and escalate real threats with recommended actions for review or automated remediation. Identity alert triage: Queries identity provider data from Entra ID and Okta, reviews findings against threat intelligence, contacts users for feedback, and proposes and executes the next steps to close identity-related alerts. Reported-phishing handling: Connects to Office 365 and Proofpoint abuse mailboxes, parses raw email data, scans attachments, and analyzes URLs to return a verdict with priority, classification, and context so only alerts that need a human reach one. SIEM and network triage: Analyzes IPs and URLs, correlates alerts to identify patterns, and reviews environment context across tools such as Splunk, Microsoft Sentinel, Sumo Logic, and Elastic, resolving false positives and escalating real threats. Cloud alert investigation: Integrates with SIEM, cloud workload protection tools, and Wiz to investigate cloud alerts with full log context, determine the scope of a threat, and recommend or automatically execute remediation steps. Detection engineering feedback loop: Feeds investigation outcomes back into detection rules at the source and tracks detection coverage against the MITRE ATT&CK framework to reduce noise and close gaps over time. Response actions: Executes response such as disabling users or isolating devices automatically via API or webhook, or routes them for analyst review, with on-demand access to Intezer security experts for complex incidents. Requires mature telemetry to work. Investigation quality depends on the customer’s existing EDR/SIEM health. Organizations with immature tooling won’t get full value out of the box. MITRE ATT&CK coverage has a realistic ceiling with Intezer benchmarking 60–70% as “top-tier” and flags anything higher as likely inflated. Some technique categories remain outside reliable coverage for any vendor. Focused on enterprise-size customers with a minimum of 1,000 employees. 2. UnderDefense Agentic AI SOC: Best for coverage without replacing your stack Best for: Enterprises wanting full coverage on top of existing tools. Strengths: Vendor-agnostic AI investigation plus concierge analysts. Things to consider: Outcomes depend partly on the provider's analyst team. UnderDefense delivers its Agentic AI SOC through the MAXI platform, which runs on top of an organization's existing SIEM or XDR without a rip-and-replace project. Agentic AI handles detection, triage, and enrichment, while concierge analysts own the last mile of verification and response. The platform integrates with more than 250 security tools, assigns a verdict to every alert, and reaches affected users directly over Slack, Teams, email, or SMS when it needs missing context. It can be deployed as SaaS, in the customer's own cloud, or fully on-premise and air-gapped, and it publishes per-asset pricing openly. Key features include: Vendor-agnostic integration: Connects to Splunk, Microsoft Sentinel, Google SecOps, CrowdStrike, Elastic, and more than 250 tools in total, so investigations run across the existing stack with full data portability and no forced replacement. Automated alert investigation: Auto-investigates every alert with context collection, multi-system correlation, and verification, producing structured investigation reports and reducing alert noise before anything reaches an analyst. ChatOps user verification: Reaches affected users directly through Slack, Microsoft Teams, email, or SMS to confirm anomalous activity, capturing the human context that fully autonomous systems cannot gather on their own. Concierge analyst response: Pairs the platform with a 24/7 analyst team that handles hands-on containment and incident response through the same channels, so containment does not require engaging a separate vendor. Detection logic as code: Writes detection rules in Python that are versioned, unit-tested, and deployed through CI/CD, keeping every investigative step observable and auditable rather than hidden in a black box. Built-in compliance: Maps the same security telemetry to frameworks including SOC 2, HIPAA, PCI-DSS, GDPR, NIS2, DORA, and ISO 27001, and answers posture questions in plain language through a built-in copilot for executives and auditors. Flexible deployment: Runs as SaaS, in the customer's own cloud, or fully on-premise and air-gapped on Kubernetes, with sovereign AI model support so telemetry can stay inside a jurisdiction or closed network. Limitations (as reported by users on G2): Onboarding setup effort: Some users report that initial setup requires attention before the platform is fully tuned to the environment. Integration breadth in edge cases: A small number of reviewers note limits when connecting less common or highly customized tools. Shared control of automation: Because response leans on the provider's concierge analyst team, some control over automated actions sits with the vendor rather than fully in-house. 3. 7AI: Best for autonomous, multi-agent investigation Best for: Enterprises adopting autonomous, agent-driven SOC work. Strengths: Swarming agents cover the full detection-to-response cycle. Things to consider: Newer platform with a shorter enterprise track record. 7AI is an agentic security platform whose swarming AI agents run security operations autonomously, with agents specialized by domain such as cloud, email, identity, and endpoint. Rather than following fixed playbooks, the agents reason through alerts case by case. The platform covers the full lifecycle from alert ingestion and detection through investigation, response, threat hunting, and case management. Agents enrich data, query the environment, correlate across systems, and form conclusions, then drive response actions tied to those conclusions. It is available through the AWS Marketplace. Key features include: Swarming investigation agents: Deploys domain-specialized agents that enrich data, query the environment, correlate across systems, and form conclusions with a full evidence trail, compressing work that previously took analysts hours. Intelligent detection and triage: Ingests alerts from existing security tools, applies AI-powered triage and enrichment, and surfaces context-aware conclusions so teams see actionable findings instead of raw alert volume. Conclusion-driven response: Takes automated remediation actions, such as isolating endpoints, disabling accounts, or blocking IPs, based on investigation conclusions rather than pattern matching, with one-click approval and human-in-the-loop options. Unified case management: Brings investigations, evidence, and team collaboration into a single case, auto-populating investigation summaries, correlating related alerts, and maintaining an audit trail and handoffs. Proactive threat hunting: Provides cross-system correlation, hunt suggestions, IOC extraction, and historical analysis so analysts can hunt for threats hiding in the environment once agents handle routine triage. Workflow builder: Lets teams build custom response workflows with drag-and-drop logic, conditional branching, and integrations to existing tools, without coding, to match organizational policies and procedures. Enterprise context awareness: Considers enterprise context dynamically at the time of investigation and reports on activity across the environment through real-time dashboards and scheduled reports. Limitations (based on publicly available sources): Shorter enterprise track record: As a company founded in 2024 and launched from stealth in 2025, 7AI has less history in complex, multi-SIEM enterprise environments with legacy tooling and strict compliance requirements. Tuning for reliability: Published comparisons note that innovation-driven, multi-agent architectures can require fine-tuning before teams rely on them for consistent production results. Limited independent reviews: Third-party verified customer reviews remain sparse relative to more established platforms, so buyers have fewer external data points to evaluate. 4. Conifers.ai (CognitiveSOC): Best for Tier-2 investigation and MSSPs Best for: Enterprises and MSSPs needing deep Tier-2 investigation. Strengths: Mesh of agents covering the full SOC lifecycle with context. Things to consider: Adaptive learning means onboarding takes weeks, not days. Conifers.ai builds CognitiveSOC, an agentic AI SOC platform structured as a mesh of coordinated agents that share context across five SOC functions: threat intelligence, threat hunting, detection engineering, investigation, and response. Rather than looking at alerts in isolation, the agents weave together multiple alerts, endpoint telemetry, identity signals, and business context. The platform runs on top of an organization's existing SIEM, SOAR, and XDR through a semantic layer with no data movement and no rip-and-replace, connecting to Splunk, CrowdStrike, AWS, Wiz, Abnormal, and more than 60 tools. It is built for enterprise SOCs and for the MSSPs and MDRs that serve them, with multi-tenant isolation. Key features include: Mesh-agentic architecture: Coordinates specialized agents across five SOC functions that share context and operate as one system, so investigative knowledge accumulates across incidents rather than resetting with each alert. Tier-2 investigation: Reasons through an entire investigation the way a senior analyst would, correlating signals across systems and forming a narrative about what happened, reaching a verdict with a transparent reasoning chain. Semantic integration layer: Connects to existing SIEM, SOAR, and XDR tools through a semantic layer that reads telemetry and writes findings back without moving data, connecting to more than 60 security tools. Institutional knowledge: Learns each environment's specific context and reuses it, so investigations become grounded in how a particular organization operates and improve with every incident. Threat hunting and detection engineering: Forms and scores hypotheses, runs proactive hunts across live data, and surfaces silent, noisy, or broken detections to keep coverage healthy as the environment changes. Governed response: Proposes and executes scoped, reviewable response actions within defined guardrails, with autonomy that expands gradually under human oversight and every action logged. Multi-tenant operation: Runs dozens of tenants from one place, each grounded in its own environment with data isolation and per-tenant reporting, addressing the segregation needs of MSSPs and MDRs. Limitations (based on publicly available sources): Longer time to value: The adaptive learning model means onboarding and full value are measured in weeks rather than days, so teams needing immediate Tier-1 relief may start with a narrower tool first. Thin public case studies: As a company that raised its first major round in 2025, public reference customers and independently verified before-and-after metrics remain limited. Pricing not published: Pricing is available only on request, which makes early budget comparison harder than with vendors that publish a starting price. 5. Exaforce: Best for reducing SIEM cost and load Best for: Cloud and SaaS-heavy teams cutting SIEM cost and load. Strengths: Multi-model AI on a unified data layer and knowledge graph. Things to consider: Newest entrant with limited independent validation so far. Exaforce is an agentic SOC platform built on a unified data layer and a real-time knowledge graph. Its multi-model AI engine combines data-ingestion models, behavioral machine learning, and large language models so that reasoning does not rely on a single LLM. The platform uses a fleet of agents called Exabots that detect, triage, investigate, and respond across identity, IaaS, SaaS, endpoint, email, and insider attack surfaces. Its data platform is built to replace a traditional SIEM by ingesting, normalizing, and transforming security data at scale, which reduces SIEM storage and licensing cost. Teams can operate the platform themselves or have Exaforce run it as MDR. Key features include: Multi-model AI engine: Runs several AI techniques in concert, combining data-ingestion models, behavioral machine learning, and large language models tuned for SecOps tasks, which reduces the hallucination risk of LLM-only approaches. Unified data platform: Ingests, normalizes, and transforms security data at scale to power AI-driven analysis and to replace a legacy SIEM, cutting storage and licensing costs tied to data-ingest pricing. Exabot Detect and Triage: Applies AI-powered detection to reduce the noise and blind spots of SIEM rules and automates triage to cut false positives before alerts reach analysts. Exabot Investigate: Investigates and hunts across a real-time knowledge graph without SIEM query complexity, giving analysts context and correlation without hand-writing queries. Exabot Respond: Executes automated response actions with analyst oversight, keeping humans in control of decisions while agents handle the mechanical steps of containment. Attack-surface coverage: Correlates signals across identity, IaaS, SaaS, endpoint, email, and insider attack surfaces, linking alerts to user and service-identity behavior for full-context findings. Flexible operating model: Runs as a self-operated platform for an in-house team or as an Exaforce-run MDR service using the same architecture and agents, with full visibility into every decision either way. Limitations (based on publicly available sources): Early market validation: Founded in 2023, Exaforce is the newest entrant among these platforms, and independently verified customer reviews remain limited to a small number. Conservative procurement fit: Enterprises with strict procurement standards may prefer to wait for broader peer validation before committing to a young vendor. Pricing not published: Public pricing is not available, so budget modeling requires a direct sales conversation. Emerging and Specialized AI SOC Platforms Newer, focused agentic platforms that concentrate on autonomous alert triage and investigation, often designed to layer on top of an existing SIEM or XDR. 6. Dropzone AI: Best for fast autonomous Tier-1 triage Best for: SOCs needing fast, low-friction autonomous alert triage. Strengths: Pre-trained agents deploy in about an hour with no playbooks. Things to consider: Focused on investigation, so response needs other tools. Dropzone AI is an autonomous AI SOC analyst that investigates security alerts by mimicking the reasoning process of an expert analyst. It ingests alerts from existing tools, correlates data, and produces decision-ready reports in plain English so analysts can follow the reasoning. The platform comes pre-trained on investigation techniques and integrates with more than 90 tools across SIEM, EDR, cloud, identity, and email, deploying in about an hour with no playbooks or code to build. It learns environment-specific context over time and includes bundled threat intelligence subscriptions with each deployment. Key features include: Autonomous alert investigation: Investigates every alert using expert analyst techniques, collecting evidence and correlating data across the stack, then delivers a full report with reasoning that analysts can verify step by step. Pre-trained rapid deployment: Connects to existing tools through API in about an hour with no log normalization, data migration, or playbooks, and begins investigating alerts immediately after connection. Broad integrations: Provides more than 90 ready-to-go integrations across SIEM, EDR, cloud, identity, and email, querying tools the way an analyst would and understanding each SIEM schema to pull the right data. Context memory: Learns details about the environment through analyst input and on its own, applying that context to future investigations to align results with organizational workflows and risk tolerance. Analyst chatbot: Offers a built-in chatbot for analysts to ask follow-up questions and run ad-hoc investigations without switching tools, extending the platform into Tier-2 work. Automated containment: Fires auto-containment actions when a threat is confirmed, such as blocking malicious IPs and disabling compromised accounts, and runs full blast-radius analysis on a confirmed phishing click. Bundled threat intelligence: Includes threat intelligence subscriptions with each deployment, such as CrowdStrike Falcon Intelligence and GreyNoise, plus common analyst utilities, at no additional cost. Dropzone AI is highly rated on Gartner Peer Insights, so the items below reflect the most common critical themes rather than strongly negative reviews. Limitations (as reported by users on Gartner Peer Insights): Initial tuning effort: Reviewers note an optimization phase during implementation to refine alert accuracy and reduce false positives before results stabilize. Usage-based cost model: Charges are tied to the number of investigations, which can grow at high or unpredictable alert volumes and may push teams to be selective about which alerts to ingest. Investigation-focused scope: The platform centers on autonomous investigation, so full response orchestration and detection engineering typically require pairing it with other tools. 7. Prophet Security: Best for transparent, analyst-in-the-loop investigation Best for: Teams wanting deep investigation with visible reasoning. Strengths: Agents show their full reasoning and evidence for every step. Things to consider: Relies on the quality of upstream alerts it receives. Prophet Security is an agentic AI SOC platform built by SecOps practitioners that spans alert investigation and remediation, scalable threat hunting, and continuous detection tuning. Its AI SOC Analyst instantly summarizes alerts and dynamically builds a complete investigation plan. Reasoning agents mimic the process of an expert analyst, asking probing questions and pivoting across the stack to gather evidence, then identify true positives and prioritize critical threats. The platform integrates with SIEMs, EDR, cloud providers, and other sources, and continuously ingests organizational context and analyst feedback to refine its reasoning. Key features include: Autonomous triage and investigation: Summarizes alerts and builds a dynamic investigation plan, then executes it by asking probing questions and pivoting across the stack to gather evidence the way a senior analyst would. Prioritized response: Identifies true positive alerts, prioritizes critical threats, and supports both autonomous remediation for high-confidence cases and human-in-the-loop decision points for complex ones. Transparent reasoning: Shows its work for every investigation, including the investigative plan, the queries used to retrieve information, and the evidence gathered, so analysts can validate each conclusion. Agentic threat hunter: Launches analyst-driven hunts from natural-language questions to validate hypotheses, and runs always-on and scheduled hunts to identify emerging threats that bypass existing measures. Threat hunter library: Provides a curated library of pre-codified hunt templates compatible with existing data sources so teams can operationalize global threat intelligence immediately. Bi-directional integrations: Connects to endpoint, email, identity, cloud, and data-loss-prevention sources with bi-directional communication that supports the full investigation lifecycle, not just alert ingestion. Continuous adaptation: Ingests organizational context and learns from analyst feedback on an ongoing basis, adjusting its reasoning logic to reduce noise and align with organizational policies. Limitations (based on publicly available sources): Dependence on upstream alerts: As an investigation-layer platform, its results depend on the quality and coverage of the alerts produced by the tools that feed it. Response orchestration scope: The platform centers on investigation and triage, so teams needing heavy response orchestration may combine it with additional tooling. Limited public reviews: As a newer vendor with modest market mindshare, independently verified customer reviews are still limited. 8. Radiant Security: Best for mid-market teams cutting SIEM cost Best for: Mid-market teams drowning in alert noise and SIEM cost. Strengths: Adaptive AI triages any alert type plus low-cost logging. Things to consider: Focused on triage rather than deep forensic investigation. Radiant Security is an AI SOC platform that ingests, triages, and responds to alerts from any source, with an agentic SOC analyst that investigates each alert like a senior analyst and escalates only real threats. Its adaptive AI is designed to handle alert types it has not seen before rather than being limited to predefined use cases. The platform emphasizes explainable AI, providing full traceability of its reasoning so analysts can review each escalation and dismissal for compliance. It includes integrated log management with unlimited retention at a fraction of traditional SIEM cost, and connects through more than 100 API integrations across the existing stack. Key features include: Adaptive alert triage: Triages and investigates alerts across email, endpoint, identity, network, cloud, insider threat, SIEM, WAF, DLP, OT and IoT, dark web, and supply chain, including alert types the system has not encountered before. Explainable reasoning: Attaches full traceability to every escalation and dismissal, including which data sources were queried, what patterns were detected, and why the AI reached its conclusion, for audit and compliance. One-click response: Generates tailored remediation plans for each incident that analysts can launch manually with one click or automate for future incidents, keeping analyst control over actions. Integrated log management: Stores, searches, and analyzes security logs with unlimited retention and predictable pricing, positioned to reduce logging costs relative to a traditional SIEM. Broad integrations: Connects through more than 100 plug-and-play API connectors across the existing security stack, ingesting alerts and pushing enriched information and response actions back through them. Guardrails and policies: Lets SOC teams influence the AI through guardrails, policies, and exclusions so triage and response align with organizational priorities and risk tolerance. Continuous learning: Refines detection models and response recommendations over time as analysts interact with the system, aligning increasingly with the organization's environment and priorities. Radiant Security is highly rated on Gartner Peer Insights, so the items below reflect the most common critical themes rather than strongly negative reviews. Limitations (as reported by users on Gartner Peer Insights): Reporting flexibility: Some reviewers note that the reporting and dashboarding capabilities could be more flexible for their needs. Triage-layer dependence: Because it works from upstream alerts, its behavioral analytics are lighter than platforms with direct access to raw telemetry. Depth of forensic analysis: The platform prioritizes speed through detection and mitigation, so organizations needing heavy forensics and post-incident recovery workflows may need additional tooling. 9. Qevlar AI: Best for compounding, self-improving investigation Best for: SOCs wanting investigation that compounds over time. Strengths: Graph-orchestrated reasoning that reuses past investigations. Things to consider: Investigation layer that pairs with existing detection tools. Qevlar AI is an autonomous SOC platform that turns daily security activity into a self-improving defense system. It investigates every alert across the stack, connects related activity into a single incident story, maps the full blast radius, and moves containment forward while following the customer's procedures under analyst control. Rather than letting a single LLM run the investigation, Qevlar's core is a graph orchestrator with structured, reproducible reasoning and decision paths, using LLMs only for narrow, bounded tasks such as enrichment and summarization. It connects to the existing stack via API and is in production across 1,500 organizations. Key features include: End-to-end investigation: Investigates every alert across the stack, connects related activity into a single incident story, and maps the full blast radius so analysts see a complete picture rather than isolated alerts. Graph-orchestrated reasoning: Runs on a graph orchestrator that keeps reasoning and decision paths structured and reproducible, using large language models only for bounded tasks like enrichment and summarization. Closed-loop response: Drives the next action for each outcome, including containment for malicious activity, tuning for false positives, and policy or compliance follow-up for benign violations, following defined procedures. Continuous threat hunting: Hunts autonomously for emerging threats, attacker techniques, behavioral anomalies, active exploitation, and patterns hidden across past investigations, turning each finding into action. Compounding institutional knowledge: Adapts to the environment and retains knowledge in the platform so investigations get faster and decisions more consistent regardless of analyst turnover. SOC and vulnerability linkage: Provides a shared intelligence layer so confirmed exploitation elevates vulnerable assets in the remediation queue and critical exposures become new hunt priorities for the SOC. API integration: Connects the existing tech stack via API within minutes, with results available in the customer's own console or in Qevlar, and supports on-premise deployment. Limitations (based on publicly available sources): Investigation-layer positioning: Qevlar enriches and interprets alerts rather than generating detections, so it pairs with, rather than replaces, existing detection and SIEM tooling. Newer capabilities still maturing: Some recently announced agents, such as those unifying SOC and vulnerability operations, are scheduled for general availability later in 2026. Pricing not published: Public pricing is not available, and independent third-party reviews remain limited relative to larger vendors. 10. Bricklayer AI: Best for governed, coordinated agent teams Best for: Teams wanting coordinated AI agents under tight control. Strengths: 50+ agents share context under enforced governance. Things to consider: Specialized to SOC work; less suited to broader use cases. Bricklayer AI is an agentic cybersecurity platform that deploys a coordinated workforce of AI agents into the SOC. More than 50 expert agents triage, investigate, and execute across the security stack while following approved procedures, with every action visible and auditable. The platform is built around three principles: context, coordination, and control. Agents share investigative context through a system Bricklayer calls Multi-Agent Context Engineering, collaborate with analysts in a shared workspace, and operate within enforced governance. It connects existing tools through agent-powered integrations with no coding. Key features include: Coordinated agent workforce: Deploys more than 50 out-of-the-box agents plus custom agents that triage, investigate, and execute across endpoint, identity, and cloud, assembling the right agents for each defined goal. Multi-Agent Context Engineering: Treats investigative knowledge as a structured system asset so agents inherit prior evidence, reasoning, and outcomes, preventing context from being lost as multiple agents work an investigation. Collaborative workbench: Provides a shared workspace where analysts and agents work together, with visibility into agent plans, evidence, and reasoning and the ability to question, drill down, and modify any procedure. Procedure-based workflows: Turns a defined goal into an auditable, task-based workflow that agents execute while humans oversee, so work follows approved procedures rather than isolated prompts. Enterprise governance: Enforces role-based access control, defined boundaries, and complete audit logging on every agent action, with multi-organization management and separate development, staging, and production environments. Agent-powered integrations: Connects existing security tools, data stores, and context to subject-matter-expert agents with no coding, so agents operate with awareness of the environment from the start. Cross-SOC use cases: Covers alert triage and response, incident investigation, vulnerability management, threat intelligence, and threat hunting, each adoptable independently and expandable into a broader system. Limitations (based on publicly available sources): Specialized scope: Aggregated user feedback notes that the platform's focus on SOC tasks makes it less versatile for broader applications outside security operations. Smaller vendor: Bricklayer is an early-stage company with a modest headcount and seed-stage funding, which some enterprise buyers weigh when assessing long-term support. Limited public reviews: As a newer platform, independently verified customer reviews are limited relative to established vendors. 11. Legion Security: Best for teams that want agents trained on their own workflows Best for: Teams wanting agents that learn their own workflows. Strengths: Learns analyst workflows in the browser with no integrations. Things to consider: Value depends on documented, validated analyst workflows. Legion Security is an agentic security operations platform that learns an organization's own tools, context, and processes and deploys agents optimized for that team. Its starting premise is that AI should learn how a specific SOC works before it is trusted to work on its behalf. Legion operates through the browser and observes analyst investigations, playbooks, runbooks, and past cases to turn that knowledge into agentic workflows. It runs in three modes, learning, companion, and autonomous, so autonomy is granted in phases under human oversight, and it requires no integrations to begin. Key features include: Learning mode: Observes analyst context in the browser and other sources, including investigations, playbooks, runbooks, and past cases, and turns that knowledge into reusable agentic workflows specific to the team. Companion mode: Executes complete workflows directly through analysts' browsers while maintaining full human oversight and control at every step, so analysts stay in the loop as agents act. Autonomous mode: Becomes an autonomous extension of the team once trust is established, scaling the team's own investigative expertise across every alert on the organization's terms. Zero-integration deployment: Works through the browser without building integrations for each tool, so it can operate across customized, homegrown, and legacy tools that are otherwise hard to connect. Workflow capture and reuse: Records the steps of an analyst's workflow, including data reviewed, actions taken, and judgments made, and builds reusable investigative logic that reflects in-house best practices. Phased autonomy controls: Lets teams grant autonomy in stages and always on their terms, showing exactly what it plans to do, doing it, and logging every step for review. Analyst-aligned operation: Aims to mirror how a team's own analysts think and work so agents stay aligned with existing operating rhythm rather than imposing generic logic. Limitations (based on publicly available sources): Dependence on existing workflows: Because it learns by observing analyst work, value depends on having documented and validated workflows and a learning period before autonomy. Browser-based model: Its tab-native, browser-based approach differs from API-integrated platforms and may fit some environments and tools better than others. Limited public reviews: As a newer vendor, independently verified customer reviews are limited relative to established platforms. AI SOC Within Broader Security and Automation Platforms AI SOC capabilities delivered inside an established endpoint, network, or automation platform rather than as a standalone AI SOC product. 12. SentinelOne (Purple AI): Best for endpoint-centric SOCs Best for: Enterprises invested in the SentinelOne Singularity platform. Strengths: Agentic investigation native to the Singularity platform. Things to consider: Value is tied to adopting the Singularity platform. Purple AI is SentinelOne's agentic AI security analyst, built into the Singularity platform as its reasoning layer and interface. It reasons across native and third-party data normalized to the Open Cybersecurity Schema Framework, so analysts get consistent context without switching tools or writing queries. Its Agentic Investigation capability runs analysis from alert to verdict, collecting evidence, correlating telemetry, and building the attack timeline so analysts start at the verdict rather than the raw alert. For critical threats, investigations can trigger automatically and deliver verdicts that can be acted on autonomously or by an analyst, with a full evidence chain. Key features include: Agentic investigation: Runs the analysis from alert to verdict, surfacing evidence and recommended next steps, and can trigger autonomously for critical threats so analysts begin with a completed investigation. Natural-language operations: Lets analysts query data and run investigations in plain language, translating natural language into structured queries so teams do not need to know a query syntax. Normalized cross-source reasoning: Reasons across native and third-party data normalized to the Open Cybersecurity Schema Framework, giving analysts a single consistent view of context across tools. Multi-model reasoning: Combines frontier models from Anthropic and OpenAI with SentinelOne's own models to compress investigations that previously took hours into minutes. Native platform integration: Runs inside the Singularity platform on telemetry already present across endpoint, identity, cloud, and third-party data, with activation by a single click and no separate deployment. Workflow documentation: Documents decisions, generates summaries and emails, and saves investigations in shared, exportable notebooks so teams can collaborate and hand off work. Community verdict: Draws on similarity analysis and verdicts from SentinelOne's managed services community to indicate which alerts to prioritize based on real investigations. Purple AI is delivered as part of the SentinelOne Singularity platform, so the reviews below reflect experience with the broader platform. Limitations (as reported by users on G2): Premium pricing: Reviewers describe the platform as a premium product with pricing on the higher side, which can be a factor for smaller organizations. Setup and tuning effort: Users note that initial setup and policy configuration can be complex and time-consuming in larger or more diverse environments. Learning curve: Some reviewers report a learning curve when first working with the feature-rich console before it becomes routine. 13. CrowdStrike (Charlotte AI): Best for Falcon-standardized teams Best for: Organizations already standardized on CrowdStrike Falcon. Strengths: Agentic triage and response native to the Falcon platform. Things to consider: Depth is tied to the Falcon ecosystem and its data. Charlotte AI is CrowdStrike's agentic AI security analyst and the interface and orchestration engine for the Falcon platform. It combines generative and agentic AI trained on decisions from CrowdStrike's managed detection and response team, and it powers chat, embedded insights, and agentic operations across detections, investigations, and response. Its Detection Triage agent automatically analyzes endpoint, identity, and cloud detections within seconds of creation and classifies them, while its Response agent drives investigations by asking and answering the questions an analyst would. Charlotte Agentic SOAR orchestrates CrowdStrike, custom-built, and third-party agents together under human command. Key features include: Detection triage agent: Automatically analyzes every new endpoint, identity, and cloud detection within seconds, assigns a priority, classifies it as true or false positive, and recommends a course of action. Agentic response: Drives investigations by asking and answering the questions a seasoned analyst would in a dynamic workspace, and lets analysts inject context and set priorities in real time. Charlotte AI AgentWorks: Lets teams build, test, and deploy custom security agents using natural language with no code, within the Falcon platform and with enterprise governance built in. Charlotte Agentic SOAR: Orchestrates CrowdStrike, custom, and trusted third-party agents as one system across prevention, detection, investigation, and response, combining structured automation with agentic reasoning. Mission-ready agent library: Provides purpose-built agents for tasks such as malware analysis, exposure prioritization, threat hunting, and detection rule generation, delivered natively through Falcon modules. Natural-language platform access: Lets analysts interact with the Falcon platform in plain language to ask questions and get context-aware answers without manual compilation or complex syntax. Governance and auditability: Operates within role-based access controls, inspectable source data, and audit-ready logs, with bounded autonomy that keeps actions user-authorized and traceable. Limitations (as reported by users on G2): Capabilities still maturing: Reviewers note that some functionality is still in development across certain modules, so teams need to track the roadmap as features are released. Ecosystem dependence: Charlotte AI's depth comes from the Falcon platform and its data, so its full value is realized by organizations already standardized on CrowdStrike. Credit-based consumption: Pricing is usage-based on credits, which requires monitoring consumption as agentic actions scale across the environment. 14. Vectra AI: Best for network and identity threat detection Best for: Enterprises prioritizing network and identity visibility. Strengths: Behavioral detection across network, identity, cloud, and SaaS. Things to consider: Specialized in network and identity rather than full stack. Vectra AI is an AI-driven detection and response platform for hybrid and multi-cloud enterprises that delivers integrated signal across public cloud, SaaS, identity, and data-center networks in one platform. Its patented Attack Signal Intelligence analyzes attacker techniques across the kill chain to distinguish real attacks from noise. The platform has extended from network detection and response into AI SOC territory with an agentic layer whose AI agents continuously triage, correlate, and prioritize genuine threats. It enriches existing SIEM, EDR, and XDR investments rather than requiring a rip-and-replace, and provides Model Context Protocol servers that give AI agents access to live security data. Key features include: Attack Signal Intelligence: Applies behavioral AI refined over more than a decade to understand attacker techniques across the kill chain, surfacing lateral movement, identity-based attacks, and living-off-the-land activity. Hybrid coverage: Delivers integrated signal across public cloud on AWS, Azure, and GCP, SaaS, Active Directory identity, on-premise data centers, and OT and IoT within a single platform. Agentic SecOps layer: Runs AI agents that continuously triage, correlate, and prioritize genuine threats in real time, including a triage agent for false-positive investigation and a stitching agent for cross-domain correlation. Entity-centric prioritization: Prioritizes entities under active attack with risk scoring so analysts know where to start and which activity is most relevant and urgent across domains. Stack enrichment: Enriches existing SIEM, EDR, and XDR investments with high-quality network and identity signals rather than requiring teams to replace their current tools. Model Context Protocol integration: Provides Model Context Protocol servers that give AI agents programmatic access to live security data for automated triage and correlation. Identity-focused detections: Detects identity threats such as MFA bypass, token theft, privilege escalation, and suspicious activity across Microsoft 365 and Azure AD environments. Limitations (as reported by users on G2): Learning curve: Reviewers note that the platform is terminology-heavy and requires familiarity with network detection and response to interpret and act on its signals. Alert noise in some deployments: Some users report a higher false-positive or benign-alert rate that needs tuning, particularly through the managed detection service. Specialized coverage: The platform is strongest in network and identity telemetry rather than full-stack SOC coverage, so teams may pair it with endpoint and other tools. 15. BlinkOps: Best for teams building their own automation Best for: Teams building custom automation across security operations. Strengths: End-to-end agents on a broad automation platform. Things to consider: Realizing full value involves building and tuning workflows. BlinkOps is an agentic security operations platform on which AI SOC is one solution among many. It deploys micro-agents across the full incident lifecycle, from triage and investigation to response and remediation, that correlate data across the stack, apply contextual reasoning, and surface only what needs human judgment. The platform lets teams start with plug-and-play agents and prebuilt workflows, customize them, or build their own with its Agent and Workflow studios, and it lets security leaders set the level of autonomy and where humans stay in the loop. The same foundation also supports threat hunting, threat intelligence, and malware analysis solutions. Key features include: Micro-agent incident handling: Deploys micro-agents across the full lifecycle, from triage and investigation through response and remediation, correlating data across the stack and surfacing only what needs human judgment. End-to-end investigation: Goes beyond triage into deep investigation, malware analysis, timeline reconstruction, blast-radius mapping, and full remediation within one platform. AI-powered case management: Centralizes the investigation lifecycle in one workspace that pulls context automatically and explains findings, blending autonomous remediation with human-in-the-loop oversight. Agent and workflow studios: Lets teams customize prebuilt agents and workflows or build their own from scratch, so automation can be tailored per alert type and environment rather than taken as-is. Configurable autonomy: Lets teams define what agents can and cannot do, limit scope, restrict actions, and set confidence thresholds and approval gates so agents operate only within set rules. Governance and audit: Applies granular role-based access control, approval gates, and full audit trails on every agent action, logging each decision and reasoning step for compliance and review. Broad platform scope: Runs AI SOC alongside prebuilt solutions for threat hunting, threat intelligence, and malware analysis on the same foundation, so teams can expand across security operations. Limitations (based on publicly available sources): Build-your-own effort: As an automation-first platform, realizing full AI SOC value involves building and customizing workflows and agents rather than deploying a finished SOC out of the box. Documentation depth: Some users note that the documentation could be more detailed, though many find the platform largely self-explanatory. Occasional portal downtime: A small number of reviewers report occasional portal unavailability during platform updates. 16. Torq (HyperSOC): Best for hyperautomation-driven SOCs Best for: Teams building an autonomous SOC on a hyperautomation engine. Strengths: Multi-agent system on a mature automation platform. Things to consider: Steep learning curve for advanced workflow building. Torq's AI SOC platform combines agentic AI with hyperautomation to triage, investigate, and respond to threats. Its HyperSOC product is an autonomous SOC that fuses the speed and consistency of automation with adaptive AI, handling the incident lifecycle from detection to triage, investigation, and remediation with minimal human intervention. At its center is Socrates, an agentic AI SOC analyst that acts as an orchestrating agent coordinating a multi-agent system of Runbook, Investigation, Remediation, and Case Management agents. The platform runs on a hyperautomation engine with more than 300 pre-built integrations and thousands of ready-to-use automation steps. Key features include: Socrates multi-agent system: Coordinates specialized agents for runbooks, investigation, remediation, and case management under an orchestrating agent that share context in real time to handle Tier-1 and many Tier-2 tasks. Investigation agent: Automatically analyzes alerts, enriches them with context, and identifies root causes, so cases arrive with analysis attached rather than as raw alerts. Runbook agent: Converts natural-language descriptions into automated workflows with no code, accelerating the creation of response procedures for the SOC. Hyperautomation engine: Provides more than 300 pre-built integrations and thousands of ready-to-use automation steps across SIEM, EDR, cloud, identity, and threat intelligence, extensible through a no-code and low-code builder. Autonomous case management: Creates and prioritizes enriched security cases with AI-generated summaries, orders them by severity and ownership, and manages the case lifecycle from detection to resolution. Human-in-the-loop remediation: Keeps critical decisions and actions under human control, letting analysts intervene in any sensitive automated process so actions align with organizational policy and risk tolerance. Open model and integration architecture: Runs in a serverless, cloud-native environment, supports custom no-code connectors that discover schemas, and can use Torq's models or customer-chosen frontier models. Limitations (as reported by users on G2): Learning curve: Reviewers note that Torq has a steep learning curve and that building highly customized workflows requires users to be well trained on the platform. Integration configuration: Some users report that connecting certain applications can be complicated to configure during setup. Support responsiveness: A few reviewers note that customer service response times can be slow at times. The future of Agentic AI SOCs The next evolution of SOC automation goes beyond alert management. In 2026 and beyond, Agentic AI SOCs will not only investigate but also take verified actions, quarantining hosts, isolating sessions, and orchestrating containment based on evidence and policy. This shift demands trust, explainability, and speed. Enterprises can no longer afford “black-box” AI that delivers vague suggestions. They need platforms capable of forensic reasoning, auditability, and full coverage, exactly what Intezer Forensic AI SOC delivers. SOC leaders who adopt these systems early will gain measurable efficiency, lower operational risk, and stronger security posture, without expanding headcount. ➡️ Learn more in our detailed guide to Agentic SOC. Final thoughts AI SOC platforms are transforming how enterprises defend against modern threats. While each platform on this list has unique strengths, Intezer stands out as the clear enterprise choice for those who demand accuracy, speed, and complete visibility. See how Fortune 500 SOCs cut through the noise, reduce risk, and reclaim their time with Intezer.

With threat actors weaponizing AI, security leaders are realizing that an AI SOC with proven, forensic capabilities, is an absolute must. The post Introducing Intezer Forensic AI SOC appeared first on Intezer .

tl;dr Greater productivity ≠ greater security outcomes. Kinda like why being able to accelerate from 0-60 MPH doesn't help when the ice is cracking under your wheels. And now, the full version. AI SOC shouldn’t just “augment workflows”, that’s a productivity-locked perspective. The goal and the delivery capability that exists right now is to deliver full-scale enterprise triage of 100% of alerts with forensicly-accurate verdicts. That looks like streamlined triage, explainable verdicts, measurable accuracy, and operational resilience. There’s already an AI SOC platform that has operationalized what Gartner calls “emerging”. While recent Gartner reports on “AI SOC Agents” and “SecOps Workflow Augmentation” succeed in elevating the conversation, they also reveal how incomplete that conversation still is. Both documents frame AI in the SOC as a promising but premature experiment, a toolset meant to make analysts more productive, not organizations more secure. That framing misses the point. AI isn’t about automation for automation’s sake; it’s about turning expert knowledge, data, context, and expertise into repeatable, scalable decision-making that covers every alert with confidence and context. The bias in today’s AI SOC conversation Gartner’s reports argue that AI SOC agents should be treated as “workflow augmentation tools” to reduce analyst fatigue and improve response efficiency. They recommend cautious adoption, structured pilots, and human-in-the-loop validation. Pragmatic? When LLMs are relied upon solely, sure. But the underlying assumption that enterprise-proven AI is not yet mature enough to deliver reliable outcomes is outdated. In practice, this mindset anchors the market in productivity metrics, not security performance. It evaluates how efficiently teams work, not how effectively they defend. The focus stays on “mean time to detect” and “mean time to respond,” rather than the more critical questions: Are ALL alerts being triaged? Are verdicts, not just investigations, consistently accurate? Are we actually reducing risk, not just improving the process? Are alerts triaged in seconds & minutes for true containment & response? That’s where the emerging class of true AI SOC platforms breaks away from the Gartner lens. Workflow augmentation isn’t security The distinction matters. Augmentation is an operational improvement; outcomes are a security transformation. Most vendors today build tools that accelerate investigation but still depend on human oversight for every meaningful decision. Those are SOAR 2.0 platforms: automation-centric, workflow-obsessed, and still fundamentally enrichment, not triage. A true AI SOC, by contrast, triages every alert across the stack autonomously, determines a verdict with auditable reasoning, and escalates only when necessary, typically less than four percent of the time. This isn’t a co-pilot; it’s a teammate that already performs at the level of a seasoned analyst and identifies the needles without the haystack. This is incredible for the SOC analysts that are focused on looking at real alerts. Security outcome execution is the critical requirement any true AI SOC should provide: Resolve millions of alerts monthly across distributed environments with <4% escalation rates. Deliver verdict accuracy above 97.7% through hybrid deterministic and AI reasoning. Provide explainable decisions, validated by periodic human review and forensic evidence. Uncover real threats in seconds & minutes, not hours. This isn’t augmentation; it’s execution. Read more about properly framing the AI SOC conversation. The “emerging” technology that’s already operational Gartner describes AI SOC agents as an “emerging technology” that promises to evolve beyond playbook-driven automation. The irony is that enterprise SOCs are already running on these systems today. Fortune 10 environments and thousands of organizations worldwide are triaging every single alert, not just the critical and high-severity ones, through AI that emulates human reasoning at scale. These systems don’t “pilot” AI; they operationalize it. They deliver 24/7 SOC capability, instant triage, and consistent decision-making grounded in explainable logic, not black-box inference. They prove that an AI SOC is no longer a future-state concept. It’s production-grade infrastructure that’s rewriting what operational maturity means, and has been for years now. The difference between Gartner’s caution and what’s happening in practice is simple: proof. Measuring what actually matters The reports fixate on efficiency → MTTD, MTTR, analyst satisfaction, but those metrics only tell half the story especially for antiquated SOCs. The next generation of AI SOCs defines success through security outcome metrics, including: Total alert coverage – Every alert analyzed, across all severities and sources. Verdict accuracy – The supermajority of decisions must be right, consistently and explainably. Escalation rate – Only the rarest cases should reach human review. Explainability – Every verdict is clearly backed by evidence: memory scans, forensic traces, and contextual reasoning. Feedback velocity – Every corrected verdict feeds back into the detection logic, closing the learning loop. When you measure what truly matters, accuracy, coverage, trust, the difference between AI that “helps” and AI that defends becomes obvious. Why “AI SOC Agent” ≠ “AI SOC Platform” The reports conflate two very different things. An “AI SOC agent” is a single use case, an assistant. An “AI SOC platform” is a full operating model: triage, investigation, and response fused into a continuous feedback loop back to detection engineering. One optimizes efficiency; the other drives security transformation. That’s the real inflection point the industry is standing at. SOCs that treat AI as a productivity booster will get marginal gains, which is a great thing for the industry. SOCs that rebuild around AI as a core operating principle will experience exponential gains with real risk reduction. In other words: this isn’t about speeding up analysts, it’s about scaling their expertise across the entire alert surface. From AI promise to proof The challenge now isn’t technology, it’s perception. The AI SOC has already proven it can outperform legacy models built on manual triage and brittle playbooks. It has shown that full alert coverage, explainable verdicts, and continuous learning can coexist with human oversight and compliance. The industry doesn’t need another year of pilots to “validate the promise.” It needs a new standard of performance. The next evolution of the SOC will be measured not by how well it augments workflows, but by how confidently it can: Detect and triage every signal. Deliver verdicts with explainable evidence. Quantify accuracy in measurable, repeatable terms. Strengthen analyst trust through transparency. That’s the AI SOC outcome model, here today. Final thoughts Gartner’s perspective is valuable for shaping the taxonomy of an emerging market. But the reality on the ground has already overtaken the research. The world doesn’t need another whitepaper on “potential.” It needs proof of performance, and it exists. The future SOC isn’t augmented. It’s autonomous, accurate, and accountable for strategic security outcomes that CISOs and leaders require, either now or in the next few months with the executive leadership push to operationalize AI. The world’s largest enterprises today already benefit from the real market-defining traits of a forensic AI SOC. To learn more about Intezer’s Forensic AI SOC platform, schedule a demo today!

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. Roy leads the development of Intezer's AI SOC technology, leveraging over 15 years of expertise in security architecture, engineering, and incident response. Passionate about simplifying cybersecurity, Roy ensures Intezer’s AI-driven platform delivers fast, accurate, and reliable results, setting a new standard in automated SOC while continually expanding capabilities to address clients’ key challenges.

Gartner’s recent Innovation Insight: AI SOC Agents report is an encouraging signal that the concept of an “AI-powered SOC” has reached mainstream awareness. The report recognizes the potential of AI technologies to transform how security operations centers function, especially in augmenting analysts through automation and intelligent workflows. Yet, while Gartner’s analysis succeeds in capturing the momentum of this space, it falls short in clarifying how and where AI actually fits within the security operations stack. By treating “AI SOC” as a monolithic, undifferentiated category, the report overlooks the crucial distinctions between detection, triage and response, each of which requires a very different kind of AI capability and delivers very different value. A closer look at Gartner’s analysis Gartner’s report provides a valuable overview of how AI SOC can assist with detection, alert investigation, and even response recommendation. We wholeheartedly agree with Gartner’s advice that CISOs should evaluate which security activities are “volumetric, troublesome, or low-performing, and which would benefit the most from augmentation with the application of AI”. However, presenting all of the AI SOC functions (and vendors) as part of a single undifferentiated security ecosystem, can be confusing. This broad framing misses the fact that an AI model designed to improve SIEM detection logic operates on entirely different data, architecture, and feedback loops than one built to support analyst decision-making or response automation. The result is a flattening of a nuanced market into one monolithic category, useful for taxonomy, but not for decision-making. For CISOs, this lack of segmentation makes it hard to answer the key strategic question: Where should we apply AI first to get tangible operational value? By contrast, our view is that organizations should start by identifying which part of their operations needs augmentation most, then evaluate AI solutions purpose-built for that domain. A clearer way to frame the AI SOC market To understand where AI truly fits in and how it can deliver measurable outcomes, it helps to zoom out and look at the broader security operations stack. As we described in a previous blog post, "Making sense of the AI SOC market", we see three main layers where AI can add value: Detection (SIEM, XDR) The first layer converts raw telemetry into actionable alerts. Here, AI can strengthen correlation logic, improve detection models, and reduce false positives. This is largely about data pattern recognition and automation of repetitive analysis. Triage and Investigation (SOC / MDR) The middle layer is where human analysts determine which alerts are real incidents worth escalating. This is where AI can truly emulate analyst reasoning, gathering context, cross-referencing intelligence, and presenting likely root causes. Done well, AI here acts as a co-analyst, not a replacement. Response and Case Management (SOAR) The final layer coordinates remediation and manages incident workflows. AI can accelerate playbook creation, automate routine case handling, and improve overall response time through dynamic decision logic. Each layer offers opportunities for AI—but they are fundamentally different problems to solve. When vendors use the term “AI SOC” without specifying which layer they’re addressing, it creates confusion and unrealistic expectations. A more practical evaluation framework To move the conversation forward, we recommend a more structured approach to evaluating AI SOC solutions. Step 1: Identify your target layer Ask: Which layer of our operations needs the most improvement. Is it detection (SIEM/XDR/Cloud), triage (SOC/MDR), or response (SOAR)? This helps narrow the field to the right class of solutions rather than chasing the broad “AI SOC” label. Step 2: Define measurable outcomes Especially for alert triage and investigation (which is usually handled by an internal SOC or external MDR), establish metrics to compare performance, such as: Reduction in mean time to detect (MTTD) Noise reduction rate Scale of alert coverage Consistency across SOC shifts or analyst tiers Triage accuracy These metrics allow organizations to compare vendors on tangible outcomes, not vague AI promises. Step 3: Evaluate transparency and integration An effective AI SOC solution should clearly explain its reasoning, integrate easily with your existing tools, and allow human oversight. The goal is augmentation, not opacity. Read more about why the "AI SOC agent" narrative misses the point. The way forward Gartner deserves credit for bringing visibility to an emerging market, but their analysis underscores how early and fluid this space still is. The future of the AI SOC isn’t one product category. It's a set of AI capabilities applied intelligently across the detection–triage–response continuum. Organizations that treat AI as a modular capability rather than a monolithic product will see the most success. The key is knowing your operational priorities and matching them to the layer where AI can have the greatest impact. Conclusion AI is not a magic “SOC-in-a-box.” It’s a set of technologies that, when properly targeted, can transform specific parts of security operations. Gartner’s latest report captures the enthusiasm, but not yet the structure, of this market. At Intezer, we believe the path forward starts with clarity. Understanding the distinct layers of the SOC, the role AI plays in each, and the outcomes that matter most. Only then can organizations cut through the noise and choose the right AI SOC partner for their needs. Explore how Intezer delivers complete peace of mind for your security operations!

What is an AI SOC? An AI SOC (Security Operations Center), often called an agentic SOC, is a proactive security operations model that integrates artificial intelligence to automate threat detection, triage, and incident response. Unlike basic AI assistants that only summarize alerts, an AI SOC uses autonomous agents to investigate and take action across your entire security stack. An AI SOC helps security organizations operate more efficiently by increasing investigation capacity without requiring proportional growth in headcount. By automating repetitive work such as alert triage, evidence collection, and initial analysis, it allows analysts to spend more time on high-value activities like threat hunting, incident response, and improving detections. How an AI SOC works: Automated alert triage: AI analyzes and prioritizes alerts, distinguishing real threats from false positives to help analysts focus on genuine incidents. Enhanced threat hunting: AI can correlate data across different security dimensions—such as network, email, and endpoint activity—to uncover sophisticated and coordinated attacks that might be missed by human analysts. Accelerated incident response: AI can initiate automated response actions, like isolating compromised devices or blocking malicious traffic, to contain threats faster. Adaptive workflows: AI agents can dynamically adjust response strategies based on situational context and past outcomes, improving efficiency over time. Natural language interaction: Some systems allow analysts to use natural language to generate reports, create automation workflows, and ask complex questions of their data. This is part of an extensive series of guides about cybersecurity. The Need for an AI SOC: What Problems Does It Solve? Alert Overload and Triage Bottlenecks Security teams face a relentless influx of alerts generated by disparate tools—many of which are false positives or lack sufficient context. Manual triage becomes unsustainable as teams waste valuable cycles sifting through irrelevant or low-priority alerts. This constant noise leads to alert fatigue, where genuine threats can slip through unnoticed due to sheer volume and cognitive overload. AI SOCs address this challenge by applying machine learning to automatically correlate, enrich, and prioritize alerts based on contextual data and historical patterns. These systems can identify repetitive benign events, flag only those truly deserving human intervention, and even automate the resolution of low-level incidents. As a result, analysts can focus their efforts on complex threats, significantly reducing time spent on manual triage and minimizing the risk of missing critical signals. Skills Gaps and Scaling Constraints in Modern SOC Teams As cyber threats grow in complexity and scale, the gap between the skills required to keep up and the available talent pool widens. Many organizations struggle to hire and retain analysts with deep expertise in threat hunting, forensics, and incident response. The shortage is compounded by the accelerating volume of security data, which only skilled teams can interpret at scale. AI SOCs help bridge this gap by embedding domain expertise within automated systems. Machine learning models learn from historical incidents, threat intelligence, and analyst feedback, enabling them to flag suspicious activity and recommend next steps—even when experienced analysts aren’t available. This technological augmentation empowers less-experienced team members, enables larger organizations to scale security operations, and ensures consistent coverage and decision-making, regardless of staffing levels. Fragmented Data and Tool Sprawl Across Security Stacks Modern security operations often involve an assortment of point solutions, each generating data in different formats and with limited interoperability. This tool sprawl leads to fragmented visibility, making it challenging to correlate signals across endpoints, networks, cloud environments, and applications. Analysts must manually navigate multiple dashboards, increasing the risk of oversight and delayed response. AI SOCs centralize data aggregation and normalize telemetry from across the stack, breaking down silos between products. Built-in AI engines continuously analyze this unified dataset to detect hidden patterns, correlate events, and build a holistic picture of risk. Tool integrations further enable coordinated, automated responses—streamlining operations and reducing the operational drag caused by disparate systems. Rapidly Evolving Threats and Attacker Automation Attackers frequently adapt their tactics and deploy automation to bypass static defenses and overwhelm manual processes. New threats, such as fileless malware or multi-stage attacks, can quickly bypass traditional signature-based detection. The dynamic nature of the threat landscape outpaces manual content updates or playbook development, leaving organizations exposed to previously unseen attack vectors. AI SOCs are equipped to address this by training on dynamic behavioral baselines, identifying novel patterns, and adapting their detection logic as attackers change techniques. AI-powered automation can mimic the speed and scale of attacker automation, enabling defenders to respond with the same agility. Continuous learning loops help the SOC stay on the cutting edge, rapidly updating detection capabilities in response to emerging threats without relying on time-consuming manual rule tuning. Evaluating managed detection and response? Explore leading MDR providers in our detailed guide. Making Sense of the AI SOC Market The Origins of the AI SOC The rise of the AI SOC stems from two converging forces. A very old problem and a very new technology. The old problem is the persistent talent shortage in cybersecurity combined with the overwhelming volume of security alerts. Security teams have been drowning in these alerts for years, struggling to keep up with investigation and response. The new technology is AI, especially large language models (LLMs) and adjacent innovations, which open up an opportunity to finally address that shortage by automating some of the human decision-making process. What AI SOC Usually Means All that said, when people refer to AI SOC, they’re usually talking about that middle layer. The part focused on automated alert triage, investigation, and escalation. Advanced solutions like Intezer provide 24/7 managed alert triage, investigation, and response powered by deep forensic analysis tooling combined with flexible and adaptable LLMs. For example, the Intezer system surfaces only what truly requires attention, and escalates only up to 4% of alerts to human analysts. This is where the market’s energy, and customer needs, are currently concentrated. Teams want to scale their response capabilities without adding headcount, and AI SOCs make that possible. How to Evaluate AI SOC Vendors With so many vendors entering the field, it’s important to evaluate them based on clear, measurable criteria. Some of the key metrics that I’m hearing from our customers and prospect that they consider, include: Accuracy: How precise are the AI-driven investigations? Speed: How quickly can alerts be triaged? Scale and coverage: Can the system handle all your alerts in a timely fashion? Noise reduction: What percentage of alerts still require human review? Context and transparency: Can you understand how the AI reached its conclusions, or is it a black box? For more on this, see our guide to evaluate AI SOC tools (with questions to ask vendors). How an AI SOC Works Intelligent Triage An AI SOC begins by collecting alerts from security tools such as endpoint detection and response (EDR), SIEM, email security, identity providers, cloud platforms, and network monitoring systems. Instead of treating each alert in isolation, the AI correlates related events, removes duplicates, and determines whether multiple signals belong to the same incident. The system then evaluates the likelihood that an alert represents a real threat by analyzing behavioral patterns, historical activity, threat intelligence, and the environment in which the activity occurred. Low-risk or known benign events can be automatically closed, while higher-risk incidents are prioritized for investigation or escalation. This significantly reduces alert volume and shortens the time analysts spend on manual triage. Contextual Enrichment After identifying an alert that requires investigation, the AI gathers additional context from internal and external sources. This can include asset information, user identity, endpoint telemetry, authentication logs, vulnerability data, previous incidents, and threat intelligence feeds. Collecting this information automatically eliminates much of the manual work traditionally required during an investigation. The AI combines these data points into a single investigation record and explains why the activity appears suspicious. Analysts receive a timeline of events, evidence supporting the assessment, and the likely attack techniques involved. This richer context helps security teams make faster, more consistent decisions without switching between multiple security tools. Autonomous Remediation Once the AI reaches sufficient confidence that an incident is malicious, it can trigger predefined response actions without waiting for manual approval, depending on organizational policy. Common actions include isolating compromised endpoints, disabling user accounts, blocking malicious IP addresses or domains, quarantining emails, and creating tickets for follow-up. Many AI SOC platforms integrate with security orchestration, automation, and response (SOAR) tools and security products to execute these actions across the environment. Human analysts remain in control of high-impact decisions, while routine containment tasks are automated. This reduces response times, limits attacker movement, and allows security teams to focus on complex investigations rather than repetitive operational work. AI in the SOC vs. AI SOC: What’s the Difference? The terms ‘AI in the SOC’ and ‘AI SOC’ are often used interchangeably, but they describe different levels of AI adoption. AI in the SOC refers to adding AI capabilities to existing security tools or workflows. For example, an EDR platform might use machine learning to improve malware detection, or a SIEM might use an LLM to summarize incidents. In this model, AI enhances specific tasks, while human analysts still perform most investigations, correlation, and decision-making. An AI SOC takes a broader approach. AI becomes a core operational layer that spans multiple security tools and automates end-to-end workflows, including alert triage, investigation, evidence collection, response recommendations, and in some cases remediation. Rather than assisting analysts with isolated tasks, the AI continuously orchestrates security operations across the environment and escalates only the incidents that require human judgment. In practice, the distinction is a spectrum rather than a strict boundary. Most organizations begin by introducing AI into individual security products and gradually expand automation as confidence grows. Vendors may also market products as AI SOCs even when they automate only a limited part of the investigation process. When evaluating solutions, it is more useful to focus on the workflows they automate, the quality of their investigations, and the measurable reduction in analyst workload than on the label itself. Key Capabilities of an AI SOC Automated Alert Triage AI SOCs automate the intake, analysis, and prioritization of security alerts to reduce reliance on manual review. Incoming alerts are evaluated using statistical models and learned patterns to estimate threat likelihood based on signal quality, affected assets, user context, and historical outcomes. This allows the system to distinguish between benign activity, low-risk noise, and alerts that warrant deeper investigation. AI SOC capabilities include: Automated alert scoring and prioritization Context enrichment using identity, asset, and environment data Historical correlation with past incidents and outcomes Automated suppression and closure of low-confidence alerts Analyst feedback loops for model tuning Enhanced Threat Hunting AI-driven threat hunting focuses on identifying suspicious behavior that does not match known attack signatures. AI SOCs analyze large volumes of telemetry across endpoints, networks, identities, and applications to identify deviations from established behavioral baselines. These systems surface patterns that would be impractical to detect through manual querying or rule-based detection alone. AI SOC capabilities include: Behavioral baselining across users, devices, and workloads Cross-domain telemetry analysis and correlation Automated anomaly detection and clustering AI-generated investigation hypotheses and leads Continuous refinement based on new data patterns Accelerated Incident Response AI SOCs reduce response latency by automating actions once a threat reaches a defined confidence threshold. Response logic is encoded into playbooks that trigger containment steps such as isolating hosts, revoking credentials, or blocking traffic without waiting for manual execution. This shortens the window between detection and mitigation. AI SOC capabilities include: Automated execution of response playbooks Policy-based containment and remediation actions Pattern recognition across past incidents Dynamic adjustment of response sequencing Analyst approval controls for high-impact actions Adaptive Workflows AI SOC workflows change based on incident context rather than following static investigation paths. The system adjusts investigation steps according to severity, affected assets, threat intelligence updates, and real-time findings. This allows resources to be allocated dynamically as incidents evolve. AI SOC capabilities include: Context-aware investigation orchestration Dynamic escalation and de-escalation logic Automated case management and task assignment Continuous learning from investigation outcomes Integration of real-time threat intelligence Natural Language Interaction AI SOC platforms increasingly expose natural language interfaces to simplify interaction with complex security data. Analysts can request summaries, query incident details, and initiate investigation steps using conversational commands instead of specialized query languages or dashboards. AI SOC capabilities include: Natural language querying of incidents and alerts Automated summarization of investigations Generation of incident reports and timelines Contextual explanations of threat activity Simplified access to analytics and workflows How AI Changes the SOC Team AI integration transforms the structure and workflows of the SOC team, shifting human roles from manual investigation and rule-writing to higher-value tasks like strategic analysis and incident oversight. Routine activities, such as alert triage, correlation, initial investigations, are largely handled by automated systems. Analysts now focus on tuning AI models, interpreting complex alerts, and making judgment calls that require domain knowledge or organizational context. This shift reduces the demand for large tiers of level-1 analysts and increases the need for fewer but more skilled professionals who can supervise automated decisions and investigate nuanced threats. Security engineers and data scientists become more central to the SOC, collaborating on model training, telemetry integration, and automation design. The AI SOC also fosters closer alignment between teams traditionally siloed (such as IT operations, compliance, and threat intelligence) through shared visibility and unified workflows. As AI handles scale and speed, human teams are free to focus on risk prioritization, strategic response, and continuous improvement of detection logic. What Is an AI SOC Analyst? An AI SOC analyst is an autonomous AI system designed to perform the duties of a human security analyst, from triage to investigation to response, without requiring continuous human input. Modern systems are based on agentic AI technology. They automatically process incoming alerts, filter out false positives, and gather relevant logs, threat intelligence, and contextual data to investigate incidents. The system then delivers prioritized findings or executes predefined response actions directly. Unlike traditional SOAR tools or AI copilots that depend on human oversight or prompt-based interaction, agentic AI SOC analysts operate independently. They possess advanced decision-making capabilities, enabling them to plan, reason, and adapt to new threats based on patterns and feedback. These systems are not just reactive, they can manage complex, multi-step tasks across varied domains such as cloud, endpoint, identity, and phishing alerts. AI SOC analysts are also built for scalability. They integrate seamlessly with existing security tools and platforms, and can handle multiple concurrent investigations without performance degradation. Their ability to learn from past incidents and refine future actions means they not only reduce mean time to investigate (MTTI) but also ease the workload on human teams. Key Use Cases of AI in Security Operations Faster Phishing Investigation and Response AI significantly improves the detection, prioritization, and response to phishing attacks. Machine learning models rapidly analyze email content, URLs, and attachments for suspicious characteristics, correlating findings with threat intelligence and known attack patterns. AI-powered automation can then flag doubtful messages, automatically block malicious links, and even simulate click-throughs in isolated sandboxes to evaluate real risk. Once a phishing alert is triggered, orchestration workflows can aggregate additional context with user history, device posture, login anomalies, etc. and suggest or execute next actions such as forced password resets or user notifications. The combination of automated triage and response reduces the time attackers have to exploit compromised credentials and minimizes human labor required for investigation. Behavioral Identity-Based Threat Detection AI enables continuous analysis of behavioral biometrics and identity usage patterns, allowing SOCs to identify abnormal user actions potentially indicative of account takeover, privilege abuse, or insider threats. Machine learning models maintain a dynamic baseline of typical behavior for each account or role and flag deviations that warrant closer examination. The AI SOC can correlate these anomalies with other environmental signals, such as impossible travel, unusual device fingerprints, or sudden escalation of privileges, to build a contextual risk score. This approach allows for real-time detection of complex attacks that circumvent traditional authentication and access controls, improving incident visibility across the identity landscape. Endpoint Malware Triage and Containment Endpoint telemetry generates immense volumes of data, making manual malware triage inefficient at scale. AI SOCs analyze process activity, file behavior, memory access, and communication patterns to identify malware in real time. Automated risk scoring and enrichment with external threat intelligence enable rapid determination of malware severity and spread. Upon label confirmation, AI-driven orchestration tools can execute containment playbooks, isolating affected endpoints, removing malicious files, and blocking related command-and-control traffic. Human analysts are notified only in exceptional or novel cases, reducing dwell time and enhancing overall endpoint security across the organization. Correlation-Driven Insider Threat Detection Insider threats are difficult to identify with siloed monitoring, as malicious activity may span email, cloud storage, endpoint, and physical access. AI SOCs fuse inputs from multiple sources, correlate timeline events, and flag suspicious patterns, such as unauthorized data movement or privilege escalation, using behavioral and statistical anomaly models. The ability to cross-reference multiple event streams ensures that precursor signs of insider incidents are surfaced even if individual activities appear benign. Automated investigation can assemble an audit trail, highlight risky behavior for focused human review, and prompt rapid intervention to mitigate loss or reputational harm. Learn more in our detailed guide to AI threat detection Types and Models of AI SOC There are a few common models for integrating AI technology into a security operations center. AI-Augmented SOC An AI-augmented SOC is a traditional security operations center where AI tools are integrated alongside human analysts to optimize workflows and boost productivity. Automation handles repetitive tasks, such as alert triage, enrichment, basic correlation, while humans oversee decisions, investigate incidents in depth, and guide complex response efforts. The AI’s role is supportive, assisting but not replacing human expertise. AI-Driven SOC (Automated Detection + Response) An AI-driven SOC shifts a larger share of detection and response duties to machine intelligence. Advanced models continuously monitor endpoints, networks, and cloud environments for threats, with incident response workflows triggered and carried out by automation in real time. Humans retain oversight of high-impact incidents and model tuning, but the system is designed to work autonomously for most day-to-day cases. Agentic/Autonomous AI SOC The agentic or autonomous AI SOC represents a future-forward model in which AI agents independently conduct detection, investigation, and response with minimal to no human intervention. These agents learn from the environment, adapt to novel attack techniques, and adjust workflows dynamically as the threat landscape evolves. Human involvement is largely reserved for exception management, compliance validation, and major incident oversight. Outsourced/Managed-AI SOC Service (Managed Detection and Response) Organizations lacking in-house expertise or resources may leverage external managed detection and response (MDR) providers offering AI-powered SOC-as-a-service solutions. These providers operate SOCs staffed with AI-driven automation, advanced analytics, and experienced analysts delivering 24/7 monitoring, triage, and response on behalf of customers. Metrics for Evaluating AI SOC Performance When deploying AI technology in the SOC, it’s important to evaluate its effectiveness in improving security operations and ultimately, the organization’s security posture. Here are a few ways organizations can evaluate the impact. 1. Time-to-Detect and Time-to-Respond Improvements A primary measure of AI SOC effectiveness is the reduction in mean time-to-detect (MTTD) and mean time-to-respond (MTTR) to security incidents. By applying real-time analytics, automated playbooks, and rapid incident orchestration, AI SOCs identify and address threats faster than traditional manual workflows. These improvements directly correlate with reduced attacker dwell time and minimized business impact. Measuring and trending detection and response times before and after AI SOC implementation helps organizations quantify operational gains. Continuous monitoring ensures that performance does not degrade as attack volumes grow or adversaries change strategies, providing an objective benchmark for the SOC’s maturity and agility. 2. Reduction in False Positives and Manual Workload AI SOCs are designed to cut through noise and decrease the number of false positives requiring analyst attention. High-fidelity detection models and automated triage ensure that analysts focus only on relevant, credible alerts. Over time, this reduces cognitive overload and allows teams to allocate resources where they are most needed. Tracking the percentage decline in false positives and the number of manual investigations over a sustained period is a strong indicator of AI SOC efficiency. These metrics directly map to reduced burnout and improved focus within SOC teams, contributing to better analyst retention and higher job satisfaction. 3. Analyst Efficiency and Skill Amplification AI SOCs amplify analyst capabilities by automating mundane tasks and providing data-driven insights. Analysts can investigate threats faster and more thoroughly, leveraging AI to surface correlations and evidence that would take hours to compile manually. Automation eliminates repetitive work and enables less-experienced analysts to perform at higher levels with machine support. Evaluating the volume and complexity of incidents handled per analyst, alongside time spent per investigation, reveals the degree of skill amplification achieved. These metrics help demonstrate ROI for AI SOC investments and guide workforce planning as operations scale. 4. Coverage Improvements Across the Kill Chain AI SOCs enhance security coverage by continuously monitoring and correlating events across all stages of the attack kill chain, from initial access to lateral movement and exfiltration. AI-driven analysis allows for early detection of subtle signals and chaining together disparate events that would otherwise be missed by siloed tools. Metrics for evaluating coverage include the variety and depth of attack techniques detected, the speed and consistency of response at each attack stage, and the reduction in successful breaches or undetected incidents. Improved kill chain coverage highlights the comprehensive nature and effectiveness of the AI SOC in defending modern enterprise environments. Tips for Successful Deployment and Operations of an AI-Driven SOC 1. Start With Incremental Adoption Organizations should avoid a big-bang approach when implementing AI in the SOC. Starting with pilot projects in areas like automated triage or enrichment allows teams to gain comfort with new technologies, validate benefits, and minimize disruption. Early successes build momentum for broader AI integration and help surface process or technology gaps before scaling. Pilot deployments also provide valuable data on integration complexity, user acceptance, and operational impact—insights that can be leveraged to refine strategy and chart a realistic roadmap for SOC transformation. This staged adoption minimizes business risk and supports smoother organizational change management. 2. Establish Human-AI Collaboration Guidelines As AI becomes more integral to security operations, clear guidelines for the division of labor between humans and machines are essential. Define which workflows can be safely automated, when human intervention is mandatory, and how escalations are managed for ambiguous incidents. Policies should address trust boundaries, explainability requirements, and override mechanisms. Effective collaboration depends on open feedback loops between analysts and AI systems. Regular reviews of automated decisions, incident outcomes, and model suggestions ensure that responsibility remains clear and that the AI continues to align with organizational risk tolerance and values. 3. Standardize Data Quality and Telemetry Hygiene AI system effectiveness is only as good as the data they process. Organizations should standardize telemetry collection across endpoints, networks, and cloud environments, ensuring complete, accurate, and well-structured data feeds. Proactive data hygiene reduces the risk of missed threats, erroneous conclusions, and bias in automated models. Implementing good data governance practices—such as schema validation, enrichment, normalization, and retention policies—is critical to preserving high-quality input for AI-driven analysis. These foundational steps maximize the return on AI investment and underwrite robust, reliable SOC automation. 4. Train Analysts to Work With AI Investigation Tools Developing analyst proficiency in AI-driven tools is central to realizing the full value of an AI SOC. Training should focus not just on operating new interfaces but on interpreting model outputs, understanding AI rationales, and identifying potential blind spots or errors. This empowers analysts to make informed decisions when collaborating with automation. Continuous professional development, through vendor-led courses, hands-on labs, and real-world scenario drills, keeps skills current as AI features evolve. Training should bridge the gap between cybersecurity fundamentals and data science basics, ensuring analysts are equipped to guide, challenge, and improve the AI SOC over time. 5. Create a Feedback Loop to Improve AI Performance Over Time No AI system is perfect out of the box. Creating structured feedback loops, where analysts rate automated recommendations, flag false positives, and contribute to model tuning, ensures continual improvement in detection and response accuracy. Feedback data aggregates into training datasets, enabling retraining and optimization of machine learning algorithms. Automated reporting and user-friendly review interfaces help capture timely, actionable feedback without adding friction to analyst workflows. Over time, these loops create a virtuous cycle in which the AI SOC adapts to new threats, organization-specific contexts, and evolving analyst expertise, driving incremental performance gains. Intezer AI SOC To bring these concepts together in practice, organizations need an AI SOC that goes beyond surface-level automation and delivers consistent, defensible security outcomes at enterprise scale. This is where Intezer AI SOC stands apart. Built on ForensicAI™, Intezer combines agentic AI reasoning with deterministic, code-level forensics to investigate every alert, across endpoint, cloud, identity, and email, without capacity limits. Instead of sampling alerts or ignoring “low severity” signals, Intezer provides 100% alert coverage, completing investigations in under two minutes with 98% accuracy, while escalating fewer than 2% of cases to human analysts. Every verdict is evidence-based and explainable, giving SOC leaders confidence that decisions are grounded in real forensic proof, not black-box assumptions. Critically, Intezer AI SOC closes the loop between detection and investigation. AI-powered Detection Engineering is natively integrated with daily triage and investigation outcomes, so detections are continuously validated, tuned, and strengthened based on what actually happens in production. This eliminates one of the biggest gaps in traditional SOC and MDR models, where detections drift out of alignment with real-world threats. The result is an operating model that allows enterprises to reclaim security operations in-house, reduce risk measurably, and scale without adding headcount. As AI SOCs become the standard, Intezer represents what the model was meant to deliver: forensic depth at machine speed, continuous improvement by design, and a clear path beyond the limitations of traditional MDR. Learn more about Intezer See Additional Guides on Key Cybersecurity Topics Together with our content partners, we have authored in-depth guides on several other topics that can also be useful as you explore the world of cybersecurity. Authored by Faddom Authored by N2W Authored by Intezer

Managed Detection and Response (MDR) was supposed to solve one of cybersecurity’s biggest problems: the lack of time, talent, and expertise to investigate alerts and stop threats quickly. Yet, after years of adoption, the same pain points keep surfacing across enterprises, no matter which MDR provider they use. It’s not that MDR doesn’t work. It’s that the MDR model has hit its scalability ceiling. And that’s exactly where the AI SOC comes in. The persistent pain points with MDR Even top-tier MDR services face systemic limitations, mostly rooted in their heavy reliance on human analysts and manual workflows. Slow speed of investigation and escalation Traditional MDRs still depend on people manually triaging and escalating alerts. When alerts are high-volume and context is shallow, triage slows down. Minutes or hours pass before something is even reviewed — and attackers don’t wait. Inconsistent quality of service Service quality often depends on who’s on shift. A senior analyst might quickly recognize a benign admin script, while a newer one escalates it as suspicious. Customers experience inconsistency and noise, not confidence. “Alert regurgitation” with too many escalations Many MDRs escalate too many alerts back to the customer, simply because their analysts can’t safely close them. Without deep forensic capabilities or contextual reasoning, they pass the decision back creating more work for internal security teams, not less. Shallow coverage (only high severity alerts) Because human bandwidth is finite, most MDRs only analyze high-severity alerts. Low-severity anomalies where early indicators of compromise often hide, are ignored. The black box problem Customers rarely know why an alert was raised or dismissed. MDR reports often lack transparency, context, or traceability. You’re asked to trust the verdict but you can’t validate it. These issues aren’t about vendor quality; they’re about model design. The traditional MDR is inherently limited by human capacity and rule-based logic. Detection engineering is the heart of security operations At the center of every MDR’s capability is detection engineering, the practice of building, tuning, and maintaining the rules and analytics that proactively identify threats. Detection engineering defines: What threats are visible. How fast they’re detected. How accurate detections are. How much noise analysts must deal with. Strong detection engineering means faster time-to-detect and fewer false positives. Weak detection engineering means missed attacks and alert fatigue. It is, without question, the intellectual property core of every MDR. But detection engineering the old way doesn’t scale Traditional detection engineering is slow, manual, and fragile. Rules take time to create and validate. New TTPs require new detections, which must be tested, tuned, and redeployed, all by hand. And rules decay quickly. Attackers evolve, environments change, telemetry shifts and yesterday’s rules stop working tomorrow. Furthermore, detection coverage is opaque. Most internal SOCs can’t quantify exactly which ATT&CK techniques they’re covered for. Finally, testing is inconsistent. Manual QA means some detections are solid, others are noisy. This leads to more false positives which drain MDR analysts. The more data collected, the more noise generated and the slower their response. In MDR models, detection engineering is a constant treadmill: write > tune > test > break > repeat. Ad nauseam. Explore this article on making sense of the AI SOC market. The paradigm shift of the AI SOC The AI SOC represents a fundamental shift from reactive, human-bounded detection to autonomous, hybrid intelligence that combines human reasoning with machine precision. Instead of relying solely on analysts, the AI SOC uses automation, behavioral modeling, and language models to perform much of the investigative heavy lifting. Here’s how it solves the core MDR pain points: Instant investigation at scale AI can automatically collect context, process ancestry, file reputation, network behavior, identity usage, and reason across it in seconds. What once took an MDR analyst 30 minutes now takes milliseconds. Consistency without fatigue LLMs and behavioral models don’t have “bad days” or “night shifts.” They deliver consistent quality, 24/7. Every alert is triaged against the same logic, evidence, and reasoning patterns. Contextual decisions, not alert regurgitation Rather than escalating uncertain alerts back to customers, the AI SOC enriches and explains them. It can summarize findings, justify verdicts, and give clear remediation guidance. Broader, deeper coverage Because AI triage scales infinitely, it can analyze low- and medium-severity alerts that MDRs typically ignore, surfacing early-stage threats before they escalate. Full transparency AI SOCs can log every step of their reasoning and decision path. Customers see not only the verdict, but the why behind it. A true end to the black box. Intezer’s edge: Deep forensics meets AI reasoning At Intezer, we believe AI alone is not enough. Large Language Models are powerful, but on their own, they’re probabilistic, great at language and context, but not inherently trustworthy for high-stakes decisions. That’s why Intezer’s AI SOC is built on the hybrid foundation of deterministic forensic analysis with LLM flexibility and intuition. Read more in this blog, Why the best LLMs are not enough for the AI SOC. Deep forensic heritage Intezer’s AI SOC is built on a forensic-grade understanding of system behavior, a foundation that goes far beyond traditional detection or endpoint analytics. Attackers today often operate without dropping malware at all. They use stolen credentials, exploit vulnerabilities or misconfigurations, and leverage legitimate tools like PowerShell, WMI, or RDP to move laterally and persist. Detecting these techniques requires more than just pattern matching. It demands a forensic view of what’s really happening inside the system. That’s where Intezer’s deep forensic heritage comes in. Our platform continuously analyzes execution at multiple layers, from code and memory to processes, persistence mechanisms, and network communication, to reconstruct the full behavioral narrative of an incident. When required, Intezer can even execute suspicious payloads in our controlled sandbox environment to capture precise behavioral indicators such as process creation, memory injection, and command-line actions. But that’s just one piece of a broader forensic ecosystem tightly integrated with static analysis, code reuse detection, memory forensics, and runtime telemetry. This multi-layered forensic engine gives the AI SOC deterministic truth. A complete, evidence-based understanding of activity whether or not malware is involved. It’s how Intezer’s AI can confidently assess not just what ran, but why it ran, who executed it, and how it fits into an adversary’s tactics. LLMs emulating human analysts as the reasoning layer On top of that forensic backbone, we apply large language models to: Correlate telemetry and behavioral chains. Explain detections in plain language. Assess intent and business impact. Generate new detection logic dynamically from emerging TTPs. The LLM provides intuition; the forensics provide ground truth. Together, they deliver what MDRs have always lacked. Speed, consistency, transparency, and trust. Redefining detection engineering with AI Even what MDRs once considered their “core IP”, detection engineering, is being transformed by AI SOC architecture. Here is how: AI-assisted detection creation: LLMs can generate draft Sigma or YARA rules from threat reports in seconds. Automated validation: The system tests detections against known TTPs and real-world telemetry. Adaptive tuning: AI adjusts thresholds and correlations based on live data, minimizing noise. Forensic-backed confidence: Every detection is validated against Intezer’s code intelligence and endpoint forensics. This turns detection engineering from an artisanal, reactive process into a continuous, self-improving capability. The bottom line The MDR market won’t disappear overnight, but its limitations are becoming clear. Customers want faster investigations, consistent quality, and full transparency. They want a SOC that doesn’t just watch alerts, but understands them. That’s exactly what the AI SOC delivers. And with Intezer’s unique combination of deterministic forensics and AI reasoning, we’re not just matching MDR capabilities. We're surpassing them, including in the area once considered MDR’s crown jewel: detection engineering. The AI SOC isn’t the next version of MDR. It’s what comes after it. Learn more about Intezer today!

Beginner's guide to malware analysis and reverse engineering October 2, 2025 Written by Nicole Fishbein Malware analysis and reverse engineering are powerful but can also be challenging and time-consuming. Performing a thorough analysis typically requires deep knowledge, specialized tools, and extensive experience. However, not every security analyst has the expertise or the resources to conduct an exhaustive investigation for every suspicious file they encounter. Moreover, a comprehensive, in-depth reverse engineering effort isn’t always necessary or practical, for example, if another researcher has already reported and documented the file. This blog series on "Breaking down malware" introduces a flexible, practical approach to malware analysis. Our goal is to guide you through determining the level of analysis required based on the context and initial findings. We will explore various techniques and tools that can help you efficiently assess a suspicious file, quickly determining whether a deeper dive is warranted or if initial triage provides sufficient insight. We’ll start by detailing the foundational steps for analyzing suspicious files, from initial triage and basic information gathering to deciding the right analytical approach. Later in the series, we’ll dive deeper into advanced reverse engineering techniques. By the end, you will understand the technical aspects of reverse engineering and the strategic mindset necessary to choose the most effective analysis path. Ultimately, this blog aims to empower analysts at any skill level to perform effective, context-driven malware investigations, demonstrating that valuable insights can often be gained without requiring expert-level reverse engineering skills. What is malware analysis? Malware (short for malicious software) analysis involves examining malicious software to understand its behavior, capabilities, and effects. By gaining insights into how malware functions, security teams can create effective detection, mitigation, and prevention strategies. It resembles digital forensics, where analysts serve as detectives, dissecting malware to uncover its mechanisms and defense methods. Just as doctors research diseases to develop cures, security researchers study malware to improve defense systems. There are two primary approaches to malware analysis: Static Analysis involves examining malware without executing it, like reading a machine's instructions without turning it on. Analysts inspect the code (if accessible) and its properties to predict its behavior. Dynamic Analysis - Running malware in a controlled environment to observe its real-time behavior. This approach typically uses a sandbox or a virtual machine with a debugger and monitoring tools. The main difference is that the latter option is more hands-on, giving the researcher more control over malware execution (particularly when debugging). In contrast, a sandbox encapsulates everything and produces a final report. Why malware analysis matters? A thorough understanding of malware allows security teams to assess its potential or actual impact on an organization. Different types of malware pose different risks. Ransomware encrypts files for extortion and presents a different threat than spyware, which silently steals sensitive data. Malware analysis helps security teams determine how a threat operates, what vulnerabilities it exploits, and how to defend against it effectively. One of the most significant benefits of malware analysis is its role in improving cybersecurity strategies. By studying malware behavior, security teams can identify weaknesses in their defenses and implement better protective measures. This includes enhancing endpoint security, refining detection rules, and strengthening network monitoring to catch malicious activity before it causes harm. Organizations can use insights from malware analysis to develop stronger incident response plans, ensuring a fast and effective reaction to future attacks. Additionally, security teams can create and distribute Indicators of Compromise (IOCs), such as malicious file hashes, domain names, and registry modifications, which help detect and block similar threats before they spread. Malware analysis also plays a crucial role in law enforcement and threat intelligence. Cybercriminals often reuse code, infrastructure, or attack patterns across different operations. Security researchers and intelligence agencies can track cybercriminal groups, attribute attacks, and uncover larger threat campaigns by analyzing malware samples. This information is invaluable for law enforcement agencies working to dismantle cybercrime operations and prosecute attackers. Furthermore, malware analysis contributes to the broader cybersecurity community by sharing threat intelligence, allowing organizations and government agencies to collaborate on mitigating emerging threats. Ultimately, malware analysis is a critical component of modern cybersecurity. It enables organizations to stay ahead of evolving threats, strengthens defense mechanisms, and supports efforts to track and stop threat actors. Without it, organizations would be left vulnerable, relying on reactive measures instead of proactive security strategies. The fundamentals of malware analysis: Define the goal of malware analysis Reverse engineering and malware analysis can quickly become complex and time-consuming tasks, especially given the sophisticated techniques malware authors employ. Analysts often face constraints on time, resources, and their specific areas of expertise. Thus, it’s essential to approach malware analysis strategically, focusing efforts based on clearly defined goals. The objectives of malware analysis differ greatly depending on the analyst’s role and organizational priorities. For instance, a frontline analyst might only need to confirm whether a file is malicious before passing it to specialized teams for further analysis. In contrast, incident response professionals may require detailed insights into malware behavior to understand the full scope of an attack, formulate response strategies, and document findings comprehensively. Analysts or researchers tasked with producing detailed threat reports, whether for internal use or public dissemination, typically require in-depth analysis. Such comprehensive reports necessitate a thorough understanding of the malware's capabilities, objectives, and technical intricacies. Clearly identifying your goal at the outset helps you determine the scope of analysis, select the appropriate tools and techniques, and efficiently allocate resources. By defining the precise information needed, whether it’s identifying indicators of compromise, understanding infection methods, extracting actionable intelligence, or simply classifying the file’s threat level, you ensure that your analysis remains targeted and effective. Always ask yourself: “What is the minimum critical information required to achieve my goal?” This mindset prevents unnecessary deep dives into irrelevant details and maximizes the efficiency and impact of your malware analysis efforts. Initial triage Before diving deep into malware analysis, the first step is to conduct an initial triage. This helps determine the file's basic characteristics, identify potential challenges like packing or obfuscation, and extract valuable indicators for further analysis. In this section and the following posts in this series, we will use an example file to demonstrate the malware analysis and reverse engineering process. The file can be downloaded from MalwareBazaar. We will name the file: mal_mal. MD5: 3f6094edd7cad01c0f12decf36dcce95 What architecture and format does it have? The first step in triage is identifying the file’s architecture and format. When it comes to executables, malware can target different operating systems and may come in various formats, such as: Determining the format helps analysts choose the appropriate tools and techniques for further investigation. Different tools, such as CFF-Explorer, Detect-It-Easy, XPEViewer, Radare2, and the file command (Unix), can help us identify the file format. Example: Identifying the file format and architecture. In this case, we have a 64-bit DLL for x84-64 processors. file mal_mal mal_mal: PE32+ executable (DLL) (console) x86-64, for MS Windows Is it a known threat? Once the format is identified, checking whether the sample is already known can save significant time. Analysts can compare the file’s hash against threat intelligence databases to see if it has been previously documented. Common sources for checking known threats include: • VirusTotal – A multi-engine scanning service • MalwareBazaar – A public malware repository • Threat Intelligence Feeds – Databases from security vendors If the malware is known, existing reports can provide insights into its functionality and risks. If it is not recognized, further analysis is required. In our case, the file was not submitted to any of the publicly available services. Packed vs. unpacked malware Packers and crypters Threat actors often use tools to pack, encrypt, and obfuscate the main payload. Their goal is to make malware analysis and detection much more complex and time-consuming. The reason is that the main payload is wrapped in layers of obfuscation, which makes it difficult to inspect. That said, there are ways to extract the main payload; some cases are easier than others. Packers are tools that compress the executable to reduce the size of the binary. Common packers include UPX, ASPack, and MPRESS. Crypters alter the code to make it difficult to read, often by renaming functions, adding junk instructions, or using encryption to hide key functionality. Common crypters include: Themida, Armadillo Crypter, and CyberSeal. For analysts, packed and obfuscated malware presents a challenge. Static analysis becomes less effective since much of the original code is concealed, making extracting valuable indicators such as strings, imports, or API calls difficult. Debugging and dynamic analysis are often required to observe the malware in action, extract the unpacked code, and uncover its true intent. In cases where advanced packers or custom obfuscation methods protect malware, analysts may need to manually trace execution in a debugger or dump the unpacked code from memory to proceed with their investigation. Is It Packed and/or Obfuscated? To determine if a file is packed, analysts can check for: High entropy – Entropy is a measure of randomness in data. In the context of files, it indicates how uniformly the bytes are distributed. A standard executable contains a mix of code, readable strings, and structured data, resulting in medium entropy. However, when a file is compressed or encrypted, the byte distribution becomes more random, increasing its entropy level. A high entropy value (typically close to 8 on a scale of 0 to 8) suggests that the file has been packed or encrypted. This is because packing tools replace readable code with compressed or encrypted data, which is later decompressed or decrypted when executed. Analysts use entropy analysis to detect potential packing, as a high entropy section, especially in areas where plain code should be, often indicates that the file has been modified to conceal its true functionality. If a file shows unusually high entropy, unpacking it is usually necessary before further analysis can be conducted. Unusual section names – Some packers create non-standard section names in executables Missing or altered import tables – In a standard executable file, the import table lists external functions and libraries the program relies on to perform tasks, such as file operations, network communication, or process manipulation. This table is crucial because it provides insight into what the program does and which system functions it interacts with. Packed malware often has a missing or heavily altered import table, making static analysis more difficult. This happens because packers remove or encrypt the import table, preventing analysts from easily identifying the malware’s functionality. Instead of listing necessary functions upfront, packed malware dynamically resolves them at runtime, often using indirect calls or API hashing techniques. A complete absence of imports or an unusually small number indicates that the file is packed and may require unpacking before further analysis. Example: Checking if the file is packed using entropy analysis {Insert command output showing entropy calculation or section analysis} Unpacking If a sample is packed, it needs to be unpacked before further analysis. Some packers, like UPX, have easy-to-use unpacking tools, while others require manual unpacking techniques such as debugging and memory dumping. Example: Unpacking a UPX-packed sample Let’s take our file and test for UPX packing - One way is to run the UPX utility with the test (-t) flag: upx -t mal_mal Another way is to check the section names. In standard UPX packing, the section names will be named UPX So now that we know that the file is packed, we will use the UPX utility to unpack it. upx -d -o unpacked_mal mal_mal The next stage in an investigation would be to analyze the unpacked file. Extracting strings and indicators – Finding clues in plain text Plaintext strings can provide valuable clues. Strings can reveal: C2 (Command and Control) domains File paths and registry keys Error messages or debug information Analyzing extracted strings helps guide further investigation and can provide early indicators of the malware’s intent. Example: Extracting strings from the malware sample We have several options: run the strings utility, use the built-in strings extraction option in BinaryNinja, or use other tools that process strings. No matter the method, we usually get a very long list of strings, some don’t make sense, some are from library code, but we are looking for user-defined strings because these strings might give away some information about the malware. It takes experience and knowledge to identify interesting user-defined strings. If you see a string and are not sure if it is part of a library or what it can be related to, you can: Google it Use grep.app - a free platform that searches for a given string in all public git repositories. In our use case, it provides context to strings and helps identify strings common in code or strings that are part of malicious code. We will use the strings command in Unix and highlight the following strings that look suspicious (and interesting): killme changeshell chcp 437 > NUL Client Ready %s\%lu.bat powershell.exe -nologo ea2ced841239466e92dc53d49b45975e [+] Endpoint changed [+] ShortTimer and FailCounter changed. New ShortTimer is [+] Short Timer changed. New Short Timeout is 1 minute orer.exe\r\nstart "%s"\r\nif exist {C2796011-81BA-4148-8FCA-C664324elete "HKEY_CURRe\Classes\CLSID\@echo off\r\nreg dexplorer.exe\r\nti5113F}" /F\r\ntask"%s" goto d\r\ndelmeout 5\r\n:d\r\ndelkill /F /IM explENT_USER\Softwar Analyzing the Import Table When analyzing a suspicious executable, the import table is one key area to examine. This table provides valuable insights into the file’s functionality by listing the external libraries and functions the program relies on. Before diving into the import table, it is essential to understand the structure of a Portable Executable (PE) file and how different sections contribute to a program's execution. Understanding the PE Header, Sections, and Segments A Portable Executable (PE) file is the standard format for executables, DLLs, and other binary files in Windows. It consists of multiple components, including: PE Header – Contains metadata about the executable, such as its entry point, section layout, and the locations of important tables, including the import table. Sections – The PE file is divided into sections, each serving a different purpose. Common sections include: .text – Contains the executable code. .data – Holds initialized global variables. .rdata – Stores read-only data, such as imported function names and strings. .rsrc – Contains resources like icons, images, and dialogs. .idata – Stores information about imported functions, forming the import table. What is the Import Table and why is it important? The import table lists the external functions that an executable calls from shared libraries (DLLs). Instead of implementing everything from scratch, programs rely on system-provided functions for common tasks such as file access, network communication, and memory management. The import table provides the following information: DLL names – The names of the libraries the executable depends on, such as kernel32.dll, user32.dll, and ws2_32.dll. Imported functions – The program's specific API functions, such as CreateFileA, VirtualAlloc, WinExec, or send. Addresses of imported functions – The memory locations where these functions will be mapped when the program runs. By analyzing the import table, we can quickly assess the purpose of a program. If an executable imports functions related to file manipulation, registry modifications, or process injection, it might indicate potential malicious behavior. For example: The presence of WriteFile, CreateFileA, and DeleteFileA may suggest file system modifications. The use of RegCreateKeyEx and RegSetValueEx could indicate registry modifications for persistence. The inclusion of VirtualAlloc, WriteProcessMemory, and CreateRemoteThread might hint at code injection or process hollowing, techniques often used by malware. How does the import table help in initial triage? During the initial triage of a file, examining the import table can help analysts quickly determine the following: Whether the file is packed or obfuscated – If an executable has very few or no imports, it might be packed since packers remove the original import table and restore it dynamically at runtime. (As we saw in the previous part). The intended functionality of the program – We can infer what the executable is designed to do by looking at the imported functions. Potential malicious behavior – Certain functions or DLLs, such as advapi32.dll for registry access or ws2_32.dll for network connections, can indicate specific attack techniques used by malware. Connections to known threats – Comparing the import table against known malware samples can help identify similarities and classify the file. Analysts can gain crucial insights into a file’s behavior by carefully analyzing the import table before executing it. This allows for a more informed approach to further analysis, whether that involves static code inspection, sandboxing, or unpacking a protected sample. Example: We will use the triage view in BinaryNinja to inspect the imports In our case, several functions stand out as possible red flags. Registry Manipulation – Possible Persistence or Configuration Extraction RegQueryValueExA, RegOpenKeyExA, RegEnumKeyExA These functions are commonly used to query, open, and enumerate registry keys. Malware often uses them to check system configurations, read stored credentials, or modify registry settings for persistence. Process and Thread Manipulation – Possible Code Injection or Process Hollowing CreateProcessA - This function creates new processes, which can indicate malware attempting to spawn additional payloads or execute commands on the system. CreateThread - The ability to create new threads can be exploited for code injection, where malicious code is executed in the context of another process. File System Operations – Potential Indicators of Data Theft or Destructive Behavior These functions allow the malware to create, modify, or delete files. Ransomware often uses WriteFile to encrypt data, while data-stealing malware may use ReadFile to exfiltrate information. These functions are part of the Windows HTTP Services (WinHTTP) library and are typically used for network communication. Malware can use these APIs to establish contact with a C2 server, download additional payloads, or exfiltrate data. Anti-Analysis and Evasion Techniques IsDebuggerPresent - This function checks whether the process is running inside a debugger. Malware often uses it to detect security researchers or sandboxes and modify its behavior to evade analysis. Inter-Process and Memory Manipulation – Potential Code Injection or Process Tampering OpenFileMappingA, CreateFileMappingA These functions create or open shared memory regions, which can be used for inter-process communication. Some malware uses these APIs for process injection or to exchange data between different processes stealthily. While none of these imports alone confirms that the executable is malicious, their presence, especially when combined, can indicate suspicious activity. If a file heavily relies on registry modifications, process creation, file manipulation, and network communication, it needs deeper analysis to determine its true intent. The suspicious strings that we saw in the previous stage further support this assumption. The following steps may include examining its behavior dynamically and investigating additional artifacts. This first part of our "Breaking Down Malware" series has laid the groundwork for understanding malware analysis and reverse engineering. We've explored the initial triage process, from identifying file architecture and format to determining if a threat is known, and understanding the challenges posed by packed and obfuscated malware. We also dug into the significance of extracting strings and analyzing the import table, highlighting how these initial steps provide crucial insights into a file's potential malicious behavior. By meticulously gathering this fundamental information, analysts can build a strong foundation for the deeper static analysis and reverse engineering techniques we will explore in the upcoming second part of this guide. In the next blog in this series, we will dive into the static analysis to showcase how we continue the investigation based on the information we have gathered. Learn more about Intezer's Forensic AI SOC platform and how our deep heritage of malware analysis tools, combined with flexible LLMs, ensure the highest levels of triage and investigative accuracy. Nicole Fishbein Nicole is a senior security researcher and malware analyst at Intezer. Prior to this, she was an embedded researcher in the IDF Intelligence Corps.

Better together: How Intezer and Torq are powering the autonomous, AI SOC [Video] September 29, 2025 Written by Zev Schonberg We know the drill. Too many alerts, not enough time. Threats slipping through. SOC analysts losing their minds. It's brutal. But all that pain makes the agent-to-agent collaboration between Intezer and Torq so much more delicious! In this Torq AMP'd session you'll enjoy the fast-paced and super informative back-and-forth with Mitchem Boles, field CISO at Intezer talking to Bob Boyle and Brittney Wittfeldt of Torq fame, all about our partnership and with a full technical deep-dive! Hope you watched the full and super fun video for all the details, but if not, here is a nice synopsis of how the Intezer+Torq magic happens, step by step: Intezer triages everything AI agents emulate elite human analysts, running forensic-grade triage and investigation on every single alert. Only true positives move forward Fully triaged, verified alerts are escalated. Noise stays behind (typically only 4% of alerts are escalated with 98% accuracy). Agent-to-agent handoff Intezer kicks those true positives over to Socrates, Torq’s agentic AI analyst inside HyperSOC. Case creation & enrichment Socrates builds a complete case, mapping observables, IOCs, and all context, then enriching with intel and quick-action buttons. Autonomous runbook execution Socrates translates Intezer’s recommendations into a step-by-step remediation plan, then executes it end-to-end. The result: true Autonomous SOC. Detection, triage, and response handled at machine speed, freeing humans to focus on what really matters. Zev Schonberg is a product marketing manager with years of experience in deep tech. As a lead contributor at Intezer, Zev authors research-driven analysis and thought leadership that explores how modern security operations centers can better detect, investigate, and respond to threats at scale.

If you are evaluating an AI SOC solution, one critical question to ask is: what’s under the hood? While every AI SOC vendor is touting their LLMs, even the best AI cannot deliver the highest accuracy, consistency, and ability to scale. In this blog post we’ll examine the main approaches that can be used in AI SOC platforms: deterministic tools and LLMs. We also will explain where each approach excels, where each falls short and why it’s important that your vendor of choice uses both in triaging and investigating all your security alerts. We also will explain why vendor claims of using analytic forensic tools need examination, as the depth and capabilities can greatly vary. Deterministic analysis: The guardrails for accuracy Deterministic analysis is rule-based and repeatable. Given the same input, they always deliver the same output. In SOC triage, this means: High consistency: Alerts are handled the same way, every time. Auditability: Easy to retrace and explain why an alert was escalated or suppressed. False positive reduction: By encoding expert knowledge into rules, deterministic logic filters out noise at scale (Intezer for example achieves ~98% accuracy here). Fast, scalable and affordable: Deterministic analysis executes in real time with minimal compute overhead, allowing thousands of alerts to be triaged simultaneously without requiring loads of expensive compute infrastructure (with cost savings passed on to the customer). Not all deterministic analysis packs the same punch It’s important to note that not all claims of “deterministic capabilities” are created equal. It’s like comparing two doctors, one who uses only a thermometer and another who uses an MRI. Both tools are deterministic in the sense that they always produce the same result when applied. The thermometer will consistently show a temperature, and the MRI will consistently reveal detailed imaging, but the depth and richness of the diagnosis they provide are worlds apart. So too in the SOC. Some vendors may claim deterministic capabilities because they scan a hash in VirusTotal, which is the equivalent of taking a patient’s temperature. Intezer, by contrast, delivers MRI-level depth with its deterministic tools. For example with our proprietary database of billions of malicious and benign code samples, Intezer can determine whether previously unknown code shares genetic fragments with malware families, delivering a much more thorough and conclusive verdict than surface-level checks ever could. Additional examples of Intezer’s deterministic tools can be endpoint forensics, memory scanning, URL scanning, threat intelligence and reputation checks for files/URLs/IPs, as well as specific org policies and tuning rules. Where deterministic shines Deterministic analysis excels in areas where repeatability, precision, and proven logic matter most. For example, matching file hashes to known malware databases delivers fast, definitive results. If a file has been identified as malicious before, there’s no ambiguity in the verdict. The same principle applies to enforcing allow or deny lists, where repeatable rules ensure consistent triage across every alert. Furthermore, deterministic analysis tools are lightning fast and do not require massive amounts of computing power, making them more affordable to customers. In short, deterministic methods ensure accuracy, consistency, clarity and affordability in triage, forming the guardrails SOC teams rely on to operate with confidence and efficiency. Where deterministic falls short While deterministic processes provide reliability and consistency, they have inherent limitations. Rules and signatures cannot adapt to new or unknown attack patterns and new triage strategies, leaving gaps when adversaries introduce novel techniques. Deterministic logic is also blind to subtle intent; for example, it may flag a PowerShell script as suspicious without understanding whether it is part of a malicious operation or simply a routine IT maintenance task. These blind spots highlight the need for a complementary layer of analysis that can reason more like a human analyst, interpreting context and intent rather than relying solely on fixed patterns. Read about what CISOs are looking for in an AI SOC platform LLMs: Human-like reasoning at scale Large Language Models bring human-like reasoning into SOC triage, acting as an analyst’s intuition at machine speed. They are able to interpret ambiguous signals, connect seemingly unrelated events, and generate verdicts like those of an experienced human operator. This capability makes them particularly valuable in situations where rigid rules fall short. Where LLMs excel LLMs excel at interpreting context and intent, taking raw technical evidence and transforming it into clear, actionable verdicts. Unlike deterministic processes, which can parse data but struggle with meaning, LLMs provide the analyst’s intuition at scale. Here are 3 examples of LLMs in action: Endpoint use case: Deterministic engines can tell you that an unknown executable spawned cmd.exe and then invoked rundll32.exe on a DLL. LLMs takes it further, analyzing the full chain: a Temp-folder EXE immediately launching a suspicious DLL registration sequence, with no legitimate installer context, flagged as malicious by both the EXE and DLL verdicts. The LLM highlights that the entire process chain—Temp EXE → cmd.exe → rundll32.exe—is consistent with malware persistence, not routine user activity. This is the difference between a list of events and a reasoned conclusion. Identity use case: Traditional rules may flag multiple rapid IP logins as a travel anomaly. LLMs enriches the context, recognizing that the IPs belong to known corporate VPN relays and Microsoft endpoints, that MFA was consistently passed, and that devices and geolocations match historical patterns. The LLM interprets these signals to conclude it is a benign VPN-driven false positive, rather than a compromised account. Email use case: Deterministic checks can identify mismatched domains or suspicious links. But LLMs can tie the indicators together into a clear verdict: the sender address does not match the sender’s name, the URLs point to untrusted subdomains, branding is off, and an urgent payment request is out of place. Instead of a raw list of red flags, the LLM delivers a reasoned judgment that the message is a phishing attempt. Across these examples, Intezer’s LLM doesn’t just parse or enrich, it interprets. By explaining whether activity is malicious, suspicious, or benign, it provides the intuition needed for fast and confident SOC decisions. Where LLMs can fail Despite these strengths, LLMs carry inherent limitations. They can be inconsistent, producing different answers to similar inputs. They are also prone to hallucinations, delivering conclusions with great confidence even when those conclusions are wrong. Perhaps most importantly, their reasoning is not inherently repeatable or auditable, which undermines trust in high-stakes SOC operations where explainability and accuracy are critical. Finally, relying solely on LLMs for alert triage, investigation and response is exorbitantly expensive with enormous needs for compute power. This often translates into vendor charging per alert which is simply not economically scalable. Why “either/or” approaches miss the mark In summary, vendors who rely on one or the other approach simply cannot deliver on the promise of the modern SOC. LLM-only platforms often market themselves as fully powered by AI and capable of handling any and all security use cases. While impressive on the surface, they can create risk if verdicts are inconsistent, opaque, or prone to hallucination. As mentioned the LLM-only approach is not economically scalable considering the massive volume of alerts that need to be triaged for most enterprises. Deterministic-only platforms provide reliable automation but lack the adaptability to interpret ambiguous signals. Both approaches in isolation leave gaps. That is why a hybrid solution that incorporates both, is ideal for the modern SOC. Intezer’s approach: Guardrails + intuition Intezer was built on the belief that no single approach is enough to meet the demands of modern SOC operations. Deterministic analysis provides the guardrails with repeatable, explainable processes that reduce false positives by ~98% and deliver consistent accuracy at scale. This foundation is what makes the platform reliable, trustworthy, and audit-ready. But deterministic processes alone are not sufficient. Attackers constantly evolve their techniques, and subtle differences in intent can determine whether an activity is routine IT maintenance or a genuine intrusion. This is where Intezer’s use of multiple Large Language Models adds balance. LLMs act as the analyst’s intuition, interpreting ambiguous signals, correlating weak indicators, and generating verdicts that mirror the reasoning of a seasoned security professional. By combining deterministic rigor with LLM-driven reasoning, Intezer delivers verdicts that are both accurate and insightful. The deterministic layer ensures consistency and confidence, while the LLM layer brings flexibility, context, and adaptability. Together, they augment the work of human analysts, delivering machine speed and scale to the task of alert triage and response. Read more about how Intezer follows Anthropic’s best practices. Everything you need, out of the box Intezer also eliminates the integration tax. With built-in threat intelligence, enrichment, and triage tooling, our platform connects directly to your existing alert sources (EDR, SIEM, cloud, and more). No additional stack or bolt-ons required. See all Intezer integrations. Top-tier human analysis at scale The AI SOC market is crowded, and not all “AI” carries the same weight. As you evaluate solutions, dig deeper than the buzzwords. Ask how the platform balances deterministic accuracy with AI flexibility, how it creates verdicts, and how it reduces, not adds to, the workload of your team. Inquire about vendor pricing. Make sure it’s not based on the volume of alerts being triaged as this may force you to cherry-pick which alerts to ingest. At Intezer, we believe that replicating human analysis at scale requires both the guardrails of determinism and the intuition of AI. Together, they deliver the SOC accuracy, speed, and efficiency that modern security teams can trust. To learn more about Intezer and see how our AI SOC platform can help you focus on real threats, book a demo today!

Frankenstein Variant of the ToneShell Backdoor Targeting Myanmar September 10, 2025 Written by Nicole Fishbein ToneShell is a lightweight backdoor tied to the China-nexus group Mustang Panda. Typically delivered via DLL sideloading inside compressed archives with legitimate signed executables and often spread through cloud-hosted lures. Zscaler’s 2025 analysis described updates to its FakeTLS C2 (shifting from TLS 1.2- to 1.3-style headers), use of GUID-based host IDs, a rolling-XOR scheme, and a minimal command set for file staging and interactive shell access. Notably, some of this activity was observed in Myanmar, a region of strategic importance to China. Targeting Myanmar is particularly interesting as it reflects China’s broader geopolitical interests, spanning border security, infrastructure projects, and political developments, and highlights how cyber operations are leveraged to maintain influence in neighboring states. This blog is a technical analysis of another variant of the backdoor. While this variant does not introduce major new features, it is worth highlighting the anti-analysis techniques it employs and the new indicators that can support threat hunting and detection. In addition, the continued targeting of Myanmar underscores China’s sustained use of cyber operations to maintain its interests abroad. Technical Analysis As previously documented, ToneShell is a dll that is sideloded by a legitimate executable, usually bundled in the archive file. In this case it is a ZIP file ,named: TNLA နှင့် အခြားတော်လှန်ရေးအင်အားစုမျာ. Which translate to: TNLA and other revolutionary forces. The backdoor first checks the current module path for the string Google\DriveFS\Scratch. If not found, it enumerates processes to identify the parent process, retrieves its image path, and verifies whether it contains GoogleDrive. If found, the backdoor will terminate its execution. This check might be an attempt by the threat actor to prevent infecting themselves. If this validation fails, the code enforces a single-instance policy using a named mutex, Global\SingleCorporation12AD8B. It attempts to create the mutex, storing the handle globally and setting a flag to indicate success or failure. If creation fails or the mutex already exists, it releases any handles and marks it as not created. Next, the backdoor checks its persistence location. It compares its module path with the user profile directory (CSIDL_APPDATA, 0x1A). If the binary is not under the user profile, it copies itself and the following files: msvcr100.dll, msvcp100.dll, mfc100.dll to a new folder it creates. The new directory name consists of a 6-character random uppercase folder name (e.g., C:\Users\ \AppData\ ). The function that copies the DLLs to a new folder in AppData Once installed, it attempts to spin up the Task Scheduler COM service, connect to the local scheduler, open the root folder ("\") and obtain an IRegisteredTask for a task named dokanctl. If the task doesn’t exist, it will create it using RegisterTaskDefinition. The task is set to execute every minute, it sets the execution path to the folder in AppData created earlier: %APPDATA%\ \svchosts.exe, and sets it as the action Path. The task is registered in the root folder with the name dokanctl. Task creation If the backdoor is already under the user profile, it performs junk arithmetic before entering its C2 loop, followed by a bounded timing/zero-check loop that appears to serve as anti-analysis noise without affecting the main flow. API Function Hashing The malware uses a custom API-resolving scheme based on a simple rolling hash, applying it to module and function names instead of storing them in cleartext. This technique, previously analyzed in previous blogs, is a common evasion method seen in different malware types. With the HashDB project, resolving these hashes back to the original imported functions is straightforward, making analysis and detection easier. Hash calculation Resolved Windows API functions Anti-Analysis and Anti-Sandboxing This ToolShell variant employs several stalling and anti-sandboxing tricks designed to waste time, confuse automated analysis, and evade lightweight sandboxes. These include: Repeated file churn: creating, writing, closing, and deleting a temporary file in a loop with Sleep(100) delays, which burns execution time and stresses filesystem emulation. Randomized sleep loops: several loops sleep for pseudo-random intervals ranging from ~800 ms to over a second per iteration, accumulating 20+ seconds of startup delay before meaningful behavior begins. Tick count checks: uses GetTickCount64() combined with jittered sleeps, waiting until at least 10 seconds of wall-clock time has elapsed. This ensures that emulators that don’t advance the system clock realistically can get stuck. Opaque string comparisons: slides across a large embedded wide-string buffer, repeatedly calling lstrcmpW() between overlapping substrings until a break condition. The comparison results are discarded; the loop simply consumes cycles and obfuscates control flow. Nonsense randomization: calculates values like 0xBABE or 0xCAFE via contrived branches using rand(). These values are not security checks, but serve as junk arithmetic to make the code harder to follow. Decoy API use: occasionally calls APIs such as OutputDebugStringA and sets LastError to unusual constants (0xBADF00D), further muddying behavior without altering core logic. File creation loops Notably, the large embedded string buffers used in the comparison loop contain text copied from OpenAI’s blog on image generation and from Pega AI’s website. Pega AI refers to the artificial intelligence features integrated into the Pega platform, a software suite for workflow automation and customer relationship management. The backdoor does not use this content functionally; instead, it serves as filler to inflate the binary and supply meaningless strings for comparison. Text taken from PegaAI’s website Text taken from OpenAI’s website Together, these techniques do not detect debuggers directly; instead, they stall execution, pollute control flow with junk work, and frustrate automated sandboxing systems that expect short-lived, straightforward malware runs. GUID Creation Similar to earlier versions, this variant of ToneShell generates a unique identifier for each infected machine. It first attempts to check if one was already created by reading 16 bytes from C:\ProgramData\SystemRuntimeLag.inc. The malware creates a new seed if the file is missing, unreadable, or does not provide exactly 16 bytes. The primary method is to generate a GUID via CoCreateGuid and use it as the seed. If that fails, it falls back to producing 16 bytes using an internal linear congruential generator (LCG) seeded from the current PRNG state. Once a new seed is generated, it is written back to the designated file path to ensure persistence across executions. This logic is similar to Zscelar’s blog about the second backdoor variant. Networking The malware sets up a socket with a C2 at the address: 146.70.29[.]229:443 The malware’s network protocol wraps its messages in a TLS-like record header to blend in with legitimate traffic. Each packet begins with the fixed bytes 17 03 03 (TLS 1.2 Application Data) followed by a two-byte length field, but only the low byte is honored, effectively capping payloads at 255 bytes. The 5-byte header is read into a temporary stack buffer and discarded; only the payload bytes are stored in the context structure’s receive buffer starting at offset 0. Once the payload is received, the malware XOR-decodes it in place with a 256-byte rolling key. The first decoded byte is treated as a “type/status” field, the second as an additional code, and the remainder (len-2 bytes) as the message body. The decoded buffer pointer is then saved in the structure for later use. This design produces a simple packet format: [TLS-like header][XOR-obfuscated type | code | body…], with the header stripped before the data is available to the rest of the malware. Interestingly, while the GUID generation logic in this sample aligns with the first version of ToneShell described by Zscaler, the communication protocol remains identical to the second version. Combined with the anti-analysis techniques and the use of text copied from AI platforms, this sample stands out as a hybrid variant. Pivoting on The C2 Address Pivoting on the C2 address, we were also able to find another variant: In summary, this analysis of a new ToneShell backdoor variant highlights the evolving tactics of the Mustang Panda group, particularly their sustained targeting of Myanmar. While not introducing revolutionary features, this variant employs anti-analysis techniques, including elaborate stalling mechanisms and obfuscated code. The blend of old and new elements, such as the consistent communication protocol alongside updated GUID generation and the use of seemingly random, copied text for filler, underscores the adaptive nature of this threat. The continuous refinement of these evasion methods, coupled with the geopolitical significance of the targeted region, reinforces the need for ongoing research and threat hunting to counter cyber operations.

Threat Bulletin: Fire in the Woods – A New Variant of FireWood August 13, 2025 Written by Nicole Fishbein A new and low-detected variant of the FireWood backdoor was discovered by Intezer's Research Team, with some changes in the implementation and the configuration of the backdoor. FireWood is a Linux backdoor discovered by ESET’s research team. They linked it to the long‑running “Project Wood” malware lineage, which dates back to at least 2005 and includes usage in the earlier Operation TooHash campaign. It functions as a remote access trojan (RAT) on Linux systems, employing kernel‑level rootkit modules (e.g., usbdev.ko) and TEA‑based encryption to hide its presence, maintain persistence, and communicate covertly with its command‑and‑control infrastructure. Once deployed, likely via web shells left on compromised Linux desktops, it enables attackers to execute commands, exfiltrate sensitive data such as system information and credentials, and operate stealthily over prolonged espionage operations. The backdoor has low confidence connections to the China-aligned Gelsemium APT group, as the overlaps may be coincidental or reflect shared tools across multiple groups. We found a new and low-detected variant of the FireWood backdoor. The core functionality of the backdoor remains the same but we did notice some changes in the implementation and the configuration of the backdoor. It is unclear if the kernel module was also updated as we were not able to collect it. Technical Analysis of New Firewood Variant In the older variant, execution began with an explicit permission gate, calling CUser::IsSuc(), and the process would exit if this check failed. In the newer build, that early check is removed entirely. The new version defers any root‑or‑kernel gating until after it daemonizes and saves its PID. To achieve this, the code splits the former SavePidAndCheckKernel() helper into two discrete steps: an early SavePid(pid), followed later by CModuleControl::AutoLoad() and CheckLkmLoad(). This separation clarifies the startup sequence and enhances the hide‑via‑kernel‑module logic. Additionally, rather than simply sending a stripped‑down identifier, the updated version builds a larger buffer containing the process name, hex‑formatted port, PID, a hardcoded “kde‑tra” process name, and a configurable flag (or the literal “nothing”). That extra metadata is passed through CHideProcess::NetLinkInit(), CHideProcess::SendProcessName(&CHideProcess::mInstance), and CHideProcess::Destroy(). Note the typo in the method name “Destroy”, this error also appears in the older Firewood variant. Another typo persists in both versions in the following error message: “Get Memory Faile”. On the networking side, the older version read configuration settings that defined both the number of days between beaconing and a delayTime specifying the interval between packets. It also used a randomized time‑window algorithm to stagger connections. The new build collapses all of this into a straightforward while (true) loop. After waiting for the configured startup delay, it continuously calls ConnectToSvr(), sleeping briefly on failure, until success or until the overall timer expires, then cleans up and exits. By removing the multi‑stage scheduling and random timing logic, the connection routine becomes more predictable and maintainable, trading temporal obfuscation for reliable C2 reachability. Overall, the communication protocol and C2 setup remain the same; the only significant change is that the new version no longer relies on timeouts from the configuration. Both Firewood versions collect information about the user and the infected machine. The new variant adds a fallback for OS detection: whereas the older version reads distribution data from /etc/issue, the new version falls back to /etc/issue.net if /etc/issue is unavailable, parsing the data in the same way. The backdoor defines file paths used by both itself and its kernel module. The new variant sets paths for root users as: /usr/lib/.kde-root/ /usr/lib/.kde-root/lib/ /usr/lib/.kde-root/data/ /usr/lib/.kde-root/kdeinit /usr/lib/.kde-root/pid /etc/init.d/rc.local For non-root users, it uses: $HOME/.kde-root/ $HOME/.kde-root/lib/ $HOME/.kde-root/data/ $HOME/.kde-root/kdeinit $HOME/.kde-root/pid $HOME/.bashrc By contrast, the older variant for root users used: /etc/init.d/rc.local /etc/rc.d/rc.local /etc/init.d/boot.local And for non-root users: $HOME/.bashrc The FireWood backdoor supports a number of commands documented by ESET. The new variant removes some commands and adds others. It drops commands for changing beacon intervals and delay times (command IDs 0x111, 0x113, 0x114), as these settings are no longer used. It also removes the file-read command (ID 0x201). The process‑hiding command has moved to ID 0x202 (from 0x112), and the HideModule function was removed. A new command (SetAutoKillEl, ID 0x160) toggles or sets an “auto‑kill” feature in the agent. Besides these commands, there are also three commands that appear in both versions and were not previously documented: Command id 0x109: A command that indicates a change in the connection configuration. Command id 0x192: Gets a file from the C2 and execute it using the system function. Unlike the previously documented command id 0x185, this command calls first ‘CFileControl::FileUp’ to receive the file from the C2. Command id 0x195: Exfiltration of files with the following extensions: v2, .k2, .W2, and drive.C2. We also located an older sample submitted to VirusTotal from Iran on February 5, 2025:

The AI cybersecurity market is booming. Everywhere you look there are vendors offering intelligent assistants, agentic triage engines, AI SOC agents, or autonomous response platforms. But with so many buzzwords and overlapping capabilities, how can you cut through the noise? This guide is here to help you evaluate AI SOC tools, which are designed to automate the triage and investigation of high volumes of security alerts. We’ll break down the six most important criteria for evaluating solutions and share smart questions you can ask vendors to assess whether their solution delivers and will meet your SOC team's specific needs. 1. Time to Value The best AI SOC tools shouldn’t require long evaluations, months of engineering work, or prolonged learning or tuning phases. Look for solutions that deliver value quickly and integrate seamlessly with your environment. Ask vendors: How long does it take to become fully operational? What integrations are supported out of the box? Will we need to develop playbooks or rules before we see value? 2. Customizability and Adaptability Every SOC is different. Your AI platform should mold to your tools, workflows, and detection logic—not the other way around. Ask vendors: Can we customize how alerts are triaged or resolved? How do you support changes in our environment (e.g., new data sources)? Does tuning require professional services or coding expertise? 3. Depth of Investigation Surface-level enrichment is not enough. You need tools to perform forensic-grade investigations and collect meaningful evidence across endpoint, cloud, and identity sources. Ask vendors: What types of evidence does your platform collect? Do you support memory analysis, script inspection, or sandboxing? Is evidence presented in a way that’s actionable and verifiable? What are the platform’s detection capabilities? Does it integrate with threat intelligence feeds? How are the depth of investigations improved by this capability? 4. Accuracy, Consistency, and AI Explainability False positives create noise. Missed detections create risk. Your AI SOC must consistently deliver verdicts that are both accurate and explainable. Ask vendors: How do you validate the accuracy of your verdicts? What’s your false positive/true positive rate? How transparent are triage decisions? Can the AI explain how it reached its conclusions? How would someone know if the AI is working, when, and what steps and outcomes are being conducted by certain parts of the model? Read More: 3 Critical Metrics for Evaluating AI SOC Solutions 5. Speed to Resolution AI should reduce your mean time to respond (MTTR). Look for solutions that autonomously triage alerts and resolve incidents in near real-time. Ask vendors: What is your median investigation and resolution time? Can the platform autonomously take action (e.g., containment, ticket closure, escalation)? How do you handle alert prioritization without analyst input? How do workflows correlate/interact with analyst work when triage is escalated or remediated? 6. Scalability and Pricing Model You shouldn’t have to pick and choose which alerts to triage based on cost. The right AI SOC platform will scale with your environment, without becoming unreasonably expensive to provide total alert coverage. Ask vendors: Is your pricing based on alert volume, endpoints, or something else? Can we ingest and triage alerts from all severities and sources? How do you ensure full alert coverage without sacrificing performance? For MSSPs: What kind of multi-tenant support or features is available? Read More: How MSSPs Use Smart Automation for Fast Incident Response Evaluate AI SOC Tools Based on Your Needs The AI SOC landscape is evolving fast; every vendor sounds impressive on paper. Agentic AI is suddenly the new shiny object of 2025. However, not every solution will align with your needs, risk posture, or operational capacity. Use this guide to ask better questions, validate bold claims, and uncover the reality behind the marketing as you evaluate AI SOC tools. Because the right partner won’t just help you respond faster—they’ll help your SOC team shift from reactive firefighting to proactive, continuous risk mitigation.