By Matt Polak, CEO of Picnic
Two weeks ago, at a closed meeting of cyber leaders focused on emerging threats, the group agreed that somewhere between “most” and “100%” of cyber incidents plaguing their organizations pivoted on social engineering. That’s no secret, of course, as social engineering is widely reported as the critical vector in more than 90% of attacks.
LAPSUS$, a hacking group with a reputation for bribery and extortion fueled by a kaleidoscope of social engineering techniques, typifies the actors in this emerging threat landscape. In the past four months, they’ve reportedly breached Microsoft, NVIDIA, Samsung, Vodafone and Ubisoft. Last week, they added Okta to the trophy case.
For the recent Okta breach, theories abound about how the specific attack chain played out, but it will be some time before those investigations yield public, validated specifics.
As experts in social engineering, we decided to answer the question ourselves—with so many ways to attack, how would we have done it? Our thoughts and findings are shared below, with some elements redacted to prevent malicious use.
How Targeted was this Social Engineering Attack?
To start, we know that Okta’s public disclosure indicates the attacker targeted a support engineer’s computer, gained access, installed software supporting remote desktop protocol (RDP) and then used that software to continue their infiltration:
“Our investigation determined that the screenshots…were taken from a Sitel support engineer’s computer upon which an attacker had obtained remote access using RDP…So while the attacker never gained access to the Okta service via account takeover, a machine that was logged into Okta was compromised and they were able to obtain screenshots and control the machine through the RDP session.”
For attackers to successfully leverage RDP, they must:
- Be able to identify the location of the target device—the IP address.
- Know that the device can support RDP—Windows devices only.
- Have knowledge that RDP is exposed—an open RDP port is not a default setting.
Let’s take a look at each of these in more detail:
How Can an Attacker Identify Target Devices to Exploit RDP?
Sophisticated attackers don’t “boil the ocean” in the hope of identifying an open port into a whale like Okta—there are 22 billion connected devices on the internet. In fact, LAPSUS$ is a group with a history of leveraging RDP in their attacks, to the point that they are openly offering cash for credentials to the employees of target organizations if RDP can be installed—quite a shortcut.
Putting aside the cultivation of an insider threat, attackers would rightly assume a company like Okta is a hard target, and that accessing it via connected third parties would be an easier path to success.
Our team regularly emulates sophisticated threat actor behaviors, so we started by mapping the relationships between Okta and different organizations, including contractors and key customers. Cyber hygiene problems are often far worse for large organizations than individuals, and our methods quickly uncovered data that would be valuable to threat actors. For example, Okta’s relationships with some suppliers are detailed here, which led us to information on Sitel / Sykes in this document. Both are examples of information that can be directly weaponized by motivated attackers.
Two killer insights from these documents:
- Sykes, a subsidiary of Sitel, provides external technical support to Okta.
- Sykes uses remote desktop protocol as a matter of policy.
This information makes an attacker’s job easier, and would be particularly interesting to a group like LAPSUS$—an RDP-reliant contractor with direct access to Okta’s systems is a perfect target.
Recon 101: Exploit Weak Operational Security Practices
With a target company identified, we ran a quick search of LinkedIn to reveal thousands of Sitel employees discussing different levels of privileged access to their customer environments. These technical support contractors are the most likely targets of attacks like the ones catching headlines today. Despite the investigation and negative publicity associated with this attack, more than a dozen Sitel employees are still discussing privileged access in the context of their work with Okta (nevermind the dozens of other companies).
Now that we have defined this group, our focus narrows to deep OSINT collection on these individuals—an area where Picnic has substantial expertise. OSINT stands for open-source intelligence, and it is the process by which disparate pieces of public information are assembled to create a clear picture of a person’s life, a company, a situation, or an organization. Suffice to say that our standard, automated reconnaissance was sufficient to craft compelling pretext-driven attacks for most of our target group.
To cast this virtual process in a slightly different light, imagine a thief casing your neighborhood. Good thieves spend weeks conducting reconnaissance to identify their targets. They walk the streets and take careful notes about houses with obscured entryways, unkempt hedges, security lights and cameras, or valuables in plain sight.
Social engineers are no different: they are essentially walking around the virtual world looking for indicators of opportunity and easy marks.
Before we explore how to go from reconnaissance to the hardware exploit, let’s recap:
- We are emulating threat actor behaviors before Okta’s breach.
- We conducted organizational reconnaissance on our target: Okta.
- We identified a contractor likely to have privileged access to the target: Sitel.
- We narrowed the scope to identify people within Sitel who could be good targets.
- We further narrowed our focus to a select group of people that appear to be easy targets based on their personal digital footprints.
All of this has been done using OSINT. The next steps in the process are provided as hypothetical examples only. Picnic did not actively engage any of the identified Sitel targets via the techniques below—that would be inappropriate and unethical without permission.
Identifying the Location of the Device for RDP Exploit
There are three ways that attackers can identify the location of a device online:
- Pixel tracking
- OSINT reconnaissance
Just as we conducted OSINT reconnaissance on people and companies, the same process is possible to identify the location of the target device. By cross-referencing multiple sources of information such as data breaches and data brokers, an attacker can identify and leverage IP addresses and physical addresses to zero in on device locations. This is always the preferred approach because there is no risk that the attacker will expose their actions.
Pixel tracking is a common attacker (and marketer!) technique to know when, and importantly where, an email has been opened. For the attacker, this is an easy way to identify a device location. Phishing is similar to pixel tracking: a clicked link can provide an attacker with valuable device and location intelligence, but pixel tracking only requires that an image be viewed in an email client. No clicks necessary.
Pixel tracking and phishing are examples of technical reconnaissance that were more easily thwarted pre-COVID, when employees were cocooned in corporate security layers. With significant portions of knowledge workers still working at home, security teams must contend with variable and amorphous attack surfaces.
For social engineers, this distribution of knowledge workers is an asymmetric advantage. Without a boundary between work-life and home-life—the available surface area on which to conduct reconnaissance and ply attacks is essentially doubled.
Social engineering’s role in the RDP exploit
According to Okta’s press release, an attacker “obtained remote access using RDP” to a computer owned by Sitel. Based on threat actor emulation conducted by our team and the typical LAPSUS$ approach, it is clear that social engineering played a key role in this attack, which was likely via a targeted spear phishing campaign, outright bribery, or similar delivery mechanism, which would have provided attackers not only with device location information needed for the RDP exploit, but also important information about the device and other security controls.
Remember that social engineers are hackers that focus on tricking people so they can defeat technical controls. Tricking people is easy when you know something personal about them—in fact, our research indicates attackers are at least 200x more likely to trick their targets when the attack leverages personal information.
The amount of time, energy, and resources required to complete this reconnaissance was significant, but it was made easier by the two key documents found during our initial recon on the target. While there are other breadcrumbs that could have led us down the same path, many of those paths offered less clear value, while these two documents essentially pointed to “easy access this way.” Finding these documents quickly and easily means that hackers are likely to prioritize this attack path over others—the easier it is, the less time and resources it consumes, and the greater the return on effort.
Key learnings for cyber defenders
Recognize you are at war. Make no mistake about it, we are in a war that is being fought in cyberspace, and unfortunately companies like Okta and Sitel are collateral damage. Just as in a hot war, one of the most successful methods for countering insurgent attacks is to “turn the map around” to see your defenses from the perspective of the enemy. This outside-in way of thinking offers critical differentiation in the security-strategy development process, where we desperately need to change the paradigm and take proactive measures to stop attacks before they happen. I wrote another short article about how to think like an attacker that might be helpful if you are new to this approach.
Be proactive and use MITRE—all of it. The prevailing method used by cyber defenders to map attacker techniques and reduce risk is called the MITRE ATT&CK framework. The design of the framework maps fourteen stages of an attack from the start (aptly called Reconnaissance) through its end (called Impact)—our team emulated attacker behaviors during the reconnaissance stage of the attack in this example. Cyber defenders are skilled at reacting to incidents mainly because legacy technologies are reactive in nature. MITRE recommends a proactive approach to remediating the reconnaissance stage to “limit or remove information” harvested by hackers. Defenders have an opportunity to be proactive and leverage new technologies that expand visibility and proactive remediation beyond the corporate firewall into the first stage of an attack. Curtailing hacker reconnaissance by removing the data hackers need to plan and launch their attack is the best practice according to MITRE.
Get ahead of regulations. Federal regulators are also coming upstream of the attack and have signaled a shift with new SEC disclosure guidance, which requires companies to disclose cybersecurity incidents sooner. Specifically, one key aspect of the new rule touches on “…whether the [company] has remediated or is currently remediating the incident.” New technologies that emulate threat actor reconnaissance can make cyber defenders proactive protectors of an organization’s employees, contractors, and customers long before problems escalate to front page news. These new technologies allow companies to remediate risk at the reconnaissance stage of the attack—an entirely new technology advantage for cyber defenders.
Every single attack begins with research. Removing the data that hackers need to connect their attack plans to their human targets is the first and best step for companies who want to avoid costly breaches, damaging headlines, and stock price shocks.