{ "id": "bd8fca59-278b-4edc-be2a-8cf7131d0312", "created_at": "2026-04-06T00:14:05.122689Z", "updated_at": "2026-04-10T03:33:41.112669Z", "deleted_at": null, "sha1_hash": "ca4bb5ad760457166ffcf906f6f6933ce099701b", "title": "Dad! There’s A Rat In Here!", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 2916458, "plain_text": "Dad! There’s A Rat In Here!\r\nBy asuna amawaka\r\nPublished: 2020-03-15 · Archived: 2026-04-05 13:17:47 UTC\r\nAs promised in my last post, I’ll be doing a walkthrough of the DADSTACHE sample fetched by the maldoc\r\n(MD5: 571efe3a29ed1f6c1f98576cb57db8a5) found off VirusTotal in late Feb 2020. After completing my\r\nanalysis, I realized that a thorough “walkthrough” is not necessary as the beaconing code logic is simple enough. I\r\nthink the toughest part was to make IDA Pro take in the final payload encrypted within the sample so that I can do\r\nstatic analysis. Hence, I decided to dedicate most of this post to my approach to unveiling the final payload ;) The\r\nsecond half would be a documentation of my findings.\r\nDADSTACHE sample analysed:\r\n009a9f7024c4dd5db8e3d793be3e99c0 dbgeng.dll\r\nLet’s Tuck In!\r\nThere are 2 exported functions, we can quickly see that DebugCreate is the interesting one, with tell-tale API calls.\r\nhttps://medium.com/insomniacs/dad-theres-a-rat-in-here-e3729b65bf7a\r\nPage 1 of 10\n\nLooks like an AES encryption, using 0x40 bytes as a “seed” to derive the key. The easiest way to arrive at the\r\ndecrypted content is to run the sample and read the decrypted content from memory.\r\nThe content hardcoded in offset 100127B4 looks like this:\r\nhttps://medium.com/insomniacs/dad-theres-a-rat-in-here-e3729b65bf7a\r\nPage 2 of 10\n\nAfter decryption, the following content is seen:\r\nContinuing dynamic analysis showed that the decrypted payload is mapped into memory and then its OEP is\r\ncalled.\r\nNow, I would like to analyze the actual payload with IDA Pro, but the content dumped from memory doesn’t look\r\nlike a proper PE file and hence the IAT can’t be recognized (though I can actually see the import table in there).\r\nDump \u0026 Fix\r\nhttps://medium.com/insomniacs/dad-theres-a-rat-in-here-e3729b65bf7a\r\nPage 3 of 10\n\nDump the decrypted file after it has been mapped to memory in sub_10001920. A good place to do this would be\r\nafter this function ends.\r\nRepairing the decrypted file’s PE header\r\nThe first 0x11C bytes of this extracted memory looked “wrong” — I would expect it to be following the structure\r\nof a PE header, but the “DOS Header” and part of the “NT Header” are missing. I can kind of recognize some of\r\nthe fields in the “NT Header” from this chunk, which means that the content before these fields are intentionally\r\n“corrupted”.\r\nI confirmed that these 0x11C bytes are not some kind of meaningful shell code:\r\nhttps://medium.com/insomniacs/dad-theres-a-rat-in-here-e3729b65bf7a\r\nPage 4 of 10\n\nFrom the dynamic analysis done up to this point, the OEP of the decrypted file in binary is 0x57E4 (called from\r\nthe function sub_10001FF0). This helps to confirm that the PE header is only corrupted up till the “Machine” field\r\nin the “NT Header”.\r\nSo, let’s fix it! I’m going to copy the PE header of the parent binary, which is only 0x10C in size before the\r\n“Machine” field, to overwrite the corrupted 0x11C of header. Since we don’t care about what is actually in this\r\nheader, other than the offset e_lfanew that needs to be corrected, I’m just going to pad 0x10 worth of values so as\r\nnot to mess up all the other offsets (like the import table address) in the file. Of course, you may also wish to just\r\nfill up 0x11C bytes of your choice, just need to be sure the “MZ” “PE” and e_lfanew are correct.\r\nhttps://medium.com/insomniacs/dad-theres-a-rat-in-here-e3729b65bf7a\r\nPage 5 of 10\n\nNow, using a tool like CFF Explorer would help to confirm if the edits have been successful. The last step is to fix\r\nthe section raw addresses so that IDA Pro will be able to do its magic for us. A trick that I usually apply to binaries\r\nthat I dumped from memory, is to copy the values from the “Virtual Address” column to the “Raw Address”\r\ncolumn.\r\nWith this, the import/export table would be nicely pointed to.\r\nSince the RICH header portion of the PE header is lost, we are not able to perform analysis on that. Fortunately,\r\nthere’s still one value that is intact, and that is the compilation date: 23 Dec 2019 17:15:32. This file is compiled\r\nabout 1 hour before its parent file (which has compilation timestamp 23 Dec 2019 18:17:44). This might suggest\r\nthat the file is manually compiled into the parent file, and not through a generator.\r\nhttps://medium.com/insomniacs/dad-theres-a-rat-in-here-e3729b65bf7a\r\nPage 6 of 10\n\nGet asuna amawaka’s stories in your inbox\r\nJoin Medium for free to get updates from this writer.\r\nRemember me for faster sign in\r\nFinally, DADSTACHE\r\nThe first thing that the malware does is to update its configuration placeholder with the actual configuration\r\n(decrypted above).\r\nThen it proceeds to do the beaconing, which comprises of AES-encrypted contents within HTTP POST requests.\r\nAES Encrypted Network Communication\r\nOne point to note is that the configuration within the malware decides whether the HTTP requests will be wrapped\r\nwith SSL or not. It is an additional layer of “security” for the C2 communications. Regardless, we’ll look at what\r\nis sent to and expected from the C2.\r\nThe following structure is AES-encrypted then sent to the C2. The AES key is found within the configuration data.\r\nhttps://medium.com/insomniacs/dad-theres-a-rat-in-here-e3729b65bf7a\r\nPage 7 of 10\n\nA quick python script can help with confirming that the content sent to the C2 is indeed AES-encrypted with the\r\nkey from the configuration data.\r\nOnce there is a status 200 response from the C2 server for the above beacon, the malware will then proceed to do\r\nfurther information collection, and await commands from the C2.\r\nThe following information are being collected from the victim’s machine and then written into\r\n%temp%\\\\~liscen3.tmp:\r\nRecent files\r\nInstalled programs\r\nDrives\r\nCount of cursor staying in one position\r\nOne of the information collected is to count the number of times that the cursor stayed in one position on screen\r\n— I suspect this is for the attacker to know if the binary is being executed in a sandbox instead of a real victim.\r\nhttps://medium.com/insomniacs/dad-theres-a-rat-in-here-e3729b65bf7a\r\nPage 8 of 10\n\nThe content to send to the C2 would be read from %temp%\\\\~liscen3.tmp into a buffer and then the file is deleted.\r\nBefore sending the above in another AES-encrypted POST request, an additional 0x208 bytes of data (path of\r\n~liscen3.tmp and “Client\\\u003cip\u003e_\u003ccomputername\u003e\\Disinfo.txt”), followed by 8 bytes to indicate the start and end\r\noffsets of collected data within ~liscen3.tmp, are pre-pended to the buffer.\r\nThe Command ID received from the C2 server is not expected to be encrypted, but the parameters used within the\r\ncommand are AES-encrypted with the same key as configured within the malware.\r\nPress enter or click to view image in full size\r\nhttps://medium.com/insomniacs/dad-theres-a-rat-in-here-e3729b65bf7a\r\nPage 9 of 10\n\nIf there are no commands received from the C2 server for a period of time (up to 3 seconds), the malware sends a\r\nGET request for /list_direction to the C2, possibly as an attempt to get a new command.\r\nAfter-analysis thoughts\r\nThere we go, a straight-forward and light-weight RAT. The next thing I would like to do is to compare this latest\r\nDADSTACHE sample with the older ones, and other malware families known to be used by APT40. Who knows\r\nwhat interesting findings await?\r\n~~\r\nDrop me a DM if you would like to share findings or samples ;)\r\nSource: https://medium.com/insomniacs/dad-theres-a-rat-in-here-e3729b65bf7a\r\nhttps://medium.com/insomniacs/dad-theres-a-rat-in-here-e3729b65bf7a\r\nPage 10 of 10", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia", "ETDA" ], "references": [ "https://medium.com/insomniacs/dad-theres-a-rat-in-here-e3729b65bf7a" ], "report_names": [ "dad-theres-a-rat-in-here-e3729b65bf7a" ], "threat_actors": [ { "id": "16f2436b-5f84-44e3-a306-f1f9e92f7bea", "created_at": "2023-01-06T13:46:38.745572Z", "updated_at": "2026-04-10T02:00:03.086207Z", "deleted_at": null, "main_name": "APT40", "aliases": [ "ATK29", "Red Ladon", "MUDCARP", "ISLANDDREAMS", "TEMP.Periscope", "KRYPTONITE PANDA", "G0065", "TA423", "ITG09", "Gingham Typhoon", "TEMP.Jumper", "BRONZE MOHAWK", "GADOLINIUM" ], "source_name": "MISPGALAXY:APT40", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "83025f5e-302e-46b0-baf6-650a4d313dfc", "created_at": "2024-05-01T02:03:07.971863Z", "updated_at": "2026-04-10T02:00:03.743131Z", "deleted_at": null, "main_name": "BRONZE MOHAWK", "aliases": [ "APT40 ", "GADOLINIUM ", "Gingham Typhoon ", "Kryptonite Panda ", "Leviathan ", "Nanhaishu ", "Pickleworm ", "Red Ladon ", "TA423 ", "Temp.Jumper ", "Temp.Periscope " ], "source_name": "Secureworks:BRONZE MOHAWK", "tools": [ "AIRBREAK", "BlackCoffee", "China Chopper", "Cobalt Strike", "DadJoke", "Donut", "FUSIONBLAZE", "GreenCrash", "Meterpreter", "Nanhaishu", "Orz", "SeDll" ], "source_id": "Secureworks", "reports": null }, { "id": "59be3740-c8c7-47aa-84c8-e80d0cb7ea3a", "created_at": "2022-10-25T15:50:23.481057Z", "updated_at": "2026-04-10T02:00:05.306469Z", "deleted_at": null, "main_name": "Leviathan", "aliases": [ "MUDCARP", "Kryptonite Panda", "Gadolinium", "BRONZE MOHAWK", "TEMP.Jumper", "APT40", "TEMP.Periscope", "Gingham Typhoon" ], "source_name": "MITRE:Leviathan", "tools": [ "Windows Credential Editor", "BITSAdmin", "HOMEFRY", "Derusbi", "at", "BLACKCOFFEE", "BADFLICK", "gh0st RAT", "PowerSploit", "MURKYTOP", "NanHaiShu", "Orz", "Cobalt Strike", "China Chopper" ], "source_id": "MITRE", "reports": null } ], "ts_created_at": 1775434445, "ts_updated_at": 1775792021, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/ca4bb5ad760457166ffcf906f6f6933ce099701b.pdf", "text": "https://archive.orkl.eu/ca4bb5ad760457166ffcf906f6f6933ce099701b.txt", "img": "https://archive.orkl.eu/ca4bb5ad760457166ffcf906f6f6933ce099701b.jpg" } }