New Android Malware Herodotus Mimics Human Behaviour to Evade Detection
28 October 2025
Jump to
During our usual monitoring activity of malicious distribution points, Mobile Threat Intelligence service observed unknown malicious samples distributed next to well-known malware variants like Hook and Octo. Despite the shared distribution infrastructure, these samples turned out to be closer to a different malware family previously discovered by ThreatFabric analysts – Brokewell. Nevertheless, the newly discovered malware, named Herodotus by its developers, does not seem to be a direct evolution of Brokewell, but a new threat with parts of Brokewell stitched together with original parts.
In this report we uncover the new threat on mobile threat landscape with several key takeaways:
- Herodotus is designed to perform Device-Takeover while making first attempts to mimic human behaviour and bypass behaviour biometrics detection.
- Active campaigns observed in Italy and Brazil, involving Device-Takeover attacks by Herodotus.
- Malware-as-a-Service is already announced while the malware is still in development.
- Links to Brokewell show further potential for capabilities enrichment.

Herodotus: writing Histories of fraud
Being a modern Device-Takeover banking Trojan, Herodotus follows latest trends and regular Modus Operandi. The actor behind this threat ("K1R0") already announced it as Malware-as-a-Service on one of the underground forums:

Distribution is done via side-loading, potentially involving SMiShing leading to the malicious link that contains the dropper to be downloaded.
The dropper used by Herodotus is written by the same developer and has only been seen distributing Herodotus so far. Once launched, dropper attempts to install the payload in order to bypass Android 13+ restrictions on Accessibility Services.

After the installation of the payload, the dropper automatically starts Herodotus payload. It is further opening the Accessibility Service settings page, urging the victim to enable it. Once enabled, Herodotus launches a “block overlay”, mimicking a loading screen to hide the suspicious activity of granting all the necessary permissions.
Following that, Herodotus is ready to perform credential stealing and further Device-Takeover fraud. The Trojan collects the list of installed packages and sends it to the C2, which returns the list of those to target and the corresponding links to load overlays from. From this moment, Herodotus is waiting for the victim to open a targeted application, which will be overlayed with a fake screen requesting credentials from the account.
Till this point there is little special about Herodotus - there are multiple banking Trojans currently active on the threat landscape following the same approach, and Herodotus is following the trends here. However, there is a feature that sets Herodotus apart from most of the Device-Takeover malware families - it attempts to mimic human behaviour during the remote-control session.
Humanising fraud
Remote control features are essential for a modern banking Trojan, especially for Malware-as-a-Service families. Herodotus has remote control features abusing Accessibility Service – using it to perform actions on the remote device. From the very beginning of its history, Herodotus provides its operators with the ability to:
- Click element on the screen
- Click by coordinates
- Perform swipes
- Input text
- Perform global actions (Back, Home, Recents)
Operators are using these features to remotely control the infected device - opening targeted applications, clicking through screens, filling in the transaction details to transfer money from victim's account.
For the text input, there are different options for criminals during the remote session. They could interact with device's keyboard, typing in mule account details. However, this approach is vulnerable to typos/misclicks due to multiple reasons: poor remote session connection, misalignment of elements on the screen of operator, human error. That is why MTI observes banking Trojans providing operators with option to directly "set" the text input field, in other words - deliver specified text to the field of choice without the necessity to use device's keyboard. It is achieved either by performing action "ACTION_SET_TEXT" or via clipboard - first setting clipboard and then pasting the text in the text field. This approach ensures that the right text is delivered to the right text input field in one action and without any interruptions.
However, from the application's perspective, the user behaviour can look suspicious and machine-like, raising the question of whether there is a real user interacting with the application and entering the data. These sort of events should be detected by behaviour-based anti-fraud engines and marked as possible indicators of a Device-Takeover attack.
Herodotus, unlike many other banking Trojans, is one of the first to attempt to humanise remote actions. In order to make the input look like it is typed in by an actual user, the text specified by the operator is split into chars, and they are separately set with random delays from each other:

Randomization of delay between set text events
Delay specified is in range of 300 – 3000 milliseconds (0,3 - 3 seconds). Such a randomisation of delay between text input events does align with how a user would input text. By consciously delaying the input by random intervals, actors are likely trying to avoid being detected by behaviour-only anti-fraud solutions spotting machine-like speed of text input
We have seen examples where developers were pausing the execution of automated actions in order to wait for the UI to be updated (especially on old devices being slow in loading UI), however, there were no random delays as there is no necessity in randomness. Thus, with high confidence we suspect that such a delay is an attempt to mimic human behaviour while automating the input of the text.
What does this mean for detection?
- Behavioural Detection systems which have a rudimentary capability to measure input timings may produce erroneous, lower risk assessments, leading to the intended bypass.
- Newer generation systems which model individual user behaviour will detect an anomaly, leading to higher risk, rather than lower risk.
- A malware detection system, able to classify malware family and version, will also help avoiding being tricked by Herodotus.
Other features
Blocking overlay becomes a trend amongst malware developers, and Herodotus is no exception. In order to hide fraudulent activity, Herodotus can display an overlay on top of the device UI. It will be opaque for victim, while being semi-transparent for the operator:

Code responsible for handling command “opacityOverlay”
Moreover, a separate command is used to show blocking overlay on top of the banking application. It is also used to hide fraudulent activity as well as keep victim away from the banking application and prevent them spotting fraud results and reaching out to bank support.

Translation from Italian: “PLEASE WAIT
The online bank is verifying the information you requested.
Please wait a few moments...
Verifying your credentials...”
Besides remote-control features, Herodotus has all the essential capabilities of a modern Android banking Trojan:
- Overlay attack with fake pages displayed on top of the targeted applications requesting credentials
- SMS stealer to intercept 2FA codes
- Accessibility logging (intercepting everything displayed on the screen)
Screenshots provided by the developer on the underground forum promoting Herodotus as Malware-as-a-Service give an operator's view on controlling the infected devices and options available there:

It is worth noting that this page contains the controls to set text (buttons “SEND 1” and “SEND 2”). These are the controls responsible for human-like text input that we highlighted earlier, there is a checkbox “Delayed text” controlling this behaviour:

Full set of the commands supported by Herodotus is available in Appendix.
Campaigns analysis
In its communication with the command and control server Herodotus relies on MQTT protocol. At the moment of writing the report, Herodotus uses the same domain google-firebase[.]digital with different subdomains, likely indicating different actors behind it targeting different regions. During the research of Herodotus, Mobile Threat Intelligence observed 7 different active subdomains, including those belonging to the developer and used for testing the malware.
Mobile Threat Intelligence service observed several active campaigns of Herodotus targeting users in Italy and Brazil.
In Italy, Herodotus used application name "Banca Sicura" ("Safe Bank" from Italian) connecting to subdomain "af45kfx".
Another campaign was observed targeting Brazilian users with application named “Modulo Seguranca Stone”. This name likely refers to a payment acquirer in Brazil, and Herodotus is masquerading as a “security module” for its application, connecting to “g24j5jgkid” subdomain.
While not observing other active campaigns, MTI was able to obtain the overlay pages used by Herodotus targeting financial organisations in the US, Turkey, the UK, Poland as well as crypto wallets and exchanges. Considering that the malware is still in active development state, we can expect Herodotus further evolving and used widely in global campaigns.
Following Brokewell
Reverse engineering of Herodotus reveals lots of links to another banking malware family discovered by ThreatFabric back in April 2024 - Brokewell. First similarity is the obfuscation technique used in both malware families: encrypted strings are stored in native code and are decrypted once the corresponding Java class is used. This helps the developers to avoid detection as well as complicate the analysis of the malware.
Further analysis of the decrypted strings shows direct mentions of Brokewell:

“BRKWL_JAVA” string in Herodotus

“BRKWL_JAVA” string in Brokewell
Such an overlap of unique strings is not a coincidence. Herodotus invokes a dynamic module from Brokewell. However, its usage is very limited: rich set of its capabilities is simply omitted (like TOR C2 communication, contact list manipulation, screenshotting, dumping cookies, etc.), only a few methods related to clicking specific coordinates or elements are invoked:

