Update June 22, 2020: thanks to @ektoplasma_ for pointing out the crypto algorithm is not “home-made” but RC4.
The unpacked sample has sha256:
When it is started, the malware communicates with a remote C&C to report it has infected a phone’s victim (provides phone’s model, release, product name, country and phone number).
All communication to the C&C has the following form:
- The URL to contact is configurable, and saved in the malware’s configuration file (a shared preferences file named
set). The default URL to contact depends on the sample. For the one we analyze, it is
- The page to reach depends on the nature of the action and data:
- The PHP page usually takes an argument
p, which contains the victim’s Android ID followed by additional data, encrypted and then converted to Base64. The algorithm is RC4 and uses a hard-coded key
The C&C responds to the initial infection report with a list of commands and/or settings. Most commands correspond to an entry in the configuration file. For example, the C&C can activate encryption of files on the smartphone (crypto locker). This features is referred to in the code as “Cryptolocker”, “Cryptor” or “AnubisCrypt”. The C&C sends a command such as
|cryptokey=key:50:BTC|endcrypt. This updates several configuration parameters such as
crypt to request encryption,
decrypt to request decryption), and triggers file encryption code: all all files located in
/sdcard are encrypted. The encryption algorithm is seeded by the “encryption” key. Encrypted files get the suffix
Encrypting or decrypting the file system is reported to the remote C&C (on page
a6.php) , with an (encrypted) status message saying for example “The Cryptor is activated, the file system is encrypted by key…”.
Once files are encrypted, a ransom message is displayed. The template is stored in the configuration under
htmllocker, and the amount and currency to request are configurable (
The malware implements numerous features: SMS interception and deletion, searching for files, listing installed applications, recording audio, screen capture, tracking geographic location, locking the screen, have the victim send spam SMS…
The malware propagates to other victims via SMS. There are 2 different methods:
- Option 1: the malware retrieves the list of contacts on the victim’s smartphone (
getNumberis set to true/false in the config file) and we assume malware author(s) try to infect them later
- Option 2: the malware can have the victim’s smartphone directly send SMS to its contacts. The text to send is configured by the setting
The malware asks the C&C (page
a17.php) who it should spam: the answer contains the name of the contact and his/her phone number. The malware crafts the spam using a template read from configuration parameter
textSPAM, and sends the SMS.
If the configuration file has option
perehvat_sms (intercept in Russian) set to true, the malware intercepts any incoming SMS and sends its content to a remote C&C. It can also report the contents of the Sent and Drafts box.
If the option
del_sws is set, it disables the ringer and deletes the SMS on the victim’s phone. The malware implements SMS interception using the well-known receiver technique: it creates a
BroadcastReceiver with high priority (
999), which therefore handles SMS before the smartphone’s normal apps.
The keylogging feature is implemented as an AccessibilityService. Those services are normally meant to help end users with disabilities, but the malware abuses that, and asks for accessibility settings:
Then, it implements a service which extends an AccessibilityService and receives accessibility events in
onAccessibilityEvent it overrides. Each button clicked, or focus change gets logged to a file
Finally, the content of
keys.log is reported to the C&C.
When this feature is enabled, a black rectangle is continuously displayed on the screen. This feature is controlled by malware’s settings
On request, the malware can communicate through a SSH tunnel. The C&C requests this via a command
The malware creates a server socket, which listens for incoming connexions on port 34500, and then reads/writes on the incoming socket.
We seldom see SSH Tunneling in Android malware, so it’s interesting.
Some specific remote access features of the malware are handled by a different URL: the botmaster sends a command like
|startrat=URL|endrat, the specified URL gets saved in configuration parameter
websocket, and this URL is used to capture screen, record audio or open/delete directories on the smartphone. The botmaster sends directly commands on the websocket URL:
startscreenVNC (screen capture),
opendir (list files in a given directory),
deletefilefolder. The data is sent back to the C&C on the websocket URL. Page names are like on the standard URL,
/o1o/a2.php etc, but the base URL is potentially different.
For example, the recording is triggered by RAT command
startsound. This launches a service (named
brtltydqhiuqbb) which instantiates a MediaRecord object and starts recording for 3 seconds. The audio file can be found on the SD card (
.amr extension), and it is posted to the WebSocket URL page
Strangely the audio recording feature is also available outside the RAT: the C&C sends a command
|recordsound=seconds|endrecord. Same, a MediaRecord object is instantiated and records for the supplied number of seconds. The audio file is stored on the SD card (see below). It is posted back to the C&C (not the WebSocket URL) on page
This ends the analysis of the sample. There are a few features I haven’t covered (phone call forwarding, URL “injection”, open the browser with a given URL, send a USSD code…) but the main parts are there 😃
Similar sample, Corona Tracker, wasn’t packed: here.