Analysis of the Spear-Phishing and KakaoTalk-Linked Threat Campaign by the Konni Group 

◈ Key Findings

• Initial access was achieved through a spear-phishing email disguised as a notice appointing the recipient as a North Korean human rights lecturer.
• After the spear-phishing attack succeeded, the victim executed a malicious LNK file, resulting in infection with remote access malware.
• The malware remained concealed and persistent on the victim’s endpoint for an extended period, stealing internal documents and sensitive information.
• After gaining unauthorized access to the victim’s KakaoTalk PC application, the threat actor selectively chose contacts from the friend list for secondary distribution of the malicious file.
• The threat actor used North Korea-related lure content to deceive recipients and leveraged victims as channels for further distribution.
• This incident highlighted the need for an EDR-centered response framework to support behavior-based threat detection.

1. Overview 

Genians Security Center conducted an in-depth analysis of a malware distribution campaign by the Konni APT group that used North Korea-themed content as a lure.

The analysis confirmed that the threat actor attempted initial intrusion through a spear-phishing email disguised as a notice appointing the recipient as a North Korean human rights lecturer, and then induced execution of a malicious LNK file to install remote access malware, leading to the initial compromise.

[Figure 1-1] Overall Attack Flow

The threat actor remained concealed on the infected system for an extended period while stealing internal documents and sensitive information. The investigation also identified evidence that the actor gained unauthorized access to the victim’s KakaoTalk PC application and selectively used contacts from the friend list to distribute the malicious file in a secondary wave of attacks.

Notably, the actor used lure content in the form of a North Korea-related video proposal to deceive recipients and establish a trust-based propagation chain that leveraged existing victims as intermediaries for further attacks. This campaign is assessed as a multi-stage attack operation that extends beyond simple spear-phishing, combining long-term persistence, information theft, and account-based redistribution.

This threat intelligence report provides a systematic analysis of the attack’s tactics, techniques, and procedures (TTPs), focusing on the key technical artifacts identified in the Konni APT campaign, including the structure of the malicious LNK file, the persistence mechanism, the characteristics of remote access communications, and the abuse of messenger accounts.

It also underscores the need for an EDR-centered response framework supported by anomalous behavior correlation analysis to effectively detect account-based secondary propagation and malicious activity disguised as legitimate processes.

2. Background 

Konni APT has been observed carrying out persistent advanced attacks using targeted social engineering phishing tactics and a variety of intrusion techniques. In our January report on "Operation Poseidon," we noted that the group used spear-phishing that abused the click-redirection mechanism of legitimate advertising infrastructure in an apparent attempt to bypass email security filters and lower users’ guard.

Our November 2025 report also identified indications that the group employed "State-Sponsored Remote Wipe Tactics Targeting Android Devices." This suggests an objective beyond simple data theft, either to maintain control over compromised devices or to remove evidence, and shows that the group is expanding its attack surface beyond PCs into the mobile environment.

In the campaign analyzed in this report, spear-phishing emails were again used as the initial access vector. The attacker used a phishing message disguised as a notice appointing the recipient as a North Korean human rights lecturer to induce file execution. As a result, a malicious LNK file was executed on the victim system, leading to the installation of remote access malware and the initial compromise. The attacker then remained concealed on the victim system for an extended period while stealing internal documents and sensitive information.

A notable feature of this campaign is that, after gaining unauthorized access to the victim’s KakaoTalk PC session, the attacker used selected contacts from the victim’s friend list to redistribute the malicious file.

In doing so, the threat actor used lure content disguised as a planning topic for North Korea-related video content to capture recipients’ interest, effectively turning existing victims into new distribution channels.

Against this backdrop, this report offers a comprehensive view of Konni APT’s evolving tactics and analyzes the campaign’s technical characteristics, with particular focus on long-term persistence following spear-phishing, abuse of account sessions, and messenger-based redistribution mechanisms. It also presents practical defense strategies, including strengthening behavior-based detection and correlation analysis.

3. Attack Scenario 

3-1. Initial Access

In the initial intrusion stage, the primary attack vector was a spear-phishing email disguised as a notice appointing the recipient as a North Korean human rights lecturer. The attacker built trust by using content aligned with the recipient’s role and interests, then induced the recipient to open the attachment.

Analysis showed that the delivered archive contained a malicious LNK shortcut file disguised with the icon of a legitimate document. When executed, the file downloaded an additional malicious payload from an external C2 server. The LNK file abused the normal process execution flow to covertly load a malicious script or executable and, following initial infection, loaded malware into memory to enable remote access.