“ACSINSTC_click_elem” method is invoked and further used by Herodotus. Other methods are omitted
However, it is important to note that the dynamically loaded module from Brokewell is not compatible with Herodotus in the current state: it contains malware-specific C2 communication protocol and data format, which is implemented differently in Herodotus. This makes it difficult to use the module to its full capacity, but in case they have the access to raw source codes of Brokewell, the developer behind Herodotus could potentially re-write it to be compatible. Currently observed samples only allow us to hypothesise that Herodotus' developers have access to some source codes which might be compiled – which makes it difficult to update.
Conclusion
The discovery of Herodotus, yet another Device-Takeover banking Trojan in an already threat-rich landscape, shows the growing popularity of these threats amongst cybercriminals, as well as commercial efficiency of Malware-as-a-Service “business model”, as Herodotus is already announced by the threat actors as a threat to rent.
It is under active development, borrows techniques long associated with the Brokewell banking Trojan, and appears purpose-built to persist inside live sessions rather than simply steal static credentials and focus on Account Takeover. A standout capability – the randomisation of time intervals between text inputs – likely aims to mimic human behaviour closely enough to bypass bot and automation detection, session heuristics, and some behavioural biometrics.
With more mobile malware families like Herodotus the implications for financial organization are as follows: fraud controls that rely primarily on interaction tempo, keystroke cadence, or simple device fingerprints are increasingly vulnerable. Behaviour biometrics is a great indicator of suspicious activity, but only as a part of a layered approach that considers not only behaviour of the user but also their device environment, being able to identify risks like Herodotus running on it.
Appendix
Bot commands
|
Commands |
Description |
|
BACK |
Perform Back global action |
|
CLICKDESC |
Click element by description |
|
CLICKELEMENT |
Click element by ID |
|
CLICKHINT |
Click element by hint |
|
CLICKTXT |
Click element by text |
|
DELPKG |
Uninstall package |
|
HOME |
Perform Home global action |
|
HVNCA11Y |
Enable “text mode”: enumerate elements on the screen and their positions |
|
INITIALIZE |
Perform set of global actions |
|
INJPATTERNPKG |
Set URL to load the overlay for device PIN / Pattern |
|
KEEPALIVE |
Wake the device |
|
LOCATIONBRO |
Request location permission |
|
NOTIFICATIONS |
Open notifications panel |
|
OPNPKG |
Start specified application |
|
RECENTS |
Perform Recents global action |
|
STARTPWA |
Not implemented yet |
|
SWIPE |
Perform swipe by coordinates |
|
TAP |
Perform tap by coordinates |
|
TXTBYDESCRIPTION |
Set text in element by description |
|
TXTBYHINT |
Set text in element by hint |
|
TXTBYTXT |
Set text in element by text |
|
TXTELEMENT |
Set text in element by element ID |
|
VNC |
Start remote screensharing session |
|
VNCA11Y |
Start remote screensharing session based on screenshots Accessibility Service (for Android 11+) |
|
YESUNINSTALL |
Uninstall malware from the device |
|
defineinj |
Set URL to load the overlay for specific targeted application |
|
opacityOverlay |
Enable opaque block overlay with specified opacity |
|
packagesData |
Get list of installed applications |
|
qualityStreamVNC |
Set quality parameter for screensharing session |
|
removeOverlay |
Remove block overlay |
|
sendNotification |
Post a notification |
|
sendOverlayLoading |
Enable block overlay from HTML |
|
sendText1 |
Set the text in the accessibility node |
|
sendText2 |
Set clipboard and paste the text in the accessibility node |
|
smsData |
Get SMS messages |
|
smsDataDefault |
Request default SMS manager privileges |
Indicators of Compromise
Sample
|
SHA-256 |
Package name |
Application name |
C2 |
|
53ee40353e17d069b7b7783529edda968ad9ae25a0777f6a644b99551b412083 |
com.cd3.app |
Chrome |
gj23j4jg[.]google-firebase[.]digital |