Most people know to be suspicious of an unexpected text claiming to be from their bank. This campaign works because the message comes from someone the victim already knows and trusts.

How the scam works

The message arrives from a contact’s WhatsApp account, which has most likely already been compromised by the same scam. It includes a link and asks the recipient to vote for a child taking part in a contest.

The site asks the victim to pick a contestant, then to enter their phone number and the code they receive.

That code links the victim’s WhatsApp account to a device the attackers control.

The site also offers a QR code to scan, which links the account in the same way.

Once linked, the attackers can read the victim’s new messages and send messages in their name, including the same voting link to everyone in their contacts. The victim’s phone carries on working as normal, so most people have no idea their account has been taken over.

The phishing pages are also built to stay out of sight. Each one loads only when visited through its full URL, and visiting the bare domain returns a 403 Forbidden error, which makes the sites harder for automated scanners to find.

Why this matters for organisations

Many employees use WhatsApp to talk to colleagues, clients, and suppliers, whether on a company phone or their own. A hijacked account gives attackers a view into those conversations and lets them message people as a trusted member of staff. Because the lure arrives through a messaging app, email security tools never see it, and mobile device management doesn’t close the gap either, because MDM and mobile threat defence do different jobs.

Indicators of compromise

We identified the following domains through our own detections and reverse IP lookups. They have been defanged so they can’t be clicked, and most are now offline.

• ballethfibs[.]cc
• czechballetschool[.]site
• awardancing[.]cc
• awardancing[.]ws
• awardancing[.]com
• awardancing[.]sbs
• awardancing[.]cfd
• besttack[.]top
• jordan-skill[.]com
• skill-bright[.]cyou
• sup-steel[.]click
• wiki-drell[.]online

Almost every phishing URL we saw used one of these two paths:

• /p/29/#
• /l/vote2026m11

The domains resolved to two IP addresses, hosted in Czechia and France:

• 95.182.87[.]131
• 138.124.92[.]4

The hosting location shows where the servers are rather than where the attackers are. However, the website’s source code contains extensive comments written in Russian, which suggests it was built by Russian speakers. The code also makes repeated references to Telegram, suggesting the template may have been reused from an earlier scam targeting Telegram users. The site shows signs of being built with AI tools, including AI-generated images. A template that has already been adapted from one messaging app to another could easily be adapted for other countries and languages, so we expect this campaign may spread.

How Corrata detected the campaign

Corrata’s zero-day phishing protection (ZDP) assesses domains it has not seen before and quarantines them if they are judged risky. None of the domains in this campaign had been seen before, so ZDP assessed them, judged them risky, and blocked access, whether the link arrived by WhatsApp, SMS, or any other app. This stopped users before they ever reached the page asking for their phone number, so customers were protected before the scam had a name.

How to keep yourself safe

1. Never enter a code into a website: WhatsApp verification and pairing codes are only ever needed inside the WhatsApp app. If a website asks you to enter your phone number and then a code you’ve just received, close it, because that is how attackers link your account to their device.
2. Check your linked devices: Open WhatsApp settings, go to Linked devices, and review everything listed there. If you see a device you don’t recognise, log it out straight away.
3. Turn on two-step verification: This adds a PIN that’s needed whenever your number is registered on WhatsApp, which makes it much harder for someone to take over your account.
4. Confirm unusual requests with the sender: If a friend sends you a link asking you to vote, donate, or log in, call them or message them on a different app to check they really sent it. Their account may have been compromised.
5. Treat links on every platform with caution: Phishing now arrives through WhatsApp, Telegram, social media, and QR codes as well as SMS and email, often from people you trust.

For organisations

Staff can’t be expected to spot a convincing link from a friend every time, so protection needs to work at the device level through mobile threat defence. Corrata’s zero-day phishing protection blocks links like the ones in this campaign whichever app they arrive through, even when the domain is brand new.

To see how it works, request a demo.

The post The WhatsApp “vote for my friend’s child” scam that takes over your account appeared first on Corrata.

This page separates those product types into layers, covering products built for phones and tablets running iOS and Android rather than for laptops. For each it sets out what the software does, where its protection ends, and who sells it. Nothing here is ranked, because the right choice depends on what you already own.

Corrata publishes this guide and sells in two of the layers below. Vendors are included if they sell to organisations and have a documented offering for iOS or Android. Application shielding products such as Appdome and Guardsquare are out of scope, because they protect apps your organisation publishes rather than the phones your staff use.

What counts as mobile security software

The useful boundary is the operating system rather than portability.

Mobile security software protects phones and tablets running iOS and Android, along with the company data they reach. A laptop is portable too, but it is a different engineering problem, because a desktop operating system has long let security software install at a privileged level and observe the whole machine. A phone has never allowed that.

A vendor describing one agent across laptops, phones, and tablets is describing two engineering approaches under one brand, and the mobile half deserves separate evaluation.

A secure access client running on a phone is also not the same category as a product that detects threats on one, and treating them as interchangeable is how gaps get missed.

Why mobile security software is built differently

Desktop security consolidated over about two decades. Antivirus, host firewall, device control, and behavioural detection all merged into endpoint protection platforms, and those in turn became endpoint detection and response.

Mobile never went the same way, for reasons that come down to how the two operating systems are built.

The sandbox denies the view that desktop agents rely on: iOS and Android isolate applications from one another, so one cannot read another’s files or watch what the user does inside it. The level of system access that desktop agents have relied on has never existed on a phone. Desktop platforms are moving the same way, with Apple replacing kernel extensions with user-space system extensions and Microsoft building a platform for antivirus and endpoint detection to run outside the Windows kernel.

Products are built on sanctioned interfaces instead: What a mobile security product can see is set by the APIs each platform chooses to expose. Network extensions allow traffic to be inspected, management frameworks report configuration state and application inventory, and attestation services report whether an application or device meets the platform’s integrity criteria. Neither platform returns a jailbreak or root flag directly, so products infer that condition from other signals, and every vendor is working through the same set of interfaces.

The two platforms expose different things: Android allows an application to enumerate other installed applications and read their permissions, though since Android 11 it must declare which ones it needs to see or hold a permission that Google approves on Play. iOS allows none of it, so a product claiming identical capability on both platforms is worth questioning.

Mobile security fragmented into layers rather than consolidating into a single agent, because no one interface exposes all of it. Working out which layer a product occupies is most of the buying decision.

What the threats actually are

• Phishing outside email: Mobile phishing arrives through SMS (smishing), RCS, WhatsApp, Signal, Telegram, and LinkedIn, none of which an email gateway sees. A truncated address bar shows only a fraction of a URL, and there is no hover preview to check it against. 
• QR code phishing: A code scanned with the native camera takes the user into a browser with a single tap and no security inspection in between, as our blog on QR code phishing sets out.
• Applications: Sideloading on Android, enterprise certificate abuse on iOS, and the alternative app marketplaces that the Digital Markets Act opened up on iOS in the EU all put software on a device without full store review. The more common problem is a legitimate store application requesting far more permission than its function requires.
• Networks: Phones join networks constantly and silently, and an attacker operating a network the device trusts can intercept any traffic that is not independently protected.
• Unpatched and unsupported devices: A phone on an operating system version that no longer receives security updates stays fully functional and fully exposed, and such devices accumulate quietly in any fleet that includes personally owned phones.
• Commercial spyware: Products sold to government customers and used against journalists, lawyers, and executives have repeatedly reached devices through zero-click delivery, as our history of iOS spyware documents.
• Data leaving through AI applications: Consumer AI services are installed on employee phones in volume, and company documents and client information are routinely pasted into them, making AI governance a necessity.

Built-in mobile protection on iOS and Android

Mobile platforms are more secure by default than a general-purpose desktop operating system, so the right starting point is a frank account of what you already have.

What the platforms cover

Application sandboxing, store review, and code signing are built in. Apple delivers OS security updates directly to every supported device. On Android, the full patch level depends on the handset maker, so two phones bought on the same day can sit months apart.

Apple offers Lockdown Mode for people at elevated risk of targeted attack, and Advanced Data Protection for end-to-end encrypted iCloud storage, though Advanced Data Protection has been unavailable to UK users since February 2025, when Apple withdrew it following a Home Office notice under the Investigatory Powers Act. 

Google Play Protect scans Android applications, and work profiles separate company from personal data on one device.

Where it stops

Store review does not catch everything, and it does not apply to apps installed from outside the store. Android devices left on an old patch level are exposed to vulnerabilities fixed upstream months earlier. 

Work profiles separate data without inspecting anything, so nothing stops a phishing link opened in the personal half of the device.

One limit applies to all of them, and it is the decisive one. None of these controls tells your security team anything. There is no alert, no console, and no record of what happened. Everything below exists to close that gap.

The layers, and who sells each

Each layer names the vendors that sell into it.

Device management: MDM and UEM

Management platforms enrol devices, apply configuration, distribute applications, enforce policy, separate company from personal data, and wipe company data remotely. Unified endpoint management extends the same model to laptops.

This is the foundation layer, and it is usually already in place. It is also the deployment path for much of what follows, because threat products are commonly distributed through it.

Management ends at administration. It verifies that a device is in a known good state, and it does not observe what happens on a device that is already in one.

Products in this layer include Microsoft Intune, Omnissa Workspace ONE UEM, Jamf Pro, Ivanti Neurons for MDM, SOTI MobiControl, IBM MaaS360, Scalefusion UEM, and Hexnode UEM. 

The line between management and detection is the one buyers most often misread, and our comparison of MDM and MTD covers where each of them stops.

Mobile threat defence

Mobile threat defence products detect threats that device management cannot see, including on phones that are fully compliant and up to date, and they work at the device, application, and network levels.

Device-level detection covers the state of the operating system, including jailbreak and root detection, weak configurations, and unsupported releases. Application-level detection goes deeper on Android, where packages and permissions can be inspected, than on iOS, where visibility into other applications is limited to what a management platform reports. Network-level detection is where phishing is caught, because a malicious link resolves to a destination that can be blocked before the page loads. 

A management platform tells you a phone is patched and configured to policy. It does not tell you the person holding it has just entered their credentials on a page registered an hour earlier. The device stays compliant throughout.

Corrata, Check Point, CrowdStrike, Ivanti, Jamf, Lookout, Microsoft, Pradeo, SentinelOne, and Zimperium all sell in this layer, each covered in more detail in our guide to mobile threat defense software.

Mobile data loss prevention and AI governance

This layer governs where company data goes once it is on a phone. The destinations that matter are consumer AI services, unsanctioned cloud storage, personal accounts in otherwise sanctioned applications, and the advertising and analytics infrastructure embedded in applications installed for other reasons.

Detection and data control are different problems. One asks whether something harmful is reaching the device; the other asks where information is leaving it. An employee pasting a client contract into a consumer AI service has not been attacked, and the data has still left the organisation.

The mobile version of this problem is harder, because the traffic does not traverse a corporate network and the applications are often on devices the organisation does not manage.

Two kinds of product address this, and they are not interchangeable. Mobile-native tools apply controls on the phone itself, and Corrata, for example, discovers and classifies AI applications across a fleet and blocks uploads to unapproved services. 

Security service edge platforms such as Netskope and Zscaler apply comparable controls across a whole estate, which suits an organisation already running one rather than one solving a mobile problem.

DNS and web filtering

Filtering products block known-bad or policy-prohibited destinations, either by refusing to resolve a domain or by blocking the connection at a gateway. They are inexpensive and effective against threats that rely on reaching a known destination.

DNS filtering works on domain lookups, so a connection made directly to an IP address bypasses it, as does a lookup sent to an encrypted resolver that the filter does not control. It also works from lists, so it is weak against a domain registered an hour ago.

Cisco Umbrella, Cloudflare Gateway within Cloudflare One, and DNSFilter sell here, and filtering is bundled into several management platforms. On phones, each works through the vendor’s own client, so check which platforms that client supports.

Choosing by situation

The criteria below matter most when a particular problem is driving the purchase.

When phishing arrives by text, chat, and QR code

• Channel coverage: Establish which channels the product can see. A product that inspects only browser traffic will miss links opened inside a messaging app’s own in-app browser, so ask about each channel individually.
• Inspection method: A product filtering on domain lookups misses a connection made directly to an IP address.
• Where analysis runs and how fresh it is: Phishing infrastructure is short-lived, so ask what the product does with a destination it has never seen, and whether assessment happens on the device or in the vendor’s cloud.
• What happens after detection: Products vary between alerting the administrator, warning the user, and blocking the connection outright. Only the last of those prevents credential entry.

Two things remain out of reach of any product here. Voice social engineering that carries no link puts nothing in the traffic to inspect, and a QR code scanned with the native camera on an unprotected phone takes the user wherever it points.

When the fleet is BYOD or unmanaged

• The population is larger than it looks: Beyond personally owned devices, this group includes contractors, board members, seasonal staff, suppliers with system access, and employees who were offered enrolment and declined it. None of them appear in the enrolled device count.
• Deployment without management: Ask whether the product deploys to a device that is not enrolled. Apple restricts system-wide content filtering on iOS to supervised devices, and the per-app alternative needs the targeted apps installed through a management platform, so any product covering an unenrolled iPhone is reaching it another way.
• What is collected: Establish what telemetry leaves the phone and what an administrator sees in the console, asking both separately.
• Where data is processed and stored: Ask where processing happens, where data rests, and whether that is contractual or current practice. 
• How much it interrupts the user: Software that prompts, warns, or slows the device gets uninstalled or worked around, whatever the detection is like. Ask what the employee experiences when nothing is wrong. 

When you are building zero trust

• Identity provider integration: Posture only matters if it reaches the access decision, so establish which identity providers are supported and what the integration passes.
• Continuous against point-in-time: A check at enrolment and one at sign-in both leave a session running on a device whose state may have changed. Ask how often posture is re-evaluated.
• Coverage of unenrolled devices: An architecture that only evaluates enrolled devices has left out the devices that most need evaluating. Corrata Identity Gate allows access from personal devices only where Corrata is installed and the device has a good security score.
• Revocation: Establish what happens when a device fails, and whether existing sessions are terminated or only new ones refused.
• Output to the rest of the stack: Check what the product sends to your SIEM or XDR platform. Corrata integrates with SIEM platforms.

Conclusion

Mobile security software is a set of layers, each solving a different problem, and vendors describe them in language similar enough to make them look interchangeable.

Work out which question you need answered, identify the layer that answers it, and establish what your existing licensing already covers before buying anything, because several management platforms bundle filtering and several security suites include a mobile tier that may already be paid for but not yet deployed.

If mobile phishing and data loss on employee devices are your problems, you can request a demo to see how Corrata handles both.

The post How Mobile Security Software Works, Layer by Layer appeared first on Corrata.

This post is for IT and security teams comparing Corrata vs Lookout, or weighing Corrata as a Lookout alternative. Both products cover phishing, malicious apps, device compromise, and network threats, so a feature checklist will mostly come back level. The more useful comparison is where each product gets its evidence, how much of that evidence leaves the phone, and where it ends up.

What we compared, and what we did not

This comparison covers Corrata’s mobile threat defence solution, including Shadow AI and DLP and AI Agent Shield, and Lookout Mobile AI Security, which Lookout’s BYOD page refers to as Lookout MES. We include the three add-on areas Lookout presents as modules of its platform: AI Visibility & Governance, Social Engineering Protection, and Advanced SOC (Mobile EDR). Where a capability sits in one of those modules, we say so, because the Lookout pages we reviewed do not publish pricing or say which modules are bundled together.

Lookout’s Threat Lab research and its Mobile Threat Intelligence offering are out of scope. Its Mobile Software Exposure Center (MSEC) is covered briefly under app risk.

Both products deploy alongside MDM and pass device risk to identity providers.

Corrata vs Lookout: the short version

The short answer

Lookout builds its picture from the device, its apps, and what reaches the user, and its app risk scores also draw on network activity. It analyses app behaviour on the device and in the cloud, monitors OS integrity, and detects rogue Wi-Fi and man-in-the-middle attacks. Its Social Engineering Protection module analyses message content and links, and includes voice call analysis, and its Mobile EDR module gives SOC teams historical mobile telemetry to hunt across.

Corrata builds its picture from the traffic: every connection the device makes, across all ports and key protocols, inspected on the device. It runs on iOS and Android, hosts console data in the EU as standard, and does not read messages, scan files, or record browsing history.

Two architectures, two kinds of evidence

Anyone weighing a Lookout alternative should start with what each product looks at.

Lookout looks at the device, the apps on it, the content that reaches the user, and network activity at the point of interaction. Its core layer combines on-device and cloud-based behavioural analysis of apps and monitors posture for rooting, jailbreaking, and OS tampering. For web threats, Lookout’s Safe Browsing feature uses a VPN interface on the device to analyse traffic, and the platform encrypts and secures DNS across cellular, Wi-Fi, and roaming networks. Social Engineering Protection extends into message content and audio, and Advanced SOC adds a historical telemetry store for analysts.

Corrata looks at the traffic. Its patented on-device inspection observes device configurations, app hashes, app permissions, domain and server names, IP addresses, port numbers, and certificate metadata. That is why individual domains, servers, ports, and IP ranges can be blocked, why detection continues when DNS is encrypted, using Server Name Indication, and why policy can target a single SaaS service or a single upload.

On everyday threats the two models overlap. They diverge at the edges: Lookout’s documentation reaches into message content, voice, and, with Advanced SOC, a central telemetry store, while Corrata documents IP, port, cipher, and certificate controls and never accesses content on the phone. Here is how that plays out across seven areas.

Phishing, smishing, and voice

Both products protect against mobile phishing on the device, outside the email gateway.

Lookout’s Social Engineering Protection detects and blocks malicious messages by analysing both content and links in SMS, RCS, and MMS, including short-lived URLs built to evade reputation lists. It extends to WhatsApp, iMessage, and Signal through a Message Verifier, checks QR-encoded URLs with a QR Code Scanner, and adds Voice Security for real-time call analysis, caller ID, and call blocking. Lookout says it evaluates intent and context to stop linkless smishing and deepfake vishing, where a lure carries no URL at all. Its privacy notice adds qualifications: text content is collected only from unknown senders when Smishing Protection is enabled, RCS coverage is Android only, and messages from third-party apps are shared voluntarily by the user.

Corrata’s Mobile Phishing Protection works on the connection. It blocks malicious destinations whichever channel the link arrived on, combining DNS filtering, SNI inspection, zero-day domain assessment, and proprietary mobile threat intelligence. Previously unseen domains assessed as risky are quarantined until their reputation is established, and Corrata blocks the IP ranges that host phishing toolkits, which matters for adversary-in-the-middle kits that proxy a real login page to bypass MFA.

Lookout documents analysis of the message and the call, which can reach lures that never produce a malicious connection. Corrata’s pages describe protection that acts when a lure leads somewhere, without reading the message that carried it. 

AI chatbots, agents, and data leaving the device

Both vendors treat AI use on mobile as a data-loss problem, and they document control at different levels.

Lookout’s AI Visibility & Governance module identifies and classifies AI-enabled apps across corporate-owned and BYOD devices, covering native GenAI apps and mobile browsers. Policies can allow, monitor, warn, or block AI applications based on risk classification and data handling practices, data guardrails monitor and govern flows between devices and AI services, and agentic behaviour is watched through behavioural analysis and permission mapping.

