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.

Malware is any software written to damage, disrupt or gain unauthorised access to a device or the data on it. The main types are viruses, worms, trojans, ransomware, spyware, mercenary spyware, adware, keyloggers, rootkits, backdoors, botnet malware, infostealers, banking trojans, cryptojacking malware, and fileless malware. They differ in how they spread, what they take and how visible they are once installed.

Most guides to malware describe a world of desktops and servers. That world has changed. Google’s Android security team reported that Play Protect identified more than 27 million new malicious apps from outside Google Play during 2025, up from 13 million the year before, and blocked 266 million risky sideloading attempts through its enhanced fraud protection, which now covers more than 2.8 billion devices across 185 markets.

The phone in an employee’s pocket is a primary target rather than an afterthought. Verizon’s 2026 breach report found the success rate of mobile social engineering up 40% year on year, with mobile named among the fastest-growing targets.

How many different types of malware are there?

Malware is classified by behaviour rather than by a formal standard, so published lists range from about seven categories to thirty. Most settle on around 15 core types, with newer families such as infostealers and mercenary spyware treated as distinct categories only in recent years.

Real samples combine behaviours: a single dropper delivered through a messaging app may install a banking trojan that also works as a keylogger and a botnet client.

The 15 types of malware at a glance

1. Viruses

A virus attaches itself to a legitimate file or program and spreads when that host is executed, so it needs a user to run something for the infection to progress. The term is often used loosely to mean all malware, but true viruses are now a small share of what security teams encounter. On phones, application sandboxing makes classic viral spread between apps impractical.

2. Worms

A worm copies itself across networks without user action, usually by exploiting a vulnerability in an exposed service. Worms cause some of the fastest-spreading incidents on record because propagation is automatic. They matter mainly on corporate networks and unpatched servers rather than on managed mobile fleets.

3. Trojans

A trojan presents itself as something useful, then delivers a hidden payload once installed. This is the dominant model in mobile malware. Attackers often use a two-stage approach, publishing a clean-looking utility that later fetches the real payload, which is one reason installing apps from outside the official stores carries a different level of risk. Kaspersky’s researchers described that pattern in the second quarter of 2026, when a trojanised PDF reader hosted on Google Play showed users a fake update request in order to drop the Anatsa banking malware.

4. Ransomware

Ransomware encrypts files or locks a device and demands payment for restoration. Most operators now steal data before encrypting so they can extort victims a second time by threatening publication. Verizon’s 2026 Data Breach Investigations Report, which analysed more than 22,000 confirmed breaches across 145 countries, found that 73% of ransomware victims had an associated infostealer infection or credential leak in the year before the attack, and that the median ransom payment fell to around $140,000 with 69% of victims declining to pay. Mobile ransomware remains rare by comparison: Kaspersky counted 570 mobile ransomware installation packages in a quarter that produced more than 304,000 malicious packages in total.

5. Spyware and stalkerware

Spyware monitors activity and exfiltrates what it finds, including messages, location, contacts and microphone audio. Stalkerware is the commercial variant, marketed as parental or employee monitoring and installed by someone with physical access to the device. Both are difficult to detect from the handset itself because they are built to leave no visible trace.

6. Mercenary spyware

Mercenary spyware is a separate class of surveillance implant developed by private vendors and sold to government buyers, and infection often requires no interaction from the target. Apple describes these attacks as vastly more sophisticated than ordinary cybercriminal activity and operates a threat notification system to warn individuals it believes have been targeted, sending a further round of alerts to users across 110 countries in August 2026. Citizen Lab researchers have forensically confirmed cases of journalists compromised by Paragon’s Graphite spyware, including one device attacked through a zero-click iMessage exploit.

Executives, legal teams and anyone handling sensitive negotiations sit closer to this threat than they tend to assume. The delivery methods have shifted over time, from zero-click messaging chains towards web-based exploitation, which we cover in our breakdown of Pegasus and the spyware families that followed it.

7. Adware

Adware injects advertising, redirects browsing and tracks behaviour for resale. It is treated as a nuisance rather than a breach, which is why it persists. The practical harm is data leakage, since adware SDKs bundled into free apps can send device identifiers, location and usage data to parties the organisation has no contract with.

8. Keyloggers

A keylogger records what the user types and returns it to an attacker, which is the simplest route to usable credentials. The mobile equivalent is abuse of accessibility permissions, which allow an app to read screen content and input across other applications. An app that requests accessibility access without an obvious reason should be treated as hostile, and the same applies to the other Android permissions malware relies on, including notification listener access and device admin rights.

9. Rootkits and bootkits

A rootkit modifies the operating system to conceal an attacker’s presence and survive normal clean-up, and a bootkit goes lower still by loading before the operating system does. Both are expensive to build and appear mainly in targeted intrusions. Stock iOS and Android devices resist them, though jailbroken or rooted handsets lose that protection.

10. Backdoors and remote access trojans

A backdoor creates a hidden entry point for future access. A remote access trojan gives an attacker interactive control, including reading files, capturing the screen and switching on the camera or microphone. On mobile they usually arrive inside apps installed outside the official stores, often after a call or message that persuades the user to bypass a security warning, and once installed a remote access trojan inherits every privilege the employee has.

11. Botnet malware

Botnet malware enrols the device into a network of compromised machines directed from a central server. Infected devices are then used for distributed denial of service attacks, credential stuffing, ad fraud or residential proxy services. Handsets are attractive for this because their traffic looks like ordinary consumer activity.

12. Infostealers

Infostealers harvest saved credentials, session cookies, authentication tokens and cryptocurrency wallets in a single pass, then exit. Because they capture live session tokens, they can defeat multi-factor authentication by bypassing the login step entirely. Stolen data is sold on in bulk, which is why an infostealer infection on one device often precedes an apparently unrelated intrusion months later. Kaspersky’s Q1 2026 reporting described a new version of the SparkCat crypto stealer found in apps on both Google Play and the App Store, with the iOS build using Apple’s Vision framework to read text from images held on the device.

13. Banking trojans and overlay malware

Banking trojans wait for a banking or payment app to open, then draw a convincing fake login screen over the top and capture the credentials entered. They are the largest category of mobile malware by volume. In the second quarter of 2026, Kaspersky found that Trojan-Banker samples accounted for 30.77% of detected malicious applications, with 93,574 mobile banking trojan installation packages identified in that quarter alone. The same overlay technique works against corporate single sign-on screens, which is why app risk on employee devices is a credential problem rather than a device hygiene problem.

14. Cryptojacking malware

Cryptojacking malware uses the device’s processor to mine cryptocurrency for someone else. There is no data theft, so it often runs undetected for long periods. On a phone the symptoms are heat, battery drain and throttled performance, which users tend to attribute to an ageing handset.

15. Fileless malware

Fileless malware never writes an executable to disk. It runs in memory and abuses tools already present on the system, such as scripting engines and administrative utilities, which allows it to pass signature-based detection. Defending against it depends on behavioural monitoring rather than file scanning.

Other categories worth knowing

Several further terms appear in malware taxonomies without forming large categories in their own right. Wipers destroy data outright and are used for sabotage rather than extortion. Scareware produces fake infection warnings to sell worthless software. Logic bombs stay dormant until a condition is met. Toll fraud malware silently signs mobile users up to premium-rate services. Droppers and loaders exist only to install something else, which is how an app that passed review can turn malicious later.

What are the dangers of the different types of malware?

