Detecting credential theft and misuse patterns for UK SMEs

Credential theft is often less about a dramatic break-in and more about an attacker using valid access in ways that do not fit normal behaviour. For UK SMEs, that matters because identity systems, email, and cloud services are usually the fastest route to business impact. If an attacker can sign in as a user, they may not need to deploy malware, exploit a vulnerability, or trigger obvious perimeter alerts.

That is why detecting credential theft and misuse patterns needs a dedicated approach. The goal is not to chase every unusual sign-in. It is to identify combinations of identity, endpoint, and cloud activity that suggest a real compromise, then respond quickly enough to limit spread.

This article focuses on practical detection engineering for small and mid-sized teams. It assumes you have some combination of Entra ID, Microsoft 365, Windows event logs, Sysmon, and endpoint detection tooling feeding a SIEM or XDR platform. The same principles apply if your stack is different, but the exact event names and query syntax will vary.

Why credential theft detection needs a dedicated approach

How credential theft differs from generic account compromise

Not every suspicious login is credential theft. A user may travel, change device, or trigger a conditional access prompt. Credential theft becomes more likely when access is paired with indicators such as token abuse, mailbox rule changes, unusual privilege use, or endpoint activity that suggests credential access.

In practice, the difference is important because the response path changes. If a user simply forgot a password, you may reset credentials and move on. If an attacker has stolen a refresh token, session cookie, or password and is actively using the account, you need to revoke sessions, review persistence, and check for lateral movement.

For SMEs, the challenge is that the same person or team often owns identity administration, endpoint management, and incident response. That means detections need to be high signal, easy to triage, and linked to a clear playbook.

Where SMEs usually have the biggest visibility gaps

The most common gaps are predictable:

• No central view of sign-in events, mailbox activity, and endpoint telemetry.
• Short log retention, which makes it hard to reconstruct the sequence of events.
• Limited device telemetry, especially on unmanaged or bring-your-own-device endpoints.
• Alerts that fire on single events rather than correlated behaviour.
• Weak coverage for cloud-native abuse, such as consent grants, inbox rules, and OAuth application misuse.

If you only monitor failed logons, you will miss the more subtle cases where the attacker already has valid credentials. If you only monitor endpoint malware, you may miss a compromised account used entirely through the browser. Good detection coverage needs both.

Threat patterns to watch for across identity, endpoint, and cloud logs

Impossible travel, unfamiliar sign-ins, and token abuse indicators

Identity telemetry is usually the first place to look. In Entra ID sign-in logs, useful patterns include:

• Impossible travel, where the same account appears to sign in from geographically distant locations in a short period.
• Unfamiliar sign-in properties, such as a new browser, device, user agent, or IP reputation change.
• Repeated MFA prompts followed by a successful sign-in, which can indicate prompt fatigue or social engineering.
• Sign-ins from anonymising infrastructure, hosting providers, or regions that do not match the user profile.
• Token-related anomalies, such as access without a matching interactive sign-in pattern.

Impossible travel alone is not enough. A user on a VPN, mobile network, or remote desktop can produce similar noise. The value comes from combining it with device posture, time of day, and subsequent actions. For example, a successful sign-in from a new location followed by mailbox forwarding creation or role assignment is much more concerning than the login event itself.

Privilege escalation, consent abuse, and mailbox rule changes

Once an attacker has access, they often try to make that access durable or more powerful. Watch for:

• Role assignment changes in Entra ID, especially where the user is not expected to administer identity or email.
• Consent to OAuth applications, particularly if the application requests broad mail, profile, or offline access permissions.
• Mailbox rule creation or modification that forwards, deletes, or hides messages.
• Inbox rules that move security alerts, finance emails, or password reset messages into obscure folders.
• New forwarding addresses or transport rules that send mail outside the organisation.

These events are useful because they often show intent. An attacker who wants to stay hidden will try to suppress alerts and capture password resets. A small team should treat these changes as high priority, especially if they occur shortly after a suspicious sign-in.

Suspicious process creation, LSASS access, and credential dumping signals

Endpoint telemetry helps distinguish a stolen password from a broader compromise. On Windows, useful signals include:

• Unexpected access to LSASS, the Local Security Authority Subsystem Service, which stores credentials and authentication material in memory.
• Process creation events that launch known administrative tools in unusual contexts.
• Suspicious PowerShell usage, especially encoded commands, hidden windows, or download-and-execute behaviour.
• Creation of new local accounts or changes to local administrators group membership.
• Use of remote management tools outside normal support windows.

