When a Password Is Not Enough: Understanding Identity-Based Attacks

In cybersecurity, we often focus on protecting devices, detecting malware, and preventing suspicious files from executing. But there is another area that deserves just as much attention: identity security.

An attacker does not always need to install malware on a device to gain access to an organisation's information. Sometimes, all they need is access to a legitimate user account.

Think about how much information an employee can access through a single Microsoft 365 account. Depending on their permissions, that account could provide access to emails, documents, Teams conversations, SharePoint sites, and other business applications.

If an attacker compromises that identity, they may be able to operate using legitimate access rather than immediately triggering the types of alerts associated with traditional malware.

This is what makes identity-based attacks particularly challenging. The activity may initially resemble normal user behaviour.

In this article, I will explain how identity-based attacks work, why passwords and multifactor authentication are not always enough, and how organisations can strengthen identity security using practical controls.

1. What Are Identity-Based Attacks?

Identity-based attacks target user accounts, authentication mechanisms, credentials, or active sessions to gain unauthorised access to systems and data.

Rather than exploiting only a vulnerability in a device or application, attackers may target the identity that grants access to those resources.

Common examples include:

• Credential theft: Stealing usernames and passwords through phishing, malicious software, or compromised websites.

• Password spraying: Trying a small number of common passwords against many accounts to avoid triggering some account-specific detection thresholds.

• Brute-force attacks: Attempting numerous password combinations against an account.

• MFA fatigue: Bombarding a user with authentication requests in the hope that they approve one.

• Session token theft: Obtaining a token that can be used to access a service as an authenticated user, potentially bypassing the need to enter a password again.

• Consent phishing: Tricking a user into granting a malicious application permissions to access organisational data.

These attacks are different, but they share a common objective: obtaining access through an identity or its associated authentication mechanisms.

For organisations using Microsoft 365, identity security is particularly important because user accounts often serve as the entry point to multiple connected services.

2. Why a Strong Password Is Not Always Enough

Strong passwords remain important. However, they cannot protect an account if an attacker obtains the password and successfully uses it.

Consider this scenario.

An employee receives an email that appears to come from their organisation's IT department. The message claims that their Microsoft 365 account needs to be verified urgently.

The employee clicks the link and enters their credentials on a fraudulent page.

The attacker now has the employee's username and password.

Depending on the organisation's authentication controls, the attacker may attempt to sign in, obtain additional authentication, or use the stolen credentials as part of a wider attack.

The problem is not necessarily that the employee chose a weak password. The problem is that the authentication information has been exposed.

This is why identity security needs multiple layers of protection.

Organisations should combine strong authentication, appropriate access controls, monitoring, and a tested response process rather than relying on password complexity alone.

3. Multifactor Authentication Helps, but It Is Not a Complete Solution

Multifactor authentication (MFA) requires users to provide additional evidence of their identity beyond a password.

Depending on the implementation, this may involve an authenticator application, a security key, or another supported authentication method.

MFA can significantly reduce the risk associated with stolen passwords. However, not all authentication methods offer the same level of protection, and MFA does not eliminate every identity-based attack.

For example, an attacker may attempt to:

• Trick a user into approving an unexpected authentication request.

• Use a phishing page designed to capture authentication information in real time.

• Steal an authenticated session token.

• Exploit an account or application that is not protected by the expected authentication controls.

This does not mean MFA is ineffective. It means organisations must implement it thoughtfully and understand its limitations.

What can organisations do?

Where supported by their environment, organisations should consider:

• Using phishing-resistant authentication methods, such as FIDO2 security keys or supported passkeys.

• Enforcing MFA consistently across users and applications.

• Implementing Conditional Access policies to control how users access organisational resources.

• Blocking legacy authentication protocols where they are not required and can be safely disabled.

• Educating employees not to approve unexpected authentication requests.

• Reviewing authentication logs for suspicious patterns.

The objective is to make unauthorised access more difficult, even when an attacker obtains a user's password.

4. How Microsoft Entra ID Helps Protect Identities

Microsoft Entra ID provides identity and access management capabilities for Microsoft cloud services and connected applications.

For security teams, it offers several controls that can help reduce identity-related risk.

Conditional Access

Conditional Access allows organisations to apply access policies based on signals such as the user, application, device, location, and authentication context, depending on the available capabilities and configuration.

For example, an organisation might require multifactor authentication when employees access Microsoft 365 resources.

It might also require a compliant device for access to particular applications or block access from locations that are not permitted by organisational policy.

The important point is that access decisions can be based on more than a correct username and password.

However, policies need to be designed carefully. Exceptions, exclusions, unsupported applications, and incomplete coverage can create gaps in protection.

Security teams should regularly review policy effectiveness and test changes before applying them broadly.

Identity Protection

Microsoft Entra ID Protection can help organisations identify and investigate identity-related risks, including certain risky users and sign-ins.

Where the relevant licensing and capabilities are available, risk signals can help security teams prioritise investigations and configure risk-based policies.

For example, a sign-in flagged as risky may require additional verification, trigger a remediation workflow, or lead to further investigation.

A risk signal should not automatically be treated as proof of compromise. Analysts still need to evaluate the available evidence and the context surrounding the activity.

Privileged Identity Management

Privileged Identity Management (PIM) helps organisations manage access to privileged roles.

Rather than leaving every administrator with permanent access to powerful roles, eligible users can activate certain permissions when required, subject to the organisation's configuration and approval requirements.

This supports the principle of least privilege: users should have only the access they need to perform their responsibilities.

