LAB 2: Static Malware analysis win32update.exe (skid)

    Static malware analysis is simply the process of analysing a malware sample, its code, structure and metadata without actually activating the file itself. Essentially, static analysis allows us to conduct a safe initial investigation. For this lab, we have chosen to conduct a static analysis of a malware named win32update.exe.

We will be using many tools and websites, such as:

PEBear,

PEstudio,

DIE,

Floss,

Strings,

Capa

malapi.com

virustotal.com.

According to these tools and the MITRE ATT&CK framework, we will confirm with high/medium/or low confidence what type of malware we're dealing with.

This lab will be divided into these parts:

1. PE File Triage

2. Reputation & Context in Virus Total

3. String Analysis

4. Capability Identification

5. Packing and Obfuscation

6. Behavior Mapping

7. Key Findings and Conclusion

1. PE File Triage

    During this part, we will be collecting some basic information of the malware using the PEBear tool, which we downloaded and configured in LAB1: Malware Analysis (check for reference).

    Firstly, let's look at the content of the malware folder we have pre-installed prior to the lab.

    From the pictures, we can see that the malware has multiple files. During this lab we will be focusing on 2 main ones: the win32update.exe for static analysis and the win32update.bat for a simple batch file analysis of the malware code itself. But first, let's start with the static analysis.

File Hash (SHA256)

    SHA256 is a one-way cryptographic hash function that takes any data and converts it to a 32-byte hexadecimal hash value. It improves integrity, authorization, and digital signatures. To find this hash function, we went to PEbear and loaded our malware file named "win32update.exe.". Then on the "General" section, we found this:

• f58ee5a3eaae6b4139b7d1b2a4b407f15705dfd0727236469730e978d8d9d436

Machine architecture

    If we go through the "File Hdr" section in PEBear, we can also see the machine architecture of the malware, which is 32 bit. Additionally, if we go the Optional HDR, we can further see that the virus allows backwards compatibility all the way down to windows 95 / NT 4.0.

• 

  
  

Compilation timestamp (raw + interpreted)

Compilation timestamp is metadata about the records that includes the exact date and time the programmer compiled the executable file. In our case its:

• 2023-04-18 22:40:23 UTC

• 

• (PE BEar => file hdr)

