Emerging Tactics and Trends
Our cloud incident response trainings are now available!
About Invictus Incident Response
We are an incident response company and we ❤️ the cloud and specialise in supporting organisations facing a cyber attack. We help our clients stay undefeated!
🆘 Incident Response support reach out to firstname.lastname@example.org or go to https://www.invictus-ir.com/247
Over the past months, we have provided support to multiple organizations that have fallen victim to Business Email Compromise (BEC) attacks. In this blog we would like to share some of the latest Tactics, Techniques & Procedures (TTPs) we observed during a specific BEC investigation in a Microsoft 365 environment. We hope that this information will be helpful to other incident responders and organizations working on similar cases.
During the investigation, we utilized the Microsoft-Extractor-Suite to collect all relevant evidence, and then analyzed it using the Splunk Blue team app for Microsoft365 & Azure. You can also extract the logs and feed it into your own platform of choice.
The typical modus operandi of Business Email Compromise attacks involves a user falling victim to a phishing email. The email contains a link to a legit looking Microsoft website, which is in fact controlled by the threat actor. The same thing happened and below is a screenshot of the phishing page.
After logging in the threat actor waited around 12 hours to access and validate the credentials, after which several emails were accessed.
The access was mostly via VPN related and Nigerian based IP-addresses, see full list in the Indicators Of Compromise (IOC) section.
- Phishing: Spearphishing Link [T1566.002]
Privilege Escalation & Lateral Movement
The account that was initially compromised wasn’t particularly interesting from a threat actor perspective as it didn’t have access to emails related to payments or privileged access. The threat decided to shift focus to other employees in the company using internal phishing
A phishing email was sent to the entire company, which eventually alerted our client to the breach. The email contained a link to a seemingly “shared” document.
The link leads to another fake Microsoft login page:
The internal phishing email led to two additional victims. For both victims, logins were observed from a Nigerian based IP-address:
One of the compromised accounts had the
Exchange Administrator Role which allowed for Privilege Escalation.
To cover their tracks, the threat actor deleted the phishing email from the compromised account and also purged it.
Tip: If you ever find yourself needing to recover a purged email, you can use the following command to restore it to the user’s mailbox:
Restore-RecoverableItems -Identity email@example.com -SubjectContains “subject-of-email”
This can only be done by users with a special role, and within 14 days of purging.
At this point the threat actor managed to obtain access to three unique accounts and one with Exchange Administrator privileges. With administrator access, the threat actor was able to perform some interesting techniques.
First the threat actor granted himself full access to the mailboxes of two other users by taking advantage of the victim’s Exchange Admin Role. The attacker also added
Send as and
Send on behalf permissions to the compromised accounts, effectively gaining full access to two additional mailboxes without the need for any additional credentials. The actor proceeded to read emails from these mailboxes.
Tip: If you want to know what emails were accessed by a threat actor. First filter for the
MailItemsAccessed operation and then use the value(s) in the
InternetMessageIdfield to identify what email was accessed.
Additionally, the threat actor sent an email to one internal and two external recipients. It is unclear why these particular recipients were chosen or why the message only contained the word “hello”.
Other interesting activity
The threat actor also performed another interesting action, which is not recognized as part of a specific phase or a MITRE ATT&CK Technique.
New inbound connector
After gaining access to the privilege account, the threat actor created a new inbound connector (reference). This is not a well-known technique, however there are a few references on internet by Argonsys and Microsoft.
After gaining access to the Exchange Admin Role, the threat actor created a new inbound connector named “”365” which allowed emails from the attacker’s infrastructure IP-address, to flow through the victim’s Exchange server. Later, an additional IP-address was added to the connector::
- 83.137.157[.]180 (offline)
- 194.163.164[.]133 (active)
We suspect this connector was created to be used as an email relay for further phishing or spam campaigns by the threat actor. If the email is originating from a legitimate Microsoft 365 environment, the chances of it being blocked or detected by email security solutions is much lower.
At the time of writing the 83.* address is offline, however the other one starting with 194.* is online and currently hosting a Windows machine (Shodan). The system has RDP exposed to the internet, so either this is a system belonging to the threat actor or a compromised machine that’s used as a relay itself.
Shortly after setting up the connector, the threat actor was detected and their access was revoked.
- Account Manipulation: Additional Email Delegate Permissions [T1098.002]
- New Inbound Connector [No MITRE TTP]
Most of the analysis was done using the Unified Audit Log which records events for 90 days by default. Below an overview of the relevant
Operations this information can be used to improve your defenses and to detect malicious behaviour.
Below are some recommendations for organizations to prevent and respond to Business Email Compromise (BEC) attacks:
1. Provide regular cybersecurity awareness training to employees
Employees are the first line of defense against BEC attacks. They should be trained on how to spot phishing emails, how to verify the authenticity of links and attachments, and how to report suspicious activity.
2. Use multi-factor authentication (MFA) for all accounts
MFA adds an extra layer of protection to accounts and can prevent attackers from gaining access even if they have stolen a user’s login credentials.
3. Disable legacy authentication protocol when appropriate
Legacy authentication protocols, such as POP3, IMAP, and SMTP, are susceptible to security vulnerabilities since they lack the capability to enforce second-factor authentication for MFA. However, in some cases, an organization may require the use of older email clients for business reasons, which may necessitate the use of legacy protocols. In such cases, it is important to limit access to these protocols to only the necessary users and to implement additional security measures, such as regularly changing passwords, to mitigate the risks associated with using these protocols.
4. Ensure the UAL is enabled
It is crucial for an administrator to enable the Unified Audit Log (UAL) in the Security and Compliance Center. The UAL serves as a centralized repository for all Office 365 events, making it an essential source of evidence. It should be on by default, but please double check using the
Get-AdminAuditLogConfig |Format-List UnifiedAuditLog* command.
5. Block mail forwarding to external domains
Blocking forwarding rules is an effective way to prevent unauthorized access to sensitive information by external parties or internal users. This can help minimize the risk of data leakage and protect against monitoring activities by malicious actors, thereby reducing the potential for further loss of valuable intelligence.
If you found this blog useful, consider sharing or commenting for broader visibility.
📧 Questions or suggestions contact us at firstname.lastname@example.org
Indicators of Compromise