How Cato Turns Identity Noise Into High-Confidence Detections

Jeremy, the Head of IT, thought it was a normal Monday until his help desk was overwhelmed with login complaints. 37 employees couldn’t log in. Password resets were happening that nobody could explain, and some devices seemed to vanish from the identity directory. The worst part was that the identity logs did not show a clear break-in. There was no obvious malware and no dramatic spike, only routine-looking admin activity.

This is a fictional scenario, but it reflects a real problem. Identity attacks rarely arrive as one loud alert. They unfold as sequences of “valid” actions that only become suspicious when you see the behavioral pattern. Identity is now the control plane, and attackers increasingly abuse valid credentials, delegated permissions, and identity management APIs. That’s why our research team built the CASB Identity Indicators of Attack (IOAs) Package for Cato XOps, designed to work across multiple out-of-band (OOB) integrations. It turns Apps Security API telemetry into high-fidelity identity alerts using baselines and behavioral context, so security teams get the signal instead of the noise. We also show in this post how Cato MDR leverages this capability and investigates identity attacks in practice.

Why Traditional Identity Detection Falls Short

Most identity detections start with a simple counter. “More than X group changes.” “More than Y password resets.” “More than Z deletions.” It sounds reasonable, and it’s easy to deploy. But in real environments, these rules rarely hold up. Admins and automation legitimately make bulk changes, help desks reset credentials during onboarding and incidents, and identity platforms generate a constant stream of routine activity. Attackers take advantage of that reality by blending in, moving slowly, and staying just under static thresholds. The result is familiar to every defender: alert fatigue, false positives, and low-and-slow identity abuse that never triggers a rule until the damage is already done.

Cato’s CASB Identity IOAs Package

We built the CASB Identity IOAs Package to solve exactly that gap. IOA stands for Indicator of Attack, a behavior pattern that signals attacker progress even when each individual action looks valid. The package is powered by the Cato Anomaly Engine, which learns baselines over time and evaluates activity in context rather than judging events in isolation. Instead of asking “Did this cross a threshold?”, it asks questions that static rules can’t: Is this unusual for this identity? Is this the first time we’ve seen this action from this user or admin? Is the scale or velocity abnormal compared to historical behavior? That’s how Cato XOps surfaces meaningful deviations even when attackers use valid credentials, satisfy MFA, and operate through legitimate-looking admin workflows.

Identity risk areas aligned to attacker objectives

The IOAs package is organized into identity risk areas that reflect common attacker goals and abuse patterns. Each area is powered by Apps Security API telemetry and anomaly-based logic. Table 1 summarizes the coverage: the risk area, what it detects, why it matters, and the related MITRE ATT&CK techniques.

Table 1: Identity IOAs coverage overview by risk area

Real-World Attack Stories: How Identity Abuse Looks Like in Practice

Identity attacks don’t announce themselves with one loud alert. They progress through a chain of valid-looking actions that only become suspicious when you connect them into a pattern, which is exactly where anomaly-based detection shines. The CASB Identity IOAs Package surfaces this kind of identity abuse without relying on brittle thresholds, and Cato XOps groups related signals into a single Story, a timeline with context that shows clear attacker progress.

Below we show as an example three representative identity attacker playbooks, and how Cato Xops are able to detect it, including attacker objectives, how the activity can appear in logs, and the key behavioral signals that help teams investigate faster with less noise.

The Quiet Privilege Climb Story (Figure1)

What the attacker is trying to do: Gain higher privileges without triggering alarms.

What it looks like in the logs (high level): Gradual group/role changes that seem legitimate, and first-time admin actions appear later.

How Cato’s XOps detects it: XOps identifies the overall behavioral shift, revealing a clear pattern of privilege abuse rather than isolated events.

Why it matters: Catches escalation early, before full administrative control is reached.

Figure 1. The Quiet Privilege Climb scenario flow

The Cleanup Crew Story (Figure 2)

What the attacker is trying to do: Cause disruption and slow investigation.

What it looks like in the logs (high level): Bulk deletions of identities and device records, suspicious timing, and rapid destructive actions.

How Cato’s XOps detects it: XOps surfaces unusual identity behavior at scale, highlighting activity that does not align with historical patterns.

Why it matters: Speeds response to destructive identity activity and limits damage.

Figure 2. The Cleanup Crew Scenario Flow

The Password Storm Story (Figure 3)

What the attacker is trying to do: Lock out users and expand control

What it looks like in the logs (high level): Password resets across many users; credential changes that look like help-desk work

How Cato’s XOps detects it: XOps detects abnormal identity behavior, allowing coordinated misuse to be identified in near real time.

Why it matters: Detects credential abuse in progress, not after widespread lockouts.

Figure 3. The Password Storm scenario flow

MDR in Action: Investigating Identity Abuse

Cato MDR monitors identity activity and correlates signals over time to validate suspicious behavior and escalate confirmed risk.

Example: A first occurrence of Entra ID device deletions

In the example shown in Figure 4 XOps story, Cato MDR investigated suspicious deletion activity tied to a federated Microsoft Entra ID user. Roughly 160 device objects were deleted in a short time window, and the behavior did not match the user’s normal baseline. Specifically, this user did not typically delete devices and did not typically perform administrative configuration changes. Because bulk device deletions can disrupt device trust and reduce security visibility, MDR escalated the incident to the customer and advised that if the activity was not approved, the customer should restrict the account, revoke active sessions, review and reduce unnecessary privileges, and restore deleted device objects where possible while validating relevant Conditional Access policies.

The analyst can drill down into the underlying events for deeper analysis of the burst and abnormal behavior.

Figure 4. XOps Story: Detection for a first occurrence of bulk Entra ID device deletions

Final Key Takeaways

Attackers don’t need zero-days when they can quietly abuse identity with valid access and blend into normal admin workflows. Defenders don’t need more alerts; they need sharper logic that separates routine changes from real-attacker progress. That’s what the CASB Identity IOAs Package for Cato XOps delivers. It uses behavioral baselines and anomaly context to surface meaningful deviations, reduce alert noise, and turn raw identity telemetry into high-confidence detections and actionable investigations, so teams can respond early, before “legitimate-looking” activity becomes business impact.