Grouped by outcome rather than by family, the damage falls into five categories.

• Financial loss: Ransom payments, fraudulent transactions enabled by banking trojans, and premium-rate charges from toll fraud.
• Data loss and regulatory exposure: Infostealers and spyware remove personal and commercial data. Under GDPR, a notifiable breach brings supervisory authority involvement and potential fines regardless of how the data left.
• Operational disruption: Ransomware and wipers stop the business functioning. The cost sits in downtime and recovery rather than in the ransom itself, and organisations that have never tested whether they can operate with key systems offline tend to discover the answer during the incident.
• Loss of access control: Backdoors, keyloggers and infostealers hand over credentials and session tokens, turning one infected device into a route into every connected system.
• Surveillance: Spyware and mercenary spyware expose negotiations, legal strategy, client information and the movements of named individuals.

What are the different types of malware attacks?

The malware family describes what runs on the device. The attack describes how it arrives.

• Phishing and smishing: A message from a bank, courier or internal service prompting the user to install something or enter credentials. On mobile this arrives through SMS, WhatsApp, LinkedIn and QR codes as readily as through email, and most mobile phishing now lands outside the inbox entirely.
• Sideloading under social engineering: The attacker talks the user through installing an app from outside the store and dismissing the warnings. Google now blocks Play Protect from being switched off during an active phone call because criminals impersonating bank staff walk victims through that step.
• Malicious apps in official stores: Review processes catch most submissions, but dropper apps that fetch their payload after approval still get through.
• Exploitation of unpatched vulnerabilities: Devices running old operating system versions are compromised with no user action at all.
• Malvertising and drive-by downloads: Compromised ad networks deliver payloads to users who only visited a legitimate site, and the same evasion logic drives phishing hidden inside QR codes, where the link is an image that text-based scanning never reads.
• Supply chain compromise: A trusted software component or SDK is modified upstream, so malicious code arrives inside something the organisation chose to install.

Reducing the risk across devices

A layered approach works better than any single control:

• Keep operating systems and applications up to date, since a large share of serious incidents trace back to a small number of known vulnerabilities.
• Restrict installation sources on corporate devices and treat any request to bypass a security warning as a red flag.
• Review app permissions, with particular attention to accessibility services, notification access and device administrator rights.
• Enforce multi-factor authentication alongside controls that detect stolen session tokens, since infostealers are designed to skip the login prompt.
• Maintain offline, tested backups so ransomware becomes a recovery exercise rather than a negotiation.

The gap on mobile

The controls above assume you can see what is happening on the device. On phones that assumption usually fails. Application sandboxing prevents security software from scanning other apps, mobile device management reports configuration state rather than behaviour, and on personally owned devices the work profile deliberately hides the personal side from the organisation.

Attackers work inside that gap, which is covered in our guide to why mobile malware is hard to detect on employee phones and the practical steps in how to improve mobile malware detection on work phones. For a view of how the vendors in this space compare, see our guide to mobile threat defence software.

Corrata provides mobile threat defence for iOS and Android. See how detection and response works on employee devices.

The post 15 Different Types of Malware and What They Do appeared first on Corrata.

This guide covers why that gap exists and what to do about it, in the order the work should be tackled.

Why mobile malware is hard to detect

The sandbox prevents scanning

On iOS and Android, applications run in isolation and cannot read the files or memory of other applications. That design blocks most malware from spreading between apps, and it also blocks security software from doing what antivirus does on a laptop. No third-party app can scan the contents of another app, inspect the filesystem or watch processes it does not own. The desktop model of on-access file scanning has no equivalent on mobile.

MDM answers a different question

Mobile device management was built to configure devices and enforce policy rather than to detect threats. It will tell you which devices are enrolled, which operating system versions they run, whether a passcode is set and which managed apps are installed. It will not tell you that an installed app is exfiltrating contacts, that a user has just authenticated on a credential harvesting page, or that a device is talking to a command and control server. Knowing an app is present is not the same as knowing what it does.

The BYOD privacy boundary is deliberate

On personally owned devices the work profile exists specifically to keep the organisation out of the personal side. Google states plainly that the separation of work and personal apps means IT gets full control over work apps and data with no visibility into personal apps.

That boundary is correct for privacy and costly for detection, and the cost is measurable in timing. Verizon’s 2026 Data Breach Investigations Report found that among ransomware victims who had a prior credential or infostealer event, half saw that event occur within 95 days of the ransomware attack.

There is usually a window of weeks or months between the theft and the consequence, and whether anyone notices depends on being able to see the device where the credentials were taken. Attackers are not constrained by the boundary the organisation agreed to respect, so a phishing message arriving through personal WhatsApp can harvest corporate credentials that work perfectly well against corporate systems.

Attacks arrive through unmonitored channels

Email security gateways see corporate email. They do not see SMS, WhatsApp, Signal, LinkedIn messages, QR codes scanned from a poster, or links opened in a personal browser. On mobile those channels carry a large share of credential phishing, and most of it now lands outside the inbox entirely. The small screen hides the signals users are trained to look for, including the full URL and the sender’s real address.

Attackers have noticed that this works. Verizon’s 2026 report recorded a 40% rise in the success rate of mobile social engineering year on year, naming mobile devices among the fastest-growing targets. The same evasion logic drives phishing hidden inside QR codes, where the destination is an image that text-based scanning never reads. Phones also spend most of their time on mobile data or home wifi, so network controls sitting in the office never inspect that traffic.

Malware is built to survive app review

Attackers assume the store review process exists and design around it. A common pattern is a clean utility app that fetches its payload only after approval. Kaspersky’s researchers documented this in the second quarter of 2026, when a trojanised PDF reader distributed through Google Play showed users a fake update prompt in order to install the Anatsa banking malware.

Attackers also hide what the code does. The SparkCat crypto stealer, found in apps on both Google Play and the App Store, kept its malicious component encrypted so that nothing suspicious was visible to anyone reviewing it. Once running on an iPhone, it read text out of photos stored on the device, looking for saved recovery phrases.

Overlay attacks draw a fake login screen on top of a real banking or single sign-on app, leaving nothing on disk to find. Accessibility service abuse gives an app the ability to read screen content and simulate input, using one of several Android permissions that have entirely legitimate uses alongside their malicious ones. Volume compounds all of it: Google reported that Play Protect identified more than 27 million new malicious apps from outside Google Play in 2025, more than double the 13 million the year before, which is a large part of why installing apps from outside the official stores carries a different level of risk.

Users have no symptoms to report

On a laptop, an infection usually produces something the user notices. On a phone, the signs are heat, battery drain and slower performance, which people attribute to an ageing handset. Spyware is designed to produce no signs at all. Apple’s threat notification programme exists because mercenary spyware attacks are difficult to detect and prevent even for the platform vendor, with infection often requiring no interaction from the target.

How to improve malware detection for mobile

Step 1: Establish what you can currently see

Start with an honest inventory rather than a tooling decision. For each group of devices, record who owns it, whether it is enrolled, what data it can reach, and what your existing tools actually report. Separate four questions: which apps are installed, what those apps are doing, what the device is connecting to, and what the user is being sent. Most teams can answer the first and none of the rest. That gap is the scope of the work.

Step 2: Set the privacy boundary before you deploy anything

On personally owned devices, detection succeeds or fails on consent. Decide and document what will be monitored, what will not, who can see the data, and how long it is retained. Under GDPR this needs a lawful basis and, in most cases, a data protection impact assessment. Write it in language employees can read, and be specific about the personal side of the device. A programme that collects less and is trusted will get better coverage than one that collects more and gets resisted.

