This article explores cyber investigations through leveraging the Security Stack. It sheds light on the role of password reset logs in swift breach detection and mitigation.
Over the last several years, one of the most prolific and common initial entries hackers use for breaking into companies, is through compromised employee credentials. Given how frequent data breaches are reported in the news, a few common pieces of data are typically included, which are usernames, passwords, email addresses and in some cases, places of employment.
Hackers love this as it provides them a large pool of corporate emails to try and leverage in order to gain access to their targets. Common techniques are password spray attacks, brute force attempts as well as standard password resets if the user and target company do not have multi-factor authentication enabled. When investigating data breaches involving user accounts, one potential rich data source could be the password reset logs from active directory or azure active directory as an example.
As any seasoned incident responder knows, the key to successful and timely investigations is ensuring that the right data is available and that the systems are properly logging important information, and ideally, forwarding to a central location such as a SIEM (security information event manager). Working with the identity and access team, a proper threshold can be arranged and set up for what should trigger suspicious account activity, whether it is 3 failed login attempts, brute force attempts, or impossible travel events where a user account appears to be logged in from the United States and Russia, for example.
A very popular method for attackers to hijack legitimate user accounts at organizations is to check and see if the target organization has multi-factor authentication in place which would make the take over attempt more challenging. Any password reset request should typically be accompanied with a notification that their account information has been changed and that their MFA tool will no longer work until the password has been updated. Another aspect is that if a threat actor successfully determined a target organization or user did not have multi-factor authentication in place and the organization had a self-service password reset tool that was public facing, the attacker could easily reset the employee password and potentially enroll themselves in multi-factor authentication, emulating their activity as the users’.
When reviewing password reset logs in an active directory, there are several fields of interest that can help guide the beginning of an investigation. When the incident response team is notified of a potential breach or situation, the first place they should look is the active directory and the logs associated with the user account or accounts, if they have multiple. Key fields to review are the date and time when the account was last modified, the location such as IP or other geographic information such as coordinates where the activity was detected, and reviewing if the user made any changes to their multi-factor authentication enrollment process. Other areas to investigate include the history of how the user typically accessed their account, and if there is a different operating system, mobile device or browser than what is normally expected.
Once the initial triage has been completed, which should be within minutes or less than an hour, the next timely step is to contact the user via pre-established mediums to confirm whether they recognize the activity. If they do not or are unsure, the prudent step would be for the security team to engage the identity and access management team to lock down the user account, remove the multi-factor method, and have the user change their password immediately, as well as work with the user directly to properly register their own device to mitigate future attempts by the threat actor.
In short, these incidents are usually easily remediated in under an hour and if detected early, will result in low dwell time for the threat actor, thereby mitigating potential damage. If the situation took time to resolve, it would be prudent to do a deeper dive and review user account activity for any new permissions assigned since the password change, as well as any other potential sites, services or locations accessed that are normally out of scope for the user. This wraps up this section on reviewing password reset logs as part of the incident response process.