In this second installment of our Top Attacks Exposed series we shift our focus to the case of the insidious insider. While internal collusion is a known issue in all areas of cybersecurity, there are specific features of this type of attack in the business payment cycle that we’ll explore. Let's delve into a real-life case study, a situation we’ve encountered at a large Fortune 500 company, which resulted in a $10M loss. After revealing the attack’s sequence we’ll analyze the circumstances that made it possible for the attack to happen in the first place. This will allow us to better understand why the payment cycle is an easy target for these types of attacks. More troubling is that many organizations don’t realize that this could be happening right under their noses today. How confident are you that your B2B payment process hasn’t been compromised by an internal bad actor?
A malicious insider introduces a unique type of threat. Unlike external attackers that need to invest heavily in reconnaissance and information gathering to discover where the soft belly of their target is, the insider already knows the inner workings of the organization intimately. In fact, when it comes to manipulating the payment cycle, an internal bad actor that has access to ERPs systems not only knows how to tamper with them but can also weaken their controls.
Moreover, the imperative in any attack is for the malicious activity to stay hidden. Translating this into a working plan means that the attack should feature as little deviation as possible from the normal behavior of systems and individuals. Here again, the insider has an advantage by being familiar with activities that are considered ‘standard’ in their organization and thereby launching a scheme that aligns with this standard. Let’s dive into a specific scenario.
The insider had administrative access to the ERP system, where the bank account details of the vendors were stored. As such they could alter it at will, changing the bank account to whatever destination they desired. Since accessing the system was part of their working routine, there was no deviation from normal activity to detect.
Every month the insider picked a random vendor from which to transfer payments. The modus operandi was simple: near the date when payment was due, the insider replaced the vendor’s bank account with a fraudulent one. The insider made these changes to one vendor each month, which significantly decreased the likelihood that these activities would be discovered. After all, within a large organization that issues payment to thousands of vendors each month, it’s only natural that there will be issues with one or a few payments. The insider’s assumption, which proved to be correct, was that when the vendor noticed that they hadn’t been paid, the company attributed the payment issue to human error.
The insider took extra precautions. After each fraudulent payment transfer, they immediately restored the vendor’s banking account in the ERP to the previous real one. This made the attack almost impossible to uncover because they covered their tracks. Even if a vigilant security practitioner had checked the ERP system, they wouldn’t see anything unusual because all the information was always reverted back after the attack.
This insider attack went on for over a year without being detected. And had the insider only proceeded with this attack for 6 months it might have never been detected. However, a very lucky coincidence uncovered the fraudulent activities, rather than a security procedure or audit. It’s not surprising that perpetual malicious activity would come to light over time, but in this case it still resulted in $10M in losses.
When we analyze this use case closely, we can identify two key pieces that enabled this attack. The first was a lack of contextual awareness within the ERP. In conducting their attack, the insider created numerous deviations from the standard however they all went unnoticed. For example, the continuous changes to the vendors’ bank account details in the ERP system should have been flagged as an anomaly. Why are the banking details changed just before a transfer is made and then changed back? The normal process for bank account information is to have it configured when the vendor is onboarded, and then through a change request, the details and information is changed down the line, but is never reverted back to previous banking information after a payment is made. No one at the organization was looking for this pattern for specific vendors or even across the vendor supply chain, and no system was in place to catch this suspicious activity. Furthermore, the ERP system itself is unable to connect the dots between the insider’s activity and these vendor payment detail changes, so no red flag was ever raised. In this way the insider was able to circumvent detection.
The other factor that enabled this attack was a lack of contextual awareness around the insider’s own activity. Missing one or two payments to a vendor happens, however, if the same individual is viewing and editing vendor records and then shortly after payments are missing, that should raise suspicion. However, no system was in place to look at all the vendors that had errors in payments to see if there was a common denominator. In other words, no one checked to see if there was a pattern of behavior for these payment errors and if it involved the same person interacting with vendor details in the ERP. What’s more, in this example there were logs that showed all the activity of the insider within the system, but no one connected the dots looking at the logs of all vendors who weren’t paid to see if there was a connection between them. Had someone queried the logs in this way, they would have discovered the insider much sooner.
In this case, the organization needed better guardrails in place to catch the insider. No system or person was looking across all the activity taking place to detect anomalies and see the entire scheme being executed. The solution is having a system with controls in place that can see who is accessing vendor information, what information is updated (and if it's changed back later), how often this activity happens, and any other common threads that might indicate fraudulent activity is afoot. With all the siloed systems involved in the payment process, it’s impossible to see the full story within one or each individual system. There needs to be a way to detect and monitor these patterns and behaviors across all the systems, which a platform like Trustmi, luckily, is able to do.
Find out if your company has been hit with insider fraud. Get in touch today and we’ll conduct a weeklong POV of your historical data to show you if there have been errors and anomalies in your business payments that were, in fact, part of an insider attack.
Stay connected by signing up to our mailing list.
We promise not to spam :)
.png)
