Account compromise (Part 1): Breaches are inevitable and early detection is crucial

Note: This is part 1 of a 3 part series on security automation for dealing with account compromise. Part 1 covers detection, part 2 looks at enrichment and case management, while part 3 tackles protection and response including prompting the user to acknowledge the incident via a side-channel.

Breaches are inevitable. The 2020 Verizon Data Breach Investigations Report (DBIR) lists “phishing” and “use of stolen credentials” as the top 2 threats that lead to breaches in their sample of 2,907 organizations. Recently we launched our free email analysis service Phish.ly to help combat phishing but today we’re going to focus on how to deal with the second biggest threat to your organization, that of “stolen credentials”. By automating your defenses your team can respond faster and are never left wondering what’s next. 

We will use the HaveIBeenPwned (HIBP)Domain Search service as a trigger to initiate our automated workflow. This will lower response times, decrease the exposure window, and strengthen your defensive capabilities. Once you’ve signed up at HIBP DomainSearch, by providing your email domain for monitoring and a notification mailbox (this is the one we will automatically check for HIBP alerts), you can try out the automation below. There are some additional verification steps with HIBP to complete but once you’re manually signed up you can switch to full autopilot!

Our security automation Story can be grouped into 3 major parts (the topic of each blog post):

1. Detect : Ingest alerts from HIBP and then check with the HIBP API

2. Enrich and Record : Enrich alerts and create cases (in your case management system)

3. Respond : Automatically respond, protect, and prompt user

For the first “Detection” phase, we will provide 2 paths to initiate the workflow. The primary one is the IMAP email Action that checks your nominated security@ mailbox (every 3 minutes) for new HIBP “DomainSearch” breach notifications. The second option makes use of a webhook and it’s intended to give you an understanding of how other platforms or processes can trigger security automations. Once the automation has been triggered we query the HIBP API for specifics.

This is done via a modular approach called “Send To Story” which allows us to abstract parts of our automation Story for a cleaner and simpler higher-level view. It also enables us to compose automation stories that are modular, reusable, and facilitate rapid development as the risk landscape evolves.

We’ve made this automation modular so we can easily add other checks over time without complicating the main flow. This also adds value when others re-use or leverage these sub-stories. Once we know there’s been a breach on our domain we identify which specific email accounts are involved before enriching further with breach details. Let’s take a look inside the first “Send To Story” called “Check with HIBP API”:

...which comprises of...

Here, we only need to pass in the email account address. Modular stories make use of the basic Webhook Action mentioned previously and then return information such as the breach results. Our triggers are simple checks to see if there are any named breaches listed for our submitted email address. We create a simple logic gate to decide what to do if a breach is indeed found. We could easily add extra checks here like querying other systems or taking alternate paths depending on the outcome of the check, but right now we’re just looking for confirmation and a list of breach names in an easy to digest format. We query the HIBP API with an HTTP Request Action and behind the scenes get a response in the body.

If the main automation is triggered by the IMAP security mailbox check then we’re pretty sure the subsequent API calls will receive some positive responses but we also allow for negative responses. This allows us to also use the automation for ad hoc queries triggered by a webhook from other systems. At the end of this first sub-Story, we return a simple status message and any breach information such as the list of breaches found which we can use for further enrichment later.

"return_breach_information": {
    "breach_found": "true",
    "email": "redacted@redacted.com",
    "breach_names": [...]
  }

When we return to the main automation Story we advance only if the sub-Story confirmed the breach and then move to Part 2 “Enrich and Record” i.e. the enrichment and case creation phase.

‍Check out Part 2 “Enrich and Record” where we enrich the alert from additional sources and automatically create cases in TheHive and Jira Service Desk to track and record our next steps! Read on...

*Please note we recently updated our terminology. Our "agents" are now known as "Actions," but some visuals might not reflect this.*