Step 3: Fix the configuration baseline

Detection is cheaper when there is less to detect. Set a minimum operating system version and enforce it through conditional access rather than through reminders. Restrict installation sources on corporate-owned devices. Ensure Google Play Protect stays enabled, which matters because Google’s enhanced fraud protection blocked 266 million risky sideloading attempts in 2025. Block enrolment of jailbroken or rooted devices, since those lose the platform protections the rest of your controls assume.

Step 4: Monitor the device’s network traffic

Since the platform prevents third-party software from scanning other apps, the practical detection surface on mobile is the connection rather than the file. Network traffic inspection performed on the device catches what file scanning cannot: connections to command and control infrastructure, credential harvesting pages opened from any app, and data leaving for destinations it should not reach. It works regardless of whether the phone is on the office network, home wifi or mobile data. This is the largest capability gap between a managed mobile estate and a monitored one.

Step 5: Watch permissions and behaviour, not just app names

Build alerting around the permissions malware needs in order to function:

• Accessibility services, which allow an app to read screen content and simulate input.
• Notification listener access, which lets an app read one-time passcodes as they arrive.
• Device administrator rights requested by an app with no management purpose.
• Draw over other apps, used for overlay attacks against banking and single sign-on screens.
• Installation from unknown sources, including any change to that setting.

Treat a request for any of these from an app outside your approved catalogue as an incident rather than a support ticket.

Step 6: Extend phishing detection to every channel

Most mobile compromise starts with a message rather than an app, so detection needs to cover SMS, messaging apps, QR codes, personal browsers and social platforms. Two behaviours deserve specific alerting: a user being walked through disabling a security control, and a user being talked into installing an app during a phone call. Google considered the second pattern common enough that Play Protect now cannot be switched off while a call is in progress.

Step 7: Route mobile alerts into the same queue as everything else

A mobile detection tool that emails a dashboard link to one administrator is not detection. Feed alerts into the SIEM, map them to your existing severity model, and name the team that owns triage. Define in advance what a confirmed mobile compromise triggers in your identity stack, because the credentials and session tokens taken from a phone are used against systems that have nothing to do with mobile.

Step 8: Write and rehearse the response playbook

Decide these points before you need them:

• How a device is isolated from corporate resources, and who authorises it.
• How sessions and tokens are revoked, given that infostealers capture live session tokens and bypass the login step.
• What evidence is preserved before any wipe, and whether a selective wipe destroys what you would need.
• How a BYOD device is handled when the organisation has no right to wipe the personal side.
• What happens when an employee receives an Apple threat notification, which warrants specialist help rather than a routine device reset.

Run the scenario at least once. The first time a team discovers it cannot revoke a session on a phone it does not own should not be during an incident.

Measuring whether it is working

Track a small set of numbers monthly: percentage of devices with work access covered by detection rather than just enrolled, percentage running a current operating system, phishing links blocked split by channel, sideloading and permission-change attempts flagged, and median time from alert to containment. Coverage is the one to watch first, since a capability deployed to 60% of the estate leaves the other 40% as the route in.

Corrata provides mobile threat defence for iOS and Android. See how detection and response works on employee devices.

The post Mobile Malware Detection on Work Phones appeared first on Corrata.

Corrata protects mobile devices against a broad spectrum of threats, including mobile phishing, spyware, malicious applications, and data leakage, while continuously monitoring devices and their network communications for security weaknesses.

A distinctive capability of the Corrata platform is the continuous assessment of the quality of encryption used by applications and services communicating with mobile devices. Rather than assuming that encryption is present and correctly implemented, Corrata actively evaluates each connection in real time.

This includes identifying cases where sensitive data is transmitted without encryption, as well as situations where encryption is present but weakened through the use of outdated TLS versions, expired certificates, or vulnerable cipher suites.

This monitoring is designed to protect against adversary-in-the-middle attacks, ensuring that communications cannot be intercepted, modified, or downgraded by attackers with access to any network the device traverses.

Corrata adopts a true zero-trust networking philosophy: every network, corporate, home, public Wi-Fi, or cellular, is treated as potentially hostile. Security decisions are therefore based on the observed quality of the connection itself, not on assumptions about where that connection originates.

Below, we illustrate the value of this continuous monitoring by describing real-world vulnerabilities Corrata has uncovered in live production environments.

Devices Transmitting Unencrypted Data

Today, over 99% of connections between mobile devices and web servers use TLS encryption by default. However, a small proportion of websites often low-traffic, legacy, or internally hosted services: still interact with devices over unencrypted HTTP. In many cases this is relatively benign, involving only the transmission of static or publicly accessible content.

Corrata has nonetheless identified multiple incidents where sensitive data was transmitted to such endpoints without encryption. This traffic typically appeared as HTTP POST requests originating from mobile applications.

In several cases, the transmitted data included usernames and passwords sent in plaintext, fully visible to any attacker capable of observing the network traffic.

All such incidents investigated by Corrata involved in-house developed applications. The failure to enforce encryption was usually the result of poor coding practices or insufficient testing, often carried out by third-party development teams. A recurring theme was the rushed release of major application upgrades, where encryption requirements were inadvertently bypassed or incorrectly implemented.

The critical advantage of Corrata’s continuous monitoring lies in speed of detection. In each case, Corrata prevented unencrypted data transmission and alerted the affected organization immediately when the faulty code entered production. This allowed the issue to be remediated quickly, often before any meaningful exposure occurred.

HTTP POST as a Malware Indicator

In a surprisingly high number of cases, the transmission of plaintext data from a mobile device to an external server has proven to be a strong indicator of malware or the presence of unauthorized applications.

In one representative incident, Corrata detected device identifiers and configuration details being sent unencrypted to a remote server. Further investigation revealed that the destination was a third-party Android app store. Such app stores are popular in certain regions but are widely known to distribute malware-infected or trojanized applications.

These stores frequently offer pirated or modified versions of popular messaging applications such as WhatsApp, Facebook Messenger, Signal, and Telegram, as well as social media platforms including TikTok and Snapchat.

While these counterfeit apps often promise enhanced features or removed restrictions, they typically result in all user communications being exposed to their criminal publishers.

In this context, unencrypted HTTP POST traffic served as an early warning signal of a far more serious compromise, enabling organizations to identify and remove malicious software before further damage occurred.

Poor maintenance of  Sensitive Servers

In regulated sectors such as finance and healthcare, failing to enforce strong encryption is not merely poor security practice. It can constitute a regulatory breach. Such failures can expose organizations to fines, penalties, and significant reputational harm.

Corrata has encountered several instances where encryption was correctly configured on some, but not all, servers supporting a critical application. In each case, the root cause was architectural rather than malicious. The application was hosted across multiple backend servers behind a load balancer.

Although testing had been performed prior to deployment, it did not cover every server in the pool. As a result, some production traffic was intermittently routed to hosts using questionable cipher suites. These failures only became apparent when employees using Corrata accessed the application under real-world conditions, at which point the issue was detected and resolved.

Use of Vulnerable TLS Versions and Cipher Suites

The TLS standard has evolved significantly over time. Today, TLS 1.2 and TLS 1.3 are considered secure when used with strong cipher suites. Despite this, Corrata continues to observe cases where websites support weak ciphers or where specific device and browser combinations trigger a downgrade to insecure encryption.

