No matter what risk framework or security standards you hold most dear, I know for sure that you consider users sharing accounts to be a violation of the common sense that is the necessary foundation of any security awareness training.
When the UserInsight team set out to identify evasive attacker behaviors like "account impersonation" and "local credential testing" (that I covered in a blog you can read here), one of the most important steps was identifying which accounts were logged in when an authentication to a second account took place. Now, that was far too complex for me to figure out, but that is why the Rapid7 UserInsight development team exists. Our focus was identifying the "linked accounts" for the concerning activities I mentioned above, but the more frightening behavior that UserInsight was immediately able to identify was account sharing, i.e. multiple source accounts authenticating to the same secondary account. I want to use this space to cover a couple real-world causes of this highly frowned-upon behavior, each of which I heard directly from a UserInsight customer once our solution exposed the issue.
We shared because...
"... following the process was slow." When I talk through "WTF?" sharing moments with our customers, this reason is most commonly at the root. Every team in your organization is trying to be productive (unless they are in it for the pension) and there are times when one person needs to urgently access a system or file to which they have no privileges. In order to get the task done immediately, a teammate writes down a password on a sticky note and accompanies it with a head nod that says "don't tell anyone".
"... I was too busy to make the change." This explanation often comes when a helpdesk administrator or someone else who knows better shares an account. Security always suffers when someone with privileged access cannot be bothered to follow the policies and process that security, IT, and management all agreed were important.
"... we couldn't think of a better solution." This one is least common today, but I still hear occasional stories of a support team sharing an account to access tickets from home after hours or a third-party consultant brought in to help with a project and not wanting to reveal when he needs help from a colleague.
No matter the reason that the account was shared, every security professional is pained by trying to identify them. While I want to, once again, stress that our focus with UserInsight is detecting malicious actions, our customer base has successfully discovered a great deal of account misuse and policy violations because (let's be realistic) users unintentionally introduce risk into your organization a lot more often. The analysis we offer has exposed shared credentials in a few ways (and there may be more that have been kept secret because of embarrassment or other security reasons):
- An account belonging to a consultant was seen both (a) on a mobile device in Chicago [where he worked] and (b) on the VPN in Atlanta [where his co-worker lived] roughly fifteen minutes apart
- ALERT: Inbound authentication with service accounts - one customer had a team sharing credentials without an expiring password, so that they could guarantee consistent customer interaction from the same account
- More than one user account impersonating the same account with local administrator privileges (a.k.a. an attacker's dream scenario) - this was simply found by clicking the "Shared Accounts" link on the home screen panel [depicted to the left here] and reading a list [as depicted to the right here]
We are always looking to expose these kinds of security issues when we analyze and present data to our customers, so that our customers can speak directly to the responsible members of their organizations and educate them on the appropriate use of credentials, in whatever manner deemed appropriate in your organization.
If you want to get the same view into shared accounts as the security teams in the examples here, please give us a call or fill in our Contact Us form.