{ "id": "54fdc6f3-5869-4455-83bf-309183d4fcd9", "created_at": "2026-04-06T00:21:19.29033Z", "updated_at": "2026-04-10T03:34:24.371951Z", "deleted_at": null, "sha1_hash": "128916fe29c9aefd387f552be1049b59cda90c5d", "title": "Extracting DDosia targets from process memory", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 2653119, "plain_text": "Extracting DDosia targets from process memory\r\nBy map[name:Alessandro Strino]\r\nPublished: 2023-05-08 · Archived: 2026-04-05 12:44:00 UTC\r\nIntroduction\r\nThis post is part of an analysis that I have carried out during my spare time, motivated by a friend that asked me to have\r\na look at the DDosia project related to the NoName057(16) group. The reason behind this request was caused by\r\nDDosia client changes for performing the DDos attacks. Because of that, all procedures used so far for monitoring\r\nNoName057(16) activities did not work anymore.\r\nBefore starting to reverse DDosia Windows sample, I preferred to gather as much information as possible about\r\nNoName057(16) TTPs and a few references to their samples.\r\nAvast wrote a very detailed article about that project and described thoroughly all changes observed in the last few\r\nmonths. Because of that, before proceeding with this post, If you feel you are missing something, I strongly \r\nrecommend that you read their article.\r\nClient Setup\r\nAccording to the information retrieved from the Telegram channel of DDosia Project, there are a couple of\r\nrequirements before executing the client. The very first action is to create your id through a dedicated bot that will be\r\nused later on for authentication purposes. After that, it’s necessary to put the client_id.txt file (generated from DDosia\r\nbot) and the executable file in the same folder. If everything has been done properly, it should be possible to observe\r\nthat authentication process will be done correctly and the client is going to download targets from its server:\r\nFigure 1: Client authenticated correctly\r\nDynamic analysis and process memory inspection\r\nhttps://viuleeenz.github.io/posts/2023/05/extracting-ddosia-targets-from-process-memory/\r\nPage 1 of 6\n\nHere we are with the fun part. Because of the issues of analyzing GO binaries statically, I preferred to use a dynamic\r\napproach supported by Cape sandbox. In fact, executing the client with Cape it was possible to gather behavioral\r\ninformation to speed up our analysis (ref). Since the executable is going to be used for DDoS attacks, it’s easy to expect\r\nthat most of the functions are related to network routines. One of the most interesting WindowsAPI refers to\r\nWSAStartup. This is interesting for us, because according to Microsoft documentation, it must be the first function to\r\nbe used in order to retrieve socket implementation for further network operations:\r\nThe WSAStartup function must be the first Windows Sockets function called by an application or DLL. It\r\nallows an application or DLL to specify the version of Windows Sockets required and retrieve details of the\r\nspecific Windows Sockets implementation. The application or DLL can only issue further Windows Sockets\r\nfunctions after successfully calling WSAStartup.\r\nMoreover, starting to monitor network requests with Wireshark, give us additional information about client-server\r\ninteractions and targets retrieving procedure:\r\nFigure 2 - Request for target list\r\nAs already mentioned on Avast blogspot, the target list is encrypted and retrieved after the authentication process.\r\nHowever, performing DDoS attacks requires a decryption routine to make targets in cleartext and forward them to a\r\nproper procedure. With this insight, it’s possible to open up a debugger and set a breakpoint of WSAStartup and start\r\nexploring the process flow from that point.\r\nhttps://viuleeenz.github.io/posts/2023/05/extracting-ddosia-targets-from-process-memory/\r\nPage 2 of 6\n\nFigure 3 - Exploring DDosia executable control flow\r\nExploring the process execution, it’s possible to observe that WSAStartup API is called two times before starting\r\nthe attack. The first one has been used from the main thread to perform the authentication process on the server side,\r\ninstead the second call will be done right after retrieving the target file and it will be used from another thread to start\r\nthe attack phase. Since that information we are looking for has been already downloaded and hopefully decrypted (at\r\nthe time of the second call) we could explore the process memory trying to identify our target list.\r\nFigure 4 - Target stored in cleartext within process memory\r\nAs we expected, information is actually decrypted right before being used from threads that are in charge to flood the\r\ntargets. From the cleartext sample, it’s also possible to reconstruct the original json file structure that follow this format:\r\nAt this point I have shown all procedures to quickly follow the execution flow until the decryption routine is called.\r\nFrom now on, it’s just a matter of looking for those data within process memory and extracting them for your own\r\npurpose. It’s worth noting that information won’t be stored decrypted forever, in fact, as the executable keeps running,\r\nthe json file is actually mangled in a way that is not easy to resemble it properly.\r\nA little bit of automation\r\nhttps://viuleeenz.github.io/posts/2023/05/extracting-ddosia-targets-from-process-memory/\r\nPage 3 of 6\n\nEven if the analysis has been completed and targets are correctly retrieved, I thought that giving a little tool to extract\r\nthat information would be useful. Instead of doing complex stuff, I wrote two simple scripts called targets.js and\r\nrecover.py. The purpose of these two files is to allow analysts from different backgrounds to extract those targets, even\r\nperforming a simple memory dump. Probably there are easier and smarter techniques out there, but it was also a good\r\nchance to put in practice DBI, which I have already covered in a previous post.\r\ntarget.js: Frida script that aims to get a memory dump after the WSAStartup has been called for the second time\r\n(when payloads are in cleartext in memory).\r\nrecover.py: it’s a simple python script that retrieves structured information from the files dumped. It’s worth\r\nnoting that I limited my script to look for structured information, retrieving IP and Hostname (additional\r\nimprovements are left to user’s needs).\r\nScript Testing\r\nIn order to run the mentioned scripts there are two requirements to fulfill:\r\nInstalling frida-tool (pip install frida-tools).\r\nCreate a folder named “dumps” in the same place where you run the target.js file.\r\nIf all requirements are satisfied it’s just a matter of running those scripts and getting the results. The first step is to run\r\nfrida.exe, using the targets.js file that contains all the information to dump the process memory:\r\nIf everything has been done correctly (please keep in mind the requirements), you should be able to see a message\r\n“[END] Memory dumped correctly” in your console.\r\nFigure 5 - Dumping process Memory with Frida\r\nNow you can navigate in dumps folder and run the python script using the following command line that is going to\r\nforward all dumped file from the current directory to the script that is going to print the result in your console:\r\nhttps://viuleeenz.github.io/posts/2023/05/extracting-ddosia-targets-from-process-memory/\r\nPage 4 of 6\n\nFigure 6 - Extracting DDosia targets from dump files\r\nFinal Notes\r\nBefore concluding, It’s worth mentioning that updates on these scripts and new techniques to dealing with further\r\nimprovements of DDosia project are not going to be shown, because it represents a topic that I’m not following\r\npersonally and I’m sure that more authoritative voices will keep track of this threat and its evolution.\r\n[2023-11 - UPDATE ]\r\nAs mentioned in the section above I’m not able to provide updates on real-time DDosia Project changes, but since it\r\nrepresents a quite good challenge to sharpen my reversing skills on GO binaries (and I received unexpected feedback\r\nabout this work), I decided to look in their new Windows client version.\r\nSince I would like to keep this update note as brief as possible, I’ll go straight to the point. What really changes and\r\nmakes the previous frida script ineffective are slightly binary improvements (mostly related to the syscalls used).\r\nBecause of that I tried to switch monitored syscall to WriteConsoleW, hooking on the message that confirmed the\r\nnumbers of targets retrieved. I found out that I really needed to change 1 line of the previous script to keep it updated.\r\n(Great example of code reuse xD).\r\nNote:\r\nThe modification required was pretty easy, however, this change could be also more consistent for further updates\r\n(limiting to tweak a little bit with counter variable) since it exploits the feedback messages (e.g., target acquired,\r\nrequests completed, rewards, etc..) that won’t be removed any time soon.\r\nMoreover, most of this blogpost it’s still a valid reference for setting up the environment and understanding the control\r\nflow to retrieve the actual targets, additionally, as far as I know, there were no great changes on the authentication layer.\r\nPrevious configured environments needs to replace the old binary to the newer provided on DDosia channel.\r\nNew frida script: console.js\r\nReferences:\r\nFileName Sha256 Date\r\nd_windows_amd64.exe 726c2c2b35cb1adbe59039193030f23e552a28226ecf0b175ec5eba9dbcd336e 2023/04/19\r\n(new sample)\r\nd_win_x64.exe\r\n1b53443ebaabafd6f511d4cf7cb85ddf9fa32540c5dd5621f04a3c5eefa663a9 2023/11/09\r\nhttps://viuleeenz.github.io/posts/2023/05/extracting-ddosia-targets-from-process-memory/\r\nPage 5 of 6\n\nSource: https://viuleeenz.github.io/posts/2023/05/extracting-ddosia-targets-from-process-memory/\r\nhttps://viuleeenz.github.io/posts/2023/05/extracting-ddosia-targets-from-process-memory/\r\nPage 6 of 6", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://viuleeenz.github.io/posts/2023/05/extracting-ddosia-targets-from-process-memory/" ], "report_names": [ "extracting-ddosia-targets-from-process-memory" ], "threat_actors": [ { "id": "b05a0147-3a98-44d3-9b42-90d43f626a8b", "created_at": "2023-01-06T13:46:39.467088Z", "updated_at": "2026-04-10T02:00:03.33882Z", "deleted_at": null, "main_name": "NoName057(16)", "aliases": [ "NoName057", "NoName05716", "05716nnm", "Nnm05716" ], "source_name": "MISPGALAXY:NoName057(16)", "tools": [], "source_id": "MISPGALAXY", "reports": null } ], "ts_created_at": 1775434879, "ts_updated_at": 1775792064, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/128916fe29c9aefd387f552be1049b59cda90c5d.pdf", "text": "https://archive.orkl.eu/128916fe29c9aefd387f552be1049b59cda90c5d.txt", "img": "https://archive.orkl.eu/128916fe29c9aefd387f552be1049b59cda90c5d.jpg" } }