Airstalk Malware: Nation‑State Exploitation of Mobile MDM APIs and What Enterprises Must Do

TLDR

Nation‑state actors use Airstalk malware to abuse AirWatch MDM APIs.

The threat targets browsers on corporate mobile devices; immediate detection and network controls are required.

What happened

Palo Alto Networks discovered a new malware family called Airstalk. The code appears in a supply‑chain attack that leverages the AirWatch API, a component of VMware’s mobile device management (MDM) platform. Attackers obtain legitimate API credentials, then use them to install a covert payload on managed devices.

Airstalk exists in two flavors. The PowerShell variant runs simple commands and can download additional modules. The .NET variant is more sophisticated. It can inject code into Microsoft Edge and Island browsers, capture screenshots, harvest cookies, and manipulate browser storage. Both variants communicate with a command‑and‑control (C2) server over HTTPS, blending in with normal MDM traffic.

The initial infection vector is still unknown. Researchers suspect a compromised third‑party library or a malicious update to an internal app used by business process outsourcing (BPO) firms. Once the malicious component is present, it registers itself as a legitimate MDM profile. The device trusts the profile, allowing the malware to run with elevated privileges.

After installation, Airstalk creates a hidden channel through the AirWatch API. It periodically polls the API for instructions. The C2 server can push PowerShell scripts, .NET assemblies, or configuration changes. Because the traffic follows the same endpoints used for routine device management, network‑based detection is difficult.

The malware also includes anti‑analysis checks. It looks for sandbox artifacts, checks the device’s hostname for known analysis tools, and aborts if it detects a virtual environment. This behavior reduces the chance of early discovery.

In the wild, the campaign has been observed targeting enterprises that outsource customer‑service or data‑entry functions. These organizations often grant broad MDM permissions to third‑party vendors, creating a fertile attack surface.

Why it matters

Airstalk demonstrates a shift in attacker tactics. Instead of exploiting a single vulnerability, the group weaponizes a trusted management interface. This approach gives them persistent, low‑noise access to a large number of devices.

• Stealthy C2 channel: By using the AirWatch API, the malware blends with legitimate traffic. Traditional IDS signatures miss the communication.
• Browser data theft: Harvested cookies can be replayed to hijack user sessions. In BPO environments, this can expose customer data, financial records, and internal portals.
• Cross‑platform impact: The .NET variant works on both Android and Windows devices that run Edge or Island. This widens the attack surface beyond mobile phones.
• Supply‑chain risk: The initial foothold may be a compromised library or update. Organizations that rely on third‑party code must assume any component could be a delivery mechanism.
• Regulatory exposure: Data leakage from browsers can trigger GDPR, CCPA, or industry‑specific breach notification requirements.

Because the malware operates at the management layer, it can survive OS re‑installs and device resets. The persistence model is more durable than typical mobile malware that relies on user interaction.

Finally, the focus on BPO firms highlights a broader trend. Outsourced teams often have elevated privileges to access multiple client environments. Compromise of a single vendor can cascade into many downstream organizations.

Who is affected

Any organization that uses VMware AirWatch (or its rebranded version, Workspace ONE) for mobile device management is a potential target. The risk is highest for the following groups:

• Business Process Outsourcing (BPO) providers: They manage large fleets of employee devices and often have deep MDM permissions.
• Enterprises with remote workforces: Remote employees rely on MDM to enforce security policies, making them visible to the same API.
• Companies that integrate third‑party mobile apps: If a vendor’s app is compromised, it can become a delivery vector.
• Financial services, healthcare, and legal firms: These sectors store high‑value data in browsers and are subject to strict compliance regimes.
• IT departments that delegate MDM administration: Delegated admin roles can be abused if credentials are leaked.

Even organizations that have not yet adopted AirWatch are at risk if they plan to migrate to VMware’s MDM solution. The underlying technique—abusing trusted management APIs—can be replicated on other platforms.

How to check exposure

Detecting Airstalk requires a layered approach. Below are actionable steps you can take today.

1. Audit API credentials: Review all service accounts that have access to the AirWatch API. Look for accounts that are unused, have excessive scopes, or were created recently without a documented business case.
2. Enable API logging: Ensure that every API call is logged with timestamp, source IP, and invoked method. Export logs to a SIEM for correlation.
3. Search for anomalous patterns: In the logs, flag any of the following:
   • Repeated GET/POST requests to /api/mdm/ endpoints from unknown IP ranges.
   • Large payloads being uploaded to device profiles.
   • Requests that include PowerShell or .NET assembly strings in the body.
4. Inspect installed profiles on devices: Use the AirWatch console to list all active MDM profiles. Verify the signer, version, and hash of each profile against a known good baseline.
5. Endpoint detection: Deploy EDR agents on managed devices that can monitor for the following indicators of compromise (IOCs):
   • Execution of powershell.exe with arguments that contain base64‑encoded scripts.
   • .NET assemblies loading from temporary directories with names resembling MicrosoftEdge_*.dll or IslandBrowser_*.dll.
   • Processes that open network connections to unknown HTTPS endpoints while using the AirWatch certificate chain.
6. Browser artifact review: On a sample of devices, extract browser cookie stores and compare them to known legitimate cookie values. Unexpected session tokens may indicate exfiltration.
7. Network traffic analysis: Deploy a TLS‑inspection proxy for MDM traffic in a test environment. Look for hidden POST bodies that contain encrypted blobs not matching standard MDM payloads.
8. Threat intel cross‑check: Compare observed IOCs with those published by Palo Alto Networks, MITRE ATT&CK (T1071.001 – Web Protocols), and other reputable feeds.

Document any findings and prioritize remediation based on the criticality of the affected devices.

Fast mitigation

Once exposure is confirmed, act quickly to contain and eradicate the threat.

1. Revoke compromised API keys: Immediately disable any service accounts that show suspicious activity. Generate new keys and rotate them across all automation scripts.
2. Force a profile refresh: Use the AirWatch console to push a forced profile update to all devices. Include a checksum verification step that rejects unsigned or altered profiles.
3. Isolate affected devices: Place devices with detected IOCs in a quarantine VLAN. Block outbound traffic to the identified C2 domains.
4. Run full endpoint scans: Deploy your EDR’s remediation playbook to terminate malicious processes, delete dropped files, and remove unauthorized registry keys.
5. Patch the MDM server: Apply the latest security patches from VMware. Review configuration settings to enforce least‑privilege access for API tokens.
6. Update browser hardening policies: Disable extensions that allow cookie export, enforce same‑site cookie attributes, and enable browser isolation where possible.
7. Notify stakeholders: Inform senior leadership, legal, and compliance teams. Prepare breach notification drafts if data exfiltration is confirmed.
8. Review third‑party contracts: Ensure vendors with MDM access are subject to continuous security assessments and have incident‑response clauses.
9. Implement continuous monitoring: Set up automated alerts for the API patterns listed in the detection section. Review alerts daily for the first 30 days.

After containment, conduct a post‑mortem. Identify how the initial supply‑chain foothold was achieved, and strengthen your software‑supply‑chain controls accordingly.

By following these steps, organizations can reduce the window of exposure, protect browser credentials, and restore confidence in their mobile management infrastructure.