hasherezade/malware_training_vol1

Materials for Windows Malware Analysis training (volume 1)

malware_training_vol1

Materials for Windows Malware Analysis training (volume 1)

🚧 WARNING: work in progress! More material will be added gradually.

Content

The goal of this training it to build understanding of various common techniques used by malware. It contains elements of programming as well as reverse engineering, and introduction to some Windows internals concepts.

It also showcases how various tools (including my own) can be used to achieve particular analysis goals.

Target audience

This material would fit best to people who already have technical knowledge from surrounding areas: basics of programming and reverse engineering - yet, who want to enter into the field of Windows malware analysis.

License

This material is published under the Creative Commons BY License, which means:

This license lets others distribute, remix, adapt, and build upon your work, even commercially, as long as they credit you for the original creation.

Noticed an error?

If you noticed any error in this material, please report it in the Issues

Need help in a task?

If you need help in any of the exercises, or have additional questions, you can share it in discussions

Covered topics vs planned

Module 1

Slides	Exercises	Topic
✔️	✔️	compilation
✔️	✔️	PE
✔️	✔️	Process
✔️	◻️	WoW64
✔️	✔️	shellcode
◻️	◻️	code injection
◻️/✔️	◻️/✔️	PE loaders

Module 2

Slides	Exercises	Topic
✔️	◻️	Malware missions & tactics (intro)
✔️	◻️	hooking
✔️	◻️	persistence
◻️	◻️	UAC bypass
✔️	◻️	Banking trojans
◻️	◻️	RATs
◻️	◻️	Ransomware
◻️	◻️	Lateral movements

Module 3

Slides	Exercises	Topic
✔️	◻️	Evasion and self-defence (intro)
◻️/✔️	◻️	Fingerprinting
◻️	◻️	String obfuscation
◻️	◻️	Imports obfuscation
◻️	◻️	Flow obfuscation
◻️	◻️	Malware antihooking
◻️	◻️	Review of approaches to deobfuscation
◻️	◻️	Kernel-mode malware components

malware_training_vol1's Issues

Additional start up location (Malware Training Vol. 1 - Module 2.3 Persistence - Slide 6)

On slide 6 additional startup location can be listed:

• C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp

Vol1-Mod1_3- Slide 23 - Typo

"WindowsAPI allows to retieve" -> "WindowsAPI allows to retrieve"

Vol1-Mod1.1 compilation - Suggestions

Slide 6:

• MSIL is a deprecated name for CIL and should not be used

Slide 17:

• the file extension (.cs) suggests C# - there are no .h files in C#.

Thanks for this training.

Exercices-Mod1-L2PE-PeSelfLoad-Main.cpp - useless code detected

At line 182 you check for argc being at least 2 otherwise exit program at line 191.
Thus, test on line 194 is always true and redundant with the one on line 182
And line 195 initialization is redundant with line 193

Suggested fix : remove lines 194 to 196

Vol1-Mod1.2PE-Slide10 - Typo

"OptionaHeader" --> "OptionalHeader"

Small typos

Hello,

I found a few small typos in the following slides.

• Module1_5_shellcode.pdf page 5 (Creating shellcode)
  "Cutom;" -> "Custom;"

• Module3_2_fingerprinting.pdf page 26 (The time check)
  "treshold" -> "threshold"

Your training materials are awesome!🥰 I am looking forward to your new materials.

Vol1-Mod1.2PE-Slide3 - Typo + Driver remark

"kernel more : " --> "kernel mode : "

Additionaly your text suggests that drivers (.sys) are always running in kernel mode which is not true anymore since win8.1. Thanks to UMDF we can run .sys drivers in a dedicated user mode environment (Wudfhost.exe).

Code robustness question

Exercises code contains some error checking and leave aside a couple of cases.
I understand we are in a lab and not seeking for bullet proof and "production ready" code quality.
Could you clarify what level of error checking/robustness you are emphazing, so that we could submit just the right level of issues that could help you reach this level ?

Additionally should you seek to improve error checking, would you prefer textual explanations and suggestions such as #6 or push requests ?

By the way the project is very interesting and I'm looking forward for next episodes;

Vol1-Mod1.3Process-Slide14 - Suggestion

At point 6 you states BaseProcessStart invokes EntryPoint which is right.

However this might not be the very first user provided code that is executed. One of the well known technic used by malwares is to use thread local storage (TLS) and associated callbacks that are defined in the IMAGE_TLS_DIRECTORY data directory. These callbacks if present would be invoked at point 5 by LdrpInitialize. I can't remind wether it is before or after DLL imports.