Corrata controls it at the traffic. Shadow AI and DLP detects and blocks file uploads to unsanctioned LLMs and cloud services, discovers and classifies AI apps, identifies previously unknown applications, and lets you allow, block, or monitor individual SaaS services, whether used through an app or a browser. AI Agent Shield works at the session: it scores each session Human, Assisted, or Autonomous from traffic metadata, can pause an autonomous session and ask the user, blocks or caps uploads to unapproved AI services by size, app, and user group, and records an Agent Receipt for each autonomous session. A device running an unapproved agent can be marked non-compliant in Intune.

The difference lies in what is documented. Lookout’s pages describe AI discovery that identifies AI in encrypted mobile traffic, policies by application risk, governance of data flows to AI services, and monitoring of agent behaviour, permissions, and API interactions. Corrata’s pages add live session scoring and pausing, an Agent Receipt for each autonomous session, upload caps by size, app, and user group, and allow, block, or monitor controls for individual SaaS services beyond AI. Corrata also sets out what it cannot see: models running entirely on the chip send no traffic, and iOS detection relies on traffic and is strongest on supervised devices.

Spyware, forensics, and containment

Lookout monitors device posture for advanced exploitation techniques, including attacks designed to bypass MDM. For investigation, Advanced SOC (Mobile EDR) gives analysts raw telemetry across web history, location history, USB and Bluetooth connection history, and app activity, historical telemetry to reconstruct an attack timeline, and the ability to interrogate and quarantine devices. There is an early access programme for Advanced SOC, so ask Lookout about availability.

Corrata’s Spyware Detection continuously monitors for the anomalies in device behaviour that spyware causes, including Pegasus-class and DarkSword-class exploits. When something looks wrong, end users can generate and submit device diagnostic files and packet captures, and Corrata automatically quarantines the device from sensitive corporate data. A packet capture shows whether a suspected implant is communicating, where to, and over what.

The difference is where the evidence lives. With Advanced SOC, Lookout holds a fleet-wide history that analysts can query, which suits a SOC running hunts. Corrata’s model keeps that data on the phone until a diagnostic is submitted, which suits organisations that want forensic depth on a suspect device without holding browsing or location history for every employee.

Network attacks and encryption quality

Lookout detects rogue Wi-Fi networks, man-in-the-middle attacks, and insecure network conditions in real time, without VPN backhaul, and detects DNS-based threats across cellular, Wi-Fi, and roaming connections. The pages we reviewed do not describe assessing the cipher strength of live connections.

Corrata starts from the assumption that the safety of cell towers and Wi-Fi hotspots can never be accurately assessed, so it checks each connection instead of the network. It examines cipher suites, protocol versions, and TLS certificates, can block traffic to apps or sites offering poor encryption, extends certificate pinning to any sensitive domain, and identifies attempts to send data in the clear. Corrata has written more on detecting weak TLS cipher suites on the device. A clean hotspot can still sit in front of a compromised path, and a legitimate app can still use weak encryption, which is what Corrata’s per-connection checks are built to catch.

Apps and device vulnerabilities

Lookout gives each app a dynamic risk score based on code-level analysis, behaviour, and network activity, and provides OS and app vulnerability visibility across managed and BYOD devices, prioritised by real-world exploitability. Its Mobile Software Exposure Center extracts a software bill of materials from compiled app binaries and correlates it with CVE and CISA KEV data.

Corrata highlights apps holding dangerous permissions such as accessibility, location, or file storage, and apps with known high-severity vulnerabilities, and blocks command-and-control traffic so harmful apps cannot exfiltrate data. Each device receives a security score, and devices that stay at risk are quarantined. Identity Gate then admits only devices verified as secure at the moment of login.

If app-level analysis and software supply chain exposure are central to your programme, Lookout documents more in that area. Corrata’s emphasis is limiting what a risky app can do over the network.

Employee privacy and what leaves the phone

Both vendors make privacy commitments for BYOD, and they describe them differently.

Lookout’s BYOD page states that personal messages, location, photos, files, and personal browsing are outside its analysis. Lookout also states that it does not track GPS, bases any location shown on IP ranges, lets administrators disable approximate location, offers de-identification of user data, and purges user data after a configurable 3 to 36 months. The text message data is stripped of personal identifiers before storage, and de-identified samples may be reviewed by Lookout researchers and used to train detection.

The Lookout for Work privacy notice sets out the detail feature by feature. With Smishing Protection enabled, SMS, MMS, and RCS content from unknown senders is collected and analysed, and the employer sees only sender number, timestamp, detected URLs, and any impersonated names. App metadata is collected and, in some circumstances, a copy of the app. In some administrator-configured scenarios, domain-level access history may be collected. Advanced SOC, as described above, works with web, location, USB, and Bluetooth history.

Lookout states that privacy is the foundation of the product rather than a configuration option. Its privacy notice sets out what each feature collects, so buyers should confirm which features they plan to enable.

Corrata never collects location, never scans files, photos, or messages, and never touches browsing history, and states these were never built, so an administrator cannot switch them on. Only security verdicts, device risk, OS version and compliance status, and risky app alerts reach the console. Agent Shield follows the same model and lets personal app traffic be excluded by policy. Corrata explains this to staff as part of employee buy-in.

Headquarters, data residency, certifications, and deployment

Lookout’s privacy notice states that its servers are housed in the United States, and says personal data from users outside the US is transferred there, using standard contractual clauses and the EU-U.S. Data Privacy Framework, including its UK Extension. The pages we reviewed do not name an EU hosting region, so a European buyer should ask where their tenant would sit. Lookout holds ISO/IEC 27001, 27017, and 27018 certification, FedRAMP Moderate, and SOC 2 Type 2 for the Lookout Platform. 

Corrata is headquartered in Dublin, with console data, security events, logs, and backups hosted in the EU as standard, and contracts governed by Irish and EU law. It is an EU-native vendor and ISO 27001 certified.

Deployment is close to a draw. Lookout covers unenrolled BYOD devices without MDM enrolment, and supplies risk scoring that Intune, Jamf, Ivanti, and BlackBerry consume to automate remediation. 

Corrata offers zero-touch deployment for managed and unmanaged devices, integration with MDM platforms, and email or SMS enrolment for BYOD or organisations without MDM.

Where compliance comes into it

Neither NIS2 nor DORA names mobile threat defence, and no product makes you compliant. Both expect you to show the measures you have in place and how you detect and report incidents. Mobile is usually the part of the estate with the least evidence to show.

Lookout maps its modules to frameworks, positioning AI Visibility & Governance against ISO/IEC 42001, the EU AI Act, and NIST AI RMF, and Mobile EDR against continuous monitoring and audit evidence requirements including NIST SP 800-53 and ISO/IEC 27001. For EU organisations, the open question is where that telemetry is processed.

Corrata covers the same ground from the traffic side: control over data sent to unsanctioned AI and SaaS, Agent Receipts prepared for auditors, DPOs, and EU AI Act evidence, and diagnostics, packet capture, and quarantine for a suspect device, from a European company hosting in the EU.

Corrata as a Lookout alternative: which one do you need?

Lookout is a credible choice, and this comparison is not an argument against it.

Choose Corrata if:

• EU data residency and a European vendor are procurement requirements
• You want allow, block, or monitor controls for individual SaaS services, and uploads to AI capped by size, app, and user group
• You want to see AI agents acting live, pause them, and keep an Agent Receipt for each autonomous session
• You want encryption quality checked on every connection, with IP, port, and certificate controls
• You want links to previously unseen domains quarantined until their reputation is established, rather than allowed by default
• You want spyware evidence from packet captures on a suspect phone, without holding location or browsing history for the whole fleet
• You need to tell BYOD staff that the agent cannot collect location, messages, or browsing history under any configuration
• You run a smaller fleet: Corrata Essentials covers fleets of up to 250 devices

Choose Lookout if:

• Vishing and deepfake voice fraud are priority risks
• You want message content and intent analysed as well as the links in it
• Your SOC wants fleet-wide historical mobile telemetry for threat hunting
• App risk scoring and software bill of materials analysis are central to your programme
• You want AI governance reporting mapped to ISO/IEC 42001 and NIST AI RMF

If you need deepfake and vishing protection, message-content analysis, or, with Advanced SOC, a fleet-wide telemetry store for threat hunting, Lookout documents those. If you need live AI session control, per-service SaaS policies, encryption checks on every connection, packet-level evidence from a suspect phone, and EU data residency, Corrata is the fit.

Whichever list you recognise, a purpose-built mobile threat defence layer is what answers it. If you are comparing other vendors too, see Corrata vs Zimperium and Corrata vs Microsoft Defender.

Book a demo to see what Corrata finds on a handful of your own devices.

The post Corrata and Lookout: How they compare on mobile endpoint security appeared first on Corrata.

What Citizen Lab found

Citizen Lab found that devices at the international news network Al Jazeera were infected with spyware from Candiru, the Israeli vendor that has since rebranded as Integrity Labs. At least 45 Al Jazeera devices were targeted in attacks during 2024 and 2025. The user did not need to click anything, because simply displaying the ad was enough to start the infection. Citizen Lab calls this technique AdFection, and describes it as the first public technical confirmation of zero-click mercenary spyware delivered through targeted ads.

Candiru has been known to researchers for some time. Citizen Lab first documented its attack chain in 2021, and assessed the sample recovered from Al Jazeera as a newer version of that chain. Confiant published a parallel investigation on the same day.

How the AdFection attack worked

Every time an app or website shows an ad, a real-time auction takes place. The device sends a bid request containing details such as device identifiers, IP address, and location. Advertisers then bid, and the winning ad is delivered, all in under a second. These auctions happen hundreds of billions of times a day on exchanges run by companies including Google and Yandex.