Most such cases involve rarely used consumer services and are mitigated simply by blocking the connection. Where appropriate, Corrata acts as a responsible corporate citizen by notifying service operators so they can remediate the issue.

On rarer occasions, weak encryption has been identified on newly adopted SaaS platforms. In these cases, Corrata customers have escalated the issue to the vendor, leading to corrective action and improved security for all users.

Conclusion

TLS is a foundational component of modern information security. Even minor operational errors, such as expired certificates, misconfigured servers, or outdated cipher support, can introduce significant risk. Ensuring that encryption is not only present, but consistently and correctly implemented, is essential to protecting sensitive communications.

Corrata’s continuous monitoring of mobile device communications provides a critical safeguard that goes well beyond the upfront testing typically performed when new applications or SaaS services are introduced. By validating encryption quality in real-world conditions, on real devices, and across all networks, Corrata helps organizations detect and remediate vulnerabilities before they can be exploited.

The post Continuous Monitoring of TLS Encryption: What Corrata Sees in the Real World appeared first on Corrata.

ECH adoption is low, but risks remain for enterprises and users.

Encrypted Client Hello (ECH) is a security protocol designed to increase user privacy by encrypting the content exchanged between clients and servers when they are establishing a connection. Increased user privacy: what’s not to like?

Unfortunately, in the view of many enterprise security professionals, the increased privacy promised by ECH could simultaneously reduce their ability to detect and respond to threats. Widespread adoption of the security protocol would severely curtail the ability of enterprises to identify and block connections to malicious domains.

Late last year, our team at Corrata noticed an uptick in detections of an ECH domain. The numbers were small, low thousands among hundreds of millions of domain scans, but nonetheless intriguing. Did this herald the primetime arrival of ECH? Would widely-used security tools soon be blind to large swaths of internet traffic?

How ECH works

You’ve seen the padlock symbol and https designation in the address bar of your browser. Both are indications that the website you’re visiting uses the Transport Layer Security (TLS) internet encryption standard, which protects communications between an endpoint device and a web server. The vast majority of internet traffic uses the TLS 1.3 standard: ECH was designed as an extension to that standard.

Without ECH, a client will reveal the domain of the website it’s attempting to visit before the encrypted connection is established. This means that any entity that can see the user’s internet traffic, such as mobile operators, Internet Service Providers (ISPs), enterprise security teams and bad actors, can see their destination, even when the user and the server take precautions to avoid this.

ECH encrypts the entire Client Hello message (the first message sent by a client in a TLS handshake) so that only the gateway to the intended server, which holds the corresponding private key, can decrypt this inner message and complete the handshake securely. Network observers can no longer see which specific domain a user is trying to access.

Why does that matter?

Important cybersecurity tools like Secure Web Gateways and Next Generation Firewalls rely on that visibility to detect and block access to content that could represent a threat, such as phishing or malware download sites. Beyond security teams, ISPs have a commercial interest in understanding how their subscribers use the internet, and governments want to be able to passively monitor and potentially restrict access to illegal, malicious, or unacceptable content.

The visibility is particularly important for banks and other heavily regulated industries that are often required to monitor their incoming and outgoing internet traffic. As it stands, these organizations can decrypt traffic selectively without looking at sensitive data like employee PII or health records. But if ECH blocks filtering tools, banks will have to decrypt all internet traffic in order to remain compliant with regulations: degrading user privacy in the process.

ECH adoption is low, but risks remain for enterprises and users

Our analysis of the adoption and impact of ECH for enterprise users brought good news and bad news. Although overall adoption is very low (more than 9% of the top 1 million domains are ECH-enabled, but less than .01% of TLS connections used the protocol), malicious actors are already taking advantage of the anonymity the protocol provides: 17% of all ECH-enabled sites are risky. Chrome users with encrypted DNS enabled are most at risk.

You might wonder if such a small portion of internet traffic matters. If less than one-tenth of one percent of internet connections are using ECH, should enterprise security teams even worry about the protocol’s potential risks?

The short answer is yes.

To work, ECH requires traffic to flow through a content delivery network (CDN) that supports the protocol. Cloudflare is currently the only CDN that supports ECH, and the company has played an important role in driving ECH adoption. (Notably, Apple’s iOS does not support ECH.)

We found that over 90% of phishing detections use Cloudflare infrastructure. In addition to the ECH anonymity, these sites take advantage of other Cloudflare features. For example, the “captcha” page can direct desktop traffic to a legitimate site while mobile traffic is sent to a fake one.

We should expect ECH to grow in popularity over time, because there are opportunities and incentives for both the server side and client side to drive adoption. On the client side, Safari could support the standard or Chrome could enable encrypted DNS by default.

Server side

On the server side, you would need to see wholesale migration to Cloudflare (unlikely) or default support from other CDNs. It’s worth noting that ECH adoption is a positive for the CDNs. The complexity of implementation means more websites will opt to use CDN services: and the CDNs would become the only infrastructure players with widespread visibility of internet traffic.

For now, security teams can breathe a sigh of relief because the community’s fears that enterprise internet traffic would go dark are not yet being realized. But it would be irresponsible to expect this to continue long-term, given the significant market opportunities that ECH adoption offers for the CDN industry. The threat posed by the protocol must be taken seriously.

Tracking ECH and its cloak of secrecy is no longer optional for enterprise security teams. Our data shows that while the potential certainly exists for ECH to become a thorn in the side of defenders, this is the time to prepare rather than panic.

This article was produced as part of TechRadarPro’s Expert Insights channel.

The post Is a new privacy protocol helping malicious actors more than internet users? appeared first on Corrata.

Remote Access Trojans (RATs) have plagued Android devices for many years. These pieces of malware are disguised within seemingly benign applications, granting attackers remote access to a device. Essentially, this software allows attackers to manipulate a phone as if they had physical access to it.

The damage from remote access to an employee’s smartphone is significant. Most employees access a wide range of enterprise applications directly from their smartphones, including productivity suites like Microsoft 365 and Google Workspace, SaaS apps like Salesforce and Workday, and various line-of-business applications. Successful authentication to these apps often means credentials and MFA challenges are not subsequently required. This reliance on physical security and passcodes to safeguard enterprise data becomes a vulnerability when a RAT is involved, exposing all data previously only accessible with physical access to an unlocked phone.

At first glance, RATs might seem like a remote risk. How could such devastating software end up on an employee’s phone? And surely the built-in protections of the mobile operating system would prevent such malware from doing harm?

Steps in RAT Attack

Initial Access

Cybercriminals are adept at tricking people into doing the wrong thing. They might promise early access to a new movie, concert tickets, a hot deal, or an exciting new crypto scheme. Alternatively, they might create urgency around avoiding being locked out of a bank account, being cut off by a mobile or broadband provider, or being blocked from work accounts. They often leverage critical incidents like the Crowdstrike outage or impending natural disasters. Recently, attackers have used QR codes embedded in emails or posted in public places where employees gather. These lures can be delivered via multiple channels: SMS, WhatsApp, LinkedIn, or email. No matter how well-trained staff are, some percentage will always fall victim.

Execution

The crudest form of malware delivery is via unapproved app stores or download sites. Here, the operating system might warn users to avoid downloading from ‘unknown sources,’ and Google’s built-in Play Protect security service should flag any potentially harmful app. However, users have become accustomed to ignoring such warnings, so they are not foolproof. Additionally, attackers have successfully introduced malware via the Google Play Store. Typically, this involves a ‘Dropper,’ an initially innocuous app that fetches the malicious payload once installed. This method bypasses warnings from both the operating system and Google Play Protect.

