Mobile T1628 Hide Artifacts: Finding Hidden Android Apps, Activity and Files

Mobile malware that hides its own icon, waits until the user puts the phone down, or tucks captured photos into folders the gallery ignores can stay on a device for months because nobody sees anything wrong. MITRE ATT&CK for Mobile tracks this behaviour as T1628 Hide Artifacts, under the Defense Evasion tactic (TA0030), with three sub-techniques. ATT&CK v20 lists the technique and all three sub-techniques for Android only. This guide covers what each sub-technique looks like, the Android platform changes that limit it, how to detect it with mobile device management (MDM), mobile threat defence (MTD) and forensic acquisition, and how to respond. It is written for mobile security engineers, endpoint teams and incident responders, and goes deeper than the MITRE ATT&CK for Mobile Guide.

Key takeaways

• Android is the platform ATT&CK lists. T1628 and its sub-techniques are mapped to Android in ATT&CK v20; one procedure example (YiSpecter) describes hiding an icon from the iOS springboard, but ATT&CK does not list iOS as a platform for this technique.
• Icon hiding needs no permission. ATT&CK notes that suppressing a launcher icon requires no special permission, which is why it appears in dozens of banking trojans and spyware families.
• Android 10 changed the game for icons. From Android 10 most third-party apps that hide their icon still get a synthesized launcher entry that opens the app's details page, so user awareness of that entry matters.
• Inventory beats visual inspection. The reliable control is comparing the package list from MDM or MTD with an approved baseline, not looking at the home screen.
• Conceal Multimedia Files has no standard detection. ATT&CK states that no standard detection method exists for T1628.003 and advises against preventive controls, so forensic review carries the load.

What T1628 covers

ATT&CK describes T1628 as abuse of mobile operating system features and developer APIs that have legitimate uses, such as hiding a launcher icon for an app with no usable interface, to hide artifacts from the user. The goal is persistence through invisibility: if the user cannot see the app or its effects, they will not remove it. The technique sits beside related mobile evasion techniques such as T1630 Indicator Removal on Host and T1629 Impair Defenses, and mirrors Enterprise T1564 Hide Artifacts.

T1628.001 Suppress Application Icon

A malicious app removes its icon from the launcher after install or first launch. ATT&CK lists more than twenty software families doing this, from banking trojans (Cerberus hides its icon after its first launch, Ginp and Gustuff after installation) to commercial surveillance tools (FlexiSpy can hide its own icon and the icon of SuperSU on a rooted device). FakeSpy hides its icon only when it detects an emulator, a sign that icon hiding is also used against analysis sandboxes. Mandrake can hide its icon on older Android versions.

ATT&CK records the platform change that limits this. Beginning in Android 10, an app's icon is fully hidden only if it is a system app, requests no permissions, has no launcher activity, or the device is fully managed or the app is in a work profile. Otherwise Android shows a synthesized activity: a launcher icon that opens the app's details page in system settings. Malware that requests permissions, which is nearly all of it, therefore leaves a visible entry on current Android.

• Mitigation M1006 Use Recent OS Version: keep devices on Android 10 or later so the synthesized entry appears. Enforce a minimum OS version through MDM compliance policy.
• Mitigation M1011 User Guidance: show users what a synthesized entry looks like (an icon that opens an app info screen rather than an app) and ask them to report one they do not recognise.
• Note for managed fleets: on fully managed devices and in work profiles the icon can be fully hidden, so the user cannot be the control there. Rely on the managed app inventory instead.

T1628.002 User Evasion

User Evasion is about timing and concealment rather than files. ATT&CK gives the motion sensor example: an app reads the accelerometer or gyroscope, which needs no user permission, to tell when the device is in use, then runs while it is idle and stops when the user picks it up. BusyGasper is documented doing this. Other procedure examples use the screen: BRATA can turn off, or appear to turn off, the screen while it acts; Crocodilus and SpyC23 display a black or blank overlay over malicious activity, and Crocodilus also mutes the device. Hornbill uploads data infrequently to avoid user attention and battery drain, and FluBot localises its notifications to the device language so they look less suspicious.

• Mitigation M1010 Deploy Compromised Device Detection Method: ATT&CK notes that mobile security products in the Samsung Knox for Mobile Threat Defense programme can examine running applications while the device is idle, which is when this class of malware is active.
• Overlay abuse is the precondition: black-screen overlays and remote control usually depend on accessibility access. Restricting which apps may use accessibility services (see T1629) removes much of this capability. See the Mobile App Permissions guide.

T1628.003 Conceal Multimedia Files

On Android, a folder containing a file named .nomedia is skipped by the Gallery app and other apps are asked not to scan it, so pictures, video and screenshots stored there do not appear to the user. ATT&CK notes the technique is often used by stalkerware and spyware, and lists the Windshift group hiding multimedia files from the user.