Sysmon can add valuable detail here, especially process creation, image load, network connection, and process access events. Windows Security logs remain important too, particularly for logon events, account changes, and privilege use. The point is not to collect everything. It is to collect enough to connect identity activity with endpoint behaviour.

Building a practical detection baseline

Minimum telemetry from Entra ID, Microsoft 365, Windows, and endpoint tooling

A workable baseline for an SME should include at least the following:

• Entra ID sign-in logs and audit logs.
• Microsoft 365 unified audit log, including mailbox, SharePoint, and admin actions where licensed and available.
• Windows Security event logs from servers and workstations.
• Sysmon on key endpoints and servers, with a consistent configuration.
• Endpoint detection and response telemetry, if available.

For Entra ID, focus on interactive sign-ins, non-interactive sign-ins, risky sign-ins if your licensing supports them, and audit events for role changes, application consent, and conditional access modifications. For Microsoft 365, prioritise mailbox rule changes, forwarding, delegated access, and admin actions. For Windows, ensure you are capturing logon success and failure, special privileges assigned, account management, and service creation.

If you are using Sysmon, keep the configuration manageable. A common mistake is to deploy an over-tuned configuration that generates too much data and then gets ignored. Start with process creation, network connections, image loads for sensitive processes, and process access events for credential-related targets. Then refine based on what your environment actually uses.

Normalising identity, device, and authentication events for correlation

Correlation is where detection quality improves. A sign-in event on its own is weak. A sign-in event linked to a new device, a new IP range, a mailbox rule change, and a suspicious PowerShell process is much stronger.

To make that work, normalise your data around a few common fields:

• User principal name or account name.
• Device identifier or hostname.
• Source IP and geolocation.
• Timestamp in a single time zone.
• Authentication method and result.
• Process name, parent process, and command line.

In a SIEM, this usually means mapping fields from different sources into a common schema. If you are using Microsoft Sentinel, the KQL tables may already be close enough for practical correlation. If you are using another SIEM, you may need to build enrichment rules or a normalisation layer first.

Using risk scoring and alert prioritisation to reduce noise

Small teams rarely have the capacity to investigate every anomaly. A simple risk scoring model can help. For example:

• Low risk: single unusual sign-in with no follow-on activity.
• Medium risk: unusual sign-in plus MFA prompt spikes or new device registration.
• High risk: unusual sign-in plus mailbox rule change, consent grant, or privilege change.
• Critical risk: unusual sign-in plus endpoint credential access indicators or confirmed persistence.

Use this scoring to drive queue order, not to replace judgement. The aim is to reduce alert fatigue while keeping the most dangerous combinations visible.

Detection logic and correlation ideas for technical teams

High-signal rules for failed logons, success-after-failure, and new device enrolment

Some of the most useful detections are still fairly simple. Good starting points include:

• Multiple failed logons followed by a successful logon from the same source or account within a short window.
• Successful sign-in after a series of MFA failures or denied prompts.
• New device enrolment followed by privileged activity or mailbox access.
• First-time sign-in from a device combined with access to sensitive applications.

These patterns are not proof of compromise, but they are strong triage candidates. A legitimate user may mistype a password several times. An attacker, however, often probes until a credential works and then moves quickly to persistence or data access.

In KQL, a simple pattern might join sign-in events to later mailbox or role events within a time window. In Sigma, you can express the same logic as a sequence or correlation rule, then adapt it to your SIEM backend. The important part is to keep the rule understandable. If the logic becomes too complex to explain, it becomes harder to tune and maintain.

Correlating identity events with endpoint activity and email forwarding changes

One of the strongest indicators of credential misuse is a cross-domain sequence. For example:

1. A sign-in from a new location or device.
2. A mailbox rule is created to forward or hide messages.
3. A PowerShell process runs on the same user endpoint, or a remote management tool is invoked.
4. A privileged action occurs, such as adding a new admin or consenting to an application.

That sequence is far more meaningful than any single event. It suggests the attacker is not just testing access, but actively establishing control and reducing the chance of detection.

You can also correlate identity events with network telemetry. A user account that suddenly authenticates to many internal services, or a workstation that starts making unusual outbound connections immediately after a suspicious sign-in, deserves closer attention.

Using Sigma, KQL, or SIEM-native queries to express detections

For technical teams, the choice of query language is less important than consistency. Sigma is useful for portable detection logic and for documenting intent. KQL is practical when you are working in Microsoft Sentinel or Defender environments. SIEM-native query languages can be fine if they are well supported by your team.