MDM compliance policies may disable sideloading of apps and restrict which apps can be downloaded to work profiles. However, enforcing these policies comprehensively in the real world is challenging. They offer no protection for the large proportion of accesses originating from BYOD (Bring Your Own Device).

Privilege Escalation

The security architectures of both Android and iOS are significantly better than Windows, with strengths in sandboxing, encryption, and app store distribution. However, attackers have found one devastating vulnerability in Android: the Accessibility Service.

Designed to make devices more usable for people with disabilities, the Accessibility Service is a core part of Android, so its use by an app might not raise suspicion. Apps granted accessibility access have extensive permissions to interact with the device, making it difficult to distinguish between legitimate and malicious use. Attackers rely on tricking users into granting accessibility access, making it seem like a necessary step to use an app’s features. However, its powerful capabilities are a boon for attackers:

Capturing Screen Content and User Input:

• Keylogging: Malware with accessibility access can monitor and record every keystroke, including passwords, credit card numbers, and other sensitive information.
• Screen Recording/Screenshots: The malware can capture what’s displayed on the screen, revealing personal data or login credentials.
• Overlay Attacks: Malware can create fake overlays that mimic legitimate app screens, tricking users into entering credentials into the malicious overlay instead of the real app.

Performing Actions on Behalf of the User:

• Clicking Buttons and Links: Malware can automatically click buttons or links, leading to unintended actions like downloading additional malware or making fraudulent transactions.
• Filling Forms: The malware can fill in forms with stolen data or malicious content.
• Sending Messages: It can send SMS messages to the victim’s contacts, spreading the malware or sending phishing messages.

Bypassing Security Measures:

• Granting Permissions: Malware can abuse the Accessibility Service to grant itself additional permissions, such as access to contacts, call logs, or SMS messages.
• Disabling Security: It can disable security features like Google Play Protect, making it harder to detect and remove.

Data Collection

Once a RAT is installed, attackers can steal sensitive data from cloud applications, collect credentials, and respond to MFA challenges while accessing the enterprise network from an attacker-controlled device. They can also communicate with colleagues as part of a Business Email Compromise attack. Essentially, the attacker inherits all the privileges of the employee whose phone they have subverted.

Attackers’ tactics continue to evolve. The recently discovered BingoMod RAT can remove security apps and wipe the device once its mission is achieved. Earlier RATs developed extensive sandbox evasion and anti-analysis techniques. GuardZoo is spyware distributed via WhatsApp designed to exfiltrate photos, documents, location data, and device configuration information. CapraTube collected and sent SMS messages and calls while capturing screens and modifying files. The list goes on.

Conclusion

Android RATs are among the most devastating attacks observed. They are particularly dangerous due to their relative lack of technical sophistication. Unlike commercial spyware like Pegasus and Predator, they don’t rely on expensive zero-day exploits but instead use classic social engineering techniques. They are also relatively easy to defend against with the right tools. Ultimately, they exploit the complacency many organizations exhibit around mobile endpoint security.

The post Stealing secrets – the menace of mobile RAT’s appeared first on Corrata.

Last year, Meta disclosed that the hacker group Bitter APT had embedded their Dracarys malware into fake versions of Signal, Telegram and Whatsapp. Corrata has also encountered similar malware in the wild. And more recently, researchers at ESET discovered trojanized versions of Signal and Telegram on Google Play and in the Samsung Galaxy Store. 

What’s Happened?

These malicious apps, named ‘Signal Plus Messenger’ and ‘FlyGram’, were embedded with the BadBazaar spyware and were uploaded by a Chinese APT hacking group known as GREF. Initially, this malware targeted ethnic minorities in China, but recent data indicates that users in countries including Ukraine, Poland, the Netherlands, Spain, Portugal, Germany, Hong Kong, and the US are now being targeted.

The spyware’s capabilities are extensive, ranging from tracking device locations, stealing call logs, SMS, recording phone calls, to exfiltrating contact lists and files. The malicious versions of these apps have novel features that allow attackers to link victims’ Signal accounts to their own devices, enabling them to monitor all future messages. Both malicious apps (FlyGram and Signal Plus Messenger) have been removed from Google Play and Samsung Galaxy Store but are still available from 3rd party sites. 

The Hidden Threat: Trojanized Messaging Apps on the Rise

As you can see above, hackers are successfully deceiving users into downloading counterfeit versions of popular messaging apps. These imposter apps have been ‘trojanized’, meaning they contain concealed malware within what appears to be a safe application. At first glance, these apps might seem appealing due to additional features not present in the standard versions. However, the hidden malware can pilfer a broad spectrum of data, including the messages themselves.

This type of attack is possible because of a key aspect of internet applications: the application developer may control the back-end but ultimately cannot fully control the front-end application.  This is true whether the user is accessing the application via a browser or a mobile app.  

The end-user has control over the software running locally (i.e. the mobile app or the browser). This is fine if the app is the legitimate version, but if the user has downloaded a fake version, the owner of the legitimate service (e.g. WhatsApp) has no way of knowing this. 

Why is this Alarming?

Given the sensitive nature of information shared over these messaging platforms, the risks associated with using a malicious version are immense. This concern is magnified when you consider that employees often use these apps for work-related communication.

Attackers typically take the source code of legitimate apps like Signal and layer on additional features that serve dual purposes:

1. Attracting users with enhanced features.
2. Granting malicious capabilities to the hacker.

With this malicious layer, attackers can:

• Link other devices, maintaining persistent access even after the malicious app’s removal.
• Leak data from the account.
• Perform on-device malicious actions, such as accessing files, location, and messages.
• Often grant extensive permissions to legitimate apps. For instance, WhatsApp requires access to photos, videos, in-chat media, and user location. Malware often manipulates users into granting these permissions, especially when the app appears legitimate.

The Bigger Picture

While these attacks are often targeted at consumer applications such as the ones named above, there’s no barrier preventing business tools like Slack, Teams, or Outlook from being trojanized similarly. Signing into these compromised apps could grant attackers access to company data, credentials, and authentication tokens – see here. The “Adversary” in this case is not traffic-level eavesdropping but on-device eavesdropping.

Mobile users are advised to always take care to download only the official versions of apps and to steer clear of third-party versions that claim to offer enhanced features, even if they are available on official app stores.

How to protect your organization

Robust defense against such threats consists of three elements:

• Firstly, make sure that your mobiles are prevented from accessing websites which host malware. 
• Secondly, ensure that your employees’ devices are continuously scanned for potentially harmful applications and 
• Thirdly, monitor traffic to and from employee devices to detect communications with Command and Control (C2) servers and other suspicious traffic.

The simplest way to provide these protections is to deploy a mobile threat defense solution to your employee devices. The right solution will provide the necessary protection while being easy to deploy and manage and avoiding the need to collect employee personal information. 

The post Deceptive Downloads: The Silent Menace of Trojanized Messaging Apps appeared first on Corrata.

As a CISO, Security Architect, Risk Manager or Security Analyst, it’s your job to identify the best way to mitigate information security risk within your organization. Sometimes this will involve implementing a technical solution to protect against a new or growing threat. You will have come to this decision after examining the range of alternative approaches to addressing the threat and, in the case of a technical solution, having assessed multiple vendor offerings. 

