When a session token is stolen, how long before every app signs that user out?
An attacker who buys a session cookie or talks the help desk into an MFA reset never trips a malware alert. We find the identity weaknesses those attacks rely on, write detections for them, and wire up revocation so one decision ends the session everywhere.
Identity threat detection and response (ITDR) finds and stops attacks that abuse identity systems instead of endpoints, such as stolen session tokens, MFA fatigue, help desk social engineering, rogue OAuth consents and Active Directory privilege escalation.
Cohash reviews your identity attack surface, builds detections in Okta, Microsoft Entra and Defender for Identity, and automates the response, from session revocation to Shared Signals events between platforms.
you probably need this if
You disable a user at the identity provider, and their SaaS sessions keep going for hours.
The help desk resets MFA for anyone who sounds convincing on the phone.
Your SIEM has no rule for when a new MFA method gets registered right after a password reset.
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Identity Threat Detection & Response, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · identity threat detection &…3 open
openYou disable a user at the identity provider, and their SaaS sessions keep going for hours.
recurringThe help desk resets MFA for anyone who sounds convincing on the phone.
blockedYour SIEM has no rule for when a new MFA method gets registered right after a password reset.
exposure
Identity attack-surface reviewDetections for identity attacksRevocation that reaches every appShared Signals between platformsHelp desk verificationHardening the IdP itself
startrehearsehandover
Assess
Detect
Respond
Rehearse
we are here
ready to hand over
Reset, new authenticator, inbox rule: that chain now fires one high-severity alert and…
Going from domain user to domain admin through certificates no longer works.
Identity attack-path findings ranked by impact
Detection rule set with test cases
chapter 01 · where it hurts
Why teams reach out
You disable a user at the identity provider, and their SaaS sessions keep going for hours.
The help desk resets MFA for anyone who sounds convincing on the phone.
Your SIEM has no rule for when a new MFA method gets registered right after a password reset.
chapter 02 · what we change
How we solve it
Identity attack-surface review
Detections for identity attacks
Revocation that reaches every app
Shared Signals between platforms
Help desk verification
Hardening the IdP itself
chapter 03 · how it runs
Our approach
Assess
Detect
Respond
Rehearse
chapter 04 · where you end up
What changes
Reset, new authenticator, inbox rule: that chain now fires one high-severity alert and kills the sessions.
Going from domain user to domain admin through certificates no longer works.
Identity attack-path findings ranked by impact
Detection rule set with test cases
what we do
Where we spend the hours
6 areas of work, each one done by an engineer who has run it in production.
Kerberoastable service accounts, unconstrained delegation, weak AD CS certificate templates, stale admins, MFA gaps and over-permissioned OAuth apps, ranked by what an attacker could reach from each.
Rules for token replay from unfamiliar devices, MFA push bombing, a new MFA method registered minutes after a password reset, and consent grants to unknown apps. Each is tuned against your own sign-in baseline.
Revoking at the IdP is only half the job. With Okta Identity Threat Protection and Universal Logout, or Entra risk policies with continuous access evaluation, a risky session gets cut off inside the SaaS apps as well.
The OpenID Shared Signals Framework and CAEP became final specifications in 2025. We set up transmitters and receivers so your EDR, IdP and SaaS apps tell each other when a user's risk changes.
Caller verification for password and MFA resets, such as a video ID check or manager approval, because a convincing phone call is now a common way in.
The identity provider's admin console, API tokens, federation trust settings and log forwarding all get locked down. An attacker with any of those can mint their own access.
capability 01 / 06in production
Identity attack-surface review
Kerberoastable service accounts, unconstrained delegation, weak AD CS certificate templates, stale admins, MFA gaps and over-permissioned OAuth apps, ranked by what an attacker could reach from each.
Rules for token replay from unfamiliar devices, MFA push bombing, a new MFA method registered minutes after a password reset, and consent grants to unknown apps. Each is tuned against your own sign-in baseline.
Revoking at the IdP is only half the job. With Okta Identity Threat Protection and Universal Logout, or Entra risk policies with continuous access evaluation, a risky session gets cut off inside the SaaS apps as well.
The OpenID Shared Signals Framework and CAEP became final specifications in 2025. We set up transmitters and receivers so your EDR, IdP and SaaS apps tell each other when a user's risk changes.
The identity provider's admin console, API tokens, federation trust settings and log forwarding all get locked down. An attacker with any of those can mint their own access.
We pieced these together from Identity Threat Detection & Response situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Help desk MFA reset, then a new authenticator and a forwarding rule
composite · not a client story
Beforethe situation
Someone called the help desk pretending to be a finance manager and got an MFA reset. Within an hour a new authenticator was registered from an unfamiliar network and an inbox rule started forwarding invoices. Each event looked routine on its own, so nothing fired.
What we dothe work
One correlation rule joins the MFA reset, the new method registration and the mailbox rule creation for the same user inside a short window. Its playbook revokes sessions and removes the new method until a callback to a known number confirms the request. Then the help desk procedure changes.
Afterwhere you end up
Reset, new authenticator, inbox rule: that chain now fires one high-severity alert and kills the sessions. And a confident voice on the phone no longer gets anyone an MFA reset.
case file 02
AD CS template letting any domain user request an admin certificate
composite · not a client story
Beforethe situation
One certificate template lets the enrollee supply the subject name, has client authentication turned on, and gives Domain Users enroll rights. Defender for Identity is licensed, but nobody put a sensor on the CA servers.
What we dothe work
We audit every template and CA setting. Enrollee-supplied subjects come out, or enrollment gets restricted to named groups, and any template that has to stay flexible needs CA manager approval. Sensors go on the AD CS servers, with detections for requests where the subject doesn't match the person asking.
Afterwhere you end up
Going from domain user to domain admin through certificates no longer works. Attempts against the templates that remain now raise an alert.
How a risk signal ends a stolen session across your apps
Device risk, sign-in telemetry and help desk resets feed identity threat detection and SIEM rules. When risk changes, the identity provider revokes the session and pushes that decision to apps through Universal Logout or CAEP.
We don't start a step until the last one has produced something you can check.
step 01
Assess
Configuration and log review of Active Directory, Entra, Okta and key SaaS apps against known identity attack paths.
step 02
Detect
Detections written, then tested with safe attack simulations in a lab or test tenant.
step 03
Respond
Playbooks revoke sessions, reset credentials and disable devices. Where the risk is high and the action is easy to reverse, we automate it. The rest waits for a person.
step 04
Rehearse
We run a tabletop built on a realistic identity attack, then fix whatever the playbooks got wrong.
you keep
What you're left with
We write these for your Identity Threat Detection & Response setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
talent and delivery · identity threat detection & response
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
due diligence · identity threat detection & response
Questions to ask any partner, including us.
Put these to anyone bidding on your Identity Threat Detection & Response work. The ones who've done it answer differently from the ones who've read about it.
Q1
If we revoke a user in the IdP right now, which of our apps keep the session alive?
Revoking at the IdP doesn't end a SaaS app's own session. The partner should test each critical app and record how long a stolen session keeps working.
Q2
How will you test detections without running real attacks in production?
A rule that has never fired is a guess. Ask for safe simulations in a test tenant or lab, with the expected events saved as test cases.
Q3
What will you check in our federation trusts and IdP admin settings?
Add a federated domain or a token-signing certificate and an attacker can issue themselves access. Federation settings, admin roles and API tokens on the IdP need their own review, separate from the rest.
Q4
Which response actions will you automate, and which need a human?
Revoking a session is cheap and reversible. Disabling an executive's account at quarter-end isn't. The split should follow reversibility and business impact.
Q5
How will you fix Kerberoastable accounts without breaking the apps behind them?
Service accounts with SPNs and weak passwords are easy offline cracking targets. Moving them to gMSAs or long rotated passwords needs dependency checks first.
01How is ITDR different from what our XDR already does?
XDR tools see endpoints and email well. Identity attacks often involve no malware at all, just a valid token used from the wrong place. ITDR watches identity telemetry and responds in identity terms, by revoking sessions or blocking MFA registration. It works best feeding the SIEM rather than replacing it.
02Do we need a separate ITDR product?
Not always. Okta Identity Threat Protection, Entra ID Protection and Defender for Identity cover a lot when they're licensed and switched on. We check what you already own first. If a real gap remains, such as coverage for a second identity provider, that's when we'd suggest another tool.
03How quickly can a user be signed out of everything?
It depends on each app. Apps that support Universal Logout or CAEP can drop a session within minutes. Apps that only honor token expiry keep working until the token lapses, so we shorten token lifetimes for those and record them as residual risk.
04Can you help during an active identity incident?
We can help contain and clean up identity systems, for example revoking tokens, resetting federation trusts and rebuilding admin access. For full forensics or legal-hold work we coordinate with your incident response retainer.
05Does ITDR cover Okta and Entra ID together?
Yes, provided both log to the same SIEM. We normalize their sign-in and admin events, and one rule can then track a user across Okta and Entra. Revocation has to be configured in each separately. Neither can kill the other's sessions unless they swap Shared Signals events.
related
Often paired with
Projects on Identity Threat Detection & Response usually end up touching one of these, so they're worth a look.
