In this series of blogs, we’ll explore common payment cycle attack patterns we encounter in the field. While every attack has its own flavor, there are common types that are easy to trace. The way we classify attacks is by the point in the payment cycle they target. We’ll analyze these attacks, focusing on the specific silo and implicit trust that makes them possible. To best benefit from this analysis, we suggest at every stage for you to pause and ask: could this have happened in my organization as well?
The concept of a supply chain attack is known and simple. Instead of attacking a large, financially attractive target organization directly, the adversary chooses to attack that organization through one of its vendors. And we know that there are various reasons that attackers do this. At a high level, vendors typically have access to the target organization’s systems, and they are easier to compromise than the target organization itself. Larger organizations often invest more heavily in their security teams whereas smaller vendors might not have the budgets to do so. Also, many organizations might maintain an ecosystem comprising a multitude of external vendors all with their own security standards in addition to different levels of access, which makes the task of enforcing consistent security controls almost impossible. These factors, along with others, make the supply chain an ideal penetration vector into the target organization’s environment.
To better understand how adversaries engage in supply chain attacks to compromise the business payment cycle, let’s explore an example we’ve seen afflict organizations out in the market.
The attacker conducts thorough reconnaissance to discover which vendors provide services to the target organizations. They can easily learn this from information that’s available on LinkedIn, Reddit, Spiceworks and other similar platforms. Following the initial investigation, the attacker chooses a vendor to compromise. Their aim is to gain access to one of the vendor’s email accounts. This task is accomplished by employing a standard phishing, spoofing, or social engineering attack, tricking one of the vendor’s employees into providing their credentials to a fake email login page. Once that step is achieved, the attacker now has access to the email account.
Gaining access to the email account is just the first step. Now, the attacker can start investigating the vendor’s email history to find any correspondence related to services or money transfers between the target organization and the vendor. Once such a thread is discovered, the attacker can now learn the typical characteristics of the emails sent between the compromised user and the target organization. They now have everything they need to craft a fake email from the vendor account that mimics the style and form of previous emails requesting payment from the target organization.
Now the adversary launches the main attack. They send a fraudulent email on behalf of the vendor to the target organization. In this email, they include an invoice that appears legitimate and that asks the target organization to change the vendor's bank account details for payment.
The employee in the target organization receives what seems to be a standard email from a known vendor that appears to be a legitimate request, containing nothing that overtly suggests something is amiss. As a result, the employee implicitly trusts that the email came from the vendor, and reacts the same way they always have in the past when they receive invoices and bank account change requests from that vendor. And so, the employee forwards the email to the Finance team to update the vendor’s payment details in the ERP with the fraudulent account information of the attacker.
The Finance team member receives the forwarded email from the employee. Like the previous stage, the Finance team doesn’t detect an anomaly and the request appears to be legitimate. Changing bank account details is considered a standard action for vendors and happens frequently. Moreover, the request is forwarded by an employee who the Finance team believes has checked and validated the invoice and information from the vendor. Thus, the Finance team member has no reason to doubt everything is above board and carries out the request, updating the vendor’s details in the ERP system.
The update of the ERP brings us to the next stage. The ERP system by design trusts the people who operate it and doesn’t raise a red flag if an employee updates or replaces data with new information for a vendor’s bank account details. The vendor’s bank account change takes place, the invoice is uploaded and processed, the money is wired from the organization, and payments are released and sent to the attacker’s bank account. Everything seems normal, and there is no indication that malicious fraud activity has been carried out. Neither the first employee nor the finance team suspects anything is wrong.
Of course, at a certain point perhaps months later, the vendor notices that they were never paid by the organization for the goods and services provided. How odd. During this 3-month period, the vendor believed that the customer was going to pay them on time. If they’ve worked together before, the vendor implicitly trusts that their client will pay them. But then 3 months pass, and the vendor reaches out and inquires after the payment. To the surprise of the employee and Finance team, they discover after an internal investigation that fraud has occurred, the vendor’s email was compromised, the fateful email with the fake invoice is discovered, and the whole chain of events comes into full view to the dissatisfaction and disappointment of all parties involved. And so, the financial losses are assessed, which is no fun for anyone.
It’s easy to see that the success of this operation was enabled by process silos and trust. The employee trusted the email from the vendor. The Finance team trusted the employee. The organization’s bank trusted the ERP was updated correctly. And all it took was an attacker hijacking a single weak link in the payment cycle to get the attack rolling and the payment sent to the wrong place.
While it’s tempting to assume that just a bit of awareness would have prevented this attack, that’s not the case here. The solution must be a unified layer that has visibility into all the different stages in the payment cycle and that can be aware of the full context of all these activities to catch the BEC attack the minute it happens.
Could this scenario happen to your organization? Reach out to our team and learn how Trustmi’s platform can prevent it.
Stay connected by signing up to our mailing list.
We promise not to spam :)
.png)
