Combining Static and Behavourial Analysis
Static and behavioural analysis have there place in automated analysis particularly when considering sandboxes. These sandboxes often combine static file analysis with monitoring what the sample does when executed.
The static approach could be to look for unusual imports or API calls or sections with high levels of entropy indicating obfuscated contents. The behavioural approach would then look at what the sample did when executed and ask the question is it normal for this to occur. This could be Winword searching for the kernel32.dll as an example.
Utilising both of these areas of analysis to try and understand a sample and its activities can be easily achieved and may not require a high level of assembly knowledge. In my experience I have noted that assembly is one of those areas that was never really covered during my academic life and many practitioners are self taught but still remains quite a niche area.
Although this has its advantages from a reverse engineering perspective I have also noted in my experience that organisations do not always allocate time for studying of samples in that detail. When responding or conducting intelligence based operations it brings in the principle of diminishing returns in that an analyst can spend 2 hours to understand 80% of a sample and a significant amount more to understand the remaining 20% or how something specific was implemented.
Granted some organisations business is also understanding that 20% and may operate differently however the vast majority of companies need answers to a problem as soon as possible.
I will begin to go through the steps when analysing a malware sample combining static and behavioural analysis techniques.
Lets take the sample:
File name Pay&34.exe File size 2690560 Hash MD5 881779e0688edfedcace8736f960dfce
MD5 Hash match: https://www.hybrid-analysis.com/sample/0aaa2389f7e9202e1428f984302e50e32012e79bc081d342a67f22bc0494a897?environmentId=100
Firstly we can use a tool called 'ent' this checks the entropy of a given file which for this file was Entropy = 6.127619 bits per byte indicated there were some pretty unstructured sections suggesting an obfuscation technique is in use.
We can than analyse the PE header details by looking at the executable using a tool called peframe (https://github.com/guelfoweb/peframe).
The output of the tool yields the following information of note:
File name Pay&34.exe
File size 2690560
Hash MD5 881779e0688edfedcace8736f960dfce
Compile time 2016-08-03 13:20:52
Sections 3 (1 suspicious)
Directories import, resource, relocation
Detected packer
Import Hash f34d5f2d4577ed6d9ceec516c1f5a744
Packer:
Microsoft Visual C# / Basic .NET
Microsoft Visual Studio .NET
.NET executable
Microsoft Visual C# v7.0 / Basic .NET
Import function
------------------------------------------------------------
mscoree.dll 1
The tool identifies that the packer was .NET The import function of mscore.dll also reinforces that this is a .NET executable.
A simple strings review of the executable identifies that the executable is packed in some way as the majority of the ASCII based strings are similar to the below:
]iB|
I:Zdg
K@wW
po7fP
Or
bNbIlVK8WCq11E8cF9.resources
Kv13KZ3RQTu.resources
RCsf3KSOKm.resources
Also note the version information as this could reveal additional intelligence via online data mining.
LegalCopyright ZTtXC
Assembly Version 66.66.69.93
InternalName bbbb.exe
FileVersion 88.93.19.92
CompanyName 0ZhM9
Comments xIoCM
ProductName jHQTn
ProductVersion 88.93.19.92
FileDescription BqKU8
Translation 0x0000 0x04b0
OriginalFilename bbbb.exe
As the file is packed static analysis would be hindered unless unpacked. There are various un-packers available depending on the packer that was used. In this case .NET which are also available but are mainly commercial.
At this point you can take the obfuscated executable and place this into a debugger and begin looking into how the obfuscation routine works and step through the program execution. This is assuming the sample does not contain defences against reverse engineering.
The quicker option would be to execute the sample and monitor what it does based on the environment it is executed in. The environment would need to be configured in a way to capture system changes as well as network activity. This could be monitoring using the host itself to capture or via an agent on the host. An external method of traffic capture should also be utilised as a rule of thumb you never trust what a compromised host tells you.
Executing the sample will cause it to unpack into memory like any other application in a de-obfuscated format to allow it to run. While running monitoring software such as Procmon, Process Hacker, WireShark allows data to be gathered on the system activity. This will capture all activity that the selected tools allow to be capture but also only the information the malware allows the system to report back depending on the sample of course.
This information can be combined into a quick reference image of the sample activity via a tool called Procdot (www.procdot.com/) I have found this to be useful as a quick reference however it may not be an exhaustive list of sample activity. Below is a behavioural image of the sample.
This allows quick identification of created files and modified registry items. The image identified that the sample created two additional executable files. One named chrome.exe and one called AudioDriver.exe. This indicated that there are additional executable files to be extracted from the host and then to be analysed. I will not go into the digital forensics element of this at this time but this can also be a useful source of information and evidence when factored into the sample analysis.
Further to the the monitoring tool I also executed a script to capture system state as well as dump memory for analysis. There are two reasons for this. One that the running of sysinternal tools to enumerate running process should match other tools such as process hacker. If the results being returned differ it suggests the tools ability to return the requested information is being interfered with. The second reason for this is that the memory sample can also be very revealing when determining the malware purpose and indicators.
Using a RAM analysis tool such as Volatility or Rekall we can parse the memory dump looking for our sample and any additional malicious artefacts. Keeping in mind that the memory dump merely represents the state of the system when the dump was performed. If the sample had terminated there would be little information available in the memory than if it was still executing. The duration of time following the event of interest can greatly affect the usefulness of memory analysis.
Using volatility's pslist a list of running process can be extracted. From this we can see that the Audiodriver.exe is still executing:
0xfffffa8031ace060 cmd.exe 3516 1680 1 24 1 0 2016-08-17 09:17:06 UTC+0000
0xfffffa8033bc89c0 conhost.exe 3076 424 2 65 1 0 2016-08-17 09:17:06 UTC+0000
0xfffffa8034055060 AudioDriver.exe 832 3832 13 240 1 1 2016-08-17 09:25:10 UTC+0000
0xfffffa8031453060 SearchProtocol 620 2920 7 289 0 0 2016-08-17 09:30:17 UTC+0000
Running peframe on the dumped executable via procdump plugin yields results that appear visually identical to the Pay&43.exe sample. Although the MD5s differ the imphash are the same suggesting the same import structure. It is possible this is the same executable deployed to a new location for persistence.
Now a running sample has been identified further inspection is required to obtain further details on the sample. Now using dlllist we can look to see what dll files have been loaded by the running processes which returns the below:
AudioDriver.ex pid: 832 Command line : "C:\Users\USER\AppData\Roaming\Microsoft\Speech\AudioDriver.exe" Note: use ldrmodules for listing DLLs in Wow64 processes
Base Size LoadCount Path
------------------ ------------------ ------------------ ----
0x0000000000f00000 0x296000 0xffff C: \Users\USER\AppData\Roaming\Microsoft\Speech\AudioDriver.exe
0x00000000775a0000 0x1aa000 0xffff C: \Windows\SYSTEM32\ntdll.dll
0x0000000073b80000 0x3f000 0x3 C:\Windows\SYSTEM32\wow64.dll
0x0000000073b20000 0x5c000 0x1 C:\Windows\SYSTEM32\wow64win.dll
0x0000000073b10000 0x8000 0x1 C:\Windows\SYSTEM32\wow64cpu.dll
The above as volatility states is a 64bit process meaning we need to run ldrmodules to repeat the same as dlllist but for 64bit processes. This returns the below representative sample for the process we are interested in.
832 AudioDriver.ex 0x0000000073740000 False False False \Windows\SysWOW64\bcrypt.dll
832 AudioDriver.ex 0x0000000004a40000 False False False
832 AudioDriver.ex 0x0000000073a00000 False False False \Windows\SysWOW64\WSHTCPIP.DLL
832 AudioDriver.ex 0x0000000073760000 False False False \Windows\Microsoft.NET\Framework\v4.0.30319\nlssorting.dll
832 AudioDriver.ex 0x00000000770e0000 False False False \Windows\SysWOW64\rpcrt4.dll
832 AudioDriver.ex 0x0000000004970000 False False False
832 AudioDriver.ex 0x0000000073b80000 True True True \Windows\System32\wow64.dll
832 AudioDriver.ex 0x0000000075590000 False False False \Windows\SysWOW64\kernel32.dll
832 AudioDriver.ex 0x0000000075db0000 False False False \Windows\SysWOW64\shlwapi.dll
832 AudioDriver.ex 0x0000000072fc0000 False False False \Windows\Microsoft.NET\Framework\v4.0.30319\clrjit.dll
832 AudioDriver.ex 0x0000000076f60000 False False False \Windows\SysWOW64\advapi32.dll
832 AudioDriver.ex 0x00000000009a0000 False False False
832 AudioDriver.ex 0x0000000075be0000 False False False \Windows\SysWOW64\ole32.dll
832 AudioDriver.ex 0x00000000758b0000 False False False \Windows\SysWOW64\sechost.dll
832 AudioDriver.ex 0x00000000771f0000 False False False \Windows\SysWOW64\KernelBase.dll
832 AudioDriver.ex 0x0000000075e10000 False False False \Windows\SysWOW64\imm32.dll
832 AudioDriver.ex 0x00000000734d0000 False False False \Windows\SysWOW64\dwmapi.dll
832 AudioDriver.ex 0x00000000734f0000 False False False \Windows\SysWOW64\mscoree.dll
832 AudioDriver.ex 0x0000000075e80000 False False False \Windows\SysWOW64\msvcrt.dll
832 AudioDriver.ex 0x0000000073f00000 False False False \Windows\SysWOW64\uxtheme.dll
Review of the imported dlls a process uses allows inference to be made of what the malware functionality may be. Further to this there should also be a reference to the dll file being loaded for example: \Windows\SysWOW64\mscoree.dll. The above highlights that there are loaded dlls that have no base image suggesting memory resident dll that may need to be recovered from memory for further analysis.
In order to dump the dll we will need the DLL memory base address of '0x00000000009a0000' and we can use dlldump in volatility to do this. keep in mind this refers to the memory address in the process address space rather than the memory dump physical offset.
If we run peframe on the newly dumped dll we get the following:
Short information
------------------------------------------------------------
File type PE32 executable (DLL) (console) Intel 80386 Mono/.Net assembly, for MS Windows
File name module.832.13cc55060.9a0000.dll
File size 49152
Hash MD5 5444ff573794d853d24fbce00548227b
Compile time 2016-05-25 19:20:21
Sections 3 (0 suspicious)
Directories import, resource, debug, relocation
Detected packer
Dll True
Packer info
------------------------------------------------------------
Microsoft Visual C++ 8
Microsoft Visual C++ 8.0
Filename found
------------------------------------------------------------
Library starksoft.aspen.dll
Library mscoree.dll
The two filenames highlight that this is .NET executable but the starksoft.aspen reference would be a good candidate for online data mining which results in the following additional information:
A good string match for this DLL would be https://github.com/bentonstark/starksoft-aspen which is .net / mono security and cryptography library that provides client support for ftps, gnupg, smartcard, and socks / http proxies.
Now if this is repeated for the remaining 4 of the interesting DLLs we get further information which can infer the purpose of this sample. Below is the main component identified as a DLL loaded by the main .NET executable.
Short information
------------------------------------------------------------
File type PE32 executable (GUI) Intel 80386 Mono/.Net assembly, for MS Windows
File name module.832.13cc55060.5320000.dll
File size 1048064
Hash MD5 815d432f31a5c2873380c4df3d53598e
Compile time 2016-07-31 19:20:08
Sections 3 (1 suspicious)
Directories import, resource, relocation
Filename found
------------------------------------------------------------
XML .purple\accounts.xml
XML FileZilla\recentservers.xml
XML default.xml
XML System.Xml
Binary http://speedtest.netcologne.de/test_100mb.bin
Binary http://speedtest.reliableservers.com/100MBtest.bin
Database key3.db
Library nss3.dll
Library System.Core.dll
Library System.Windows.Forms.dll
Library System.Xml.Linq.dll
Library msvcr100.dll
Library mozglue.dll
Library msvcr120.dll
Library System.Xml.dll
Library System.dll
Library msvcp120.dll
Library msvcp100.dll
Library shlwapi.dll
Library user32.dll
Library msvcrt.dll
Library mscoree.dll
Library advapi32.dll
Library Kernel32.dll
Library iphlpapi.dll
Library gdi32.dll
Library a.DLL
Library shell32.dll
Compressed costura.microsoft.win32.taskscheduler.dll.zip
Compressed costura.orcus.plugins.dll.zip
Compressed costura.aforge.video.directshow.dll.zip
Compressed costura.orcus.shared.utilities.dll.zip
Compressed costura.orcus.shared.dll.zip
Compressed costura.starksoft.aspen.dll.zip
Compressed costura.cscore.dll.zip
Compressed costura.aforge.video.dll.zip
Data Microsoft\Speech\Files\err_{0}.dat
Data Microsoft\Speech\Files\klg_{0}.dat
Url found
------------------------------------------------------------
http://mirror.internode.on.net/pub/test/100meg.test
https://api.ipify.org/
http://speedtest.reliableservers.com/100MBtest.bin
http://speedtest.netcologne.de/test_100mb.bin
http://www.speedtestx.de/testfiles/data_100mb.tes
The above identifies a list of useful filenames that were not masked and the compressed items namely those beginning costura.orcus highlight this is likely to be the Orcus RAT. The additional dlls also yield further details about the capability relating to SSL encryption/decryption and researching these can produce useful insights.
There is also another item we can perform to help gleam useful details from this sample. If we dump the memory utilised specifically by the AudoDriver.exe process using the volatility command memdump. If a search is conducted for strings such as Orcus or costura or http may identify details relating to its functionality. For example:
Orcus.Shared.Connection
IDatabaseConnection
get_DatabaseConnection
set_DatabaseConnection
databaseConnection
ArgumentNullException
ArgumentException
get_Description
set_Description
Shutdown
CompareTo
CultureInfo
PluginInfo
IConnectionInfo
connectionInfo
IpAddressInfo
ipAddressInfo
JOrcus.Commands.UninstallPrograms.UninstallProgramsCommand+<GetEntries>d__2
TOrcus.Commands.Passwords.Utilities.RegistryKeyExtensions+<GetFormattedKeyValues>d__4
FOrcus.Commands.Passwords.Applications.WinSCP.WinSCP+<GetPasswords>d__0
HOrcus.Commands.Passwords.Applications.Windows.Windows+<GetPasswords>d__0
FOrcus.Commands.Passwords.Applications.Pidgin.Pidgin+<GetPasswords>d__0
ZOrcus.Commands.Passwords.Applications.InternetExplorer.InternetExplorer+<GetPasswords>d__1
LOrcus.Commands.Passwords.Applications.FileZilla.FileZilla+<GetPasswords>d__1
HOrcus.Commands.Passwords.Applications.CoreFTP.CoreFtp+<GetPasswords>d__1
QOrcus.Commands.AudioVolumeControl.AudioVolumeControlCommand+<GetA udioDevices>d__4
Orcus.Commands.LiveKeylogger
LiveKeyloggerCommunication
Orcus.Shared.Commands.LiveKeylogger
SendOrPostCallback
Further to this it may also reveal items that the creator may not have intended as this appears to be under developemt such as:
Orcus.Plugins
QProvides all interfaces which are needed to create an awesome plugin for a client
Orcus Technologies
$Copyright
Orcus Technologies 2016
$0d743e5d-0d5f-4b9b-b2df-1f607b5031c4
1.3.0
R/VK
yjjk
RSDS"i
D:\Dokumente\Visual Studio 2015\Projects\Orcus\MainSource\Orcus.Plugins\obj\Release\Orcus.Plugins.pdb
This shows that Orcus is indeed .NET based and the .NET project resided on a machine which had the German language pack applied.
Combining these techniques can allow an incident responder to identify malicious artefacts and additional intelligence to mitigate the threat that automated sandboxes may not identify. This is also true in relation to utilised IP connections or HTTP connections.
This is not aimed at being an exhaustive write up on static analysis, dynamic analysis, digital forensics, intrusion forensics or memory analysis. This merely shows with a little time and freely available tools what could be identified if applied.