Dissecting the Escobar bot

6 min readApr 6, 2022

The com.escobar.pablo is yet another banking Trojan which, between else abuses the Android’s Accessibility Service (a11y in short) in order to take over the mobile device’s UI. This service has been designed to assist users with disabilities and it is so powerful, that can literally act in behalf of the user by clicking, reading and generally reacting on any UI event that takes place in the mobile device.

TL;DR, a banking-type Trojan comes with a list of targeted applications (usually banking apps). The a11y, allows the trojan to read which app is currently in the device’s foreground. If the app is targeted the malware will start a phishing activity which will take over the device’s foreground. The behaviour is similar to the one bellow (although that in this POC I am using a different service):

No A11y abuse

Edit description

www.youtube.com

We won’t go more into details about the a11y and why the user must be very careful when providing access to it (there are countless posts about that). Additionally, we won’t focus on the Escobar’s common characteristics with other families of the same category. You can refer to this post from Cyble in case you want to read more about it.

Compared to other families of this category, this bot was found to include some additional features, like stealing the Google Authenticator Codes and creating a pseudo-VNC session and this is where this post will focus.

Initialisation

The application’s entry point was found to be the .MainActivity. The onCreate callback of this class will first perform an environment reconnaissance by checking the following system properties:

!MainActivity.hasHttpProxy() && ((!Build.BRAND.startsWith(“generic”) || !Build.DEVICE.startsWith(“generic”)) &&(!Build.FINGERPRINT.startsWith(“generic”) && !Build.FINGERPRINT.startsWith(“unknown”)) && (!Build.HARDWARE.contains(“goldfish”) && !Build.HARDWARE.contains(“ranchu”)) && (!Build.MODEL.contains(“google_sdk”) && !Build.MODEL.contains(“Emulator”) && !Build.MODEL.contains(“Android SDK built for x86”) && !Build.MANUFACTURER.contains(“Genymotion”)) && (!Build.PRODUCT.contains(“sdk_google”) && !Build.PRODUCT.contains(“google_sdk”) && !Build.PRODUCT.contains(“sdk”) && !Build.PRODUCT.contains(“sdk_x86”) && !Build.PRODUCT.contains(“sdk_gphone64_arm64”) && !Build.PRODUCT.contains(“vbox86p”) && !Build.PRODUCT.contains(“emulator”) && !Build.PRODUCT.contains(“simulator”)As well as:!this.getApplicationContext().getSharedPreferences(“sharedPrefs”, 0).getBoolean(“setup”, false)

The setup parameter is fetched from the shared preferences and signals whether the application runs for the first time while the rest are used to detect a virtual machine environment. Upon failure on any of the conditions above the application will exit. Alternatively, it will create a notification that will keep requesting the user to enable the a11y service. At the same time, it will load the file:///android_asset/welcome.html in the main activity’s WebView:

Approving access to a11y will cause the malware to perform the following actions:

Close the accessibility settings menu and remove the main activity from the foreground as well as from the resents queue (1)
Restart the main activity (2)
Start a thread that will maintain the command-listener, notification-listener as well as a touch-implementation service running (3)
Start a pseudo-VNC service (4)

Starting the MainActivity once again, will have as a result to follow a different code branch in the onCreate callback:

This will trigger the System’s Permissions-Request dialog for the following set of permissions:

“android.permission.READ_CONTACTS”, 
“android.permission.SEND_SMS”, 
“android.permission.RECEIVE_SMS”, 
“android.permission.READ_SMS”, “android.permission.CAMERA”,
“android.permission.READ_PHONE_STATE”, “android.permission.READ_EXTERNAL_STORAGE”,
“android.permission.WRITE_EXTERNAL_STORAGE”, “android.permission.ACCESS_COARSE_LOCATION”, “android.permission.ACCESS_FINE_LOCATION”, “android.permission.READ_CALL_LOG”, “android.permission.RECORD_AUDIO”, 
“android.permission.CALL_PHONE”

The malware will use the a11y capabilities to auto-approve the above as well as to enable access to the notification listener and disable the Google Play Store scanning service.

C2 Communication

Starting from the onStartCommand of the CommandListener class, we observe a call to the Location’s manager requestLocationUpdates function followed by the start of an additional runnable (see highlighted line below):

The device’s location will be sent to the C2 every time the device location changes, as the location query parameter in the following endpoint /project/apiMethods/updateLoc.php?botid=<android_id>&location=. The functions in charge for this task are depicted below:

onLocationChanged will call the OooOooO function depicted bellow, to send the device’s location to the C2

The highlighted runnable (see initial figure) will start polling the C2 every 5 seconds in order to send status updates and fetch commands which will execute on a separate thread. The OooO00o function depicted below is used to fetch commands from the C2:

The request is repeated with a period of 5 seconds, while the server‘s reply may contain one of the following commands:

Push CC Injection, Take Photo, Send SMS, Send SMS to All Contacts, Inject a web page, Download File, kill Bot, Push Bank Injection With Time, Push Bank Injection, Uninstall an app, Record Audio, Get Google Authenticator Codes, Call a number/Run USSD code, Start VNC, Stop VNC, VNCClick, VNCHold, VNCDrag, SWIPE UP, SWIPE DOWN, RECENTS, HOME, BACK, SCROLL UP, SCROLL DOWN, NOTIFICATIONS, SCREEN OFF, SCREEN ON.

As the functionality of most of the commands above can be concluded by the word semantics, we will focus on the Activity Injections, the Google Authenticator code exfiltration and the Pseudo-VNC implementation as especially the last, is not often encountered.

Pseudo-VNC implementation

The particular service is triggered by the Start VNC C2 command and is stopped by the Stop VNC:

The class that implements the service is a runnable which uses the takeScreenshot API call in order to take screenshots of the mobile’s UI on short periods of time (100 milliseconds):

The takeScreenshot API call

The TakeScreenshotCallback is implemented by the a8 class depicted below which will send the picture to the C2 on the onSuccess callback:

Besides passive observation, the malware can also take over the UI by executing a series of gestures depending on the incoming C2 command. These commands include the following:

VNCClick, VNCHold, VNCDrag, SWIPE UP, SWIPE DOWN, RECENTS, HOME, BACK, SCROLL UP, SCROLL DOWN, NOTIFICATIONS, SCREEN OFF, SCREEN ON

Each one will be interpreted by the same runnable, using a single or a set of gestures:

Getting Google Authenticator Codes

This functionality is triggered by the Get Google Authenticator Codes command which is depicted in the following figure:

This command will set the f499OooO0O0 value to true and create an intent which will target the com.google.android.apps.authenticator2 package. This intent will trigger the package execution using the startActivity function. This will trigger an accessibility event which will be handled by the corresponding onAccessibilityEvent callback of the Accessibility Service binder: