Insider Threat Programs Can Sniff Out Malicious Firmware

Last month, security researcher Mickey Shkatov posted a video demonstrating how he was able to install malicious firmware on a device in fewer than four minutes. Commonly known as an evil maid attack, such an attack is based on a scenario where someone breaks into a hotel room to gain physical access to a laptop left behind. Naturally, this type of attack isn’t limited to hotel rooms; it could happen anywhere.

On the surface, malicious firmware doesn’t really seem to be within the purview of an insider threat program (ITP), but it most certainly is. Many assume the term insider means that the scope of an ITP is limited to a company’s employees, contractors, suppliers, or anyone else with legitimate access to company assets or infrastructure. However, an ITP is also useful for detecting people who are external to your company, but use things such as malicious firmware, for example, to access and nose around your network posing as a credentialed user.

Years ago, when I was helping to establish my first ITP, an important part of this process was building relationships between my program and stakeholders across the company. I would tell members of other teams—data loss prevention, security operations, and human resources, to name a few—that my role was not to own controls around their processes, but rather to supplement their work by serving as a secondary, detective control. Sitting between a number of groups and combining their data, I explained, would provide me with unique insights that may even help make their lives a little easier and the company a little more secure.

These unique insights are exactly why malicious firmware and related threats should be within the scope of your ITP. The evil maid attack demonstrates how an ITP can be particularly useful for keeping devices secure during travel. For example, if a traveling user’s device is infected with malicious firmware, the attacker could then use the device to connect to your company’s network, harvest credentials and other data stored on the device for later use, and/or install malicious functionality that could lay dormant in the short-term before inflicting substantial damage later on.

The good news is that providing your ITP with visibility into your company’s travel policies, post-travel monitoring processes, and related datasets can help your company effectively combat malicious firmware infections, evil maid attacks, and similar threats. Here are a few examples that illustrate this concept:

Many companies aim to protect company-issued devices from malicious firmware infections by restricting or prohibiting device usage during travel, but such policies aren’t foolproof. When I was leading an ITP in the financial industry, I once observed a user who appeared to be located in China checking email from a company-issued laptop. At the time, this company had no employees located in China, no employees traveling in China for business purposes, and a policy that prohibited employees from bringing company-issued devices on vacation.

As a result, the company was quick to assume that a Chinese threat actor had penetrated the network. But because this company had previously provided its ITP, and therefore me, with visibility into travel-related and similar datasets, I was able to confirm that the user in question was not a Chinese threat actor, but rather an employee vacationing in China who was simply unaware of the travel policy.

Furthermore, many companies also block IP addresses from countries deemed high-risk, but this measure won’t prevent users—or, in the case of an evil maid attack, malicious actors with physical access to a user’s device—from accessing the company VPN while traveling in high-risk countries. VPNs obscure users’ locations, and although VPN administrators generally have access to data that includes VPN users’ identification, they are unlikely to have the demographic data necessary to identify VPN connections that occur from high-risk locations or are otherwise suspicious.

But in most cases, an ITP will have access to such demographic data, which, when combined with VPN data, can enable the ITP to identify VPN connections from countries that are foreign to the user. In fact, several years ago, I was asked to demonstrate this capability firsthand in order to justify the need for integrating VPN data into the company’s ITP. My demo revealed 12 different users with recent VPN sessions on unapproved devices from countries that were foreign to them. Needless to say, the company agreed to provide my team with access to VPN data moving forward.

There are a number of additional ways in which VPN data can reveal invaluable indicators when integrated with an ITP. In particular, it can identify concurrent logins that occur from geographically dispersed locations. This type of indicator could point to an outsider who accessed the network using credentials stolen from a legitimate user’s device during an evil maid attack, for example. Other datasets such as domestic traffic, atypical logins based on time or day, or unusual IP addresses can also help an ITP identify additional useful indicators. False positives, however, are not uncommon within any dataset, which is why it’s important for your ITP to evaluate the context and relevance of every resulting indicator and be prepared to triage accordingly.

Each example I described above underscores that in order to be truly effective, an ITP needs to be integrated with as many datasets and business functions as possible throughout an organization. And while my examples highlight the value of an ITP in the context of malicious firmware and travel-related security issues, you can apply the same basic principles to support countless other use cases across the enterprise.

But, before you set out to do that, be prepared to encounter what has become a difficult reality for many ITP practitioners. In most cases, integrating additional datasets into your ITP framework is fairly straightforward. Your biggest challenges, however, will likely stem from the bureaucratic and often siloed structure of many corporate environments. Obtaining the permissions, resources, and staffing you’ll need may feel like an uphill battle. This is why it’s so important to have patience, be collaborative, and clearly communicate the value that a new dataset will bring to your ITP, the data owners, and the company as a whole. And above all else, keep an open mind—remember that an effective ITP is always developing and never truly complete.