Operation Mangal - Win32 / Syndicasec Used In Targeted Attacks Against Indian Government Organizations - Part-2 : Demystifying The Malware And Its Network Communications

In the previous blog on this campaign , I walked through the exploit , the timeline and the possible attack targets . Out here , I'll take a more deeper look into the malware family dropped and its communication to the command and control servers.

Dropped Malware family : Win32 / Syndicasec :

dw20.exe, 1st stage dropper executable dropped by all  the RTF exploits involved in this a attack, is a malware family dubbed as Win32/Syndicasec by ESET. This malware was identified back in March 2013 during which it was used in the cyber espionage attempt against the Tibetian activist and was also used in multiple other targeted campaigns. Previous versions of this threat was also discovered way back in July 2010 during which it was active in Nepal and China, as I indicated earlier.However, the payload and the mechanism of this malware has evolved since then.

I have uncovered that this threat is now also being currently used in the espionage attempt against the Indian government organizations. We can very well confirm the threat similarity based on the behavioural pattern on the system during the execution. 

It tries to determine the presence of sysprep.exe in the system32 and sysnative directory and then it goes to extract the embedded executable from the resource section , drops it in the %Temp% directory with the name gupdate.exe

Subsequently , it reads the Cabinet file embedded in the resource section , into the memory , extracts it into the /sysprep directory with the name cryptbase.dll , using the Windows Update Standalone Agent ( wusa.exe ).The technique used here to load the custom cryptbase.dll is what we call as DLL Load Order Hijacking . Sysprep.exe usually loads the cryptbase.dll, which is directly under the system32 and is not in the OS’s  Known_DLLs list . If the malware drops the DLL with the same name in the system32/sysprep/ directory , then the dropped dll would be loaded instead of the one directly under the system32 , because of the DLL search order. Further, it exploits the vulnerability in the Microsoft UAC whitelist process allowing it to run the arbitrary command with the elevated privileges.

Below are all the hashes of the 1st stage dropper along with the compile time which would give the fair enough idea of the timeline of the attack.

MD5s Compile time 1B83B315B7A729CB685270496AE68802 August 12, 2014 68BFA1B82DC0E2DE10D0CF8551938DEA August 12, 2014 C249CB532699E15B3CB6E9DEB6264240 August 12, 2014 5A80F6F6D75FD8D95D7EC830DC669129 August 12, 2014 2881F3EA27802FD9C1ED08C767083D12 Feb 27, 2014 391552FB8DE3F45FB7DD9EF7B9CAA4BB Septr 5, 2014 13C4D1CA7256B1FBEEEE9DE532097A94 August 12, 2014 7F5F57DE1734CC20D915AF68CC2821F2 Feb 27, 2014 0E7DB6B6A6E4993A01A01DF578D65BF0 Sept 5, 2014

The second-stage dropped file, gupdate.exe, connects to the command and control server. This communication is done in stages as well and uses the uncommon Windows Management Instrumentation system to register the JavaScript that connects to the first-stage URLs. The XOR routine for JavaScript follows:

Looking at the previous versions of this threat, JavaScript versions have changed every time this malware was used.

Command and Control communications :

The JavaScript is primarily responsible for connecting to the first- and second-stage URLs, which leads to the control server. Examining the multiple variants of the RTF exploits and the dropped binaries, we’ve found the following fake blogs with which variants of gupdate.exe communicate. All of the URLs point to the blogs’ RSS feeds, from which the encoded Stage 2 (control server) URL is fetched.

Stage 1 URL pointing to the RSS feeds of the fake blogs:

hxxp://kumar807.blogspot.com/feeds/posts/default

hxxp://kumar807.wordpress.com/feed/

hxxp://kumar807.livejournal.com/data/rss

hxxp://blogs.rediff.com/kumar807/feed/

hxxp://kumar807.thoughts.com/feed

hxxp://kumar807.tumblr.com/rss

hxxp://www.blogster.com/kapoorsunil09/profile/rss

hxxp://kumarsingh1976.wordpress.com/feed/

hxxp://musictelevision.blogspot.com/feeds/posts/default

Next we see the format of the encoded Stage 2 URL found on the fake blog. Note that the URL is within the the "title" tag with the “@” delimiter:

 

