From pocket to Pwn: How we hacked a multinational Corp for $200 with what's in our pockets

From pocket to Pwn: How we hacked a multinational Corp for $200 with what's in our pockets

Speakers: Tim Shipp, CTO and Co-founder, Threat

Conference: BSides SF

YouTube: https://www.youtube.com/watch?v=P6K3R9mUSsg

Overview

In this compelling talk at BSides SF, Tim Shipp, CTO and co-founder of Threat, unveiled a low-cost, high-impact attack vector that leveraged everyday items and overlooked security gaps to compromise a multinational corporation. Titled "From pocket to Pwn: How we hacked a multinational Corp for $200 with what's in our pockets," Shipp detailed a red team engagement where traditional methods failed against a highly resilient target. The team pivoted their focus to mobile devices, specifically targeting developers using their personal Android phones, exploiting common oversights in bring-your-own-device (BYOD) policies and the surprisingly accessible Android developer ecosystem.

Shipp's presentation highlighted how an attacker, with minimal financial investment (as little as $100-$200) and readily available tools, could establish persistent access to a developer's personal mobile device and subsequently pivot into the corporate network. The methodology involved an ingenious combination of Bluetooth jamming, masquerading as trusted devices, and leveraging the Android Debug Bridge (ADB) for remote control. This talk is critically important for organizations, particularly those with developers or a BYOD culture, as it exposes a significant, often unmonitored, attack surface that traditional endpoint detection and response (EDR) solutions may miss.

Background

▶ Watch: Introduction and legal disclaimer about Bluetooth jamming (0:00)

The genesis of this unconventional attack stemmed from a long-standing red team engagement with a customer known for their robust security posture. Previous attempts using conventional tactics like spear phishing, dead drops, local approaches, and smishing had been consistently thwarted. The client's security operations center (SOC) was exceptionally efficient, mitigating any dropped binaries within minutes. This forced Shipp's team to think "outside of the box" and provide "extra value" beyond standard symmetrical testing.

The target company, a late-stage startup, possessed its own internal development teams, including a dedicated Android and mobile application development unit. A crucial vulnerability identified was the widespread use of personal mobile devices for corporate tasks, including multi-factor authentication (MFA) and application testing, due to a poor BYOD policy. These personal devices were not subject to corporate monitoring or EDR solutions, creating an unacknowledged blind spot. The red team's objective shifted from direct network compromise to passive targeting of these developers, observing their routines and identifying potential avenues for device compromise using "what's in our pockets." Initial observations noted rampant Bluetooth device usage (headsets, mice, keyboards) and a unique company car scheme providing employees with electric vehicles, specifically a brand that "rhymes with Tesla," which became a key component of the attack chain.

Key Findings

▶ Watch: The red team challenge: traditional methods failed (3:20)

The talk revealed several critical findings that collectively demonstrated a potent and low-cost attack methodology:

1. Low-Cost Tool Effectiveness: The red team successfully utilized inexpensive hardware, such as Cardputers ($25 each) and nrf24 dongles, in conjunction with a Flipper Zero, to perform sophisticated Bluetooth denial-of-service and masquerading attacks. This proved that significant budget is not a prerequisite for advanced attacks.
2. Android Developer Program Loophole: A significant discovery was the ability to register as an official Android developer for a one-time fee of $25. This allowed for the creation and distribution of seemingly legitimate applications, which could then be used to push malicious payloads to beta testers (without their explicit knowledge) or even to replace the "guts" of an approved application on the app store, facilitating payload delivery and bypassing standard app store review processes.
3. USB Rubber Ducky over Bluetooth: The team effectively implemented the classic USB Rubber Ducky attack vector, traditionally requiring physical USB access, over a Bluetooth connection. By masquerading as a trusted Bluetooth device (e.g., a car's infotainment system), the attacker could trick a user's phone into connecting, then automatically execute a series of commands as if a keyboard were typing them, leading to a Metasploit shell.
4. Achieving Persistence on Android 13+: Despite Android's improved security features (from Android 13 onwards) that aggressively kill outbound activity from applications (typically within 1-5 minutes), the red team developed a method to achieve persistent remote access. This involved leveraging the initial Metasploit shell to set SELinux to permissive mode (setenforce 0), install Termux as a service, and establish a reverse SSH tunnel back to an attacker-controlled server (e.g., in AWS). This effectively provided remote Android Debug Bridge (ADB) access to the device until a reboot.
5. Pivoting from Mobile to Corporate Network: Once persistent access was established on the developer's personal Android device, the team demonstrated the ability to use the device as a pivot point. Utilizing tools like sock proxy, Nmap, and BloodHound, they enumerated the corporate Windows domain and moved laterally within the network, proving that unmonitored personal devices can serve as critical initial access points for broader enterprise compromise.

Technical Deep Dive

▶ Watch: Targeting mobile developers via BYOD personal devices (4:00)

The attack commenced with passive targeting of developers to understand their routines. The team identified that many developers drove electric vehicles (EVs) from a specific manufacturer, which handily provided online service manuals. These manuals revealed the location of two Bluetooth modules: one under the front badge and one under the rear badge. The plan was to exploit this.

The initial phase involved Bluetooth jamming and masquerading. The attackers used two Cardputers (or one Cardputer and a Flipper Zero for demonstration purposes), equipped with nrf24 dongles, positioned magnetically on the target EV. One device would perform Bluetooth denial-of-service (jamming) against the car's modules, preventing the user's phone from connecting to their vehicle. Simultaneously, the other device would masquerade as the car's Bluetooth system. When the developer attempted to connect their phone to the car for media playback (e.g., Spotify), they would inadvertently connect to the attacker's device.

Upon connection, the core of the exploit leveraged the USB Rubber Ducky over Bluetooth concept. This technique, available since 2010, allows an attacker to inject keystrokes and commands into a target device as if a human were typing rapidly. The Flipper Zero or Cardputer, once connected, would automatically execute a pre-programmed script. This script would download and execute a malicious payload, typically an Android application package (APK), designed to establish a Metasploit shell.

However, a significant challenge arose with modern Android versions (13 and above). Android's security features are designed to aggressively terminate background processes and outbound network connections from non-system applications, leading to the Metasploit shell being killed within approximately 5 minutes. This severely limited the utility of the initial compromise.

To overcome this, the team developed a persistence mechanism. Immediately upon gaining the short-lived Metasploit shell, the exploit would perform several critical actions:

1. SELinux Permissive Mode: The first step was to execute setenforce 0 to set SELinux (Security-Enhanced Linux), Android's mandatory access control system, to permissive mode. This reduced restrictions on subsequent actions. While this required the device to be rooted or for the user to be a developer with elevated permissions (as was the case in this scenario), it was a crucial enabler.
2. Termux Installation and Service: The exploit would then remotely install Termux, a powerful terminal emulator and Linux environment for Android. Termux was configured to run as a service, providing a persistent environment that Android's default process killer was less likely to terminate.
3. Reverse SSH Tunnel: From Termux, a reverse SSH tunnel was established back to an attacker-controlled server (e.g., an AWS instance). This encrypted tunnel provided a stable, long-term communication channel.
4. Remote ADB Access: Crucially, this reverse SSH tunnel effectively granted the attackers remote Android Debug Bridge (ADB) access to the device. ADB is a versatile command-line tool used by developers to communicate with an Android device. With remote ADB, the attackers could execute arbitrary shell commands, manage files, install/uninstall applications, and control various device settings. This persistent access remained active until the device was rebooted.

Further enhancing the post-exploitation capabilities, the team used specific ADB commands to maintain control and usability:

• adb shell settings put global stay_on_while_plugged_in 7: Prevents the screen from turning off.
• adb shell input keyevent 26: Wakes the device screen.
• adb shell wm dismiss-keyguard: Dismisses the lock screen.
• adb shell settings put secure lockscreen_disabled 1: Completely disables the lock screen.

With persistent ADB access, the attackers could leverage tools like scrcpy (pronounced "screen copy") for remote desktop-like control of the Android device, providing a graphical interface in addition to the command line. Although scrcpy couldn't bypass the security feature that blacks out the screen during PIN entry, it offered significant situational awareness.

Finally, the compromised developer device became a pivot point for lateral movement into the corporate network. Using sock proxy over the established reverse tunnel, the attackers could route network traffic through the developer's phone. This allowed them to deploy standard enumeration and reconnaissance tools like Nmap to map the network and BloodHound to analyze the Windows Active Directory domain, leveraging the device's connection to the corporate Wi-Fi or even its mobile data network (GSM/3G). This lateral movement, originating from an unmonitored personal device, allowed the red team to gain unexpected deep access into the multinational corporation's environment.

Demo / Proof of Concept

▶ Watch: Hacking company EVs by jamming their Bluetooth (5:50)

Tim Shipp provided a brief, yet impactful, demonstration of the USB Rubber Ducky over Bluetooth attack using a Flipper Zero. The demonstration highlighted the speed and automation of the exploit.

The Flipper Zero was configured with the "bad USB traffic" module enabled, essentially turning it into a Bluetooth HID (Human Interface Device) keyboard. When a target Android device connected to the Flipper Zero (masquerading as a trusted device), the attack sequence was initiated. The video, though "massively slowed down" for presentation clarity, showed the automatic connection, followed by the rapid execution of a pre-defined payload. This payload, injected as if a user was typing at incredible speed, downloaded and executed the malicious APK. The demonstration concluded with a successful Metasploit shell being established on the target Android device, illustrating the immediate compromise potential once the Bluetooth connection was made. This proof of concept effectively showcased the initial access vector that paved the way for the more advanced persistence and lateral movement techniques.

Defensive Implications

▶ Watch: Introducing the cheap Cardputers for Bluetooth attacks (6:30)

This talk underscores several critical areas where organizations, particularly those with a strong BYOD culture or a developer workforce, need to enhance their defensive posture:

1. Overhaul BYOD Policies and Enforcement: The most immediate implication is the necessity for a robust and strictly enforced BYOD policy. Organizations must clarify what devices can connect to the corporate network, what applications are allowed, and what security measures (e.g., mobile device management/MDM, mobile application management/MAM) are required. The ideal scenario, especially for developers handling sensitive intellectual property or production environment access, is to provide dedicated, company-owned, and fully managed devices, enforcing a clear "separation of church and state" between personal and professional usage.
2. Enhanced Mobile Device Monitoring: Traditional EDR solutions often focus on laptops and servers, leaving mobile devices unmonitored. This talk highlights the urgent need to extend protective monitoring to mobile endpoints. This means ingesting logs from mobile devices into SIEM (Security Information and Event Management) and XDR (Extended Detection and Response) platforms. Defenders should look for anomalous outbound connections, unusual application installations (especially non-App Store/Play Store apps), unexpected shell activity, or attempts to modify system settings like SELinux or screen locks.
3. Update Risk Registers: Mobile devices, especially personal ones used for corporate access, must be explicitly added to an organization's risk register as a significant attack vector. Security teams need to assess the specific threats posed by mobile compromise, including data exfiltration, lateral movement, and credential theft.
4. Developer Security Awareness and Device Provisioning: Developers are often targeted due to their elevated access and the sensitive nature of their work. Providing them with dedicated, patched, and secured development phones that are strictly segregated from personal use is paramount. Furthermore, training developers on the risks of connecting to unknown Bluetooth devices, installing unvetted applications, and the potential for social engineering is crucial.
5. Bluetooth Security Practices: Users should be educated about the risks of automatically pairing with unknown Bluetooth devices. Organizations might consider policies around Bluetooth usage in sensitive areas or for critical corporate devices. Monitoring for unusual Bluetooth pairing events on corporate networks could also be a proactive measure.
6. Review Android Developer Program Usage: While the $25 developer registration is a legitimate feature, organizations should be aware of its potential for abuse. Monitoring for suspicious or unauthorized developer accounts associated with their domain, or unexpected beta program invitations, could be beneficial, though challenging to implement at scale.
7. Network Segmentation and Least Privilege: Even if a mobile device is compromised, strong network segmentation can limit an attacker's lateral movement. Applying least privilege principles to developer accounts and network access ensures that a compromise of one device does not immediately grant access to critical production systems.

Key Takeaways

• Low-cost attacks are highly effective: Sophisticated compromises don't require expensive tools; readily available hardware like Cardputers and Flipper Zeros can be used for impactful attacks.
• BYOD policies are critical attack surfaces: Unmonitored personal mobile devices, especially those used by developers, represent a significant and often overlooked entry point into corporate networks.
• Android developer program loophole: The $25 Android developer registration can be abused to bypass app store security controls for malicious payload delivery.
• Bluetooth-based rubber ducky attacks are potent: Leveraging Bluetooth for HID attacks allows for automatic payload execution without physical USB access, rapidly compromising devices upon connection.
• Persistence on modern Android is achievable: Despite Android's security enhancements, techniques involving SELinux modification, Termux, and reverse SSH tunnels can grant persistent remote ADB access.
• Mobile devices enable lateral movement: A compromised mobile device can serve as an effective pivot point for enumerating and moving laterally within a corporate network, leveraging tools like sock proxy, Nmap, and BloodHound.

About the Speaker(s)

Tim Shipp is the CTO and co-founder of Threat, an agentic instant response platform specializing in instant response (IR) and XDR. With over 20 years of experience, Tim has built and led numerous IR teams, conducting around 200 investigations throughout his career. Beyond his civilian role, he serves as a Major in the British Armed Forces cyber reserves, engaging in international cyber operations, including recent work in Singapore and with the US government. His extensive background includes roles at prominent cybersecurity and technology firms such as Ascentia, CyberReason, Semantic, Airbus, and Thales. Shipp's journey into security began unconventionally in 2007 at Matsushita Electric Company (Panasonic), where he was tasked with "breaking" early Android phones to understand their vulnerabilities, leading to him being flown to Japan to explain how he managed to run Doom and Day of the Tentacle on their flagship device before its official release. This unique experience in early mobile hacking has clearly informed his current insights into mobile device security.