According to Citizen Lab, an Israeli company called Discover-Tech presented itself as a legitimate ad buyer but operated as a facilitator for several mercenary spyware vendors, including Candiru. Its ads carried a script that contacted Discover-Tech’s own server when the ad rendered. That server checked the device’s advertising identifiers and IP address. 

For most devices it returned nothing, while for selected targets it returned code. Network logs from Al Jazeera showed infected devices contacting Discover-Tech’s infrastructure first, then a Candiru validator server that checked the device, and finally a Candiru command and control server.

Controlium: the targeting console behind the ads

Citizen Lab also examined Controlium, a Discover-Tech platform that gives customers a control panel for these malicious “controlled ads”. Customers can choose whom to target by mobile advertising ID on iOS or Android, by browser identifier, or by IP address. Administrators can also restrict which countries each customer is allowed to target. Further modules show recent bid requests and ad impressions for a given identifier, which can be used to monitor a target’s activity.

A separate threat actor, which Citizen Lab calls DARK CARTOGRAPHER, used Discover-Tech’s infrastructure to run ads that tried to reveal the real IP addresses of VPN and proxy users and to unmask the phone numbers of mobile users. Citizen Lab reports that this actor’s infrastructure links to a mercenary adtech vendor and a US government contractor, and says a fuller report will follow.

Why mobile devices are in scope

The implant recovered from Al Jazeera was a Windows file, and the report does not confirm a mobile implant. However, the channel used to deliver and profile targets is overwhelmingly mobile. About three quarters of Discover-Tech’s bids were for ads inside mobile apps. Over four months, ads carrying its attacker script appeared in more than 75,000 Android and iOS apps, including mainstream messaging, email, weather, and gaming apps.

Even when no spyware was delivered, the ads still sent data back to Discover-Tech. In the UK, Citizen Lab recorded ID-syncing requests to Discover-Tech domains during a visit to The Guardian’s website. Its ads also appeared on government, defence, and critical infrastructure networks across Europe.

After Citizen Lab’s disclosure, Google, IAB Europe, Beeswax, and Eskimi cut off Discover-Tech’s access, and Vungle (Liftoff) paused it pending review. The wider lesson for security teams is that every ad request shares data about the device, and ADINT turns that data into a targeting tool.

How Corrata limits ADINT exposure

Over the past year, Corrata has treated ADINT as a real threat, and we have explained how the ad economy harvests location data from employee devices. In a typical week, Corrata blocks between 1,000 and 2,000 different advertising domains in real time across our platform. These range from well-known ad vendors to obscure services that often go unnoticed.

Turning off the mobile advertising ID on a device helps, but other details such as IP address, location, and operating system version can still be shared with ad services. With Corrata, you can block access to these domains completely, so this information is not shared with third parties. Alternatively, you can allow the domains and report on them, giving you visibility of the ad domains that websites and apps use to collect data.

Corrata also scans the apps on employee devices for background location tracking, which it classes as a potentially dangerous permission. It alerts the user and, if the issue is not addressed, can quarantine the device until action is taken.

To find out how exposed your organisation’s mobile devices are to ADINT, request a demo of Corrata and talk to our team.

The post ADINT and AdFection: Spyware Delivered by Ads appeared first on Corrata.

Employees are also more likely to fall for the mobile version. Verizon’s 2026 Data Breach Investigations Report found that phishing simulations delivered by phone, through SMS and voice, had a median click rate around 40% higher than email simulations.

This guide is for security leaders and architects responsible for employee mobile device security. It explains what mobile threat detection is, why existing controls miss mobile threats, and how on-device detection finds phishing and malware, including on personal phones.

What is mobile threat detection for employee phones?

Mobile threat detection for employee phones is the continuous monitoring of the smartphones and tablets staff use for work. It identifies phishing, malware, network attacks, and risky configurations, then blocks or contains them before they reach corporate data. It is the detection layer of mobile threat defence, a category often searched for under the US spelling “mobile threat defense”.

Mobile threat detection works alongside mobile device management (MDM), but serves a different purpose from other mobile security software. MDM controls how a device is configured, while mobile threat detection assesses whether the activity on it is safe. Phones also face conditions laptops rarely do. Most phishing arrives outside email, devices move between networks all day, and many are personal phones the organisation does not fully control.

Where existing controls leave gaps in mobile threat detection

Most enterprise security stacks were designed around email, laptops, and the corporate network, and each layer has a blind spot on mobile.

Email security only sees email. On mobile, attackers favour channels that never touch the mail server, and mobile phishing increasingly arrives through SMS, WhatsApp, QR codes, and social media. An SMS is delivered by the mobile operator, so it reaches the phone without passing any control your organisation owns.

MDM manages the device rather than defending it. It enforces passcodes, pushes apps, and reports the operating system version, but it cannot judge whether a link is malicious or whether an app is beaconing to a command-and-control server.

Network controls only see the traffic routed to them. A secure web gateway or corporate VPN can inspect connections while the phone is tunnelled through it, but phones spend much of the day on cellular data and public Wi-Fi, and many personal devices are never tunnelled at all.

What mobile threat detection needs to see

Effective detection combines signals from the network and the device. The useful ones fall into five groups:

• Destinations: the domains, server names, IP addresses, and ports a device connects to, checked against mobile-focused threat intelligence.
• Apps: the installed app inventory, app hashes, and permissions, with particular attention to sensitive permissions such as accessibility.
• Traffic behaviour: background connections the user never sees, which are often the clearest sign of malware.
• Connection integrity: TLS certificate metadata that reveals interception on a hostile Wi-Fi or cellular network.
• Device posture: the operating system version, patch level, and configuration weaknesses that make an attack more likely to succeed.

No single signal is enough. A suspicious domain matters more when a new app with accessibility rights contacts it.

The limits of routing mobile traffic through a gateway

One common way to gain mobile visibility is to send device traffic through a cloud gateway or always-on VPN and inspect it centrally. This can work, but it carries three trade-offs.

Coverage depends on the tunnel staying up, so detection stops whenever the profile disconnects or is switched off. The gateway also lacks device context. It cannot see the installed apps, their permissions, or the device configuration that turn a suspicious connection into a confirmed threat. On personal phones, routing every connection through company infrastructure means the organisation handles employees’ personal browsing. That is hard to justify under GDPR, and it tends to undermine BYOD adoption.

How on-device mobile threat detection works

On-device detection moves the inspection to the phone. A security app inspects connection attempts locally, checks them against threat intelligence, and blocks malicious destinations before the connection completes, without sending traffic to a remote gateway. Because the app runs on the device, it can also correlate network activity with the installed apps, their permissions, and the device posture.

This approach works wherever the device goes. It also suits personal phones, because only security findings reach the console.

How mobile threat detection finds phishing on phones

Mobile threat detection finds phishing on phones by checking the destination of every connection against threat intelligence. A malicious page is blocked at the moment of the click, whichever app delivered the link. This matters because the lure often arrives through a channel no security tool can scan, such as an SMS.

Effective mobile phishing detection combines five techniques:

1. It inspects every connection, regardless of the app: A link opened from SMS, WhatsApp, Teams, LinkedIn, or a QR code becomes a connection request, so checking the destination covers every delivery channel at once.
2. It uses threat intelligence built for mobile campaigns: Smishing domains are often registered, used, and abandoned within hours, and feeds tuned for email tend to miss them.
3. It blocks the infrastructure as well as the URL: Phishing kits reuse hosting, so blocking the IP ranges behind known kits catches new pages before they appear on any blocklist.
4. It treats high-risk hosting platforms with caution: Some free website builders host a disproportionate share of phishing pages, so restricting them on work devices removes significant risk.
5. It feeds blocked attempts into the incident process: A blocked click shows who is being targeted and through which channel, which helps you spot a campaign aimed at a particular team.

How to detect mobile malware on employee phones

Mobile malware detection uses two methods. The first checks installed apps against known malware and flags apps that request dangerous permissions. The second watches network behaviour. Even sophisticated spyware must talk to its operators, and that traffic can be detected and blocked.

The network method matters most on iOS, where sandboxing stops security apps from scanning other apps’ files. Blocking command-and-control traffic also stops malware sending data out while the device is cleaned up. Our guide to improving mobile malware detection on work phones covers these methods in depth, and our history of iOS spyware from Pegasus to DarkSword shows how advanced threats have evolved.

What is mobile threat detection for BYOD in 2026?

Mobile threat detection for BYOD runs on employees’ personal phones to find phishing, malware, and network attacks while keeping personal data, messages, and browsing private. In 2026 it has become a core part of employee mobile device security, because personal phones now hold the authenticator apps, email, and SaaS sessions that attackers target.

Three shifts make BYOD detection more pressing this year:

1. AI tools let attackers write fluent, personalised smishing messages at scale, and Verizon’s 2026 Data Breach Investigations Report documents threat actors using AI across the attack lifecycle, from reconnaissance through to initial access.
2. Apple’s User Enrollment and Android’s work profile separate work data from personal data and restrict what IT can see. Threat detection must work without full control of the device.
3. A phishing page that captures a password or MFA code on a personal phone can lead straight into corporate systems, even when the link arrived in a personal chat.

Good BYOD detection meets five tests:

1. It runs locally and sends only security findings to the console.
2. It does not need to read messages or collect browsing history.
3. It protects every app, since a phishing link in a personal WhatsApp chat can still harvest work credentials.
4. It ties access to device health, so a compromised phone, or one with its protection removed, loses access to corporate resources.
5. It is transparent with employees about what it collects and why.

Turning detection into response

Detection is only useful if it triggers a fast response. Your employee mobile device security process should define three things in advance:

• Automatic containment: blocking malicious connections immediately and quarantining a compromised device so it cannot reach corporate data during investigation.
• Access decisions: ensuring only devices known to be secure can reach email, SaaS apps, and internal systems.
• User guidance: alerting the employee in plain language and guiding them through removing a malicious app or updating the operating system.

