Identifying Compromised Accounts

Although the Heartbleed vulnerability allowed for credential theft on an unprecedented scale, account compromises have long been of significant concern to security operations. Even though an organization may not have directly implemented systems vulnerable to Heartbleed, users sharing account names and passwords across applications could easily have had their credentials stolen from a separate, vulnerable site.

To detect a malicious actor using stolen credentials to log in to your organization’s network or web applications, LogRhythm includes a set of purpose-built Advanced Intelligence Engine rules. Because the LogRhythm Labs team is in the process of renaming and reorganizing AIE Rules, the rule id, which will not change, will be included with the current rule name in order to keep this post relevant.


The most basic form of catching a malicious login is to blacklist or whitelist certain source locations for remote log ins. Three rules, Susp:Inbound:Connection With Blacklisted Country (464), Susp:Inbound Connection With Non-Whitelisted Country (467), and Ext:Acnt Comp:Remote Auth From Unauthorized Location (6) are very easily to implement, yet are very effective at detecting compromised accounts.

Obviously, these rules will not trigger when the malicious actor happens to be outside of a blacklisted area or within a white list one, but it certainly narrows down possible breach points. The second group of rules detect authentications for the same account across disparate geographic areas. For example, a user typically shouldn’t be logged in from both Denver and London at the same time.

The rules, Ext:Acnt Comp:Concurrent Auth From Multiple Cities (39), Ext:Acnt Comp:Concurrent Auth From Multiple Regions (4), and Ext:Acnt Comp:Concurrent Auth From Multiple Countries (5), will detect malicious actors logging into accounts already in use. Finally, attackers that have stolen credentials that include the organization’s domain may attempt authentication, even if the user wisely uses a different password.

In this case, many authentication failures should be observed. If rules such as Ext:Acnt Atck:Account Scan On Single Host (8) and Ext:Acnt Atck:Brute Force From A Single Origin Host (2) are triggered, the organization can identify users who have a compromised external account. And if the authentications failures are followed with a successful login, rules such as Ext:Acnt Comp:Account Scan On Single Host (7) and Ext:Acnt Comp:Brute Force From A Single Origin Host (1) will identify account compromises.

To reiterate, large account breaches, even if not experienced directly by an organization, can still easily lead to security breaches. Monitoring accounts can allow for much easier mitigation and remediation in the event of an account compromise and should be considered standard practice for even smaller-scaled security operations.