A good detection rule should include:

• Clear purpose and mapped technique.
• Required data sources.
• Time window and thresholds.
• Expected false positives.
• Triage guidance.

For example, a Sigma rule for suspicious mailbox forwarding should not just look for any forwarding change. It should specify the event source, the action type, and perhaps a condition such as a newly created rule that forwards outside the organisation or deletes messages after forwarding. That keeps the rule focused on misuse rather than normal mailbox administration.

Response actions that preserve evidence and limit spread

Account containment, session revocation, and credential reset sequencing

When you suspect credential theft, sequence matters. A sensible order is usually:

1. Confirm the alert is not a known administrative or support activity.
2. Revoke active sessions and refresh tokens where your identity platform supports it.
3. Reset the password or disable the account if the risk is high.
4. Review MFA methods and remove suspicious registrations.
5. Check for delegated access, forwarding, and application consent.

Do not rely on password reset alone. If the attacker has a valid session token, they may continue to operate even after the password changes. Session revocation and token invalidation are often the more important containment steps.

When to isolate endpoints and review persistence mechanisms

If the account misuse is linked to endpoint activity, isolate the device before the attacker can move laterally or wipe evidence. Review scheduled tasks, services, startup items, browser sessions, remote access tools, and local admin changes. If Sysmon or EDR shows credential access behaviour, treat the endpoint as potentially contaminated.

For SMEs, the main trade-off is operational disruption. Isolation can affect the user and their work, but it may be the fastest way to stop further misuse. If the device is a shared or privileged workstation, the threshold for isolation should be lower.

Logging, retention, and handover considerations for investigation

Keep the evidence chain simple. Preserve the relevant logs, note the timestamps, and record the actions taken. If you have a managed service provider or external responder, hand over:

• Timeline of suspicious events.
• Relevant user and device identifiers.
• Actions already taken, such as session revocation or password reset.
• Any business-critical systems affected.

Retention matters because credential theft investigations often depend on reconstructing several days of activity. If your logs roll over too quickly, you may lose the sequence that shows how the compromise progressed.

Operationalising detections in a small security team

Tuning false positives and exception handling

False positives are unavoidable, but they should be understood. Common sources include travel, VPN use, service accounts, helpdesk activity, and automated application sign-ins. Build an exception process that is documented, time-limited, and reviewed regularly. Permanent exceptions should be rare.

When tuning, ask three questions:

• What benign activity is causing the alert?
• What additional condition would make the rule more precise?
• Would that condition reduce coverage for a real attack path?

This keeps the detection useful without making it so narrow that it misses genuine misuse.

Mapping detections to MITRE ATT&CK techniques

Mapping detections to MITRE ATT&CK helps you see coverage gaps. For credential theft and misuse patterns, relevant techniques often include valid accounts, credential dumping, account manipulation, phishing-related access, and persistence through mailbox or token abuse. You do not need to map every alert exhaustively, but a basic coverage view helps prioritise where to invest next.

For a small team, the practical benefit is clarity. If you can see that you detect sign-in anomalies but not mailbox persistence, or endpoint credential access but not OAuth consent abuse, you can focus on the highest-risk gap first.

Review cadence, metrics, and continuous improvement

Detection engineering is not a one-off project. Review your rules on a regular cadence and track a few simple metrics:

• Number of true positives versus false positives.
• Mean time to triage for high-priority alerts.
• Percentage of alerts with a documented response.
• Coverage of key identity and endpoint telemetry sources.

Use incidents and near misses to improve the detections. If a real misuse case was only found because a user reported strange behaviour, ask what telemetry should have caught it earlier. If a rule generated noise, refine the threshold or add context rather than disabling it outright.

For UK SMEs, the practical objective is not perfect detection. It is enough visibility to spot misuse early, contain it quickly, and learn from each event. That approach is usually more sustainable than trying to build a large enterprise SOC model on a small team budget.

Frequently asked questions

What log sources are most useful for spotting credential theft early? The most useful sources are Entra ID sign-in and audit logs, Microsoft 365 audit data, Windows Security logs, Sysmon on key endpoints, and endpoint detection telemetry. The strongest detections usually come from correlating identity events with mailbox changes and endpoint activity.

How can a small team reduce false positives without missing real misuse? Start with high-signal combinations rather than single events, add context such as device, location, and time, and document known benign exceptions. Review alerts regularly and tune based on actual investigations, not just volume.

If you want help turning these ideas into a workable detection baseline, or aligning them with a broader ISMS and operational control set, speak to a consultant.