These characteristics MIGHT be of malware, but not necessarily. These are just some clues and advice.

Runtime linking

Since static linking is rare (it increases the body of a program) and dynamically linked functions can be inspected in different ways, 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?

Imports

Importing and using GetProcessAddress/LdrGetProcessAddress or/and LoadLibrary/LdrLoadDll.

❓ For Mac and Linux?

Strings

Check strings in Image and in Memory using the corresponding radio button on the Strings tab of selected process info in Process Explorer. If they differ - process replacement took place.

32bit Code

Since malware authors usually want their software to work on as many machines as possible, they often compile 32bit code. That’s not a decent indicator by itself, but it’s a good additional score.

Signed Code

Around 3% of malware is signed. It’s due to the fact that 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 that was signed with the same certificate will be identified as well. 🛠 Use sigcheck to check signatures and hashes against Virus Total.

Packed Executables

Packed executables are almost 100% indicators 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 legitimate software is a program that generates OTP codes. There are several ways to determine that a file is packed. The first one - using entropy 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), and use the second method with pescan (commercial cross-platform tool).

PE Sections

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.

Virtual vs Physical Addresses

VA vs PA. Empty Physical addresses for sections (while VA are not empty).

«««< Updated upstream:content/docs/reverse/malware-analysis/tips/indicators.md

Librariries and Methods

Throubleshooting malware

• If it’s a dll, it can be still ran independently. Though there are no guaratees, there are two ways to acomplish that (either can work for you):
  • use rundll32 (rundll32 [dllname].dll, [function name or ordeal]). Example, a malware.dll that has a function InstallService which requires an argument service name. We want to launch it, call this function to create a service with name “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.
  • patch PE header of the dll + changing its extension. IMAGE_FILE_HEADER -> CHARACTERISTICS –> IMAGE_FILE_DLL flag 0x2000 set to 0x0000.
• ServiceMain without any Install function.
  • Use sc command
  • HKLM/SYSTEM/CurrentControlSet\Services - modify the registry

Interesting places to check

• .rsrc section usually contains such resources as icons, pictires 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 progam flow.

Naming conventions

• On Windows systems some functions have a suffix A or W. These indicate that this function accepting ASCII or wide character string as an argument respectively.
• On Windows systems some functions have a suffix Ex or even ExEx. These indicate that Windows has released a new version of a function which is not compatible with older ones, since older ones must be supported.

How to find out …

• … which processes used a certain 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.

Tools

• ProcMon (Sysinternals) for Windows and Glances for macOS https://nicolargo.github.io/glances/, osquery, Instruments, vtop. Also try opensnoop, but with SIP off.

Malware Databases

Tools

A great resource with code snippets and techniques - https://unprotect.it/technique/vmprotect/.

Repos

• theZoo: https://github.com/ytisf/theZoo
• VXUnderground GitHub repo: https://github.com/vxunderground/MalwareSourceCode
• Zeltser Resources: https://zeltser.com/malware-sample-sources/

Info

Try MISP API - https://www.misp-project.org/openapi/#tag/Attributes/operation/restSearchAttributes.

https://www.hybrid-analysis.com/sample/9fe55c51af6230c8640e140104645b32ba83ac868bf0f1571733f14761701247 https://www.f-secure.com/v-descs/trojan-spy_w32_finspy_a.shtml https://malshare.com/

Malicious websites: https://zeltser.com/lookup-malicious-websites/

https://mail.google.com/mail/u/0/#inbox

My own is maintained in Notion for now. Planning to turn this into a SQL DB + CLI.

Network

https://malware-traffic-analysis.net https://packettotal.com/malware-archive.html

Stashed changes:content/docs/reverse/malware-analysis/tips.md

General Guidelines

Signed executable. It’s a rare case, but it exists. Around 3% of malware is signed. It’s due to the fact that 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 that was signed with the same certificate will be identified as well. 🛠 Use sigcheck to check signatures and hashes against Virus Total.

Check with a spctl if the given application (not yet installed) is notarized by Apple.

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)

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

32 bit application. For backward compatibility for older machines, malware authors prefer compiling 32bit applications. Since malware authors usually want their software to work on as many machines as possible, they often compile 32bit code. That’s not a decent indicator by itself, but it’s a good 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).

Suspicious time. Created at suspicious time? Launch time suspicious?

Suspicious name. For example, name exactly like or very similar to some core system process? Strange name similar to leg 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 common wincore processes or use the same names in weird locations. Name mangling is a common technique.

Signs of reconnaissance stage.

Runtime linking. Since static linking is rare (it increases the body of a program) and dynamicly linked functions can be inspected in different ways, 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 executables. 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. The first and dummiest way, but highly suggested is to check the file hash against 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. May be you have some signatures left from previous malware.

Name. In order to spot deviations at that point you need to have a firm understanding of what’s normal for that particular system. There are some common “normalities” for different OSes, of course, as well. You can refer to SANS poster “Find Evil” which is often updated, 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.

Unexpected owners. Check the account it being run from. The most commonly used are: local system account, network service account, local service account. If any of the core processes is run from a user account, it’s a possible sign of compromise. 👣 For Windows:

Unexpected parent. Each executable is run by some other 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.

Hidden by WinAPI.

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

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

Unusual behaviour and resources. Suspicious files opened, netwrk ports and connections, OS resources (mutexes, hooks etc), significant amount of CPU or RAM? .rsrc section usually contains such resources as icons, pictires 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 progam flow. If you suspect that a dinamically 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 usefull resources (Windows API docs, of course) and also https://malapi.io/ (from the malware perspective).

Network triage. Check network activity for malicious stuuff.

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

Boot time. Core processes boot at certain time 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: System usually has PID 4.

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

References