3-2. Persistence & Collection

Following the initial infection, the threat actor established persistence by registering scheduled tasks, creating startup entries, or masquerading as legitimate processes.

The actor then remained concealed on the infected system for an extended period while collecting internal documents, user account information, and system environment data. The collected data is believed to have been encrypted or encoded before being transmitted to an external server.

3-3. Messenger Abuse & Lateral Propagation

A key characteristic of this campaign is the threat actor’s unauthorized access to the victim’s KakaoTalk PC application and abuse of the active messaging session.

The actor selected certain contacts from the victim’s friend list and sent them additional malicious files. In doing so, the attacker used filenames disguised as materials introducing North Korea-related content to induce recipients to open the files.

[Figure 3-1] Distribution of Malicious Files via KakaoTalk

This approach enables trust-based propagation, helping the attacker bypass security solutions and lower recipients’ guard, while effectively turning existing victims into new vectors for further attacks.

3-4. Attack Flow Summary

This attack followed a multi-stage sequence consisting of: spear-phishing-based initial access, installation of remote access malware through execution of a malicious LNK file, long-term persistence and information theft, and secondary distribution of malicious files through abuse of the KakaoTalk PC session.

This represents a complex threat scenario that goes beyond a single infection by incorporating account-based propagation.

4. Detailed Analysis 

4-1. Analysis of the Malicious LNK File

The ZIP archive distributed through KakaoTalk Messenger contained a malicious shortcut-type LNK file.

The execution sequence and internal structure of the LNK file are shown below.

[Figure 4-1] Extracted Commands from the Malicious LNK File

• Launches 32-bit PowerShell (SysWOW64) through "cmd.exe"
• The PowerShell script identifies the LNK file itself based on its file size
• Decodes the hidden data block (0x1D79FB) embedded in the LNK file using XOR (0x3D), drops it as a PDF file, and executes it as a decoy
• Downloads files from the command-and-control (C2) server to "C:\Users\Public\Videos"
• C2 : drfeysal[.]com
• Establishes persistence through a Scheduled Task
• Executes the AutoIt script downloaded from the C2 server and performs additional malicious commands

The LNK file distributed via the messenger was made to appear as a "PDF document," but in reality it was a malicious shortcut designed to execute a PowerShell-based dropper with a single click.

When the user opens the file, Explorer makes it appear as though a document has been opened, while "cmd.exe" and PowerShell run in the background to prepare additional payloads and establish persistence.

Execution begins with "%windir%\system32\cmd.exe" as the entry point.

The LNK target is set to "cmd.exe", and its arguments include the "/c" option together with the 32-bit PowerShell path, "C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe".

In other words, the moment the user double-clicks the LNK file, it is configured to immediately execute a PowerShell script in the form of "cmd.exe /c powershell.exe -Command "<malicious script>"". The use of the "SysWOW64" path may indicate an attempt to ensure compatibility with the execution environment or to evade certain security controls.

The PowerShell script first locates itself, namely the LNK file, and then identifies it by its file size. It collects a list of "*.lnk" files in the current folder and selects only the item whose "Length" value matches the specific constant "0x001DBB82".

[Figure 4-2] Internal Structure of the Malicious LNK File

This value matches the actual size of the LNK file, 1,948,546 bytes, meaning the script can locate the file itself as long as the size remains the same, even if the filename is changed. If the file is not found in the current folder, the script switches to a path under "%USERPROFILE%\AppData\Local\Temp" and performs a recursive search.

Once the script identifies the LNK file itself, it opens the file in binary form and reads a large block of embedded data from a specific offset. Specifically, it reads 0x1D79FB bytes starting at file offset 0x1892.

This block is not embedded in plaintext, but is obfuscated using a simple XOR method. The script applies a fixed key, 0x3D, to the extracted byte array to decode it.

Notably, because the key stream is repeated as a single byte (slSize=0x01), the same XOR key is effectively applied to every byte, making this a very simple obfuscation scheme.

Once decoding is complete, the script writes the output to a file and immediately executes it. The output filename is created by removing only the ".lnk" extension from the original LNK filename. This is the point at which the user is led to believe that a legitimate document has been opened.

The decoded output is a document that begins with the PDF header ("%PDF") and serves as a decoy embedded within the LNK file. In other words, when the user clicks the LNK file, it appears that a PDF document has been opened, while PowerShell-based follow-on activity is already underway.

After launching the decoy document, the script proceeds to a cleanup stage intended to reduce traces. It deletes the original LNK file using "remove-item -force". As a result, the original LNK file disappears from disk immediately after the user opens it, a typical anti-forensics pattern designed to make user reporting and forensic acquisition more difficult.

