Identity risk is rising: why ITDR belongs in every security programme

Identity is the new perimeter, and it is under pressure#

For years, security programmes invested heavily in endpoints, email gateways, and network controls. Those layers still matter. What changed is where attackers spend their time once the easy malware path gets harder.

They go after identity.

Stolen passwords, hijacked sessions, consent prompts, helpdesk social engineering, and quiet mailbox access now sit at the centre of many real incidents. The attacker often never drops a payload on a managed device. They log in as someone who already has access, then use the same portals your staff use every day.

That is why ITDR (Identity Threat Detection and Response) has moved from niche jargon to an operational necessity. Prevention (MFA, conditional access, privileged access hygiene) is required. It is no longer enough on its own.

The threat landscape: risk has shifted upstream#

Modern estates are identity-heavy by design:

• Cloud email and collaboration
• VPN and remote desktop for hybrid work
• SaaS finance, HR, and CRM portals
• Federated SSO into dozens of apps
• Self-service password resets and helpdesk workflows

Each of those is a door. Attackers do not need to break every door. They need one valid session, one reset, or one person who trusts the wrong prompt.

Industry reporting and incident response work keep pointing at the same pattern: initial access is frequently credential or session based, then the rest of the attack looks like normal business activity. That makes detection harder if your tooling still assumes "malware on the laptop" is the main signal.

The risk is rising for a few practical reasons:

1. More internet-facing identity surfaces (RDS/RDP gateways, webmail, SSO portals, partner B2B access)
2. MFA that can be phished or relayed if it depends on user approval of a push, or on a session cookie after a successful login
3. Helpdesks under volume pressure, where social engineering thrives
4. Token and cookie theft that bypasses "enter your password again" assumptions
5. Business email compromise payoffs that remain high for relatively low attacker effort

The reality of what is happening#

In real incidents, the story rarely starts with a sophisticated zero-day. It starts with something ordinary:

• A user opens a convincing sign-in page
• A contractor's password is reused from another breach
• Someone approves an MFA prompt they did not initiate
• An attacker calls the service desk claiming to be locked out before a critical meeting
• A dormant account still has access to a legacy remote desktop farm

Once inside, the attacker behaves like a rushed employee: open Outlook on the web, check Teams or calendar, look for invoice processes, find VPN or RDS bookmarks, reset or enrol another MFA method if possible, and expand to adjacent apps through SSO.

Endpoint antivirus may stay quiet the whole time. From the directory's point of view, many of these actions are successful authentications.

That is the uncomfortable reality: a large share of modern compromise looks like login success, not exploit failure.

Adversary-in-the-middle: when MFA is not the finish line#

Adversary-in-the-middle (AiTM) phishing is one of the clearest examples of why "we have MFA" is not a complete answer.

In a classic password phish, the attacker steals a password and hopes MFA is off. In AiTM, the attacker proxies the real sign-in experience in real time. The user types credentials into what looks legitimate. MFA completes against the real identity provider. The attacker then captures the session cookie / primary refresh token (or equivalent) and replays it.

From the victim's perspective, they signed in and continued with their day. From the attacker's perspective, they now have a live session that often does not ask for the password again.

What follows is usually not flashy:

• Open webmail as the user
• Search for "invoice", "payment", "bank", "password", "VPN"
• Create inbox rules that hide replies or divert threads
• Register an additional authentication method if the portal allows it
• Access connected SaaS apps that trust the same session

AiTM does not mean MFA is pointless. It means phishable MFA and session replay need detection and response, not only stronger slogans on a policy slide.

Social engineering: people are part of the identity control plane#

Technical phishing is only half the story. Attackers also social-engineer the humans who can change identity state:

• Helpdesk password resets without strong identity proofing
• MFA re-enrolment after a "lost phone" story
• Urgency theatre ("I'm with the CFO, board pack in ten minutes")
• Callback attacks where the victim is persuaded to run remote support tooling
• Vendor or partner impersonation against accounts payable

These attacks succeed because identity processes are operational, not ceremonial. Someone has to unlock accounts, reset factors, and unblock travel logins. If those workflows lack strong verification, step-up checks, and after-the-fact monitoring, attackers will use them as a service desk API.

Social engineering also pairs with technical access. The attacker who already has a mailbox can craft highly targeted internal messages. The attacker who already has calendar access knows when people are out of office. Trust becomes an exploit path.

Internet-facing assets: logging in as the user is the payload#

A common misconception is that attackers only want domain admin on day one. Plenty of financially motivated and espionage-oriented actors are happy to log into what is already exposed:

Remote Desktop / RDS and similar gateways#

Internet-facing RDP, Remote Desktop Services gateways, and published desktops remain high-value. With valid credentials (and sometimes after MFA fatigue or token theft), an attacker gets an interactive desktop, mapped drives, internal line-of-business apps, and a foothold that looks like remote work.

From there they can:

• Access file shares and finance systems
• Run tooling under an existing user context
• Look for stored credentials, scripts, or VPN profiles
• Move laterally using the same trust relationships the user already has

Online portals and SaaS#

