Flying Eagle Android RAT traced across 170 servers

On 29 July 2026, researchers published an infrastructure study of Flying Eagle, a kit for building and operating malicious Android applications. Hunt.io and NetAskari found characteristic fingerprints on 170 internet-facing servers. The number is significant, but it needs precise interpretation: it does not mean 170 victims, 170 active campaigns or 170 independent operators.

The Hunt.io and NetAskari report describes 158 hosts identified through panel components, redirects and headers, plus 12 more associated through a default TLS certificate. The research demonstrates how repeatable infrastructure can be mapped, but it does not automatically establish whether every server was an active command-and-control node, a test deployment, an abandoned panel or a system exposed by another researcher.

What Flying Eagle is

Flying Eagle is not one application impersonating one brand. The materials examined by the researchers form an operator kit that includes a backend, management panel, real-time communications, an Android application builder and ready-made social-engineering templates. Its source code reportedly circulated in criminal Telegram channels, lowering the entry barrier for multiple users of the toolkit.

The analysed environment—an archive labelled “China Dragon” by the researchers—was approximately 388 MB and included Docker configuration, nginx, PHP, MySQL, a Node.js/WebSocket component, Android tooling and templates. Someone with infrastructure could use the set to produce a branded application and manage enrolled devices from a browser panel.

A malicious build can impersonate an application associated with Chinese public-security authorities. The research describes capabilities including:

• capturing entered data and screen content;
• attempts to obtain payment passwords;
• monitoring interactions by abusing Accessibility Services;
• access to the camera and device functions after permission is granted;
• display of phishing templates;
• remote control through the backend communications channel.

This is a capability inventory for the framework. It does not prove that every discovered server used every feature or that every sample carried an identical module set.

Where the number 170 comes from

The researchers used traits repeated across deployments: panel appearance and responses, redirect chains, characteristic headers and a default TLS certificate supplied with the kit. Internet-scale fingerprinting revealed:

• 158 addresses associated through web-service traits;
• 12 additional addresses associated through the default certificate;
• 170 hosts in total matching the research criteria.

A certificate is especially valuable when an operator deploys a ready-made package without changing defaults. It is not irrefutable proof that a named actor controls the host: a file can be copied, deliberately used as a false flag or left on an inactive server. Sound analysis therefore combines the certificate with panel content, DNS history, open ports, activity time and application samples.

Breachroad’s conclusion is that 170 represents the size of an infrastructure set with matching fingerprints, not a victim counter. That distinction matters in executive communication and threat-intelligence prioritisation.

Why a builder defeats simple app-name blocking

The report describes builder functions that change package identifiers and class names. Two applications produced by different operators can therefore look different in a manifest despite sharing a common origin. Reliance on one APK name, package name or file hash provides short-lived protection.

The C2 configuration was reportedly embedded using AES-128-CBC and padding. Encrypting configuration does not establish that the entire system uses strong cryptography; it makes simple plaintext searches for a server address harder. Defenders can still detect app behaviour, Accessibility usage, the configuration-decryption pattern, signing certificates or network protocol.

Researchers also noted similarities between some samples and SpyNote. That is useful family context, not an automatic equation of every Flying Eagle build with all SpyNote variants.

Accessibility abuse is a central signal

Android Accessibility Services have a legitimate purpose: helping people with disabilities operate a device. A malicious application can nevertheless persuade a user to grant broad visibility into the interface and permission to perform actions. Once approved, it may read text displayed by other applications, monitor events, click controls and interfere with removal.

An Accessibility request alone does not prove malware. Context and combined behaviour are what matter:

• the application impersonates an authority, bank or employer;
• it was downloaded outside the managed store;
• instructions pressure the user to enable “special permissions”;
• its declared function does not justify whole-screen access;
• it tries to hide its icon or obstruct settings;
• the device connects to an unknown server without a business need.

User education should teach people to recognise this sequence, while MDM policy should technically restrict sideloading and Accessibility grants to unapproved applications.

Who may be affected

A campaign using a fake Chinese public-security application is most credible to people for whom that language and institutional pretext seems natural. The risk is not limited to one country. The builder, panel and templates can be rebranded, and an application can be delivered through a messenger, SMS, fake support, recruitment conversation or investment fraud.

Organisations should pay particular attention to:

• corporate phones that permit APK installation outside the managed store;
• BYOD devices with email, VPN and messenger access;
• employees who communicate with customers through messaging apps;
• finance teams and payment approvers;
• users operating in markets where fake government apps are a common lure.

The 29 July reporting also refers to a warning issued by Chinese authorities on 18 June. That supports public concern about the threat, but available evidence does not attribute all observed hosts to one campaign.

Device and network detection

Effective detection should not depend solely on the list of 170 addresses. Infrastructure can disappear, change address or be reused. On-device telemetry should correlate:

• installation of an APK outside a managed source;
• grants of Accessibility, camera, screen or overlay permissions;
• an application whose reputation does not match the institution in its name;
• an unusual signing certificate and changing package identifiers;
• persistent WebSocket connections to unknown infrastructure;
• attempts to hide components or maintain background execution;
• overlays appearing over a payment application.

At the network layer, the IOC list remains useful for historical searches across DNS, proxy and NetFlow. A match should be enriched with time, source process, device owner and business context. It could originate from security research, shared hosting or a server that later changed ownership.

Responding to a suspicious application

If a corporate device may be infected:

1. isolate it from corporate networks without destroying evidence;
2. record the time, installation source, filename and message that prompted the user;
3. inventory granted permissions and accounts signed into the device;
4. revoke email, VPN, SSO and messenger sessions from a clean device;
5. notify the bank or finance team if payment passwords were entered;
6. perform analysis or a controlled reset under the MDM procedure;
7. inspect accounts for new MFA methods, forwarding rules and unusual logins;
8. search the environment for the same delivery source and message.

Removing an icon does not close the incident. If an application saw the screen, keyboard or sessions, the scope includes digital identities and potentially transactions.

How to treat malware sellers’ claims

Criminal channels routinely advertise features, customer numbers or tool effectiveness. Those statements do not carry the same evidentiary weight as analysed code, servers or telemetry. For Flying Eagle, components in the archive and fingerprints of identified services are supported by research. Promotional claims on Telegram remain seller assertions.

An internal report should label:

• observation — an element found in a sample or log;
• assessment — the most likely explanation connecting several observations;
• adversary claim — information that has not been independently verified.

This discipline prevents cybercriminal marketing from being repeated as “confirmed fact.”

What to do today

• disable sideloading where there is no business justification;
• alert on new, unapproved Accessibility Services;
• search historical telemetry for IOCs from the Hunt.io report;
• review WebSocket traffic from Android devices to unknown hosts;
• remind employees that an authority, bank or recruiter should not demand an APK installation from a messenger;
• prepare a session and credential-rotation procedure for a lost or compromised phone;
• do not present 170 servers as 170 confirmed victims.

The strongest result comes from combining technical controls with user behaviour. Cybersecurity and phishing training shows teams how to recognise fake applications, social-engineering pressure and dangerous permission requests. Additional technical context is available in our guides to phishing and mobile application penetration testing.

If your organisation manages Android or BYOD fleets, an IT security audit can verify MDM policy, application sources, detection signals and the response process. An IOC list is a starting point; durable protection depends on permission control, device observability and a rehearsed procedure.

Use the infrastructure map without creating stale alerts

The host set is most valuable for historical hunting, not as a permanent blocklist. Every IOC needs a source, observation date, fingerprint type, confidence level and review deadline. An IP can later belong to a different hosting customer, while a certificate can be copied.

Preserve the report version, search DNS, proxy, EDR and MDM within the relevant time window, then enrich every match with device, application, user and granted permissions. Escalate correlated signals; treat a single old address as a lead. This is a practical Cyber Threat Intelligence lifecycle: the objective is not the longest list, but a faster isolation, session-revocation or false-positive decision.

Without installing malware, test whether MDM detects sideloading, a new Accessibility Service, an unknown signing certificate and loss of agent contact. Measure time from alert to owner identification, isolation, session revocation and device-recovery decision. The Breachroad Academy provides a shared foundation for help desk, SOC and users.

Flying Eagle is a reminder that the visible app icon is only one part of an incident. Defenders must connect installation source, permissions, sessions and infrastructure while separating strong research fingerprints from an attractive but unverified victim count.