ATT&CK maps only M1059 Do Not Mitigate to this sub-technique, because .nomedia files have legitimate uses (messaging apps, games and caches use them), and its detection strategy states that no standard detection method currently exists. In practice, defenders find concealed media during forensic acquisition: a .nomedia folder holding camera or screenshot content inside a storage path owned by an unrecognised package is a strong lead.

Detection and measurement

ATT&CK v20's detection strategies for T1628 correlate Android Enterprise management state (managed package inventory, permission grant state through DevicePolicyManager.getPermissionGrantState()) with app vetting evidence (manifest and requested permission review, dynamic API traces such as calls that disable a launcher component, or sensor listener registration by apps outside an approved list). Treat MDM state queries as periodic observations, not real-time events.

Metrics that show the control works:

• Percentage of managed Android devices on Android 10 or later.
• Percentage of devices whose full package inventory was reconciled against the baseline in the last 7 days.
• Count of unapproved packages found per month, and median time from detection to removal.
• Percentage of devices reporting Play Protect on (no POSSIBLE_RISK verdict) in apps that use the Play Integrity API.
• User reports of unrecognised app info entries, as a measure of awareness training.

Implementing the controls

1. Baseline the fleet. Export the package list from MDM for every Android device and build an approved list per device profile. Unknown packages are the starting point for every T1628 investigation.
2. Block sideloading. Apply DISALLOW_INSTALL_UNKNOWN_SOURCES through the device policy controller; Android's DPC documentation notes that existing apps remain and adb installs into a personal profile still work, so pair it with inventory checks.
3. Enforce a minimum OS and patch level. Set compliance rules that quarantine devices below Android 10 or with stale security patches.
4. Turn on security logging on company-owned devices. Only a device owner can enable it, with setSecurityLoggingEnabled(); pilot on a small ring first because of log volume, then expand.
5. Deploy MTD with idle-time scanning where available and feed its findings into the SIEM. See the Mobile Threat Defense Buyer's Guide.
6. Rollback: if security logging or MTD causes battery or performance complaints in the pilot ring, reduce collection to compliance checks and inventory first; do not remove the inventory baseline.

Responding to a hidden app

• Preserve first: before removal, acquire the device or at least the package list, permission grants and storage paths owned by the package. Removal destroys evidence of what was captured.
• Check for concealed media: search shared storage for .nomedia folders owned by the package and record their contents for scoping.
• Remove and reset credentials: uninstall through MDM or suspend the app with setPackagesSuspended() while you investigate, then rotate passwords, session tokens and any API keys used on the device.
• Consensual forensics for high-risk users: Amnesty International's Mobile Verification Toolkit (MVT) supports consensual analysis of Android and iOS devices against published indicators. See the Mobile Spyware Infection Response Playbook and the Mobile Forensics Guide.

Where identity fits

Hidden banking trojans and spyware exist to steal credentials: one-time codes, session cookies and tokens held by mobile apps. When a hidden app is found, treat every token issued to that device as exposed, including OAuth refresh tokens and app API keys. Bind high-value sessions to device integrity signals where the platform supports it. See the Mobile Access Credentials and Mobile App Attestation guides.

Framework mapping

Common failure patterns

• Trusting the home screen: asking users whether they see a suspicious app. On managed devices and work profiles the icon can be fully hidden, and users rarely recognise a synthesized entry.
• Old Android left in service: devices below Android 10 allow full icon hiding with no visible trace; they stay in the fleet because they still work.
• Removing before preserving: uninstalling a hidden spyware app first loses the concealed media that shows what was taken.
• Allowlisting accessibility by default: overlay-based user evasion depends on accessibility access that was never restricted.
• Alerting on every .nomedia file: the file is common and legitimate, so naive rules are switched off after a week. Correlate with package ownership and media type instead.

Practitioner checklist

• Maintain an approved package baseline per Android device profile and reconcile it at least weekly.
• Quarantine devices below Android 10 through MDM compliance rules.
• Block installs from unknown sources on managed devices and work profiles.
• Restrict accessibility services to an explicit allowlist on managed devices.
• Enable security logging on company-owned devices and forward it to the SIEM.
• Read the Play Protect and app access risk verdicts in your own apps' Play Integrity checks.
• Teach users what an unfamiliar app info entry in the launcher means and how to report it.
• Preserve package data and concealed media before removing a suspicious app.

Standards and references

• MITRE ATT&CK: Hide Artifacts (Mobile T1628)
• MITRE ATT&CK: Suppress Application Icon (T1628.001)
• MITRE ATT&CK: Conceal Multimedia Files (T1628.003)
• Android Developers: Security for device policy controllers
• Android Developers: Play Integrity API integrity verdicts
• Google: Play Protect on-device protections
• MVT Project: Mobile Verification Toolkit documentation

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Mobile Malware Guide · Mobile Device Management Security Guide · Mobile Forensics Guide