Inside the MSP Wire Fraud Playbook: How Hackers Hijack Payments

Inside the MSP Wire Fraud Playbook: How Hackers Hijack Payments

Wire fraud is a sophisticated form of financial fraud that exploits social engineering techniques such as phishing, email spoofing, and domain impersonation to deceive victims into disclosing sensitive information or authorizing transactions to fraudulent accounts. One of the most prevalent tactics involves attackers registering domains that closely resemble legitimate domains and using these to send deceptive emails to suppliers or vendors, thereby redirecting payments to accounts under the attackers' control. These fraudulent bank accounts often bear names similar to legitimate ones and are distributed across multiple jurisdictions, complicating traceability and legal intervention. Common jurisdictions used to register these fraudulent bank accounts include countries known for their less stringent banking regulations and high levels of financial secrecy. Additionally, some banks may not perform stringent name checks or may have lax verification processes, which can be exploited by perpetrators of wire fraud.

Wire fraud schemes often involve use of money mules, these are individuals who are recruited to transfer illicit funds on behalf of cyber criminals. These mules may be unwitting participants or complicit actors enticed by a share of the profits. Once the funds are deposited into the mule's account, they are rapidly moved through a series of transactions, often involving multiple countries, to obscure the money trail and evade detection by authorities.

For wirefrauds, attackers have to privy to internal communications to find information about supplier/vendor emails and who deals with it internally, however, at the same time, it is possible to do the same, by solely relying upon OSINT and companies tend to expose information about their suppliers on platforms such as Linkedin, which may allow an attacker to correlate email addresses that deal with them.

Background

A major recruitment company in the US approached REDSECLABS suspecting wire fraud, whereby, emails were sent from legitimate accounts to their suppliers/vendors, requesting payment redirection to attacker controlled accounts. The email was sent from a user POC that is normally used to initiate such communications.

The email contained an attachment: a PDF document which included the attacker's bank details. The attacker retained all original information, including company details, and altered the bank account details.

The first step was to ascertain if these emails were being sent from a legitimate source or being spoofed. Upon checking, the email headers, it was determined that the email is indeed legitimate and not spoofed, in one instance, attacker registered a alike domain to sent an email. This was perhaps to deviate the investigators in thinking that attacker is operating outside the environment.


Next, step was to obviously investigate the logs of email accounts that were used to send these emails. However, to our surprise, all of these accounts were Multi Factor Authentication (MFA) enabled since the very beginning and showed no signs of compromise. This gave credence to the theory that the attacker has probably used spear phishing and has obtained access to the victim’s machine. Upon investigating the machines, no signs of compromise was found.

Next step was to dive deeper into the Azure environment, and during the analysis, it was determined that the MSP (Managed Service Provider) email account was compromised which had Domain Administrator Privileges, this attacker targeted a dormant training account and reset its password and elevated its privileges. Using the compromised training account the attacker executed the operation "Add- Mailbox Permission" on the victims mailbox. This action granted the attacker full access rights to the victim mailbox, enabling them to read, send, and delete emails, and manipulate communications undetected.

Initial Compromise

Upon delving deeper into the breach regarding the compromise of the support account, we relied on Azure Entra ID logs for insight. Through this investigation, it became evident that a Global admin account had been compromised, with the attacker gaining entry from an suspicious IP address. After accessing the domain account, the attacker targeted a dormant training account and reset its password. By elevating the permissions associated with this account, the attacker expanded their access and control within the domain.

Following logs reveal attacker logging into the MSP Support account, as indicated earlier The the MSP Support ([email protected]) account was Global administrator on the Domain:

Privilege Escalation

Upon accessing it, attacker reset password for the training account ([email protected]) considering that it was not in use and then elevated its permissions.

Using the elevated permissions attacker logged into the “Training account” ([email protected])

Assigning Privileges to Mailbox

Next, attacker using [email protected] performed the operation “Add-MailboxPermission" on the mailbox victim". User "[email protected]" granted full access to victims mailbox, hence being able to read, send, delete emails on the behalf.

This event triggered an alert named “Mailbox Permission Change” alert in the compliance center.

From the details, it’s clear that [email protected] has full access to the victim email.

Covering Tracks

The attacker also added several email rules to the victim's inboxes to prevent them from recognizing the unauthorized activity.

Here is an example of one such domain:

Following is an example of the rule found on victims mail box, the rule suggests that as soon as the message is received containing words from supplier/victim domain, it should be marked as read and moved to the “Conversation History”. This is to prevent victim from recognizing what is going on.

The attacker also registered a fake domain similar to the original email account and created a victim account to send a similar email.

The domain was registered a few days after the initial compromise. We were able to retrieve the whois record using a third party aggregator and determined that the domain was registered on a fictitious email.

Lateral Movement:

The attacker added mailbox permissions and sent similar fraudulent emails from other compromised accounts This widened the scope of the attack and increased the attacker's ability to deceive and manipulate victims
Here is an example of an email sent from victim account.

Attribution and Tactics

The attack technique closely resembled that of APT28-29, known for employing similar tactics to target active directory environments.

Technical Analysis of Attacker IP

Further technical analysis revealed the following IP addresses associated with the attacker:
⦁ 199.247.14.116
⦁ 45.133.158.29

Notably, the IP address 45.133.158.29 has shown prolonged activity and has been flagged for malicious attempts, as indicated by discussions on Microsoft platforms regarding known malicious activity associated with this IP on 8/7/2022.

Incident Timeline

The timeline of the incident based on available, identified evidence is as follows:

Event Table
Date/Time Event
15th March 2024 Attacker logged in to the Global account
15th March 2024 Attacker elevated privileges of supportaccount and logged into it
2nd April 2024 Attacker used victim’s email to send customer updated invoice.
4th April 2024 Attacker added permission to the 2nd victim’s email and sent emails on her behalf to customer asking for procedure to update bank accounts
4th April 2024 Attacker added Mailbox permission to 3rd victim’s email.
4th April 2024 Attacker registered fakedomain.com which is similar to original domain
5th April 2024 Victim sent email to customer with updated ACH instructions
8th April 2024 Attacker sent email using 4th victim confirming the email sent by 2nd victim.
9th April 2024 Attacker used [email protected] domain to send customer another email.