Rhadamanthys PDF file analysis – How attackers evade defences

Evalian’s SOC analysed a live phishing campaign using a weaponised PDF that bypassed standard controls. Inside it were embedded scripts, staged payloads and obfuscated PowerShell leading to the Rhadamanthys infostealer. By deconstructing each stage, the team identified all IoCs, mapped attacker TTPs to MITRE, and engineered detections to stop repeat attempts across all clients.

Attackers use multiple different methods while phishing to trick, deceive and most commonly steal user credentials to aid in future exploitation. A popular method attackers utilise is PDF documents, as these are commonly used when sending files between businesses – but they can hide malicious scripts inside them.

PDF files can use embedded scripts like JavaScript, embedded files, or exploits that take advantage of vulnerabilities in PDF readers. Attackers will use these elements to redirect users to harmful websites, download other malware, or compromise a user’s system. 

To demonstrate this, I will use this blog to explore a live phishing campaign that Evalian’s SOC identified. It bypassed standard enterprise security tools and checks, landed cleanly in inboxes, and aimed to install the Rhadamanthys info-stealer malware. 

I will demonstrate how I was able to deconstruct the attack to identify Indicators of Compromise (IoCs), and I will show you how analysing the attack methodology of this threat actor and the IoCs left behind by the attacker helped us build the right detections to continue to monitor and protect all our customers. 

Figure 1: Phishing Email Received

Infection Chain:

For the first step, I will collect the hash of the file and search for it on VirusTotal to see if any other vendors have reported it as malicious.

As I can see, this hash has been marked as malicious by 20 vendors, with most of them classifying it as a generic Trojan – subsequent payload analysis and overlap with known Rhadamanthys campaigns confirmed attribution. From the tags, I can also see that this PDF will perform some automatic actions, has JavaScript embedded and calls WMI via PowerShell cmdlets such as Get-WmiObject.

This is a legitimate tool used to gather information about hardware, software and system events, but can be used by malicious actors to execute malicious code.

Figure 2: VirusTotal Search Results

PDF Analysis

To analyse this PDF, I will be downloading it onto a virtual machine, disconnected from the internet, that has PDFid and PDF-parser installed. PDFid is used first to determine what is within the document.

It works by scanning the file to search for certain PDF keywords such as obj, JS and JavaScript. The presence of these within a document can indicate that it is potentially malicious.

Figure 3: Running PDFid

From this command, I can see that this file contains one occurrence of JavaScript, which is most likely the malicious payload. I will investigate this more using pdf-parser, another tool used to analyse PDF files and will identify the fundamental elements used.

To see what objects contain JavaScript, I ran the command:

pdf-parser.py -O invoice-1637482117.pdf

This expands the objects within the JavaScript, and from there, I searched through the output. The output showed that objects 2, 10, 14 and 18 contained what I needed to further analyse.

The figure below is a view of the objects that contain the JavaScript extracted into VS Code.

Figure 5: Malicious PDF File’s JavaScript

1.1 JavaScript Analysis

The script is split into different sections, most of which relate to formatting and showing alert boxes to the user.

Figure 6: Warning Message to User

The first alert box shown to the user contains a message, which, after a quick Google Translate, translates into “The player is not compatible! Please open it in your browser.” This is a fake warning not produced by the PDF viewer and is likely an attempt to move the user to a browser.

The next notable section defines another pop-up, but this time it contains a URL: hxxps://account[.]bo0king[.]co/#invoice-1637482117.pdf

Figure 7: Second Alert Box Shown to User

However, this is the name of the document we are currently viewing – which is interesting and visiting this URL in a sandbox environment downloads a .js file with the name invoice-1637482117.pdf.js – utilising a fake double extension to further deceive the user. I will aim to analyse this later.

Figure 8: Malicious JavaScript

The last part contains the interesting stuff – the malicious JavaScript payload. This script is partially obfuscated, assigning the various parts of the PowerShell command to individual variables, which are later called. The final command, once de-obfuscated and the commands expanded, is:

Figure 9: Formatted PowerShell Script

This command bypasses PowerShell execution policies, which will allow the script to run and force TLS 1.2 for HTTP requests. Alongside this, the second line will download the content from the URL – this is the core malicious action. The last line pauses execution for 9 seconds, likely to evade execution or ensure that the download completes. Visiting the URL within a sandbox browser redirects and returns a webpage filled with more PowerShell scripts. The final URL is:

hxxps://94fae730-597f-4442-813c-86263972a8f0[.]usrfiles[.]com/ugd/94fae7_2c7a859032924ae0aa0e819669ae9f3f.txt

Jumping back to the downloaded .js file “invoice-1637482117.pdf.js” in the screenshot below, I can see that they have filled the name with whitespace to hide the .js extension. This file contains the exact same script as within the URL hxxps://potalgonabunbunsed[.]blogspot[.]com/compac.pdf . This is likely for redundancy in the malware; an attacker will host the same payload under several paths so that if one is taken down or blocked, the other still works.

The hash for this file does not return any results on VirusTotal.

Figure 10: Invoice-1637482117.pdf.js

1.2 JavaScript Analysis

Figure 11: Obfuscated PowerShell Command

This script utilises a Caesar Cipher to shift ASCII characters by +3 to obfuscate malicious commands so that they are not immediately readable. De-obfuscating the script shows me the below:

Figure 12:De-obfuscated PowerShell Script

This script starts by stopping processes mshta, wscript and msbuild and then kills processes matching .bat or PowerShell modules. These processes are often used by security software to detect and prevent malicious behaviour.

After this, a large obfuscated decimal string is converted into text containing JavaScript and PowerShell that together make the payload.

Figure 13: Payload & Registering A Scheduled Task

