AN1779: Analytic 1779
Defender correlates a look-alike prompt inside an app (e.g., faux Apple ID password view, webview of brand login) with timing against scene/foreground activation, optional push notification bait, then local form cache writes and/or small egress. Chain: scene activation around sensitive UI → suspicious prompt creation (UIKit events without expected auth controller) or webview navigated to look-alike domain → local cache write → near-term egress
Analyst context for executives and security teams
This analytic is about catching deceptive login prompts inside iOS apps: for example, a fake Apple ID-style password prompt or a webview showing a look-alike brand login. The business issue is credential exposure through trusted mobile workflows. If an organization relies on iOS apps for workforce access, customer engagement, or regulated transactions, leaders should care whether security teams can distinguish legitimate authentication flows from suspicious in-app prompts followed by local data storage or small outbound network activity.
Executive priority
Prioritize this as a mobile identity and fraud-resilience validation item rather than a generic malware alert. Executives should ask whether the organization has visibility into iOS app behavior, authentication prompt patterns, webview destinations, local data writes, and near-term network egress. The value is strongest for environments where mobile apps handle credentials, customer identity, workforce access, or compliance-sensitive data. Because the supplied ATT&CK object is a detection analytic and not an attributed threat report, it should inform control validation and monitoring requirements, not assumptions of active exposure.
Technical view
For SOC, mobile security, and incident response teams, the analytic describes a correlation chain on iOS: scene or foreground activation around sensitive UI, creation of a suspicious prompt without an expected authentication controller or navigation to a look-alike domain in a webview, then local form/cache writes and/or small outbound egress shortly afterward. Teams should validate whether they can observe these event classes and correlate them by app, session, timestamp, UI context, storage activity, and destination. Since no ATT&CK tactic or official detection logic is provided, implementation should be treated as a hypothesis-driven detection pattern requiring local baselining of legitimate authentication prompts and normal webview behavior.
Likely telemetry
- iOS app scene or foreground activation events
- UI prompt or UIKit event telemetry where available
- Expected authentication controller usage or absence signals where instrumented
- Webview navigation URLs and destination domains
- Local form, cache, or storage write events
Detection direction
- Correlate prompt or webview activity with scene activation timing rather than alerting on a single UI event alone.
- Baseline legitimate iOS authentication flows so expected Apple ID, enterprise SSO, or app-native login prompts do not create excessive false positives.
- Review webview destinations for look-alike domains, especially when followed by local cache writes or small outbound egress.
- Tune correlation windows around foreground activation, local writes, and network egress to reduce noise from normal app startup and session refresh behavior.
- Validate telemetry availability first; many environments will not have deep UIKit, webview, or local storage visibility without app instrumentation or mobile security tooling.
Mitigation priorities
- Inventory iOS apps and workflows that handle credentials or sensitive authentication prompts.
- Prefer trusted, expected authentication controllers and documented login flows where applicable, then verify apps do not rely on ambiguous custom prompts for sensitive credentials.
- Establish review requirements for embedded webviews, external login domains, and brand look-alike destination risk.
- Improve mobile telemetry collection for app foreground activity, webview navigation, local storage writes, and outbound egress where privacy and platform constraints allow.
- Prepare incident response playbooks for suspected mobile credential capture, including credential reset decisions, affected app review, and evidence preservation.
Analyst notes and limits
The ATT&CK object is an iOS mobile detection analytic, AN1779, tied to DET0676. It provides a useful behavioral chain but no official detection query, no tactic assignment, and no relationship context. The strongest defensive use is to convert the described sequence into mobile app monitoring requirements and validation tests.
This take is based only on the supplied STIX fields and external reference. It does not establish adversary attribution, active exploitation, prevalence, impact, or existing detection coverage. Local app architecture, available iOS telemetry, privacy constraints, and authentication design will determine whether this analytic is implementable.
Analytic 1779
Defender correlates a look-alike prompt inside an app (e.g., faux Apple ID password view, webview of brand login) with timing against scene/foreground activation, optional push notification bait, then local form cache writes and/or small egress. Chain: scene activation around sensitive UI → suspicious prompt creation (UIKit events without expected auth controller) or webview navigated to look-alike domain → local cache write → near-term egress
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.1 | Current bundle | 71e9beec1c05… |
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.
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 AN1779Open source URL
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.