Many ransomware incidents no longer begin with a dramatic exploit against a perimeter device. Attackers often start with a password, session token, help-desk manipulation or compromised cloud identity. Once inside, they use legitimate tools to discover systems, increase privilege, copy data and prepare encryption or extortion.
The modern attack path
An attacker may purchase credentials, steal them through phishing, abuse an infostealer or compromise a supplier. They test the account against cloud services, email and remote access. If MFA is weak or poorly configured, the attacker establishes persistence. Next comes reconnaissance: groups, shared drives, backup consoles, security tools and administrator accounts.
The final stage is not only encryption. Modern campaigns combine data theft, disruption and pressure on customers or partners. Identity controls therefore need to protect both the initial login and every important action afterward.
Controls that reduce identity ransomware risk
Use phishing-resistant MFA for administrators and high-value applications. Remove legacy authentication and review conditional-access exclusions. Apply least privilege and just-in-time elevation so a compromised user cannot immediately administer backups or domain policy. Separate backup identities from production identities and protect them with independent credentials.
Monitor impossible travel, unfamiliar devices, unusual token use, mass downloads, new forwarding rules, privilege changes and suspicious service-principal activity. A single alert is not enough; join identity, endpoint, cloud and data events so responders can see the attack path.
Test the human and technical layers
Security assessments should review password policy, MFA enrolment, recovery flows, help-desk verification, OAuth applications, service accounts and privileged roles. Test whether a low-privilege identity can reach administrative functions or backup systems. Validate that an account can be disabled quickly and that active sessions and tokens are revoked.
Phishing simulations should be authorised, limited and educational. The objective is to improve reporting and resilience, not to collect real passwords. Combine them with technical testing and tabletop exercises so staff know what to do when an identity is suspected to be compromised.
Recovery is part of prevention
Immutable or offline backups, tested restoration and a documented decision process reduce the attacker’s leverage. Maintain clean administrative accounts, emergency contacts and an agreed communication plan. If recovery has not been rehearsed, a backup may exist but still fail when the business needs it.
How attackers turn one identity into enterprise access
A compromised account is valuable because it looks normal at first. The attacker can read email, learn naming conventions and discover which applications the employee uses. They may create inbox rules, register another authentication method or grant consent to a malicious application. These changes preserve access even after a password reset.
From there, the attacker looks for trust relationships. Shared drives reveal infrastructure documents. Password vault invitations and support conversations expose operational details. Collaboration platforms identify administrators and vendors. If the user has local administrator rights or can request temporary privilege without strong verification, the compromise can expand quickly.
Cloud environments add service principals, workload identities and API tokens. These identities often lack interactive MFA and may remain valid for months. Attackers search repositories, automation scripts and build logs for credentials, then use legitimate cloud tools to copy data or disable protections.
Initial access controls
Start by reducing the value of a stolen password. Deploy phishing-resistant authentication for administrators and high-risk users. Block legacy protocols that cannot enforce modern controls. Require managed devices for sensitive applications and use conditional access carefully, with documented exclusions.
Protect enrolment and recovery. If an attacker can persuade the help desk to reset MFA, strong authentication at login loses much of its value. Recovery should use verified contact details, risk-based checks and escalation for privileged accounts. Never rely only on information available in email or public profiles.
Session security matters too. Limit long-lived sessions for privileged applications, detect token replay and revoke active sessions during containment. A password change alone may not remove an attacker who already holds a valid token.
Privilege and lateral movement
Administrators should use separate accounts for ordinary work and privileged tasks. Keep domain, cloud and backup administration distinct so one compromise does not control every recovery option. Use just-in-time access with approval and expiration instead of permanent membership in powerful groups.
Segment management services from user networks. Restrict remote desktop, PowerShell, SSH and management consoles to approved paths. Monitor new scheduled tasks, services, remote tools and changes to security agents. These controls make it harder to turn identity access into widespread execution.
Protect data before encryption begins
Many groups steal data before disrupting systems. Monitor unusual searches, archive creation, mass downloads and transfers to new destinations. Apply data classification and access reviews so one employee account cannot read every shared folder. Sensitive repositories should generate alerts when access volume or geography changes.
Egress controls need context. Blocking every large upload may interrupt legitimate work, while allowing every sanctioned cloud service creates gaps. Combine destination reputation, user role, device state, data sensitivity and volume to prioritise investigations.
Backups that survive identity compromise
Backups should use separate identities, isolated management and immutable or offline copies. An administrator of production systems should not automatically be able to delete recovery points. Protect backup configuration changes with MFA, approval and alerts.
Test restoration at the application level. Recovering files is not enough if the identity service, encryption keys or database sequence is missing. Measure recovery time and verify clean-room procedures for rebuilding systems without reintroducing attacker persistence.
Detection engineering for identity attacks
Create detections around behaviour rather than one indicator. Useful signals include impossible travel, unfamiliar device enrolment, repeated MFA prompts, new OAuth consent, mailbox rules, privilege changes, disabled logging, bulk data access and unusual use of remote administration.
Join events into a narrative. A new device followed by a mailbox rule and cloud-role assignment is more meaningful than three isolated low-severity alerts. Ensure responders can identify the user, source, affected sessions, granted applications and actions taken.
A tabletop scenario
Use a realistic exercise: finance receives a suspicious login alert, a cloud administrator sees a new consent grant, and the backup team notices an attempted retention change. Ask who owns the incident, who can revoke sessions, how legal and leadership are informed, and which systems are restored first.
The exercise should produce actions with owners and dates. Common gaps include missing after-hours contacts, uncertainty about token revocation, untested backup credentials and no process for communicating with suppliers.
Measuring readiness
Track phishing-resistant MFA coverage, standing privileged accounts, dormant identities, service-account credential age, recovery test success and time to disable an account across all applications. Measure critical findings closed after testing. These indicators show whether an identity compromise is becoming easier to contain.
Common mistakes
Do not assume an identity provider automatically protects every application. Local accounts and legacy protocols may bypass central controls. Do not exclude service accounts from reviews because they are “non-human.” Avoid leaving emergency accounts unmonitored. Finally, do not test only prevention; containment and restoration determine the real business impact.
Detox’s penetration testing and cyber security services can support identity, web, API and infrastructure assessments. Link this article to the existing common cyber threats guide where available.
Priority actions for the next 30 days
Close authentication gaps
Find privileged and remote-access applications that still permit password-only or legacy authentication. Move the highest-impact accounts first and document every temporary exception.
Reduce permanent privilege
Replace standing administrative access with approved, time-limited elevation. Review nested groups and inherited cloud roles that make effective privilege greater than it appears.
Separate recovery control
Ensure production administrators cannot silently delete all backups. Alert on retention changes and test emergency access using identities protected outside the ordinary user workflow.
Hunt for persistence
Review new MFA methods, OAuth grants, forwarding rules, application secrets and service accounts. These mechanisms can survive a password reset and are frequently missed during containment.
Practise revocation
Time how long it takes to disable an identity, revoke sessions, remove tokens and block a device across critical services. Convert delays and unclear ownership into remediation tasks.
These questions are most useful when answered with evidence: configuration screenshots, access reports, log samples, recovery results and named owners. Record decisions and dates so the review becomes an improvement programme rather than a one-time discussion.
A practical investigation sequence
When a suspicious identity alert appears, preserve the timeline before making assumptions. Identify the account, authentication method, device, source network, active sessions and recently granted applications. Search for mailbox rules, new credentials, privilege changes and data access. Then contain in a coordinated order: revoke sessions, disable or restrict the identity, isolate affected devices, rotate exposed secrets and protect backups. Broad password resets without understanding persistence may disrupt users while leaving the attacker’s token or application grant active. Document every containment action and verify it across cloud and on-premises systems.
Questions for leadership
Leadership should know which services would stop if identity infrastructure were unavailable, how long clean recovery would take and who can authorise emergency actions. They should also understand legal, insurance and customer-notification contacts before an incident. These are operational decisions, not details that can be delegated entirely to security tooling.
A staged improvement roadmap
Week one
Protect the highest-impact administrators with strong MFA, review active sessions and verify backup access. Disable obvious dormant and shared accounts. The responsible team should retain configuration evidence, test results, named exceptions and a completion date. Before moving to the next stage, confirm that the control works in practice and that operational teams know how to support it.
Week two
Reduce permanent privilege, investigate service accounts and close legacy authentication paths. Add monitoring for recovery-method and OAuth changes. The responsible team should retain configuration evidence, test results, named exceptions and a completion date. Before moving to the next stage, confirm that the control works in practice and that operational teams know how to support it.
Week three
Exercise identity containment and clean restoration. Measure revocation across email, cloud, VPN, endpoints and business applications. The responsible team should retain configuration evidence, test results, named exceptions and a completion date. Before moving to the next stage, confirm that the control works in practice and that operational teams know how to support it.
Week four
Commission targeted validation, assign remediation owners and brief leadership on recovery confidence and unresolved exposure. The responsible team should retain configuration evidence, test results, named exceptions and a completion date. Before moving to the next stage, confirm that the control works in practice and that operational teams know how to support it.
A roadmap is useful because it creates order, not because every organisation must follow identical dates. Adjust sequencing for business impact, dependencies and available expertise, while keeping ownership and verification explicit.
FAQ
Use the companion 30-day ransomware readiness checklist to turn these identity controls into an assessment and recovery plan.
Is MFA enough to stop ransomware?
No. MFA reduces some account takeover, but attackers can abuse session tokens, recovery processes, OAuth grants and privileged accounts. Layered controls are essential.
Which accounts deserve priority?
Start with global administrators, backup operators, identity administrators, cloud consoles, remote-access systems and service accounts with broad permissions.
How often should access be reviewed?
Review privileged access monthly and ordinary access at least quarterly, with immediate review after role changes or incidents.
What is phishing-resistant MFA?
It uses authentication designed to prevent credentials from being replayed on a fake site, such as hardware-backed security keys or passkeys implemented with appropriate policy. Exact deployment should match the application and risk.
Why are service accounts important?
They often have broad access, long-lived credentials and limited monitoring. Inventory them, assign owners, remove interactive login where unnecessary and rotate secrets.
Should backups use the same identity system as production?
Avoid a design where compromise of one production administrator can delete every recovery copy. Use separation, independent controls and tested emergency access.
Conclusion
Identity is now a primary ransomware control plane. Strong MFA, least privilege, behavioural monitoring, protected backups and tested response make it harder for stolen credentials to become a business-wide compromise.
The practical objective is not to guarantee that credentials are never stolen. It is to ensure that one stolen identity has limited authority, produces visible signals and can be removed before the attacker reaches critical data and recovery systems.