What to look for in a mobile threat detection solution

When you evaluate enterprise mobile security tools, these questions separate strong detection from basic coverage:

• Does detection keep working on cellular and public Wi-Fi without depending on a tunnel?
• Does it cover phishing that arrives through SMS, messaging apps, and QR codes, as well as email?
• Can it detect malware on iOS as well as Android, given iOS sandboxing?
• Can it block command-and-control traffic by domain, IP address, and port?
• What data leaves the device, and can you explain that to employees using personal phones?
• How has its phishing detection rate been tested, and against which attacks?

For a wider view of the vendors in this space, see our overview of the mobile threat defence software market.

How Corrata protects employee mobile devices

Corrata was built around patented on-device traffic inspection. It observes thousands of data points on each device every day, including device configurations, app hashes, app permissions, domain and server names, IP addresses, port numbers, and SSL certificate metadata. All traffic is processed on the device rather than through an external gateway, so protection follows the phone wherever it connects.

For mobile phishing, Corrata blocks suspicious links using threat intelligence specialised for mobile. This covers SMS, WhatsApp, QR codes, LinkedIn, and other channels. It also blocks the IP ranges used by phishing toolkits and website builder platforms with a high incidence of phishing. If an employee scans a QR code that leads to a phishing page, Corrata blocks the destination.

For mobile malware, Corrata blocks malware download sites, scans installed apps, and monitors apps that use dangerous permissions. By blocking command-and-control traffic across malicious domains, IP addresses, and ports, it disables malware on the device. Automatic quarantining limits the damage while users are guided through removal.

Because processing happens on the device, Corrata does not read the content of messages, and only security-critical information is sent to the cloud. That makes it practical to protect personal phones as well as corporate ones.

To see on-device mobile threat detection working on your own fleet, request a demo of Corrata.

The post How to Detect Threats on Employee Mobile Phones appeared first on Corrata.

Most security teams have started with discovery, building a list of which AI apps are installed across the fleet. That list is a useful first step, but it can’t tell you which app is acting right now, what it touched, or how to stop it.

This guide covers the risks specific to mobile, how to detect AI agents on iOS and Android, and how to build an audit trail your DPO and auditors can rely on. Later in this guide, we’re also upfront about where mobile visibility ends, so you can plan around it.

What are shadow AI agents?

Shadow AI is usually pictured as an employee pasting a document into an unapproved chatbot, and our earlier post on shadow AI on mobile looked at how much of that AI traffic is already moving across mobile fleets. Shadow AI agents go further: they read, decide, and act across company systems using the employee’s own access, with nobody reviewing each step.

The scale of the wider problem is already clear, and Gartner has predicted that by 2030 more than 40% of global organisations will suffer security and compliance incidents due to the use of unauthorised AI tools, a forecast reported by Infosecurity Magazine.

Agents are the sharpest edge of the broader AI governance challenge, because the risk sits in what the software does once it has access, rather than in whether someone typed a prompt.

Why AI agents are hardest to see on mobile

AI arrives inside ordinary apps

Keyboards, document scanners, transcription tools, and note apps increasingly call model APIs directly. None of them appear as “AI apps” on an inventory, and a silent update can add AI to an app that was harmless last week. A static scan of installed software will miss both.

Agents work at machine speed

An agent can read a mailbox, open a file, and upload it in under two seconds. A weekly usage report finds out after the data has already gone, which leaves security teams investigating incidents they had no chance to prevent.

An app that could act is different from one that is acting

Some tools flag every app with permissions that would let it behave as an agent. On Android, for example, accessibility permissions allow an app to read the screen and drive other apps, which is why apps that over-reach on permissions already carry risk. Flagging capability produces a list of suspects. Security teams need to know which app is acting at this moment, and they need a way to stop it.

Five agentic AI security risks to plan for

The risks below are where general AI agent security guidance meets the realities of a mobile fleet.

• Data leaves for unapproved AI services: An agent can pull email, files, or customer records and send them to a model or storage service your organisation has never assessed, which is the problem mobile data loss prevention is designed to address.
• Agents inherit corporate access: An agent working through an app the employee has signed in to Microsoft 365 can reach whatever mail and files that app has been granted, without IT approving anything new.
• Risk can change with an update: An approved app can start talking to a model after an update, so a one-off review of the app catalogue quickly goes out of date.
• Personal and corporate data mix: On BYOD devices, the same phone carries personal messaging, banking, and work email, which makes broad monitoring both intrusive and hard to justify to employees.
• There is no evidence trail: When an agent acts in seconds and leaves no record of what it touched, incident response, audits, and regulatory questions all start from guesswork.

Why an AI app inventory falls short

Discovery answers the first question security teams ask. Runtime control answers the questions that follow.

How to detect AI agents on iOS and Android

Agents leave a recognisable pattern in network behaviour. They loop rapidly between a model and company services, they act while the screen is off, and they work at a pace no human thumb could manage. Because detection looks at behaviour, it can catch an agent inside an app that was never labelled as AI.

Corrata Agent Shield detects and stops AI agents on mobile by reading that pattern on the device, tying each connection to the app that made it, and scoring every session Human, Assisted, or Autonomous in milliseconds.

To make this concrete, consider an illustrative session on an Android phone in a field sales team (the app and data are fictional). A note-taking app sends a short prompt to a model API, reads 48 KB of mail from Exchange, sends a larger prompt, reads a 1.8 MB file from SharePoint, and then attempts a 2.1 MB upload to unapproved storage. Those five actions take 1.4 seconds with accessibility switched on. Agent Shield scores the session Autonomous, blocks the upload, and pauses the session.

What to do when an agent is active

Blocking all AI rarely holds, because employees find workarounds on personal apps and devices. Proportionate responses keep approved AI useful while closing the routes that put data at risk.

• Copilot and your other sanctioned tools can keep working, while uploads to unapproved AI services are blocked or capped by size, app, and user group through the Corrata Advanced DLP controls that power Agent Shield’s guardrails.
• When an autonomous session reaches for email, files, or finance apps, Corrata can pause it and ask the employee on their phone whether it was them. One tap lets the session continue, and without that tap no data moves.
• A device running an unapproved agent can be marked non-compliant in Microsoft Intune, so conditional access cuts Microsoft 365 until the issue is resolved, without adding another console for your team to learn.

Building an AI agent audit trail

Every autonomous session in Agent Shield produces an Agent Receipt, a timeline showing which app acted, which AI service it used, which company systems it touched, how much data moved, and what action Corrata took.

Receipts can flow to your SIEM and to Intune, so they sit alongside the rest of your security evidence. For compliance teams, that record supports conversations with auditors, your DPO, and evidence gathering for the EU AI Act.

Governing AI agents without reading employees’ messages

Agent Shield works on metadata, analysed on the device. It knows an agent moved 2 MB to an unapproved service, and it has no view of what those 2 MB contained. There are no certificates to install, no TLS interception, and no broken certificate pinning, and only verdicts and receipts reach the console.

This approach, which we describe in more detail in our page on privacy by architecture, is built for works council and DPO review. It is BYOD friendly, personal app traffic can be excluded by policy, and Corrata is ISO 27001 certified and EU native, so your AI governance data stays in the EU.

What no mobile security tool can see

No tool has total AI visibility on mobile. AI that runs entirely on the device sends no traffic, the iOS sandbox stops any third party watching one app drive another, platform assistants such as Siri and Gemini run partly on Apple and Google infrastructure, and cloud agents in a remote browser never touch the phone. The Agent Shield page sets out where its visibility ends and how to plan around each gap.

Five steps to bring AI agents on mobile under control

1. Agree which AI tools are approved, and give employees a sanctioned route to use them so they have less reason to look elsewhere.
2. Identify every app on your fleet that communicates with a model, including AI added to ordinary apps through updates.
3. Monitor sessions for agent behaviour, since an installed app tells you far less than what that app is doing.
4. Set proportionate responses that range from asking the user to blocking uploads and cutting Microsoft 365 access.
5. Keep a receipt for every autonomous session, and explain to employees what you can and can’t see, which is central to employee buy-in on BYOD devices.

See it catch a live agent

The quickest way to judge any AI agent security claim is to watch it work. Book a demo and we’ll run an AI agent on a test phone while you watch Agent Shield detect it, score the session, and produce the receipt.

The post Agentic AI security risks on employee phones appeared first on Corrata.

This guide explains what each tool does, where MDM stops, how the two work together, and how to decide what your fleet needs.

What is the difference between MDM and MTD?

The two tools look at different things. MDM looks at the state of the device and whether it is configured the way policy says it should be. MTD looks at what is happening on and around the device and whether it is under attack.

What MDM does

MDM is the tool IT uses to enrol, configure, and control a fleet of devices. Most MDM products have grown into unified endpoint management (UEM) platforms, such as Microsoft Intune and Omnissa Workspace ONE, which manage phones alongside laptops.

Typical MDM tasks include enforcing a passcode and encryption, setting a minimum OS version, deploying and updating apps, pushing Wi-Fi, VPN, and email settings, separating work and personal data, and locking or wiping a device that is lost or belongs to someone who has left. On personal devices, that wipe is usually a selective wipe that removes only company data.

MDM can also check a few security-related settings, including OS version, passcode status, and, in most products, whether a device has been jailbroken or rooted. Those checks describe how the device is configured. They do not inspect the links a user opens, the networks the phone joins, or what installed apps are doing.

What MTD does

MTD is mobile security software, offered by the around ten vendors in our guide to mobile threat defence software, that runs as an app on the device and looks for threats in the device itself, its apps, its network connections, and the links and websites the user opens.

It detects phishing sent by SMS, messaging apps, email, and QR codes, malicious or over-permissioned apps, rogue Wi-Fi and man-in-the-middle attacks, and signs of compromise such as spyware. When it finds a threat, it can block it on the device, warn the user, and report a risk level that other systems act on.