The script then changes the working directory to "C:\Users\Public\Videos". This Public path is commonly used to drop follow-on files because it is easily writable even with standard user privileges.

It then downloads two files from an external C2 server. The C2 uses the WordPress-based domain "drfeysal[.]com" and serves the files through query-string requests under the "wp-admin/maint/treasure" path. A short delay of 100 ms is inserted between the download requests.

The first file downloaded is a legitimate AutoIt executable named "AutoIt3.exe". The second is a compiled AutoIt malicious script disguised as a document under the filename "APDNHFU.pdf".

Once the downloads are complete, the attacker establishes persistence.

The script creates a Scheduled Task configured to start one minute after the current time and repeat every minute thereafter.

The repetition period is set to 365 days, allowing the persistence mechanism to remain in place over the long term.

The execution action is configured to run "AutoIt3.exe" with "APDNHFU.pdf" as an argument, and the task is named "APDNHFU".

This configuration allows the malware to continue running at one-minute intervals even after a system reboot, providing a mechanism for maintaining persistence and carrying out additional malicious activity.

In summary, this LNK sample is a dropper/loader-type malicious shortcut that, while appearing to open a PDF document for the user, actually uses PowerShell to decode and launch a decoy PDF hidden within the LNK file itself, while also downloading an executable and an additional file from an external source and establishing one-minute persistence through a Scheduled Task.

Several aspects are particularly notable from an analysis perspective. Rather than relying on a hardcoded filename, the malware locates itself by file size. It also reads a large embedded data block from the LNK file based on a specific offset and decodes it using XOR. In addition, it deletes the original LNK file after infection to remove evidence.

From an IoC perspective, priority items for verification include access to "drfeysal[.]com", creation of "AutoIt3.exe" and "APDNHFU.pdf" under "C:\Users\Public\Videos", and creation of a Scheduled Task named "APDNHFU".

4-2. Structural Analysis of the File Disguised as a PDF

Although "APDNHFU.pdf" appears to be a standard PDF document based on its extension, its actual byte structure shows that it is not composed of document data. Instead, it is a disguised file containing AutoIt compiled script container data (A3X type).

Notably, this file is more than a simple extension-based disguise. Dummy data has been intentionally inserted into both the prefix and suffix, indicating that it was designed to interfere with static signature-based detection as well.

A HEX-level inspection first shows that the expected "%PDF-" signature of a legitimate PDF is not present at the start of the file. Instead, a substantial portion of the beginning of the file is filled with human-readable ASCII characters, but the content consists of meaningless random strings unrelated to PDF structure or document objects.

In fact, the range from 0x0000 to 0x270F is filled almost entirely with printable ASCII characters, and from the perspective of a PDF parser, this region cannot be interpreted as a meaningful document structure. From the threat actor’s perspective, this prefixed dummy data serves as an initial layer of disguise intended to conceal the file’s true identity.

This technique reduces the likelihood of detection by ensuring that the actual payload signature does not appear at the beginning of the file, especially when anti-malware programs or simple file classification logic rely on fixed magic values at the start of a file or on header-based identification. At the same time, the PDF filename makes it more likely that users will mistake the file for a document, while also creating potential for evasion in environments where email or web upload filters make decisions based on a combination of file extension and content type.

The core payload is then identified in the middle of the file. This file contains the string "AU3!EA06", an identifier observed in AutoIt compiled scripts, which strongly indicates that the file contains AutoIt script container or bytecode data rather than document data.

[Figure 4-3] Code Embedded in a File Disguised as a PDF

In the actual sample, the signature AU3!EA06 is identified at offset 0x2720, and from that point onward the file structure changes markedly, with the proportion of anomalous binary data increasing sharply rather than continuing as dummy content. This confirms that the file does not contain the PDF document body, but is instead designed to conceal an AutoIt container behind the dummy strings placed at the beginning of the file, as though it were the main body of the document.

When extraction and decompilation are performed from this point, AutoIt source code can be recovered at a level sufficient for analysis, providing technical support for the conclusion that the ".pdf" extension is merely a disguise unrelated to the actual file content.

The dummy data at the end of the file (suffix) serves as a second layer of disguise. The latter portion of the file is again structured to hinder analysis. The area from offset 0x543CA to EOF(0x56AD9) is filled with random strings composed largely of printable ASCII characters. This is effectively noise data, or padding, unrelated to the termination structure of a normal AutoIt container or any document format.

