D3FEND Evict Tactic: Removing Attackers and Their Access in One Coordinated Window

Most failed incident responses do not fail at detection: they fail at eviction, when the team removes some of the attacker's access and the rest lets them straight back in. MITRE D3FEND gives this step its own tactic, Evict, defined as the tactic "used to remove an adversary from a computer network". This hub explains what the tactic contains, how its three families of techniques fit together, which ATT&CK behaviours they cut off, and the order in which to use them. It is written for incident responders, SOC leads and identity teams who need a working map of the eviction techniques. For the framework as a whole see the MITRE D3FEND Guide.

Key takeaways

• Evict has three families and 16 techniques. Credential Eviction, Object Eviction and Process Eviction, 19 entries in all on the D3FEND tactic page (D3FEND 1.6.0, checked November 2026).
• The families only work together. Ending a process without removing its autostart entry, or deleting malware without revoking the credentials it stole, gives the attacker a way back.
• Credentials are the usual way back. Stolen tokens, added cloud credentials and forged Kerberos tickets survive host clean-up, so Credential Eviction carries most of the weight in modern intrusions.
• Order matters more than tooling. Preserve evidence, scope, stage replacements, then lock, purge, revoke and remove persistence in one window, then verify. D3FEND does not prescribe this order; it is our recommendation.
• Eviction is not finished until it holds. Measure re-entry: any reuse of an evicted credential, reappearance of a removed object or contact with a removed domain means the eviction failed.

What Evict means in D3FEND

D3FEND organises defensive techniques under seven tactics: Model, Harden, Detect, Isolate, Deceive, Evict and Restore. Evict sits after Isolate and before Restore, and the order is meaningful. Isolation limits what an attacker can reach while you work out the scope; eviction takes away their footholds; restoration brings systems and access back to a trusted state.

Each technique in D3FEND is described by the digital artefact it acts on. Evict techniques act on three kinds of artefact, which is why the tactic splits into three families:

• Credential Eviction (D3-CE): "disable or remove compromised credentials from a computer network". The artefacts are user accounts, credentials, tokens and authentication caches.
• Object Eviction (D3-OE): "terminate or remove an object from a host machine", described by D3FEND as "the broadest class for object eviction". The artefacts are files, registry keys, email, DNS cache records, domain registrations and whole disks.
• Process Eviction (D3-PE): techniques that "terminate or remove running process". The artefacts are processes, sessions and the running state of a host.

Evict techniques are actions, not controls you deploy once. They need detection and scoping to tell them what to act on, and several are destructive, so decision rights and sequencing matter as much as tooling.

Every technique in the Evict tactic

The table lists every entry on the D3FEND Evict tactic page, with its parent taken from the D3FEND ontology. Definitions are summarised from D3FEND's own text. Each ID links to the detailed page on this site.

Two things in the hierarchy are easy to misread. Disk Erasure and Disk Partitioning sit under Disk Formatting, so the disk techniques together describe wiping and rebuilding a device rather than removing a single object. And Credential Rotation (D3-CRO) is not an Evict technique: D3FEND places it under Credential Hardening in the Harden tactic, even though responders use it in the same window. See D3-CRO Credential Rotation.

How the three families fit together

An attacker who has been inside a network for more than a few hours usually holds three kinds of foothold at once: something running (an implant, a remote session), something stored (a file, a registry run key, a scheduled task, a mailbox rule, a domain they control) and something they can authenticate with (a password, a token, a key, a ticket). Each Evict family removes one kind. Remove fewer than all three and the remaining foothold restores the others.

The token row is the one most often missed. Identity platforms below are listed alphabetically, as examples of the same customer-side step. Google documents that resetting a user's sign-in cookies does not sign the user out of desktop apps such as Google Drive for desktop, and that suspending a user resets those cookies automatically. Microsoft documents that after disabling a user and revoking sessions in Entra ID, access tokens already issued stay valid until they expire, one hour by default, unless the application supports Continuous Access Evaluation. Okta documents that its revoke user sessions operation (DELETE /api/v1/users/{userId}/sessions) revokes OAuth and OpenID Connect tokens only when oauthTokens=true is set, and does not clear sessions created by web or native apps. In each case the identity provider action is necessary but not sufficient, and the application layer needs its own step. RFC 7009 sets the protocol baseline: an authorisation server that revokes a refresh token "SHOULD also invalidate all access tokens based on the same authorization grant" if it supports access token revocation.

