Revisiting Stuxnet: Research Notes - Technical Analysis and Design Insights into the “hide files” mindset

 

Revisiting Stuxnet: Research Notes

Technical Analysis and Design Insights into the “hide files” mindset

 

 

“To understand the immeasurable, the mind must be extraordinarily quiet, still.”
— Jiddu Krishnamurti

 

 

Seeker(李标明) · @clibm079    

China · Independent Malware Analyst & Researcher 

From 2026.06.24 to 2026.06.30

---

Prologue: Curiosity-driven, keep moving

I took a short break from the last time when I had revisited stuxnet and made a record about the “~WTR4141.TMP: USB Loader as a userland rootkit”, and then to share serveral videos about “Practical Malware Analysis: Kernel Debugging with WinDbg” on YouTube before moving forward. If those videos from Lab 1 to 3 can help beginners who want to get the intuition from user mode to kernel mode, I think it’s nice, and the original thinking is still to record the stage of quiet exploration.

 

In this report, I will move to the rootkit driver MRXNET.SYS that has ability to hide malicious files on the compromised computer. The reason I did it was to help me gain a complete understanding of how it protects and treats itself as an advanced cyber weapon.

 

In the process of studying and preparing, thanks again to all reference stuff, and I mainly read Symantec’s and ESET’s reports to do static and manual debugging and expand my personal research.

 

 

 

 

 

 

 

Analysis Tools

#IDA, and #Windbg

 

Stuxnet

MRXNET.SYS: rootkit driver

 

The Design Flaw of the Userland Rootkit ~WTR4141.TMP

~wtr4141.tmp is a userland rootkit that uses IAT hooking to hide malicious files on a compromised computer; it prevents the file from being shown in a directory listing, but the file still exists. For example, you could copy the file “Copy of Shortcut to.lnk” using the DOS command. The file would not be hidden by dir.

Figure 1: The malicious files would not be hidden by dir.

 

 

Yes, from the above observation, the IAT Hooking is not a perfect solution for hiding malicious files; that’s why the kernel mode rootkit driver MRXNET.SYS, as an important part of the design, is involved in my revisiting research notes. Let’s do it.

 

 

 

The Rootkit Driver: MRXNET.sys

MRXNET is read from the main .dll’s resource and is written to disk as Mrxnet.sys; it can be created as a single kernel drive to hide malicious files by the command sc.

Figure 2: Create and start mrxnet by sc command.

 

 

What Kind of Malicious Files are to be Hidden

It hides as the userland rootkit ~WTR4141.TMP does by the specific design rule, like extension, size and mod operation, the two types are as follows:

1.      ".LNK" extension: size is 4.07 KB ( 4,171 (0x104Bh) ) bytes;

Figure 3: Hide files with specific LNK extensions and sizes.

 

 

2.      “.TMP” extension: “~WTR” as a prefix, and then four number and their sum module 10 is null. e.g., the file ~WTR4141.TMP, 4+1+4+1 mod 10. And size between 0x1000 (4Kb) and 0x800000 (8Mb).

Figure 4: Hide files with specific TMP extensions and sizes and mod operation.

 

 

How to hide malicious files on a compromised computer

The rootkit driver leverages IoRegisterFsRegistrationChange to monitor filesystem driver loading events (e.g., NTFS, FASTFAT, CDFS), and installs custom handlers in DriverObject->MajorFunction[IRP_MJ_DIRECTORY_CONTROL (0x0C)] to intercept directory enumeration IRPs, allowing modification of file listing results before they are returned to user-mode applications.

 

Figure 5-1: Snippet code for IRP dispatch hooking (MajorFunction).

 

 

When a breakpoint is set in the DriverNotificationRoutine and a USB storage device is plugged in, the callback is triggered as shown below.

Figure 5-2:Testing with a USB storage device.

 

 

Note: For more detail, please check out symantec’s report on page 24 and ESET’s reports on page 64.

 

 

The Screenshots Show the Hide-File Implementation

1.  Before Directory Enumeration Interception

Figure 6-1: The malicious files are present in the directory list.

 

 

2.  After Directory Enumeration Interception
The key point is: the rootkit intercepts the directory enumeration results returned by the filesystem, locates the target file entry, and uses the memmove function to modify the current directory buffer, preventing the target file from appearing in that enumeration.

Figure 6-2: The malicious files are hidden in the directory list.

 

 

The Userland Rootkit’s Design Flaw Had Been Fixed

The malicious files on the compromised computer when using the DOS command “copy” and “dir” that are displaying as “not found.” The above design flaw had been fixed when kernel mode rootkit MRXNET.SYS deployed.

Figure 7: Malicious files are not found with dir and copy.

 

 

A Simplified Flow for Hiding Files Mindset

From the above analysis process, the userland rootkit is ~WTR4141.TMP uses IAT hooking to hide malicious files on a compromised computer, but DOS commands can display them, and the kernel-mode rootkit MRXNET.SYS has the same ability to hide; at the same time, it fixes the desgin flaw perfectly.

 

The userland rootkit and kernel mode rootkit are a comprehensive solution, thinking and designing for hiding malicious files. The mindset model is to maximize the ability to “hide files” on each layer.

 

The following simplified hidden files mindset model doesn’t include complete details.

Figure 8: Simplified hiding files mindset model.

 

 

Here, since just the kernel mode rootkit can hide files very well, but why does it still need IAT hooking? In my personal view, it’s for more stealth and can strengthen the analysis of difficulty and time consumption and execution order thinking. Both have their place.

 

 

Observation on my personal perspective

From the process of analysis, the design, thinking, and mindset model are very rigorous. In addition, both IAT hooking and classical “hide files” tech are mature and proven technologies, not the most advanced at that time; maybe reliability and stability are considered high priorities.

 

Again, here it’s a very, very, very limited analysis and still incomplete and not covering all details; the analysis is my observation, not a conclusion. Especially Thanks to Symantec’s and ESET’s reports. Given my limited foundation, it’s hard to imagine the time and effort I would have needed to expand my research without their research findings, viewpoints, and sharing. For more technique details, please check them out.

 

And finally, in the process of analyzing, I used the tools #IDA and #Windbg, which helped me expand my observing and understanding from different perspectives. Thank you very much!

 

 

 

 

References

[1]. https://docs.broadcom.com/doc/security-response-w32-stuxnet-dossier-11-en

[2]. https://web-assets.esetstatic.com/wls/en/papers/white-papers/Stuxnet_Under_the_Microscope.pdf

 

 

 

 

Epilogue: What This Exploration Taught Me

1.      Computers are composed of layered structures, and the design of malware may involve multiple layers as a complete mindset model.

2.      To me ,one of the huge challenges is operating without knowledge of the layers, or without even recognizing that they exist.

Annotation: In all the sentences I wrote and used the word “you or your or yourself” in, it talked to me or “the malware sample itself, especially in my poem I did”, not the reader. I must clarify my motivation.

End of Report

──────────────────────

Seeker(李标明) · @clibm079    

China · Independent Malware Analyst & Researcher