Taken together, "APDNHFU.pdf" is not a document implementing the PDF format, but a multi-layered disguised container that hides AutoIt compiled script data in the middle of the file and appends dummy strings to both the beginning and the end.

4-3. Analysis of the Malicious AutoIt Script

The analyzed file, "APDNHFU.pdf", was distributed as a file disguised as a PDF document, but internal structure analysis confirmed that it contains an AutoIt compiled script (A3X container).

Analysis of the source code obtained through decompilation showed that the file matches the operational structure of the EndRAT malware family that has been publicly reported.

EndRAT is a remote access trojan written in AutoIt. Despite its relatively simple implementation, it is known to provide an integrated set of RAT capabilities, including file management, remote shell access, data transfer, and persistence.

This sample also contains the same communication structure, command handling method, and internal function patterns.

• Identification of the Execution Structure and EndRAT Characteristics

• • In the initial section of the decompiled code, the following logic for creating a global mutex is observed:
    • "Global\B073W15Z-D8QD-87B1-7465-CE77A8819E701"

• • EndRAT-family samples repeatedly exhibit a pattern of creating a global mutex to ensure that only a single session is maintained per infected host, and this sample follows the same approach.
  • This design helps prevent network conflicts caused by multiple executions and supports stable maintenance of the C2 session.
    
    

• Analysis of the EndRAT C2 Communication Structure

• • Immediately after execution, the script creates a TCP socket and attempts to connect to a hardcoded server.
    • "185.21.14[.]249" [NL]

• • One of EndRAT’s defining characteristics is that it uses a custom socket protocol over HTTP port 80 without actually using the HTTP protocol itself.
  • The same pattern is observed in this sample. No HTTP request headers are present. Instead, string-based packet delimiters are used.

• • • "endServer9688"
    • "endClient9688"

• • This delimiter-based message handling is a communication pattern consistently observed in earlier EndRAT variants, and is intended to increase the likelihood of the traffic being mistaken for normal web traffic in IDS environments.
    
    

• Compromised System Registration (Beaconing)

• • Once the C2 connection is established, the script collects information about the compromised system and transmits it in JSON format.

• • This appears to be the initial beaconing stage, in which the threat actor registers the EndRAT-infected host with the management console. The system then enters a command-waiting state.
    
    

• File Manager Functionality

• • The script includes a file listing feature that allows the threat actor to remotely browse the file system of the compromised host.
  • Actual command handling is carried out through switch-case branching based on the "command" key in the JSON object, with file browsing functions mapped to the "refresh", "list", and "goUp" commands.
  • In the script’s command dispatcher, execution of the "refresh" command triggers a call to GETFILELIST().

• • Within GETFILELIST(), the script collects the list of drives through DriveGetDrive("ALL"), calls SCANDIRECTORY() for each drive to build a list of files and directories, encodes the result in JSON, and sends it to the C2 server.
    
    

• File Upload and Download Capabilities

• • The sample implements bidirectional file transfer capabilities commonly observed in the EndRAT family.
  • Within DOWNLOADPROCESS(), the script checks whether the target file exists and, if its size is below MAX_DOWNLOAD_SIZE (30 MB), reads the binary data and transmits it.
  • The transfer protocol signals the start of transmission with "FILE_START:", sends the file body as is, and marks the end with "endClientFile9688".

• • File upload is handled through the "command":"upload" case. After setting the "clientPath" and "fileName" values, the script switches to upload mode when the actual receiving function detects the "upLoad_Start:" marker.
    
    

• Remote Command Shell

• • The remote shell in this sample is not implemented through a simple StdinWrite/StdoutRead model, but as an interactive shell using Windows API pipe handles such as WriteFile, PeekNamedPipe, and ReadFile.
  • The remote shell session starts when the JSON object contains the "shellStart" key, and when "shellStop" is received, the script injects "exit\n" to terminate the session.
    
    

• Persistence

• • Persistence is established through Task Scheduler ("schtasks"), with the core mechanism involving creating a BAT file, writing the "schtasks" command to it, and then executing it in a hidden manner via "@ComSpec /c".
  • Rather than reusing the original script as is, the malware creates a new ".au3" file by inserting random garbage at the beginning and end of the original script data.
  • It then creates a randomly named BAT file under "C:\Users\Public\Videos", deletes any existing task, and registers a new one to run at minute-level intervals. The interval is determined by "Random(5,10,1)", resulting in a range of 5 to 10 minutes.

4-4. Analysis of Additional Malware Delivered via the C2