Reducing unnecessary permanent privileges can limit the potential impact if an administrator's account is compromised.

5. How to Investigate a Potentially Compromised Account

Preventive controls are important, but security teams also need to recognise and respond to suspicious identity activity.

Imagine that Microsoft Entra ID records a successful sign-in for an employee from an unfamiliar location. Around the same time, the employee reports receiving unexpected MFA prompts.

Neither detail alone proves that the account has been compromised. Together, however, they justify a closer investigation.

A practical investigation could follow these steps.

Step 1: Review the sign-in details

Examine the available sign-in logs and review:

• The account involved.

• The date and time of the sign-in.

• The source IP address and approximate location.

• The application being accessed.

• The device and browser information, where available.

• The authentication method and MFA result.

• Any recorded Conditional Access results.

• Available risk indicators and related events.

An unfamiliar location does not automatically indicate an attack. Employees travel, use VPNs, and connect through networks that may be associated with unexpected locations.

The analyst should look for a combination of indicators rather than making a decision based on geography alone.

Step 2: Establish whether the activity is expected

Where appropriate, contact the user through a trusted communication channel to confirm whether they recognise the activity.

Ask whether they were signing in at the time, whether they approved an unexpected authentication request, or whether they recently clicked a suspicious link.

A user's confirmation is useful context, but it should be considered alongside the technical evidence.

An attacker may also have access to the user's email account, so avoid relying on a potentially compromised channel to verify the incident.

Step 3: Look for additional suspicious activity

Review related events to determine whether the sign-in was followed by other unusual behaviour.

Depending on the environment, this may include:

• Unexpected mailbox forwarding rules.

• Unusual access to emails or files.

• Suspicious application consent grants.

• Changes to authentication methods.

• Unusual privilege assignments.

• Additional sign-ins or activity involving the same account.

For Microsoft 365 environments, reviewing relevant audit records and Microsoft Defender alerts can help establish whether the activity extended beyond authentication.

The aim is to understand what the account accessed and whether the attacker made changes that could allow continued access.

Step 4: Contain the compromise

If the evidence indicates that an account has been compromised, the response should follow the organisation's incident response procedures.

Depending on the circumstances, actions may include:

• Resetting the user's password.

• Revoking active sessions and refresh tokens where supported.

• Blocking sign-in temporarily while the incident is investigated.

• Removing unauthorised authentication methods.

• Investigating and removing malicious mailbox rules.

• Reviewing application permissions and privileged access.

• Checking for other compromised accounts.

These actions address different aspects of an incident. A password reset alone may not be sufficient if an attacker has established persistence through application permissions, mailbox rules, or other mechanisms.

Security teams should verify that containment actions have succeeded and investigate the original access method before closing the incident.

6. Why Monitoring Matters

Identity security does not end after Conditional Access and MFA have been configured.

Security teams need visibility into authentication activity and changes to identities, permissions, and applications.

Monitoring can help identify patterns such as repeated failed sign-ins, unusual authentication behaviour, unexpected privilege changes, or suspicious access to organisational resources.

Microsoft Entra sign-in and audit logs provide useful sources of identity-related evidence. Depending on the environment, these records can also be integrated with Microsoft Sentinel or other security monitoring platforms for correlation and alerting.

For example, repeated failed sign-ins followed by a successful sign-in and an unexpected mailbox rule change may warrant investigation as a related sequence of events.

Individually, some of these events might have legitimate explanations. When viewed together, they may reveal a more concerning pattern.

This is why effective monitoring should focus not only on isolated alerts but also on the relationships between events.

Organisations should also ensure that relevant logs are available for an appropriate retention period and that alerts are routed to people who can investigate and respond to them.

7. Common Identity Security Mistakes to Avoid

Even organisations with modern security tools can leave gaps in their identity protection.

Here are several areas worth reviewing.

Assuming MFA eliminates identity risk. MFA reduces risk, but phishing, session theft, and other attacks can still succeed under certain conditions.

Leaving unnecessary administrator privileges in place. Excessive permissions increase the potential impact of a compromised account.

Ignoring unexpected authentication requests. Repeated or unexplained prompts may indicate that someone is attempting to access an account.

Creating Conditional Access policies without reviewing exclusions. Exceptions may be necessary, but they should be justified, documented, and monitored.

Resetting passwords without investigating the wider incident. Attackers may have created alternative ways to access data or maintain persistence.

Treating every unusual sign-in as a confirmed compromise. Security teams need to assess context, corroborate evidence, and distinguish suspicious activity from legitimate behaviour.

Failing to test incident response procedures. Teams should know who is responsible for containment, escalation, recovery, and communication before an incident occurs.

The goal is not to eliminate every exception or flag every unusual event. It is to build controls and processes that reduce risk while allowing legitimate business activity to continue.

Final Thoughts

Identity security is a critical part of protecting modern organisations because access to business information increasingly depends on user accounts, authentication methods, and connected applications.

A strong password is important. Multifactor authentication is important. But neither should be treated as a complete identity security strategy on its own.

Organisations need layered protection that combines appropriate authentication, Conditional Access, least privilege, monitoring, and a well-defined incident response process.

For security analysts, the responsibility extends beyond identifying a suspicious sign-in. It involves understanding the context, investigating the activity, determining the potential impact, and ensuring that appropriate corrective actions are taken.

The question is no longer simply whether a user has the correct password. It is whether the access is legitimate, appropriately authorised, and consistent with the organisation's security requirements.

That is the foundation of a stronger identity security strategy.