This script also registers a scheduled task called “phuditaskhai” with a 30-minute random delay and adds an HKCU Run Key to start this task at login. HKCU is a part of the registry that contains configuration settings specific to the currently logged-in user.

Run is a subkey under HKCU where Windows looks for programs to automatically execute after that user logs in. This is to establish persistence.

The payload is then executed immediately via Invoke-Expression – the payload is the URL:

hxxps://hotelsep[.]blogspot[.]com/puddi.pdf

Once completed, the script file that launched this is deleted, and other script-like processes are slept and killed again.

Figure 14: Payload Executed & Processes Killed

To analyse this second-stage payload, I have split it into 2 parts.

Stage 1: Script Removal & Binary Reconstruction

The URL executed loads another page of PowerShell, again starting with a Caesar Cipher. This Cipher shifts the command by 3 letters to obfuscate it.

Figure 15: Caesar Cipher & Command

This command changes the PowerShell execution policy for the current PowerShell process to allow all scripts to run without restriction. The next part of the script starts by defining two .NET Framework directories to target. It then defines two variables $ex and $names:

• $ex: This is the name of processes not to stop (exceptions)
• $names: These are the names of processes targeted for termination.

The bulk of this part is to kill processes that live in either of the directories mentioned, unless the executable’s name is defined in the $ex variable as an exception. For every process, it checks:

• Does the process have an executable path?
• Is the directory of that executable exactly one of the directories defined in $f?
• Is the executable filename NOT in $ex?

If the process passes all these checks, then it is forcibly stopped by the ProcessID (PID). After this, Stop-Process is called for the list of processes in $names, excluding any in $ex. Finally, the script tries to close any processes whose process name matches “*.bat.exe” before waiting 5 seconds and closing the main window.

Figure 16: Ending Processes in .NET Directories

In the image below, I can see that a list of three directories is built – $env:APPDATA, $env:PUBLIC, and the user’s startup directory. These directories are then searched for the file extensions listed in the script, and it then attempts to force-delete each matched item. This process is repeated again, but for .vbs extensions within $env:PUBLIC, $env:APPDATA, and $env:ProgramData.

The last function inputs a string of comma-separated decimal numbers, converts that string into an integer array and then into a byte[]. The returned value is a byte array that represents raw binary data. If the caller then writes this byte array to disk, it will reconstruct a .exe file from the decimal representation.

Figure 17: File Removal & Decimal Bytes Conversion

Stage 2: Obfuscated String & RegSvcs.exe Injection

The second stage starts with a PE loaded stored in reverse order – $lora. The contents of the variable $PE area are also reversed, which is the malicious loader responsible for injecting the malware into RegSvcs.exe.

The malicious loader now stored in $data1 is loaded using PowerShell reflection, which allows you to inspect, invoke and access .NET type data. This is a common fileless technique used by malware to avoid detection. Next, the script builds a character array that turns into the string “A.B”, and another called “C”.

From this “$I.GetType(A.B)”, where $I is a System.Reflection.Assembly object, searches the loaded assembly for a type whose full name is “A.B” – this is assigned to $Y.

Next, the paths for RegSvcs.exe are defined and assigned to variables. RegSvcs.exe is the .NET services installation tool, which allows you to load and register an assembly, among other things.

Lastly, the method is invoked with those specific RegSvcs.exe paths and the final payload, which is now stored in $data2.

To end the script, the execution block is executed. After this, the script cleans up by spawning a separate PowerShell process to delete the script file after a short delay so that the file disappears from disk.

Figure 18: De-obfuscating String & Injecting Process into RegSvcs.exe

Hunting Queries:

With confidence in the program’s indicators and tactics, I moved to detection engineering. The goal is not to just stop the campaign, but to detect it whenever it might appear next. Below are two detection/hunting queries used to identify further attempts.

Script File Deletion:

Query Purpose: Detect when script files are mass-deleted from specific directories.

Mapped MITRE Techniques:

T1562.001: Impair Defences: Disable or Modify Tools: Detects when scripts are deleted or removed that security tools or response automation rely on.

Registry Key Addition:

Query Purpose: Detect when registry keys are added to a HKCU path alongside schtasks for persistence.

Mapped MITRE Techniques:

T1053.005: Scheduled Task/Job: Scheduled Task: Detects when schtasks is used for persistence to execute code on a schedule.

T1547.001: Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder: Detects when registry keys are added under HKCU for persistence.

Final Thoughts

The final PE hash, which was collected post-reconstruction, matched known Rhadamanthys samples reported in open threat intel sources. The infection chain observed is a multi-stage document/JS downloader: a malicious invoice PDF (invoice-1637482117.pdf) fetches a staged PDF (compac.pdf) alongside downloading a JavaScript downloader, which fetches a duplicate staged PDF script for redundancy (i.pdf) before calling the final stage PDF (puddi.pdf) and dropping the Rhadamanthys infostealer.

The campaign employs Ingress Tool Transfer to pull payloads, PowerShell / script interpreters to execute them, and multiple layers of obfuscation to evade detection. Public reporting ties Rhadamanthys to similar PDF/JS delivery chains.

This PDF analysis shows how phishing has evolved from obvious scams into sophisticated, scalable operations. Rather than crude HTML pages with spelling errors, attackers now embed JavaScript inside documents that spin up obfuscated PowerShell – this shift has major implications for SOCs.

Defending against these campaigns means moving from reactive blocking to proactive hunting. Only by combining telemetry-driven hunting, artefact pivoting, and ongoing user awareness can teams catch these polished, multi-layered attacks before they execute their payloads.

Indicators of Compromise (IOCs):

MITRE ATT&CK Mapping:

Additional resources

You may find the following blog useful: Building effective threat hunting queries for phishing

View Evalian’s Managed SOC Service