AuraWiper

بسم الله، الحمد لله حمدًا طيبًا مباركًا يليق بجلاله وعظيم سلطانه، والصلاة والسلام على نبينا محمد ﷺ، الذي بلّغ الرسالة وأدّى الأمانة وجاهد في الله حق جهاده.

I'm Ahmed Allah Mohamed, aka 0x_V3n0m.

In this write-up, I'll walk through how I analyzed and solved the AuraWiper challenge on MalOps, uncovering the behavior of a destructive Windows wiper through static analysis and reverse engineering.

We'll begin by examining the PE structure, embedded PDB path, and imported Windows APIs. Then, we'll trace the malware's execution flow, identify its mutexes and persistence mechanisms, analyze its process-termination routine, and investigate its destructive payload — including MBR overwriting, deletion of critical Windows files, privilege manipulation, and the final hard system crash.

So, enough talking — let's dive into AuraWiper and see how this wiper attempts to leave a system completely unusable.

Q1 — What is the last part of PDB file path embedded in the malware sample?

Looking at the highlighted bytes, we can see that the sample contains a full path to a Debug Symbols file embedded within the PE at offset 0x5F264. The decoded text clearly reveals the following path:

1
C:\Users\prostone\Desktop\all\Malware-67-main\Release\SF-Verif.pdb

The .pdb extension confirms that this is a Program Database (PDB) path associated with the program's development and build process, rather than just an ordinary string.

Since the question asks for the last part of the path, we take the filename after the final \. Therefore, the answer is: SF-Verif.pdb

This path also provides some insight into the sample's build environment, including the project name Malware-67-main and the Release directory from which the sample was compiled.

Q2 — The wiper checks two mutex values in the main function. What are those values?

Looking at the main function, we can see two clear calls to the CreateMutexA API.

The first call creates a mutex named Global\SFV67PayloadLeader. Immediately afterward, the program calls GetLastError() and compares the result against the value 183, which corresponds to ERROR_ALREADY_EXISTS. This indicates that the sample is checking whether another instance of the payload is already running.

The second call creates a mutex named Global\SFVDeployOnce and performs the same check.

These mutexes prevent the malware's execution stages from being triggered repeatedly, helping AuraWiper ensure that both the payload and deployment stages are executed only once on the same machine.

Q3 — How many persistence mechanisms are implemented by AuraWiper?

Answer: 4

Looking at the thread setup, we can see that main initializes the function pointer sub_140015590 as the worker routine before executing it in a separate thread.

When we trace this routine, we can see that after passing the sub_140013690() validation check, it calls sub_140013E00(), which contains the actual persistence logic.

Inside this function, the malware opens the HKCU\Software\Microsoft\Windows\CurrentVersion\Run registry key and writes values using RegSetValueExA. It then repeats the same behavior with HKLM\Software\Microsoft\Windows\CurrentVersion\Run. It also constructs paths associated with the user directory and the Startup folder. Finally, it opens SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon and modifies the Shell value to ensure execution during the Windows logon process.

Therefore, AuraWiper uses four persistence mechanisms:

* HKCU Run

* HKLM Run

* Startup Folder

* Winlogon Shell

This gives the sample multiple opportunities to regain execution if one of the persistence mechanisms is removed or fails.

Q4 — What is the virtual address of the function responsible for terminating common system monitoring tools by process name?

Answer: 0x140011BE0

Looking at the pseudocode, we can see that sub_140011BE0 is the monitoring loop responsible for targeting monitoring and analysis tools.

The function is marked as noreturn and runs in an infinite loop. After each Sleep, it calls the helper function sub_140010570 with specific process names such as taskmgr.exe, ProcessHacker.exe, procexp.exe, procexp64.exe, and powershell.exe.

The helper function performs the actual process search and termination by name, while sub_140011BE0 manages the list and continuously repeats the operation. The function also uses OpenProcess and SetPriorityClass to raise the malware's own priority to REALTIME_PRIORITY_CLASS, making it harder for the user to stop the malware while the payload is being executed.

Q5 — How many times does AuraWiper invoke the process-termination function?

Answer: 8

Looking at the Xrefs to sub_140010570, IDA shows 8 call references to the function. Each one represents a direct call to the process-termination routine.

The first five calls are visible in the disassembly, each preceded by a lea rcx instruction that loads the process name into the first argument — including taskmgr.exe, ProcessHacker.exe, procexp.exe, procexp64.exe, and powershell.exe. The remaining Xrefs appear in the second part of the monitoring loop and target Windows Security-related processes.

It is important not to count the final .pdata entry, since it is exception-handling metadata, not an actual call instruction.

Q6 — What is the virtual address of the function that implements the wiper's destructive payload?

Answer: 0x140014E40

IDA shows that the procedure starts at address 0x140014E40, which is the address of AuraWiper's main destructive payload function.

The function does not immediately begin the destructive operations. It first hides the console using ShowWindow and FreeConsole, then opens the process's access token through OpenProcessToken. The most important part is the call to LookupPrivilegeValueW with SeShutdownPrivilege, followed by AdjustTokenPrivileges to enable that privilege.

These steps prepare the sample for the destructive operations that are executed afterward through worker threads — such as overwriting the MBR, deleting critical system files, and ultimately forcing the machine to crash.

Q7 — Which Windows privilege does AuraWiper attempt to modify?

Answer: SeShutdownPrivilege

AuraWiper opens the access token of the current process using OpenProcessToken. It then calls LookupPrivilegeValueW and passes the name SeShutdownPrivilege to resolve it into a LUID — the identifier Windows uses internally to reference privileges.