Sequencing an eviction

D3FEND lists techniques; it does not say in which order to run them. The sequence below is NHI Mgmt Group's recommendation, built so each step removes a fallback the attacker could use against the next. It assumes the incident has been detected and the affected hosts isolated (see the D3FEND Isolate Tactic hub and the Incident Scoping and Containment Strategy Guide).

1. Preserve evidence. Capture memory and disk images, or at least copies and hashes of the objects you will remove. Suspend (D3-PS) rather than terminate where you need process memory. Deletion, termination and reboot destroy evidence you need for scoping and for any notification decision. See the Forensic Readiness Guide.
2. Scope the whole footprint. Use indicators from the first host to sweep every host, mailbox and tenant. Build one eviction list covering credentials (D3-CCSA, see D3-CCSA Credential Compromise Scope Analysis), objects and running processes.
3. Stage replacements. Prepare new secrets, certificates and break-glass access before anything is revoked, so the eviction window does not become an outage that someone cuts short.
4. Execute in one window. Lock accounts (D3-AL), terminate sessions (D3-ST) and invalidate caches and tokens (D3-ANCI); revoke exposed credentials (D3-CR) and switch consumers to replacements; terminate implants (D3-PT); delete persistence objects (D3-FEV, D3-RKD, D3-ER). In hybrid Active Directory environments Microsoft's emergency revocation guidance resets a compromised user's password twice; where forged Kerberos tickets (T1558.001 Golden Ticket) are suspected, the KRBTGT account password also needs a double reset.
5. Cut external infrastructure. Request takedown of attacker domains (D3-DRT), correct any tampered DNS records, then flush resolver caches (D3-DNSCE) so stale answers do not linger.
6. Rebuild what cannot be trusted. Where a host had kernel-level or firmware-level compromise, or where scoping cannot rule out hidden persistence, wipe and rebuild (D3-DKE, D3-DKF, D3-DKP) rather than clean. That hands over to the D3FEND Restore Tactic.
7. Verify and watch. Test that every evicted credential is rejected, rescan for every removed object, and keep heightened monitoring on the indicators for an agreed period (30 days is a common example, not a standard).

Rollback: only some Evict actions are reversible. Account Locking and Process Suspension can be undone; Credential Revocation, Disk Erasure and Domain Registration Takedown cannot. Export registry keys and quarantine files before deletion where your tools support it, keep a list of locked accounts with an owner who can unlock critical ones, and require a second approver for destructive actions.

Choosing the right technique

Most families have a gentle option and a decisive one; the choice depends on evidence needs, business impact and confidence in scope.

Small organisations usually run eviction by hand from the identity provider console and endpoint tool; the sequence matters more than automation, and a written runbook with pre-approved destructive actions is the main gain. Large organisations should pre-build response actions (session revocation, host isolation, mailbox purge) in their SOAR or EDR platform with approval gates, because a coordinated window across thousands of identities and hosts is not achievable by hand.

ATT&CK techniques the Evict tactic counters

D3FEND relates its techniques to ATT&CK through shared digital artefacts and labels these relationships as inferred and experimental. They show which behaviours an eviction action can cut off, not tested coverage. The selection below is drawn from the three family pages, uses ATT&CK v20 IDs, and is grouped by tactic.

D3FEND's pages still list some ATT&CK IDs that v20 has revoked. The one that matters most for eviction is Disable or Modify Tools, now T1685 under the v20 Defense Impairment tactic (TA0112): an attacker who has disabled your endpoint agent can block process and file eviction, so confirm agent health before relying on it. See the EDR Tampering and BYOVD Response Playbook.