The threat actor is confirmed to have maintained persistent access to the victim system and remained concealed for an extended period after successfully gaining initial access through the first spear-phishing attack.

During this dwell time, evidence was identified that the attacker abused the KakaoTalk PC application installed on the infected system to distribute additional malicious files externally.

A detailed forensic investigation of the system found that multiple additional malware samples had been installed and were active on the host. The analysis also showed that the attacker abused the Windows Startup folder to establish persistence.

After excluding duplicate entries, a total of two malicious LNK shortcut files were found to be registered in the Startup path shown below. These LNK files were configured to execute AutoIt-based malicious scripts from hidden subdirectories under the "ProgramData" and "Public" paths.

<Startup Registration Path>

%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup

• Start_Web.lnk

• C:\ProgramData\NuGetPacks\AutoIt3.exe mmlib.au3

• SVC_Init.lnk

• C:\Users\Public\etaxSign\AutoIt3.exe cliconfg.au3
  
  

This configuration is a typical persistence mechanism that allows the malware to run automatically whenever the user logs on.

In addition to the Startup folder, the threat actor also hides and executes multiple malicious files disguised as legitimate programs under subdirectories of "ProgramData" in an effort to evade detection. Representative examples are listed below.

• C:\ProgramData\Casio\autoit.vbs
• C:\ProgramData\Casio\sqlite4.au3
• C:\ProgramData\Casio\svc.exe
• C:\ProgramData\Casio\taskhosts.exe
• C:\ProgramData\Startup\Spoolsv.exe
• C:\ProgramData\remcos\logs.dat
• C:\Program Files\RDP Wrapper
  
  

These files are distributed in forms disguised as legitimate software or system components and operate using AutoIt scripts and executables.

They serve either as loaders or droppers for additional malicious activity, or as intermediate components in an execution chain that loads and executes follow-on payloads in memory.

Analysis of the three identified AutoIt scripts revealed different RAT families, including EndRAT, RftRAT, and RemcosRAT.

The C2 infrastructure is assessed to use addresses distributed across multiple countries, including Finland, Japan, and the Netherlands.

This suggests a multinational distributed C2 operation designed to evade detection and maintain infrastructure resilience.

 [Table 4-1] Types and C2 Infrastructure by Malicious AutoIt Script

All three collected files use the AutoIt script extension ".au3", but analysis confirmed that they are not original script files, but compiled AutoIt executables.

Because compiled AutoIt files store the original script inside the executable in compressed or encrypted form, the actual script logic is difficult to inspect directly through standard static analysis alone.

Accordingly, accurately identifying the functions and behavioral flow of these files requires a decompilation process to recover the embedded script.

When decompilation is successful, it becomes possible to closely analyze the actual AutoIt code, hardcoded strings, C2-related information, additional payload download logic, and specific malicious behaviors such as conditional execution and anti-analysis techniques.

First, the "mmlib.au3" file was classified as a variant of the EndRAT family, and was found to contain the string "D:\3_Attack Weapon\Autoit\Build__Poseidon - Manage\client3.3.14.a3x".

This path closely resembles the one described in the Operation Poseidon report, but with one notable difference: the earlier label "Poseidon - Attack" has been replaced with "Poseidon - Manage".

This may indicate a change in the build environment or internal project naming.

[Figure 4-4] EndRAT Local Build Path String

The analyzed EndRAT AutoIt script contains hardcoded network configuration used to communicate with a C2 server controlled by the threat actor.

In the global variable section of the script, the C2 server IP address and communication port are explicitly defined, and the infected system is implemented to attempt a connection to the external server based on that information.

In the code, the C2 server address is set to "157.180.88[.]26", and the communication port is specified as "443".

Port 443 is commonly used for HTTPS traffic, and the use of this port suggests an attempt to disguise the communication as legitimate HTTPS traffic in order to evade detection by network security devices.

The script also defines a range of command strings used to remotely control the infected system through communication with the C2 server. Commands such as "cmd", "exit", "download", "upload", "listdir", "delete", and "run" are defined in the code, allowing the threat actor to start or terminate a command prompt on the infected system.

It also implements file upload and download capabilities, as well as functions to retrieve directory listings and delete specific files.

In addition, the script includes the ability to execute specific programs based on externally delivered commands, indicating that it is designed to allow the attacker to maintain continuous remote control over the infected system.

[Figure 4-5] EndRAT C2 Server Address

The EndRAT script also defines a mutex value to prevent duplicate execution of the same malware instance.

It is implemented to create a global mutex named "Global\78732E15-D8DD-03A1-7464-CE6398819E701", which allows the malware to check whether another instance of the same malware is already running.