I don't know if you wish to state it here or consider this as an advanced topic you will deal with later in your slides.

Vol1-Mod1-Slide12-WyWiWyG

I feel "decompiled code is identical to the assembly code that you wrote" is sligthly misleading. Both MASM and YASM support macros and equates that are inlined during compilation. Thus, any decompilation process will be unable to recover these syntactic constructions.

Exercices-Mod1-L2PE-PeSelfLoad-Main.cpp - logical bug

On line 202 you retrieve file size but fail to check for INVALID_FILE_SIZE (-1) return value.
Should GetFileSize fail on a 32 bit system, allocation on line 204 will throw an std::bad_array_new_length exception.

Additionally you don't check either the result of the byte array allocation which could fail on very big files or in case of high memory pressure.

Vol1-Mod1-Slide18-Typo

"contails: JIT compiler ..." --> "contains: JIT compiler ..."

Vol1-Mod1.4WoW64-Slide14 - Heaven's gate and CFG

You wrote "Load other 64 bits DLLs with its help, in order to be able to use the 64 bit API."

Are you sure this is always/still possible ? My understanding is that any shellcode running on a thread bound to a Control Flow Guard (CFG) protected process will fail here, or at least will have a very tough journey to succeed.

A good explanation by A. Ionescu can be found here

Exercises-Setup-README.md Typos

"when your Virutal Disk is located" --> "where your Virtual disk is located"
"Go throug and accept" --> "Go through and accept"
"Display -> Screem -> Increase" --> "Display -> Screen -> Increase"
"improve the performence of you VM" --> "improve the performance of your VM"
"Disable redundant starup apps" --> "Disable redundant startup apps"
"Tailored expiriences" --> "Tailored experiences"
"Imprtove inking" --> "Improve inking"
"Allow aps to access" --> "Allow apps to access"
"Visual Studio and programming utitilies" --> "Visual Studio and programming utilities"

vol1-Mod1.2PE-S44 - Suggestion DUMPBIN & EDITBIN

The DUMPBIN & EDITBIN command line tools (available with all editions of Visual Studio when VC++ workload is installed) might be interesting references. The tools allows extensive dump/modification of many parts of a PE/OBJ file except those compiled with global optimization (/GL compiler option). These tools are helpfull when experimenting with PE files.

https://docs.microsoft.com/fr-fr/cpp/build/reference/dumpbin-reference?view=msvc-160
https://docs.microsoft.com/fr-fr/cpp/build/reference/editbin-reference?view=msvc-160

Vol1-Mod1.5Shellcode-Slide12 - /FA flag

It might be usefull for people not familiar with /Fa flag to clarify that it generates a listing of the assembly code default named <file_name>.asm, otherwise readers may wonder where the <file_name>.asm comes from.
Personnally, I prefer using /FAs instead so that the original C source code appears as comments in the .asm file which help during refactoring.

Vol1-Mod1.3Process-Slide29 - Wording

The slide says that the TEB can be obtained "via registry: FS, GS".
But I think "via registers" should be used instead since FS and GS are segment registers. 'Registry' might lead people to think it is related to the Windows Registry.

Vol1-Mod1.6PELoaders-Slide9 - Clarify Section concept

When you say "Create a Section" I assume you mean invoking Zw/NtCreateSection.
This might be confusing for readers because the section concept has been introduced in module 1.2 as a structure from the COFF file format.
Do we agree the "section" you are talking about here is a Windows Kernel objet that can be mapped into user mode adress spaces ?
If so how could we clarify this ? Do you feel a Vol1 module 0 with some "required" Windows concepts (virtual memory, sections ...) would be usefull or do you consider this is "basic stuff" that is assumed to be known from the reader ?

Vol1-Mod1.5Shellcode-Slide3 - "caves between sections" question

I don't understand what you mean by "cave between sections". As I understand, the PE loader allocates a memory block for each section. However these blocks are disjoint and it seems memory areas between sections are undefined. Am I missing something ?

Vol1-Mod1.4WoW64-Slide3 - Emulator vs Subsystem

AFAIU WoW64 is an emulator not a subsystem.

Microsoft itself defines WoW64 as an emulator :
https://docs.microsoft.com/en-us/windows/win32/winprog64/wow64-implementation-details
... while it advertises WSL as a subsystem :
https://docs.microsoft.com/en-us/windows/wsl/