Encoded stage 2 URLs ( Command and Control servers ) found on the fake blog sites.

Once the response is received, the "title" tag is parsed out of the response and the decoding function in the JavaScript is applied to expose the control servers. Decoding algorithm has remained same in the previous versions of the javascript as well.

Below are the stage 2 URLs found to be connected by the variants of the gupdate.exe

www.asiasky.tk
kumarsingh.tk
zz13572.0023.jxwb2.com
hidimovie.tk
www.pattanasettyraju.org

The parameters sent in the POST request are formed by executing the WMI queries from the JavaScript. This image shows the functions of this operation:

While the malware executes, all of the control servers are live but with an empty command array. Examining the JavaScript, we see the command decoding is done with the eval() function, which leads us to believe there could be another JavaScript embedded:

Hashes for the RTF exploits involved in this attack:

598d9b335cec4e3ae6bd87d2c9734a1a
82440b92ddfccbd9645227c71df04db6
6b3700048ef7224f1d0efe1b33bab957
84cef2b4e9cc92533717919aefb55e3e
57679deaf8b39bbee00ac001c7eede81
cc3d7699838bcd434a2c3a804c4a196c
0a81badaf590ad6a9c6bd2f6edbb5f37
bd95cd9a058a267486ee8dbf44c3a757
6122d3fb69e9d3d7f93116eb8fbbf1ef
7772021f3883fd9f0b470387d46ae775
719db97a61e24b2619759ed054c06308
b908156a3fed1db5593c2ea730158f91
c10ffafcc7f44265c7f40d00bdbf5f73
2ed5a096825b7f7a147441d35ec28f10
e73ea3c88a89ef3ed2f4f8acacd048eb
077eaae040cbe7b35e4d2064cb75efe1
b2dfb6007c385414b6dcbb7a69c1ca2c
43c872c4b31c9e6de976e198639a390f
d8ef8fbb9689127b30229659fc091738

I've been tracking this threat since quite some time now . I'll keep posting any interesting updates and details on this campaign as and when I discover ..stay tuned !!..

Operation Mangal - Win32 / Syndicasec Used In Targeted Attacks Against Indian Government Organizations - Part-1 : Exploits, Attack Timeline And Targets

During the period of last couple of months, we’ve observerd several RTF exploits floating around in the wild, targeting multiple Indian government organizations. Series of RTF exploits , first of which was found to be around by on 21st August 2014 , subsequently, multiple variants of the same exploit has been seen until end of September and through October . Contents of the documents are politically themed , targetting multiple local and overseas Indian government establishments.

Recent political reforms undertaken by the new Indian government, Prime Minister’s visit to Japan and United States as well as meeting with the Chinese president, recent UNSC reforms and series of the other similar political events has generated quite a movement within the APT actors. I believe this could be a part of a possible campaign, involving a group of APT actors, targeting positive political movements and disrupting the intent of developing and strengthening the bilateral ties with the neighbouring countries and United States.

I've decided to dub this wave of attack as "Operation Mangal" based on the original name of the APT and ISRO's recent MangalYaan's success that has distinguished India as a whole from the rest of the world.

Vulnerability :

All the RTF exploits has been found to be exploiting the old and already patched Microsoft Word ActiveX control vulnerability CVE-2012-0158. It has already been used in several targeted campaigns in the past and continues to be popular in ongoing targeted attack campaigns. Exploit laden doc files has been found in the wild with the following filenames:

• Modi’s foreign policy agenda.rtf

• ASEAN-India Agreemnet On Investment.doc

• Planning Commission Reform Note FINAL.doc

• High Speed Railways.doc

• ASEAN-India Comprehensive Brief 2014.doc

• Bilateral.doc

Attack vector :

Attack is believed to be carried out via the RTF exploit ( CVE-2012-0158) as an attachment to the possible spear phishing emails targeting Indian organizations. On launching the exploit , it drops the executable with the filename dw20.exe in the %temp% directory following the drop of gupdate.exe at the same location which connects to the multiple C&C in the staged fashion. Following is the high level picture of how the attack works :

Overall working of the attack

Below is the visualization of the timeline of this attack over the period of last 3 months :

