03/24/2026

When Malware Talks Back: Real-Time Interaction with a Threat Actor During the Analysis of Kiss Loader

Real-Time Interaction with a Threat Actor During the Analysis of Kiss Loader Techblog

The author was actively developing a loader referred to as “Kiss Loader,” which, at the time of analysis, had not been previously observed and appears to be a newly developed tool representing a potential emerging threat. It employs techniques such as Early Bird APC injection, among others. The experience was both thrilling and remarkable, as the line between analyst and adversary briefly blurred. Before delving into this unusual encounter, it is important to first examine the sample that led us there. 

Technical Analysis Overview

To simplify the behavior of the sample, I mapped the execution into a multi-stage flow, as illustrated in Figure 1. The diagram highlights the key phases of execution. 

Initial Access and WebDAV Delivery

The infection begins with a Windows Internet Shortcut file (DKM_DE000922.pdf.url) that triggers execution and connects to a remote WebDAV resource hosted through a TryCloudflare tunnel. TryCloudflare is a Cloudflare service that creates temporary public tunnels to locally hosted services without requiring domain registration or dedicated infrastructure. This enables the attacker to dynamically host and modify payloads. 

Execution Trigger and Script Execution

Among the files in the WebDAV directory is a secondary shortcut (DKM_DE80KS0095283.pdf.url), disguised as a PDF document, which requires user interaction to execute. One triggered, this shortcut launches a WSH script that chains into a JScript component. This layered execution flow enables controlled staging of the payload while minimizing direct exposure of later stages. 

Payload Retrieval and Staging

The JScript component retrieves and executes a batch script responsible for orchestrating the next steps. This includes displaying a decoy PDF to the user, establishing persistence by placing a batch script in the user’s Startup folder, and downloading additional payload components. 

Loader Deployment, Shellcode Decryption and Execution

The retrieved archive contains a Python-based loader, identified by the threat actor as “Kiss Loader,” which is deployed to decrypt payloads. Decryption keys are sourced from JSON configuration files, allowing the payload to remain concealed until runtime. The shellcode was generated using Donut, an open-source tool that produces position-independent shellcode for in-memory execution of .NET assemblies. To expedite analysis, I utilized a dedicated Donut decryptor and extractor, enabling me to recover the embedded payloads from the BIN files. One of the payload was identified by our system as VenomRAT, which also resembles an AsyncRAT variant (See here, as well as one of our earlier articles on AsyncRAT), while the other was a .NET Reactor–protected utility. These components are subsequently prepared for execution, and this stage represents the transition from staging to active compromise. 

Process Injection

The final execution is achieved through injection into a legitimate process (explorer.exe) using an Early Bird APC technique, as shown in Figure 2. The loader creates the target process in a suspended state, preventing its main thread from executing immediately. It then allocates memory within the target process with executable permissions and writes the decrypted shellcode into the allocated region.

Instead of creating a new thread, the loader queues an Asynchronous Procedure Call (APC) to the primary thread of the suspended process.

Upon resuming the thread, the queued APC is executed before the process begins normal execution, allowing the injected shellcode to run under the context of a trusted process, thereby enhancing stealth and evading detection. 

Key Observation

Both the supporting infrastructure and associated scripts of Kiss Loader were still under development at the time of analysis. The exposed WebDAV directory lacked access restrictions, which allowed me to directly enumerate and retrieve its contents. I also observed that the files were recently deployed, as I first identified them on March 10 (see Figure 3). 

Additionally, the scripts, particularly the “Kiss Loader,” exhibit clear signs of ongoing development. This is evident from the inclusion of testing utilities and helper functions intended for validating payloads and simulating execution scenarios (see Figure 4). 

The code also contains extensive inline comments that describe key routines such as decryption and process injection, providing step-by-step context for logic. The level of detail in these comments may suggest the use of automated assisted code generation during development (see Figure 5). 

Moreover, the loader produces verbose execution output, displaying detailed runtime information such as payload loading, decryption status, process creation, and injection steps. This level of output is typically associated with testing or debugging phases (see Figure 6). 

My encounter with the Threat Actor