Comparing MDM and MTD

Is MDM enough to secure company phones?

For most organisations it falls short, because MDM was built to manage devices and has no view of the attacks that most often reach phones.

Take a phone that passes every MDM check, with a passcode, a current OS, and only approved apps. Its user can still tap a phishing link in a WhatsApp message, enter their Microsoft 365 password on a fake login page, or join a hotel Wi-Fi network that is intercepting traffic. MDM reports the phone as compliant throughout, because none of those events changes how the device is configured.

There are two further gaps. MDM covers only enrolled devices, so personal phones used for email and Teams, and contractors’ devices, often sit outside it entirely. MDM also evaluates compliance when a device checks in, so it has no way to react the moment an attack starts.

MDM remains essential for the job it does. Detection is the part it leaves uncovered, and that is the job MTD is built for.

What MDM misses without mobile threat defence

MDM can confirm that a device is configured correctly, but most of the threats that reach phones never touch that configuration. Without MTD, four kinds of attack go unseen.

• Phishing outside email: Links sent by SMS, messaging apps, collaboration tools, and QR codes bypass the email filters most organisations rely on, and MDM has no view of the links a user opens.
• Malicious and over-permissioned apps: MDM can deploy approved apps and restrict others, but it does not analyse what an installed app is doing, so mobile malware hidden inside a legitimate-looking app goes unnoticed.
• Network attacks: A phone that joins a rogue hotspot or a network that is intercepting traffic still shows as compliant, because MDM does not inspect the device’s connections.
• Compromise and spyware: MDM checks whether a device is jailbroken or rooted, but advanced spyware usually runs without leaving those signs, and connections to attacker infrastructure are invisible to it.

MTD covers each of these on the device and turns what it finds into a risk level, which is where the two tools start to work together.

Do I need MTD if I already have MDM?

If your phones and tablets can reach company email, files, or SaaS apps, you almost certainly do. MDM keeps the device set up correctly, and MTD covers the threats that a correctly set-up device can still meet.

The two also make each other more useful. MDM can deploy the MTD app silently to enrolled devices, so users do not have to install anything. MTD in turn gives MDM and your identity provider a risk signal that configuration checks could never produce, so a phone that has just connected to a malicious network can lose access before any compliance check would have noticed.

Some organisations already have an MTD option through an existing vendor. Microsoft 365 E3 and E5 include Microsoft Defender for Endpoint, which has apps for Android and iOS, and our comparison of Corrata and Microsoft Defender for Endpoint on mobile covers how that option works. Whichever product you look at, test whether it detects threats across messaging apps as well as the browser, and whether it covers the personal devices your MDM does not reach.

How MDM and MTD work together

On a managed device, the two tools form a loop. The MDM enrols the device, applies policy, and deploys the MTD app. The MTD app then monitors the device, its apps, and its connections, blocks what it can immediately, and calculates a risk level.

That risk level feeds compliance and conditional access, so a device with an active threat loses access to company apps. Once the user fixes the problem, for example by removing a malicious app or updating the OS, the risk level drops and access returns without IT having to step in.

For a wider view that also covers mobile EDR and SIEM integration, see our guide to mobile endpoint security.

MDM and MTD on personal devices

Personal phones are where the difference between the two tools matters most. Employees are often reluctant to enrol their own phone in MDM, since full enrolment gives the employer control over a device they paid for, and many organisations do not ask them to. Those phones still read company email and join Teams calls.

MTD can protect a personal device without MDM enrolment. The app is installed from an email or SMS invite, protects against phishing, malicious apps, and network attacks, and can report the device’s risk into access decisions. Before rolling out any MTD product to personal devices, check what it collects; Corrata sets this out in its product privacy statement.

How to decide what your fleet needs

If you manage corporate-owned phones through Intune or Workspace ONE, keep the MDM and add MTD, then connect MTD’s risk level to compliance and conditional access so that a detection changes what a device can reach.

If staff also use personal phones for work, run MTD on those devices through invite-based installation, and base access to company apps on device risk instead of enrolment status.

If you run a smaller fleet without MDM, MTD on its own covers the threats, although you will still lack central configuration, app deployment, and remote wipe. Corrata Essentials is built for fleets of up to 250 devices.

How Corrata works alongside your MDM

Corrata provides mobile threat defence for iOS and Android, protecting corporate-owned and personal devices in the same platform. It integrates with the leading MDM platforms, including Microsoft Intune and Workspace ONE, for zero-touch deployment, and personal devices activate from an email or SMS invite.

It also works with identity providers including Microsoft, Google, and Okta, and with EDR and XDR tools such as Microsoft Defender for Endpoint.

Detection runs on the device. Corrata blocks phishing links across SMS, messaging apps, email, and browsers, detects rogue Wi-Fi and adversary-in-the-middle attacks, blocks connections to command-and-control infrastructure, and flags dangerous apps, jailbroken or rooted devices, outdated operating systems, risky configurations, and spyware.

When it finds indicators of compromise, the device can be blocked from enterprise apps until the issue is fixed, and the user gets guided steps to resolve it.

To see how Corrata would sit alongside your current MDM, you can request a demo with our team.

The post MDM vs MTD: what each one does for company phones appeared first on Corrata.

It usually spans three layers:

1. Mobile endpoint management controls how devices are configured.
2. Mobile threat defence detects and blocks attacks.
3. Mobile endpoint detection and response brings the visibility and response options security teams rely on for laptops and servers to phones.

Most organisations have the first layer in place and assume it covers the other two. This guide explains what each layer does, where the gaps usually sit, and what to ask vendors when you close them.

What is mobile endpoint security?

A mobile endpoint is any phone or tablet that connects to company data, including email, Microsoft 365, SaaS apps, and internal systems. Mobile endpoint security protects those devices, the data on them, and the accounts they can reach, across iOS, iPadOS, and Android.

Phones need their own approach because they work differently from laptops. Apps run in sandboxes that limit what a security tool can see, and software arrives through app stores rather than IT-controlled installers.

Devices also move between home, office, and public networks throughout the day, and the same phone often carries personal messaging, social media, and work apps side by side. Desktop security tools were built for a different operating model, so they rarely translate directly to mobile.

Why phones are the weakest point in most endpoint strategies

Attackers target phones because they hold credentials, MFA approvals, and access to email and collaboration tools, and because they are watched less closely than laptops. The most common threats are:

• phishing links sent by SMS, messaging apps, and QR codes
• malicious or over-permissioned apps
• attacks on public and rogue Wi-Fi networks
• devices left on outdated OS versions with known vulnerabilities

Phishing is also more effective on mobile than in the inbox. The Verizon 2026 Data Breach Investigations Report found that phishing simulations using text messages and voice calls had a median click rate about 40% higher than email. These messages bypass the email security tools most organisations rely on, which is why SMS and messaging-app phishing so often reaches employees unfiltered.

Many of the types of malware that affect laptops now have mobile equivalents. They are also harder to spot, because the sandboxing that protects users limits what mobile malware detection tools can observe.

Personal devices widen the gap further. Many organisations let staff read email or use Teams on personal phones that are not enrolled in MDM. IT then has no view of the device’s health, even though the phone can still reach corporate data.

The three layers of mobile endpoint security

The table below compares them.

Mobile endpoint management (MDM and UEM)

Mobile endpoint management covers the tools IT uses to enrol, configure, and control devices. These include mobile device management (MDM) and unified endpoint management (UEM) platforms such as Microsoft Intune and Workspace ONE, which manage phones alongside laptops.

They set passcode and encryption rules, deploy and update apps, enforce a minimum OS version, separate work and personal data, and lock or wipe a device if it is lost.

These controls deal with configuration and policy. An MDM can confirm that a phone has a passcode and a current OS, but it cannot see a phishing link in a WhatsApp message, a rogue Wi-Fi hotspot, or an app quietly sending data to an unknown server. It also only covers enrolled devices, which usually leaves out personal phones and contractors.

Compare MDM vs MTD

Mobile threat defence (MTD)

Mobile threat defence adds the detection that management tools lack. It runs as an app on the device and looks for threats in four areas: the device itself, its apps, its network connections, and the links and websites the user opens.

When it finds a threat, it can block it, warn the user, and pass a risk score to the management and identity layers. MTD is a well-established category, with around ten vendors compared in our mobile threat defence software guide, and most of them integrate with the major UEM platforms.

Mobile endpoint detection and response (mobile EDR)

Mobile EDR applies the EDR model to phones. That means continuously collecting device, app, and network events, raising alerts, and supporting investigation and automated response within the same SOC workflow used for laptops and servers.

In practice, the line between MTD and mobile EDR has blurred because many MTD platforms now include detection and response features. The term is mostly used to describe how deeply a product supports the security team once a threat is found.

Can your EDR protect mobile devices?

Many security teams assume their existing EDR already covers phones. Desktop EDR depends on deep access to the operating system, including process activity, file system changes, memory, and kernel events.

iOS and Android do not give third-party security apps that level of access, so a desktop agent cannot simply be installed on a phone.

This changes how detection and response works on mobile. Mobile tools rely on the signals that are available to them:

• network traffic and the destinations apps and browsers connect to
• installed apps and their permissions
• device configuration
• operating system integrity

The strength of a mobile EDR capability depends on how much it can learn from those signals and how quickly it acts on them.

Some EDR platforms extend to mobile through their own apps. Microsoft Defender for Endpoint, for example, has apps for Android and iOS, and our comparison of Corrata and Microsoft Defender for Endpoint on mobile sets out how the two approaches differ. Whichever route you take, test the mobile product against the requirements checklist instead of assuming it matches the desktop agent.

What mobile endpoint detection and response should include

A mobile detection and response capability should cover five areas.

