{
	"id": "3b456b26-73f5-48da-9352-e0680ff09971",
	"created_at": "2026-04-06T00:17:59.203427Z",
	"updated_at": "2026-04-10T03:37:22.726319Z",
	"deleted_at": null,
	"sha1_hash": "5f9c7afb1a194085da42eea82c7560f2a6033de5",
	"title": "A Deep Dive Into SoWaT: APT31’s Multifunctional Router Implant",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2046833,
	"plain_text": "A Deep Dive Into SoWaT: APT31’s Multifunctional Router\r\nImplant\r\nPublished: 2021-11-25 · Archived: 2026-04-05 19:07:10 UTC\r\nExecutive Summary\r\nAPT31 is long known to use Operational Relay Boxes (ORBs) and compromise routers.\r\nThis report examines in detail their only publicly known router implant, dubbed “SoWaT”\r\nThe implant is capable to function as RAT, a tunnel and a proxy.\r\nExtensive verification and double-encryption procedures signal a TA trying to evade even the most capable\r\ndefender\r\nThe implant’s code reveals a long development history, most likely over several years\r\nIntroduction\r\nAPT31\r\nAPT31, aka Zirconium, is an interesting Chinese threat actor, operating almost separately any other Chinese TA.\r\nThe group is targeting various types of targets of interest to the Chinese government. Notably, the group has been\r\nsubject to several governmental attribution statements, including Germany, France, Norway, Australia.\r\nAPT31 Timeline, taken with permission from sekoia.io\r\nSekoia published on the 10/11/21 a great report expanding on previous report by the French ANSSI, The timeline\r\nabove was copied with permission from them.\r\nIt is long known that APT31 is using ORBs (Operational Relay Boxes) for their network operations, specifically\r\nhacked routers. Still, there is no public research into how they are operate those ORBs. With this reports I try to\r\nshed some light into the groups capabilities on network devices and potential detection and prevention options.\r\nhttps://imp0rtp3.wordpress.com/2021/11/25/sowat/\r\nPage 1 of 19\n\nSoWaT checking how far off the clock is\r\nSoWaT\r\nThe implant, I dubbed “SoWaT” because of its use of the custom file called “swt”, is an ELF file for 32-bit MIPS\r\nbased processors. According to the research done by Sekoia, it was most likely used for Pakedge routers, as they\r\nrepresent the vast majority of attacked routers and often run a Linux based OS on MIPS32 processors.\r\nThe implant was first mentioned in a tweet by billy leonard as a router implant found by google TAG team and\r\nwas attributed to APT 31. Sekoia reaffirmed that attribution in their report.\r\nAccording to the upload time (Nov. 2019) and compilation information of the sample, it was most likely compiled\r\nduring the fist half of 2019. The compilation used the February 2019 version of cross-compilation tool Buildroot.\r\nExecution Flow\r\nTLS Server and Client\r\nhttps://imp0rtp3.wordpress.com/2021/11/25/sowat/\r\nPage 2 of 19\n\nSoWaT communicates with the attacker using TLS, where it can function as a client or as a server, If the implant\r\nhas a command line argument it start a server on the port given. Regardless of that, it tries to connect to a list of\r\nservers specified in its encrypted configuration (See Configuration File) every hour.\r\nSome functions of the implant can only be run if the implant is in server mode.\r\nIn both modes, the implant uses certificates and keys parsed from “swt” (See swt). The CA keys to the chain to\r\nauthenticate the attacker and uses the public and private key for its own.\r\nWhen SoWaT works as server, it sends a Client certificate request, accepting only connections client certificates\r\nby the CA from “swt”.\r\nIf it attempts to connect as client, it expects the server to send a client certificate request and in response it verifies\r\nitself using the private key in “swt”\r\nAll components of the TLS connection are implemented by the popular library mbedtls. The specific settings of\r\nSoWaT cause the connection to have a unique JA3 and JARM signature, see IOCs.\r\nCommand Loop\r\nInterestingly, The main execution function of SoWat isn’t exclusively used to execute command from the attacker\r\nbut also called from withing the implant itself. This way complicates understanding . Functions in bold are\r\nfunction which were most likely intended to be used by the attacker.\r\nAfter the TLS connection is successful, SoWaT waits for commands.\r\nAny message needs to have the following basic structure:\r\nCommand Message Univerval Structure\r\nAll Network protocol structures from here forward are in big endian.\r\nAccording to the Message size, the implant allocates data and waits for all the data before executing the command.\r\nThe are 16 possible commands:\r\nFunction num. Description\r\n0 connect to the servers detailed in the configuration\r\n1 Unkown, most likely internal functions\r\n2 Unkown, most likely internal functions\r\n3 Connect to new server with new certificate\r\nhttps://imp0rtp3.wordpress.com/2021/11/25/sowat/\r\nPage 3 of 19\n\n4 Unkown, most likely internal functions\r\n5 start proxy functions\r\n6 query proxy port\r\n7 run RAT\r\n8 reconnect again to Servers in configuration\r\n10 Write current connection IPs to “config” file\r\n11 Get information about all current TLS connections\r\n12 Unkown, likely internal functions\r\n13 Unkown, likely internal functions\r\n15 Update Count of hours without connection\r\n16 Exit process\r\n17 If functions as server, delete all and exit process\r\nFunctions in bold are also called by the implant itself.\r\nThis command switch place can be confusing, as it combines both function called by the implant for itself and\r\nalso function that can be called by the attacker. Moreover, some of the function seem to be largely overlapping,\r\nmost likely because of code added in different parts of the development. The RAT and Proxy functions have their\r\nown section, I will describe here other notable functions:\r\nFunction 3\r\nThe function expects a buffer containing 482-byte long chunks of data detailing a connection to initiate, with the\r\nfollowing structure:\r\nFunction 15\r\nThe function is called hourly by the implant. It checks whether there were any successfull connections to the\r\nimplant in the last 24 hours and if there weren’t it calls Function 17. It is unlikely that the function is intended to\r\nbe called by the attacker directly.\r\nhttps://imp0rtp3.wordpress.com/2021/11/25/sowat/\r\nPage 4 of 19\n\nFunction 17\r\nThis killswitch tries to delete any artifact of the malware: it deletes the entrie current working directory and runs\r\nswt to revert any opened ports.\r\nRAT\r\nFunction num. explanation\r\n0 Execute command, send output back (“exc_cmd”)\r\n1 Change IP of server\r\n2 Write file “$(CWD)/s”\r\n3, 5 Add IP to configuration and reconnect to that file\r\n4 Delete all files and exit\r\n6 Write to file path chosen by the attacker\r\n7 Add IP to configuration and write file\r\n8 read file\r\nAs you can see, the functions are quite simple. Of some interest is function 2, which writes to a file named “s” in\r\nthe current working directory. I have not seen any other reference to that file\r\nhttps://imp0rtp3.wordpress.com/2021/11/25/sowat/\r\nPage 5 of 19\n\nFunction number 2\r\nRAT messages\r\nWhen SoWat receives a RAT message, it first checks if it’s the server or the client in the connection. if it’s the\r\nclient it skips the verification, if it functions as a server it does require verification.\r\nThis is the message fromat for the verification:\r\nThe verification process occurs as follows:\r\n1. Check whether the Signed checksum was signed with the Private key of the Client certificate\r\n2. Calculate the CRC64 Jones checksum of the command data,\r\n3. Compare the message checksum to the CRC64 checksum it calculated.\r\nhttps://imp0rtp3.wordpress.com/2021/11/25/sowat/\r\nPage 6 of 19\n\nOnly if the message is verified the command is ran,\r\nProxy\r\nSoWaT can function in two different proxy modes:\r\n1. Attacker \u003c-\u003e Attacker\r\n2. Attacker \u003c-\u003e Victim\r\nThe names of the modes comes only from reversing their internal logic and and analysis of potential uses. While\r\nthe Attacker \u003c-\u003e Victim mode is quite clear, the Attacker \u003c-\u003e Attacker mode is complicated and it is possible that\r\nits purpose is different, though it still works in the way detailed below..\r\nIn both modes, the command data needs to to be encrypted using the private key of the client (which it also used\r\nto verify itself in the TLS handshake).\r\nThe command data, before encryption, is structured in this way:\r\nI have written a script which can connect to SoWaT and perform as both sides of the proxy, See Scripts.\r\nAttacker \u003c-\u003e Victim Proxy\r\nhttps://imp0rtp3.wordpress.com/2021/11/25/sowat/\r\nPage 7 of 19\n\n1. The Attacker connects to SoWaT with TLS and client certificate validation\r\n2. The Attacker send a proxy initiation command, with the relevant data (encrypted):\r\n1. Attacker proxy listening port port and IP\r\n2. 32 byte ChaCha Key to encrypt communication later.\r\n3. SoWat initiates a raw unencrypted TCP socket with the attacker according to the data it got in the proxy\r\ncommand. The attacker sends back the victim connection port and attacker listening port.\r\n4. A malicious program, running on a victim attempts to connect to its server. Its server IP is the SoWaT’s\r\naddress. As soon as it initiates a TCP session with the implant, the implant initiates a new TCP session with\r\nthe attacker.\r\nThe malware encrypts the TCP data from the victim before forwarding it to the attacker and decrypts the\r\ndata from the attacker before forwarding to the victim. The data is encrypted using the ChaCha Key set by\r\nthe attacker in step 2.\r\n5. Step 4 can happen simultaneously with up to 5 victims, where each victim prompts the ORB to create a\r\nnew session with the attacker.\r\nIt is important to note that steps 3 onward are not necessarily with the same attacker as steps 1,2. The attacker of\r\nsteps 3 onward needs only to know at what port to listen to SoWaT.\r\nAttacker \u003c-\u003e Attacker Proxy\r\nhttps://imp0rtp3.wordpress.com/2021/11/25/sowat/\r\nPage 8 of 19\n\n1. Attacker 1 (A1) connects to SoWaT with TLS and client certificate validation\r\n2. A1 send a proxy initiation command, with the relevant data (encrypted):\r\n1. A2 proxy listening port and IP\r\n3. SoWaT connects to Attacker 2 (A2) using TLS and sends its client certificate.\r\n4. SoWaT sends A2 the port for the next stage.\r\n5. A2 sends command 6 to SoWaT, which prompts the implant to send A1 its stage 1 port.\r\n6. Both attackers initiate a TCP connection with SoWat each with the destination ports the implant assigned\r\nthem\r\n1. A1 sends command to run stage to the implant, which prompts it to send A2 its stage 2 port\r\n7. A2 sends the ORB a command to send A1 its stage 2 port\r\n8. A1 initiates a TCP connection with its stage 2 port and sends two bytes: {02 00} in order to signal the\r\nimplant to move forward with this stage.\r\n9. A1 initiates a new TCP connection to the same port as in step 8. A2 initiates a TCP connection to the\r\nstage2 port it has been given\r\n10. The attackers can communicate with each other through the sockets, and SoWaT servers as a proxy\r\n(without encryption).\r\nhttps://imp0rtp3.wordpress.com/2021/11/25/sowat/\r\nPage 9 of 19\n\nAs In the previous mode, steps 6 onwards can be done by a third attacker and do not need necessarily to continue\r\nwith A1 which initiaited the proxy command.\r\nBut why so complicated?\r\nI do not have a definite answer as to why the proxy intiation process is so complicated, expecially the attacker \u003c-\u003e\r\nattacker mode. Two Hyptotheses:\r\n1. Defense \u0026 SIGINT evasion\r\n1. Because of the difficult process until finally able to use the proxy, it is much harder for defendersn\r\nproactive hunter or anyone wandering in the internet to use it or exfiltrate attackers’ data this way.\r\n2. Finding open ports is becoming irelevant as even if the first port used by the attacker is always the\r\nsame it is open for a very short time, and the other ports are then random\r\n3. When having a lot of data, it is harder for some man in the middle to parse every paket to\r\nunderstand what the final proxy port is, which can make it more complicate to capture the relevant\r\nattacker traffic.\r\n2. Compatability and legacy – It’s possible it was easier for the developers to keep in place old code and to\r\njust wrap it with their additions, as it does not have any substantial impact on efficiency.\r\nAdditional Findings\r\nThe Implant File\r\nThe implant, available on Virustotal, is an ELF file compiled for the MIPS processor architecture. The ELF is\r\nstatically linked, with the libraries uClibc, libec, mbedtls, libc-ares and potentially others. While the code is in no\r\nmatter obfuscated, the stripped binary complicates reversing.\r\nConfiguration File\r\nSoWaT assumes a configuration file encrypted using ChaCha20 protocol named “conf” in its current working\r\ndirectory. The file needs to be exactly 386 bytes long, and constructed in this way:\r\nNonce – Some 12-byte random value which serves as salt for the chacha20 encryption. See ChaCha.\r\nBuffer size – size of the entire structure, in big endian.\r\nThe Configuration is decrypted using the following hard-coded key:\r\n53 14 3D 23 94 78 A9 68 2F 68 C9 A2 1A 93 3C 5B 39 52 2D 1D E0 63 59 1C 30 44 A2 6A 2A 3F A2 95\r\nhttps://imp0rtp3.wordpress.com/2021/11/25/sowat/\r\nPage 10 of 19\n\nThere are up to 10 IP,Port couples, which represent each an attacker-controlled server the implant may try to\r\nconnect to.\r\nThe structure of the configuration is probably due to compatibility reasons. it is possible that the first 260 bytes\r\nwere once used to sign the configuration, as that exact buffer length is used in other places for verification.\r\nThe “swt” file\r\nThe implant depends on a file named “swt” located also in the current working diretory.\r\nI am not in possesion of that file but from examining SoWaT’s use of it is clear It contains a CA certificate, and a\r\nsigned server certificate and private key. Moreover, it’s also an executable file. From context, it has likely some\r\nfunctionality which opens ports in the router’s firewall or changes its routing so to allow SoWaT to listen to\r\nincoming connections in a custom set port.\r\nHow SoWaT listens\r\nIn order to open a listening socket the implant has a specific procedure:\r\nSetup of socket\r\n1. It creates a basic socket object (AF_INET, SOCK_DGRAM)\r\n2. It sets the option SO_REUSEADDR to true.\r\n1. SO_REUSEADDR allows other processes to create another socket listening on the same port.\r\n3. The socket is bound to an open port or to a port directed by the function caller\r\n4. “./swt port \u003cbound port\u003e” is executed as a child process\r\nhttps://imp0rtp3.wordpress.com/2021/11/25/sowat/\r\nPage 11 of 19\n\n1. This behavior indicated that the “swt” executable most likely has some ability to alter the firewall or\r\nforwarding table of the router.\r\nDead Code\r\nThe implant contains a lot of dead code, which bears resemblance to the malicious code ran. Most likely, this code\r\nwas used in a previous version of the implant and was included because of compilation flags.\r\nUnused Logging function\r\nThe implants’ function and architecture show a comprehensive and advanced codebase, relying on many custom\r\nstructs, and running different tasks simultaneously.\r\nThe implant contains very few custom strings, which is quite unusual in router malware, whose developers are\r\nless afraid of detection and analysis.\r\nThe appearance of strings in an unsystematic way, and the use of status codes may hint that the threat actor has\r\nbeen detected and analyzed in the past and changed their implant to avoid detection.\r\nhttps://imp0rtp3.wordpress.com/2021/11/25/sowat/\r\nPage 12 of 19\n\nExecution Path\r\nThe implant doesn’t give any direct hint to how it was executed. Upon deeper inspection, the string “Usage :\r\nntpclient destination” stands out. which is referenced by a basic print_usage function. This function is never\r\ncalled. Most likely, it is an artifact left by accident by the Threat actor.\r\nThe executable lacks the functionality of every ntpclient, i.e. setting the time on the machine, so it was not\r\npossible for the implant to masquerade as a that.\r\nIt is possible that previous versions of the binary replaced the original ntpclient and so would be started as a\r\ndaemon, running ntpclient functionality along the malicious functionality. Alternatively, is is possible that the\r\nexecutable was just named ntpclient and the Usage was there to try make it look legitimate to a suspecting IT\r\ntechnician.\r\nIn the directory the implant is run from 2 files are expected:\r\n“swt”\r\n“conf”\r\nWhen a kill command is sent, the malware deletes its entrie current working directory, this means that it’s likely\r\nthe attacker dedicate an empty or new folder for their implant\r\nDetection\r\n1. Check for processes with suspicious names or running from unusual paths.\r\n2. I have written YARA rules to detect both unique string and code of the implant, available on my github\r\nAV Detection\r\nAs of the time of this writing, the original implant sample was detected by 33 out of 61 AV engines in VT.\r\nUploading the same sample, with some strings deleted, but fully functional yielded very different results: only 6\r\nAV vendors detected most of these samples.\r\nEssentialy, this means all but the 6 AV vendors are highly unlikely to detect the next SoWaT implant if uploaded\r\nto VT.\r\nnum. 1 2 5 4 5\r\ndetection 6 8 6 6 18\r\nchange changed\r\nmost\r\nstrings\r\nremoved\r\nonly unused\r\nstrings\r\nremoved all\r\nunique\r\nstrings\r\nremoved all\r\nunique strings\r\nchange file hash\r\nby appending\r\nsome bytes\r\nhttps://imp0rtp3.wordpress.com/2021/11/25/sowat/\r\nPage 13 of 19\n\nand encryption\r\nkey\r\nlink link link link link link\r\nThe 6 AVs that have shown consistent detections are (in alphabetical order):\r\nAhnLab\r\nDrWeb\r\nESET\r\nJiangmin\r\nKaspersky\r\nZillya\r\nIt is important to note that checking if an AV detect a file in VT does not mean whether an AV is good or bad, as in\r\nreal network AVs detect activity based on many other indicator and not just files.\r\nNevertheless, this comparison is important in my opinion, especially regarding router malware. it’s common that\r\nno AV is installed on the network device and to check a suspicious file one can only upload the file to VT or to\r\ntheir own AV portal.\r\nPrevention\r\nThe NSA has published in 2020 a great resource detailing how to harden network devices\r\nConclusions\r\nDevelopment timeline\r\nI can assess with high confidence that SoWaT has had several developmental builds before, for the following\r\nreasons:\r\n1. Dead code: Most likely because of a wrong compilation flag the implant contains a lot of dead code, which\r\nhas a striking resemblance to code that is actually used by the implant. I believe this indicates previous\r\nbuild of the threat actor where they formulated and changed the body of their build.\r\n2. Overlap in functionality: both the RAT and command switcher have function which do almost the same, in\r\na different manner. It is most likely because of backward compatibility.\r\n3. Unnecessary complex code: The code contains a lot of structures and sub-functions which seem to indicate\r\nfeatures that were added later to the codebase.\r\nTargets\r\nIt is likely that SoWaT is also deployed to other router vendors or linux based servers:\r\n1. The implant expects all incoming communication to be formatted as big endian. This does seem a little\r\nstrange considering that most likely the attacker is also working on a little-endian based computer. It’s\r\nhttps://imp0rtp3.wordpress.com/2021/11/25/sowat/\r\nPage 14 of 19\n\npossible that the attacker used that for comfort reasons, but another reason could be that the communication\r\nprotocols were initially written for a big-endian devices.\r\n2. The implant is fully system-independent and could be run on any linux kernel. The OS dependent part is\r\nmost likely in the “swt” binary, which changes the firewall of the specific device. The separation between\r\nOS-dependent and OS-independent executables does hint that the independent executable is also ran\r\nelsewhere.\r\nVerification and Encryption\r\nThroughout the research of the sample it is clear that the developers paid much attention to encryption and\r\nverification. Several remarks on that:\r\n1. The implant does not use AES at all and uses only ChaCha for symmetric encryption. That is not only true\r\nfor the configuration and proxy, but also its TLS supports only one ciphersuite\r\n(TLS_DCDHE_RSA_WITH_CHACHA20_POLY1305_SHA256). Most likely, it means the developers\r\ndeliberately compiled the executable without any AES support. This could be for reasons of efficiency\r\n(ChaCha tends to be faster), but also possible that they trust ChaCha to be more secure than AES.\r\n2. The usage of verification and encryption even though TLS is used cannot be explained as an old procedure\r\nused before the developers used TLS, because the encryption and verification rely on Client certificate only\r\navailable throught the TLS handshake. Two other possible explanations are:\r\n1. The attackers do not trust the TLS protocol so they try additional security measures\r\n2. Previously a 3rd party successfully did a MiTM attack using a cracked or stolen attacker CA\r\ncertificate stolen from the attackers. encrypting or verfying data with the client certificate private\r\nkey makes it difficult for the 3rd party to do that again.\r\nSummary\r\n1. While certainly far from the only router implant, SoWaT underlines that threat actors move to\r\ncommercially available tools (such as cobalt strike) where it fits them, but do not stop in-house\r\ndevelopment and research where needed. The fact that the implant was likely developed over multiple\r\nyears underlines that it is likely not to be thrown away easily.\r\n2. Routers are detection and prevention-wise almost a black hole. The fact that the compromised routers\r\noperate as ORBs and most of the time do not harm the organization to whom the router belongs makes\r\nprevention and detection even more complicated. Shedding more light and discourse into these may help in\r\ndeveloping and distributing more detection and prevention options.\r\n3. This research is far from complete. Any researchers with questions or information are welcome to contact\r\nme, and I’ll be happy to share the IDA database and any other relevant data.\r\nAPPENDIX A – IOCs\r\nSHA256\r\n1d60edb577641ce47dc2a8299f8b7f878e37120b192655aaf80d1cde5ee482d2 (VT)\r\nhttps://imp0rtp3.wordpress.com/2021/11/25/sowat/\r\nPage 15 of 19\n\nFile names\r\nswt\r\ns\r\nconf\r\nlog\r\nJA3 – e1f787e2b6ec64bf23157522c2e8073d\r\nJARM – 3fd3fd0003fd3fd0003fd3fd3fd3fd755a2cec4b52fb1bce1ac7f1e48c8a7d\r\nAPPENDIX B – Scripts\r\nProxy Communication Simulation\r\nConfiguration creator\r\nBasic Openssl certificates creator\r\nMock swt creator (depends on certificates)\r\nAPPENDIX C – Internal Structures\r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\n9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\nstruct sowat_info{\r\nDWORD current command_num;\r\nDWORD calling_method;\r\nunion message{\r\n* char client_response;\r\n* char server_response;\r\n};\r\nunion message_len{\r\nDWORD client_response_len;\r\nDWORD server_response_len;\r\n};\r\nchar client_public_key[460];\r\n* global_connection_infromation global_connection_infromation;\r\nDWORD unknown;\r\nDWORD sock_fd_read;\r\nhttps://imp0rtp3.wordpress.com/2021/11/25/sowat/\r\nPage 16 of 19\n\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22\r\n23\r\n24\r\n25\r\n26\r\n27\r\n28\r\n29\r\n30\r\n31\r\n32\r\n33\r\n34\r\n35\r\n36\r\n37\r\n38\r\n39\r\n40\r\n41\r\n* char connection_init_msg;\r\n* client_to_server client_to_server;\r\n* void command_run(sowat_info * sowat_info);\r\n};\r\nstruct cert_info\r\n{\r\n* void unknown;\r\n* mbedtls_x509_crt mbedtls_x509_crt_in_connection;\r\n* mbedtls_pk_context mbedtls_pk_context_in_connection;\r\n};\r\nstruct global_connection_infromation\r\n{\r\n* internal_conn_info internal_conn_info;\r\n* DICT known_public_keys;\r\n* cert_info cert_info;\r\n* char decrypted_configuration;\r\n* ev_loop main_loop;\r\nDWORD time_delta;\r\nDWORD hours_counter;\r\n};\r\nstruct internal_conn_info\r\n{\r\nQWORD pk_crc64_jones;\r\nDWORD connection_ip;\r\nWORD connection_port;\r\nDWORD unknown;\r\nhttps://imp0rtp3.wordpress.com/2021/11/25/sowat/\r\nPage 17 of 19\n\n42\r\n43\r\n44\r\n45\r\n46\r\n47\r\n48\r\n49\r\n50\r\n51\r\n52\r\n53\r\n54\r\n55\r\n56\r\n57\r\n58\r\n59\r\n60\r\n61\r\n62\r\n63\r\n64\r\n65\r\n66\r\n67\r\nDWORD time_of_conn_init;\r\nchar public_key[460];\r\n};\r\nstruct proxy {\r\nBYTE prx_command;\r\nDWORD fd_socket_0;\r\nDWORD fd_socket_1;\r\nDWORD unknown;\r\nDWORD tls_server_IP;\r\nWORD socket_2_1_port;\r\nWORD socket_0_port;\r\nWORD socket_1_port;\r\nWORD socket_2_0_port;\r\nchar chacha_encryption_key[32];\r\n* ev_io prx_cb_1;\r\n* ev_io prx_0_cb0;\r\nDWORD fd_socket_prx_1;\r\nDWORD time_last_recv_pack1;\r\nDWORD time_last_recv_pack2;\r\nDWORD time_last_recv_pack3;\r\n* ev_loop prx_ev_loop;\r\nWORD prx_2_listen_port;\r\nDICT used_ports;\r\nQWORD unknown;\r\nWORD socket_1_port;\r\nDICT unknown;\r\nhttps://imp0rtp3.wordpress.com/2021/11/25/sowat/\r\nPage 18 of 19\n\n68\r\n69\r\n70\r\n71\r\n72\r\n73\r\n74\r\n75\r\n76\r\n77\r\n78\r\n79\r\n80\r\n81\r\n82\r\n83\r\n84\r\n85\r\n86\r\n};\r\nstruct DICT{\r\nvoid * djb2_hashtable;\r\nDWORD num_keys;\r\n};\r\nstruct dict_hash_obj{\r\nDWORD djb2;\r\n* void value;\r\n* dict_hash_obj next;\r\nchar key[4];\r\n};\r\nSource: https://imp0rtp3.wordpress.com/2021/11/25/sowat/\r\nhttps://imp0rtp3.wordpress.com/2021/11/25/sowat/\r\nPage 19 of 19\n\nBuffer size – The Configuration size of the entire is decrypted structure, in big using the following endian. hard-coded key:  \n53 14 3D 23 94 78 A9 68 2F 68 C9 A2 1A 93 3C 5B 39 52 2D 1D E0 63 59 1C 30 44 A2 6A 2A 3F A2 95\n   Page 10 of 19",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://imp0rtp3.wordpress.com/2021/11/25/sowat/"
	],
	"report_names": [
		"sowat"
	],
	"threat_actors": [
		{
			"id": "aacd5cbc-604b-4b6e-9e58-ef96c5d1a784",
			"created_at": "2023-01-06T13:46:38.953463Z",
			"updated_at": "2026-04-10T02:00:03.159523Z",
			"deleted_at": null,
			"main_name": "APT31",
			"aliases": [
				"JUDGMENT PANDA",
				"BRONZE VINEWOOD",
				"Red keres",
				"Violet Typhoon",
				"TA412"
			],
			"source_name": "MISPGALAXY:APT31",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "9e6186dd-9334-4aac-9957-98f022cd3871",
			"created_at": "2022-10-25T15:50:23.357398Z",
			"updated_at": "2026-04-10T02:00:05.368552Z",
			"deleted_at": null,
			"main_name": "ZIRCONIUM",
			"aliases": [
				"APT31",
				"Violet Typhoon"
			],
			"source_name": "MITRE:ZIRCONIUM",
			"tools": null,
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "74d9dada-0106-414a-8bb9-b0d527db7756",
			"created_at": "2025-08-07T02:03:24.69718Z",
			"updated_at": "2026-04-10T02:00:03.733346Z",
			"deleted_at": null,
			"main_name": "BRONZE VINEWOOD",
			"aliases": [
				"APT31 ",
				"BRONZE EXPRESS ",
				"Judgment Panda ",
				"Red Keres",
				"TA412",
				"VINEWOOD ",
				"Violet Typhoon ",
				"ZIRCONIUM "
			],
			"source_name": "Secureworks:BRONZE VINEWOOD",
			"tools": [
				"DropboxAES RAT",
				"HanaLoader",
				"Metasploit",
				"Mimikatz",
				"Reverse ICMP shell",
				"Trochilus"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "dc7ee503-9494-4fb6-a678-440c68fd31d8",
			"created_at": "2022-10-25T16:07:23.349177Z",
			"updated_at": "2026-04-10T02:00:04.552639Z",
			"deleted_at": null,
			"main_name": "APT 31",
			"aliases": [
				"APT 31",
				"Bronze Vinewood",
				"G0128",
				"Judgment Panda",
				"Red Keres",
				"RedBravo",
				"TA412",
				"Violet Typhoon",
				"Zirconium"
			],
			"source_name": "ETDA:APT 31",
			"tools": [
				"9002 RAT",
				"Agent.dhwf",
				"AngryRebel",
				"CHINACHOPPER",
				"China Chopper",
				"Destroy RAT",
				"DestroyRAT",
				"Farfli",
				"Gh0st RAT",
				"Ghost RAT",
				"GrewApacha",
				"HOMEUNIX",
				"HiKit",
				"HidraQ",
				"Homux",
				"Hydraq",
				"Kaba",
				"Korplug",
				"McRAT",
				"MdmBot",
				"Moudour",
				"Mydoor",
				"PCRat",
				"PlugX",
				"RedDelta",
				"Roarur",
				"Sakula",
				"Sakula RAT",
				"Sakurel",
				"SinoChopper",
				"Sogu",
				"TIGERPLUG",
				"TVT",
				"Thoper",
				"Trochilus RAT",
				"Xamtrav"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434679,
	"ts_updated_at": 1775792242,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/5f9c7afb1a194085da42eea82c7560f2a6033de5.pdf",
		"text": "https://archive.orkl.eu/5f9c7afb1a194085da42eea82c7560f2a6033de5.txt",
		"img": "https://archive.orkl.eu/5f9c7afb1a194085da42eea82c7560f2a6033de5.jpg"
	}
}