A good way to find out malware is to look through the ads, normally there are youtube ads with gambling applications but this time I found a backdoor. This is the first time I actually got a TP backdoor in ads.

The usual signal of this application was that it was a PDF reader and had 1K installations.

AndroidManifest had the permission REQUEST_INSTALL_PACKAGES, which is a signal that the application can install other applications. Used commonly by droppers. The next step was to find where the application was using this permission, so I used jadx-gui to decompile the application and search for the permission. I searched for package/vnd.android.package-archive but I couldn’t find anything, so I searched for “https://” and found the following code:

Two C2’s were hardcoded in the application in plain text with the same domain, they contained binaries that were downloaded and executed in the device. I won’t go into detail how the payload was downloaded and executed, I found this while I was reversing another application and I wanted to provide a quick write-up about it. All C2’s were saved in wayback machine.

• https://dulinare[.]com/pdffile
• https://dulinare[.]com/hanihani (malicious dex file)

Loading the dex file there were only 4 classes, I searched around them and could see an anti-emulator check and geo-location check. Seems to be targeting the following ISO’s:

• es, sk, si, sl, bg, gb, cn, fi, hu, ie, pt

Another C2 was found, this one had the actual backdoor:

• https://sefuban[.]com/1.apk

Installing this last APK, quickly asked for accessibility permissions and started to send the following information to the C2:

• http://185.215.113[.]31:85/api/getkeyloggers
• http://185.215.113[.]31:85/api/botupdate
• http://91.215.85[.]55:85/api

I haven’t looked much into what the backdoor actually did, but the url /api/getkeyloggers is a good signal that it was a keylogger. Inside the C2, there were multiple banks and applications, so it was probably a banking trojan targeting also Portuguese people.

For example, the following banks were targeted and much more:

• com.binance.dev
• pt.santander.oneappparticulares
• com.revolut.business
• com.santandermovelempresarial.app
• de.traderepublic.app
• ie.avantmoney.mobileapp
• com.comtrade.simba.gbkr
• dbs.mobileBankingProd
• com.hrc.eb.mobile.android.hibismobilelon
• com.hrc.eb.mobile.android.hibismobilevipava
• bg.ccbmobile.app
• bg.allianz.banking
• com.openintegra.dsk_smart_business
• sk.vub.banking
• cgd.pt.caixadirectaparticulares
• wit.android.bcpBankingApp.millennium
• pt.novobanco.nbsmarter
• wit.android.bcpBankingApp.activoBank
• pt.bctt.appbctt
• pt.cetelem.homebanking
• pt.oney.oneyapp
• com.bankinter.portugal.bmb
• pt.sonaefs.Universo
• app.wizink.pt

Encryption/decryption algorithm of the requests is XOR with the key 66 decimal.

SHA256 DIGESTS of the samples:

• 95765ba9ade111c579d53d10585f594af6241f32599d084b4646316facc491aa
• 6b49ff162980515a62a716c76b0c170f80dd01e5b533c2a458ddf88bc74eb49d

1. Bypass the anti-debugging validation
2. Verify what arguments were needed

We received one EXE file with the hash (8d665653f572b550400313feb208b277604805803182b15868daeafc80eb40ae).

When executing it the first time, it pop’s up a Message Box with the Title “Locked”. So now, we have a starting point during our analysis.

If we load our program with IDA, we will see that we don’t see any of these strings. During execution, we can see that it will perform XOR operations that will lead us to those strings.

So now we know that any XOR operation on this EXE could lead us to the flag.

We have one interesting IF statement, before anything is XORified.

According to microsoft, https://learn.microsoft.com/en-us/cpp/c-runtime-library/argc-argv-wargv?view=msvc-170, we know that “___argc” is our arguments counter. We also know that always the first argument holds the program name and the second points to the first actual argument. We know now, we will have to send at least one argument to the execution.

The next bytes shown after the argument counter, are related to the TLS callback. According to the IDA documentation, if you press CONTROL+E you can choose the application entry points. We can see that our application has two TLS callbacks.

I won’t go into the details about TLS(Thread-Local-Storage), however all we need to know is that they are executed before our program entry point. And if we take a look at both TLS callbacks, we can see that they are being used to verify if the application is being debugged.

So now, I thought of three options.

Use x32dbg to patch these flows then use IDA. (didn’t test) Manually modify the registers using IDA Use x32dbg with ScyllaHide since it is able to bypass Process Environment Block

After updating the registers manually we see that we get a string. We can try to send this as a parameter. We have to update the anti-debug stuff, again.

During the execution

“p4s5ing_th3_g4te” has the 16 chars that we want. If we pass this as our argument, it finally enters the while loop and proceeds to the if statement.

And we have our flag.

Reminder:

When using x32dbg, you have to be careful since with the default settings it breaks on TLSCallbacks. And due to this, the bytes of the function are going to be different due to int3 interruption. As shown here:

As you can see, the dl is going to be “CC”. Why? Because the setting “Break on: TLS Callbacks*” in the Preferences on x32dbg is on. Then the debugger does the following:

The debugger is basically replacing the first byte with an int3 instruction. That’s the reason why it ends up with “CC”.

You can replicate the same behavior if you place a breakpoint on the first byte “F8”. So you have to be careful with this.