How Auth0 Automates Phishing Response

Phishing continues to be a popular attack vector used by attackers with all sorts of motivations — from political to financial ones. According to Verizon’s 2019 Data Breach Investigations Report, 32% of the investigated breaches involved phishing. Most organizations deal with this threat on an almost daily basis, which makes automating the triage for these events an important part of maturing a security program.

In this post we talk about the approach Auth0 has taken to automating phishing in the hopes that it will help other organizations tackle this near-universal threat vector.

phishing@auth0.com

Auth0 uses the email address

phishing at auth0 dot com

as an "abuse" inbox. We encourage customers and members of the public to report any suspicious Auth0-related emails they receive to this address. In addition, all Auth0 employees are trained to report suspicious emails they receive to this abuse inbox.

In Auth0’s infancy, every email that was sent to the abuse inbox was analyzed manually. A security engineer would review the email body and headers, copy URLs from the body of the emails and analyze them in various intelligence tools, and upload suspicious attachments (or their hashes) to various sandboxes. If the reported email represented a real threat, a remediation process was performed.

This worked great; however, as Auth0 started to grow, the volume of reports to

phishing at auth0 dot com

increased. Email analysis work became time-consuming and was detracting our attention from other higher-impact activities. In other words, it was a perfect use-case for security automation.

Security Automation

At Auth0, we rely heavily on security automation to ensure we’re not wasting valuable cycles performing repetitive, manual tasks. We partner with the security automation company Tines in this regard. Every alert from our detection stack, whether it’s from SIEM, GuardDuty, or custom tooling we’ve built, first goes through Tines where it is enriched, prioritized, and ticketed. We also use Tines to automate phishing responses.

Automated Phishing Response

For the most part, our automated phishing response story maps directly to our previous, manual process and consists of the following high-level steps:

1. Fetch email data and extract indicators
2. Create tracking tickets
3. Analyse indicators
4. Determine if the email represents a real threat
5. Close case if benign
6. Remediate if true positive

Step 1: Fetch email data and extract IOCs

The first step is to read all emails sent to our abuse inbox. We do this with GSuite’s Gmail API. Once we have the email content, we can extract all URLs and attachments and begin to analyse them. We also recursively open and extract Indicators of Compromise (IOCs) from EML files attached to the originally reported email.

Step 2: Create tracking tickets

We track and record every single email that’s reported to our abuse inbox in our case management system. Not only does this allows us to track the volume of emails reported over time, but it also allows us to store indicators for future reference and later threat-hunting.

Step 3 - Analyze indicators

One of the key benefits of automating analysis of indicators is that we can leverage many different intelligence sources without having to worry about wasting an analyst’s valuable time. In our phishing automation story we analyse URLs in:

• VirusTotal
• Urlscan.io
• URLhaus
• PhishTank
• Phish.AI

Protip: When submitting URLs to public sandboxes, remember to first redact sensitive information from URL parameters and never submit links that could be used to reset passwords, etc.

Tines allows us to easily add and remove intelligence sources and experiment with different combinations of sandboxes, without having to change the core flow of the automation story.

Step 4: Determine if the email represents a real threat

Once we have analysed a URL or attachment in all the various intelligence sources and sandboxes, we use the combined results to determine whether the URL represents a legitimate threat and should be remediated/escalated to a human engineer or whether it’s a false positive and we can ignore it. There’s some secret sauce involved in making this determination and we regularly change the criteria used as our requirements adapt.

Step 5: Close case if benign

If we have determined that all indicators associated with an email are benign, we update the ticket in our case management system and no further action is taken.

Step 6: Remediate if true positive

If, however, we have determined that the reported email represents a real threat, we perform a number of automated remediation actions. Again, these actions change regularly but include the following:

• Purge the email from all employee inboxes
• Sweep endpoint logs to determine if any employees visited the malicious domain/URL, or downloaded/executed a malicious file
• Proactively share indicators with trusted peers in the InfoSec community
• Quarantine the devices we believe may have been infected
• Contact users who visited and/or interacted with malicious content and provide them with the next steps needed to mitigate any damage
• Reset potentially compromised credentials

Again, for every step that’s taken, evidence is collected and added to the relevant ticket in our case management system. This ensures a complete paper trail is available for every action that’s taken.

Summary

Security awareness, email sandboxes, and strong multi-factor authentication all play a part in our defense-in-depth approach to phishing response. However, an abuse inbox, where employees and customers can report suspicious emails, is an indispensable resource, providing vital insight into on-going and emerging phishing attacks.

By automating triage of our abuse inbox, our security engineers can focus on higher-impact activities such as threat hunting and refinement or detection logic.