Subsystem (GUI / Console) / DLL characteristics flags (NX, ASLR, etc.

        In the picture below, we can see that the subsystem is Windows Console. In a malware analysis context, this means that the attacker has easier automation and scripting compatibility, since CLI files can run without user input via .batch files, PowerShell, etc. Additionally, through the same command, we can also see that there are no DLL characteristics flags, just general ones (as can be seen through the second picture).

    PE bear => optional hdr => offset 144 & 146

PE bear => file hdr => FE

Is it signed or unsigned?

        In the context of malware, a signature is a "fingerprint", meaning that it is a unique identifying digital footprint or characteristic tied to malware. A signature can take the form of a hash function, strings, registry keys, etc. An easy way to find signatures is to look at offset 180 in PE bear (Security Directory), and if we have any values other than zero, it means that the malware is signed. In our case, both address and size are equal to zero.

Using PE-Bear, we can see that the section names are defined as:

• .text

• .rdata

• .rsrc

• .data

PE-Bear -> Section hdrs

Virtual size vs raw size of Section Headers

Raw size is the actual physical size of the section on disk, usually expressed in bytes, while the virtual size is the size of the section when loaded into memory. Using PE studio, we found these results:

• RAW VS VIRTUAL data size:

• 
  

• .text 61KB - 60KB

• .rdata 4KB - 3KB

• .data 8KB - 11MB ( the difference here is extremely suspicious, and we thought it was a definite sign of packing; however, after research, we think that it might be due to VirtualAlloc being connected.)

• .rsrc 4KB - 16 bytes

PE studio => sections

Entropy

Mid-to-No Entropy, this would be a sign that the application is likely not packed. This evidence is further backed up with DiE report saying that the chances are about 76% that it is not packed.

DiE => advanced => Entropy

Permissions (R/W/X)

Each section has different permissions, using PE bear we found that:

-text r/x

-rdata r

.data rw

.rscr r

Pe bear - section hdrs

Imports

List of imported DLLs

DLL (Dynamic Link Libraries) - are Windows files which contain code and data that multiple programs can use to perform tasks, think of them as common toolboxes for applications. Using PE Bear we found that these DLL's were imported:

Kernel32.dll

User32.dll

WINMM.dll

Pe bear - imports

    To understand the importance or risk of each of these imported DLL's, we had to research their function first. According to this link (https://learn.microsoft.com/en-us/windows-hardware/drivers/audio/user-mode-wdm-audio-components), this is what we found:

Photo taken from the book “Practical Malware Analysis : The Hands-On Guide to Dissecting” Chapter 2

Anti-analysis indicators

    So far, we have not found any indicator of anti-analysis (which was the case when we tried to do static analysis on the ukraine malware). From what we can tell, everything is left open to see by the attacker besides the win32update.exe. An indicator of this can be the picture above, in PE Bear, where even the imported DLL's were open to see.

11 security-relevant APIs:

Using PE Studio, we saw that 11 APIs were flagged, those being:

• SetConsoleMode

• SetConsoleCursorPosition

• SetEnvironmentVariableA

• GetCurrentProcess

• WriteFile

• GetEnvironmentStrings

• GetEnvironmentStringsW

• VirtualAllocCreateProcessA

• GetDesktopWindow

• SetWindowPos

Pestudio - imports

For this part, we also used (malapi.io). This website is extremely helpful when trying to understand what each of the API flagged in PEstudio do.

Required analysis

Which section likely contains core logic and why

    As we saw before, the only part that had execute privileges was the section header .text. This essentially means that the code is there.

What the import table suggests about functionality

    The import table shows us 2 main parts, Memory manipulation through VirtualAlloc and CreateProcessA.

Firstly, through this link (https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc?source=post_page-----73d52a74fd2a---------------------------------------), we can see that VirtualAlloc enables the allocation of executable memory, which than could mean that it also allows the memory to unpack or run code dynamically straight at runtime.

Secondly, through this link (https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa?source=post_page-----73d52a74fd2a---------------------------------------), we can see that this comand creates a new process and its primary thread, which then have the capability of turning into malicious processes (such as the .bat file).

We believe that these 2 functions have a say in the abnormal size of the .data abnormality.

Whether metadata appears legitimate or suspicious

    The metadata (data of data) in this malware seems to be suspicious. This claim can be supported by PE Bear, since there we can see that all: Security directory = 0

Debug Directory = 0

Major Version = 0

Minor Version = 0

This essentially means that there is no info on version, on debugging and there is no security directory. Additionally, all resources seem to have the same 0 value, as can be seen below. A normal info would actually contain values. 

PE Bear => Optional hdr

Pe Bear => Resources

2. Reputation & Context in Virus Total

    VirusTotal is a free online service owned by Google subsidiary Chronicle. It uses 70 third-party antivirus scanners and url/domain blocklisting services so it can detect malware. This part of the lab will compare our initial findings to findings posted online on this platform.

SHA256 hash - The Virus Total SHA256 Hash matches the hash we found earlier f58ee5a3eaae6b4139b7d1b2a4b407f15705dfd0727236469730e978d8d9d436

Detection ratio => 22/72 antiviruses have claimed this malware as malicious.

• 
  
  

First-seen date => 2025–09–22 20:31:10 UTC

3 AV vendors => CTX,KINGSOFT, Artic Wolf

Behavioral tags according to Virus Total => Persistance

Required analysis

    When it comes to this virus, vendors agree on both behaviour and naming, since most of them classify it as a Trojan, and the behaviour is classified as "persistent" throughout all reports. Persistent behavior (when it comes to malware) means that the virus is able to maintain long-term access to a system, further ensuring that it survives interruptions like reboots or credential changes.

    However, it is worth mentioning that VirusTotal does not show us all of the information we need. This page is missing important info like:

APIs that are flagged as security sensitive,

DLL characteristics,

String Analysis,

Other behaviour tags such as Discovery,

And important context from the batch file.

3. String Analysis

    To properly see what was written within the code, we have to conduct a string analysis (manually going over the strings to catch on something suspicious). We achieved this part of the lab with tools like strings and floss. First we had to put the malware in the same directory as these tools, after which we executed these commands.

.\strings.exe .\win32update.exe > report1.txt

.\floss.exe .\win32update.exe > report2.tx

    Both of these commands allowed us to run the malware through the tools, and then get the output written into a text file (report1.txt and report2.txt). The output for both tools was the same, and will be showcased down below.

Static strings of interest

Loading. => this function may indicate that the malware might have a console output or a fake loading screen.

WindowTitle => This function gets or sets the title of the host Window or NavigationWindow of a Page. It can be used to guide the malware to a specific place.

GetTickCount. => Based on this link (https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-gettickcount) we can see that this returns the value of milliseconds since the system was started. This can mean that it is a anti-debugging method, since debuggers and VMs have a much smaller up-time, which the malware can detect and acknowledge if its being used in a sandbox environment.

            VirtualAlloc / VirtualFree. => Mentioned beforehand, with this, we can                 confirm memory manipulation.

TerminateProcess (Confirms destructive capability). => Can be an artifact that further demonstrates the destructive capability of the malware. According to this post (https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-terminateprocess) this function terminates specified processes and all of its threads, Common thing for a CNA trojan malware.

93796 => The file size data expressed in bytes.

111111111 => Can potentially be a "go" method or "true" method

000000000 => Can potentially be a "stop" method or "false" method

Decoded/deobfuscated strings

There is none.

File paths

fe.txt =>The malware likely creates or looks for this text file.

Registry keys / URLs /IPs

While searching through the .bat file manually, or after running floss and strings, we did not encounter any Registry keys, URLs or IPs

Command-line strings

• /c =>Standard flag for cmd.exe to run a command and close. 

• del=>Delete command. 

• >nul=>Hides the output of a command so the user sees nothing. 

• Pause

• cmd.exe
  command.com

User-agent or protocol indicators

• none

Required analysis

Strings indicating execution:

• cmd.exe
• command.com
• /C
• CreateProcessA
• TerminateProcess
• ExitProcess
• GetCommandLineA
• WaitForSingleObject
• GetExitCodeProcess
• .exe
• .bat
• .cmd
• .com

Strings indicating persistence

There is no strings that indicate persistence, no registry run keys, schedules tasks or anything that looks like its service related.

Strings suggesting C2 or data exfiltration

No clear IP addresses, URLs or network APIs were seen or mentioned

Strings likely to be noise or decoys

These are standard parts of the compiler or libraries and should be ignored in your analysis report to avoid clutter.

• %s%s%s%s%s=>Standard C formatting strings.

• R6028, R6027, runtime error => These are standard Microsoft Visual C++ Runtime error messages. They are present in almost every program written in C++.

• 00000000, 11111111 => Memory padding or placeholders.

• GetACP, GetOEMCP =>Code page settings, usually standard boilerplate.

• CorExitProcess => A standard artifact of the .NET or Visual Studio runtime environment.

4. Capability Identification

    CAPA is an open-source tool created by Mandiant. With this tool, we can analyze and compare the malware with the written rules that the tool has within. Capa maps analyzed behavior to the MITRE ATT&CK framework and uses predefined rules to identify capabilities through automatic static analysis. To use this tool we need to put the virus and capa in the same file, and then run this command :

.\capa.exe .\win32update.exe

    By doing this we get this result:

    Here we can see the MITRE ATT&CK Tactics and Techniques, as well as the capabilities the malware has. However, if we want to find the CAPA rule names, their capability categories and evidence properly, we need to run this command: .\capa.exe -v .\win32update.exe . The -v stands for verbose, where capa will simply list all the required information from the .exe file. Here are the results:

    In order to sort the up-stated info, we created a simple table using Google Docs.

CAPA Rule Name	Capability Category	Evidence
check for time delay via GetTickCount	anti-analysis/anti-debugging/debugger-detection	function @ 0x408038
manipulate console buffer	host-interaction/console	function @ 0x407FDD
get common file path	host-interaction/file-system	function @ 0x401000
check if file exists	host-interaction/file-system/exists	function @ 0x409F40
get file attributes	host-interaction/file-system/meta	basic block @ 0x409F40
write file on Windows	host-interaction/file-system/write	function @ 0x40B801
find graphical window	host-interaction/gui/window/find	instruction @ 0x405514
get disk information	host-interaction/hardware/storage	function @ 0x40806A
terminate process	host-interaction/process/terminate	function @ 0x403EB6, 0x4050EC, 0x4060F8, 0x406BC1

CAPA Rule: Manipulate Console Buffer

Why CAPA triggered this=> Capa identified this behaviour because our malware imports and uses SetCOnsoleMode and SetConsoleCursorPosition. These APIs allow the program to modify the how the CLI pops up (ex. changing colors, clearing the screen, etc)
Confidence Level: High=> SetCOnsoleCursorPosition seems to be a very specific indicator of console manipulation. It is rarely imported unless the program specifically wants to control the CLI layout.
Possible False-Positive: Normal software like the normal CLI may also often use these APIs to create user-friendly text interfaces.

• CAPA Rule: Write File on Windows

Why CAPA triggered this => This rule was triggered directly by the presence of the WriteFile API. This seems to be a standard windows method for writing data to a file on a disk.
Confidence Level: High => if WriteFile is imported and used, the program has the capability to write data to the disk, so there is essentially zero ambiguity here.
Possible False-Positive: This is standard behavior for almost every legitimate software. By itself, this capability is neutral, however it can be malicious if the file written is a payload(like a virus).

CAPA Rule: Find Graphical Window

Why CAPA triggered this: .This was potentially triggered by GetDesktopWindow(retrieves a handle to the desktop window) or SetWindowPos (changes window size, position, tion or z-order). Malware often uses GetDesktopWindow as a start point to scroll through the windows on the computer.
Confidence Level: Medium => Even though the APIs give us a strong hint, they can also be used just to get screen dimensions.
Possible False-Positive: A screen recording app or a presentation tool can would also need these same permission to function properly.

5. Packing & Obfuscation

    Packing is the result of compressing or encrypting malicious .exe files. When malware gets packed, the file on the disk is not the actual malware, it is usually a wrapper. Packing is made possible by "packer" programs like UPX, which compress the data and add small pieces of code called stubs. Then, when the used double-clicks the packed file, the stub runs first. It decompreses the real malware into RAM and then hands control over it. Packing would essentially create high entropy (chaos) within the file, or said simply, make the file look like random noise mathematically.

    Obfuscation on the other hand is the process of making the code hard to read for humans. This doesn't mean changing what the code does; rather, it just makes it messy and confusing. This can be achieved when the author uses tools to rename variables to random characters and/or inserts dead code. This can impact static analysis severly, especially if we try to do string analysis since we just simply cannot tell whats going on without a blueprint.

    In order to see if we have Packing or Obfuscation, we need to run a DiE Entropy test.

Packer detection result

DiE → Check Advanced box -> Entropy

    As can be seen in the graph, the entropy never exceeds 7. Even though we were highly suspicious in the beggining that .data section was being packed by the VirtualAlloc API, with this graph we can see that its clearly not the case. However, we can assume that this API is either taking up a lot of space for no reason or its loading the batch and all commands into the RAM all at once.

Since the Confidence level is up at 76%, we can confirm with medium confidence that the .exe is not packed.

Overlay Presence

 

Everything that is attached to the end of the .exe file, that is not part of the .exe initial structure, is considered overlay presence. In our case, the file size for the .exe file was 93796 bytes, while the section data added up to 77824 bytes (we got it from PE Studio and PE Bear). To calculate we simply subtract the section data from the file size:

93796(file data) - 77824(section data added together) = 15972 (overlay is present)

TLS callbacks

TLS (Thread Local Storage) callbacks are a simple mechanism in Windows that allows a program to define functionts that are called when a thread is created. These functions are executed automatically before the main entry point, and are technique that is used frequently by malware when trying to bypass security mechanisms.

In our case, we do not have any TLS callbacks, which can be seen from the 1A8 offset in PE Bear, where both address and size of the TLS Directory have a 0 value.

Pe bear optional hdr, data

Required analysis

We can conclude that there is no packing in the malware because:

• DIE did not detect a packer with 76% certainity (medium confidence)
  
  

• PE-bear: “Not packed (76% certain)”
  
  

• Entropy: ~6 (normal)
  
  

• Code sections: Normal
  
  

• TLS: None
  
  

• Overlay: Present, but not encrypted
  
  

6. Behavior Mapping

According to the ATT&CK Tactic of MITRE, and all of the previous findings throughout this lab, we have come up with this table of behaviour mapping, crafted through Google Docs:

ATT&CK Tactic	Technique ID & Name	Supporting Evidence	Tool Source	Confidence Level
Discovery	T1082: System Information Discovery	Execution of start msinfo32 (OS/BIOS), start dxdiag (Graphics/Drivers), start perfmon (Performance), and start devmgmt.msc (Device Manager).	CAPA, manual .bat analysis.	High
Discovery	T1083: File and Directory Discovery	Execution of start cmd /k "tree C:\" to map drive structure and start cmd /k "dir /s" to list all subdirectories and files.	CAPA, manual .bat analysis	High
Discovery	T1010: Application Window Discovery	Confirmed by CAPA analysis; the executable itself contains logic for identifying active application windows.	CAPA	High
Defense Evasion	T1562 : Impair Defenses T1562.001: Disable or Modify Tools	Command netsh advfirewall set allprofiles state off is used to globally disable the Windows Host Firewall across all network profiles.	Manual .bat Analysis	High
Privilege Escalation	T1548 - Abuse Elevation Control Mechanism T1548.002: Bypass User Account Control	Registry modification of the EnableLUA value to 0 via reg add, effectively disabling User Account Control (UAC) prompts and restrictions, which is a critical change.	Manual .bat Analysis	High
Persistence	T1547 - Boot or Logon Autostart Execution T1547.001: Registry Run Keys / Startup Folder	Script sets a path to the user's Startup folder and utilizes the copy command to ensure prank.bat executes automatically upon user logon.	Manual .bat Analysis	High

Further supporting evidence:

    This is the part where we can encounter persistence in its true form. To achieve persistence, the script injects a command into the \Run directory of the HKCU, then it creates a string value labeled as SystemPrank, which then points to the malware's location. This technique lets the malware survive reboots by forcing Windows to launch the file directly at the startup runtime process

T1083 Technique -  File and Directory Discovery.

CAPA output.

MITRE ATT&CK — ATTACK NAVIGATOR

   Each technique listed is based in concrete evidence from both our manual .bat file inspection and the CAPA analysis. By focusing on the main logic of the malware, we have also verified that the identified behaviours are not speculative, but they are well-supported and documented. We believe that this dual-layered approach helped us to accurately capture all of the most severe threats to the system.

7. Key Findings and Conclusion

    Based on all 6 previous sections of the lab, which go through a detailed static analysis of win32update.exe, we can classify this malware with high confidence as a Trojan designed for discovery, defense ecasion and persistence. The malware's capabilities range from disabling the Windows Firewall (T1562.001) and User Account Control (T1548.002) to automating system-wide snooping. Ultimately, the lack of digital signatures and the presence of potential anti-debugging strings like GetTickCount solidify its status as a malicious tool intended to compromise host security and maintain long-term unauthorized access. These indicators also verify the file's status as a CNA threat, engineered to compromise the integrity of hosts by disabling critical security layers and ensuring persistent, disruptive control over the victim.