return
After the COVID-19 pandemic, a survey conducted in 2023 by Global Workplace Analytics (GWA) revealed that 8% of employees with a contract-based employment in Latin America work entirely from their homes. While this number might seem insignificant to those of us in tech-related fields, it represents a significant increase from the pre-pandemic period when only 3% of employees worked in a home-office dynamic. The consultancy McKinsey & Company disclosed that 70% of companies in the region plan to continue offering remote work options to their employees. Likewise, the Inter-American Development Bank (IDB) concluded that the number of remote workers in Latin America is expected to grow by 50% over the next five years. This new dynamic and labor market trends encourage companies and employers to include as a differentiator in their proposals incentives for these positions, offering equipment such as notebooks, PCs, and mobile phones, as well as peripheral kits including keyboards, mice, microphones, and webcams. In some cases, they even offer vouchers to "equip" an office in an unused space of the candidates' homes.
The latest metrics from Statcounter indicate that approximately 86% of the population in the region uses Windows as their default operating system (OS). This suggests a high likelihood, or almost confirms, that it is the preferred operating system for remote work.
Considering this information, various government entities have launched awareness campaigns for both employees and employers regarding cybersecurity. We quote directly from Cert.ar in their guide 'Recommendations for Telework' the following paragraph:
Among various recommendations, they also suggest some key points relevant for this post:
If the device belongs to your employer:
• Protect it in public places. It should always be under your supervision.
• Do not allow anyone to use it except for you, even if they are work colleagues.
• Do not install unnecessary software or download unnecessary files.
• Avoid personal tasks on this device, such as accessing “home banking” or browsing unknown sites.
• Refrain from using public or insecure networks for connection.
• Safeguard your work's information. It's truly vital, and not protecting it can harm you, your employer, and others interacting with the entity.
If you are a technical manager within the organization:
• Enable remote access to your organization's IT network through a secure channel (e.g., VPN) and only for those employees who need it.
• Regularly back up critical information.
• Define procedures and a communication channel for remote employees to report any support, anomalous, or suspicious situations.
• Increase security event monitoring levels, for example, failed login attempts followed by successful ones, access with the same user from multiple IP addresses, identification of suspicious network traffic, and connections from unusual locations or countries.
• Limit remote access only to permitted services and properly isolated zones within the network.
• Require two-factor authentication wherever possible.
• Review the capacity of links and monitor them consistently to ensure service continuity, as remote work can overload internet connections.
• Ensure personal devices have disk encryption and apply controls to prevent data leakage.
• Check controls on remote devices related to antivirus, operating systems, updates, security settings, etc.
Hypothetical Case
Now, let's imagine we secure a job that offers a home-office dynamic, and we are provided with a notebook for our daily tasks. Based on the information mentioned earlier, there's a high likelihood that this is a notebook with a Windows operating system. If we're fortunate to be part of an organization that follows security recommendations, we might feel protected against potential attacks. However, one day, we decide to work from our favorite coffee shop and end up either forgetting our device there or becoming a victim of theft. Could we answer the following questions?:
From this point on, this post will take a more technical tone. So if you're not technically inclined, focus on the initial recommendations we shared and pass this information on to the security managers in your organization. On the other hand, if you're involved in cybersecurity or simply curious about cryptography, electronics, or hardware, we invite you to continue reading.
Context
Recently, a technique known as BitLocker Bypass has been revisited at top-tier conferences and training centers. As the name suggests, it involves bypassing disk encryption done with a native application within Windows. Years ago, a group of researchers from DolosGroup, W/labs, and other researchers referenced in this post asked themselves the same questions regarding a misplaced notebook from their fleet. But before diving into their findings, let's review some concepts.
TPM
The Trusted Platform Module is a complex cryptographic chip located on our devices' motherboard. It implements a predefined set of cryptographic operations, secure key storage, and a set of platform configuration registers (PCR).
One of the TPM's advantages is its ability to release a piece of secret information after the platform's integrity has been verified. This verification is achieved by measuring each step in a boot-up process and storing the measurements in the PCR. The secret can be tied to specific PCR values, and it can only be released if the current state of the PCR matches those original values.
In short, the TPM won't expose keys unless it's in an expected boot state (the PCR registers have a specific set of values within them). This implementation means that, for instance, we couldn't boot from a live Ubuntu image and simply break the encryption with a command on the TPM. For more details, you can visit Microsoft's hardware-security tpm-fundamentals. BitLocker uses TPM to "seal" its Volume Master Key (VMK), and the key can only be exposed if the boot process hasn't been tampered with.
Typically, the TPM chip is a discrete module on the motherboard and communicates with the CPU through the Platform Controller Hub (PCH) or a south bridge. The TPM specification describes three different communication interfaces: LPC, SPI, and I2C; we'll particularly discuss one in this post. Additionally, there are two different types of TPM enclosures allowed, TSSOP-28 (on the left) and QFN-32. The latter, being almost BGA, makes it harder to connect to its pins, but with specific techniques, it's not impossible.
BitLocker
BitLocker is the native application used by Windows to encrypt drives (hard drives). Starting from Windows 10 version 1511, BitLocker employs the AES-XTS encryption algorithm to encrypt the entire volume. By default, the key length is 128 bits, but it can also be configured to use a 256-bit key. Data is encrypted using the Full Volume Encryption Key (FVEK). The FVEK, in turn, is encrypted with the Volume Master Key (VMK). The VMK is encrypted by multiple protectors.
One of these protectors is the TPM, which we discussed earlier, and another is the recovery key. All of this exists so that if an attacker gains physical access to the device, they can't boot the laptop into a live Linux distribution (or remove the drive) and access its data using forensic techniques. When BitLocker is enabled in its default configuration, no additional user interaction is required at boot. This is because the TPM chip alone is used to decrypt the VMK. The rationale behind this is that if the device is captured, and the attacker doesn't know your login password, they can't access the data, not even by removing the drive. Any modifications to the BIOS or the boot manager code will change the PCR values, and the TPM will not decrypt the VMK.
SPI Protocol
The Serial Peripheral Interface (SPI) is a synchronous serial communication protocol that supports full-duplex communication at high Clock (SCLK) frequencies. It uses the master-slave architecture, where the master device always initiates the communication. The SPI bus consists of four wires.
Multiple slave devices can be connected to the same SPI bus. However, in such a setup, each slave device requires its own SS (Slave Select) line, as depicted below.
To capture the SSX signals, one requires a logic analyzer that can simultaneously capture multiple signals based on the number of slave devices. The minimum sampling frequency depends on the speed used on the bus. The TPM standard states that it will be compatible with a range between 10 and 24 MHz. However, the standard also stipulates that faster SCLK frequencies could be supported. It's essential to note that we must use at least a sampling frequency four times faster than the speed used on the bus. Therefore, we recommend a minimum 100 MHz logic analyzer for this task, which could be somewhat costly.
Proof of Concept
The DolosGroup team received a securely pre-configured Lenovo notebook according to the organization it belonged to.
They had no prior information about this device: no test credentials, no configuration details, and the device followed many of the best practices recommended at the beginning of this post, making many known attacks infeasible.
For example:
• pcileech/DMA attacks were thwarted because the Intel VT-d BIOS setting was enabled.
• All BIOS settings were locked with a password.
• BIOS boot order was locked to prevent booting from USB or CD.
• Secureboot was enabled.
• Kon-boot'sauthentication bypass didn't work due to full disk encryption.
• LAN turtle and other responder attacks via USB Ethernet adapters yielded nothing useful.
• The SSD was fully disk encrypted (FDE) using Microsoft's BitLocker, protected via the Trusted Platform Module (TPM).
Given this situation, the team decided to execute a BitLocker Bypass by working directly on the TPM chip, in this case featuring a QFN-32 encapsulation or similar:
As we can see from the datasheet, this chip communicates with the CPU using the SPI protocol that we described earlier:
This was later confirmed with the schematic of the notebook:
As you can see, SPI is an extremely common communication protocol; nearly all mass consumer hardware uses it. Due to its simplicity, there's no encryption option for SPI. Any encryption has to be handled by the devices themselves.
Even today, BitLocker doesn't use any encrypted communication features of the TPM 2.0 standard. This means that any data coming out of the TPM does so in plain text, including the decryption key for Windows. If we can get that key, we should be able to decrypt the drive, and optimally, considering the best practices implemented on this notebook, gain access to the VPN client configuration and perhaps gain access to the organization's internal network.
Often, SPI chips share the same "bus" with other chips that implement it. It's a technique hardware designers use to simplify connections, save costs, and facilitate troubleshooting/programming. For this reason, if the TPM is BGA, it's recommended to look for another integrated component where connections are easier to make without the need to solder. In this case, it was found that the TPM shared an SPI bus with the CMOS chip, which definitely had larger pins. In fact, the CMOS chip had almost the largest pin size you can find on standard motherboards, which was an SOP-8 (also known as SOIC-8).
Just like the team of researchers mentioned earlier, and as we at BASE4 recommend, a Saleae logic analyzer was used.
An attacker with precise knowledge or prior preparation could use an SOIC-8 clip instead of individual probes, saving a significant amount of time in a real attack context.
Once the probes are connected, the notebook is powered on, and every byte of the SPI bus is recorded. Somewhere among the thousands and thousands of bits, a BitLocker decryption key was being sent. The challenge now was to find it.
Henri Nurmi's tool was used to automatically extract the key. As you can see, a screenshot from a high-level analyzer (HLA) is displayed, showing the obtained key:
Offensive Practice
Once the key is obtained, we can simply decrypt the drive by placing it in an adapter and using tools like Dislocker to decrypt the FVEK and then mount the drive. Alternatively, as recommended in such offensive/forensic practices, we can create an image of the drive to work comfortably without altering the original:
Once the image was created, steps were initiated to extract data such as password hashes, plain text, or encoded credentials, exposed confidential files, etc. As this was a PC for the POC, nothing useful was found, nor were any credentials of any kind retrieved since it wasn't a real employee's notebook with years of files.
However, the VPN client in use was identified: Palo Alto's Global Protect (GP) . This has an interesting "feature" called pre-logon tunneling:
Pre-logon is a connection method that establishes a VPN tunnel before a user logs in. The purpose of pre-logon is to authenticate the endpoint (not the user) and allow domain scripts or other tasks to run as soon as the endpoint powers on.
While this "feature" is ideal for IT teams to manage their endpoints, it's also a way to access the VPN without knowing credentials.
In theory, if we virtualized the previously created image, we could implement Event Triggered Execution: Accessibility Features, allowing VPN tunnel access without needing a credential. Assuming we'd have write access to the entire file system, we could essentially do anything, including rewriting driver files for kernel-level malware or privileged proxy DLLs to simply add accounts. But returning to the previously mentioned Mitre reference, the steps are really straightforward:
• Copy C:\Windows\System32\Utilman.exe to Utilman.exe.bak.
• Copy C:\Windows\System32\cmd.exe to Utilman.exe.
• Press Windows + U at the login screen.
With the backdoor activated, we'd just need to mount the drive. To boot a correctly encrypted Windows image in a virtual machine, one must create a custom VMDK, the specifics of which we won't delve into here (more info can be found in the references). Now, with that VMDK and the backdoor in place, we create the virtual machine, start it, and press Windows + U at the login screen.
For this to work, the VPN authentication is done through a certificate attached to the computer's account. Since each computer account has very basic privileges in Active Directory, we can run basic SMB commands within the domain. We query the domain controller for various types of domain information, such as users, groups, systems, etc. We could also enumerate and view the contents of files in internal SMB shared resources:
We could also leverage the access of this computer account as a platform to launch internal attacks and laterally move within the network. To demonstrate writable access to a server, an internal online file server was chosen. The POC entailed writing a file on that server and then reading it back to validate read/write access.
Taking the 'Scanner' action is a potent move for an attacker, e.g., LNK Attacks, Trojanized PDFs, etc. At this stage, we had gained access to the internal network, basic privileges in Active Directory, and access to internal shared files—more than enough to start compromising an entire organization from a forgotten or stolen notebook, even if it follows all the best practices.
Conclusion
To mitigate this attack, instead of relying solely on the default-configured TPM, it should be paired with one of the following items:
• TPM with PIN
• TPM with a startup key
• TPM with both a startup key and PIN
In the TPM with PIN mode, the TPM requires an additional PIN before the VMK is decrypted, as seen in the architecture diagram. Although the key can still be obtained from the bus even when the PIN is in use, the attacker must capture it at the exact moment the PIN is entered.
If unprivileged users can access the BitLocker keys or protectors, a local privilege escalation (LPE) can be executed by altering the volume's content. Thus, this attack facilitates an easy LPE. It's worth noting that the same LPE applies if users knew their recovery keys. A startup key adds another layer where the VMK can only be decrypted if both the TPM and the startup key are presented. The startup key can be stored on a removable device, such as a USB stick or a Dongle, for increased security. On the other hand, it's advisable to follow the recommendations proposed by Microsoft at the following link:
https://learn.microsoft.com/es-mx/windows/security/operating-system-security/data-protection/bitlocker/bitlocker-countermeasures
Other links of interest
1.https://earthweb.com/operating-system-market-share/
2.https://earthweb.com/tech-industry-statistics/
3.https://learn.microsoft.com/es-es/windows/security/hardware-security/tpm/switch-pcr-banks-on-tpm-2-0-devices
4.https://learn.microsoft.com/es-es/troubleshoot/windows-client/windows-security/decode-measured-boot-logs-to-track-pcr-changes
5.https://www.st.com/en/secure-mcus/st33tphf20spi.html
6.Disobey 2018 - All your encrypted computer are belong to us - Tomi Tuominen & Timo Hirvonen
