Dissecting Android KorBanker
FireEye recently
identified a malicious mobile application that installs a fake banking
application capable of stealing user credentials. The top-level app
acts as a bogus Google Play application, falsely assuring the user
that it is benign.
FireEye Mobile Threat Prevention platform detects this application
as Android.KorBanker. This blog post details both the top-level
installer as well as the fake banking application embedded inside the
top-level app.
The app targets the following banks, all of which are based in Korea.
- Hana Bank
- IBK One
- KB Kookmin Bank
- NH Bank
- Woori Bank
- Shinhan Bank
Once installed, the top-level application presents itself as a
Google Play application. It also asks the user for permission to
activate itself as a device administrator, which gives KorBanker
ultimate control over the device and helps the app stay hidden from
the app menu.
The user sees the messages in Figure 1 and Figure 2.
class="alignnone size-full wp-image-3983 landscape-med"
alt="korbanker_1"
src="https://www.fireeye.com/content/dam/legacy/blog/2013/11/korbanker_1.png"
width="671" height="356" />
The message in
Figure 2 translates to:
style="font-family: Arial;font-size: small;">“Notification
installation file is corrupt error has occurred. Sure you
want to delete the corrupted files?”
When the
user clicks taps the “Yes’ button, KorBanker hides itself
from the user by calling the following Android API:
getPackageManager().setComponentEnabledSetting(new
ComponentName("com.pro.www",
"com.pro.www.MainActivity"), 2, 1)
The
arguments “2” and “1” which are being passed to the above
function are explained below.
The 2
argument represents is the value for the
COMPONENT_ENABLED_STATE_DISABLED flag, which causes
the component to be disabled from the menu of apps.
The 1
argument is the value for the DONT_KILL_APP flag,
which indicates that the app should not be killed and
continue running in the background.
After
installation, the app checks whether any of the six targeted
banking applications have been installed. If it finds any,
it deletes the legitimate banking application and silently
replaces it with a fake version. The fake versions of the
banking applications are embedded in the “assets” directory
of the top-level APK.
style="color: rgb(102,102,102);font-family: Arial;font-size: medium;">Initial
registration protocol
The
top-level APK and the embedded fake banking app register
themselves with their respective command-and-control (CnC)
servers. The following section explains the registration
process.
Top-level app
The
top-level app registers itself by sending the device
ID of the phone to the remote CnC server packed in a
JavaScript Object Notation (JSON) object. The data
packet excerpt is shown in Figure 3. This is the first
packet that is sent out once the app is installed on
the device.
class="alignnone size-full wp-image-3975 landscape-med"
alt="korbanker3"
src="https://www.fireeye.com/content/dam/legacy/blog/2013/11/korbanker3.png"
width="616" height="157" />
Figure 3: KorBanker data packet during registration
The
packet capture shown in Figure 3 shows the structure
of the registration message. The bytes highlighted in
red indicate the CnC message code of 0x07(decimal 7)
which translates to the string addUserReq.
Outlined
in yellow is length indicator —
style="font-family: Arial;font-size: small;">0x71(113
bytes)— followed by the JSON object
containing the Device ID and the phone number of the
device. The values for callSt and smsSt are
statically set to 21 and 11, respectively.
The response bytes shown in
black containing 0x04 and 0x01 map to the command
addUserAck. They are sent by the server to
acknowledge the receipt of the previously sent
addUserReq. Code inside the application invokes
various functions as it receives commands. These functions
may exist for future updates of the application.
href="/content/dam/legacy/blog/2013/11/korbanker4.png"> class="alignnone size-full wp-image-3976 landscape-med"
alt="korbanker4"
src="https://www.fireeye.com/content/dam/legacy/blog/2013/11/korbanker4.png"
width="613" height="172" />
Figure 4: KorBanker code for
sending incoming messages to CnC server
Once the installation of
the app has been registered, the app waits for incoming
messages on the phone, possibly looking for access codes
that arrive as a part of two factor authentication
methods for one of the six targeted banks. All incoming
messages to the phone are intercepted and sent to the
CnC server 180.214.160.70 on port 8888 as shown in
Figure 4.
The bytes highlighted in
red after the response show the message code of
0x08 (Decimal 8), which translates to the
command addSmsReq. This is followed by the size of
the message. The Device ID is sent at the end of the data
packet to identify the device from which this message was
seen with the timestamp. It also suppresses the SMS
notifications from the user and deletes the message from the
device.
The remote CnC
infrastructure is based on numeric codes. These codes
are stored in a data structure in the app. All incoming
messages and responses from the CnC server arrive in
numeric codes and get translated into corresponding
strings, which in turn drive the app to perform
different tasks.
Table 1 shows the CnC
commands supported by the top-level app. All the
commands ending with “Req” correspond to the
infected client requests made to the CnC server. All
the commands ending with “Ack”
indicate acknowledgements of the received commands.
href="/content/dam/legacy/blog/2013/11/korbankertable.jpg"> class="alignnone size-full wp-image-3981 landscape-lg"
alt="korbankertable"
src="https://www.fireeye.com/content/dam/legacy/blog/2013/11/korbankertable.jpg"
width="860" height="543" />
Fake banking app
style="font-family: Arial;font-size: small;">The
fake banking app once installed registers with a
CnC server on a different IP address by sending
the HTTP request shown below.
href="/content/dam/legacy/blog/2013/11/korbanker5.png"> class="alignnone size-full wp-image-3977 landscape-med"
alt="korbanker5"
src="https://www.fireeye.com/content/dam/legacy/blog/2013/11/korbanker5.png"
width="750" height="550" />
Figure 5: Data capture showing
the installation of the fake banking app
Once the phone
is registered, the user is presented with
the following fake login page of the banking
app, which prompts the user for banking
account credentials. All these credentials
are stored internally in a JSON object.
href="/content/dam/legacy/blog/2013/11/korbanker_6.png"> class="alignnone size-full wp-image-3984 landscape-med"
alt="korbanker_6"
src="https://www.fireeye.com/content/dam/legacy/blog/2013/11/korbanker_6.png"
width="639" height="363" />
The user
is then prompted for a SCARD code and
35-digit combination, which is recorded
into the JSON and sent out to ‘http://180.214.160.70/send_bank.php
’ style="font-size: small;"> as follows:
{ "renzheng" : "1234",
"fenli" : "1234",
"datetime" : "2013-08-12 12:32:32",
"phone":'8889991111',
"bankinid": '1234',
"jumin": '1234',
"banknum" : '1234',
"banknumpw" : '1234',
"paypw" : 'test',
"scard" : "1234567890",
"sn1" : "1234",
"sn2" : "1234",
"sn3" : "1234",
....
....
"sn34" : "1234",
"sn35" : "1234"
}
style="font-family: Arial;font-size: small;">The
response received is as follows:
Cache-Control: no-store, no-cache,
must-revalidate, post-check=0,
pre-check=0
Connection: close
Content-Type: text/html
Date: Fri, 22 Nov 2013 02:05:00 GMT
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Conclusion
This malware sample takes extra
measures to obtain banking credentials. With the increased
usage of mobile devices and with the liberal permission
allotment to apps that appear benign we are now at an
increased risk of monetary losses on the mobile front. Mobile
banking is not completely void of its adversaries. KorBanker
is a vivid reminder of just how dangerous apps from untrusted
sources can be.
Source:
Dissecting Android KorBanker
