{"id":15137,"date":"2019-04-19T11:10:03","date_gmt":"2019-04-19T19:10:03","guid":{"rendered":"https:\/\/www.palada.net\/index.php\/2019\/04\/19\/news-8886\/"},"modified":"2019-04-19T11:10:03","modified_gmt":"2019-04-19T19:10:03","slug":"news-8886","status":"publish","type":"post","link":"https:\/\/www.palada.net\/index.php\/2019\/04\/19\/news-8886\/","title":{"rendered":"Funky malware format found in Ocean Lotus sample"},"content":{"rendered":"

Credit to Author: hasherezade| Date: Fri, 19 Apr 2019 18:37:54 +0000<\/strong><\/p>\n

Recently, at the SAS conference I talked about “Funky malware formats”<\/a>\u2014atypical executable formats used by malware that are only loaded by proprietary loaders. Malware authors use these formats, such as a custom format that is not recognized as an executable by AV scanners, in order to make static detection more difficult. <\/p>\n

Using atypical formats may also slow down the analysis process because the file can’t be parsed out of the box by typical tools. Instead, we need to write custom loaders<\/a> in order to analyze them freely.<\/p>\n

Last year, we described one such format in a post about Hidden Bee<\/a>. This time, we want to introduce you to a malware we discussed at the SANS Conference: Ocean Lotus, also known as APT 32, a threat group associated with Vietnam.<\/p>\n

Sample<\/h3>\n

49a2505d54c83a65bb4d716a27438ed8f065c709<\/a> – the main executable<\/p>\n

Special thanks to <\/em>Minh-Triet Pham Tran<\/em><\/a> for providing the material.<\/em><\/p>\n

Overview<\/h3>\n

The sample comes with two elements\u2014BLOB and CAB\u2014that are both executables in the same unknown format. The custom format is achieved by conversion from PE format. (There are some artifacts that indicate it manifests in a way typical for PE files.) However, the header is fully custom, and the way of loading it has no resemblance with PE. Some of the information from the typical PE (for example, layout sections) is not preserved: sections are shuffled.<\/p>\n

Origin<\/h3>\n

This sample is from June 10, 2017, from the following email:<\/p>\n

\"\"
Content of the phishing email, along with its attachment<\/figcaption><\/figure>\n

The title “S\u1ed5 tay v\u1ea5n \u0111\u1ec1 ph\u00e1p l\u00fd cho c\u00e1c nh\u00e0 ho\u1ea1t \u0111\u1ed9ng nh\u00e2n quy\u1ec1n” translates to: “Handbook of legal issues for human rights activists.” It’s a subject line for a spear phishing campaign targeting Vietnamese activists.<\/p>\n

The malicious sample was delivered as an attachment to the email: a zipped executable. The icon tried to imitate a PDF (FoxitPDF reader).<\/p>\n

\"\"
An executable with FoxitFDF icon<\/figcaption><\/figure>\n

Behavioral analysis<\/h3>\n

After being run, the sample copies itself into %TEMP%, unpacks, and launches the decoy PDF.<\/p>\n

\"\"
The main executable and the decoy copied to the Temp folder<\/figcaption><\/figure>\n

While the user is busy reading the launched document, the dropper unpacks the real payload. It is dropped into C:ProgramDataMicrosoft Help<\/em>:<\/p>\n

\"\"
All the elements of the malware unpacked<\/figcaption><\/figure>\n

The dropper executable is deleted afterwards.<\/p>\n

The malware manages to bypass UAC at default level. We can see the application sporder.exe<\/em> running with elevated privileges.
Persistence is provided by a simple Run key, leading to the dropped script:<\/p>\n

\"\"
Added run key (view from Sysinternals Autoruns)<\/figcaption><\/figure>\n

The interesting factor is that the sample has an “expiry date” after which the installer no longer runs.<\/p>\n

Internals<\/h3>\n

The main executable sporder.exe is packed with UPX. It imports the DLL SPORDER.dll:<\/p>\n

\"\"
Import table of SPORDER.exe (view from PE-bear)<\/figcaption><\/figure>\n

SPORDER.dll imports another of the dropped DLLs, hp6000.dll<\/em>:<\/p>\n

\"\"
Import table of SPORDER.exe (view from PE-bear)<\/figcaption><\/figure>\n

The key malware functionality is, however, not provided by any of the dropped PE files. They are just used as loaders.<\/p>\n

As it turns out, the core is hidden in two unknown files: BLOB and CAB.<\/p>\n

Custom formats<\/h3>\n

The files with extensions BLOB and CAB are obfuscated with XOR. After decoding them, we notice some readable strings of code. However, none of them are valid PE files, and we cannot find any of the typical headers.<\/p>\n

BLOB<\/h4>\n

The BLOB file is obfuscated by XOR. We can see the repeating pattern and use it as an XOR key:<\/p>\n

\"\"
SPORDER.blob (original version), the repeating pattern is selected<\/figcaption><\/figure>\n

As a result, we get the following clear version: 2e68afae82c1c299e886ab0b6b185658<\/a><\/p>\n

BLOB’s header:<\/p>\n

\"\"<\/figure>\n

The BLOB file looks like a processed PE file, however, its sections appear to be in swapped order. The first section seems to be .data, instead of .text.<\/p>\n

We can see visible artifacts from the BZIP library<\/a> and C++ standard library.<\/p>\n

CAB<\/h4>\n

The CAB file is obfuscated with XOR in a similar way, but with a different key:<\/p>\n

\"\"<\/figure>\n

When we apply the key, we get an analogical clear version: b3f9a8adf0929b2a37db7b396d231110<\/a><\/p>\n

\"\"<\/figure>\n

This sample also has a custom header, which does not resemble the PE header. However, we found sections inside that are typical for PE files, for example, a manifest.<\/p>\n

"VMNet3<\/figure>\n

Loader<\/h4>\n

As it turned out, both files are loaded by hp6000.dll: 67b8d21e79018f1ab1b31e1aba16d201<\/a><\/p>\n

The loading function is executed in an obfuscated way: when the DllMain is executed, it patches the  main executable that loaded the DLL. <\/p>\n

First, the file name of the current module is retrieved. Then, the file is read and the address of the entry point is fetched. Then, the copy of the module that is loaded in the memory is set as an executable:<\/p>\n

\"\"
Using VirtualProtect to make the main module writable<\/figcaption><\/figure>\n

Finally, the bytes are patched so that the entry point will redirect back to the appropriate function in the loading DLL:<\/p>\n

\"\"
Patching the entry point of the main module, byte by byte<\/figcaption><\/figure>\n

This is how the entry point of the main module looks after the patch is applied:<\/p>\n

\"\"
The Entry Point of the main module (sporder.exe) after patching<\/figcaption><\/figure>\n

We see that the Virtual Address (RVA 0x1210 + DLL loading base) of the function within the DLL is moved to EAX, and then the EAX is used as a jump target.<\/p>\n

The function that starts at RVA 0x1210 is a loader for BLOB and CAB:<\/p>\n

\"\"
Beginning of the loading function<\/figcaption><\/figure>\n

This redirection works, thanks to the fact that when the executable is loaded into the memory, before the Entry Point of the main module is hit, all the DLLs that are in its Import Table are loaded, and the DllMain of each is called. Just after the DLLs are loaded, the execution of the main executable starts. And in our case, the patched entry point redirects back to the DLL.<\/p>\n

Inside the function loading BLOB and CAB:<\/p>\n

\"\"
The function loading BLOB and CAB<\/figcaption><\/figure>\n

As you can see, the CAB file is loaded first:<\/p>\n

\"\"
Executing the function loading CAB file (unconditional)<\/figcaption><\/figure>\n

Further, we see this function retrieving some environmental variable. This variable is used to store the state of the application, and is shared between consecutive executions. Depending on this state, one of multiple execution paths can be taken.<\/p>\n

The name of the variable is created by concatenating:<\/p>\n

    \n
  1. hardcoded string: L”Local\\{076B1DB0-2C01-45A5-BD0A-0CF5D6410DCB}”<\/li>\n
  2. the name of the executable<\/li>\n
  3. a local username<\/li>\n<\/ol>\n
    \"\"<\/a>
    Setting the variable name<\/figcaption><\/figure>\n

    The content variable may be one of the following: ‘@’, ‘*’,’:’. If it is empty, the first value ‘@’ is set. Those variables are translated to particular states that control the flow.<\/p>\n