{ "id": "c7a74f65-72f3-4571-ade3-1feb3c5c87b7", "created_at": "2026-04-06T00:15:41.047283Z", "updated_at": "2026-04-10T03:36:36.638169Z", "deleted_at": null, "sha1_hash": "441eb0411e109e93008ad00cb223fef4782a5b07", "title": "Tracking a P2P network related to TA505", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 100711, "plain_text": "Tracking a P2P network related to TA505\r\nBy Joost Jansen\r\nPublished: 2021-12-02 · Archived: 2026-04-05 14:27:32 UTC\r\nThis post is by Nikolaos Pantazopoulos and Michael Sandee\r\ntl;dr – Executive Summary\r\nFor the past few months NCC Group has been closely tracking the operations of TA505 and the development of their\r\nvarious projects (e.g. Clop). During this research we encountered a number of binary files that we have attributed to the\r\ndeveloper(s) of ‘Grace’ (i.e. FlawedGrace). These included a remote administration tool (RAT) used exclusively by TA505.\r\nThe identified binary files are capable of communicating with each other through a peer-to-peer (P2P) network via UDP.\r\nWhile there does not appear to be a direct interaction between the identified samples and a host infected by ‘Grace’, we\r\nbelieve with medium to high confidence that there is a connection to the developer(s) of ‘Grace’ and the identified binaries.\r\nIn summary, we found the following:\r\nP2P binary files, which are downloaded along with other Necurs components (signed drivers, block lists)\r\nP2P binary files, which transfer certain information (records) between nodes\r\nBased on the network IDs of the identified samples, there seem to be at least three different networks running\r\nThe programming style and dropped file formats match the development standards of ‘Grace’\r\nHistory of TA505’s Shift to Ransomware Operations\r\n2014: Emergence as a group\r\nThe threat actor, often referred to as TA505 publicly, has been distinguished as an independent threat actor by NCC Group\r\nsince 2014. Internally we used the name “Dridex RAT group”. Initially it was a group that integrated quite closely with\r\nEvilCorp, utilising their Dridex banking malware platform to execute relatively advanced attacks, using often custom made\r\ntools for a single purpose and repurposing commonly available tools such as ‘Ammyy Admin’ and ‘RMS’/’RUT’ to\r\ncomplement their arsenal. The attacks performed mostly consisted of compromising organisations and social engineering\r\nvictims to execute high value bank transfers to corporate mule accounts. These operations included social engineering\r\ncorrectly implemented two-factor authentication with dual authorization by both the creator of a transaction and the\r\nauthorizee.\r\n2017: Evolution\r\nLate 2017, EvilCorp and TA505 (Dridex RAT Group) split as a partnership. Our hypothesis is that EvilCorp had started to\r\nuse the Bitpaymer ransomware to extort organisations rather than doing banking fraud. This built on the fact they had\r\nalready been using the Locky ransomware previously and was attracting unwanted attention. EvilCorp’s ability to execute\r\nenterprise ransomware across large-scale businesses was first demonstrated in May 2017. Their capability and success at\r\npulling off such attacks stemmed from the numerous years of experience in compromising corporate networks for banking\r\nfraud activity, specifically moving laterally to separate hosts controlled by employees who had the required access and\r\ncontrol of corporate bank accounts. The same techniques in relation to lateral movement and tools (such as Empire,\r\nArmitage, Cobalt Strike and Metasploit) enabled EvilCorp to become highly effective in targeted ransomware attacks.\r\nHowever in 2017 TA505 went on their own path and specifically in 2018 executed a large number of attacks using the tool\r\ncalled ‘Grace’, also known publicly as ‘FlawedGrace’ and ‘GraceWire’. The victims were mostly financial institutions and a\r\nlarge number of the victims were located in Africa, South Asia, and South East Asia with confirmed fraudulent wire\r\ntransactions and card data theft originating from victims of TA505. The tool ‘Grace’ had some interesting features, and\r\nshowed some indications that it was originally designed as banking malware which had latterly been repurposed. However,\r\nthe tool was developed and was used in hundreds of victims worldwide, while remaining relatively unknown to the wider\r\npublic in its first years of use.\r\nIn early 2019, TA505 started to utilise the Clop ransomware, alongside other tools such as ‘SDBBot’ and ‘ServHelper’,\r\nwhile continuing to use ‘Grace’ up to and including 2021. Today it appears that the group has realised the potential of\r\nransomware operations as a viable business model and the relative ease with which they can extort large sums of money\r\nfrom victims.\r\nThe remainder of this post dives deeper into a tool discovered by NCC Group that we believe is related to TA505 and the\r\ndeveloper of ‘Grace’. We assess that the identified tool is part of a bigger network, possibly related with Grace infections.\r\nTechnical Analysis\r\nhttps://blog.fox-it.com/2021/12/02/tracking-a-p2p-network-related-to-ta505/\r\nPage 1 of 6\n\nThe technical analysis we provide below focuses on three components of the execution chain:\r\n1. A downloader – Runs as a service (each identified variant has a different name) and downloads the rest of the\r\ncomponents along with a target processes/services list that the driver uses while filtering information. Necurs have\r\nused similar downloaders in the past.\r\n2. A signed driver (both x86 and x64 available) – Filters processes/services in order to avoid detection and/or prevent\r\nremoval. In addition, it injects the payload into a new process.\r\n3. Node tool – Communicates with other nodes in order to transfer victim’s data.\r\nIt should be noted that for all above components, different variations were identified. However, the core functionality and\r\npurposes remain the same.\r\nUpon execution, the downloader generates a GUID (used as a bot ID) and stores it in the ProgramData folder under the\r\nfilename regid.1991-06.com.microsoft.dat . Any downloaded file is stored temporarily in this directory. In addition, the\r\ndownloader reads the version of crypt32.dll in order to determine the version of the operating system.\r\nNext, it contacts the command and control server and downloads the following files:\r\nt.dat – Expected to contain the string ‘kwREgu73245Nwg7842h’\r\np3.dat – P2P Binary. Saved as ‘payload.dll’\r\nd1c.dat – x86 (signed) Driver\r\nd2c.dat – x64 (signed) Driver\r\nbn.dat – List of processes for the driver to filter. Stored as ‘blacknames.txt’\r\nbs.dat – List of services’ name for the driver to filter. Stored as ‘blacksigns.txt’\r\nbv.dat – List of files’ version names for the driver to filter. Stored as ‘blackvers.txt’.\r\nr.dat – List of registry keys for the driver to filter. Stored as ‘registry.txt’\r\nThe network communication of the downloader is simple. Firstly, it sends a GET request to the command and control server,\r\ndownloads and saves on disk the appropriate component. Then, it reads the component from disk and decrypts it (using the\r\nRC4 algorithm) with the hardcoded key ‘ABCDF343fderfds21’. After decrypting it, the downloader deletes the file.\r\nDepending on the component type, the downloader stores each of them differently. Any configurations (e.g. list of processes\r\nto filter) are stored in registry under the key HKEY_LOCAL_MACHINE\\SOFTWARE\\Classes\\CLSID with the value name being the\r\nthread ID of the downloader. The data are stored in plaintext with a unique ID value at the start (e.g. 0x20 for the processes\r\nlist), which is used later by the driver as a communication method.\r\nIn addition, in one variant, we detected a reporting mechanism to the command and control server for each step taken. This\r\ninvolves sending a GET request, which includes the generated bot ID along with a status code. The below table summarises\r\neach identified request (Table 1).\r\nRequest Description\r\n/c/p1/dnsc.php?n=%s\u0026in=%s\r\nFirst parameter is the bot ID and the second is the formatted string\r\n(“Version_is_%d.%d_(%d)_%d__ARCH_%d”), which contains\r\noperating system info\r\n/c/p1/dnsc.php?\r\nn=%s\u0026sz=DS_%d\r\nFirst parameter is the bot ID and the second is the downloaded\r\ndriver’s size\r\n/c/p1/dnsc.php?\r\nn=%s\u0026er=ERR_%d\r\nFirst parameter is the bot ID and the second is the error code\r\n/c/p1/dnsc.php?n=%s\u0026c1=1\r\nThe first parameter is the bot ID. Notifies the server that the driver\r\nwas installed successfully\r\n/c/p1/dnsc.php?\r\nn=%s\u0026c1=1\u0026er=REB_ERR_%d\r\nFirst parameter is the bot ID and the second is the error code\r\nobtained while attempting to shut down the host after finding\r\nWindows Defender running\r\n/c/p1/dnsc.php?\r\nn=%s\u0026sz=ErrList_%d_%\r\nFirst parameter is the bot ID, second parameter is the resulted error\r\ncode while retrieving the blocklist processes. The third parameter is\r\nset to 1. The same command is also issued after downloading the\r\nblacklisted services’ names and versions. The only difference is on\r\nthe third parameter, which is increased to ‘2’ for blacklisted\r\nservices, ‘3’ for versions and ‘4’ for blacklisted registry keys\r\n/c/p1/dnsc.php?\r\nn=%s\u0026er=PING_ERR_%d\r\nFirst parameter is the bot ID and the second parameter is the error\r\ncode obtained during the driver download process\r\nhttps://blog.fox-it.com/2021/12/02/tracking-a-p2p-network-related-to-ta505/\r\nPage 2 of 6\n\n/c/p1/dnsc.php?\r\nn=%s\u0026c1=1\u0026c2=1\r\nFirst parameter is the bot ID. Informs the server that the bot is about\r\nto start the downloading process.\r\n/c/p1/dnsc.php?\r\nn=%s\u0026c1=1\u0026c2=1\u0026c3=1\r\nFirst parameter is the bot ID. Notified the server that the payload\r\n(node tool) was downloaded and stored successfully\r\nTable 1 – Reporting to C2 requests\r\nDriver Analysis\r\nThe downloaded driver is the same one that Necurs uses. It has been analysed publically already [1] but in summary, it does\r\nthe following.\r\nIn the first stage, the driver decrypts shellcode, copies it to a new allocated pool and then executes the payload. Next, the\r\nshellcode decrypts and runs (in memory) another driver (stored encrypted in the original file). The decryption algorithm\r\nremains the same in both cases:\r\nxor_key = extracted_xor_key\r\nbits = 15\r\nresult = b''\r\nfor i in range(0,payload_size,4):\r\ndata = encrypted[i:i+4]\r\nvalue = int.from_bytes (data, 'little' )^ xor_key\r\nresult += ( _rol(value, bits, 32) ^ xor_key).to_bytes(4,'little')\r\nEventually, the decrypted driver injects the payload (the P2P binary) into a new process (‘wmiprvse.exe’) and proceeds with\r\nthe filtering of data.\r\nA notable piece of code of the driver is the strings’ decryption routine, which is also present in recent GraceRAT samples,\r\nincluding the same XOR key\r\n(1220A51676E779BD877CBECAC4B9B8696D1A93F32B743A3E6790E40D745693DE58B1DD17F65988BEFE1D6C62D5416B25BB78EF0622B5F82\r\nPayload Attribution and Analysis\r\nThe identified sample is written in C++ and interacts with other nodes in the network using UDP. We believe that the\r\ndownloaded binary file is related with TA505 for (at least) the following reasons:\r\n1. Same serialisation library\r\n2. Same programming style with ‘Grace’ samples\r\n3. Similar naming convention in the configuration’s keys with ‘Grace’ samples\r\n4. Same output files (dsx), which we have seen in previous TA505 compromises. DSX files have been used by ‘Grace’\r\noperators to store information related with compromised machines.\r\nInitialisation Phase\r\nIn the initialisation phase, the sample ensures that the configurations have been loaded and the appropriate folders are\r\ncreated.\r\nAll identified samples store their configurations in a resource with name XC .\r\nANALYST NOTE: Due to limit visibility of other nodes, we were not able to identify the purpose of each key of the\r\nconfigurations.\r\nThe first configuration stores the following settings:\r\ncx – Parent name\r\nnid – Node ID. This is used as a network identification method during network communication. If the incoming\r\nnetwork packet does not have the same ID then the packet is treated as a packet from a different network and is\r\nignored.\r\ndgx – Unknown\r\nexe – Binary mode flag (DLL/EXE)\r\nkey – RSA key to use for verifying a record\r\nport – UDP port to listen\r\nva – Parent name. It includes the node IPs to contact.\r\nThe second configuration contains the following settings (or metadata as the developer names them):\r\nmeta – Parent name\r\napp – Unknown. Probably specifies the variant type of the server. The following seem to be supported:\r\nhttps://blog.fox-it.com/2021/12/02/tracking-a-p2p-network-related-to-ta505/\r\nPage 3 of 6\n\ntarget (this is the current set value)\r\ngate\r\ndrop\r\ncontrol\r\nmod – Specifies if current binary is the core module.\r\nbld – Unknown\r\napi – Unknown\r\nllr – Unknown\r\nllt- Unknown\r\nNext, the sample creates a set of folders and files in a directory named ‘target’. These folders are:\r\nnode (folder) – Stores records of other nodes\r\ntrash (folder) – Move files for deletion\r\nunits (folder) – Unknown. Appears to contain PE files, which the core module loads.\r\nsessions (folder) – Active nodes’ sessions\r\nunits.dsx (file) – List of ‘units’ to load\r\nprobes.dsx (file) – Stores the connected nodes IPs along with other metadata (e.g. connection timestamp, port\r\nnumber)\r\nnet.dsx (file) – Node peer name\r\nreports.dsx (file) – Used in recent versions only. Unknown purpose.\r\nNetwork communication\r\nAfter the initialisation phase has been completed, the sample starts sending UDP requests to a list of IPs in order to register\r\nitself into the network and then exchange information.\r\nEvery network packet has a header, which has the below structure:\r\nstruct Node_Network_Packet_Header\r\n{\r\n BYTE XOR_Key;\r\n BYTE Version; // set to 0x37 ('7')\r\n BYTE Encrypted_node_ID[16]; // XORed with XOR_Key above\r\n BYTE Peer_Name[16]; // Xored with XOR_Key above. Connected peer name\r\n BYTE Command_ID; //Internally called frame type\r\n DWORD Watermark; //XORed with XOR_Key above\r\n DWORD Crc32_Data; //CRC32 of above data\r\n};\r\nWhen the sample requires adding additional information in a network packet, it uses the below structure:\r\nstruct Node_Network_Packet_Payload\r\n{\r\n DWORD Size;\r\n DWORD CRC32_Data;\r\n BYTE Data[Size]; // Xored with same key used in the header packet (XOR_Key)\r\n};\r\nAs expected, each network command (Table 2) adds a different set of information in the ‘Data’ field of the above structure\r\nbut most of the commands follow a similar format. For example, an ‘invitation’ request (Command ID 1) has the structure:\r\nstruct Node_Network_Invitation_Packet\r\n{\r\n BYTE CMD_ID;\r\n DWORD Session_Label;\r\n BYTE Invitation_ID[16];\r\n BYTE Node_Peer_Name[16];\r\n WORD Node_Binded_Port;\r\n};\r\nThe sample supports a limited set of commands, which have as a primary role to exchange ‘records’ between each other.\r\nCommand ID Description\r\n1 Requests to register in the other nodes (‘invitation’ request)\r\nhttps://blog.fox-it.com/2021/12/02/tracking-a-p2p-network-related-to-ta505/\r\nPage 4 of 6\n\n2 Adds node IP to the probes list\r\n3 Sends a ping request. It includes number of active connections and records\r\n4 Sends number of active connections and records in the node\r\n5 Adds a new node IP:Port that the remote node will check\r\n6 Sends a record ID along with the number of data blocks\r\n7 Requests metadata of a record\r\n8 Sends metadata of a record\r\n9 Requests the data of a record\r\n10 Receives data of a record and store them on disk\r\nTable 2 – Set of command IDs\r\nANALYST NOTE: When information, such as record IDs or number of active connections/records, is sent, the binary adds\r\nthe length of the data followed by the actual data. For example, in case of sending number of active connections and\r\nrecords:\r\n01 05 01 02 01 02\r\nThe above is translated as:\r\n2 active connections from a total of 5 with 2 records.\r\nMoreover, when a node receives a request, it sends an echo reply (includes the same packet header) to acknowledge that the\r\nrequest was read. In general, the following types are supported:\r\nRequest type of 0x10 for echo request.\r\nRequest type of 0x07 when sending data, which fit in one packet.\r\nRequest type of 0xD when sending data in multiple packets (size of payload over 1419 bytes).\r\nRequest type 0x21. It exists in the binary but not supported during the network communications.\r\nRecord files\r\nAs mentioned already, a record has its own sub-folder under the ‘node’ folder with each sub-folder containing the below\r\nfiles:\r\nm – Metadata of record file\r\nl – Unknown purpose\r\np – Payload data\r\nThe metadata file contains a set of information for the record such as the node peer name and the node network ID. Among\r\nthis information, the keys ‘tag’ and ‘pwd’ appear to be very important too. The ‘tag’ key represents a command (different\r\nfrom table 2 set) that the node will execute once it receives the record. Currently, the binary only supports the command\r\n‘updates’. The payload file (p) keeps the updated content encrypted with the value of key ‘pwd’ being the AES key.\r\nEven though we have not been able yet to capture any network traffic for the above command, we believe that it is used to\r\nupdate the current running core module.\r\nIoCs\r\nNodes’ IPs\r\n45.142.213[.]139:555\r\n195.123.246[.]14:555\r\n45.129.137[.]237:33964\r\n78.128.112[.]139:33964\r\n145.239.85[.]6:3333\r\nBinaries\r\nSHA-1 Description\r\nhttps://blog.fox-it.com/2021/12/02/tracking-a-p2p-network-related-to-ta505/\r\nPage 5 of 6\n\nA21D19EB9A90C6B579BCE8017769F6F58F9DADB1   P2P Binary\r\n2F60DE5091AB3A0CE5C8F1A27526EFBA2AD9A5A7 P2P Binary\r\n2D694840C0159387482DC9D7E59217CF1E365027 P2P Binary\r\n02FFD81484BB92B5689A39ABD2A34D833D655266 x86 Driver\r\nB4A9ABCAAADD80F0584C79939E79F07CBDD49657 x64 Driver\r\n00B5EBE5E747A842DEC9B3F14F4751452628F1FE X64 Driver\r\n22F8704B74CE493C01E61EF31A9E177185852437 Downloader\r\nD1B36C9631BCB391BC97A507A92BCE90F687440A Downloader\r\nTable 3 – Binary hashes\r\nSource: https://blog.fox-it.com/2021/12/02/tracking-a-p2p-network-related-to-ta505/\r\nhttps://blog.fox-it.com/2021/12/02/tracking-a-p2p-network-related-to-ta505/\r\nPage 6 of 6", "extraction_quality": 1, "language": "EN", "sources": [ "ETDA" ], "references": [ "https://blog.fox-it.com/2021/12/02/tracking-a-p2p-network-related-to-ta505/" ], "report_names": [ "tracking-a-p2p-network-related-to-ta505" ], "threat_actors": [ { "id": "5e6b31a6-80e3-4e7d-8b0a-d94897ce9b59", "created_at": "2024-06-19T02:03:08.128175Z", "updated_at": "2026-04-10T02:00:03.636663Z", "deleted_at": null, "main_name": "GOLD TAHOE", "aliases": [ "Cl0P Group Identity", "FIN11 ", "GRACEFUL SPIDER ", "SectorJ04 ", "Spandex Tempest ", "TA505 " ], "source_name": "Secureworks:GOLD TAHOE", "tools": [ "Clop", "Cobalt Strike", "FlawedAmmy", "Get2", "GraceWire", "Malichus", "SDBbot", "ServHelper", "TrueBot" ], "source_id": "Secureworks", "reports": null }, { "id": "75d4d6a9-b5d1-4087-a7a0-e4a9587c45f4", "created_at": "2022-10-25T15:50:23.5188Z", "updated_at": "2026-04-10T02:00:05.26565Z", "deleted_at": null, "main_name": "TA505", "aliases": [ "TA505", "Hive0065", "Spandex Tempest", "CHIMBORAZO" ], "source_name": "MITRE:TA505", "tools": [ "AdFind", "Azorult", "FlawedAmmyy", "Mimikatz", "Dridex", "TrickBot", "Get2", "FlawedGrace", "Cobalt Strike", "ServHelper", "Amadey", "SDBbot", "PowerSploit" ], "source_id": "MITRE", "reports": null }, { "id": "99cb4e5b-8071-4f9e-aa1d-45bfbb6197e3", "created_at": "2023-01-06T13:46:38.860754Z", "updated_at": "2026-04-10T02:00:03.125179Z", "deleted_at": null, "main_name": "TA505", "aliases": [ "SectorJ04", "SectorJ04 Group", "ATK103", "GRACEFUL SPIDER", "GOLD TAHOE", "Dudear", "G0092", "Hive0065", "CHIMBORAZO", "Spandex Tempest" ], "source_name": "MISPGALAXY:TA505", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "e447d393-c259-46e2-9932-19be2ba67149", "created_at": "2022-10-25T16:07:24.28282Z", "updated_at": "2026-04-10T02:00:04.921616Z", "deleted_at": null, "main_name": "TA505", "aliases": [ "ATK 103", "Chimborazo", "G0092", "Gold Evergreen", "Gold Tahoe", "Graceful Spider", "Hive0065", "Operation Tovar", "Operation Trident Breach", "SectorJ04", "Spandex Tempest", "TA505", "TEMP.Warlock" ], "source_name": "ETDA:TA505", "tools": [ "Amadey", "AmmyyRAT", "AndroMut", "Azer", "Bart", "Bugat v5", "CryptFile2", "CryptoLocker", "CryptoMix", "CryptoShield", "Dridex", "Dudear", "EmailStealer", "FRIENDSPEAK", "Fake Globe", "Fareit", "FlawedAmmyy", "FlawedGrace", "FlowerPippi", "GOZ", "GameOver Zeus", "GazGolder", "Gelup", "Get2", "GetandGo", "GlobeImposter", "Gorhax", "GraceWire", "Gussdoor", "Jaff", "Kasidet", "Kegotip", "Kneber", "LOLBAS", "LOLBins", "Living off the Land", "Locky", "MINEBRIDGE", "MINEBRIDGE RAT", "MirrorBlast", "Neutrino Bot", "Neutrino Exploit Kit", "P2P Zeus", "Peer-to-Peer Zeus", "Philadelphia", "Philadephia Ransom", "Pony Loader", "Rakhni", "ReflectiveGnome", "Remote Manipulator System", "RockLoader", "RuRAT", "SDBbot", "ServHelper", "Shifu", "Siplog", "TeslaGun", "TiniMet", "TinyMet", "Trojan.Zbot", "Wsnpoem", "Zbot", "Zeta", "ZeuS", "Zeus" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434541, "ts_updated_at": 1775792196, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/441eb0411e109e93008ad00cb223fef4782a5b07.pdf", "text": "https://archive.orkl.eu/441eb0411e109e93008ad00cb223fef4782a5b07.txt", "img": "https://archive.orkl.eu/441eb0411e109e93008ad00cb223fef4782a5b07.jpg" } }