Hybrid work is here to stay. According to the 2022 Cisco Global Hybrid Work Study, more than 90% of respondents will work remotely at least part time in the future. In many organizations, however, remote workers are left with fewer security protections than those on the corporate network, and attackers have taken notice.
One of the largest breaches in the past year involved an attack on a remote user. While our intent is not to sensationalize a company’s data breach, the attack is a useful model to study how threat actors are targeting remote workers in the wild. This post will focus on the tactics and techniques used by the attacker and how security service edge (SSE) can help you protect your users from similar threats.
Recent breaches remote work security challenges
The targeted organization released two primary breach disclosures detailing separate incidents involving the same as-yet-unidentified attacker. The first notification detailed an incident in August 2022. While this notification lacked details on the initial attack vector, it said the attacker had compromised a software engineer’s corporate laptop, which it used to “tailgate” into the corporate systems via the corporate VPN. With this access, the attacker exfiltrated proprietary company source code, some of which included cleartext embedded credentials and stored digital certificates.
In the second breach disclosure, the company describes a much more impactful compromise of their systems that resulted in the exfiltration of access and decryption keys for production backup systems, other cloud-based storage, and related critical database backups. The two incidents are part of a single attack involving the same threat actor, according to the breach.
In this case, the attacker specifically targeted a senior DevOps engineer who had access to decryption keys needed to access cloud storage services and likely had other deep privileges. This kind of high-value user is often subject to targeted attacks because they have access to highly sensitive environments as part of their day-to-day job.
The attacker compromised the engineer’s home computer through a three-year-old vulnerability in Plex Media Server. The vulnerability, which was patched in version 1.19.3 in 2020, allowed an attacker with access to the user’s Plex account to remotely change the media server’s data directory to overlap with the directory for Camera Upload, a now unsupported feature that allowed users to remotely upload files. With the directory changed, the attacker could upload a malicious file that enabled remote Python code execution.
According to the second breach disclosure, the attacker installed a keylogger on the engineer’s computer by using this remote code execution exploit. The attacker was then able to capture the engineer’s master password and gain access to the employee’s corporate password vault. From there, the attacker exfiltrated highly sensitive notes that contained decryption keys for a number of key systems.
The entire attack kill chain looks like this. Note that I am going to make a few assumptions where details of the breach are sparse or not available. You should treat this as a model for a potential attack rather than a factual recount of what happened.
- Assumption: when researching the company, the attacker identified high-value employees to target that likely had deep access privileges. Threat actors often identify these users through social media sites, such as LinkedIn.
- Assumption: after identifying a potential target, the attacker managed to identify the user had a Plex account and compromise it. This could have been accomplished in a variety of ways, such as phishing. Plex did disclose a breach in August 2022 that leaked user emails, username, and encrypted passwords. It is possible – though unconfirmed – information from this Plex breach was used to compromise the account.
- With Plex account access, the attacker was able to exploit CVE-2020-5741 on the employee’s outdated media server to implant keylogger malware.
- Eventually the attacker was able to capture the employee’s master password.
- Assumption: the attacker was able to trick the user, allowing them to bypass MFA. One possible way this could be done is to wait for a time when the employee was likely to be authenticating, then sending a duplicate MFA request in the hopes that the user would mistake it as legitimate.
- Once authenticated, the attacker could access the user’s access credentials and secure notes, which included corporate decryption keys for a number of services.
- Then it is just a matter of accessing systems, exfiltrating data, and decrypting it where possible.
For many companies, remote work security is a relatively new challenge. There are many more remote and hybrid workers than there were just a few years ago, and attacks targeting these users are a new challenge for many security teams. This attack is a rare example of a publicly disclosed breach that targeted a remote worker, and it includes enough detail for us to create a model based on tactics and techniques that are actively in use. By studying this model, you can take away a few lessons that will help you improve your security posture and defend against similar attacks.
Security Service Edge (SSE) can help protect remote workers
One of the most significant technologies that can help you protect remote workers is the security service edge (SSE). In fact, the company noted in the disclosure that in response to the breach, they adopted zero trust network access (ZTNA) and a secure access services edge (SASE) architecture. SSE is the security component of SASE, and it includes ZTNA as one of its primary functionalities. SSE represents the convergence of a variety of technologies, including secure web gateway, cloud access security broker, zero trust network access, and cloud security posture management.
Zero Trust Network Access (ZTNA)
In this case, ZTNA is particularly effective. In the first security incident, the attacker was able to “tailgate” onto the corporate VPN via the compromised engineer’s laptop, which gave them access to source code repositories. Oftentimes, the use of VPNs creates open, flat network access, where once a user authenticates, they have broad access to sensitive resources. This means that if an attacker can gain access to the corporate VPN, they have extensive reach inside the network. In other words, the blast radius of the attack is larger.
ZTNA is a component of zero trust architecture that provides secure remote access to an organization’s applications based on defined access policies. A key difference between a VPN and ZTNA is that ZTNA provides access only to specific applications instead of the entire network, ensuring that if an attacker manages to bypass authentication, they can only access the target application and not everything on the network. ZTNA effectively reduces the blast radius of an attack.
Not only would the use of ZTNA have limited the scope of the attack, but it may also have prevented the attacker from accessing any secure systems. When a user authenticates to connect to a ZTNA-protected app, the security posture of the user’s device is assessed to ensure it is safe to connect.
These capabilities would have had been relevant during two crucial moments of the attack. In the first incident, it would have limited the attacker from gaining broad access to the corporate systems via VPN. In the second incident, it might have prevented the employee from accessing secured resources from their vulnerable home computer, which would in turn have prevented the attacker from using access to the machine to infiltrate corporate systems.
Data Loss Prevention (DLP)
Moving beyond the initial attack vector, it is also important to secure the resources that remote workers can access, by using strong security policies. One such policy is controlling sensitive information at rest in cloud services or in transit from remote workers’ computers using Data Loss Prevention (DLP) policies.
As its name implies, data loss prevention, or DLP, aims to prevent data exfiltration by identifying sensitive data at rest or in motion. Commonly, DLP is used to detect unsecured credentials, access tokens, or personally identifiable information. There are two primary types of DLP: inline DLP, which captures web traffic from a user’s machine in real-time, decrypting it where necessary, and inspecting it for sensitive information based on security policies; and API-based scanning, which inspects at-rest data in cloud storage services for sensitive information.
Cisco DLP can identify cleartext embedded credentials or other sensitive data at-rest in places they shouldn’t be. Also, if an employee attempts to store, post, or otherwise transmit sensitive data to restricted or unauthorized destinations, inline DLP will identify it and prevent the transfer. This would prevent an attacker from using a compromised user machine to exfiltrate this data. In this attack, DLP policies could have prevented cleartext credentials from being stored in the source code repository or transmitted by the attacker.
Secure Web Gateway (SWG) and DNS Security
In this attack, exploiting the vulnerable Plex media server was a critical action. If this was on the corporate network, the company’s firewall would have likely prevented this exploit. However, because it was a remote user’s computer, there was no such protection. One way to detect and block this activity off the corporate network is by using secure web gateway (SWG) with a firewall-as-a-service (FWaaS) and intrusion prevention system (IPS). Because the exploit used a known vulnerability, a firewall with an intrusion prevention system (IPS) would have been able to block any attempts to exploit the vulnerability.
In addition, most malware – such as the keylogger in this instance – involve communicating with a command-and-control server over DNS. A DNS security solution can detect command-and-control activity and block it at the DNS level, regardless of whether the user is remote or not. Even if the attacker managed to circumvent protections and install the malware, it would not have been able to receive instructions from the command-and-control servers.
Public cloud threat detection
When attacks impact public cloud environments – such as the Amazon S3 buckets that were targeted in this attack – threat activity can be detected using a public cloud threat detection platform, such as Cisco Secure Cloud Analytics. These solutions consume native logs from public cloud environments to identify anomalous and malicious activity, such as a user logging in from two different locations in a short period of time or a user downloading an unusually large amount of data from the environment, both of which happened in this attack.
While this isn’t directly related to protecting remote workers, it does protect the resource the attacker is targeting. It is important to enact security controls across the entire attack surface, including user machines and infrastructure.
Preventing other initial attack vectors
While in the case of this breach, the attacker used a vulnerable media server to take over the targeted laptop, there is a wide variety of potential attack vectors that could allow an attacker to gain initial access. It is worth discussing a few here.
Phishing is a common attack vector, and more broadly, the use of stolen credentials in general is involved in most breaches, according to the 2022 Verizon Data Breach Investigations Report. DNS security and a SWG can minimize phishing by identifying and blocking malicious websites. In addition, multi-factor authentication with pin code verification can prevent a user from erroneously approving a malicious MFA request.
For highly targeted employees – such as those with deep access privileges – remote browser isolation (RBI) can prevent an attacker from using browser-based exploits. RBI provides an added layer of protection against browser-based security threats for high-risk users. It creates a surrogate browser in the cloud that visits a website on behalf of the user and renders all content safely. This prevents browser-based threats from exploiting the end user’s browser.
These security measures work whether the user is remote or accessing the network from a branch office or corporate headquarters.
Improve security for your remote workers
Hybrid work is a common feature of today’s workplaces, and modern security teams need the right technology and processes in place to protect remote workers. This breach provides us with a real-world model of how attackers can target high-value users at home to gain access to sensitive corporate resources.
Security Service Edge (SSE) solutions provide organizations with secure connectivity for their hybrid workforce as they access the internet, cloud services, and applications, while protecting corporate resources from cyberattacks and sensitive data loss. Cisco SSE solutions utilize resilient cloud services that deliver industry-leading security efficacy and performance. Multiple third parties regularly validate the value, such as Forrester research showing that Cisco SSE customers realized a 231% in ROI in three years. With multiple deployment options, Cisco helps organizations improve security at their pace, smoothly transitioning from on-premises security to cloud security, expanding to SSE and optionally, evolving toward a SASE architecture.
Learn more about how Cisco Secure Service Edge can protection your remote and hybrid users.
We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!
Cisco Secure Social Channels
Instagram
Facebook
Twitter
LinkedIn
CONNECT WITH US