Real-time detection and on-device remediation

The tool should act the moment a threat appears, for example by blocking a phishing site, cutting traffic to a malicious server, or warning the user, without waiting for an analyst to step in. Users should also get clear guidance on fixing issues they control, such as updating the OS or removing a risky app.

Risk-based conditional access

Detection becomes far more useful when it changes what a device can reach. The device’s risk level should flow to your identity provider or UEM, such as Microsoft Entra ID and Intune. Access to Microsoft 365 and other SaaS apps can then be blocked or limited until the threat is resolved. This is how zero trust principles extend to phones.

Automated response through integrations

For higher-risk threats, the platform should trigger action in the tools you already run. Examples include a selective wipe or app removal through the UEM, quarantine through network access control, or a policy change on the firewall. Look for controls over which responses run automatically and which need approval.

Investigation telemetry and threat hunting

Security teams need enough history to investigate an incident properly. That means device, app, and network events kept long enough to look back over weeks or months. Ask how long each type of data is retained and whether longer retention costs extra. For high-risk users, on-demand forensic collection such as iOS sysdiagnose files and Android bug reports adds valuable depth.

Threat intelligence and false-positive control

Detection is only as good as the intelligence behind it. Ask where the threat data comes from, how often it updates, and how the vendor handles new domains that no list has seen yet. How the tool handles mistakes matters just as much. Look for allow-listing, a simple way for users to report a wrongly blocked site, and a team that reviews those reports quickly.

How MDM, MTD, and EDR work together

Management, threat defence, and detection and response are designed to be combined. On a managed device, a typical flow runs as follows:

1. The UEM enrols the device, applies policy, and deploys the threat defence app silently.
2. The threat defence app monitors the device, its apps, and its connections, blocks what it can immediately, and calculates a risk level.
3. That risk level feeds conditional access in the identity provider, so a compromised phone loses access to corporate apps until it is fixed.
4. Alerts and telemetry flow into the SIEM, where the SOC can investigate mobile events alongside laptop and server activity.

Personal devices outside MDM can still be covered. The threat defence app can be installed from an email or SMS invite and report device risk into access decisions, giving security teams a view of phones that IT does not manage. The data on those phones needs protecting too, which is where mobile data loss prevention and controls on employee use of AI tools complete the picture.

How to Choose Mobile Endpoint Security in 2026

Mobile endpoint security requirements checklist

Use these questions to assess your current setup or to compare vendors.

• If an employee taps a phishing link in a text, a WhatsApp message, or a QR code, what stops the page from loading, even if the site was set up only hours earlier?
• Can you protect phones that IT does not manage, such as contractors’ and employees’ own devices? What do those users need to do to get protected, and how does their protection compare with a managed phone?
• How would you know if a phone had been jailbroken, was running an unsupported OS version, had its screen lock switched off, or had been targeted by spyware?
• Can you tell which apps on a phone are malicious or ask for more access than they need, and which AI tools your staff are using?
• What happens when a phone joins a fake hotspot or a network that is intercepting traffic, and is app traffic checked as well as browser traffic?
• When a threat is found, what happens without anyone stepping in? How does the device’s risk level affect what it can access, and how much history is kept for investigations?
• Which management, identity, and SIEM tools does it work with today, and how do alerts reach the right people?
• What can your admins see on an employee’s personal phone, how noticeable is the app on battery and performance, and is it available in the languages your staff use?

How Corrata approaches mobile endpoint security

Corrata provides threat detection and response for iOS and Android, protecting corporate-owned and personal devices in the same platform. Devices enrolled in a UEM activate through zero-touch deployment, and personal devices activate from an email or SMS invite. Corrata supports iOS 14.0 and Android 7.1 onwards.

Detection runs on the device using Corrata’s in-house engine. Traffic is inspected through a local loopback VPN that works alongside a corporate VPN, with a battery impact of around 1.25%. This lets Corrata block phishing links across SMS, messaging apps, email, and browsers, including newly registered sites and adversary-in-the-middle kits built to steal MFA codes. It also stops malicious destinations reached through QR codes.

On the network side, Corrata detects rogue Wi-Fi and man-in-the-middle attacks and blocks connections to command-and-control infrastructure at DNS and IP level. On the device itself, it flags jailbroken or rooted devices, out-of-date operating systems, risky configurations, and mercenary spyware.

When a threat is found, Corrata acts on the device in real time and can restrict access until the issue is fixed. Alerts flow into your SIEM, and Corrata’s security research team maintains a database of around 250,000 zero-day domains to keep detection current.

Corrata’s product privacy statement sets out what is collected from personal devices, and the app is available in English, French, Spanish, and German. Corrata is ISO 27001:2022 certified and runs an annual third-party penetration test. Every customer gets a named customer success manager, along with onboarding and admin training.

If you are reviewing your own stack, you can work through the requirements checklist with our team to see where Corrata fits.

The post Mobile endpoint security: Closing the MDM and EDR Gap appeared first on Corrata.

This post is for IT and security teams comparing Corrata vs Zimperium, or looking for a Zimperium alternative. The useful question is not which product has more features. It is where each product gets its information from, and what that means for the risks you care about. Every claim below, for both products, links to the vendor’s own product page.

What we compared, and what we did not

This comparison covers Zimperium Mobile Threat Defense (MTD) and Corrata Mobile Threat Defence Software. Zimperium’s Mobile Application Protection Suite (MAPS) is out of scope, as it protects apps a company publishes, not employee devices. The Mobile SOC Agent and Advanced Remote Security Diagnostics are included, though Zimperium sells both as paid additions to MTD.

Both products deploy through MDM and integrate with identity, SIEM, EDR and XDR platforms.

Corrata vs Zimperium: the short version

The short answer

Zimperium Mobile Threat Defense builds its picture from the device: OS state, app behaviour, app binaries and network safety. It runs on iOS, Android and ChromeOS, with cloud, on-premises, air-gapped and FedRAMP deployment, and an optional AI agent for incident triage.

Corrata builds its picture from the traffic: what the device sends, across all ports and key protocols, inspected on the device. It runs on iOS and Android, is EU-based, and never reads an employee’s messages or files.

If you need Chromebooks, on-premises or air-gapped deployment, or FedRAMP, Zimperium has those. If your questions are about AI and SaaS traffic, encryption quality, packet-level evidence or European data governance, Corrata is the fit.

Anyone weighing a Zimperium alternative should start with where each product gets its picture of the device from.

Zimperium gets its picture from the device. It watches what the OS is running, how apps behave, what is in the app binary, and whether a network is unsafe. That is why its app vetting and device checks are as broad as they are, and why it runs on ChromeOS and in air-gapped environments.

Corrata gets its picture from the traffic. Its patented on-device traffic inspection watches what the device sends, across all ports and key protocols, at the network level rather than the app level. That is why control does not depend on DNS visibility, why individual domains, servers, ports and IP ranges can be blocked, and why policy can target a single service rather than an app or a category.

Neither approach covers everything the other does. That is why several rows are draws. Here is how it plays out across six areas.

Phishing that arrives outside the browser

Most mobile phishing no longer arrives by email. It arrives by SMS, WhatsApp, iMessage, a QR code or a search result. Both products detect across those channels on the device, not at an email gateway.

Zimperium’s Mobile Phishing Protection claims detection of known and zero-day phishing across email, SMS, QR codes and in-app messaging, on iOS, Android and Chromebook.

Corrata’s Mobile Phishing Protection inspects traffic on the device in real time. Zero Day Protection blocks destinations with no reputation history rather than waiting for one to build. Phishing sites often live for only a few hours, which is where reputation checks struggle. We would rather block an unknown destination briefly than let it through while it is classified.

Data leaving the device, including AI chatbots

This is the fastest-growing gap. Staff paste company data into whichever AI assistant is open, and on mobile most security teams cannot see it. Both products address it. The difference is where control sits.

Zimperium controls it at the app. Its app vetting identifies AI SDKs, permissions and data flows, applies AI-specific web content filtering, and uses a policy engine to mark apps non-compliant and restrict access. Zimperium also says policy can cover where apps communicate geographically and support data sovereignty requirements. If your question is “which installed apps contain AI, and what can they access”, that is what the app-side model answers.

Corrata controls it at the traffic. Shadow AI and DLP controls access to unsanctioned AI and SaaS, monitors file uploads to unsanctioned LLMs, email and file-sharing services, and lets you allow, report, block, or monitor individual SaaS services.

A sanctioned service stays available while an unsanctioned one is blocked, whichever app sent the traffic. That includes a chatbot opened in a browser tab, which an app-level control sees only as browser traffic. Corrata’s own detection data found AI traffic on 84% of customer fleets over six weeks, growing about 40% a month, with 69% of AI domains never seen before.

Spyware, forensics and containment

Mercenary spyware is a niche concern for most organisations and a serious one for a few: legal, journalism, public sector, anyone of interest to a nation state. Dealing with it needs continuous visibility, a way to collect evidence from a suspect handset, and a way to contain the device quickly.

Both products monitor continuously, in different ways. Zimperium detects on-device exploits and device compromise, and lists on-device forensic analysis for threat hunting. The signal comes from the device and its apps. Corrata’s spyware protection constantly monitors device settings and network activity, across all ports and key protocols. The signal comes from what the device sends. A compromise that leaves no trace on the device, or hides inside a legitimate app, still shows up in its traffic.

For evidence, Zimperium offers a user-run forensic scan, footnoted as iOS only at this time, and a paid feature called Advanced Remote Security Diagnostics that collects Android security logs every 24 hours and guides users to upload Android bug reports and iOS system diagnostics. Packet capture is not listed. Corrata lets users send diagnostics to admin to collect and analyse, including network packet captures. A packet capture shows whether a suspected implant is actively communicating, where to, and over what.