Exploit Analysis :

All the RTF exploits used in this campaign uses the staged shellcode . However , noticing the shellcode in the exploit is fairly straightforward and uses the known technique of resolving the API names from its hashes.

Once the APIs are resolved , it tries to locate itself in the memory by enumerating the file handles and then reads the 1st stage shellcode in the allocated virtual memory which is then used to decrypt the 2nd stage shellcode.

Below is the routine from the 1st stage shellcode that decrypts to the 2nd stage and then jumps to it.

"Datastore" of the RTF exploit contains the embedded XORed executable which is accessed by 2nd stage shellcode .

2nd stage shellcode then decrypts the embedded binary and the embedded decoy document using the same decryption algorithm , eventually droping them in the %Temp% directory with the name dw20.exe , executing it.

Here is how the complete shellcode looks like :

Some of the other decoy documents that has been found in the ongoing campaign : 

Based on the further research on the origin of this targeted attacks against India , I believe , this campaign had been going on since 2010 during which this threat was active in the limited geographical location in Nepal and China. Subsequently,during this span of 4 years, several different families of malware could have been used to exfilterate the information from multiple compromised machines within targeted Indian organizations . 

Based on the nature and theme of the exploits used in the attack, it leads me to believe that this could be a continued attempt of cyber espionage against India with the intent to steal the confidential data and documents that could be of the national interest.

In this wave , I believe the following organization were targeted using multiple variants of RTF exploits taking advantage of the same vulnerability.

• Indian embassies in United States and China
• Military / Defence educational institutions in India
• Institute of Defence Analysis and Studies , India
• Defence Intelligence Agency under Ministry of Defence in India

A while back when taking a closer look at this attack, I came across a very interesting paper that was published way back in 2010 , elucidating similar espionage attempt against India and very closely relating to this ongoing attack with the similar targets . It perhaps clears out the way to perceive that this is a closely knit group of APT authors focusing on this locality . 

Report can be read here -- SHADOWS IN THE CLOUD:Investigating Cyber Espionage 2.0

In the next part , I would take a deep dive into the family of malware dropped by these exploits and its network communications to get the better visualization of the techniques used and how this threat works as a whole.

Evading Sandboxes : Into The Loopholes Of Sandboxing Technology - Part 1

As I demonstrated in my last blog , malwares have now started to submerge much deeper into the system to detect the sandbox environment. Besides the file system , process and known registry artifacts which can be very easily spotted by the researchers , there are several other methods researched to evade the automated analysis systems and needless to say , actively being used today. This two part blog series is primarily intented to provide a complete walkthrough of the most common sandbox evasion techniques prevalent today.

Latent execution:

Automated malware analysis systems are designed to process several thousand samples within a short period of time . Because of that fact, the proportion of time allocated for its execution is usually very limited , ranging from somewhere between 3 to 5 mins for one sample. Malware authors tend to take the advantage of this configuration aspect by introducing the Sleep ( ) calls in the middle of the code to pause the execution for several minutes before the execution of actual malicious payload. Under the Sandbox configured to execute the malware for shorter period , none of the malwares' actual behaviour would be captured. This is very common technique used today to bypass sandboxes . One such family of malwares using this was Win32/Kuluoz . 

One of the disadvantage of using Sleep / SleepEx calls is that they are easily noticeable and Sandboxes are now protected against this trick. Since they use the API Hooking to trace the calls , the moment it notices the Sleep ( ) calls , it will patch the argument to the API, effectively resulting into the faster sample execution.

Malwares as always , continues to look out for more elegant methods. One of the way to evade this protection mechanism is to use the alternate APIs some of them which are undocumented . For Instance below APIs can still be used to achieve the same functionality:

NtDelayExecution ( ) [ Undocumented ]

WaitForSingleObject ()
WaitForMultipleObject ( )
CreateWaitableTimer ( )
SetWaitableTimer ( )

More polished method to introduce latency was observed in the Win32/Cutwail ( MD5 : b4f310f5cc7b9cd68d919d50a8415974 ). It loaded the ECX register with the huge value and kept calling the API in the loop resulting into single API call > 78 Lac times. Below is the snippet of the code:

This can still be noticed by some of the intelligent sandbox systems out there . Way to go one step beyond this is not to call the API , instead place the junk instuctions in the loop . This can virtually defeat every sandbox technology. We could do something like this : 

Self Name Checks

One of the other common and observed way of sensing the sandbox environment is to perform the self check. Sandboxes, while executing the malwares are inclined to rename the file either to sample.exe / malware.exe / virus.exe etc. Malwares have found to be taking advantage of this naming convention. Similar technique was found in one recent malware (MD5:9404955681a5828b5ab9ab2a5c5547ce) named Win32/Comrerop.

And don't be surprised to see that Comodo sandbox helps this malware. Look at the analysis report here . Prevalent sandboxes like ThreatExpert can also  be traced using this simple mechanism. 

Loaded modules and monitoring tools

Sandboxes have their own monitoring DLLs that are used and loaded while processing the samples. Several malwares have been observed to check for these loaded DLLs specifc to respective sandboxes. It can also check for the installed monitoring tools used to capture the end to end behaviour of the malwares. Here is the code snippet from Win32/Comrerop performing similar checks:

More checks from the same malware searching for open windows of sysinternal tools / debugger :

Checking Hard Disk size

This technique is very well documented and has been observed in several recent malwares. The idea behind this logic is to obtain the handle to the physical drive using CreateFileA ( ) API and then use this handle to pass it to the device driver using DeviceIoControl ( ) API to perform the operation specified by IoControlCode. Malware using this mechanism with IoControlCode of 0x7045c is most likely performing the HD size check . If the Hard Disk size is < 10 GB , malware presumes that it is running under the sandbox.

IoControlCode 0x7045c stands for IOCTL_DISK_GET_LENGTH_INFO , which retrieves the length of the specified disk, volume or partition. Below is the HD size check in the malware code:

This actually makes sense because it is rare to have the sandbox machines with the larger HD size . 

Tracing mouse movements

Tracing the mouse movements is one of most effective way of differentiating the sandbox and easier to implement as well. Mouse movement check basically involves checking for the cursor position and then substracting the coordinates to check if the mouse has moved. GetCursorPos ( ) API is called twice to check for the cursor movement . Since there is no input device connected to the sandbox machines, it can trace almost all the sandboxes. 

Sandboxes can be protected against this technique by intercepting the call and randomizing the coordinate values. 

Ring 3 hook detection

Sandboxes significantly rely on the API hooks to be able to trace the activity of the malware. Ring 3 hooks are the user space hooks that can be easily implemented via modifying the initial instructions of the API code within the mapped DLL and pointing it to the hooked code. Several available sandboxing technology including Cuckoo , employs the similar techniques to log the APIs called by malware . Malware authors are very well aware of this and take the advantage of this implementation by detecting them. One of the simplest detection method is to get the virtual address of the API and check if that does not start with the standard prologue. If code starts with Jump/Call instruction , then it indicates that API has been hooked which leads to the conclusion that code is being executed in the sandbox . Here is the example code that attempts to detect the user mode inline hooks.

One of the way malwares tend subvert the user space hooks is to implement the custom loader and map the desired DLL in the process address space perhaps using a different name, and then get API address using the standard GetprocAddress mechanism . More sophisticated approach for the malwares could be to drop the kernel drivers which implements the required code using the lower level APIs and then user space components calling them , which will essentially bypass the sandbox hooking framework .

Sandbox detection using known product IDs

This is the another popular and easy to implement sandbox detection technique used by several recent malwares including Win32/Gamarue,Win32/Comrerop etc . Every commercial sandbox has its own associated Windows product ID that can be fetched from the registry key and matched against the blacklisted product IDs. Calliing the API RegQueryValueEx ( ) on the following registry keys will extract the respective product IDs :

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\\ProductID
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\\ProductID

API trace for one of the sample trying to access the product ID:

Following is the list of some of the known product IDs and associated with their respective sandboxes:

Anubis :
product ID :76487-337-8429955-22614

CWsandbox :
Product ID :76487-644-3177037-23510

JoeBox :
Product ID :55274-640-2673064-23950

However, more focused commercial sandboxes are now well conscious about the product IDs being used against them and either deny the access to the registry key or respond with the randomized value.

