LocalizeApp banking trojan: yet again abusing Accessibility Services
Around April 1st 2021 (no joke), a new malware surfaced posing as “Localize Já!” [ref]. Its SHA256:
Banbra, BasBanke, or BrazKing?
As usual, it is difficult to classify this sample in a given malware family. Some tell you this is Banbra [ref], others that this is BasBanke ([ref1], [ref2] and [ref3]), and yet others naming it BrazKing [ref]. In each case, there are similarities, but enough differences to leave doubts (different organization of code, different communication with CnC etc).
Communication with CnC
The remote CnC,
atualservicenovo.hopto.org on port 5000, is no longer responding, but the malware used to communicate with that host using Socket.IO, an event-driven socket communication SDK.
The malware manages several other events such as “seta_tela_cef” (looks like this sets the URL to retrieve a fake image for Caixa Economica Federal), “get_tamanho_tela” (retrieve smartphone’s screen size) etc.
Connecting to Accessibility Services
I haven’t done any statistics to be honest, but abusing Android Accessibility Services feels like the new (or not so new) trend: all samples I have analyzed last month were abusing AAS, one way or another!
That being said, understanding code that deals with AAS isn’t very easy. It is worth a few explanations.
The malware declares an Accessibility Service in the Android manifest. The service is named
com.gservice.autobot.Acessibilidade and it requests the
<service android:description="@string/TESTE" android:enabled="true" android:exported="true" android:label=": Localize Já! Rastreio Online para android" android:name="com.gservice.autobot.Acessibilidade" android:permission="android.permission.BIND_ACCESSIBILITY_SERVICE">
<meta-data android:name="android.accessibilityservice" android:resource="@xml/accessibilityservice"/>
The precise accessibility capabilities are listed in an XML resource (
@xml/accessibilityservice). For example, it asks to perform gestures and retrieve window content. It gets notified for any feedback or events.
<accessibility-service android:accessibilityEventTypes="0xffffffff" android:accessibilityFeedbackType="0xffffffff" android:accessibilityFlags="0x53" android:canPerformGestures="true" android:canRequestFilterKeyEvents="true" android:canRetrieveWindowContent="true" android:description="@string/TESTE" android:notificationTimeout="100" xmlns:android="http://schemas.android.com/apk/res/android"/>
Clicking at given coordinates
Once accessibility rights are granted, the malware can basically pilot the smartphone and click wherever it wants. The CnC can for instance send an list of operations to perform, such as click at given (x,y) coordinates on the screen.
The click is performed by a method named
Clicar_Pos. On Android, all nodes (see that as each component of screens: button, labels etc) are organized in hierarchy. The malware begins in the root window, checks if the given coordinates are within that node (if so, it clicks and it is the end). If not, the method searches recursively through children nodes until it finds the right one.
Writing text at given coordinates
Similarly, the malware is able to automatically insert input text. With accessibility services power, this is automatic, the end-user does not interact.
The method is the same as for clicking: from the root node, search recursively down all nodes to insert text in the appropriate node.
Entering input text occurs when CnC’s operations contain keyword
ND_TEXTO. Similarly, the malware implements automatic insertion of gestures (
ND_CLICK_G), or even drawing (
ND_CLICK_DRAW) on the screen. The list of points of the drawing are provided by the CnC.
Navigating through windows
The malware can use the HOME, POWER, BACK (etc) buttons very simply through
It seems harmless at first sight, but dumping all node information to the CnC actually leaks any kind of data: username, email, phone number, credit card number, password… Have a look at figures in this article, where a malware named Defensor ID, uses the same technique. The same occurs with our sample, data organization and labels are just different.
For each node, the following information is dumped: coordinates, text (this will contains passwords for example), if the node is clickable, visible, its resource identifier, description, classname, package name.
infos = nodeinfo_x + ":" + nodeinfo_y + ";!!;" + nodeinfo_text + ";!!;0xxx;!!;" + isclickable + ";!!;" + isvisible + ";!!;" + viewidres + ";!!;" + contentdesc + ";!!;" + packagename + ";!!;" + node_classname + ";!!;" + rect_info + "@";
IMHO, Accessibility Services on Android are too powerful — and thus too interesting to abuse by malware. Probably Android designers need to contact developers writing legitimate apps for people with disabilities to check out what they really need. I understand text to speech, or zooming, or contrast. I am not so sure about allowing an app to “click through”. But people with the relevant disabilities should speak for themselves.