AN1778: Analytic 1778

Defender correlates an app preparing to phish (gaining overlay/notification/accessibility capability) with precise foreground targeting (reading activity in front via accessibility/focus) and then presenting a look-alike UI (overlay window or activity-on-top) immediately before local storage or small-burst egress of entered data. Chain: capability/permission → target app in foreground detected → overlay/activity-on-top or fake notification tap → local prompt input write → near-term network egress.

MobileAN1778AnalyticObject v1.1 Modified May 12, 2026, 16:30 UTC (UTC+00:00)

This analytic matters because it describes a higher-confidence Android phishing pattern: an app first gains capabilities commonly needed to deceive the user, observes which legitimate app is in the foreground, presents a look-alike interface at the right moment, and then stores or quickly sends the entered data. For leaders, the value is not a single alert condition; it is whether mobile security monitoring can connect several weak signals into a meaningful fraud, credential, or data-theft investigation path.

Executive priority

Prioritize this as a mobile identity and business-continuity concern where Android devices access corporate accounts, regulated data, or operational workflows. The key decision is whether the organization can produce evidence across permissions, foreground app context, UI overlay behavior, local writes, and near-term network egress. If those evidence classes are unavailable, executives should treat mobile phishing detection as a visibility gap rather than a solved control.

Technical view

For SOC, detection engineering, and IR teams, validate whether Android telemetry can correlate the full chain described by AN1778: capability or permission acquisition for overlay, notification, or accessibility behavior; observation of the foreground app through accessibility or focus signals; display of an overlay window, activity-on-top, or fake notification interaction; local prompt/input storage; and small-burst network egress soon afterward. Because no ATT&CK detection logic is supplied, this should be implemented as a correlation and triage strategy rather than a fixed signature.

Likely telemetry

Android app permission and capability changes, especially overlay, notification, and accessibility-related access
Foreground app or activity/focus visibility where available
Accessibility-service usage or events where collected
Overlay window, activity-on-top, or notification interaction telemetry
Local app storage writes associated with entered prompt data where observable

Detection direction

Validate correlation timing across the chain: permission/capability acquisition, target app foreground detection, look-alike UI presentation, local input write, and near-term egress.
Tune for combinations of behaviors rather than any single event, because overlays, notifications, accessibility features, and network access can each have legitimate uses.
Pay attention to apps that newly request or begin using sensitive UI-control capabilities and then interact with foreground context shortly before user input or outbound traffic.
Confirm whether telemetry preserves app identity, device identity, user identity, and timestamps tightly enough for incident reconstruction.
Document blind spots where Android privacy boundaries, MDM limitations, or missing mobile threat telemetry prevent observing foreground activity, overlay behavior, local storage, or egress.

Mitigation priorities

Inventory Android devices and apps that can access business systems, then identify which controls govern installation, permission grants, and accessibility/overlay use.
Restrict or review high-risk mobile permissions and capabilities where business policy allows, especially for untrusted or unmanaged apps.
Ensure mobile security tooling can collect and retain the evidence classes needed for this correlation before relying on alert coverage.
Prepare IR playbooks for suspected mobile credential or data entry phishing, including account protection, device triage, app review, and evidence preservation.
Use findings from testing to support compliance evidence around mobile access governance, monitoring, and incident response readiness.

Analyst notes and limits

AN1778 is a detection analytic in the mobile ATT&CK domain for Android. It provides a behavioral chain but no official detection implementation and no relationship context. The practical value is in validating whether defenders can join multiple Android mobile signals into a defensible investigation narrative.

This take is limited to the supplied ATT&CK fields. Tactics, relationships, and official detection logic were not provided. Local device management architecture, Android version behavior, privacy constraints, and available mobile security telemetry will determine whether this analytic can be implemented effectively.

Official MITRE ATT&CK definition

Analytic 1778

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release: 19.1
Object version: 1.1
Created: Oct 21, 2025, 15:10 UTC (UTC+00:00)
Modified: May 12, 2026, 16:30 UTC (UTC+00:00)
Raw hash: 95bb1f63c091a923...

Imported snapshots across ATT&CK releases (1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	May 18, 2026, 07:08 UTC (UTC+00:00)	1.1	May 12, 2026, 16:30 UTC (UTC+00:00)	Current bundle	`95bb1f63c091…`

Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Open mirrored raw JSON Open MITRE-hosted copy

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

[1]
mitre-attack AN1778
Open source URL

Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use