Cisco Breach – A Cautionary Tale of Mismanaged Credentials & Privileged Identities | BeyondTrust

On the 10^th of August 2022, Cisco confirmed they had been breached by the Yanluowang ransomware group. On the same day, the Yanluowang group posted a notice on their own site and claimed to have stolen 2.75GB of Cisco’s data, consisting of around 3100 files, including NDA documents and engineering files.

It’s important to highlight that, while Cisco has acknowledged and investigated the breach, they do not believe any products, services, or sensitive customer data were impacted.

In Cisco’s public response to the breach, they stated, “Cisco did not identify any impact to our business as a result of this incident, including Cisco products or services, sensitive customer data or sensitive employee information, intellectual property, or supply chain operations. On August 10 the bad actors published a list of files from this security incident to the dark web. We have also implemented additional measures to safeguard our systems and are sharing technical details to help protect the wider security community.”

However, as with any breach, it’s helpful to understand what happened in order to inform your own threat defenses. So, let’s explore the steps—and missteps—around this incident and see what lessons can be learned.

Step 1 – Acquiring the credentials via a compromised personal (Google) account

The breach began with the compromise of a Cisco employee’s personal Google account. While the details of how this happened have not been shared, there are multiple common scenarios for this to happen. Here’s a few common ways this could have occurred:

• The employee was phished and handed over the credentials
• The employee reused a password that was leaked in another breach
• The employee accidentally downloaded some credential stealing malware

While a compromised personal account is generally not an issue (unless the user reuses passwords), in this case, the employee was signed into Chrome and used the password syncing feature to store some Cisco credentials.

Security Lessons

There are a few lessons to be learned here. First, it’s important to separate corporate and personal accounts and data to prevent accidental leaks. Second, corporate passwords should be unique per account, and stored and managed by an enterprise password management tool to ensure appropriate controls.

Often, browser-based credential stores are encrypted locally using Windows APIs. While this practice prevents other users from easily accessing the credentials, any code running in the context of the user can easily access the passwords stored in plaintext. While it is possible to prevent users from signing into Chrome on corporate controlled systems, this cannot easily be enforced on personal devices. There are also Windows security settings that can prevent other passwords being stored by the user in other areas.

Step 2 – Authenticating to the Cisco VPN

The attackers now had the user’s credentials but, to authenticate to the Cisco VPN, they needed to get an MFA push sent to the user’s mobile device and have it approved. To accomplish this, the threat actors used two techniques.

• Voice phishing – Calling the user pretending to be from support organizations the user trusted
• MFA fatigue – Triggering MFA push notifications repeatedly in the hope the user would approve one to make the notifications stop

Once the threat actors succeeded in gaining MFA approval and authentication, they enrolled new devices under their control to use for MFA. With this done, the attackers could simplify their authentication process for the future.

Security Lessons

MFA does not fully protect user accounts by itself, and not all MFA methods are created equal.

Many organizations rely on knowledge-based MFA to authenticate rather than possession-based ones. Although having MFA codes sent to a phone though SMS or push notification are better than a username and password alone, they are still phishable. This attack shows why FIDO2 authentication is so important.

From SIM card cloning and voicemail interception to classic social engineering and MFA fatigue, there are multiple ways to abuse knowledge-based credentials, as they aren’t linking a user to a device. Where possible, organizations should look to move away from basic mobile phone-based MFA to a more secure possession-based authentication like FIDO2, especially for highly privileged or sensitive accounts. It is also important to understand MFA attack techniques and how to prevent them. For example, training employees to be aware of voice phishing, social engineering attempts, and reporting unsolicited MFA events is important, but often forgotten. There is also a need to ensure MFA logging is enabled and monitored to identify unexpected spikes in activity, activity at unusual hours, new devices being enrolled, etc. Ultimately, it is important to remember that MFA isn’t perfect and must be implemented correctly to provide protection.

Step 3: Execution, persistence, and lateral movement

Once connected to Cisco’s internal network via their VPN, the threat actor used stolen credentials to connect to internal systems. They were able to drop a number of tools, including LogMeIn and TeamViewer, to maintain remote access and persistence. Cobalt Strike and Mimikatz were then dropped for exploitation, credential harvesting, and lateral movement. It was the presence of these tools that initially alerted the incident response team.