For containment, Zimperium disconnects on network threat detection and runs broader response through the MDM, UEM or identity integration. How precise that response is depends on the integration in place. Corrata automatically quarantines the device from sensitive systems while analysts review the data, with remediation applied automatically and no UEM policy needed.

Is the device talking to the right server, and can anyone else see it?

Zimperium states that MTD detects unsafe and rogue networks, warns on attempts to connect, and identifies malicious networks nearby. App vetting separately flags apps that use insecure communication.

Corrata approaches the same problem from a different starting point. The network a device joins is only the first link in a chain that runs through carriers, exchanges, and intermediaries before it reaches the server. A mobile network can be compromised, or can cooperate with a state actor. A hotel Wi-Fi can be clean while the connection beyond it is not. Weak cipher suites, outdated TLS versions, and apps sending sensitive data over encryption that should not be trusted happen on perfectly legitimate networks. On that view there is no such thing as a safe network, only connections that are protected end to end and connections that are not.

So rather than asking whether the network is trustworthy, Corrata checks whether each connection is: that the device is talking to the server it intends to, and that nobody in between can read or interfere with the traffic. Adversary-in-the-Middle Protection inspects the TLS handshake on the device and reports weak cipher suites, on every connection, on every network, with blocking as an administrator policy choice.

Employee privacy and permissions

Zimperium states that privacy settings are granular across Location, Application, Network and Device data, that a BYOD policy group can be set so information never leaves the device, and that users can adjust what the app transmits. Personal email, documents, contacts, calendar, passwords, pictures and videos are never collected, and the GDPR right to be forgotten is supported.

The practical difference is that Zimperium’s privacy outcome is a configuration. Location is a collectable category, and what a fleet transmits depends on how the admin and the user have set the policy. That suits mixed fleets. It also means the answer to “what does this agent see” depends on policy, not architecture.

Corrata does not read messages, scan files, record browsing history or require sensitive permissions. It sees connection metadata: domain and server names, IP addresses, ports, certificate metadata, app hashes and permissions. That is domain-level metadata, not full URLs, page content or search terms. Corrata explains the difference to staff as part of employee buy-in.

Headquarters, GDPR and deployment

Zimperium is headquartered in Dallas, Texas. Its MTD page lists cloud, on-premises, air-gapped and FedRAMP deployment. No EU hosting region is named on the product pages or solution briefs, so a European buyer should ask where their tenant would sit and what transfer mechanism applies.

Corrata is a European cybersecurity company headquartered in Dublin, ISO 27001 certified. Its on-device design is built to make compliance with strict data protection standards straightforward. For UK and Irish public-sector and financial-services buyers, a European processor under GDPR removes a step from procurement. 

Deployment is a draw. Zimperium offers zero-touch deployment and MDM, EMM and UEM integration. Corrata offers zero-touch deployment for managed and unmanaged devices, Intune and Workspace ONE integration, and email or SMS enrolment for BYOD or organisations without MDM.

Where compliance comes into it

Neither NIS2 nor DORA names mobile threat defence, and no product makes you compliant. Both expect you to show the measures you have in place and how you detect and report incidents. Mobile is usually the part of the estate with the least to show, and DORA’s reporting deadlines are short.

Zimperium covers a good deal of this. Devices report into a console, alerts feed your SIEM, posture feeds conditional access, and the Mobile SOC Agent can produce an incident narrative for your reporting process. For regulated EU organisations, the open questions are where that data is processed and whether you can reconstruct what left a handset.

Corrata covers the same ground from the traffic side: control over data going to unsanctioned services including AI, device diagnostics, packet capture and quarantine for a suspect device, from a European processor, integrating with SIEM and your identity provider.

Corrata as a Zimperium alternative: which one do you need?

Zimperium Mobile Threat Defense is a credible choice, and this comparison is not an argument against it. 

Choose Corrata if:

• EU data governance is a priority and you want a European vendor
• You want one platform that scales from an SME fleet of up to 250 devices to a large enterprise estate, with the same level of protection at every size
• You need to see and control which AI and SaaS services the fleet uses, including from a browser
• You want spyware detection based on what the device sends, with packet captures from a suspect device as evidence
• You have a BYOD environment where “the agent cannot read messages or files, under any configuration” is the answer you need to give

Choose Zimperium if:

• You have a SOC or MSSP and want an AI agent that investigates and triages mobile incidents for them
• You want deep run-time analysis of individual apps, including which AI SDKs they embed
• You want automated collection of Android security logs across the fleet without user involvement
• You want privacy settings you can tune per device group, including what location and personal data is collected

Whichever list you recognise, a purpose-built mobile threat defence layer is what answers it. The category is also written as mobile threat defense.

Book a demo to see what Corrata finds on a handful of your own devices.

The post Corrata and Zimperium Mobile Threat Defense: How they compare on mobile appeared first on Corrata.

This is the new tactic that is employed by attackers.

Recruitment scams have always been around but now with the difficulty rising in the job market and job hunt, many people would do anything that would lead them closer into landing a job. This new scam is employed by malicious actors, where they mimic the Indeed job platform. The victims often are reached out to by the bad actors in the form of SMS messages, asking them to download an app called IndeedInterview to attend the interview or schedule it for a later date. 

Once installed on the device, the malware works to steal the credentials of your accounts. Even if the app is not installed on the device, just the mere act of clicking on the link is enough to let the bad actors know that this device / user / number is prone to clicking any links that come through the SMS. This campaign was active in the Middle East, but there are chances that they are employing these tactics in different regions of the world.

It is particularly targeted at mobile devices, since if a person were to access the website on their desktop it would navigate or prompt them to open the website on their phone. 

The application is not active at the moment, however the domain that was used in this campaign is still active. It has not changed the way it operates, however we have observed on certain networks that it does change the way it operates.

When the website is accessed on the desktop, it displays a QR code, asking the user to scan the code which opens the phishing website on the device, and in some cases it displays a fake job listing for a remote job in Canada with an option to email the “recruiters” with information about the CV.

Following this, it is likely that they would ask the users to download an application attached with the email or scan a QR code which will lead the user to a page where they can download the malware onto the device. 

We performed our own investigation into this based on the report from MalwareBytes.

Workflow of the attack

Date tested: Sep 25, 2026
Devices used: Samsung A15, Samsung Galaxy Z Flip
Android version: Android 16

Below is a screen recording of the workflow.

Technical Details 

There were many interesting things that were found through deeper investigation of this malware. Like any malware of recent times, it installs an innocuous file, following which a dropper is installed on the device. This is the main malicious payload that causes harm. 

The malware APK is completely obfuscated with an encryption making it difficult for it to be analysed through traditional tools like Android Studio. When we accessed the link, we were able to download multiple files of the malware. Each version of the malware that was downloaded onto the device, had a different hash value, different package name, and in some cases, even the icon colour of the malware was different. 

The attackers made use of an interesting technique called server side polymorphism. This means that whenever a victim tries to download malware onto the device, the code is rearranged internally on the server side, as well as changes the package name of the malware. 

This is used to evade detection as multiple services traditionally check for the SHA256 Hash values and packages name, which are not changed. This is also why Play Protect and many third party vendors were able to detect only one version of the malware when it was reported. 

At the time of our investigation, Play Protect was not able to detect the presence of the different versions of the malware. 

On the analysis of the APK file, we were also able to find the various possible package names as well as function names, to avoid easy analysis, and identification of each function present in the code. The malware asks for extensive permissions along with accessibility services permission. However this accessibility permission is specifically for the Dropper. 

Although the functionality of the malware is the same, which behaves like a spyware and exfiltrates the data from the device, the permissions that each version of the malware APK require is different. This is possibly done to evade detection as much as possible, as it would change the file size and hash value significantly.

An XML file called deviceStreaming.xml was found to have a list of devices, manufactures and models. The purpose of this file is that when a particular model / device is detected then the data exfiltration can happen. This potentially leads us to believe that this piece of malicious software has spyware capabilities.

We were also able to detect the possible versions of the package names and functions that could be employed by the malware. This was identified as they were not being in any location inside the file or calling any function. An extensive list of words consisting of jumbled up letters was found. For each version of the malware that was downloaded the list of words changes.

When the innocuous looking file is installed on the device, it asks you to log in, set up a VPN connection, and then update the app. The reason for the VPN connection is that all the traffic goes through the attackers VPN service with nothing to interfere with it. 

The dropper named “Updater” is then installed on the device. We observed that if dropper is not installed correctly or not given the necessary permissions, it is incredibly persistent. With unnecessary notifications as well as the vibrate effect on the device, it would annoy the victim into granting the permissions it is asking for. Both the devices that we completed the tests on were part of the list. 

Once this act is done, the phone performs a temporary update, and all the permissions are granted to the malware. This will be completely hidden from the main screen and it can be seen only in the Settings under Apps. It is very difficult to remove, for if you try to access the application, it immediately closes the screens. 

The malware is also quite clever, if it detects an emulator, the innocuous app completely crashes and does not run on the device. 

How to spot and avoid fake interview apps

• Whenever you have to install an app for an interview, double check if it is from a legitimate source such as Play Store, and confirm that the person who sent it to you is legitimate company. 
• We have noticed an increase in malwares asking for VPN connection, to evade detection and sending data safely to the C2 servers. 
• Applications downloaded from any source asking for accessibility permission should be proceeded with caution. 

Indicators of Compromise 

• Startcareer[.]org
• Api[.]flowerscantdie[.]com
• Drive-interview[.]cloud
• Api[.]interviewtoday[.]info

Currently all these domains are active, and should be dealt with caution.

About Corrata

Corrata provides mobile threat defence for iOS and Android, including protection against apps that over-reach on permissions or come from outside the official stores. 

See how Corrata approaches spyware detection on employee devices.

The post How a fake Indeed interview app hides spyware on Android phones appeared first on Corrata.