Malware Analysis Series 3 — DBS Rewards Scam Malware Analysis

8 min readFeb 1, 2024

Introduction

With the recent rise in scams leading to Singaporeans losing money due to the use of malicious android applications, our team thought it would be interesting to review some of the techniques used by the mobile malware and at the same time familiarise in ourselves in analysing android malware. The recent “Egg scam”[1], “Durian scam” [2, 3] and “Mooncake scam” [4] posted on the news are a result of victims installing a malicious APK file on their android phones. To start the analysis, we will need the malware samples which we would like to thank Jacob from Starlabs [5] who helped us to hunt for the samples related to the scams happening in Singapore. There are multiple themes from the samples collected and from the set of samples, Jacob has sorted the samples into the following themes:

Note that the table above is non-exhaustive and there are lots more samples out there.

Out of all the samples, all of the samples belonged to the SpyNote trojan family with the exception of the DBS Rewards campaign sample (967922d0239935a0fef73e615b025e38dfbefbb0209246f0652790d83366cc10). In this article, we will cover the DBS Rewards campaign sample in detail and leave the SpyNote analysis to the next article.

DBS rewards scam campaign

This campaign is not mentioned in the list of scams involving DBS [6] and without the background story, how the malware is introduced to victims remains unknown. Based on the interaction with the application, victims should be enticed to be “rewarded” with 5000 DBS Rewards after they submit their credit card information for some promotional campaign.

Scam application workflow

Upon installing the application, the application will appear with DBS logo as the icon. Executing the application will show a splash screen with DBS logo for a few seconds before launching another screen containing the form for the user to enter their credit card details.

After entering the required details, the user will be brought to another screen indicating that 5000 Rewards points will be credited to the user’s account after a period of time. After the workflow, the attacker would have successfully obtained the necessary credit card information to initiate a transaction online. To complete a transaction, an OTP would normally be required. With the application installed, the OTP sent via SMS would be available to the attacker as well because the application would have installed a SMS stealer, exfiltrating all SMSes to the attacker and thus ultimately able to create fraudulent transactions using the victim’s card.

Rewards message after submitting the form

Technical details

To reverse engineer the application, our team uses jadx [7] to decompile the APK into human readable format. Inspecting the AndroidManifest.xml reveals several things about the application:

It has permission to access SMS on the phone
It has 3 activities
- TqActivity
- MainActivity
- SplashActivity
It has 1 service declared
- ScreenOnOffBackgroundService
It has one broadcast receiver declared which can receive the following intents and it is enabled and exported
- com.example.autostart.ACTION_IMPLICIT_BROADCAST
- com.example.autostart.ACTION_EXPLICIT_BROADCAST
- android.provider.Telephony.SMS_RECEIVED

The application workflow starts with the SplashActivity which will start a service and then launch the MainActiivty which shows the form. The flow is summarised in the diagram below:

MyReceiver

This is declared in the manifest which allows the Broadcast receiver to execute the onReceive function if the intent filter conditions are met. It will exfiltrate the contents of the SMS to the C2 tagging it with the user’s email and phone number to the URL declared in SplashActivity (https://dbscardservice.com.sg/api/user/sms). Since it is declared in the manifest, it does not require the application to be running in the background to trigger the onReceive function as the enabled and exported attribute are set to true. As long as the user execute the application once, the SMS exfiltration function will still be able to execute after a reboot even if the background service is not running and as long as the user does not force stop the application [8].

Snippet of code of implemented BroadcastReceiver to exfiltrate SMS content

ScreenOnOffBackgroundService

The service is responsible for registering the MyReceiver class to listen for SMS_RECEIVE intent dynamically. This is not really necessary as the Broadcast Receiver is declared in the manifest statically as long as the application is executed once.

SplashActivity

SplashActivity is responsible for starting the background service which will register a broadcast receiver to intercept the content of SMS messages to be exfiltrated to the C2. After 3 seconds of delay, it will start the MainActivity.

MainActivity

Displays the registration form to collect the following:

Name
Mobile number
Email
Date of Birth
Card Number
Card Holder Name
Expiry Date
CVV

Form to submit user’s credit card information

Each field will have input validation function before enabling the submission button. In this case, we would like to highlight two input validation functions to submit the form successfully.

For mobile number, the function expected 10 digits with the first digit only accepting 6 to 9. This clearly does not match a Singapore phone number as Singapore number contains only 8 digits unless the country code is required to be included.

For credit card number, in order to fulfill the requirement, a 16 digit number starting 4 to 6 must be submitted.

TqActivity

Displays the “rewards” that will be credited to user after completing the registration.

Reward information after submitting credit card information

Dynamic analysis

To capture the traffic posted by the malicious application, the requirements are as such:

A wireless hotspot for the phone to connect to
DNS server to reply IP address of C2 domain
HTTPS server to listen on C2 IP

To setup the sniffing machine, we will have to setup a dummy interface with an IP that corresponds to the entry in the DNS server resolving dbscardservice.com.sg. In our analysis, we set the A record of dbscarservice.com to be 2.5.2.5 using pydns [9] listening on the wireless hotspot interface. By doing so, any network traffic to dbscardservice.com would be directed to the dummy1 interface which we can setup a HTTPS server to listen on using python. For the phone to connect to the sniffing machine, hostapd was used to setup a wireless hotspot to connect the two devices such that the sniffer machine is the network gateway.

Commands to setup a dummy interface:

ip link add dummy2 type dummy
ip addr add 2.5.2.5/32 dev dummy1
ip link set dummy2 up

The phone is connected to the wireless hotspot with the DNS server pointing the dbscardservice.com domain to the sniffing machine. When the form is submitted, an error will be displayed indicating that SSL peer verification failed due to self-signed certificate used in setting up the HTTPS server.

SSL error when connecting to our fake HTTPS server

To overcome this issue, frida is used to hook the verify method in OkHostNameVerifier to return true regardless of whether the certificate is trusted. As a result, a POST request is observed at the HTTPS server collecting all the information.

let HostnameVerifier = Java.use("com.android.okhttp.internal.tls.OkHostNameVerifier");
HostnameVerifier["verify"].implementation = function() {
    log("Verify called", "Green");
}

Captured credit card information on HTTPS server

When an SMS is received, another POST request is observed with the content of the message being exfiltrated due to the registered BroadcastReceiver. With the credit card information and SMS exfiltrated, attackers are able to perform online transactions thus successfully scamming the victim.

Recommendations

There are recommendations in advisories published by the authorities. As the attack requires user’s interaction, the ultimate success of being scammed depends on the user’s actions such that the recommendations are just mitigations and cannot prevent the malicious application from being executed.

Do not install APK outside of the play store (Based on user action)
Remove “Install from unknown sources” from all applications (Based on user action)
Do not ever allow accessibility permission for any applications (Based on user action)
Enable Play Protect which is default turned on but not fool proof as new published apps without signature would fall through the cracks. The outcome is rather similar to installing AV which is recommended by the authorities. (Based on technology but limited effectiveness)

Conclusion

Relating back to the local context where some of the victims claimed that they do not receive any SMS from the bank, it is unlikely this particular malware is able to delete SMS using this technique. In this case, the content of the SMS will still remain in the messaging application. We hope this simple malicious application demonstrates the importance of not installing any unknown applications as nowadays our mobile phones contain lots of sensitive personal information. In the next article, we will cover in detail the SpyNote trojan that is used in the other themes.