Initial Static Analysis of a Suspicious svchost.exe Using Ghidra

May 17, 2026

When dealing with suspicious executables masquerading as system files, a careful static analysis phase is essential before jumping into behavioral tests. We recently looked at a rogue svchost.exe sample to demonstrate how to safely extract, import, and configure it for initial triage in Ghidra. Here’s a breakdown of the import process and the key analyzer options you need to set up for a smoother reverse engineering workflow.

When you spend enough time dissecting malware, you start to notice the recurring themes. One of the oldest tricks in the book is malware authors naming their payload after a legitimate Windows component to blend in with background noise. Recently, I spent some time statically analyzing a sample hiding behind a very familiar name: svchost.exe.

In this walkthrough, I want to take you through the very first steps of static analysis using Ghidra. We won't be diving deep into the assembly instructions just yet; instead, we are going to focus on the crucial preparation phase. Getting your environment set up, understanding the binary's basic properties, and configuring your analysis tools correctly can save you hours of headache later on.

Let's break down the process of importing and initially analyzing this rogue executable.

Safe Extraction and Initial Triage

The sample arrived neatly packaged in a password-protected ZIP archive—a standard industry practice to prevent accidental execution and to stop endpoint security software from neutralizing the file before we can look at it.

After extracting the archive using the standard infected password, the first thing I like to do before even firing up a disassembler is to get a high-level overview of what exactly I'm dealing with.

To do this, I dropped the extracted svchost.exe into Detect It Easy (DIE). If you aren't familiar, DIE is a fantastic lightweight tool that parses file headers to give you immediate context. In this case, DIE confirmed the file is a 32-bit Windows Executable (PE32) with a Graphical User Interface (GUI). Knowing the architecture upfront is a small but vital detail, as it dictates how we will approach the disassembly and what calling conventions we might expect to see.

Setting Up the Ghidra Environment

With the binary confirmed as a 32-bit PE file, it was time to move into our primary static analysis tool: Ghidra (version 10.2.2 running on Java 17, for those keeping track of environments).

I prefer to keep things organized from the start. Rather than dumping everything into a single massive repository, I created a dedicated, non-shared project specifically for this sample.

  1. From the Ghidra Project Window, go to File -> New Project.
  2. Select Non-Shared Project.
  3. Choose a dedicated directory. I set up a folder on the Desktop named GhidraProjects and named the project itself SVC_Host.

Keeping projects isolated like this is just good hygiene. It prevents cross-contamination of your notes, bookmarks, and symbol trees when you are juggling multiple investigations.

The Import Process and Metadata Review

Importing a binary into Ghidra is straightforward—you can simply drag and drop the svchost.exe file right into the active project window. Ghidra immediately parses the headers and correctly identifies the executable format as x86, 32-bit.

Once you confirm the import, Ghidra presents an Import Results Summary window. It can be tempting to just click "OK" and dismiss this box, but I highly recommend pausing to actually read what Ghidra has found. This summary is packed with vital intelligence:

  • Hashes: It automatically generates the MD5 hash of the file. You can immediately copy this and run it against your internal threat intelligence platforms or public sandboxes to see if it's a known commodity.
  • Timestamps: It provides the compile time and the date the file was last modified. While these can certainly be spoofed by malware authors, they are still a valuable data point for constructing a timeline of the threat.
  • Memory Layout: It shows the minimum and maximum memory addresses, giving you a quick sense of the binary's footprint.
  • Compiler Information: Identifying the compiler used can sometimes give you hints about the author's skill level or preferred development environment.

Tracking Down Dependencies: The ADVAPI32 Case

One of the most valuable pieces of information in the Import Summary is the list of external libraries the binary attempts to load. Ghidra noted that it searched 43 different paths looking for required libraries.

A prominent library flagged in this sample was ADVAPI32.dll.

If you are relatively new to Windows internals, ADVAPI32.dll (Advanced Windows 32 Base API) is a core operating system component. It handles highly sensitive operations—things like reading and writing to the Windows Registry, managing user accounts, and controlling system services.

When you analyze a binary statically, it is critical to distinguish between native system DLLs (like ADVAPI32.dll, KERNEL32.dll, or USER32.dll) and custom libraries that the program might have brought along with it. To demonstrate exactly where this lives, I navigated through the file explorer to C:\Windows\System32.

C:\Windows\System32\advapi32.dll

Finding this DLL natively in the System32 directory confirms it's a standard OS component. If an executable named svchost.exe is heavily leveraging ADVAPI32.dll, we can safely assume it will likely attempt to interact with the registry or perhaps try to install itself as a persistent system service—a classic persistence mechanism.

Launching CodeBrowser and Configuring Analysis

With the import complete, double-clicking the file in the project window launches the CodeBrowser tool (cue the familiar Ghidra dragon icon).

Because the binary is fresh, Ghidra will immediately prompt you: "svchost.exe has not been analyzed. Would you like to analyze it now?"

Clicking "Yes" brings up the Analysis Options window. This is another area where taking a few extra seconds can drastically improve your workflow. Ghidra has dozens of different analysis modules you can toggle on or off.

For this specific sample, I scrolled down to ensure one highly specific option was checked:

Windows x86 PE Propagate External Parameters

Why is this specific option so important? When Ghidra runs its auto-analysis, it tries to make sense of the assembly. By checking the Propagate External Parameters option, you are instructing Ghidra to go fetch the standard function signatures from those dynamic libraries (like the ADVAPI32.dll we just talked about) and apply them to the decompiled code.

Practically, this means that instead of staring at a generic function call with unnamed variables, Ghidra will automatically populate the decompilation view with meaningful comments and the correct expected parameters for standard Windows API calls. It turns a wall of incomprehensible instructions into something much closer to readable source code.

Running Auto-Analysis and Interpreting Warnings

After hitting "Analyze", Ghidra gets to work. You can monitor the progress in the bottom right corner of the UI as it cycles through decompiling functions, finding cross-references, and mapping out the binary's logic.

Once the progress bar finishes, an Auto Analysis Summary dialog usually appears. In this instance, Ghidra threw a few warnings and errors, which is entirely expected in our line of work.

The most prominent message in the log file was a warning stating it could not find an appropriate .pdb file.

PDB Universal Warning: Could not find an appropriate PDB file

A PDB (Program Database) file is essentially a roadmap of the executable, created by the compiler. It contains debug symbols—the original names of functions, variables, and source file paths that the developer used when writing the code.

If we had the PDB file for this binary, Ghidra would automatically rename all the cryptic memory addresses to things like InstallMalwareService or ConnectToC2.

Unsurprisingly, malware authors almost never ship their compiled payloads alongside their debug symbols. They intentionally strip this information out to make the reverse engineer's job as difficult as possible. So, seeing a "Missing PDB" warning isn't a failure of Ghidra; it's simply confirmation that we are looking at a stripped binary and we'll have to figure out the custom function names the hard way.

Wrapping Up the Triage Phase

At this point, the static triage phase is complete. We've safely unpacked the sample, identified its architecture, cleanly imported it into a managed Ghidra project, reviewed its cryptographic hashes and system dependencies, and configured the auto-analyzer to give us the best possible decompilation output.

From here, the real fun begins. The next steps would involve diving into the entry point, tracing how it utilizes those imported functions from ADVAPI32.dll, and ultimately mapping out its execution flow. But by taking the time to set up the environment methodically, we've laid a solid foundation for the deep dive ahead.

← All posts