On the audit of the mobile arsenal of fintech companies from the top 30, we found the iPhone of the CFO, who for three weeks leaked the microphone records on the C2-server via HTTPS. At the same time, Intune cheerfully reported "compliant": encryption is actively installed, PIN is installed, iOS is fresh. Network monitoring hooked the anomaly by chance - the device daily resolved 12-15 domains registered less than a week ago, and unloaded 8-15 MB of data in the interval 02:00-04:00. MDM didn't say a word about that.
This gap between the compliance status and the real compromise is exactly what commercial spyware exploits by design. And if your SOC relies only on MDM, you have a blind spot the size of the entire mobile arsenal.
Business Logic of Attack: Why Mobile Spyware Is Targeting a Corporate Environment
Mobile phone of the top manager - the point of concentration of everything valuable: correspondence in messengers, voice conversations, corporate mail documents, VPN-credentials. Commercial spy instruments (peace and less public analogues of NSO Group, Predator and less public analogues) are designed to covertly extract these data.
The financial impact goes beyond direct losses from the leak of strategic plans or M&A-deals. In the Russian jurisdiction, negotiable fines for the leakage of personal data for 152-FZ reach 3% of annual revenue. Compromise of a mobile device with access to corporate systems is a direct path to such a scenario.
A separate vector is an insider threat. Stalkerware and commercial spy apps can install an employee with physical access to the victim’s device: a colleague, a contractor, a service center employee. Unlike zero-click exploits, this vector does not require a nation-state budget - enough unlocked device for 3-5 minutes.
Kill chain of commercial mobile spyware:
1. Initial Access - zero-click exploit via iMessage/WhatsApp or physical installation (insider). The victim does nothing.
2. Collection - implant activates Keylogging (T1056.001), Screen Capture (T1113), Audio Capture (T1123), Video Capture (T1125).
3. Stealth - Rootkit-level techniques (T1014) to hide artifacts below the OS level.
4. C2 - Encrypted Channel (T1573) via HTTPS with certificate penning.
5. Exfiltration - Exfilration Over C2 Channel (T1041) portions at night.
For SOC, the main problem here is: the entire chain works below the level that MDM sees. How exactly the guys from iVerify formulated - "MDM configuration, not compromise""MMD reflects the configuration, not a compromise".
MDM detection of spyware: why compliance is not equal to security
Microsoft Intune, Jamf Pro, Workspace ONE - what everyone sees and what everyone does not see
MDM solutions were designed to control the configuration, not to detect compromise. Here is a breakdown by vendals:
See the pattern? The bottom half of the table is complete "no". The device with the active implant Pegasus passes all compliance-checks Intune: the implant is not reflected as an installed application, not the triggers of the jailbreak-detection when using kernel-level on the exploit of the current iOS. Green tick in the console - and complete tranquility SOC.
Where MDM is useful as a data source for detection:
Inventory of the Arsenal (NIST CSF ID.AM-01) - complete visibility of the park of devices. Without it, the network detection loses the context: there is anomalous traffic, and it is impossible to bind to a particular employee. Baseline Configurations (NIST CSF DE.AE-01) - compliance policy is created by baseline, deviations from which are correlated with network anomalies in SIEM. Forced VPN - Intune (per-app VPN), Jamf Pro (Always-On VPN), Workspace ONE (Tunnel) route mobile traffic through the enterprise infrastructure, where it is already analyzed by the network monitoring.
MDM is an inventory book and control panel. Expect implant detections from it - approximately how to expect from the ACS to detect the lateral movement.
Mobile Threat Defense Solutions: Lookout, Zimperium, iVerify - trade-off
MTD expands detection beyond MDM, but each solution has its own limitations:
When the MTD is not enough: No MCD product does not guarantee the detection of fresh 0-day zero-click exploit. Commercial spavivares are designed taking into account the bypass of IoC-bases and MTD behavioral patterns. Lookout and Zimperium are good against the mass stalkerware, but against Pegasus with the actual exploit chain is a race in which the MTD vendors lag behind. Network-based detection is a mandatory second echelon.
Network-based detection of mobile threats: catch C2-traffic
The implant can hide on the device, but he needs to unload the data - and at this point it becomes visible for network monitoring. This is the only place in the kill chain where we can even hook an unknown implant.
Adjustments to the environment
• Hardware: dedicated server or VM, at least 8 GB RAM, 4 CPU cores, 500 GB for storing logs
• Network position: tap/mirror port on the Wi-Fi gateway or VPN aggregator. Devices on cellular - only through a given VPN
• OS: Ubuntu 22.04+ or Debian 12+
• Zeek 6.x (actively supported, stable release), Surica 7.x
• TinyCheck (open source, Kaspersky, GitHub - for point checking specific devices via Raspberry Pi)
IoC mobile spyware in network traffic
Six compromising indicators at the network level that I actually saw in the product:
1. DNS to NRD (Newly Registered Domains): Resolving domains registered less than 30 days ago - a typical C2 infrastructure pattern. The same case with the financial director began with this.
2. Certificate anomalies: TLS certificates from little-known CA, short life or self-signed.
3. Beacon-pattern: periodic connections to jitter +-10-15% to one IP-address - a sign of automatic efficiency. A man doesn't go online like that, and that's what a bot doesn't.
4. Upload/download ratio: The compromised upload device has anomalously high relative to the typical user profile.
5. Night traffic: efficiency at 02:00-05:00, when the user does not interact with the device.
6. DoH bypass: access to DNS-over-HTTPS providers (dns.google, cloudflare-dns.com) bypassing the corporate DNS projector.
Suricata rule for beacon-pattern detection to unknown domains:
Code:
alert tls $HOME_NET any -> $EXTERNAL_NET any (
msg:"MOBILE-SPYWARE Potential C2 beacon to NRD";
flow:established,to_server; tls.sni;
dataset:isnotset,known_domains,type string,
state /var/lib/suricata/known_domains.lst;
threshold:type both, track by_src, count 5, seconds 3600;
classtype:trojan-activity; sid:1000001; rev:1
The rule will work with TLS-connections to 5+ unknown domains per hour from one source. File known_domains.lst formed from DNS-legs in 90 days - your baseline. In practice, the first week after the inclusion will be cleansing false positives from marketing SDK in mobile applications - they also love fresh domains.
For Zeek - monitoring of JA3 hash. Commercial implants sometimes use non-standard TLS libraries whose JA3 prints are different from mobile browsers:
Code:
event ssl_established(c: connection) {
if (c$ssl?$ja3 && c$ssl$ja3 !in known_mobile_ja3) {
NOTICE([$note=SSL::Unknown_JA3,
$msg=fmt("Unknown JA3: %s -> %s",
c$id$orig_h, c$ssl$ja3),
$conn=c]);
}
}
Limitation: Pegasus on iOS uses the system TLS-sweep - JA3-hash coincides with the legitimate Safari. Here JA3 is useless, you need analysis of away behaviors. The JA3 approach is more effective against stalkerware and less sophisticated commercial implants – and most of them.
DoH: Blind Spot of Corporate DNS Monitoring
Blocking DoH providers (8.8.8.8:443, 1.1.1.1:443, 9.9.9.9:443) at the level of firewall for the mobile segment is the first step. Any contact from a mobile device to DoH outside of corporate policy is an altrate to SIEM. If the device is trying to bypass your DNS, it is either compromised or an application that behaves suspiciously. In both cases, it is worthwhile to understand.
This gap between the compliance status and the real compromise is exactly what commercial spyware exploits by design. And if your SOC relies only on MDM, you have a blind spot the size of the entire mobile arsenal.
Business Logic of Attack: Why Mobile Spyware Is Targeting a Corporate Environment
Mobile phone of the top manager - the point of concentration of everything valuable: correspondence in messengers, voice conversations, corporate mail documents, VPN-credentials. Commercial spy instruments (peace and less public analogues of NSO Group, Predator and less public analogues) are designed to covertly extract these data.
The financial impact goes beyond direct losses from the leak of strategic plans or M&A-deals. In the Russian jurisdiction, negotiable fines for the leakage of personal data for 152-FZ reach 3% of annual revenue. Compromise of a mobile device with access to corporate systems is a direct path to such a scenario.
A separate vector is an insider threat. Stalkerware and commercial spy apps can install an employee with physical access to the victim’s device: a colleague, a contractor, a service center employee. Unlike zero-click exploits, this vector does not require a nation-state budget - enough unlocked device for 3-5 minutes.
Kill chain of commercial mobile spyware:
1. Initial Access - zero-click exploit via iMessage/WhatsApp or physical installation (insider). The victim does nothing.
2. Collection - implant activates Keylogging (T1056.001), Screen Capture (T1113), Audio Capture (T1123), Video Capture (T1125).
3. Stealth - Rootkit-level techniques (T1014) to hide artifacts below the OS level.
4. C2 - Encrypted Channel (T1573) via HTTPS with certificate penning.
5. Exfiltration - Exfilration Over C2 Channel (T1041) portions at night.
For SOC, the main problem here is: the entire chain works below the level that MDM sees. How exactly the guys from iVerify formulated - "MDM configuration, not compromise""MMD reflects the configuration, not a compromise".
MDM detection of spyware: why compliance is not equal to security
Microsoft Intune, Jamf Pro, Workspace ONE - what everyone sees and what everyone does not see
MDM solutions were designed to control the configuration, not to detect compromise. Here is a breakdown by vendals:
See the pattern? The bottom half of the table is complete "no". The device with the active implant Pegasus passes all compliance-checks Intune: the implant is not reflected as an installed application, not the triggers of the jailbreak-detection when using kernel-level on the exploit of the current iOS. Green tick in the console - and complete tranquility SOC.
Where MDM is useful as a data source for detection:
Inventory of the Arsenal (NIST CSF ID.AM-01) - complete visibility of the park of devices. Without it, the network detection loses the context: there is anomalous traffic, and it is impossible to bind to a particular employee. Baseline Configurations (NIST CSF DE.AE-01) - compliance policy is created by baseline, deviations from which are correlated with network anomalies in SIEM. Forced VPN - Intune (per-app VPN), Jamf Pro (Always-On VPN), Workspace ONE (Tunnel) route mobile traffic through the enterprise infrastructure, where it is already analyzed by the network monitoring.
MDM is an inventory book and control panel. Expect implant detections from it - approximately how to expect from the ACS to detect the lateral movement.
Mobile Threat Defense Solutions: Lookout, Zimperium, iVerify - trade-off
MTD expands detection beyond MDM, but each solution has its own limitations:
When the MTD is not enough: No MCD product does not guarantee the detection of fresh 0-day zero-click exploit. Commercial spavivares are designed taking into account the bypass of IoC-bases and MTD behavioral patterns. Lookout and Zimperium are good against the mass stalkerware, but against Pegasus with the actual exploit chain is a race in which the MTD vendors lag behind. Network-based detection is a mandatory second echelon.
Network-based detection of mobile threats: catch C2-traffic
The implant can hide on the device, but he needs to unload the data - and at this point it becomes visible for network monitoring. This is the only place in the kill chain where we can even hook an unknown implant.
Adjustments to the environment
• Hardware: dedicated server or VM, at least 8 GB RAM, 4 CPU cores, 500 GB for storing logs
• Network position: tap/mirror port on the Wi-Fi gateway or VPN aggregator. Devices on cellular - only through a given VPN
• OS: Ubuntu 22.04+ or Debian 12+
• Zeek 6.x (actively supported, stable release), Surica 7.x
• TinyCheck (open source, Kaspersky, GitHub - for point checking specific devices via Raspberry Pi)
IoC mobile spyware in network traffic
Six compromising indicators at the network level that I actually saw in the product:
1. DNS to NRD (Newly Registered Domains): Resolving domains registered less than 30 days ago - a typical C2 infrastructure pattern. The same case with the financial director began with this.
2. Certificate anomalies: TLS certificates from little-known CA, short life or self-signed.
3. Beacon-pattern: periodic connections to jitter +-10-15% to one IP-address - a sign of automatic efficiency. A man doesn't go online like that, and that's what a bot doesn't.
4. Upload/download ratio: The compromised upload device has anomalously high relative to the typical user profile.
5. Night traffic: efficiency at 02:00-05:00, when the user does not interact with the device.
6. DoH bypass: access to DNS-over-HTTPS providers (dns.google, cloudflare-dns.com) bypassing the corporate DNS projector.
Suricata rule for beacon-pattern detection to unknown domains:
Code:
alert tls $HOME_NET any -> $EXTERNAL_NET any (
msg:"MOBILE-SPYWARE Potential C2 beacon to NRD";
flow:established,to_server; tls.sni;
dataset:isnotset,known_domains,type string,
state /var/lib/suricata/known_domains.lst;
threshold:type both, track by_src, count 5, seconds 3600;
classtype:trojan-activity; sid:1000001; rev:1
The rule will work with TLS-connections to 5+ unknown domains per hour from one source. File known_domains.lst formed from DNS-legs in 90 days - your baseline. In practice, the first week after the inclusion will be cleansing false positives from marketing SDK in mobile applications - they also love fresh domains.
For Zeek - monitoring of JA3 hash. Commercial implants sometimes use non-standard TLS libraries whose JA3 prints are different from mobile browsers:
Code:
event ssl_established(c: connection) {
if (c$ssl?$ja3 && c$ssl$ja3 !in known_mobile_ja3) {
NOTICE([$note=SSL::Unknown_JA3,
$msg=fmt("Unknown JA3: %s -> %s",
c$id$orig_h, c$ssl$ja3),
$conn=c]);
}
}
Limitation: Pegasus on iOS uses the system TLS-sweep - JA3-hash coincides with the legitimate Safari. Here JA3 is useless, you need analysis of away behaviors. The JA3 approach is more effective against stalkerware and less sophisticated commercial implants – and most of them.
DoH: Blind Spot of Corporate DNS Monitoring
Blocking DoH providers (8.8.8.8:443, 1.1.1.1:443, 9.9.9.9:443) at the level of firewall for the mobile segment is the first step. Any contact from a mobile device to DoH outside of corporate policy is an altrate to SIEM. If the device is trying to bypass your DNS, it is either compromised or an application that behaves suspiciously. In both cases, it is worthwhile to understand.
