End users and their devices are right smack in the center of the battle between enterprise InfoSec teams and malicious hackers, and it’s not hard to see why.
When compromised, connected endpoints — desktops, laptops, smartphones, tablets — offer intruders major entry points into corporate networks. However, end users are also their organizations’ best threat detection tools.
The study, conducted in May and June, polled 263 IT and InfoSec pros from companies of all sizes and major industries such as finance, government, technology and education.
It found that most of the top intrusion methods reported by respondents sought to directly or indirectly compromise end users or their devices. Hackers’ preferred threat vectors included:
Email attachment or link (flagged by 74 percent of respondents)
In the last 10 years hackers have routinely taken advantage of web application vulnerabilities to successfully breach organizations. During that time there has also been an increase in the use of malware hosted on websites to infect unsuspecting users. Many times a vulnerability in a website is exploited to setup the malware that a legitimate website may then deliver. The relationship between website vulnerabilities and malware is one that is likely to continue to increase. The Verizon 2012 Data Breach Investigation Report notes: “Out of the 855 incidents this year, 81% leveraged hacking, 69% included malware, and an impressive 61% of all breaches featured a combination of hacking techniques and malware.“ The combination of threats presents organizations with a new challenge when trying to identify both web application vulnerabilities and malware that may exist on their sites.
WAS 3.0 Now Includes Malware Detection
In announcing QualysGuard WAS 3.0, organizations now have away to address the need to detect not only web application vulnerabilities, but also malware that may infect these same web properties. Qualys has offered the Malware Detection Service as both a freemium solution for individuals and as an Enterprise Edition for larger organizations that need to protect a large number of websites. With WAS 3.0, Qualys has integrated this malware detection capability into the WAS solution to make it easy for organizations to configure both types of scans from WAS. Although the services are integrated, the way the scanning is executed and the threats that are identified by vulnerability scanning and malware detection are very different. Now that we’ve outlined the integration at a high level, lets go into a little more detail about how each type of scanning is performed, and how they are integrated in WAS 3.0.
Malware Detection Dashboard
Advanced Detection Methods
QualysGuard WAS works by interacting with a web application or website just as a user would, but does so in a fully automated way. The WAS scanner will request pages, login and follow links to new pages, posting forms as it goes. While interacting with the site, WAS injects hostile payloads and then observes how the web application responds. If the web application responds in a given way, WAS can determine that the application is vulnerable to the specific attack used. This is the same type of action that a penetration tester or malicious hacker would use to discover these vulnerabilities, but it is done in an automated way that takes a fraction of the time that it does for a human. This makes the automated scanning far more cost effective.
The Malware Detection Service (MDS) takes a different approach to detection. While MDS also automatically interacts with the site as a user would, navigating and following links, it uses a much different technique to detect malware. MDS primarily uses Behavioral Analysis to identify when a website is infected with malware. MDS actually interacts with websites using an instrumented vulnerable browser hosted on a virtual machine. The virtual machine is created on the fly when the scan is requested. The service then navigates the site automatically, and by observing the behavior of the system the web browser is hosted on via the instrumentation, the service can detect when activities associated with malware take place. So instead of looking for something specific in the content itself, it is instead looking for what the browser and host do when pages are loaded. Behavioral analysis is superior in many ways to traditional malware detection methods because it can identify even zero-day malware that has not yet been analyzed to create a detection signature.
Malware Scan Report
Look for Malware Close to Home
Now that we have discussed how each service works and the differences in their detection techniques, we can discuss some other differences in web application vulnerability testing and malware detection. While web application vulnerabilities can be expected in both internal and external web applications, website malware is typically found only on Internet facing web applications. This is because malware distributors want to infect as many users as possible, so hosting malware on sites that have the most exposure is the most effective approach. Malware is also typically not likely to be distributed evenly on websites. Unlike vulnerabilities, which are usually distributed throughout a web application because they are unintentional, malware is usually found on pages that are closer to the home page for the site. This is also to take advantage of the traffic patterns of users that will typically be heavier in the pages that are the fewest clicks away from the default for the site. So while WAS will scan a large number of pages to ensure it is testing all the relevant functions thatmay be vulnerable, MDS will seek to test just the unauthenticated pages that are closest to the default page for a site, where malware is most likely to be found.
Another difference between the services that is important to note is the impact. While WAS is actively testing websites by injecting payloads and therefore usually requires advanced notice or scheduling in a maintenance window for production sites, the MDS service is purely observational and does not have any more impact on a site than a normal user would. This allows MDS to be run more often and without the notification that is typically required for running a vulnerability scan.
Malware Threat Detail
To bring these two services together, Qualys has added the ability to configure malware scanning for external web applications that are licensed in QualysGuard WAS. When an Internet accessible web application is being setup in WAS, the user will now have the option to indicate that they would like it to be scanned for malware. This will setup a daily scheduled malware scan for the site. If any malware is discovered the MDS service notifies the subscription owner with an email outlining the issue. Users can login to QualysGuard to see more details if needed. So now organizations have an easy way to combine Web ApplicationScanning and Malware Detection to ensure that their Internet facing websites are free from web application vulnerabilities and malware.
Burp Suite Professional Integration
Last but not least, QualysGuard WAS 3.0 also introduces a first in a series of integrations with attack proxy tools used primarily to conduct more advanced manual application penetration and validation testing. While WAS is designed to be fully automated and scalable and is appropriate for the security testing requirements of the majority of applications, there are some web applications that require higher levels of assurance. These applications typically require both automated scanning as well as manual penetration testing activities. In most cases, web application penetration testing is primarily conducted with the use of attack proxy tools such as Burp Suite. Attack proxies provide a high level of control that helps to facilitate the depth of testing when it is required. Recognizing that there is a place for both automated scanning and attack proxies, Qualys is moving to combine the best of both approaches by integrating attack proxy tools, enabling customers to benefit from highly automated and scalable scanning while at the same time having access to manual tools when additional exploitation or risk evaluation is required.
QualysGuard WAS 3.0 takes the first step in this evolution by integrating the scan results from Burp Suite Professional (BSP). BSP is a tool that combines many different interactive testing capabilities with scanning. Testers who use BSP can scan individual pages as they navigate a web application and discover vulnerabilities as they do so. But BSP is primarily intended for use by a single user. There is no centralized storage for results that would allow them to be shared by multiple users, or to be tracked and trended over time. Qualys seeks to overcome this limitation by providing a way to import the BSP scanner findings. This gives organizations a way to store the findings discovered in the BSP scanner with those discovered by QualysGuard WAS.
Upcoming versions of QualysGuard WAS are planned to extend the integration with BSP and other attack proxies by supporting the ability to define vulnerabilities that are discovered through manual testing with attack proxies and storing these along with the WAS automated findings. This will provide organizations a way to store and manage all the web application testing data together on one platform. Qualys will also seek to send http request information directly to the proxy that was used by WAS to identify a specific vulnerability. This will help penetration testers who use attack proxies to more fully explore the level of risk that may be associated with a specific vulnerability.
As you can tell, QualysGuard WAS 3.0 is a major release with a lot of new capabilities that will help organizations better combat the growing threats to their web applications. We’re excited by the new WAS 3.0 and we look forward to getting it into your hands.
Have you ever looked at your Android applications and wondered if they are watching you as well?
Whether it’s a bandwidth-hogging app, aggressive adware or even malware, it would be interesting to know if they are doing more than what they are supposed to and if your personal information is exposed. Is there really a way to automatically evaluate all your apps, even hundreds of them, to harvest their behavioral data, analyze their run pattern, and at the same time provide an interface to facilitate a vast majority of evolving security tests with most practical solutions?
To answer these questions, I created the Android Security Evaluation Framework (ASEF) to perform this analysis while alerting you about other possible issues. Use it to become aware of unusual activities of your apps, expose vulnerable components and help narrow down suspicious apps for further manual research.
ASEF Framework
The framework takes a set of apps, either pre-installed on a device or as individual APK files, and migrates them to the test suite which runs through test cycles on a pre-configured Android Virtual Device (AVD). The technique is to simulate the entire lifecycle of an Android app on an Android device (virtual/physical) and collect data while triggering behavioral aspects of it. In simple words, download an Android app from an internet, install it on an Android device, launch it and mess with it (e.g clicking different buttons, scrolling up/down, swipe etc..) While doing so, collect an activity log using adb (Android debug bridge utility which is available as a part of an Android SDK) and network traffic using tcpdump (a widely used packet capturing tool).
Behavioral Analysis
During such a simple yet thorough approach of performing a behavioral analysis for various apps, interesting results were found about apps leaking sensitive information like IMEI, IMSI, SIM card or a phone number of a device. Some malicious apps might just send this data in clear text over the Internet and are much easier to be caught by analyzing collected behavioral data. However some malicious apps can be sophisticated enough to detect the default settings of a virtual Android device and might behave differently in such settings. In order to overcome such limitations, a virtual device can be custom built by fine-tuning the kernel and also altering default settings to emulate a real device or it can be replaced by a physical Android device.
Open Source
ASEF is now available as open source at http://code.google.com/p/asef/. With it, users can gain access to security aspects of android apps by using this tool with its default settings. An advanced user can fine-tune this, expand upon this idea by easily integrating more test scenarios, or even find patterns out of the data it already collects. ASEF will provide automated application testing and facilitate a plug and play kind of environment to keep up with the dynamic field of Android Security.
Morto is a self-replicating malware, i.e. a worm that exploits Windows servers with weak passwords through the Remote Desktop Protocol (RDP). It was first detected in July of 2011 and was held responsible for a 200-fold increase in RDP scanning activity from approximately 500 sources to over 100,000 sources [10]. In typical malware fashion it looks for common security software and disables their function, once it has successfully infiltrated the machine. Then it connects to its command & control server to wait for instructions and receive software updates.
Even though the number of Morto infections was not considered high [3] [6] compared to other notorious malware types, Morto has interesting algorithms in its internals, and this article will focus on of them. Also, there was rumor [11] about a possible version of Morto and this will be discussed in the section titled Morto Variant.
More details about Morto’s history and its activities can be found at [1] and [2].
Architecture
Morto can be divided in three components, as shown in Figure 1.
Figure 1: Morto Architecture
The dropper is the executable file, which, in order to call the loader, drops the embedded malicious DLL into the system and calls regedit.exe, which is the application that executes the loader. Once the loader is executed, it creates a service in the system and drops another malicious DLL, which is then called by the malicious service. This second DLL is responsible to call the payload.
Most of the available public analysis, such as [1] and [2], describe Morto’s activities and its three components: dropper, loader and payload. However, little is known about how the components are interacting between them. This article will focus on how the dropper and loader work in conjunction to execute the payload.
In particular we will analyze and answer the following questions regarding Morto:
Why delete HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU registry key, which stores the list of executed programs through the run dialog?
How is regedit actually executed in order to load malicious DLLs?
How does the loader execute the payload?
What is sens32.dll?
What is HKLM\SYSTEM\WPA\sn?
Why is it called “Morto”, which means dead in Portuguese? Actually, we don’t know the answer to that one.
In the next sections, each component will be described in more details focusing on its internal algorithms.
The dropper is divided in three parts as shown in Figure 2.
Figure 2: Dropper
Part one removes obfuscation in the data section, turning it into a “plain” code which is executed later by the entire malware. Part two stores data into the registry which is used later by the malware. Finally, part three drops the loader into the system and executes “regedit.exe”. The three parts are described in more details below.
Dropper – Part one
It starts by allocating memory through ZwAllocateVirtualMemory and copying itself into this area. At this time, the code in memory is obfuscated, and being so, Morto will then de-obfuscate the code and copy the “plain” code to another memory area, allocated through VirtualAlloc. Now, the code is ready to be executed, and Morto finally calls it.
Dropper – Part two
Part two calculates a random number using function GetTickCount, srand and rand, which is then stored in HKLM\SYSTEM\WPA\id. It then attempts to read HKLM\SYSTEM\WPA\md which does not exist yet, on a non-infected machine. It continues its execution by allocating memory and copying obfuscated data into it, which is later stored in HKLM\SYSTEM\WPA\md. Also, another block of memory is allocated and a DLL is copied into it. Then, it executes GetSystemTime and stores its results in HKLM\SYSTEM\WPA\it as well as creates a file under c:\windows\offline web pages\ with its name based on GetSytemTime. Once the plain code execution finishes, a call is made to a function which receives “Drop” as its parameter. This function returns an address which is the third part of the dropper, that will be discussed in the next section. It is interesting here that the malware itself confirms that it will “drop” something onto the system calling that function. Figure 3 shows the call to the function which received “Drop” as a parameter.
Figure 3: Call to drop loader
Dropper – Part three
Part three of the dropper starts by attempting to create a file in \\tsclient\a\ whose name is constructed by a fixed prefix ID plus the random value obtained in part two, which was saved in registry key HKLM\SYSTEM\WPA\id. The malware does not even check if a RDP session is opened or if the drive is already mapped: an attempt to create this file could be a way to check if the system is already infected, but since the ID is random this might not be the case. It then deletes the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU, but the reason for that is still unclear. Next, it creates the registry key HKLM\SYSTEM\WPA\md and adds to it the data that was allocated in part two: this seems to be the payload. Then the DLL c:\windows\clb.dll is created, using the data copied by part one, and its MAC times (modification time, access time and creation time) are changed based on the valid DLL c:\windows\wmi.dll. This is used to fool an analyst who would look for last changed files on the system. Figure 4 shows malicious DLL c:\windows\clb.dll after the MAC times change.
Figure 4: clb.dll after change its MAC times
Finally, regedit is executed to load the malicious DLL c:\windows\clb.dll. This is when things gets really interesting. Instead of just calling regedit.exe through common functions such as System, the dropper enumerates windows until finds a run dialog window, then changes its text to regedit.exe and clicks on button “OK”. The user does not see any window opening; however, if we open run dialog ourselves, regedit.exe is clearly visible. Figure 5 shows run dialog window before button “OK” is executed.
Figure 5: regedit.exe being executed
The use of the run dialog window explains why it previously deleted registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU which lists the commands executed through the run dialog.
Before we continue with the loader analysis, it is important to understand how the malicious DLL clb.dll, which is placed under c:\windows, is executed by regedit. This is done by the search order which Windows looks for DLL as described at [4] and explained from a malware standpoint at [5]. But basically, once an application loads a DLL, if its name is not listed under HKLM\System\CurrentControlSet\Control\Session Manager\KnownDLLs, Windows operating system will check on the application’s path. Since clb.dll is not listed under the KnownDLLs registry key and regedit.exe is placed under c:\windows, it will look for clb.dll under c:\windows directory and execute its version of the clb.dll, that is the malicious one, instead of the original c:\windows\system32\clb.dll. Using the sysinternals tool [7] procmon we can clearly see the malicious DLL clb.dll getting executed by regedit.exe, as depicted by Figure 6.
Figure 6: Malicious clb.dll being executed by regedit.exe
Loader
The loader is also divided in three parts, as shown in Figure 7.
Figure 7: Loader
Part one checks if the calling process is rundll32.exe, which is responsible for load DLLs into the system, and tries to open an existing file probably for Morto to check if the system has been already infected. Part two has the same function as dropper’s part two; however in this case, it reads the registry key HKLM\SYSTEM\WPA\md. Part three simply calls the payload. The next sections will describe the three loader parts.
Loader – Part one
First, the loader checks if the calling process is rundll32.exe. Since I executed the loader through OllyDBG debugger [8], loaddll.exe was used instead of rundll32.exe because loaddll.exe lets us debug a DLL instead of just execute it such as rundll32.exe. But on the payload, Morto executes rundll32.exe in order to execute malicious DLL on an infected system. If this part was called by rundll32.exe, the malware would try to open the existing file \\tsclient\a\moto, which where the name Morto came from and that is most likely to be used to check if system has been already infected. It also reads the first 4 bytes of c:\windows\winhlp32.exe, but if it does not exist, it tries to read the first 4 bytes of c:\windows\system32\write.exe. The first 4 bytes are 0x4D, 0x5A, 0x90, 0x00, which are common for every PE file. One may initially thought that such bytes would be inserted at beginning of HKLM\SYSTEM\WPA\md to and make it an executable. However, that was not the case, and so those 4 bytes might be used by the payload itself for another reason that is still unclear or they are were just another trick used by the author to fool the analyst.
Loader – Part two
The part two has almost the same function as the dropper’s part two: the only difference is that here the HKLM\SYSTEM\WPA\md already exists and its contents are read and placed into a buffer. Again, a call is made to a function which returns the address for where the execution will be jumped to and represents the part three. Regarding the parameter, at this time the string “Load” is used as parameter instead of “Drop”: this parameters shows that the malware is attempting to execute the loader.
Loader – Part three
Part Three deletes again the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU and then copies the valid file c:\windows\system32\wmi.dll to c:\windows\temp\ntshrui.dll. Then, a service named “6to4” is created which is the first string returned by a query on HKLM\Software\Microsoft\Windows NT\CurrentVersion\Svchost\netsvcs. The binary path of service is set to C:\WINDOWS\system32\svchost.exe –k netsvcs, and then the service parameter is changed to c:\windows\temp\ntshrui.dll. After that, the real malicious c:\windows\temp\ntshrui.dll is created. At this time, we have a service created that, when executed, loads another malicious DLL that seems to be the payload. Figure 8 shows the malicious service created while on stopped state.
Figure 8: Malicious service 6to4
Before the potential payload (DLL c:\windows\temp\ntshrui.dll) gets executed, the loader still changes some configuration on the service Sens, which is responsible for monitor system events [9], loader will first copy the valid file c:\windows\system32\sens.dll to c:\windows\system32\Sens32.dll, change HKLM\SYSTEM\CurrentControlSet\Services\Sens\DependOnService to NULL and HKLM\SYSTEM\CurrentControlSet\Services\Sens\Group to SchedulerGroup, and finally lastly modify the parameter stored at HKLM\SYSTEM\CurrentControlSet\Services\Sens\Parameters\ServiceDll to c:\windows\system32\sens32.dll. This service might be used later by the payload.
Looking at ntshrui.dll, it is clear how the payload is executed: Morto checks if the calling process is svchost.exe and, if so, another part of the plain code is called and a thread is created pointing to the real payload.
There was a rumor about a new Morto variant [11], we executed and analyzed it but concluded it is innocuous since it does not perform any change on the system, nor any network activity. Also, the malware does not check if it is running on a virtual environment or any other thing that would make it not execute. Probably, it was considered a possible Morto variant for two reasons:
It creates a Mutex object [12], which is commonly used by malware to check if a machine has been already infected, with the name “_MOTOCCATK_”. Figure 9 shows assembly code responsible to create Mutex.
Figure 9: Mutex
It reads contents from the HKLM\SYSTEM\WPA registry key which is used by Morto. Figure 10 shows Morto variant reading the registry key HKLM\SYSTEM\WPA.
Figure 10: Morto variant reading registry key
Then, we developed a little tool named check_mutex.exe which helps detect malware that uses mutex. Basically, once a malicious mutex is known, just run check_mutex.exe passing the malicious mutex name as a parameter, and it will check if a process is running with the given mutex name, and if so, it will display its process ID. Then, even though Morto variant does not attempt to harm the system, we put a breakpoint after a call is made to CreateMutexA function and executed check_mutex on the system to make sure it is working properly. Figure 11 shows check_mutex in execution.
Figure 11: check_mutex
Thanks to ISC Handlers who provided us sample for analysis. Thanks to @Ivanlef0u who developed code to list handles, and made it public, which helped a lot on check_mutex development.
Conclusion
Despite its interesting payload, the way Morto is executed is also very interesting. First, placing a malicious DLL into %SystemRoot% directory and calling the valid executable regedit.exe instead of a malicious executable is an interesting choice of execution, probably designed to bypass malware detection algorithms. Second, the way that it executes regedit.exe is uncommon, most likely used to avoid detection as well. Third, it uses another malicious DLL as a service to get it executed. In conclusion, as malware evolves we need to make sure protection mechanisms are in place to detect such behaviors, not only analyzing its payload but also how it gets executed. This will allow us to develop mechanisms to defend against these threats independently of its activities.
Good Software Hygiene mandates fast patching, but most organizations prioritize the roll-out of patches and take into account severity and applicability.
To help organizations tune their prioritization process we added last week a knowledgebase enhancement that extends our severity rating with an “ExploitKit” mapping. The new mapping groups all QIDs that are used in the so called ExploitKits that are available for purchase on the black markets. ExploitKits, such as Crimepack, IcePack and Phoenix offer the attacker a suite of exploits that can be used to attack common OS, browser and application vulnerabilities and automate the setup of malicious webservers necessary in the malware infection cycle and focus (for the moment) on the Windows OS.
ExploitKits are behind many of the mass malware infections (Zeus, SpyEye, etc) that group the affected machines into botnets that are remotely controlled to send SPAM, participate in DDoS attacks and intercept banking credentials by monitoring browser usage. Affected machines can also be used as beachheads for further incursions into the enterprise networks they participate in, which are widely spread. Gartner estimates that between 4-8% of all workstations in enterprise environments are infected.
Organizations can protect themselves from infection by hardening their installation and patching all of their workstations against the vulnerabilities abused by the ExploitKits. The “ExploitKit” mapping can be used in targeted scans or in reporting to aid in the hardening process.
Infections of Win32/Rimecud.B were first spotted in the wild in the second half of 2010, but customers are still calling us due to difficulties in removing it even in the presence of anti-virus software. So we decided to analyze it and on the way also describe some interesting anti-debugging techniques that are used by it. We also analyze the malware’s behavior once a system is infected.
Sample
File: ctfmon.exe MD5: f5f4ec6d780715d713b7e085fd24447c SHA1: f4507f91806aef7bdbbab1047b5ce4d5d6033e6c File Type: MS Windows Portable Executable file
Malware Analysis
Before starting the analysis, open the malware in PEiD to see if the malware was packed using any known available packers. PEid indicates that the malware is packed using UPX packer (fig.1). For further analysis the malware is unpacked using the Ultimate Packer for executable. Figure 1: PEid output for malware sample.
Once the unpacked malware executable is opened in a debugger, we will see that the malware does a lot of calls to Windows API “CopyFileA”, trying to copy some random files to random location and this is done multiple times in a very big loop. This is junk code used to probably frustrate the reverse engineer (Fig.2). Figure 2: Random Calls to “CopyFileA” API.
Inside this junk code, the malware implements a very powerful anti-debugging technique. The malware calls the “kerne32.CloseHandle” API with random values of “hObject” (Fig 3.). If a process being debugged tries to close an invalid handle, it generates a STATUS_INVALID_HANDLE (0xC0000008) exception. The only proper way of bypassing this anti-debugging technique is to modify the syscall data from ring3, before it is called or setup a kernel hook. To bypass this anti-debugging technique we will replace all such random values by NULL and this will allow us to debug our malware smoothly. Figure 3: CloseHandle Anti-debugging technique.
However, even after bypassing this anti-debugging technique, if you allow the malware to run, it will get executed and terminate with exit code 0 without doing anything or will stop with “Access Violation” exception, depending upon the time elapsed since the program is executed. This is because of the anti-debugging technique implemented by malware using the ‘kernel32.GetTickCount’API (Fig.4). Figure 4: kernel32.GetTickCount Anti-debugging technique.
The instruction at 0x00330126 will call kernel32.GetTickCount and PUSH that value on stack. It again makes the same call, subtracts that value from the one obtained previously and tests if it is zero. It continues this in loop until it gets the subtraction of these two values as zero. On every time this loop is executed, the value of kernel32.GetTickCount is pushed on the stack. After coming out of this loop, CALL 00330151 is made. This function make CALL DWORD PTR SS:[ESP+C], which should ideally be kernel32.GetProcAdddress. However if you are debugging the malware, the stack might have values that were pushed on stack because of the previous ‘GetTickCount’ loop and hence trigger an Access Violation. To bypass this debugging technique you need to adjust the ESP value so that [ESP+C] points to kernel32.GetProcAddress.
The malware under analysis is created using a CrimeWare Kit that is available in the underground market called CRUM Cryptor Polymorphic by Sunzer Flint (Fig 5). This is a program that is used by malware authors to encrypt malware through a random key of 256 bytes and also subject it to polymorphism. Figure 5: CRUM Cryptor Polymorphic.
The last two anti-debugging techniques that are implemented by malware before it decrypts itself, is done by accessing the Process Environment Block (PEB) of the current process. The first technique is checking if the byte at offset 0x02(IsDebugged) in the PEB is set or not. If a program is being debugged, this byte is set to 1 else it is 0. The other anti-debugging technique is to check for the NtGlobalFlags at offset 0x68 in the PEB. If the process is debugged, some flags controlling the heap manipulation routines in ntdll will be set. This anti-debug can be bypassed by resetting the NtGlobalFlags field (Fig. 6). Figure 6: PEB Anti-debugging Technique.
Once we have bypassed all these anti-debugging technique, the malware will start importing the different library it requires using the kernel32.LoadLibraryA API.
The malware then tries to find if the process “explorer.exe” is running on the system and gets handle to this process via the kernel32.OpenProcess API(Fig. 7). Figure 7: Malware trying to find the “explorer.exe” process.
The malware then reserves a region of memory within the virtual address space of the “explorer.exe” process using kernel32.VirutalAllocEx API and creates a thread in the explorer.exe process via the kernel32.CreateRemoteThread API (Fig. 8). Once the remote thread is created in the “explorer.exe” process, the malware terminates itself with exit code 0. Figure 8: Malware Creates a Remote Thread in explorer.exe.
Once this new thread is created in the explorer process, the original malware file is copied to “%USERPROFILE%\\ctfmon.exe” location (Fig. 9) and sets file attributes to system, read-only and hidden. Figure 9: Explorer Thread making a copy of itself as “ctfmon.exe”.
After creating the executable, the malware creates the key “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Taskman”: “%USERPROFILE%\ctfmon.exe” (Fig. 10). This key ensures that every time explorer.exe process is created, the malware gets executed. Figure 10: Explorer Thread creating the “TaskMan” registry.
The malware creates a NamedPipe which can be later used for inter-process communication (Fig. 11). Figure 11: Explorer Thread creating a NamedPipe.
The malware then tries to communicate to its masters at “tinaivanovic.sexy-serbain-girls.info” (Fig. 12). Figure 12: Malware trying to communicate on Internet.
The malware is known to spread via USB drives. On connecting a USB stick to an infected host, the malware drops a copy of itself in the “[RemovableDrive]\\nemoj\\meni.exe” and creates an autorun.inf file (Fig. 13). Figure 13: Malware trying to spread via removable drive.
Removal Instructions
Open “Regedit” and locate the above mentioned registry key. Delete this registry key.
Open “Task Manager” and find explorer.exe in the “Processes” tab. Right click on explorer.exe and select “Kill Process”. If you are comfortable using command line, use the following steps to kill explorer.exe:
tasklist | find /i "explorer" This command will give you the process id of explorer.exe process.
taskkill /PID 12345 /f (12345 to be substituted with the process id of explorer.exe obtained from the above step)
Upon doing this you will notice that another process named “ctfmon.exe” appears in the process list. Kill “ctfmon.exe” as well, same way as we killed explorer.exe.
Browse to the %UserProfile% directory using a command line. Use “dir /ah” command to list all the files in that directory. You should be able to see “ctfmon.exe” file in that directory. This file has “SHR” attribute. Remove these attributes of the file so that you can delete this file. Use the following commands to do this:
On Friday April 15th, The Oak Ridge National Laboratory (ORNL) disconnected its Internet access to contain an intrusion and interrupt the theft of data. Attackers had gained access to the ORNL network on April 7 through a phishing e-mail attack carrying malware with an exploit for a 0-day vulnerability in Microsoft Windows Internet Explorer.
Previously, we had seen a similar attack on the security company RSA, where data related to SecurID, RSA’s two-factor token authentication product was extracted. In RSA’s case, the phishing e-mail involved an Excel spreadsheet purporting to be about the hiring budget for 2011. The spreadsheet contained an exploit for a 0-day vulnerability in Adobe Flash.
At the same time Verizon’s 2011 Data Breach Investigations Report (DBIR) affirms for the 3rd year in a row that the majority of data breaches (96 %) could have been avoided with the implementation of simple countermeasures.
Organizations can effectively protect themselves by implementing good software hygiene, which starts by introducing a structured patching process aimed at installing critical updates for all software within a short timeframe, we recommend within 10 days. Organizations that have implemented such fast patching have seen a significant improvement in the robustness of their infrastructures and have been documenting their progress publicly (see reference section on processes in use at Goldman Sachs and US State Dept).
Fig 1: Motivation for Patch Speed at Goldman Sachs (From SPO-208 RSA US 2009)
Fast patching will prevent infection from all of the common malware exploit kits that are available for purchase. The toolkit “Phoenix 2.5” for example offers 5 exploits based on the PDF file format, 3 on Java and 1 each for Quicktime and Adobe Flash, all of them abusing vulnerabilities that are already patched.
Further resilience can be gained by controlling installed software and its configuration. The ORNL case would have been countered by the consistent use of an alternative browser. The Excel attack could have been prevented by prohibiting active content in Microsoft Office Trust Center or uninstalling Adobe Flash, preferably both. Switching to a more modern version of the base OS or even an alternative OS will also help to add resilience against malware (i.e. Windows7 64bit, Mac OS X or Linux).
This level of tightening of IT configurations raises the bar significantly and will keep most classes of attackers out of enterprises networks. Talk to your industry peers to see what they are doing; a number of organizations are already operating their networks in this way and can attest to the effectiveness of these measures.
Adobe recently released an advisory warning about a zero day vulnerability affecting Adobe Flash Player 10.2.153.1 being exploited in the wild. The attack uses a flash .swf file embedded inside a seemingly innocuous .doc file. The embedded .swf file uses ActionScript to perform a heap spray and then loads another malicious swf files created via the loadBytes() function.
(Click figure below for full resolution image).
Sample
File: Disentangling Industrial Policy and Competition Policy.doc
MD5: 96cf54e6d7e228a2c6418aba93d6bd49
SHA1: 820699d9999ea3ba07e7f0d0c7f08fe10eae1d2d
CVE: CVE-2011-0611
File Type: MS Word.doc file with embedded flash .swf file
Analysis of the Malware:
On opening the .doc file, the vulnerability in flash player is exploited and it creates “scvhost.exe” and “AAAA” files in the %temp% directory. The “scvhost.exe” is the malware dropper and file “AAAA” is a dummy word file that will be shown to the user after the exploited is completed.
Once scvhost.exe is created, this file is then executed using the command “cmd /c “%temp%\\scvhost.exe””.
The malware then replaces the original .doc malicious file with the innocuous “AAAA” file it created and then opens it. It also kills “hwp.exe” process. It does this by executing the following command:
cmd.exe /c "dir /s %windir%\system32\*.sys&&taskkill /im hwp.exe /f &
dir /a /s %windir%\system32\*.msc && copy %temp%\\AAAA "C:\Documents
and Settings\Rodrigo\Desktop\Disentangling Industrial Policy and Competition
Policy.doc " /y && "C:\Documents and Settings\Rodrigo\Desktop\Disentangling
Industrial Policy and Competition Policy.doc"
The scvhost.exe process on startup stops the “WmdmPmSN” service. The scvhost.exe process now copies the “SFC_OS.dll” to a temp file.
Copies the windows %system32%\\mspmsnsv.dll to %programfiles%\\commonfiles\\bak.dll. The system32%\\mspmsnsv.dll file is then moved to %temp% dir and set to delete on restart.
Svchost.exe then creates the malicious %system32%\\mspmsnsv.dll and msimage.dat.
Svchost.exe then copies this %system32%\\mspmsnsv.dll to %system32%\\dllchace\\mspmsnsv.dll
Svchost.exe is then moved to a %temp%\\[tempfilename] and is then set to delete on reboot and starts the “WmdmPmSN” service. Thus leaving no trace of any malicious executable on system.
Once the service restarts it tries to connect to its masters at liciayee.dyndns-free.com.
Files Created and MD5:
Conclusion
As a best practice, avoid opening unexpected e-mails or attachments and do no click on links from un-trusted sources. Adobe has released a critical security advisory APSA11-02 and is in the process of finalizing a fix for Adobe Flash Player 10.2.x, Adobe Acrobat X (10.0.2) and earlier 10.x and 9.x versions for Windows and Macintosh, Adobe Reader X (10.0.1) for Macintosh, and Adobe Reader 9.4.3 and earlier 9.x versions for Windows and Macintosh.Google Chrome users can update to Chrome version 10.0.648.205. Verify the version of Google Chrome installed on your system. QualysGuard customers can scan for QID: 119144 for Adobe Flash and QID: 119145 for Adobe Reader/Acrobat for detecting this vulnerability in their network.
