Rethinking BYOD Access

How personal device attacks often work

When an employee uses a personal device to access corporate SaaS applications – such as email, file storage, or collaboration tool – any malware present on that device can intercept credentials, session cookies, or authentication tokens.

Rather than breaching corporate infrastructure directly, the attacker inherits the user’s authenticated access. This allows them to operate within enterprise systems as a legitimate user, accessing sensitive data and expanding their reach across connected applications.

A high-level attack diagram

Two recent incidents have shown how personal‑device compromises can cross into corporate environments. In one case, infostealer logs linked to a HungerRush employee’s personal device reportedly exposed credentials. In another, a developer unknowingly transferred a malicious file from a personal device to a corporate laptop via AirDrop, creating a backdoor later used for large‑scale cryptocurrency theft.

These cases illustrate how BYOD habits can silently smuggle malware into trusted systems, even without mobile RATs or direct device exploitation.

Recent Examples: ALBIRIOX

Infostealer malware can infect an employee’s devices before or after they join the organisation, and JUMPSEC has recently observed an uptick in commercial android malware sold on the dark web with C2 and infostealer capabilities.

Threat actors are constantly developing and selling new Malware as a Service (MaaS) that specifically targets mobile devices, allowing threat actors to setup and build malicious mobile applications with ease.

While mobile threats are often defined by high-profile spyware campaigns (e.g., Pegasus, Predator), there is sustained growth in financially motivated malware focused on credential theft, session interception, and scalable access. The graphic below charts notable mobile malware from 2024-2026.

JUMPSEC have analysed a recent example, ALBIRIOX, an Android-focused Remote Access Trojan (RAT) that poses a threat to organisations operating cloud/SaaS environments where employees access corporate resources and files from personal mobile devices.

While the malwares’ primary function and goal is cryptocurrency theft and other fraud, it has other core capabilities such as real-time screen surveillance, live keylogging, credential phishing HTML overlays, device PIN capture, notification/SMS interception, and full remote device control/filesystem access.

The central risk with this malware is that a singular compromised personal mobile device provides an attacker with persistent access into cloud applications. The attacker does not need to compromise an organisations infrastructure, they do not need to bypass MFA, SSO, or Zero Trust policies, as the malware operates downstream of all authentications.

Common infection paths

Malware can be installed from many different sources. Two of the most common methods are spear-phishing via WhatsApp or Email, wherein the threat actor will share a malicious .APK application with the victim with a convincing social engineering pretext to install the application.

The other method is uploading a legitimate app with legitimate functionality to the Google Play Store, this could be something like a Free VPN app, or a PDF Reader/Editor, then the threat actor boosts fake downloads and gains credibility, and final pushes a malicious update to the application, infecting all devices which currently have the app installed.

As below, Joker Android botnet uploads trojanized Android apps to the Google Play Store after its 2024 resurfacing, with a total of 51,000+ installations. These aren’t obscure apps no one will ever see – they are highly downloaded, and can easily appear legit given the fake ratings and reviews aided by botting.

Which app above is Joker malware? Unfortunately, all of them. Security controls are an issue with the Play Store.

There are constant risks on employee devices. This ranges from drive by downloads on adware sites, malvertising campaigns that exploit stolen Google Ads accounts with malicious landing pages, and third-party App Stores with embedded malware embedded. In conjunction with a malicious Google Play Store app, threat actors could change a drive-by download link to instead redirect to the malicious app on the Google Play Store.

Online channels within messengers advertise “modded” APKs, for example a “Modded Spotify” which boasts “more Premium features than the official Spotify Premium”, but these have proven to be trojan-style Android malware loader malware.

While you may trust your security instincts to avoid such spurious offers, it is not advisable to afford every BYOD-enabled employee the same trust. The aesthetics are relatively convincing replicas, and with AI-generated graphics, these will only become more realistic.

Why Android introduces additional risk

Platform usage influences how likely compromise is, but not the impact once compromise occurs.

On Android phones, users can install APK files from arbitrary sources, this means that attackers can target employees’ personal devices with trojanized APK applications that are distributed via phishing. Users can also accidentally install malware from the Google Play Store that is at first, legitimate, but delayed malicious updates can be introduced after an app gains trust. These apps can be disguised as anything from a VPN app to a PDF reader/editor or QR Code scanner.

As below, malware on the google play store with 10+ Million downloads. According to sources, the “Wuta Camera” app was a compromised update version which loaded the Necro Android Trojan. Because Android allows this sideloading an alternative app stores, device compromise can occur without exploiting vulnerabilities in the operating system or kernel.

The bottom line with Android devices is that the risk is controllable. If organisations incorporate modern Android Enterprise controls, then most mobile malware risk shifts primarily from opportunistic infection to policy failure or misconfiguration.

Android Enterprise can, for example, disable sideloading/unknown sources, force Google Play Protect, and mandate OS updates, moving the risk from malware to things like phishing, supply-chain compromise, or zero-day exploits. But naturally, for a BYOD organisation, no such controls are possible.

Why iOS is better but not fully secure

iOS presents a more restricted attack surface than Android, as it does not allow application installation from arbitrary sources and enforces stricter app review controls. This reduces exposure to opportunistic malware, particularly in unmanaged environments.

However, compromise is still possible. One of the primary infection vectors is the use of malicious Mobile Device Management (MDM) or configuration profiles. These can be installed via social engineering and allow attackers to deploy untrusted applications, route traffic through controlled infrastructure, and modify device settings.

