Malicious Executables

For details on reverse engineering - refer to the Reverse 🔧 section of this website. I will only look into the simple static and dynamic analysis (using tools without running the file and running it- to see where it poos 💩).

SANS Six-Part Methodology

• Identify rogue processes
• Analyse DLLs and handles.
• Review network artefacts
• Look for code injection.
• Check for any signs of a rootkit.
• Dump suspicious process and drivers.

Static

• .rsrc section usually contains such resources as icons, pictures etc. However, some malicious programs (as well as legitimate ones) can store a driver or other code there, which gets extracted and executed by the main program flow.

Strings

Check strings in Image and in Memory using the corresponding radio button on the Strings tab of a selected process info in Process Explorer. If they differ - process replacement tool place. Use 🛠 strings or floss (decodes them as well)

Interesting strings:

• pdb files (often contain username and can also give a hint on the malware writer’s country of origin)
• URLs
• Something that looks like a password
• emails
• Base64 encoded things
• library names

Signed Malware

It’s a rare case, but it exists. Around 3% of malware is signed. It’s because some systems require executables to be signed. But this technique is not very good for malware authors since when at least one “product” is marked as malicious, all code signed with the same certificate will also be identified. 🛠 Use sigcheck to check signatures and hashes against Virus Total.

Check with a spctl if Apple notarises the application (not yet installed).

spctl -a -vvv -t install /Volumes/BurpSuitePro/Burp\ Suite\ Professional.app 
/Volumes/BurpSuitePro/Burp Suite Professional.app: accepted
source=Notarized Developer ID
origin=Developer ID Application: PortSwigger Ltd (N82YM897DZ)

Libraries and Imports

• On Windows systems, some functions have the suffix A or W. These indicate that this function accepts ASCII or wide-character strings as an argument.
• On Windows systems, some functions have a suffix Ex or even ExEx. These indicate that Windows has released a new version of a function incompatible with older ones since older ones must be supported.
• You can use this web resource to understand WinAPI functions that are used by malware - https://malapi.io/. Remember, these are legit WinAPI functions and they are also used by legit software.

32-bit Apps

For backward compatibility with older machines, malware authors prefer compiling 32-bit applications. Since malware authors usually want their software to work on as many machines as possible, they often compile 32-bit code**. That’s not a decent indicator but an excellent additional score.

Location

It might be atypical location for svchost.exe in Documents forlder. You’ll need to know what’s ok and good for the given system. May user SANS poster Find Evil. Common locations for malware: Windows\System32 is a very important location since it allows running with elevated privileges? ❓❓❓Also Temp folder and Temp Internet Files. Windows, Windows SxS. Recycle bin also may contain some files or remnants. Program files is the most usual for programs and malware may reside there as well.System Volume Information. That doesn’t mean, however, that malware can’t be elsewhere. Some core Windows executables don’t even have an image file on disk (System, IDLE, for example).

Name

For example, name precisely like or very similar to some core system process? Is the strange name similar to the legit one? svchosts, for example. Present in psscan but absent in pslist (for running processes)? Read more about RAM forensics in the corresponding section. It’s usual for malware to mistype the names if standard win core processes or use the same names in weird locations. Name mangling is a common technique.

To spot deviations at that point, you need to understand what’s normal for that particular system. There are some common “normalities” for different OS, of course. You can refer to the SANS poster “Find Evil”, which is often updated, the SDF Podcast of Michael Leclair about Windows Core Processes, or find the corresponding article about core processes and system supernova in the Technical Reference section of this website.

Runtime Linking

Since static linking is rare (it increases the body of a program) and dynamically linked functions can be inspected differently, runtime linking might be a choice for malware authors to hide the functionality. How to determine if the runtime linking is used?❓Windows, Mac, Linux? Importing and using GetProcessAddress/LdrGetProcessAddress or/and LoadLibrary/LdrLoadDll.

Packed Executable

Almoust 100% indicator that the author didn’t want his treasure to be reverse engineered. Why could this be? Because it’s some software with a portion of client-side code that performs sensitive operations. One example of a legitimate software is a program that generates OTP codes. There are several ways to determine that a file is packed. The first one - using enthropy analysis against the file. Consider, that most program epilogues start with 55 8B EC (push ebp mov ebp, esp) and end with c3 (ret). That means that the number of both in one executable should be relatively the same. Compressed files don’t compress well. Another example is to pack the file and determine, how efficiently was it packed. If it wasn’t possible to pack the file too much, it’s probable that the file is already packed. 🛠 Use the first method with PEiD (GUI Windows tool), use the second method with densityscan (commercial cross-platform tool). Below are some common preliminary indicators of packed executables:

• VA vs PA. Empty Physical addresses for sections (while VA are not empty). More about virtual and physical addresses in the reverse engineering section.
• Weired names for PE sections. PE sections (for Windows) are usually text, bss, data etc. If you some gibberish that’s not usually seen here, most likely the executable is packed.

