Alfred Da Silva

Alfred Da Silva

Study Case

The Cyber Challenge

Incident Response for a Business Email Compromise attack

Location
Italy

Date
July 2023

A cyber attack carried out via email was reported. Acme Corporation noticed a missing payment from one of its customer: Umbrella Corporation. It seemed that Umbrella Corp. made a payment to an illicit IBAN after receiving an email stating new payment details to settle an invoice issued by Acme Corp.
The email appeared to have been sent from Acme’s user Peter Griffin (peter.griffin@acme.com)
Since Acme had not sent this communication and the bank account specified in the message was not owned by them, it was clear we were facing a Business Email Compromise (BEC) attack.

Note: For privacy reasons, I cannot disclose client names. Company names has been changed. Our customer’s name will be “Acme Corporation” while its partner’s name will be “Umbrella Corporation”.

Detection & Analysis

Email message
Looking carefully, we saw that the email did not actually originate from the corporate domain “acme.com” but from a similar domain: “acne.com.” The displayed Name of the sender was exactly “Peter Griffin”, Acme’s sales manager.
From this observation, we came to understand that the attack was performed with typosquatting.
Even analyzing the message header, it was evident that the email did not originate from the corporate mail system, which is indeed Microsoft 365, but from a different one: mailhostbox.com.

DNS Domain
We first analyzed the acme.com domain, to check the SPF record configuration.
From the findings, it appeared that the record was properly configured and did not allow emails to be sent by illicit mail servers.
Next, we also analyzed the phishing domain.
We found out that it had been carefully configured, since it was created almost one year before the attack and both the SPF and DKIM were correctly configured, so as not to be intercepted by antispam systems.

Inbox Rules
We choose to check the rules for incoming mail configured in the corporate mailboxes, since attackers often create rules inside victim’s mailbox as a way to maintain stealthy access.
We used the Exchange Online PowerShell module and the cmdlet Get-EXOMailbox to export these information and we noticed the presence of some rules that hided messages containing the words “payment” and “invoice” from the inbox folder.
At that point we suspected that attackers had gained access to user’s Microsoft accounts to create the rules.

Azure AD
To confirm this hypothesis, we looked at the accesses made to the Microsoft cloud with corporate accounts, via Azure Active Directory reports.
The logs showed accesses performed from unusual locations for some users, including Peter Griffin himself.
The account compromise was now undeniable.
We also noticed a relevant misconfiguration on the tenant: MFA was not enabled for most users.

Containment & Eradication

To ensure the integrity of accounts belonging to the Azure AD tenant acme.com, we chose to follow the following steps:

  1. Apply appropriate complexity criteria for passwords
  2. Reset passwords for all users
  3. Force Logoff on all devices currently connected to each account
  4. Force re-enrollment of MFA

Since acme.com was a hybrid domain without the password write back option, we had to manage the password requirements through local Active Directory. We wanted to apply the requirements to groups of users instead of the whole domain at once, so we had to use the Active Directory Fine-Grained Password Policy instead of Group Policy Objects.

After that, we forced all users to reset password at next logon. Once done, we synched the new passwords through AD Connect.

Then we moved onto Office 365 Admin Center to force logoff on all devices connected to each user account.

Eventually, we also forced the MFA re-enrollment through the Azure Active Directory option “Require re-register MFA” for every user.

Finally, we enabled a Threat Intelligence service to continue monitoring the presence of additional phishing domains and block them promptly.

Conclusion

After four weeks of monitoring we detected additional login attempts from the same unusual locations, which failed due to the failure of MFA check.

We could claim to have restored the integrity of the corporate accounts.

Before considering the incident response activity concluded, we emphasized the urgency of investing in training paths to increase employee cybersecurity awareness and prevent similar events in the future