Four Real-Life Financial Service Attacks Paths

Back in the wild west, there was this guy, Willie Sutton. Willie’s chosen profession wasn’t the town dentist-barber or saloon owner. Nope, he was one of the most prolific bank robbers. And when asked why banks were his number one target, famously, he replied “because that’s where the money is”.

No vouching for his career choices, but the observation was blazingly astute.

The world has evolved more than a bit and today, the incidents of IRL robberies are thankfully less common, but cyber attacks are more common than ever. To this day, financial services continue to be one of the most highly targeted sectors, and in fact, a report from Boston Consulting Group found that FinServ was targeted 300 times more than other industries. 

To try to prevent such events from occurring, security teams continually invest in the best detection and response tools. Over time, this has led to greatly improved Mean Time to Detect (MTTD) and Mean Time to Respond (MTTR). And dwell times have gone down as well. These stats represent a great step forward. Yet despite the improvements made by defenders in the areas of detection and response, breaches and incidents still happen. And whether it takes 21 days to identify a breach or not is irrelevant if the attacker reached their target in fewer days.

There are a lot of blogs and articles that focus on how those approaches can potentially reduce losses and *maybe* prevent attacks. FinServ orgs continue to rely on endpoint protection solutions and log correlation tools to prevent attacks in real time, financial services security teams are making the shift to more proactive prevention. These approaches definitely have merit – but back to that “300 times more” thing – clearly, they aren’t doing quite enough. 

This blog takes a bit of a different approach by exploring 4 real-life attack paths from actual organizations within the financial services space. Why explore their attack paths? Attack paths are the routes by which attackers can take to enter systems and reach assets. Certain exposures on their own, aren’t capable of being leveraged in any significant way by attackers. But attackers don’t look at the individual exposure – instead they leverage a combination of vulnerabilities, misconfigurations, overly permissive identities, and other security gaps to move across systems and reach sensitive assets. This allows them to cause significant and ongoing damage while hiding inside networks. 

Understanding attack paths helps us understand how attackers compromise critical assets across on-prem and hybrid cloud networks. Following are four real-life attack paths we found and remediated within networks in the financial sector. By understanding the construct of attack paths, we can better understand how the attacks would have occurred – and importantly, how to prevent similar attacks down the road.

Attack Path #1 – Man-in-the-Middle Attack at an Insurance Company

A large insurance company discovered that a small subset of machines was sending out DHCP v6 broadcasts, enabling an attacker to position themselves as a man-in-the-middle and exploit a Windows update vulnerability on those machines. 

One of the machines belonged to a developer and had several private SSH keys unprotected in its downloads folder. Using these SSH keys, an attacker could easily compromise some 200 Linux systems in the company’s on-premise data center and in their cloud environment. From these systems, the attacker could have carried out additional attacks, encrypted systems/data for ransom, or exfiltrated data.

How was this remediated?

By disabling DHCPv6 and patching the developer’s machine, both the vulnerability and misconfiguration were addressed. It was also a good time to review best practices with the developers – making them aware of how SSH keys could put their Linux systems at risk.

Attack Path #2 – Global Financial Institution Ensures Offshore Developers Can’t Access Production Data

A global financial institution spent a year hardening their sandbox development environment for offshore developers, in order to ensure that developers couldn’t access their production environment. They were looking to avoid the risks of a malicious offshore developer going rogue, or a breach resulting from lax security practices in the contractor digital supply chain – either of which could pose significant risks to the company’s production data.

Our analysis found that not only was it possible, but actually quite simple for any developer to abuse a Lambda function within AWS, assume a role with privileges, and then move laterally into the production environment.

How was this remediated?

The security team shared this attack path with the cloud architecture team, who then removed the Lambda misconfiguration. This remediation ensured that there were no potential attack paths from the developer sandbox environment to the production systems. Today, the financial institution runs the same simulation every day, to ensure that no third-party contractors can access production data.

Attack Path #3 – Global Bank Did Not Fully Deploy Patch 

As part of a Patch Tuesday, a global bank tried to patch all servers using SCCM. This included the patch for the ZeroLogon (CVE-2020-1472) vulnerability on their domain controllers. 

Since domain controllers are very sensitive and mission critical, not all were rebooted after the patch update. Thus, the patch was deployed, but the fix was not fully implemented. This left an open avenue that attackers could use to compromise the domain controllers.

How was this remediated?

Once they understood the issue, the bank’s team changed procedures to ensure reboots after patching when required.

Attack Path #4 – The Bank and the Complex Attack Path

A global financial institution identified an automation using a service account which had initiated an action based on SMB port. This could enable credentials from the service account to be used for a man-in-the-middle attack inside the network – enabling an attacker to move laterally to another device or workstation. 

Then, they discovered private SSH keys to a server running on an AWS EC2 instance. Attached to this EC2 was an IAM role. Using the permissions from this role, it would be possible to spin up a new EC2. And this could be used to compromise one of the company’s most critical assets, used for deployment in the customer environment.

If a threat actor had discovered this path, the consequences could have been disastrous. 

How was this remediated?

The bank immediately remediated each step of the attack path – removing private SSH keys, resetting IAM role permissions, and removing specific users.

Enterprise security teams face so many exposures, it’s hard to understand which impact risk level most acutely, and how they can be strung together and exploited by a savvy attacker.

In the ever-evolving financial services threat landscape, the focus is shifting towards proactive prevention, understanding and securing complex attack paths. These real-life scenarios underscore the importance of addressing vulnerabilities and exposures strategically to safeguard critical assets.