Spotting an Account Compromise
In this article, we walk through a scenario where a Microsoft account triggers a risky sign-in alert and break down the key indicators you should look for when validating whether the activity is malicious.
What is a compromised account?
A compromised account has been accessed by malicious actors with the intention of exfiltrating data, elevating privileges, or causing damage to reputation or finances. There are many ways to access an account, some of which include but are not limited to:
- Phishing Links/Emails
- Brute Force of Weak Passwords
- Data Breaches
- Credential Stuffing
- Data-scraping Malware, such as keyloggers.
- Session Hijacking
How can you prevent account compromise?
- Conditional access policies that restrict login access to specific countries reduce the attack surface area. It is important to note that sometimes the use of VPNs raises false positive alerts, especially on personal devices.
- Multi-factor Authentication (MFA) is a good prevention tactic, as a user will be prompted for MFA verification even if they entered the correct password. This is helpful in cases where there has been a credential leak, as the user will be prompted about a login attempt and can report/remediate their account.
- Implement strong password policies across the company, following guidelines like NIST.
- Being cautious when opening links or attachments on emails, installing safe email practices throughout the company. Also, having good spam filtering protection that blocks and removes a lot of malicious emails before they are delivered to a user.
How to spot an account compromise?
Image 1 shows a risky detection alert for a user who is trying to log in from ‘Montreal, Quebec, CA’. You might notice that the alert has low levels of detail, e.g., the detection type being ‘Risk detected’. This is due to varying Microsoft licenses. For more detail on license levels see this Microsoft blog.
From here, you should investigate two avenues:
- Analyse logins from the last 24 hours
- Cross-reference findings with the user
Now you are probably asking what the key artifacts are that we look for when trying to validate a true positive?
First, we would need to navigate to the Entra portal, filter by the affected user, and click into their logs. For each login, you would want to look at these artefacts:
| Artefact | What to Identify? |
| Basic info > Authentication requirements, Status, Additional details | Look at whether the authentication methods were successful. An unsuccessful authentication can imply malicious activity, depending on the reasoning and frequency. A human is likely to enter their password wrong a few times, but is unlikely to enter their password in 20 times incorrectly. Here is a good example: Authentication requirements : ‘Single-factor authentication’ Status: ‘Success’ Additional details: ‘MFA requirement satisfied by claim in the token’ |
| Location | Looking into the location section of a login, we can gather where they have logged in from to spot any unusual patterns. Let’s say a user always logs in from the UK, and then suddenly there is a login log from Quebec, CA that should flag as weird behaviour. If conditional access policies have been set up, then we can also look at the ‘Named location type’ and whether it’s in an allowed countries/IP list. |
| Location > IP address | Here we can look at the IP address that attempted to log in, use threat intel platforms to determine if it is malicious, a VPN identified IP, or a TOR exit node IP. For our case example, the IP 51.79.54.101 is 1 on VirusTotal and has been flagged as positive on VPN checker platforms. |
| Authentication Details | Looking at this tab, you are able to determine what method the user has chosen to log in by and whether it was successful. If it says they used a password, but it failed because of an invalid username or password, then you might be able to infer whether there has been a password leak, or an MFA token compromise. |
| Basic info > Application | With this value, you can determine what a user was trying to log in and access, giving you some context to follow up with the user. This could be ‘Office 365 Exchange Online’, ‘SharePoint Online Web Client Extensibility’, or any other applications that a company manages. |
| Basic info > User agent | This value helps determine the context of what type of device was used to log in, an example being ‘Mozilla/5.0 (Macintosh; Intel Mac OS)’. This gives you data for you to confirm with the user. |
| Time & Frequency Trends | Looking at the time between login requests and the frequency of those login requests can give you valuable data to make assumptions about. Here are some examples: 1. A human is unlikely to send login requests with the incorrect password at a high frequency in a short time window. This can imply bot/script behaviour. 2. A user trying to log in and failing the first two times and then being successful suggests human behaviour. 3. Logins at consistent intervals can also suggest bot behaviour. 4. Is it within usual business hours? However, this shouldn’t be the only variable you factor into your analysis. In our example, we can see that the risky detection was at 10:35am, which is normal business hours in that context. |
It is also good to cross-reference with the user before taking remediation actions (depending on the severity of the context). Following them up with questions like:
- Are they abroad right now but still working, maybe a conference or confirmed allowance to work from abroad?
- Did they log in from that device around the time?
- Was there a VPN active on that device?
- Have they clicked on any suspicious links, email attachments, or entered their credentials in any suspicious portals recently?
- Inform them of any remediation actions you have taken and any follow-up measures they would need to do.
For the example investigation, we have gone through and examined the alert for the user attempting to log in from Montreal, Quebec, CA — not the user’s usual login location. By querying the logs and analysing key artefacts, we can then determine the legitimacy of the activity. The login occurred during normal business hours, and the authentication method succeeded. Although the IP was flagged as a VPN, there was no evidence of rapid failed attempts or suspicious devices, suggesting this alert may be a false positive.
We reached out to the user, and they confirmed they were using a VPN at that time, set to Canada. Combining these insights allows security teams to make a data-driven decision and mark this alert as a false positive.
How to remediate an account?
- Reset their password
- Revoke sessions
- Enable MFA
- Remove compromised MFA devices
- Block malicious IoCs – this can include IPs, domains, or countries on firewalls.
These things can be done both manually (from an account with admin privileges) or can be done automatically via scripts. For help with investigating these alerts with a SOC team refer to Swarm-SecOps.
-
I just wanted to take a moment to personally thank IP Performance for all your help and guidance during our recent upgrade project. Upgrading all three of our production clusters was a huge undertaking, especially with the amount of traffic they serve and thousands of services they deliver. Achieving this with zero downtime was no small feat and your expertise and quick responses were absolutely crucial in making it happen. It really felt like you were part of our team throughout this process and were more than just providing support but indeed kind of taking ownership of all the challenges and issues we had during this migration which we couldn’t have done as smoothly without your support.
Khalid Kamal,
European Bioinformatics Institute