Where identity fits: non-human credentials

Credential Eviction is where non-human identities make eviction hardest. Service accounts, API keys, OAuth client secrets, workload certificates and personal access tokens often have no owner on call, are embedded in several systems, and cannot be locked without breaking production. Attackers favour them for persistence for the same reasons: T1098.001 Additional Cloud Credentials adds a new secret to an existing application identity, which survives a password reset of every human account.

• Inventory first: eviction can only cover the machine credentials you know about. Credentials found in scope analysis but missing from inventory are the ones attackers come back with.
• Revoke, do not lock: for most secrets and keys, D3-CR (delete and reissue) is the meaningful action; D3-AL applies to the account, not the secret.
• Check what the identity created: new credentials, role assignments and federation trusts added by a compromised application identity must be removed in the same window.

See the Workload Identity Compromise Response Playbook and the Leaked Credential Response Playbook.

Detection and measurement

Eviction needs its own telemetry: proof that each action ran and proof that it held.

• Action logs: identity provider audit events for account disable, session revocation and credential deletion; EDR response action logs; mail platform purge logs; registrar and DNS change records.
• Re-entry signals: any authentication attempt with an evicted account, key or token; reappearance of a removed file hash, registry value or scheduled task; resolution of or connection to a removed domain.
• Persistence re-creation: new accounts, new application credentials or new role assignments in the days after eviction.

Useful metrics (example targets, not standards):

• Eviction completeness: share of items on the eviction list confirmed removed or revoked. Target 100 per cent before closing the incident.
• Eviction window length: time from the first eviction action to the last.
• Time to session revocation: from the decision to evict to all sessions and refresh tokens revoked for affected identities.
• Re-entry rate: incidents where the same actor regained access within 30 days of eviction.
• Machine credential coverage: share of compromised non-human credentials revoked and reissued, against those identified in scoping.

Framework mapping

Common failure patterns

• Piecemeal eviction: cleaning the first host found while the attacker still controls others.
• Password reset treated as eviction: refresh tokens, session cookies and added application credentials survive a password change, as the identity provider documentation above shows.
• Evidence destroyed first: terminating processes, deleting files or reimaging before capture leaves no basis for scoping or for notification decisions.
• Machine credentials left out: human accounts are reset but service account secrets, API keys and CI/CD tokens on compromised hosts are not, so the attacker returns as a workload.
• No replacement staged: revoking a production secret without a replacement causes an outage, and the eviction gets rolled back under pressure.
• Closing without verification: the incident is closed when actions are taken rather than when re-entry monitoring confirms they held.

Practitioner checklist

• Pre-authorise destructive Evict actions (credential revocation, host reboot, mailbox purge, disk erasure) and name who approves them out of hours.
• Document, per identity provider and major application, which action revokes sessions, refresh tokens and access tokens, and how long tokens stay valid afterwards.
• Build one eviction list per incident covering credentials, objects and processes across all affected hosts, mailboxes and tenants.
• Capture evidence before any termination, deletion or reboot.
• Stage replacement secrets and break-glass access before revoking anything.
• Run all eviction actions in one coordinated window and record each action with its timestamp.
• Include non-human credentials, attacker-created accounts, added roles and federation trusts in scope.
• Request takedown of attacker domains and flush DNS caches after records are corrected.
• Rebuild rather than clean hosts with signs of deep persistence.
• Monitor for re-entry for an agreed period and close the incident only when it holds.

Standards and references

• MITRE D3FEND: Evict
• MITRE D3FEND: Credential Eviction
• NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• IETF: RFC 7009 OAuth 2.0 Token Revocation
• Google Workspace Admin Help: Sign a user out of their managed Google account
• Microsoft Learn: Revoke user access in an emergency in Microsoft Entra ID
• Okta Developer: Revoke all user sessions
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: MITRE D3FEND Guide · Identity Incident Response Playbook · Incident Response Guide · D3FEND Detect Tactic · Digital Forensics (DFIR) Guide