Since the resources hosted on WebDAV were still live and accessible, I executed the shortcut file within a controlled analysis environment to simulate its intended behavior and observe the overall execution flow. Using the parameters specified in the batch script, I proceeded with decrypting the embedded shellcode. While attempting to dump the decrypted payload, something immediately felt off. The command prompt suddenly terminated, followed by the abrupt shutdown of the analysis tools I had open: Notepad++, Process Explorer, and System Informer.

Then the cursor started moving on its own. I attempted to reopen the command prompt, but each attempt was instantly shut down. At that moment, I paused, took my hands off the keyboard, and even raised them to confirm that I was not interacting with the system. The cursor continued to move, clearly indicating that the behavior was not user-initiated. That realization was both notable and unexpected. Since this was my first time encountering “Kiss Loader,” I was driven to learn more about it and validate whether the observed activity was merely incidental or the result of deliberate remote access.

To test this, I re-executed the sample within the same controlled environment and left a Notepad window open containing a simple message: “Hello! Are you the author of this malware?”

I let the system run.

After roughly an hour, a response appeared, as shown in Figure 7. 

The message was brief and informal, but it confirmed what I had suspected. The system was being actively accessed. What followed was an unexpected exchange. The individual on the other end appeared curious, even conversational, asking about my tools and whether I was an analyst. At one point, he acknowledged the nature of his own work, referring to it simply as “the malware,” and admitted to developing it in different forms while experimenting with various techniques.

As the conversation progressed, I steered it toward technical details. When asked about the injection method, the threat actor identified it as “early bird injection,” aligning with my prior analysis of the loader’s behavior. The discussion also revealed that the malware was still under development, reinforcing earlier observations from both the infrastructure and the code itself.

It is rare to engage directly with a threat actor during active development, and even rarer to receive confirmation of specific techniques in real time. The exchange was short. After a few responses, the threat actor stopped replying and did not reconnect in subsequent attempts. Still, the encounter left a lasting impression. 

Conclusion

We often study malware as artifacts, reduced to data points for detection and correlation. But behind every command and connection is a human who observes, adapts, and sometimes reveals more than intended. This case shows that analysis is not always one-sided. The boundary between analyst and adversary can become unexpectedly thin, turning observation into interaction.

Beyond the technical findings, this reinforces a key principle: analysis must remain within a controlled and isolated environment, as demonstrated in our handling of this case. We are not only analyzing code; at times, we are confronting the individuals behind it. 

IoC List

6abd118a0e6f5d67bfe1a79dacc1fd198059d8d66381563678f4e27ecb413fa7 

DKM_DE000922.pdf.url 

e8f83d67a6b894399fad774ac196c71683de9ddca3cf0441bb95318f5136b553 

oa.wsh 

549c1f1998f22e06dde086f70f031dbf5a3481bd3c5370d7605006b6a20b5b0b 

ccv.js 

6d62b39805529aefe0ac0270a0b805de6686d169348a90866bf47a07acde2284  

gg.bat 

b4525711eafbd70288a9869825e5bb3045af072b5821cf8fbc89245aba57270a 

pol.bat 

e8dbdab0afac4decce1e4f8e74cc1c1649807f791c29df20ff72701a9086c2a0  

vwo.zip 

5cab6bf65f7836371d5c27fbfc20fe10c0c4a11784990ed1a3d2585fa5431ba6 

so.py 

20a585c4d153f5f551aaa509c8c1fa289fa6f964fe53f241ef9431a9390b3175  

tv.bin 

6a7c3029cd4f7ffe9a24ea5d696e1f612ada91b5a5ca5b28d4972d9c772051fd  

t.json 

665f44b5a46947ad4fdac34a2dca4cf52b3e7e21cfa3bd0fc3ef10bd901ad651  

ov.bin 

b3737f621eb2ee6d784a6b9d695b890a5f22ee69e96058c99d9048b479451fbd 

a.json 

130ca411a3ef6c37dbd0b1746667b1386c3ac3be089c8177bc8bee5896ad2a02  

decrypted ov.bin (VenomRAT) 

2b40a8a79b6cf90160450caaad12f9c178707bead32bcc187deb02f71c25c354 

decrypted tv.bin (Kryptik)