S1055: SharkBot

SharkBot is a banking malware, first discovered in October 2021, that tries to initiate money transfers directly from compromised devices by abusing Accessibility Services.[1]

MobileS1055MalwareObject v1.0 Modified Apr 16, 2025, 21:22 UTC (UTC+00:00)

SharkBot matters because it is Android banking malware described by MITRE as attempting to initiate money transfers from compromised devices by abusing Accessibility Services. For security leaders, the practical issue is not only one malicious app: it is whether mobile controls can see risky permission abuse, post-install code changes, credential or OTP capture paths, and command-and-control traffic on devices used for business or financial workflows.

Executive priority

Prioritize SharkBot as a mobile fraud and identity-readiness scenario. Leaders should ask whether corporate-managed and BYOD Android devices have enforceable app governance, visibility into Accessibility Services misuse, SMS/notification exposure, and evidence suitable for incident response or audit. This is especially relevant where mobile devices are used for banking, approvals, MFA, privileged access, or customer operations.

Technical view

ATT&CK provides no official detection text for SharkBot, but the relationships give concrete validation areas. SOC and mobile security teams should map Android telemetry to the related behaviors: obfuscated files, runtime code download, keylogging, GUI input capture, process discovery, web-protocol C2, input injection through accessibility APIs, notification access, SMS control and SMS collection, encrypted C2, ingress transfer, DGA use, out-of-band data, exfiltration over C2, malicious app uninstall behavior, and application versioning. Coverage should be tested against both pre-install app reputation controls and post-install behavioral monitoring.

Likely telemetry

Android app inventory and package/version history
Requested and granted permissions, especially Accessibility Services, notification access, SMS-related permissions, and default SMS handler status
Mobile device management or enterprise mobility management compliance events
Mobile threat defense alerts for suspicious app behavior, runtime code loading, obfuscation, or risky accessibility use
DNS and web traffic metadata from Android devices, including unusual domains, DGA-like patterns, and HTTPS destinations

Detection direction

Validate whether tools can detect high-risk combinations rather than single indicators, such as accessibility access plus input injection, notification/SMS access, or runtime code download.
Tune carefully for legitimate accessibility tools, keyboards, messaging apps, enterprise applications that download modules, and normal encrypted web traffic.
Review app-version monitoring because ATT&CK links SharkBot to application versioning, where a previously benign app can become malicious after update.
Check whether DNS and web telemetry can support DGA and web-protocol C2 investigation without relying on full payload visibility.
Confirm mobile IR procedures preserve app package details, permissions, version history, network destinations, and uninstall traces, since malicious apps may attempt removal.

Mitigation priorities

Start with mobile app governance: managed app stores, app allowlisting or risk-based blocking, and controls over sideloading where appropriate.
Restrict or monitor sensitive Android permissions and roles, especially Accessibility Services, notification access, SMS permissions, and default SMS handler assignment.
Use MDM/UEM and mobile threat defense policies to flag risky app updates, runtime code loading, obfuscation, and suspicious network behavior.
Reduce dependence on SMS or notification-delivered one-time codes for sensitive workflows where feasible, because related techniques include SMS and notification access.
Prepare mobile incident response playbooks for isolating a device, collecting app and permission evidence, revoking exposed credentials, and reviewing financial or approval activity.

Analyst notes and limits

The strongest decision value comes from the relationship set: SharkBot is not represented as a single observable but as a cluster of Android mobile behaviors involving accessibility abuse, credential/input capture, SMS and notification access, evasive app behavior, and C2/exfiltration patterns. Treat this as a control-validation use case for mobile visibility and identity-risk workflows.

MITRE does not provide official detection guidance, tactics, aliases, labels, or guaranteed indicators in the supplied object. The external reference identifies a public research article, but no additional details beyond the supplied fields should be assumed. Local device management, privacy constraints, and mobile telemetry availability will determine actual detection and response coverage.

Official MITRE ATT&CK definition

SharkBot

SharkBot is a banking malware, first discovered in October 2021, that tries to initiate money transfers directly from compromised devices by abusing Accessibility Services.[1]

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.

ATT&CK relationship table

Techniques used

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

Filter related techniques 18 rows

Domain	ID	Name	Relationship / procedure
Mobile	T1407	Download New Code at Runtime	SharkBot can use the Android “Direct Reply” feature to spread the malware to other devices. It can also download the full version of the malware after initial device compromise.[1]
Mobile	T1644	Out of Band Data	SharkBot can use the “Direct Reply” feature of Android to automatically reply to notifications with a message provided by C2.[1]
Mobile	T1646	Exfiltration Over C2 Channel	SharkBot can exfiltrate captured user credentials and event logs back to the C2 server. [1]
Mobile	T1424	Process Discovery	SharkBot can use Accessibility Services to detect which process is in the foreground.[1]
Mobile	T1417.001	Keylogging Sub-technique	SharkBot can use accessibility event logging to steal data in text fields.[1]
Mobile	T1637.001	Domain Generation Algorithms Sub-technique	SharkBot contains domain generation algorithms to use as backups in case the hardcoded C2 domains are unavailable.[1]
Mobile	T1630.001	Uninstall Malicious Application Sub-technique	SharkBot has C2 commands that can uninstall the app from the infected device.[1]
Mobile	T1636.004	SMS Messages Sub-technique	SharkBot can intercept SMS messages.[1]
Mobile	T1516	Input Injection	SharkBot can use input injection via Accessibility Services to simulate user touch inputs, prevent applications from opening, change device settings, and bypass MFA protections.[1]
Mobile	T1661	Application Versioning	SharkBot initially poses as a benign application, then malware is downloaded and executed after an application update.[1]
Mobile	T1582	SMS Control	SharkBot can hide and send SMS messages. SharkBot can also change which application is the device’s default SMS handler.[1]
Mobile	T1544	Ingress Tool Transfer	SharkBot can download attacker-specified files.[1]
Mobile	T1406	Obfuscated Files or Information	SharkBot can use a Domain Generation Algorithm to decode the C2 server location.[1]
Mobile	T1417.002	GUI Input Capture Sub-technique	SharkBot can use a WebView with a fake log in site to capture banking credentials.[1]
Mobile	T1521.002	Asymmetric Cryptography Sub-technique	SharkBot has used RSA to encrypt the symmetric encryption key used for C2 messages.[1]
Mobile	T1437.001	Web Protocols Sub-technique	SharkBot can use HTTP to send C2 messages to infected devices.[1]
Mobile	T1521.001	Symmetric Cryptography Sub-technique	SharkBot can use RC4 to encrypt C2 payloads.[1]
Mobile	T1517	Access Notifications	SharkBot can intercept notifications to send to the C2 server and take advantage of the Direct Reply feature.[1]

Relationship explorer

All related ATT&CK context

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.0
Created: Jan 18, 2023, 19:44 UTC (UTC+00:00)
Modified: Apr 16, 2025, 21:22 UTC (UTC+00:00)
Raw hash: 3c40c484485fbd40...

Imported snapshots across ATT&CK releases (1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	Jun 3, 2026, 07:54 UTC (UTC+00:00)	1.0	Apr 16, 2025, 21:22 UTC (UTC+00:00)	Current bundle	`3c40c484485f…`

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]
nccgroup_sharkbot_0322

RIFT: Research and Intelligence Fusion Team. (2022, March 3). SharkBot: a “new” generation Android banking Trojan being distributed on Google Play Store. Retrieved January 18, 2023.
Open source URL
[2]
mitre-attack S1055
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