Business Email Compromise (BEC) is a sophisticated form of cybercrime where attackers impersonate trusted individuals or organisations to manipulate victims into transferring money, sharing sensitive information, or taking other actions that benefit the attacker. BEC attacks often involve social engineering techniques, such as email spoofing, spear phishing, or even infiltrating legitimate email accounts.
Unlike traditional phishing attacks, BEC campaigns are highly targeted and rely on exploiting trust rather than malicious links or attachments. Attackers may impersonate a company executive, a supplier, or even a client, convincing employees to authorise fraudulent payments or disclose confidential data. The financial and reputational damage caused by successful BEC attacks can be devastating for organisations.
Preventing Business Email Compromise (BEC)
Like most attacks, preventing a successful Business Email Compromise (BEC) attack does not rely on a standardised approach for every organisation. Organisations should therefore adopt a multi-layered approach to further mitigate BEC attacks. The following recommendations provide a good starting point for organisations to begin strengthening defences against BEC:
- Enable Multi-Factor Authentication (MFA): MFA adds an extra layer of security by requiring users to verify their identity using multiple factors, such as a password and a one-time code sent to a mobile device. This significantly reduces the risk of account compromise, even if credentials are stolen.
- Conduct Regular Employee Training: Regular cybersecurity awareness training helps employees recognise and respond to phishing attempts, suspicious emails, and social engineering tactics. Simulated phishing campaigns can be an effective way to test and improve user awareness.
- Implement Advanced Email Filtering: Use advanced email filtering solutions that leverage machine learning to detect and block suspicious emails, including those that exhibit BEC-related characteristics, such as unusual sender behaviour or domain spoofing.
- Establish Payment Verification Processes: Organisations should establish strict processes for verifying payment requests. This might include requiring multiple levels of approval for high-value transactions or confirming requests via phone or in-person communication.
- Monitor Account Activity: Regularly review account activity for signs of compromise, such as unusual login locations, multiple failed login attempts, or unexpected mailbox rule changes. Microsoft 365 offers tools to monitor and alert administrators about suspicious activities.
- Deploy Role-Based Access Controls: Limit access to sensitive systems and data based on job roles. For example, only authorised finance personnel should be able to approve or process payments.
- Use Threat Intelligence Services: Subscribing to threat intelligence services can provide real-time insights into emerging BEC tactics and vulnerabilities, enabling organisations to adapt their defences proactively.
Securing Microsoft Exchange Online
Exchange Online, as part of Microsoft 365, is a widely used cloud-based email solution that offers a robust platform for communication; however, if Exchange Online is not securely configured, it can be a prime vector for cyberattacks, including phishing, spoofing, and business email compromise (BEC). Securing Exchange Online to prevent these types of attack requires the implementation of critical security features like SPF, DKIM, and DMARC.
Securing Exchange Online with SPF, DKIM, and DMARC is a crucial step in safeguarding your organisation from email-based threats. By implementing these authentication protocols, organisations can reduce the risk of spoofing and phishing attacks, improve email deliverability, and build trust with their recipients. While the configuration process requires careful planning and testing, the long-term benefits far outweigh the initial effort.
Test Your Email Server
If you’re not sure if you’ve already configured your organisation’s email service with SPF, DKIM or DMARC, we’ve found some helpful online resources that you can use to find out if these protocols have been configured correctly.
- The UK’s National Cyber Security Centre (NCSC) have a free online Email Security Check service that allows organisations to check if their email server is configured securely against spoofing attacks.
- Other online resources that you can also consider include: MX Toolbox, DMARCLY and Mail-Tester.
Sender Policy Framework (SPF)
Sender Policy Framework (SPF) is an email authentication protocol that verifies whether the sender of an email is authorised to send messages on behalf of a domain. It helps reduce email spoofing by allowing domain owners to specify which mail servers are permitted to send emails for their domain.
To understand how SPF works, consider the following steps:
- When an email is received, the receiving server checks the SPF record of the sending domain.
- This record is a DNS TXT entry listing authorised IP addresses or mail servers.
- If the sender’s IP matches an authorised server, the email passes the SPF check.
Enabling SPF has significant impacts. It prevents domain spoofing and reduces spam, improves email deliverability by signalling to receiving servers that your emails are legitimate, and ensures better communication security. However, misconfigured SPF can lead to legitimate emails being marked as spam, necessitating careful setup and validation.
Configuring Sender Policy Framework (SPF)
First, access your DNS management by logging in to your domain registrar or DNS hosting provider and locating the DNS settings for your domain. Next, add an SPF record by creating or updating a TXT record with the following value:
v=spf1 include:spf.protection.outlook.com -all
The -all
directive indicates a hard fail for unauthorised senders. Finally, verify the record using tools like MXToolbox or Microsoft’s Remote Connectivity Analyzer to ensure it has been correctly implemented.
DomainKeys Identified Mail (DKIM)
DomainKeys Identified Mail (DKIM) adds a digital signature to outgoing emails, allowing receiving servers to verify that the message has not been tampered with. This is accomplished using cryptographic signatures.
Here is how DKIM operates:
- When an email is sent, a cryptographic signature is added to its header.
- The receiving server fetches the public key from the sender’s DNS to verify the signature.
- If the signature matches, the email passes the DKIM check.
The benefits of enabling DKIM include ensuring email integrity, preventing tampering during transit, and building trust with receiving servers. However, improper implementation may result in failed authentication and delivery issues.
Enabling DomainKeys Identified Mail (DKIM)
Enabling DKIM requires several actions:
- Start by accessing the Microsoft 365 Admin Centre and navigating to the Exchange Admin Centre (EAC). Next, create CNAME records in your DNS settings. For example:
Hostname: selector1._domainkey
Points to: selector1-<domain>-com._domainkey.<your-tenant>.onmicrosoft.com
Hostname: selector2._domainkey
Points to: selector2-<domain>-com._domainkey.<your-tenant>.onmicrosoft.com
- Enable DKIM signing by going to the Protection > DKIM section in the EAC, selecting your domain, and clicking Enable.
- Finally, verify DKIM functionality using email testing tools like DKIMValidator to confirm that DKIM signatures are applied to outgoing emails.
Domain-based Message Authentication, Reporting, and Conformance (DMARC)
Domain-based Message Authentication, Reporting, and Conformance (DMARC) builds upon SPF and DKIM by allowing domain owners to specify how unauthenticated emails should be handled. DMARC policies can instruct receiving servers to quarantine, reject, or take no action on emails that fail authentication.
The functionality of DMARC includes:
- Combining results from SPF and DKIM checks.
- Evaluating alignment between the “From” header and the authenticated domains.
- Applying the policy (none, quarantine, or reject) defined in the DMARC record.
By enabling DMARC, organisations gain visibility into email authentication through detailed reports, strengthen protection against phishing and spoofing attacks, and enhance their email security posture. Misconfigured DMARC policies, however, can block legitimate emails, making careful planning essential.
Implementing Domain-based Message Authentication, Reporting, and Conformance (DMARC)
Implementing DMARC involves creating a DMARC record, monitoring reports, and tightening policies gradually.
- First, create a DMARC record by adding a TXT record to your DNS with the following format:
v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]
Key components include p=quarantine
, which specifies the action for unauthenticated emails, and rua
and ruf
, which define email addresses for aggregate and forensic reports, respectively.
- Next, monitor reports using DMARC reporting tools to analyse trends and adjust policies as needed. Begin with a policy of
p=none
to monitor email authentication without affecting delivery, then transition to stricter policies such asp=quarantine
andp=reject
as confidence in your setup grows.
Potential Challenges and Best Practices
While implementing these protocols, organisations may face challenges such as complex configuration requirements, potential false positives, and DNS propagation delays. For example, ensuring proper alignment between SPF, DKIM, and DMARC records can be technically demanding, and misconfigurations may result in blocked legitimate emails.
To address these challenges, it is best to follow certain good working practices when implementing SPF, DKIM or DMARC for your organisation.
- Always test records before enforcing strict policies using tools to validate configurations.
- Regularly monitor DMARC reports to identify and resolve issues promptly.
- Educate stakeholders about the importance of email security and provide training to help employees recognise phishing attempts.
- Leverage advanced security tools like Microsoft Defender for Office 365 to complement SPF, DKIM, and DMARC.
“We were very impressed with the service, I will say, the vulnerability found was one our previous organisation had not picked up, which does make you wonder if anything else was missed.”
Aim Ltd Chief Technology Officer (CTO)