This technique is commonly used to prevent multiple instances of the same process from running on a single system and to maintain stable C2 communication.

Next, the "cliconfg.au3" file does not store its internal configuration values in plaintext. Instead, it conceals key string data using a repeated-key string obfuscation technique based on SUB(subtraction) operations.

Static analysis showed that a specific decoding routine is called during program execution. That routine is implemented to perform byte-wise repeated operations using an encoded string stored in memory and a key value.

[Figure 4-6] RftRAT C2 String Decoding Logic

At the assembly-code level, the decoding routine is implemented as a loop that repeatedly applies SUB operations to each byte.

Within the loop, the routine first calculates the index into the key array based on the index of the string currently being processed.

This step is implemented using the x86 "div" instruction and is designed to use the remainder of dividing the loop index by the key length as the index into the key array.

The routine then loads the current byte of the encoded string and performs a SUB operation with the previously calculated key value to decode it.

[Figure 4-7] RftRAT C2 Decoding Result

In other words, the decoded output is produced by subtracting the corresponding value in the key array from each encoded byte, and the result is implemented to be written sequentially to a separate output buffer.

To verify the actual operation, we applied the same calculation to the encoded string and key values and confirmed that repeated SUB operations decode the obfuscated string.

The decoded string is used as a C2 server address in IPv4 format. Although this SUB-based string obfuscation method is relatively simple, it makes direct identification of network infrastructure information embedded in the malware difficult during static analysis.

In particular, by avoiding direct inclusion of plaintext IP addresses or URLs in the binary, it serves as a relatively simple obfuscation technique intended to evade string-based or signature-based detection.

The "sqlite4.au3" file, in turn, conceals a RemcosRAT binary within it.

[Figure 4-8] RemcosRAT Resource Structure

RemcosRAT stores its configuration data in the SETTINGS resource located under RCData in the PE file’s resource section.

This resource contains configuration data encrypted with the RC4 algorithm, and the RC4 key is stored within the data block with its size specified by the value in the first byte (0x99).

When the encrypted data following this key value is decrypted, it reveals a range of configuration information required for the malware’s main functions, including the C2 server address and port, the mutex value, the installation filename, and the keylogging log filename.

This structure is used to conceal the malware’s core configuration data within the executable, making analysis more difficult and enabling control over communication with the C2 server and malicious activity on the infected system.

[Figure 4-9] RemcosRAT Configuration Decoding Results and C2

5. Threat Attribution

5-1. Similar Cases of the Konni Campaign

Through a range of cyber threat intelligence analysis reports, Genians Security Center has continuously tracked the activities of the Konni campaign and accumulated cases and characteristics of the major cyber operations carried out by this threat actor.

These findings serve as important reference material for understanding campaign-level activity observed over an extended period, rather than viewing each incident as an isolated attack.

In particular, cross-case analysis comparing attacks conducted at different points in time is effective for identifying recurring patterns in the tactics, techniques, and procedures (TTPs) used by the threat actor.

This makes it possible to comprehensively analyze the relationships among various elements, including attack infrastructure design, malware development trends, and social engineering approaches, and ultimately to gain a clearer understanding of the consistency of the actor’s strategy and its operational objectives.

The major Konni campaign cases identified to date are as follows.

• Operation Poseidon: Spear-Phishing Attacks Abusing Google Ads Redirection Mechanisms
• State-Sponsored Remote Wipe Tactics Targeting Android Devices
• Analysis of Konni APT Campaign Disguised as Korean National Police Agency and National Human Rights Commission
• Expanded Analysis of Konni Threat Universe
• Analysis of defense evasion tactics using AutoIt in the Konni APT campaign
  
  

Through these various CTI analyses, Konni campaign activity has been continuously identified and should be understood not as a series of isolated incidents, but as part of a long-term and systematic operation.

In other words, technical analysis of individual intrusion cases alone is insufficient to fully explain the threat actor’s overall operational structure and strategy.

Against this backdrop, threat attribution serves as an important analytical element in assessing the actual threat level posed by the Konni campaign.

Threat attribution goes beyond merely identifying the party behind an attack. It helps build a comprehensive understanding of how the attack infrastructure is operated, which TTPs are repeatedly employed, how long-term operational patterns are maintained, and what strategic objectives ultimately underpin the activity.

This is especially true in the case of long-running state-sponsored threat actors such as the Konni campaign, where reliable attribution requires a comprehensive analysis of the technical characteristics and operational patterns that repeatedly appear across multiple attacks.