But for many, this is the easy part. It’s essentially a technical issue, a question of diligence and expertise, likely conducted with peers who share your deep understanding and engagement with cybersecurity risks and technologies and the tradeoffs involved in any such decision. Now the time comes to bring your proposal to the upper management, perhaps the executive team or the Board. Now you need to articulate in terms that the non-technical will understand why your organization needs to spend time, money and resources on the project, aka – make the business case.

What then is the business case for investing in mobile endpoint security?

Why we need a mobile endpoint security solution now

The first question you must answer is, ‘Why now ?’ In other words, what has changed in the information security environment that makes it urgent to implement mobile endpoint security today? After all, employees have been using smartphones since the advent of the iPhone.

The reason why mobile endpoint security is a business priority today is straightforward. The move to cloud means that mobile users now have access to the same business systems that are available on traditional laptops and desktops. In the past, laptops and desktops had access to a much wider range of applications because they were joined to the corporate network either directly or through a VPN. Today that distinction is disappearing: all devices access cloud or SaaS applications on the same basis. 

This gives us our first argument for the need for mobile endpoint security:

“More and more of our business applications will be accessible directly from our employees’ phones and tablets:

– We are now using the Microsoft 365 suite, including Outlook, Teams, OneDrive, Word and Excel, all of which are accessible from employee mobiles.

– In the last two years, the organization has adopted a wide range of SaaS applications.

– We expect that the number of SaaS applications used by the business will continue to increase.”

Parity of protection

Your senior management is very aware that the organization has a range of security solutions in place to protect traditional endpoints. What they may not appreciate is that these solutions do not operate in the mobile environment. Web content is not filtered, mobile phishing messages are not blocked, and phones are not scanned for malware infection. 

This leads us to the second argument in support of mobile endpoint security – parity of protection:

“While we have an endpoint security solution deployed on desktops and laptops, we don’t have an equivalent protection on employee mobile devices. This means we have no protection against malicious content, phishing over sms and other messaging applications, and mobile malware.“

Mobile Devices are not invulnerable

85% of mobile phishing attacks are outside email. SMS, WhatsApp, and other messaging, social and collaboration platforms are all being targeted with increasingly sophisticated phishing attacks.

Based on data from the hundreds of organizations using Corrata, we know that most employees receive a mobile phishing message at least once a month. We also know that one in five devices have poor security configuration, making them susceptible to malware infection. And one third, access websites with weak encryption leaving employees exposed to data loss. Nothing in your mobile device management system addresses these threats. 

This leads us to the third argument in support of mobile endpoint security – heightened risk:

“There are a range of risks which are not addressed by the built-in security on iOS and Android or by our mobile device management system. These include:

– Targeted phishing attacks sent directly to mobiles over SMS, Whatsapp, Slack and other messaging and collaboration platforms.

– Attacks which bypass our multi-factor authentication by stealing authentication cookies. A successful attack would allow unauthorized access to our business systems over a prolonged period.

– Malicious software which allows attackers to read messages and other content sent to and from our employees’ phones.

– Poor encryption of data in transit leading to unauthorized disclosure of company and customer information sent to and from mobile devices.

– Non-compliance with acceptable use policy which restricts access to inappropriate content

– Failure to keep phone software up-to-date and other poor security configurations.”

How mobile endpoint security helps

You’ve made a strong set of arguments for the need to do something about the mobile security gap. You now need to introduce the solution. This means explaining what a mobile endpoint security solution will do. In doing this, it’s important to remember that your audience will assume it’s like the endpoint security solution with which they’re familiar – this might be a traditional anti-virus solution or a more modern EDR solution. Mobile endpoint security incorporates virus scanning and malware detection and response but also next-generation firewall, web-filtering, and anti-phishing features:

“The mobile endpoint security solution we’re proposing will protect us by doing the following:

• Blocking links to phishing sites, malware download sites, sites which are contrary to our acceptable use policy, and other malicious sites. It provides the equivalent of the web filtering we currently have on our desktops and laptops.
• Detecting any malware present on a device. Any device with malware installed is automatically prevented from accessing our business applications. This is equivalent to the [anti-virus, endpoint protection, or endpoint detection and response] software on our laptops and desktops.
• Preventing any data being sent to or from our phones without proper encryption. This ensures that our data cannot be snooped on by bad actors monitoring WiFi or other networks. This is equivalent to the protection provided by using a VPN.
• Assigning a security score to each device. Employees are prompted to keep their devices up to date, to remove any risky applications, and to correct any poor configurations. Devices with low scores can be automatically prevented from accessing business applications. This is equivalent to features provided by our endpoint protection software on laptops and desktops.”

No negative impact on employees

Having convinced your executive team of the need for a solution and the practical protections it will deliver, your final step is to address two common objections. The first relates to employee acceptance. Your senior managers will be only too aware that employees don’t like being surveilled. They also love their phones and don’t want anything interfering with the smooth functions of their devices. So it is important to be able to reassure your executives that the solution respects employee privacy and does so in a transparent and easy-to-communicate manner.

This means a solution that doesn’t track location, scan images or other content, read messages, or record browsing history.

You should also be able to offer the reassurance that your chosen solution runs unobtrusively in the background without impacting the normal operation of the device. Employees are only required to interact with the app in the rare case that their manual intervention is required to resolve a security issue.

Easy to deploy and needs little ongoing management

The second concern will be around the impact on the, undoubtedly stretched, security operations team. The good news is that mobile endpoint security focuses on preventing attacks: blocking phishing and malware download sites, preventing unencrypted communications, and disabling malware. Alerts and escalation requirements are generally minimal, and mature solutions will integrate with your existing security operations stack. 

The final clincher: quick and easy to deploy (and hence no upfront professional services costs), a single all-inclusive annual fee with no hidden extras.

In conclusion: you should approach your senior management with confidence. Mobile Endpoint Security is a cost-effective, easy to deploy and manage technology which addresses a gap in your defences which, unless addressed, will only get larger.

Best of luck! 

The post Making Your Case appeared first on Corrata.

As an IT leader in a legal firm, you don’t need to be told about how important Information Security is to your sector. Legal firms face unique challenges. They not alone handle client funds but also handle sensitive and highly confidential information. Handling of sensitive information is not the exception in legal firms, it’s the rule.

The range of potential attackers targeting legal firms is comparable to that facing governmental organizations, including nation-states, serious organized crime gangs, and hacktivists. Attackers are motivated not just by financial gain but also by political, ideological, and nation-state concerns. Incidents such as the release of the Panama and Paradise papers send a chill through the bones of legal firm Information Security staff everywhere. 

Risks are particularly acute for firms whose clients are in sensitive or controversial sectors such as energy, life sciences, capital markets, and high technology.  

Recent trends

Experts point to a range of recent trends which are heightening the risk profile of the legal industry:

• Clients challenge the technical capabilities of firms insisting that they support their preferred collaboration and data storage systems.
• The legal supply chain is becoming more complex: outsourcing, disaggregation of the delivery of legal services, and the increased use of specialist firms. Not alone must legal firms collaborate securely with their clients, but they must also do so with a range of other legal providers.
• Remote working has become the norm, and with it, the requirement that documents and systems be accessible from anywhere at any time in a manner which delivers both security and ease of use.
• Complex and often conflicting privacy regulations. For example, firms working with US clients may well need to take growing state-level privacy laws into account in their operations.

