{"id":3243,"date":"2026-10-01T15:28:49","date_gmt":"2026-10-01T13:28:49","guid":{"rendered":"https:\/\/lab52.io\/blog\/?p=3243"},"modified":"2026-10-01T15:29:49","modified_gmt":"2026-10-01T13:29:49","slug":"backdoors-in-the-dungeon-turn-mqtt-abused-by-dragonforce","status":"publish","type":"post","link":"https:\/\/lab52.io\/blog\/backdoors-in-the-dungeon-turn-mqtt-abused-by-dragonforce\/","title":{"rendered":"Backdoors in the Dungeon &#8211; TURN &amp; MQTT Abused by DragonForce"},"content":{"rendered":"\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p>\u201cThere are paths that lead into darkness, and once you set foot upon them, the way back is never certain. Somewhere ahead, the dragon waits.\u201d<\/p>\n<\/blockquote>\n\n\n\n<p>One of the latest operations uncovered involving DragonForce is the abuse of legitimate TURN (Traversal Using Relays around NAT) servers to encapsulate communications between a malicious implant and the attacker\u2019s infrastructure.<\/p>\n\n\n\n<p>In this article, we provide information on two backdoors used by the attackers. While the first type is better known and can be linked to <a href=\"https:\/\/www.security.com\/blog-post\/dragonforce-msteams-backdoor\">Symantec\u2019s report<\/a>, the second type is notable for its use of MQTT as an additional communication channel in the event that communication through TURN fails.<\/p>\n\n\n\n<p>The first type has been observed during an initial deployment phase, while the second type corresponds to a backdoor that is expected to remain resident on disk, albeit protected.<\/p>\n\n\n\n<h1 class=\"wp-block-heading\">Backdoor 1 \u2013 TURN<\/h1>\n\n\n\n<p>The first backdoor is injected directly into memory. Its metadata name is <strong>Shell.dll<\/strong>, and it is a binary written in Go. To deploy this backdoor, the attackers use TURN, resolving the IP address of their C2 server directly in memory through decryption. Among its features, this backdoor retains the use of a private key for its SSH communications.<\/p>\n\n\n\n<p>The following diagram illustrates the deployment model. The attackers abuse legitimate Microsoft Teams TURN servers, thereby masking their traffic.<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"998\" height=\"664\" src=\"https:\/\/lab52.io\/blog\/wp-content\/uploads\/2099\/08\/d-e1790860816886.png\" alt=\"\" class=\"wp-image-3274\" srcset=\"https:\/\/lab52.io\/blog\/wp-content\/uploads\/2099\/08\/d-e1790860816886.png 998w, https:\/\/lab52.io\/blog\/wp-content\/uploads\/2099\/08\/d-e1790860816886-300x200.png 300w, https:\/\/lab52.io\/blog\/wp-content\/uploads\/2099\/08\/d-e1790860816886-600x400.png 600w, https:\/\/lab52.io\/blog\/wp-content\/uploads\/2099\/08\/d-e1790860816886-768x511.png 768w\" sizes=\"(max-width: 998px) 100vw, 998px\" \/><\/figure><\/div>\n\n\n<h1 class=\"wp-block-heading\">Backdoor 2 \u2013 TURN | MQTT<\/h1>\n\n\n\n<p>The second backdoor is used for persistence, as it is executed through a scheduled task left behind by a previous stage.<\/p>\n\n\n\n<p>In this case, it is loaded via DLL sideloading, abusing the legitimate <strong>javaw.exe<\/strong> executable, which loads <strong>jli.dll<\/strong>, the first-stage loader. This loader, in turn, loads <strong>rvsdiqw.txt<\/strong>, the next stage, which is encrypted with DPAPI to make the file dependent on the PC on which it is executed. Additionally, <strong>jli.dll<\/strong> will have a different hash on each system where it is executed.<\/p>\n\n\n\n<p>There is another <strong>jli.dll<\/strong> artifact with the hash <strong>6bbf10bcbef7ac5102b54c81137859891a3802dbacd888be90f990d50e18b0b4<\/strong> that can be directly linked to DragonForce through previous reports. That other artifact is different from the one used in this loader and is not included in this post, although it is already available on VirusTotal.<\/p>\n\n\n\n<p>Returning to the case at hand, the following diagram summarizes the observed deployment operation, identifying the TURN communication flow as well as an <strong>additional flow via MQTT for communication with the C2<\/strong>.<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"874\" height=\"1024\" src=\"https:\/\/lab52.io\/blog\/wp-content\/uploads\/2099\/08\/d-1-e1790861004137-874x1024.png\" alt=\"\" class=\"wp-image-3275\" srcset=\"https:\/\/lab52.io\/blog\/wp-content\/uploads\/2099\/08\/d-1-e1790861004137-874x1024.png 874w, https:\/\/lab52.io\/blog\/wp-content\/uploads\/2099\/08\/d-1-e1790861004137-256x300.png 256w, https:\/\/lab52.io\/blog\/wp-content\/uploads\/2099\/08\/d-1-e1790861004137-768x900.png 768w, https:\/\/lab52.io\/blog\/wp-content\/uploads\/2099\/08\/d-1-e1790861004137.png 999w\" sizes=\"(max-width: 874px) 100vw, 874px\" \/><\/figure><\/div>\n\n\n<p>Details of these communication flows are provided below.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">TURN Flow<\/h2>\n\n\n\n<p>The C2 communication flow over TURN first sends a request using the same protocol observed previously, with the following format:<\/p>\n\n\n\n<p class=\"has-text-align-center\"><strong>TRN1&lt;UUID:16&gt;22222222@@@<\/strong><\/p>\n\n\n\n<p>Next, the beacon generates a random 8-byte nonce using the <strong>BCryptGenRandom<\/strong> API and sends this value in a request with the following format:<\/p>\n\n\n\n<p class=\"has-text-align-center\"><strong>TRN1&lt;UUID:16&gt;33300000&lt;NONCE:8&gt;@@@<\/strong><\/p>\n\n\n\n<p>The binary then checks whether the received string is <strong>nocmd<\/strong>, indicating that there is no task for the beacon.<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"730\" height=\"262\" src=\"https:\/\/lab52.io\/blog\/wp-content\/uploads\/2026\/08\/image-20260730205948835.png\" alt=\"\" class=\"wp-image-3253\" srcset=\"https:\/\/lab52.io\/blog\/wp-content\/uploads\/2026\/08\/image-20260730205948835.png 730w, https:\/\/lab52.io\/blog\/wp-content\/uploads\/2026\/08\/image-20260730205948835-300x108.png 300w\" sizes=\"(max-width: 730px) 100vw, 730px\" \/><figcaption class=\"wp-element-caption\">Task existence notification message<\/figcaption><\/figure><\/div>\n\n\n<p>It then checks whether the message starts with <strong>[33300000<\/strong>. This indicates that a task is available. The beacon begins downloading data from the server, receiving a message containing an MD5 hash and the number of blocks to be received:<\/p>\n\n\n\n<p class=\"has-text-align-center\"><strong>[33300000&lt;Nonce:8&gt;&lt;MD5:32&gt;&lt;Count:4&gt;<\/strong><\/p>\n\n\n\n<p>After validating the nonce, the program sends a request to retrieve the files:<\/p>\n\n\n\n<p class=\"has-text-align-center\"><strong>TRN1&lt;UUID:16&gt;33299999&lt;NONCE:8&gt;@@@<\/strong><\/p>\n\n\n\n<p>The request is parsed by searching for the [ character. Each time one is found, the program attempts to interpret a record with the following structure:<\/p>\n\n\n\n<p class=\"has-text-align-center\"><strong>[&lt;NONCE:8&gt;&lt;INDEX:4&gt;&lt;MD5:32&gt;&lt;LENGTH:8&gt;&lt;SEPARATOR:1&gt;&lt;DATA:N&gt;]<\/strong><\/p>\n\n\n\n<p>After parsing the record, the code iterates through all expected indexes, checks whether any are missing, and validates the MD5 hash of each block. If a block is missing, it can be retrieved using the following request:<\/p>\n\n\n\n<p class=\"has-text-align-center\"><strong>TRN1&lt;UUID:16&gt;3320&lt;INDEX:4&gt;&lt;NONCE:8&gt;@@@<\/strong><\/p>\n\n\n\n<p>Once all blocks have been obtained, the program reconstructs the final package and validates its MD5 hash. Finally, it sends an acknowledgment message:<\/p>\n\n\n\n<p class=\"has-text-align-center\"><strong>TRN1&lt;UUID:16&gt;33100000&lt;NONCE:8&gt;@@@<\/strong><\/p>\n\n\n\n<p>The contents of the package are then Base64-decoded. The package has the following format:<\/p>\n\n\n\n<p class=\"has-text-align-center\"><strong>&lt;Value1:8&gt;&lt;XOR_Material:8&gt;&lt;Encrypted_Payload:N&gt;<\/strong><\/p>\n\n\n\n<p>A key is then derived by performing an XOR operation using the 8 bytes of <strong>XOR_Material<\/strong>, which is subsequently used to decrypt the code. Finally, the decrypted code is executed using <strong>CreateThread<\/strong>.<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"360\" src=\"https:\/\/lab52.io\/blog\/wp-content\/uploads\/2026\/08\/image-20260730232627270-1024x360.png\" alt=\"\" class=\"wp-image-3254\" srcset=\"https:\/\/lab52.io\/blog\/wp-content\/uploads\/2026\/08\/image-20260730232627270-1024x360.png 1024w, https:\/\/lab52.io\/blog\/wp-content\/uploads\/2026\/08\/image-20260730232627270-300x105.png 300w, https:\/\/lab52.io\/blog\/wp-content\/uploads\/2026\/08\/image-20260730232627270-768x270.png 768w, https:\/\/lab52.io\/blog\/wp-content\/uploads\/2026\/08\/image-20260730232627270.png 1084w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><figcaption class=\"wp-element-caption\">Thread creation<\/figcaption><\/figure><\/div>\n\n\n<p>The program also contains code that allows data to be sent from the beacon to the C2, but this functionality is only used during the initial handshake.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Sending Beacon Data to the C2 After the Initial Handshake<\/h3>\n\n\n\n<p>The beacon can upload data blocks with a maximum size of 930 bytes using the following format:<\/p>\n\n\n\n<p class=\"has-text-align-center\"><strong>[&lt;UUID:16&gt;&lt;TRANSFER_ID:8&gt;&lt;INDEX:4&gt;&lt;MD5:32&gt;&lt;LENGTH:8&gt;]&lt;DATA:N&gt;<\/strong><\/p>\n\n\n\n<p>Once all blocks have been generated, the beacon calculates the MD5 hash of the complete content and sends a request to initiate the transfer using the following format:<\/p>\n\n\n\n<p class=\"has-text-align-center\"><strong>TRN1&lt;UUID:16&gt;4440&lt;NUMBER_OF_BLOCKS:4&gt;&lt;TRANSFER_ID:8&gt;&lt;MD5:32&gt;@@@<\/strong><\/p>\n\n\n\n<p>After sending the request, the beacon waits 5 seconds and checks whether the response begins with the string <strong>NEXT<\/strong>. If a valid response is received, it performs another communication, waits 3 seconds, and then starts querying the transfer status using the following request:<\/p>\n\n\n\n<p class=\"has-text-align-center\"><strong>TRN1&lt;UUID:16&gt;4410????&lt;TRANSFER_ID:8&gt;@@@<\/strong><\/p>\n\n\n\n<p>The server can respond with the string <strong>DONE<\/strong> followed by the transfer identifier:<\/p>\n\n\n\n<p class=\"has-text-align-center\"><strong>DONE&lt;TRANSFER_ID:8&gt;<\/strong><\/p>\n\n\n\n<p>If any blocks are missing, the server can request their retransmission using a response with the following format:<\/p>\n\n\n\n<p class=\"has-text-align-center\"><strong>RESEND&lt;TRANSFER_ID:8&gt;&lt;INDEX:4&gt;<\/strong><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Command Summary<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><td>Command<\/td><td>Description<\/td><\/tr><tr><td>22222222<\/td><td>Initiates communication with the C2.<\/td><\/tr><tr><td>33300000<\/td><td>Checks for new tasks.<\/td><\/tr><tr><td>33299999<\/td><td>Requests the blocks of a task.<\/td><\/tr><tr><td>3320&lt;INDEX:4&gt;<\/td><td>Requests retransmission of a downloaded block.<\/td><\/tr><tr><td>33100000<\/td><td>Confirms the complete receipt of a task.<\/td><\/tr><tr><td>4440&lt;COUNT:4&gt;<\/td><td>Initiates a transfer from the beacon to the C2.<\/td><\/tr><tr><td>4410????<\/td><td>Queries the status of a transfer.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">MQTT Flow<\/h2>\n\n\n\n<p>In the case of MQTT, the program uses a similar protocol. After validating the timestamp received during the authentication process, the beacon generates a random 16-character string that acts as a session identifier. It then sends a message to the MQTT broker using the identifier stored in the sample\u2019s configuration as the topic.<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"591\" height=\"421\" src=\"https:\/\/lab52.io\/blog\/wp-content\/uploads\/2026\/08\/image-20260731005000662.png\" alt=\"\" class=\"wp-image-3255\" srcset=\"https:\/\/lab52.io\/blog\/wp-content\/uploads\/2026\/08\/image-20260731005000662.png 591w, https:\/\/lab52.io\/blog\/wp-content\/uploads\/2026\/08\/image-20260731005000662-300x214.png 300w\" sizes=\"(max-width: 591px) 100vw, 591px\" \/><figcaption class=\"wp-element-caption\">Random string generation<\/figcaption><\/figure><\/div>\n\n\n<p>The message contains only the previously generated session identifier:<\/p>\n\n\n\n<p class=\"has-text-align-center\"><strong>&lt;SESSION_ID:16&gt;<\/strong><\/p>\n\n\n\n<p>After completing the registration, the program queries the task-receiving topic using the system\u2019s UUID. If the server returns no content, or if the received response contains only the value <code>0<\/code>, the beacon assumes that there are no pending tasks and terminates the communication.<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"396\" height=\"210\" src=\"https:\/\/lab52.io\/blog\/wp-content\/uploads\/2026\/08\/image-20260731010356907.png\" alt=\"\" class=\"wp-image-3256\" srcset=\"https:\/\/lab52.io\/blog\/wp-content\/uploads\/2026\/08\/image-20260731010356907.png 396w, https:\/\/lab52.io\/blog\/wp-content\/uploads\/2026\/08\/image-20260731010356907-300x159.png 300w\" sizes=\"(max-width: 396px) 100vw, 396px\" \/><figcaption class=\"wp-element-caption\">Check for value &#8220;0&#8221;<\/figcaption><\/figure><\/div>\n\n\n<p>If a task is received, the program waits 3 seconds and calculates the length of the received message. It then Base64-decodes its contents using the <strong>CryptStringToBinaryA<\/strong> API. The decoded package has the following format:<\/p>\n\n\n\n<p class=\"has-text-align-center\"><strong>&lt;XOR_Material:8&gt;&lt;Encrypted_Payload:N&gt;<\/strong><\/p>\n\n\n\n<p>The beacon derives a one-byte key by XORing the 8 bytes of <strong>XOR_Material<\/strong>. This key is then used to decrypt the remainder of the package by performing an XOR operation on each byte of the encrypted content.<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"878\" height=\"201\" src=\"https:\/\/lab52.io\/blog\/wp-content\/uploads\/2026\/08\/image-20260731010552615.png\" alt=\"\" class=\"wp-image-3257\" srcset=\"https:\/\/lab52.io\/blog\/wp-content\/uploads\/2026\/08\/image-20260731010552615.png 878w, https:\/\/lab52.io\/blog\/wp-content\/uploads\/2026\/08\/image-20260731010552615-300x69.png 300w, https:\/\/lab52.io\/blog\/wp-content\/uploads\/2026\/08\/image-20260731010552615-768x176.png 768w\" sizes=\"(max-width: 878px) 100vw, 878px\" \/><figcaption class=\"wp-element-caption\">Busqueda de clave cmdnum<\/figcaption><\/figure><\/div>\n\n\n<p>After decrypting the message, the program checks that its contents begin with a JSON structure containing the <strong>cmdnum<\/strong> field. The check is performed by verifying that the string <strong>cmdnum<\/strong> appears starting at the third byte, meaning that the expected message has a structure similar to:<\/p>\n\n\n\n<p class=\"has-text-align-center\"><strong>{&#8220;cmdnum&#8221;:&#8230;}<\/strong><\/p>\n\n\n\n<p>After obtaining <strong>cmdnum<\/strong>, the beacon queries another MQTT topic to retrieve the metadata associated with the payload. This message differs from the task JSON and includes a 16-byte transfer identifier, the MD5 hash of the content, the number of blocks, and the total size. The received format is:<\/p>\n\n\n\n<p class=\"has-text-align-center\"><strong>&lt;TRANSFER_ID:16&gt;;TotalMD5:&lt;MD5:32&gt;;chnkNum:&lt;COUNT&gt;;totalSize:&lt;SIZE&gt;<\/strong><\/p>\n\n\n\n<p>The program then uses this identifier to generate the topics corresponding to each block, appending a four-digit decimal index:<\/p>\n\n\n\n<p class=\"has-text-align-center\"><strong>&lt;TRANSFER_ID:16&gt;0001<br>&lt;TRANSFER_ID:16&gt;0002<br>&lt;TRANSFER_ID:16&gt;0003<\/strong><\/p>\n\n\n\n<p>Each block is retrieved through a new MQTT request and concatenated with the previous blocks. If a request returns no content, the index is not incremented and the program requests the same block again.<\/p>\n\n\n\n<p>After downloading all the blocks, the beacon removes the headers delimited by the [ and ] characters. It then checks that the length of the reconstructed content matches the value specified in <strong>totalSize<\/strong>.<\/p>\n\n\n\n<p>After validating the content by calculating its MD5 hash, the package is Base64-decoded. The resulting data has the following format:<\/p>\n\n\n\n<p class=\"has-text-align-center\"><strong>&lt;XOR_KEY:8&gt;&lt;Encrypted_Payload:N&gt;<\/strong><\/p>\n\n\n\n<p>The decrypted content is an executable code template. Depending on the value of <strong>cmdnum<\/strong>, the JSON message is accompanied by different parameters that are inserted into the payload regions identified by a sequence of <strong>0xAA<\/strong> bytes. The following actions are performed according to <strong>cmdnum<\/strong>:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><td>cmdnum<\/td><td>Fields accompanying the command<\/td><td>Usage<\/td><\/tr><tr><td>1<\/td><td><strong>shk_url<\/strong>, <strong>tedByUID<\/strong><\/td><td>Inserts both values into the payload, separated by 256 bytes.<\/td><\/tr><tr><td>2<\/td><td><strong>ps_line<\/strong>, <strong>cmdid<\/strong><\/td><td>Inserts the PowerShell command line into the payload and copies 8 bytes of <strong>cmdid<\/strong> at offset <strong>5000<\/strong>.<\/td><\/tr><tr><td>3<\/td><td>None<\/td><td>Directly uses the payload without adding any parameters.<\/td><\/tr><tr><td>4<\/td><td><strong>rhost<\/strong>, <strong>rport<\/strong><\/td><td>Inserts the remote host and port into the payload, separated by 256 bytes.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>Finally, the program executes the payload by changing the memory region\u2019s protection using <strong>VirtualProtect<\/strong> and executing it via <strong>CreateThread<\/strong>.<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"629\" height=\"286\" src=\"https:\/\/lab52.io\/blog\/wp-content\/uploads\/2026\/08\/image-20260731015610108.png\" alt=\"\" class=\"wp-image-3258\" srcset=\"https:\/\/lab52.io\/blog\/wp-content\/uploads\/2026\/08\/image-20260731015610108.png 629w, https:\/\/lab52.io\/blog\/wp-content\/uploads\/2026\/08\/image-20260731015610108-300x136.png 300w\" sizes=\"(max-width: 629px) 100vw, 629px\" \/><figcaption class=\"wp-element-caption\">Thread creation<\/figcaption><\/figure><\/div>\n\n\n<p>If any of the communications fail, the beacon calls <strong>Sleep<\/strong> for 5 minutes and encrypts the contents of the memory region where it is executing in order to evade detection by security tools while it is inactive.<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"838\" height=\"431\" src=\"https:\/\/lab52.io\/blog\/wp-content\/uploads\/2026\/08\/image-20260730192011651.png\" alt=\"\" class=\"wp-image-3259\" srcset=\"https:\/\/lab52.io\/blog\/wp-content\/uploads\/2026\/08\/image-20260730192011651.png 838w, https:\/\/lab52.io\/blog\/wp-content\/uploads\/2026\/08\/image-20260730192011651-300x154.png 300w, https:\/\/lab52.io\/blog\/wp-content\/uploads\/2026\/08\/image-20260730192011651-768x395.png 768w\" sizes=\"(max-width: 838px) 100vw, 838px\" \/><figcaption class=\"wp-element-caption\">Encrypted memory region after calling Sleep.<\/figcaption><\/figure><\/div>\n\n\n<h1 class=\"wp-block-heading\">Conclusion<\/h1>\n\n\n\n<p>DragonForce is a ransomware-as-a-service (RaaS) operation that emerged around 2023 and has since evolved into a significant player in the ransomware ecosystem. Beyond its role as a conventional ransomware group, DragonForce provides infrastructure, tooling, and services that enable affiliates and other operators to conduct attacks against organizations. Recent activity associated with DragonForce also highlights a broader focus on maintaining persistent access and establishing resilient communication channels. In particular, observed operations have involved the deployment of multiple backdoors that abuse legitimate infrastructure, including Microsoft Teams TURN servers, to communicate with attacker-controlled infrastructure while blending malicious traffic with legitimate services. <\/p>\n\n\n\n<p>The backdoor analysed here also incorporate MQTT as an alternative communication channel, providing redundancy in the event that TURN-based communications fail. The observed tooling includes in-memory execution, DLL sideloading, scheduled-task persistence, encrypted payloads, and mechanisms designed to protect or conceal malicious code while inactive. This activity illustrates how DragonForce has expanded beyond the deployment of ransomware itself toward a more mature operational model combining access, persistence, custom tooling, and resilient command-and-control infrastructure. Over time, DragonForce has consequently evolved from a traditional RaaS model into what has been described as a \u201cransomware cartel,\u201d making it a particularly relevant case study in the evolution and professionalization of modern cybercrime.<\/p>\n\n\n\n<h1 class=\"wp-block-heading\">Intelligence Availability Notice<\/h1>\n\n\n\n<p>This article presents selected insights derived from our broader threat intelligence operations and coverage. Additional details related to this campaign, as well as other investigations and ongoing intelligence activities, are enriched and available through our private intelligence feed.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Indicators of Compromise (IOC)<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Artifacts<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><td>Name<\/td><td>Hash SHA256<\/td><\/tr><tr><td>jli.dll<\/td><td>f8eabae53e9dc8c529b6e38c58040ff28a07728cb5e896e16fb64e84bed5cd88<\/td><\/tr><tr><td>jli.dll<\/td><td>e9cd052f2d9514d40235ec04c9592f4274d0a4161b846e59bbb5a1a2c806a1c5<\/td><\/tr><tr><td>jli.dll<\/td><td>6bbf10bcbef7ac5102b54c81137859891a3802dbacd888be90f990d50e18b0b4<\/td><\/tr><tr><td>25vtps.txt<\/td><td>1657b22a553feae422dab77886ac60c06b8fad7cbd2cfaf482ba9066ba9922be<\/td><\/tr><tr><td>dldwuibjn_chShllcodeTrn.txt<\/td><td>5275579f539812ff66d060e12c9b7e99a22c625018f1aae9c5642ab0ba058ccb<\/td><\/tr><tr><td>dldwuibjn_chShllcodeTrn.bin<\/td><td>c91852bfb8f1d428875595c14cfada8fb234483adb8c6ba78ca2b5ae2a0683e2<\/td><\/tr><tr><td>rvsdiqw.txt<\/td><td>01d638ddd9d780e934305422bc9ee8fa3a5b3163ba66514ae5e5a34ff24df9db<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">Network indicators<\/h3>\n\n\n\n<p>hxxp:\/\/188.190.4[.]111\/25vtps.txt<br>hxxp:\/\/188.190.4[.]111\/dldwuibjn_chShllcodeTrn.txt<br>62.164.177[.]145:3478<br>217.156.8[.]181:7586<br>hxxps:\/\/accesscapfunding[.com\/wp-<br>content\/themes\/twentytwentyfour\/v4wwy9.php<br>hxxps:\/\/www[.paigeinfull[.com\/wp-content\/themes\/twentyeleven\/g5kq2b.php <br>hxxps:\/\/cncluxurywater[.com\/wp-content\/themes\/twentytwentythree\/wd9o9v.php<br>hxxps:\/\/printpro.com[.pl\/wp-content\/themes\/twentytwentytwo\/ghq4sk.php<br>hxxps:\/\/pymsolutions[.com.ar\/wp-content\/plugins\/easypost\/mn3fda.php<br>hxxps:\/\/whapido.com[.ar\/wp-content\/themes\/elessi-theme\/ze1edd.php<br>hxxps:\/\/prolabgest[.it\/language\/ove<\/p>\n\n\n\n<p><\/p>\n\n\n\n<p><\/p>\n","protected":false},"excerpt":{"rendered":"<p>\u201cThere are paths that lead into darkness, and once you set foot upon them, the way back is never certain. Somewhere ahead, the dragon waits.\u201d One of the latest operations uncovered involving DragonForce is the abuse of legitimate TURN (Traversal Using Relays around NAT) servers to encapsulate communications between a malicious implant and the attacker\u2019s [&hellip;]<\/p>\n","protected":false},"author":28,"featured_media":3250,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_genesis_hide_title":false,"_genesis_hide_breadcrumbs":false,"_genesis_hide_singular_image":false,"_genesis_hide_footer_widgets":false,"_genesis_custom_body_class":"","_genesis_custom_post_class":"","_genesis_layout":"","footnotes":""},"categories":[92],"tags":[],"class_list":{"0":"post-3243","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-ransomware","8":"entry"},"featured_image_src":"https:\/\/lab52.io\/blog\/wp-content\/uploads\/2026\/08\/ddbads-600x400.jpg","featured_image_src_square":"https:\/\/lab52.io\/blog\/wp-content\/uploads\/2026\/08\/ddbads-600x600.jpg","author_info":{"display_name":"3722304989","author_link":"https:\/\/lab52.io\/blog\/author\/3722304989\/"},"_links":{"self":[{"href":"https:\/\/lab52.io\/blog\/wp-json\/wp\/v2\/posts\/3243"}],"collection":[{"href":"https:\/\/lab52.io\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lab52.io\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lab52.io\/blog\/wp-json\/wp\/v2\/users\/28"}],"replies":[{"embeddable":true,"href":"https:\/\/lab52.io\/blog\/wp-json\/wp\/v2\/comments?post=3243"}],"version-history":[{"count":7,"href":"https:\/\/lab52.io\/blog\/wp-json\/wp\/v2\/posts\/3243\/revisions"}],"predecessor-version":[{"id":3277,"href":"https:\/\/lab52.io\/blog\/wp-json\/wp\/v2\/posts\/3243\/revisions\/3277"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/lab52.io\/blog\/wp-json\/wp\/v2\/media\/3250"}],"wp:attachment":[{"href":"https:\/\/lab52.io\/blog\/wp-json\/wp\/v2\/media?parent=3243"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lab52.io\/blog\/wp-json\/wp\/v2\/categories?post=3243"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lab52.io\/blog\/wp-json\/wp\/v2\/tags?post=3243"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}