I'll keep rest of the techniques of evading sandboxes to my next blog.We'll walk though few of them used in the recent targeted attacks. Stay tuned !!..

Trojan.FakeAV Uses Unprecedented APIs To Detect Virtualized Environment ..Pretty cool stuff ..!

With the ever changing facets and trends of the Cyber attacks , Sandboxing technology using virtual machines has become the inevitable tool for researchers to analyze the behaviour of the malwares in abbreviated period of time. With the huge inflow of the samples , sandboxes based on virtualized environment is another premier tool in the armoury. Sandboxing provides the isolated setup which can execute the malware binaries within , without effecting the underneath host resources . This can help researchers quickly analyze and locate the malicious behaviour of the sample and produce the heuristic / behavioural signatures .

But there are two sides of the every coin . Sandboxes usually leaves too many traces and evidences into the system to make itself a completely imperceptible environment. Malware authors tend to come out with the innovative methods to detect the virtualized / sandboxing territory and cease to execute the moment they discover it. Subsequently, obscuring the setup has become very significant when they are builded to execute tons of malwares.

There have been several researched and documented methods of distinguishing the sandbox area . For instance , traditionally , malwares use to search for the known artifacts like running process , registry keys , file systems for noticing the sandbox . These methods are easily noticeable by the researchers. Today , Advance persistent threats and targeted attacks tend to wait for the human interaction with the system to activate the malicious code . Since automated malware analysis frameworks process millions of samples per day , human interaction is bare minimal and malwares does not replicate as a result. One of the very interesting papers that has been published and presented by FireEye researchers here , documents bunch of interesting techniques to perceive the sandbox.

Few days back , I was researching a malware that showed a lot of behaviour on the physical system and other sandboxes but refused to execute on the vmware . I was pretty keen to figure out what exactly it did . Eventually , after a session of debugging , I was able to determine that it accessed the registry key to detect if it was running under VMware , Vbox and Qemu but the interesting aspect was it never used the known registry APIs . If we look at the imports of the binary :

Malware importing device APIs

If we look at the nature of the APIs that is imported by the malware , experienced eyes can make an educated guess. These are the device APIs , though very seldomly used , but can fetch you the properties of the underlying device / hardware .  Malware trying to extract the device properties is most likely performing environment checks.

After all the deobfuscation , it calls  SETUPAPI.SetupDiGetClassDevsA( ) API to get the handle to the device information set that contains device information elements for a local computer

At this point , if we check the memory of the process , the strings to match has already been decrypted:

Next , it passes the returned handle to the SetupDiEnumDeviceInfo ( ) that returns the structure relating to the device information set . More information about the API and structure is available on MSDN.

Then eventually calls SETUPAPI.SetupDiGetDeviceRegistryPropertyA ( ) to access the registry key:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\SCSI\Disk&Ven_VMware_&Prod_VMware_Virtual_S&Rev_1.0\4&5fcaafc&0&000

They key that it accesses is the "FriendlyName" of the above registry key:

And then finally calls the functions to match the value against the Vbox , Virtual HD , Vmware and Qemu .

Below is the top level view of the rest of the code checking for variety of virtual environments :

Interesting ingredient of this malware was all the checks that it performed does not seem to be obviously visible to the reverser. Above that , all of these validation code was concealed below few layers of obfuscation which kind of makes it harder to expose.

As malware authors get smarter , I am pretty certain that level of discretion in detecting the virtualized / sandbox environment is going to grow.

Multiple Microsoft Word Vulnerabilities Used In Targeted Attacks Against European Aviation Company

Exploits targeting zero day vulnerabilities delivered via spear phishing emails is one of the most successful attack combinations used by threat actors. It has been proven method of infiltrating the target organization in an attempt to gain access to the confidential information.
Recently, over the period of last month, We have uncovered another targeted attacks being carried out via spear phishing emails against the European Aviation company. We have observed the emails being sent to the larger group of individuals in the target organization with the attachments exploiting recently patched RTF vulnerability CVE-2014-1761 and previously patched CVE-2012-0158 ActiveX control vulnerability. Both of these vulnerabilities has been predominantly used in several ongoing targeted attacks.