Supply chain attacks have raised awareness across all sectors that your data is only secure when the third-party suppliers you rely on have effective information security management systems. Clients demand insight into their legal service providers’ cybersecurity controls, processes, and procedures. They are acutely aware that the information they share with their lawyers is highly sensitive and need reassurance that it is being handled and protected appropriately. Firms need to credibly answer clients’ requests about their cyber security practices and their information security management system. Increasingly clients demand certifications such as ISO 27001 and SOC 2.

All of these factors point to the unique importance of information security to the reputation of legal firms. Partners are only too aware that a single incident can destroy a reputation carefully built up over countless years, and there are plenty of ready, willing, and able competitors just waiting for an incumbent to slip.

Information security leaders within legal firms are not complacent, and neither are their management. PWC UK’s Annual Law Firm Survey revealed that the top 100 firms have increased their spending on cybersecurity by an average of 39% in the last year.

The rise of mobile risk

But what if that spend is not properly allocated? Today many legal firms have no protection in place against the rising threats facing mobile users, even though we are now seeing a 50/50% split between mobile and desktop traffic – a significant change from the 25/75 split in 2015. As the profession embraces cloud computing, the exposure that mobile represents begins to align with the exposure with traditional domain-joined devices.  

Today, the vast majority of medium and large legal firms have mobile device management systems in place. In fact, many have had these systems in place for many years. However, the clue is in the name: these are management systems, not security systems. They don’t defend against the three principal risks facing mobile users today. 

The first of these is the risk of credential theft either via phishing attacks or malicious applications. 77% of leading law firms reported experiencing a phishing incident in 2022. These attacks are widespread and increasingly sophisticated. Not alone can they steal usernames and passwords but also authentication cookies and codes. MFA is not a panacea.

Advanced spyware is the second significant risk facing law firms, particularly those dealing with clients in sensitive sectors. Multiple scandals have raised awareness of security agencies’ use of the Pegasus iOS spyware to mount targeted surveillance on politicians and civil rights activists. Today there is mounting concern that similar sophisticated technology is being deployed more widely. Such malware bypasses the in-built security protections in iOS and Android and cannot be detected by anti-virus software. But the threat is real and can lead to a fundamental compromise of any data on the phone and create a gateway to all of the data in the organization.

The third risk is from intercepted communications. Lawyers use their smartphones and tablets continuously on networks which are not under their organization’s control. This can be anything from a home network to the free Wi-Fi provided in hotels or coffee shops or, indeed, the cellular network itself.  Without robust and continuous encryption, these communications are at risk of interception by determined adversaries.

A better set of solutions

It is, unfortunately, true that the first generation of mobile security solutions promised more than they delivered. Many were designed and based on replicating the limited features found in traditional anti-virus solutions. They failed to take into account the unique benefits (for example, sandboxing and the app store distribution model) and challenges (for example, smishing and user privacy expectations) of the mobile environment.

The good news is that there are easy-to-deploy, privacy-sensitive solutions available today. Mobile Threat Defence technology has moved on since the term was first coined by Gardiner back in 2016. Today leading-edge mobile threat defense solutions protect against SMS and other mobile-specific phishing attacks, are able to detect sophisticated malware and against communications which are inadequately encrypted. And what’s more, the leading solutions can do all of this without the need to collect privacy-sensitive information such as location or the contents of files on the device.

In Conclusion

I would urge legal firm IT leaders to carefully consider the benefits of deploying MTD. If you’ve previously looked at mobile endpoint security solutions, now is a good time to look again and if not, then take a look for the first time. You’ll be pleasantly surprised by the protections available, the positive user experience provided, and the ease of management and deployment. And you never know, but your partners might even thank you! 

The post Courts, Contracts, Cloud And Collaboration appeared first on Corrata.

Ask most people whether they review the permissions an app requests before installing it and the honest answer is no. Requests to access contacts, track location and read the calendar get tapped through with barely a pause, often by people who work in security and know better. There is a general sense that more care would be sensible. There is also a widespread assumption that the downside is modest: a bit more tracking than is ideal, nothing worth losing sleep over.

That assumption remains the single most serious security exposure the average Android user will ever create for themselves. When Corrata last examined this in 2022, the reference points were Flubot, Hydra and Autolycos. Those families are gone. The technique is not.

Every significant Android banking trojan operating today, including Anatsa, Octo, Hook and Crocodilus, depends on persuading a user to grant one or two powerful operating system capabilities. What has changed since 2022 is that Google has spent four years building defences against exactly this, and attackers have engineered around each one within months.

It is worth understanding both halves of that story.

Android permissions and consent

The first thing to grasp is the difference between what Android enforces and what Google Play enforces.

Android’s rules are enforced by the operating system. Short of running an unsafely modified build, an app cannot simply ignore them. Google Play’s rules are policy, enforced through app review. Review is a genuinely difficult job at Play’s scale, and it does not achieve full compliance. Apps installed from outside Play have historically sat outside that policy net entirely.

That distinction still matters, though it is now blurrier than it was, for reasons covered further down.

Android confusingly uses the word “permission” for the APIs an app uses to interact with the operating system, most of which never involve the user at all. It is more useful to think in three tiers.

Install-time permissions are granted automatically when the app is installed. They give an app limited access to restricted data and allow actions that minimally affect the system or other apps: sending and receiving data, downloading files, reading Bluetooth settings, running in the foreground. Not requiring consent for these is deliberate. It preserves the user’s attention for the requests that actually matter.

Runtime permissions, which Android formally classifies as “dangerous”, require an explicit consent prompt. These cover:

• Phone: making and receiving calls, and reading call logs
• SMS: reading and sending messages
• Camera and microphone
• Location, physical activity and body sensors
• Calendar and contacts
• Photos, video and audio, split into separate categories since Android 13, with partial “selected items only” access added in Android 14
• Notifications, which became a runtime permission in Android 13
• Automatic connection to nearby devices over Bluetooth or Wi-Fi

Special permissions are the third tier, and the one that matters most from a security perspective. These are not granted through a runtime dialog at all. The user has to go into Settings and turn them on deliberately, because the capability they confer is too broad for a one-tap prompt. This tier includes accessibility services, notification listener access, display over other apps, usage access, all-files access, device admin, and permission to install other apps.

Almost all serious Android malware abuse happens in that third tier.

Why accessibility services are the prize

It is obvious why granting an app your camera, microphone or SMS messages is risky. It is less obvious why accessibility services should be a concern, given the name suggests something benign.

Accessibility services exist so that people with disabilities can use their phones. The API lets an app read the contents of the screen, understand what is displayed, and perform inputs on the user’s behalf. Screen readers and alternative input systems could not function without it.

The same capabilities are exactly what an attacker wants. Once accessibility is granted, an app can observe every action the user takes, capture keystrokes, read message content, and record anything that appears on screen. It can also draw over the screen and replace what is displayed with content of its own. Malware uses this to harvest credentials, present convincing fake login pages, suppress security warnings and keep itself hidden.

Crocodilus, first documented by ThreatFabric in March 2025 and since observed worldwide, is a good illustration of how mature this has become. It monitors app launches and displays overlays over banking and cryptocurrency apps to intercept credentials. It logs every accessibility event, which functions as a keylogger without ever needing keyboard access.

It reads one-time passcodes directly off the screen while an authenticator app is open. And it can display a black overlay while muting the device, so that fraudulent transactions are carried out on a screen the victim believes is off.