It is worth noting that the threat actor appears to have been unusually “noisy” by introducing multiple tools to the environment rather than “living off the land” and using fileless techniques. It is unclear why this was the case—it may point to this threat actor being more focused on initial access with their voice phishing techniques. Often, threat actors specialize in an area and will then sell access to another actor for the next stage, but Cisco access might have proved too tempting to sell.

While the exact details of how the attacker elevated privileges have not been shared, it is clear the attackers made use of several privileged accounts in the environment, including machine accounts. These privileges were used to move laterally and establish new local administrator accounts on systems, creating a local admin user called “z” as well as resetting the password of existing local admin user accounts.

This local admin account was used to execute reconnaissance tools (such as adfind and secretsdump) to obtain additional credentials, as well as to dump the SAM database and LSASS memory on compromised systems.

The threat actor also used the privileges to establish Windows lock screen bypasses using the “sticky keys” trick. They attached cmd as a debugger to sticky keys, which allowed them to launch a SYSTEM command prompt from the logon screen, with no need to log in.

This method would be useful if the credentials they were using were revoked. The attackers could simply use their established remote access tools and this lock screen bypass to reset local admin accounts or run privileged commands. It is worth noting that this technique is commonly detected by AV and EDR products, which again points to a lack of sophistication on the threat actor’s part.

Security lessons

VPNs don’t just let employees in

This provides a good example of why many organizations are shifting away from VPNs, which typically give broad network access. Zero Trust Network Access (ZTNA) approaches provide a more controlled, secure experience by ensuring granular access to just those applications and tools an employee needs. Such zero trust security controls not only reduce the likelihood of a breach occurring in the first place, they also limit the blast radius in the event of a compromise.

Even with a VPN, there are best practices that can be followed around network segregation, access logs, and traffic monitoring to ensure that a compromise can be contained and detected. In this case, we saw an attacker land and expand because of broad access that could have been controlled and limited.

The principle of least privilege isn’t new, but it does work

The threat actor’s modus operandi here also highlights why robust application allow listing and privilege management are such fundamentally critical and powerful defensive measures. The ability to prevent unknown applications from executing, or at least limiting easy access to privileges to prevent an attacker dumping credentials, minimizes the ability of a threat actor or malware to execute or make any headway in an attack.

Privileged accounts, both local and domain, should be carefully monitored and managed. Being able to discover and remove users’ admin privileges, as well as manage machine accounts and service accounts, does a huge amount to reduce the attack surface and limit an attacker’s ability to move around the network.

One privileged account leads to another

The privileged accounts that were compromised allowed the threat actors to move laterally, harvest more credentials, and, ultimately, breach domain controllers and Citrix servers. However, despite this widespread compromise, Cisco believes that the only data successfully exfiltrated was the contents of a Box folder linked to one user’s compromised active directory account.

Once Cisco removed the threat actor from their systems, several more attempts were made to gain access to the Cisco VPN, as well as to contact executives in the organization. The email contact included screenshots of files to show that the perpetrators had access to Cisco data.

Cisco Breach: Attack & defense summary

This Cisco breach was a fresh reminder of how a determined threat actor can compromise an enterprise, starting with one compromised identity. Here are some key takeaways from this breach:

• Employees’ personal accounts can cross corporate boundaries, causing a weakness that enables an attacker to gain a foothold.
• MFA does not fully protect user accounts by itself, and not all MFA methods are created equal. Employee education, monitoring of MFA logs, and, ideally, use of FIDO2, are important in reducing security risks.
• A VPN shouldn’t provide an open door to an attacker. Assume compromise and build defenses accordingly. Consider a ZTNA approach to limit the blast radius.
• More privileges, more problems. The compromise of any identity is an issue, but the problems increase exponentially when it is a privileged identity. Applying least privilege access to privileges for human identities and machines identities on local and cloud systems is essential to reduce risk.
• Log and listen. In the Cisco breach, the attacker was noisy and this provided valuable indicators of an attack. New local admin accounts being created, rogue remote access tools being installed, and new devices enrolled for MFA are all activities that can be audited and controlled.

All across this attack, privileged identities and access were compromised, and these were crucial for the threat actor to advance. If you would like to know more about securing privileged credentials, identities and secure remote access, contact BeyondTrust. Our comprehensive approach to PAM provides powerful, blended protection against external attacks and insider threats alike, while also enabling zero trust security principles. Learn more.