Such analysis provides important clues for identifying operational structures and attack intent that may not be clearly visible in individual incidents.

Threat attribution also has clear practical value from a security operations perspective.

A stronger understanding of a threat actor’s operational characteristics enables organizations to build more refined threat models, improve the accuracy of detection rules, and design more targeted threat hunting scenarios.

This provides a foundation for evolving security response strategies beyond short-term incident response and toward a sustained threat response framework.

Accordingly, analysis of the Konni campaign should move beyond fragmented technical analysis of individual attack events and instead adopt an attribution-focused perspective that takes into account campaigns conducted over different periods and threat intelligence accumulated over time.

This approach provides important insight into the threat actor’s strategic objectives and long-term operational direction, while also offering a meaningful basis for organizations to assess their threat landscape more realistically and set response priorities.

5-2. Threat Infrastructure Correlation

Analysis of the threat infrastructure indicates that this attack was carried out as an integrated operation combining distribution of malicious LNK files through KakaoTalk Messenger, use of multiple RATs including EndRAT, RftRAT, and RemcosRAT, and C2 infrastructure linked to external IP addresses in Europe.

In particular, the infection flow shown in the right-side cluster of the correlation diagram suggests a modular attack approach in which additional payloads are introduced sequentially after the initial intrusion, rather than a one-time deployment of a single malware strain.

[Figure 5-1] Threat Infrastructure Cluster Correlation Diagram

A notable point is that the RftRAT-related infrastructure connects to the cluster of earlier Konni campaigns on the left through the Japan-based C2 server "96.62.214[.]5".

This connection suggests operational continuity and possible reuse of network assets between the infrastructure identified in this campaign and previously observed Konni-related infrastructure.

In other words, the right-side cluster represents the core attack axis of the current activity, while the Japan-based infrastructure serves as a key correlation point linking it to earlier Konni operational infrastructure.

Taken together, the malware distribution method, RAT combination, external infrastructure layout, and the connection to earlier campaigns through the Japan-based C2 all indicate a high degree of similarity to previous Konni activity in terms of tactics, infrastructure, and operational approach.

Therefore, given the sufficient technical evidence of linkage, this threat activity is believed to have been carried out by the Konni threat group.

6. Conclusion

This threat begins with a spear-phishing email disguised as a notice appointing the recipient as a North Korean human rights lecturer, leading to initial compromise and the installation of remote access malware through execution of a malicious LNK file. It then develops into a multi-stage attack involving long-term persistence, information theft, and secondary propagation through abuse of the KakaoTalk session.

In particular, the attacker uses North Korea-related lure content to gain the recipient’s trust, then gains unauthorized access to the infected victim’s KakaoTalk PC application and redistributes malicious files to selected contacts from the friend list, thereby turning existing victims into intermediaries for further attacks.

This makes the threat particularly serious, as it goes beyond simple spear-phishing and represents a propagating APT attack that combines trust-based propagation with abuse of account sessions.

In addition, this campaign involved the staged use of multiple RAT families, including EndRAT, RftRAT, and RemcosRAT, and showed a pattern of continuously introducing additional payloads after infection through linkage with external C2 infrastructure.

Given these characteristics, the threat cannot be effectively addressed through single-file blocking or IoC-focused response alone. A multilayered defense strategy is required, one that considers the threat actor’s full range of TTPs, from initial access and persistence to information collection, messenger abuse, and secondary propagation.

6-1. Email and Initial Access Response

Organizations should enforce policies that minimize execution of attachments in spear-phishing emails using socially and politically sensitive themes such as North Korea, human rights, national security, and public institution notices.

Multi-stage execution formats, including LNK files, scripts, and executables contained in archive files, should be prioritized for inspection or quarantine. Where business necessity is low, organizations should consider restricting receipt of such file types.

User awareness training should also be strengthened to cover shortcut files disguised with document icons, attachments masquerading as official documents or notices, and file execution attempts that exploit trust in the sender.

6-2. Endpoint Behavior-Based Detection and Response

Because this threat abuses legitimate processes after LNK execution and sequentially loads additional payloads, static file-based detection alone has clear limitations in identifying variants.

Organizations should therefore use EDR to correlate and analyze behaviors such as abnormal process creation following LNK execution, script execution, scheduled task creation, Startup registration, external C2 communication, and the loading of malicious modules in memory.

In particular, detection policies should be refined to correlate not only isolated events, but also persistence and information-collection activity that occurs after a delay following the initial execution.

6-3. Response to Information Theft and Long-Term Persistence