SMS permission is the other perennial target. The simplest abuse is billing fraud, where a user is subscribed to a premium service and the operator’s notification is intercepted and suppressed. The more damaging use is interception of one-time passcodes sent for two-factor authentication. Combined with accessibility abuse, this gives an attacker the credentials and the second factor in a single chain.

What Google has done since 2022

Google has hardened this area substantially, in four distinct moves.

Restricted Settings, Android 13 (2022)

Apps installed from outside an app store are blocked from being granted accessibility service access and notification listener access. Android identifies these apps by the installation method used, so an APK opened from a browser, messaging app or file manager is treated as sideloaded. The user can still override this on a per-app basis, but the path is deliberately obscure.

Expanded Restricted Settings, Android 15 (2024)

The same protection was extended to cover display over other apps, usage access and device admin, closing the most obvious workarounds.

Advanced Protection Mode, Android 16 (2025)

A single setting that applies a set of hardened configurations for users at elevated risk, including journalists, activists and public figures. Among other things it blocks installation from unknown sources outright, disables 2G, restricts USB data access when locked, and reboots the device after prolonged inactivity.

Google has been testing a further extension that would prevent accessibility permission being granted to any app that does not declare itself an accessibility tool, and would automatically revoke it from apps already holding it.

Developer verification, rolling out now

This is the largest structural change to Android app distribution in years. Google’s stated rationale is that it found over ninety times more malware coming from sideloaded sources than from Google Play. From 30 September 2026, apps must be registered to a verified developer in order to be installed or updated on certified Android devices in Brazil, Indonesia, Singapore and Thailand, with global rollout planned from 2027.

Sideloading of unregistered apps remains possible through an “advanced flow” that began rolling out in August 2026, but it now carries a one-time waiting period of a day, specifically designed to break the high-pressure scam scripts that talk victims through disabling their own protections in real time.

Taken together, this is a serious body of work. It has meaningfully raised the cost of the attack.

Why it isn’t enough

It has not eliminated it.

Crocodilus is delivered by a purpose-built dropper that bypasses the Android 13 and later restrictions and installs the payload in a state where accessibility can be granted normally. It is not alone in this. Dropper development is now a distinct specialism in the mobile malware economy precisely because Restricted Settings made it necessary. The families that matter have all adapted.

The deeper issue is one of visibility rather than capability. Every control described above operates at the level of a single device, configured by a single user, with no reporting to anyone else. Advanced Protection Mode is opt-in and, by Google’s own framing, aimed at high-risk individuals rather than at a typical employee.

Restricted Settings can be overridden by the same user who was just persuaded to install the app. Developer verification will not reach most markets until 2027 and does not govern what a verified app asks for once installed.

So an IT security team asking a reasonable question, namely which devices in our fleet currently have accessibility, SMS or overlay permission granted to an app that has no business holding it, still has no way to answer it from the platform alone.

What this means for enterprise mobile fleets

The obvious response is to tell colleagues to be vigilant, review permission requests carefully and never sideload. In our experience this is close to useless on its own. Laptops still carry some residual aura of a work machine and are used with a degree of care. Phones are stitched into daily life and used informally. Consumer apps have spent fifteen years training everyone to grant whatever is asked as fast as possible.

Policy that depends on a user making the right decision at the exact moment an attacker has engineered urgency is not policy, it’s hope.

What works is making the permission itself visible to someone other than the person who granted it, and making that visibility actionable. Not a full inventory of everything an employee has installed, which is neither necessary nor proportionate, but a signal when an app on a work device has acquired a capability it has no legitimate reason to hold.

This is the gap Corrata was built to close.

Corrata identifies apps that request permissions which are not acceptable from a security perspective, alongside apps carrying known high-severity vulnerabilities. Accessibility is treated as the priority case. Where a user has granted accessibility permission to an app, Corrata surfaces the detail of that app to the security team, which serves as an early warning that a user may be exposed well before any credential theft occurs.

Crucially, this is done without inventorying every app on an employee’s phone. Corrata takes an exception reporting approach: information is shared with the service backend only when a clear security concern has been identified. Employee privacy and security visibility are usually presented as a trade-off. They do not have to be.

Detection is only half of it. Corrata provides alerting, blocking and quarantining to manage the risk once an app has been flagged. Where an app is identified as malware, the Corrata app prompts the user directly to remove it. Dangerous permission findings are handled differently, reported to the admin console rather than to the user, so that the security team decides whether a given app and permission combination is acceptable in their environment.

Where a device cannot be trusted, it can be quarantined and denied access to corporate applications until the situation is clear. And because Corrata inspects traffic on the device, communication with command and control infrastructure can be blocked, which cuts off the exfiltration path even where a compromised app is still present.

That last point matters for the threats described earlier in this post. A trojan that has successfully bypassed Restricted Settings and obtained accessibility permission still has to reach its C2 server to receive its target list and its overlays, and still has to send the harvested credentials and passcodes somewhere. Interrupting that traffic breaks the attack chain at the point the attacker cannot design around.

Where this leaves us

The openness of the Android ecosystem has brought real capability and real benefit to billions of people. That same flexibility creates work for those of us trying to keep organisations safe.

The direction of travel is encouraging. Google is closing the gaps faster than it was in 2022, and developer verification in particular will change the economics of malicious distribution once it reaches scale. But the pattern of the last four years is consistent: each control raises the cost of the attack without ending it, and the interval between a defence shipping and a working bypass appearing is measured in months.

For anyone responsible for a fleet of devices, the practical conclusion has not changed since 2022. User consent is the weakest link in mobile security, and it cannot be defended by asking users to be more careful.

Frequently asked questions

Is the nearby devices permission safe?

For most apps, yes. Nearby devices covers scanning for and connecting to Bluetooth and Wi-Fi devices. It is actually more privacy-protective than what it replaced, because before Android 12 an app had to request full location permission just to scan for Bluetooth. Question it when an app has no obvious reason to connect to anything. A headphone or smartwatch app needs it. A torch or photo editor does not.

Which Android permission can be used to steal your contacts?

READ_CONTACTS. It gives an app your entire address book, including names, numbers, email addresses and any notes stored against a contact. Android classifies it as dangerous, so an app must ask explicitly and you can revoke it under Settings, Apps, Permissions. On a work phone the exposure extends beyond the individual to colleagues, customers and suppliers who never consented to anything.

What are dangerous permissions on Android?

Dangerous permissions are capabilities that require explicit user consent because they access sensitive data or affect privacy: contacts, camera, microphone, location, calendar, SMS, call logs, photos and body sensors. Lower-risk permissions such as internet access are granted automatically at install. A third and more powerful group, including accessibility services and display over other apps, must be enabled manually in Settings, and this is where most malware abuse occurs.

Why is accessibility permission considered the most dangerous?

Because it lets an app read everything on screen and act on the user’s behalf. It can capture keystrokes and message content, log every interaction, and draw its own content over other apps. Attackers use it to place fake login pages over banking apps, harvest credentials and one-time passcodes, and conceal their presence. Very few legitimate apps need it, which makes it a useful signal for a security team.

How can an organisation see which apps have risky permissions?

Android offers no native way to see this across a fleet, because every control Google has built is configured on a single device by the person holding it. Mobile threat defence fills that gap. Corrata identifies apps requesting permissions that are unacceptable from a security perspective and reports them to the admin console, using exception reporting so a full inventory of an employee’s apps is never collected. Alerting, blocking and quarantining are then available to manage the risk.

The post Dangerous Permissions: How Android Malware Abuses Consent appeared first on Corrata.