How Financial Services Institutions Are Tackling Continuous Exposure Management

Leading Financial Services institutions are proactively identifying their most high-risk exposures with an Exposure Management platform. This post recounts 4 times they uncovered attack paths to their business data – and prioritized remediation to prevent the attack.

At financial institutions, 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. In 2021, the average number of days between compromise and detection fell to just three weeks, according to the Mandiant M-Trends Report.

This is a great step forward – yet despite all the improvements made by defenders in the areas of detection and response, breaches and incidents still happen. It doesn’t matter if it takes 21 days to identify a breach – if the attacker got to their target in fewer days, it could already be game-over.

While continuing to rely on endpoint protection solutions and log correlation tools as a necessary way to prevent and alert on attacks in real time, many financial services institutions are making the shift to proactive prevention, to make sure they are resilient.

This is because attackers don’t look at the individual exposure – rather, they leverage a combination of vulnerabilities, misconfigurations, overly permissive identities, and other security gaps to move across systems and reach sensitive assets. This route is called an attack path and this type of lateral movement can go undetected for weeks or months, and allow attackers to cause significant and ongoing damage while hiding inside networks. Understanding the available attack paths demonstrates how attackers compromise critical assets across on-prem and hybrid cloud networks.

From a potential Man-in-the-middle attack, to identifying a key risk in the supply chain, here are 4 real-life attack paths we found and remediated within networks in the financial sector.

Potential Man-in-the-Middle Attack at an Insurance Company

A large insurance company we work with 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, to exploit a Windows update vulnerability present on that system. One of those systems was a developer’s machine with several private SSH keys unprotected in their downloads folders. Using those SSH keys, an attacker would’ve been able to easily compromise around 200 Linux systems with their on-premise data center and in their cloud environment.

This could have allowed a large majority of their Linux servers to be compromised. From those 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 to make them aware of the SSH keys putting their Linux systems at risk, to limit future risk.

Global Financial Institution Ensures Offshore Developers Can’t Access Production Data

A global financial institution we worked with spent the last year hardening the sandbox development environment that its offshore developers work within. They didn’t think that any of the developers could access their production environment, but they wanted to be certain. A malicious insider threat, such as an offshore developer going rogue, or lack of control on how the offshore contractors handle their own security (e.g., not using MFA or complex passwords, or storing passwords in unencrypted note-taking apps) could pose significant risks to the company’s production data.

We very quickly saw that not only was it possible but it was actually very easy for any of the developers 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 to remediate this issue and ensure that there were no potential attack paths from the developer sandbox environment to the production systems. They now run the same simulation every day to demonstrate to leadership that there’s no way any third-party contractors can access their production data.

Global Bank Thought ZeroLogon Patch was Deployed

As part of patch Tuesday, one of our customers, a global bank, had tried to patch all servers using SCCM. This included the patch for the ZeroLogon (CVE-2020-1472) vulnerability on the domain controllers. The domain controllers are very sensitive and mission critical, so not all were rebooted after the patch update.

The patch was deployed, but the fix had not been fully implemented because of the reboot that had been suppressed. This left an open avenue that attackers could use to compromise the domain controllers.

How was this remediated?

As soon as they became aware of the issue, they changed their procedures to ensure that in the future, they won’t forget to reboot after patching when required.

The Bank and the Complicated Attack Path

A global financial institution identified an automation using a service account which had initiated an action based on SMB port. This could risk credentials from this service account to be used for a Man-in-the-Middle attack inside the network, which would allow an attacker to laterally move to another device/workstation in the network. Next, they found SSH private keys to a server running on an EC2 instance (AWS). Attached to this EC2 was an IAM role, and using its permissions it was possible to spin up a new EC2. Finally, this could be used to compromise one of their most critical assets, used for deployment in the customer environment.

Although it’s a bit of a complex path, it’s very potent – and if the wrong entities were to locate it, it could be a disaster. 

How was this remediated?

They immediately remediated each part of the attack by removing private SSH keys, resetting IAM role permissions, and removing specific users.

Close the Exposures of Today to Prevent the Attacks of Tomorrow

Most security teams have tons of exposures and they don’t have the time or ability to see which ones impact their risk the most or how they all come together to be exploited by an attacker.

With exposure management, you can understand where the most high-risk vulnerabilities and exposures in the infrastructure are, to prioritize those first. Not only can you spot the exposures that pose the greatest risk, you’ll know exactly which critical assets are at risk and how to remediate with step-by-step instructions.

Some of the world’s largest, most complex financial services organizations use XM Cyber to eradicate risk. Learn how you can eliminate risk across your hybrid cloud network at a fraction of the effort by getting a demo.