Hash

Check the file hash against the VirusTotal database. This way you’ll eliminate known good files, since it’s highly unlikely that a legitimate software like Windows files have never been checked so far. Also, this way you can find known bad.

Byte-level signatures

You may have some signatures left from previous malware.

Owners

Check the account it is run from. The most commonly used are local system accounts, network service accounts, and local service accounts. If any of the core processes are run from a user account, it’s a possible sign of compromise.

Dynamic

Parent Process

Some other executable runs each executable. For core processes, there is only one legitimate parent. 👣 For Windows: wininit doesn’t have a parent, while sms.exe is the child of System. Read more about core processes for each specific OS in a separate section.

Process taken over

https://www.linkedin.com/pulse/process-injection-detection-malfind-britton-manahan/

On-disk vs RAM

On-disk and in-memory contents don’t match.

Behaviour

Suspicious files opened, network ports and connections, OS resources (mutexes, hooks etc), a significant amount of CPU or RAM? .rsrc section usually contains such resources as icons, pictures etc. However, some malicious programs (as well as legitimate ones) can store a driver or other code there, which gets extracted and executed by the main program flow. If you suspect that a dynamically linked library was loaded into a process after load time, compare the import list in Process Explorer to the imports shown in Dependency Walker (Windows, for other OS use analogous tools). radare2 and IDA can also show imports.

One of the useful resources (Windows API docs, of course) also https://malapi.io/ (from the malware perspective).

If your detection engine says there is an injection technique being used - most likely it’s malware. https://www.linkedin.com/pulse/process-injection-detection-malfind-britton-manahan/

🔥 An awesome resource to help with malware analysis - https://unprotect.it/technique/evasion-using-direct-syscalls/.

Singletons

One instance running only. 👣 For Windows: One instance lsass, services, System, winint, lsm.exe ❓. If any of these have more than 1 process should be the object of further investigation.

Boot time

Core processes boot at a certain time and in specific order after boot. Anomalies here might be a good indicator of compromise. 👣 For Windows: sms starts at boot, for example.

PID

Some core processes might have a predefined PID. 👣 For Windows: The system usually has PID 4.

Troubleshooting

Funny enough, malware can sometimes only run with massive help. Usually, that happens when there is an OS mismatch, some lib is missing from the machine, or simply a bug in the code itself. Ironically, we need to help it do its job in this case. So, how to troubleshoot malware?

DLL to EXE. DLLs are dependent processes on Windows and, under normal circumstances, can’t run independently. This complicates the analysis, and we want to save time. There are two ways (that I know of) that can make the DLL think it’s an EXE:

1. use rundll32 (rundll32 [dllname].dll, [function name or ordeal]). For example, a malware.dll has the function InstallService, which requires an argument service name. We want to launch it, call this function to create a service named “MaliciousService”: rundll32 malware.dll, MaliciousService. In Dependency Walker, we can peek the function’s ordeal and run this command like this (if the ordeal is, say, 5): rundll32 malware.dll, #5.
2. patch the PE header of the DLL + change its extension. IMAGE_FILE_HEADER -> CHARACTERISTICS –> IMAGE_FILE_DLL flag 0x2000 set to 0x0000.

Services. On Windows, ServiceMain can sometimes be missing an Install function. To fix this, either:

1. Use sc command or
2. HKLM/SYSTEM/CurrentControlSet\Services - modify the registry key.

How to find out …

• … which processes used a specific dll ❓ In Process Explorer choose Find Handle or DLL.
• … if a DLL is loaded into a process after load time ❓ Compare the DLL list in Process Explorer to the imports shown in Dependency Walker.
• … if a .doc or .pdf or another document is malicious ❓ Open Process Explorer, launch the suspicios doc in sandboxed environment and check whether it has spawned any processes. Open this process’s Properties window, Image tab to check the location of the malware file.
• If there is an open socket, you can open nc -nv <IP> <port> to see what it wants to get.
• If the malware is looking for a DNS record and iNetSim doesn’t work (because it’s something very custom), try adding 127.0.0.1 <DNS name> and observing the activity with a tool like ProcMon. Then, do ncat -nvlp <port>. Try ipconfig /flushdns (Windows) if this doesn’t help.
• If process injection took place, find the victim in Process Hacker (or some analogue) and open Properties -> Memory. Sort by Protection and find all that have RWX permissions (that’s usually what a shellcode will require to run). No name in the Use column usually indicates. Here is a separate section devoted to malware analysis methodology, tips, etc..

Malware as an Artefact

The attacker leaves malware, so it’s a trace of their activity. Type of malware, location found etc., sometimes can hint at the actor.

PDB

Strings

Meta

Resources

• .rsrc section usually contains such resources as icons, pictures etc. However, some malicious programs (as well as legitimate ones) can store a driver or other code there, which gets extracted and executed by the main program flow.

Evidence

• Passwords
• Names
• Paths

References