The threat actor is assessed to have remained concealed on the infected system for an extended period after infection while collecting a wide range of data, including internal documents, user information, and system environment information.

Accordingly, organizations should strengthen behavior-based monitoring to detect access to sensitive documents, abnormal file collection activity, attempts to compress or exfiltrate large volumes of data, and information access patterns outside normal business hours.

Because this type of threat is designed for long-term persistence, forensic and threat hunting capabilities should be employed alongside one-time malware detection to track follow-on activity after infection.

6-4. Response to Messenger Session Abuse and Secondary Propagation

One of the key features of this campaign is secondary propagation through abuse of the victim’s KakaoTalk PC session.

Because this approach leverages the trust relationships of existing victims to drive further infections, it is difficult to mitigate through conventional controls focused solely on blocking external threats.

Organizations should therefore establish security guidelines for file transfers via messenger platforms and enhance their response posture to detect abnormal bulk transfers, repeated transmissions, and file-sharing patterns that differ from a user’s normal behavior.

Additional security reviews are also needed for endpoints used by key personnel and high-risk departments, including checks on messenger session protection, authentication status, and the protection of stored credentials and session artifacts.

6-5. Integrated Security Strategy Based on "Genian Insights E"

To effectively address threats of this kind, organizations need to move beyond static detection-centered response and adopt an endpoint security framework capable of behavior-based detection and blocking at the execution stage.

"Genian Insights E" is an integrated endpoint security platform built on a single-agent architecture to address a wide range of threats.

It provides EDR (Endpoint Detection and Response) for real-time behavior-based detection and threat response, Anti-Virus for signature-based malware detection and remediation, and Anti-Ransom capabilities that enable real-time blocking of file encryption activity as well as automatic backup and recovery of critical documents.

It also provides Device Control functionality to prevent internal data leakage by controlling the use of storage media such as USB drives and external hard disks.

In addition, it provides a response framework that combines IoCs (Indicators of Compromise), ML (Machine Learning), and XBA (behavior-based detection engine) to enable rapid detection and block threats such as APTs and ransomware at the execution stage.

Accordingly, it can serve as an effective defense against the attack flow identified in this report, including LNK-based initial access, the use of multiple RATs, long-term persistence, information theft, and secondary propagation through abuse of messenger sessions, by supporting detection and response based on actual behavior rather than relying solely on blocking individual IoCs.

[Figure 6-1] Identifying the Initial Intrusion Flow Based on EDR

The Attack Storyline feature in Genian Insights E makes it possible to visualize the attack flow step by step, from the download of an archive delivered through a spear-phishing email disguised as a notice appointing the recipient as a North Korean human rights lecturer, to execution of the embedded malicious LNK file, loading of follow-on remote access malware, and persistence-establishment activity.

[Figure 6-2] PowerShell Command Identification

In particular, the EDR’s behavior-based detection engine (XBA) can identify behaviors such as execution of the malicious LNK shortcut contained in the archive, subsequent PowerShell execution, abnormal process creation, invocation of additional payloads, and attempts to communicate with an external C2 as anomalous activity that deviates from normal user behavior.

This allows the threat to be detected and addressed in the early stages of the attack, before the overall attack flow fully develops, even when the threat actor deploys multiple RATs in sequence following LNK execution.

[Figure 6-3] C2 Communication Flow

Using the Attack Storyline, EDR administrators can perform the following response actions:

• Automatically or manually isolate endpoints suspected of compromise
• Collect evidence from, delete, and register IoCs for the malicious LNK file and related archive files
• Investigate the additional scope of compromise by reviewing the associated process tree, scheduled task creation activity, and external network connection data
• Conduct follow-up analysis of signs of messenger process abuse and secondary distribution activity

These capabilities go beyond isolated event-level detection and enable contextual understanding of the full attack flow, from spear-phishing-based initial access to LNK execution, RAT infection, long-term persistence, and secondary propagation through messenger abuse. This is effective in improving both analytical efficiency and response speed.

7. IoC (Indicator of Compromise)

• MD5

148405ff05bf15a6a053e4e7c1795d40

2e1b0ac49313873a0e0b982c591a5264

7dc50e8af0070e544bff5299405cd3b9

61f65bd593ea0e52ac0dfdc6bc9cd73a

461ade40b800ae80a40985594e1ac236

01022facb38cf60b052e65a682f4a127

3288c284561055044c489567fd630ac2

• C2

drfeysal[.]com

185.21.14[.]249

157.180.88[.]26

96.62.214[.]5

178.16.54[.]208