Campaigns such as “GoldPickaxe” demonstrate how attackers can combine these techniques with credential and biometric data harvesting, as well as SMS interception, to bypass identity verification processes. While these attack paths are less common than Android malware, they highlight that iOS reduces the likelihood of compromise, but not the impact once a device is trusted.

Regardless of platform, a compromised device results in the same outcome of authenticated access to enterprise systems. However, route to compromise and level of prevalence can materially differ between Android and iOS, particularly in BYOD environments where security controls are limited.

In addition to the risk of initial access, allowing BYOD also introduces a potential control circumvention risk via rogue device enrolment. Policies typically restrict sensitive enterprise data access for PCs via manufacturer‑bound identifiers (serial numbers, IDs). But mobile devices are often observed in our offensive engagements to be auto approved/enrolled due to identity misconfiguration or platform restrictions – but ultimately because of an employee’s privacy rights over their personal device.

Internal device enrolment attack risk – adapted from real attack path traversed in a red team engagement

Cloud native and hybrid considerations

In cloud native or hybrid corporate environments, BYOD can introduce cloud breach risks even without direct device compromise, as the organisation cannot assert device trust. Threat actors can gain access into enterprise systems if a user is phished through their work email on a personal device, and one of multiple scenarios could occur:

• Corporate credentials/sensitive files/keys may be stolen
• MFA fatigue attacks may occur
• OAuth tokens and session cookies may be stolen, providing access to the employee account without requiring the password.

Once valid credentials or session tokens are obtained, attackers can:

• Access sensitive platforms (cloud systems, CRM systems, HR, SharePoint, etc)
• Escalate privileges for further compromise
• Move laterally across cloud infrastructure

This comes from the underlying assumption that ‘company-managed devices’ are meant to have all the vetting, monitoring and extensive security controls one would expect from a corporate PC.

However, if BYOD is allowed without device pre-registration this essentially means that the attacker could phish someone in the organisation and get their rogue device ‘managed’ or even ‘compliant’ (in either Entra/M365 or Google MDM) without any meaningful defensive capability or telemetry on the rogue device.

This could mean a substantial amount of a real-world attack, or a red team engagement, can be conducted on an iPhone – as our adversary simulation team have discovered. If an attacker’s device can pass firmly inside your trust boundary with no oversight, BYOD assumptions need to be challenged.

There are several low/no-cost mitigations to improve compliance and reduce the risk of unmanaged employee devices.

Both external malware and internal enrolment weaknesses should trigger fundamental policy discussions:

• Is BYOD actually essential? For many organisations, BYOD creates more risk than it solves, especially for roles with high privilege (admins, finance, engineering, executives). Alternatives include restricting BYOD, providing corporate devices, or limiting mobile access to low‑risk functions only.
• If you need personal / mobile devices, which platform should you trust? As detailed, Android BYOD is a high inherent risk. Sideloading, third‑party stores, and lax app vetting expand the attack surface dramatically. iOS is better baseline security and fewer routes to compromise. For corporate fleets, iOS is the safer default.
• Who genuinely needs personal device access? Not all staff require access to corporate systems from a mobile device. Limiting access based on role significantly reduces blast radius.
• Could a compromised personal device realistically cause a breach? Modern RATs like ALBIRIOX can harvest credentials, intercept MFA, and hijack SaaS sessions, granting attackers persistent access without needing to breach the corporate network. This applies to cloud native or hybrid organisation in particular.
• Are your enrolment workflows resilient against manipulation? Weak device‑approval flows enable attackers to escalate privileges by enrolling rogue devices as ‘trusted’. These pathways should be tested and validated regularly.

2. Strengthen enterprise Mobile Device Management (MDM)

Improving device enrolment hygiene significantly reduces the likelihood of attackers inserting rogue devices into the environment. Key measures include:

• Pre‑registration of devices. Ensure only known serial numbers/IMEIs are allowed to enrol, preventing disposable or spoofed attacker devices from being automatically trusted.
• Stronger identity verification during enrolment. Require robust identity checks before a device becomes “managed.” Weak identity-to-device binding is one of the most common flaws JUMPSEC observes during red team engagements.
• Mandatory security posture checks. Devices should prove they meet minimum OS version, patch, encryption, and integrity requirements before accessing sensitive systems. This is largely impossible in true BYOD environments.
• Block auto‑approval pathways. Default or legacy MDM settings can automatically approve mobile devices, even when identity configuration is weak. These flows should be reviewed and hardened

Realistically, many organisations view employee device policy in three ways: cost, compliance, and convenience.

While address employee device risk may be temporarily inconvenient – the low/no-cost mitigations above will improve compliance and reduce the risk of increasingly prevalent cloud-based cyber attacks.

• https://www.proofpoint.com/uk/blog/cloud-security/community-alert-ongoing-malicious-campaign-impacting-azure-cloud-environments
• https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft
• https://www.bleepingcomputer.com/news/security/hacker-mass-mails-hungerrush-extortion-emails-to-restaurant-patrons/
• https://www.linkedin.com/posts/alon-gal-utb_im-investigating-a-machine-belonging-to-ugcPost-7434887636277907456-0o5u/
• https://www.quickheal.com/blogs/google-play-store-applications-laced-with-joker-malware-yet-again/)
• https://www.kaspersky.co.uk/blog/necro-infects-android-users/28199/)
• https://www.group-ib.com/blog/goldfactory-ios-trojan/