The sample then places this LUID inside a TOKEN_PRIVILEGES structure and calls AdjustTokenPrivileges, confirming that it is attempting to modify and enable the SeShutdownPrivilege privilege within its own token.

This privilege is associated with system shutdown operations and hard system errors, and its presence here prepares the malware for the final stage of the wiper, where it forces the machine to crash after carrying out its destructive actions.

Q8 — AuraWiper creates a registry policy key to prevent the user from terminating the wiper process. Which registry key is responsible for this?

Answer:

1
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System\DisableTaskMgr

The function sub_140011B50 uses RegCreateKeyExA to create or open the following registry key:

1
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System

It then immediately uses RegSetValueExA to write a value named DisableTaskMgr, setting its Data to 1 as a REG_DWORD. This value disables Task Manager for the current user, making it more difficult for the user to open Task Manager and attempt to terminate the malware process while the payload is executing.

Q9 — Which Windows API handles communication with the Media Control Interface?

Answer: mciSendStringA

Looking at the Imports window, we can see that the sample imports mciSendStringA from the WINMM.dll library. This API is responsible for sending string-based commands to Windows' Media Control Interface (MCI).

When we trace its usage, we can see that AuraWiper calls it inside a loop with the following commands:

1
set cdaudio door open
2
set cdaudio door closed

In other words, the malware repeatedly opens and closes the CD/DVD tray. This behavior is not essential to the wiping process, but rather serves as an additional nuisance behavior used by the malware to interfere with and distract the user while the payload is executing.

Q10 — What is the virtual address of the function responsible for displaying random strings?

Answer: 0x14000FC00

The function sub_14000FC00 starts at address 0x14000FC00. It prepares a Windows Hook using SetWindowsHookExW, then calls MessageBoxA to display a message to the user. The important part of the call is the lpText argument, because it is selected from an array at off_14005DCA8 using an index that operates with % 6 — meaning the selection rotates across six different strings. After displaying the message, the function calls UnhookWindowsHookEx to remove the hook.

Q11 — What is the offset address of the array containing the lpText values?

Answer: 0x14005DCA8

The lpText argument passed to MessageBoxA inside sub_14000FC00 points to the data address off_14005DCA8. When we navigate to this address, IDA displays an array of dq offset entries, where each entry is a pointer to a different string such as "67", "SIXTY-SEVEN", "SIX SEVEN", and "S I X T Y - S E V E N". The use of dq here is expected because the sample is 64-bit, so each pointer is 8 bytes. The function selects an element from this array and passes the pointer as lpText to MessageBoxA.

Q12 — What is the virtual address of the function responsible for overwriting the Master Boot Record (MBR)?

Answer: 0x140011AA0

The function sub_140011AA0 starts at address 0x140011AA0 and runs in a continuous loop. In each iteration it calls memset on a buffer of size 0x200 bytes with zero, then opens the path:

1
\\.\PhysicalDrive0

using CreateFileA. This path is not an ordinary file — it represents direct access to the first physical disk. The sample then calls WriteFile to write the zeroed buffer at size 0x200 (512 bytes) to the beginning of the disk. 512 bytes is the size of the first sector, which contains the MBR on legacy disks — overwriting it destroys the boot data and leaves the machine unable to boot.

Q13 — What is the virtual address of the function responsible for deleting key Windows system files?

Answer: 0x140011650

Looking at the Imports window, we can see that AuraWiper imports DeleteFileA from KERNEL32.dll. When we examine the Xrefs to this API, IDA shows that one of the code references comes from the function sub_140011650.

Inside this function, the malware calls DeleteFileA on a collection of critical Windows files, including boot-related files such as winload.exe and bootmgr, system files such as ntoskrnl.exe, as well as registry hives including SAM, SYSTEM, SECURITY, and SOFTWARE.

Targeting these files complements the MBR destruction process. Even if the disk were still capable of initiating the boot process, the essential boot and system files would have already been deleted, leaving the system unable to start properly.

Q14 — What is the name of the Windows Native API that AuraWiper uses to trigger a hard system error?

Answer: NtRaiseHardError

After AuraWiper creates a set of worker threads and waits using Sleep, it loads the ntdll.dll library. It then uses GetProcAddress to retrieve the address of the function named NtRaiseHardError at runtime.

This technique is known as dynamic API resolution — meaning the API does not necessarily appear directly in the sample's Import Table. NtRaiseHardError is a Windows Native API that the malware uses during its final stage to trigger a hard system error, ultimately forcing the machine to crash after completing its destructive operations.

Q15 — What hexadecimal value is passed as the ErrorStatus parameter to the native API that triggers the hard system error?

Answer: 0xDEADDEAD

Looking at the disassembly, we can see the instruction:

1
mov ecx, 0DEADDEADh   ; load ErrorStatus into ECX (first argument in x64 calling convention)

immediately before the call to the function whose address was dynamically resolved as NtRaiseHardError.

In Windows x64, the first argument to a function is passed through the RCX register. Using ECX here loads the same value into the lower 32 bits of RCX. Since the first parameter of NtRaiseHardError is ErrorStatus, this confirms that AuraWiper passes 0xDEADDEAD as the ErrorStatus before triggering the hard system error.

The choice of this value appears intentional — it is a distinctive and easily recognizable constant, forming part of the malware's final stage after the primary destructive operations have been completed.

Thanks a lot for taking the time to read this write-up — I hope it was helpful and easy to follow!

If I made any mistakes along the way, they're on me (or on Shaytan); any good in this write-up is purely from Allah.