Both of these spear phishing emails are observed to be coming from French actors using the French Yahoo and Laposte email services and possibly impersonating the employee of the target organization.

RTF Vulnerability : CVE-2014-1761

As indicated above, both these exploits targets recently patched RTF vulnerability CVE-2014-1761. Precise reason for triggering this vulnerability is the value of the “ListOverrideCount” which is set to 25.

Which according to MS RTF specifications should be either 1 or 9 . This eventually causes the out of bounds array overwrite subsequently resulting into incorrect handling of the structure by Microsoft word leading to control of the EIP.

Shellcode:

Interesting aspect of this vulnerability is that all the byte of the shellcode ( ROP chain ) are directly controlled by the attacker and comes straight from the RTF structure. Here is the high level view of how the ROP chain is formed directly out of the structure.



Below is the memory snapshot of the parsed RTF structure in the memory leading to the control of the EIP:

Successful execution of the shellcode opens the decoy document and drops the malware svohost.exe in %TEMP% which then connects back to the C&C server ( C&C details provided later )

Compelete Technical details of the vulnerability and the shellcode has been blogged here

In the same cycle of spear phishing attacks we’ve also got the hold of the mails targeting the same organization with the attachments exploiting old CVE -2012-0158 vulnerability. Exploit laden doc files are found to be with the file name: article.doc

Following API trace shows gives the fair enough idea of the sequence of activities once the exploit is launched on the system :

Payload Analysis:

Analysis of the dropped binary reveals that it is specifically written to gather information about the network of the target organization as well as the configuration of the endpoint leading us to believe that this could be spear phishing reconnaissance attack.Payload seems to have been compiled on 9th April, 2014 :

Malware initially starts with retrieving the %Temp% path and prepares to log the communication with the C&C server in the file %Temp%explorer.exe

Subsequently , it starts collecting following information about the system configuration,registered organization and network:
- Hostname
- Username
- System type by resolving IsWOW64Process API
- Existing TCP and UDP connections and open ports on the System
- Organization information from the Registry key :
--- HKLM/Software/Microsoft/WindowsNT/CurrentVersion
Productname
CSDVersion
CurrentVersion
CurrentBuildNumber
RegisteredOrganization
RegisteredOwner

- Current running system services
- Installed softwares from the registry key:
--- HKLM/Software/Microsoft/Windows/CurrentVersion/Uninstall
- Information about Network Adapters , IP Configuration , Netcard Numbers , IP Mask,Gateway , DHCP Server , DHCP Host , WINS server ,WINS host.

Here is the high level snapshot of the malware’s information gathering code:

Encryption at the high level is primarily done using the SYSTEMTIME structure. It forms the repetitive 256 byte key using the SYSTEMTIME information as shown below:

And then further converts the key into 16 byte to finally start encrypting the information.

Once the buffer has been encrypted , it connects to the C&C sophos.skypetm.com.tw posting all the collected  information in an encrypted format.

Command and Control Research:

During the time of analysis of this exploit, sophos.skypetm.com.tw was found to be resolving to the IP 66.220.4.100 located in the Fremont City, USA. First instance of outbound traffic to this domain was seen on 27th January 2014 during which it resolved to the IP 198.100.113.27 located in Los Angeles City, USA.

From our passive DNS data , we’ve found following MD5s connecting to the same domain :

Whois record reveals that the TLD (skypetm.com.tw) domain has been registered under the email ID:  longsa33@yahoo.com Which is also found to have registered another domain “avstore.com.tw” used actively as the C&C server.

While several other malware binaries has been observed to be communicating to the various subdomains of skypetm.com.tw and avstore.com.tw , all of them are identified as “PittyTiger” malware that has been implanted in numerous CVE- 2012-0158 exploits used in recent targeted attacks . Same payload was also used in the “Tomato Garden” APT Campaign targeting Tibetian and Chinese democracy activist uncovered in June 2013.

Additional Domains related to this attack :

·        63.251.83.36

·        64.74.96.242

·        69.251.142.1

·        218.16.121.32

·        61.145.112.78

·        star.yamn.net

·        216.52.184.230

·        212.118.243.118

·        bz.kimoo.com.tw

·        mca.avstore.com.tw