HR, ERP, CRM, ticketing, and customer portals are identity destinations. Once SSO or portal credentials are in hand, attackers harvest personal data, change bank details on supplier records, create forwarding rules in CRM email, or export customer lists.

Cloud identity admin surfaces#

If a privileged identity is taken, the attacker can create apps, grant consents, add credentials to service principals, or weaken conditional access. That is still identity abuse, just higher up the stack.

The important point: many of these actions never look like malware. They look like remote work.

Mailboxes: the quiet command centre#

Email remains one of the highest-ROI targets after identity takeover. When attackers land in a mailbox, they are not only reading messages. They are operating a business process.

Typical activity includes:

• Search and reconnaissance for invoices, bank changes, M&A, legal holds, credentials shared "temporarily" in threads
• Inbox rules that hide security alerts, auto-delete messages from banks, or forward copies externally
• Conversation hijacking in live invoice or payment threads (business email compromise)
• Internal spear phishing from a trusted address to expand access quickly
• Application consent and password reset emails used to deepen persistence
• Exfiltration of attachments and contact lists without touching an endpoint agent

If your detection story stops at "was there a suspicious attachment?", you will miss the attacker who simply logged into Outlook on the web from an unfamiliar location, created a rule, and waited.

Mailbox abuse is identity abuse with a spreadsheet and a sense of timing.

Why prevention alone bottoms out#

Good identity hygiene still matters:

• Phishing-resistant MFA where it fits
• Conditional access and device trust
• Least privilege and just-in-time admin
• Hardening helpdesk reset processes
• Reducing standing access to RDS and legacy protocols
• Attacking dormant accounts and over-privileged guests

But every control has an operator, an exception, a travel scenario, a break-glass path, or a legacy dependency. Attackers specialise in those seams.

When authentication succeeds for the wrong person, you need a second discipline: detect identity threats quickly, investigate them in identity terms, and respond by containing sessions, credentials, and privileges.

That is ITDR.

What ITDR actually means (vendor-neutral)#

Strip away product categories and ITDR is an operating capability:

1. See identity signals as first-class telemetry (sign-in and audit logs)
   Sign-ins, MFA events, risk scores, unusual token use, privileged role changes, app consent, mailbox rule creation, RDS/VPN auth anomalies, impossible travel, new device enrolments, and helpdesk resets.

2. Detect abuse of valid credentials and sessions
   Not only brute force. Also AiTM replay, consent grants, stealthy mailbox rules, anomalous SaaS access after a phish, and privilege escalation inside the directory.

3. Investigate in the language of identity
   Who authenticated, from where, with which method, into which apps, what changed afterwards, and which lateral paths opened.

4. Respond by interrupting the identity attack path
   Revoke sessions and refresh tokens, disable or reset accounts, remove malicious rules and consents, force re-authentication with stronger factors, contain privileged roles, and watch for re-entry.

5. Feed lessons back into prevention
   Close the helpdesk gap, remove the exposed RDS path, tighten MFA methods that were phished, and reduce standing access that made the blast radius large.

ITDR does not replace EDR, SIEM, or email security. It covers the gap those tools leave when the attacker never needs malware because login was enough.

Practical signals worth caring about#

You do not need a shopping list of brands to start improving identity detection. You need coverage and response ownership for patterns like:

• Sign-in success followed quickly by mailbox rule creation or mass search/export
• MFA prompts repeatedly denied or ignored, then suddenly approved
• New authentication method registered after an atypical sign-in
• Access to RDS/VPN or admin portals from unusual ASNs, countries, or device postures
• OAuth / app consent grants that request broad mail or files permissions
• Privileged role activation outside change windows
• Password reset or unlock followed by access to finance systems
• Concurrent sessions that break the user's normal pattern

If nobody is watching those as a coherent identity narrative, an attacker can live in your estate while every individual log line looks "successful".

Closing the gap#

Identity risk is rising because work is remote, apps are federated, and attackers have learned that being the user is quieter than hacking the user.

AiTM phishing, social engineering against resets and MFA, and direct login to RDS, portals, and mailboxes are not edge cases. They are standard tradecraft. Once inside, adversaries read mail, hijack payment conversations, plant rules, enrol persistence, and move through SSO as if they belonged there.

Prevention narrows the door. ITDR assumes someone will still walk through it, then makes sure you notice, understand, and kick them out before the invoice is paid to the wrong account.

If your security programme can detect a malicious binary but cannot reliably detect a stolen session in webmail or a quiet RDS login with a phished identity, identity is still your soft underbelly. Fix that deliberately.

References#

Sources and further reading for the claims above.

• Microsoft Security, From cookie theft to BEC: AiTM phishing sites
• CISA, Implementing phishing-resistant MFA
• Microsoft Learn, Conditional Access overview
• Microsoft Learn, Authentication methods and strengths
• Microsoft Learn, Entra ID sign-in logs
• MITRE ATT&CK T1078, Valid Accounts
• MITRE ATT&CK T1557, Adversary-in-the-Middle
• Sophos X-Ops, 2026 Active Adversary Report (identity-rooted incidents)