{
	"id": "7f42e72b-a38c-4939-b624-551ee028f5b5",
	"created_at": "2026-04-06T00:08:46.803379Z",
	"updated_at": "2026-04-10T03:22:03.870085Z",
	"deleted_at": null,
	"sha1_hash": "f817b88484abc2ca00c0fd022a74dfcd6b3e0167",
	"title": "Inside of Danderspritz post-exploitation modules",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 609845,
	"plain_text": "Inside of Danderspritz post-exploitation modules\r\nBy Wojciech\r\nPublished: 2020-04-04 · Archived: 2026-04-05 18:12:42 UTC\r\nDanderspritz, NSA post-exploitation tool, has some interesting reconnaissance scripts, which were used in covert operations.\r\nBasically, they gather as much information as possible about drivers, memory, network traffic (DSky) or PSP (Personal\r\nSecurity Product — AV software).\r\nMost of the scripts are in “Ops” directory, inside “Windows” catalog which deserve additional attention, you can find full list\r\nhere.\r\nHow to setup lab, run Fuzzbunch and Danderspritz here.\r\nEverything was said about this framework, so I will focus only on post-exploitation modules. At the end of article, I will\r\nshow how to write your own plugin, so bear with me.\r\nNot every tool can be accessed in Danderspritz at the beginning, you have to add an alias to make it work, example with\r\nSimonTatham module.\r\nAdding alias in Danderspritz\r\nand after that it can be used with given alias. You can also execute it by typing “python windows\\SimonTatham.py”\r\nSimonTatham module is responsible for getting session and credentials to WinSCP by looking in registry and storage. This\r\nmodule can be also accessed in Overseer.\r\nReboot history\r\nIn some cases persistent may be not necessary knowing that system is rebooted once per year. Moreover, together with other\r\nenvironmental data it may be used as sandbox detection. Script uses couple sources in order to determine history of reboot\r\n— eventlogs, dumps, registry keys, and logfiles. Also It checks for Dr. Watson logs, which is error troubleshooting tool for\r\nold version of Windows, to gather even more information about OS.\r\nEvent logs\r\nFile reboothistory.py contains 12 functions responsible for retrieving and parsing information regarding reboot history. First\r\none looks into event logs for following IDs:\r\n6005 — Event log startup\r\n6006 — Event log service was stoppped\r\n6008 — Last shutdown was unexpected\r\n6009 — User restarted or shut down system\r\n1001 — Application crashed or hung\r\n1074 — System shut down or restarted by other task\r\n109 — Shutdown by kernel power manager\r\n42 — System went into sleep mode\r\n41 — Shutdown during sleep mode(?)\r\n13 — Proper shutdown(?)\r\n12 — System started\r\nhttps://www.offensiveosint.io/inside-of-danderspritz-post-exploitation-modules/\r\nPage 1 of 10\n\nReboot history\r\nSome of the IDs are weakly documented, but from what I found every one refer to restart, shutdown OS by user, other task\r\nor kernel. Also sleep mode wasn’t omitted during checks.\r\nIn addition, boot log is created, which means it measures system’s boot, shutdown and up time based on specific event IDs.\r\nCode measuring boot time\r\nRegistry, dumps and logs\r\nAs previously mentioned script checks for presence of specific registry entries and files to examine reboot history.\r\n“HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\CrashControl” is key that include useful information about\r\nunexpected applications behavior like crashes or hangs, extracted values are “Dumps” and “Minidumps”.\r\nChecking crashcontrol\r\nWhen path is extracted from registry it calls checkdumps function in order to retrieve metadata from dump.\r\nFunction ‘checkdumps’ looks for files with extension .DMP in %%SystemRoot%% directory and finally displays metadata\r\nof found files. Dump file keeps memory dump of Windows crashes but in this case content is not important, only metadata\r\nlike ‘Modified’, ‘Accessed’, ‘Created’ are gathered.\r\nhttps://www.offensiveosint.io/inside-of-danderspritz-post-exploitation-modules/\r\nPage 2 of 10\n\nRetrieving metadata from dump files\r\nWindows Error Reporting (WER) functionality is also abused to retrieve errors and crashes information, from current user as\r\nwell as from local machine, the information about WER can be found in software\\\\microsoft\\\\windows\\\\windows error\r\nreporting and ReportQueue is in Microsoft\\\\Windows\\\\WER\\\\ReportQueue\r\n‘Checkdirtyshutdown’ looks for registry key in “software\\microsoft\\windows\\currenversion\\reliability”, which tracks every\r\nshutdown. The most important keys here are DirtyShutdown and DirtyShutdownTime, more details about this keys.\r\nWindows server logs every shutdown into “Windows\\system32\\logfiles\\shutdown”, this location is also checked in function\r\n“checkshutdownlogfiles”.\r\nDr. Watson is a tool for Windows 98, Millennium and XP and can help you troubleshoot issues with application by creating\r\nsystem snapshot and then analyze it.\r\nWhat is interesting here, script checks only “%%allusersprofile%%\\documents\\DrWatson” directory, which is correct for\r\nWindows 2000. In XP and ME, paths are “All Users\\Application Data\\Microsoft\\Dr Watson” and “C:\\Windows\\Drwatson”\r\nadequately. It might indicate that script wasn’t regularly updated even at that time.\r\nDr. Watson check\r\nYou can find full script here\r\nhttps://github.com/francisck/DanderSpritz_docs/blob/master/Ops/PyScripts/windows/reboothistory.py\r\nUser query\r\nThis module tracks signs of activity of Windows Media Player, Internet Explorer, Remote Desktop Protocol and others.\r\nCheck can be done for specific user or for every user in system. It achieves that by iterating through HKEY\\USERS and\r\npicking Security Identifier Number (SID) between 42 and 49 characters. Additional, one function can convert SID to user\r\nname by using sidlookup command.\r\nCheck for all users\r\nhttps://www.offensiveosint.io/inside-of-danderspritz-post-exploitation-modules/\r\nPage 3 of 10\n\nWindows Media Player last files are accessed by querying key Software\\Microsoft\\MediaPlayer\\Player\\RecentFileList. It is\r\nsimple way to hijack what user was watching recently and then inspect it in details.\r\nOnly Internet Explorer is targeted in this reconnaissance script and last typed urls are gathered. It’s worth to note that\r\nRipper, other script from collection, is responsible for retrieving credentials, storage and history of other browsers. The key\r\nwhich is used in this case is Software\\Microsoft\\Internet Explorer\\TypedURLs.\r\nEven last Windows popups are in interest of script. It queries\r\nSoftware\\Microsoft\\Windows\\CurrentVersion\\Explorer\\ComDlg32\\OpenSaveMRU to get list of files that were accessed in\r\nWindows dialog popups i.e. during download or save.\r\nAnother interesting functionality is USB monitoring, in some cases it can proof that two separate people plugged this same\r\nUSB stick or phone into his computer. Last connected devices can be found in\r\nSYSTEM\\\\CurrentControlSet\\\\Control\\\\DeviceClasses\\\\{53f56307-b6bf-11d0–94f2–00a0c91efb8b and it’s only key checked,\r\nhowever also {53f5630d-b6bf-11d0–94f2–00a0c91efb8b} class keeps history of connected removable devices. Moreover,\r\nthis way may allow to detect virtual environment.\r\nUSB devices\r\nIt has something common with next, very precise function — “start_run”. Registry keeps track of your last commands, or\r\ndisplayed hints in autocomplete box in Windows Run. The responsible key is\r\nSoftware\\Microsoft\\Windows\\CurrentVersion\\Explorer\\RunMRU.\r\nUserAssist is next Windows functionality that collects detailed information about operating system and its usage. Precisely\r\nspeaking, key SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\UserAssist keeps metadata like timestamp, number\r\nof execution or path to executed software on machine. Its structure requires couple words of introduction, in registry, key\r\n(path) is ROT13 encoded and value is binary representation of information data. This value is different for various systems,\r\nfor XP, ME it’s 16 bytes and for newer ones is 72 bytes. Script has no checks for Win 95 and 98, where the value is 8 bytes,\r\nas well as for focus time value.\r\nWhat you can dig from binary is number of execution (bytes 4–8 bytes), focus time (bytes 12–16) and timestamp (bytes\r\nfrom 60 to 68).\r\nTo find this module, we need to dig little deeper to another project called ‘dsz’, which then calls ‘history’ and ‘User Assist’\r\nmodules. https://github.com/francisck/DanderSpritz_docs/blob/master/Ops/PyScripts/windows/userquery.py#L45 (More\r\nabout modules and structure later on).\r\nThis project required decompilation but after that, python code became easily readable. Below code clearly shows how\r\ndescribed data are retrieved for Windows 7.\r\nObtaining data from UserAssist\r\nhttps://www.offensiveosint.io/inside-of-danderspritz-post-exploitation-modules/\r\nPage 4 of 10\n\nOf course, script saves ROT13 decoded path of executed file and other useful data as well, I strongly encourage you to read\r\nabout User Assist possibility in forensics and general usage here\r\nYou can turn off this feature in your system by setting key named “Settings” and creating DWORD with name “NoLog” and\r\nvalue 1.\r\nLast thing is history of RDP connections, whole cache is Software\\Microsoft\\Terminal Server Client\\Default\r\nFull script — https://github.com/francisck/DanderSpritz_docs/blob/master/Ops/PyScripts/windows/userquery.py\r\nPersistence — Survey\r\nIf you don’t know it already, each time when DanderSpritz connects to the target, survey takes place. It is bunch of python\r\nscripts trying to gather as much detailed information about environment, where implant is already installed. It has modular\r\ndesign, which means each script is in separate file in “lib/ops/survey” directory. Among others modules, persistence\r\nchecking is present. The idea behind this module is simple, it investigates what software are running during startup. It’s kind\r\nof similar to TeritorialDispute (TeDi) which looks for indicator of compromise of known malware and other APT groups.\r\nNow, let’s try focus more on structure of the code itself, first executed file is launcher.py from “survey/launcher.py”. The\r\nmost important parameter it gets is “ — module”, which is obvious.\r\nAfter some basic arguments and path checks, method “plugin_launcher” is called with given parameters. Worth to highlight\r\nis that parameter “bg” stands for “background” and allows to execute script in background.\r\nlauncher.py\r\nhttps://github.com/francisck/DanderSpritz_docs/blob/86bb7caca5a957147f120b18bb5c31f299914904/Ops/PyScripts/survey/launcher.py\r\n“plugin_launcher” also parses flags and if everything is fine, it executes specific module with help of runpy.\r\nplugin_launcher\r\nThe actual persistence.py script is in lib/ops/survey and takes only one parameter “ — maxage” which stands for “Maximum\r\nage of information to use before re-running commands for this module” and is 3600 by default.\r\nIt contains dictionaries with registry keys, values to check and known good values. However, there is no checks for schedule\r\ntask. In addition, paths to %Program Files%, %AllUsersProfile% and %WINROOT% are generated but no used in script.\r\nFollowing items were extracted from script:\r\nsystem\\\\currentcontrolset\\\\Services\\\\tcpip\\\\Parameters\\\\Winsock — Value to check — HelperDllName, known goods\r\n— ‘wshtcpip.dll’, ‘%%SystemRoot%%\\\\System32\\\\wshtcpip.dll’\r\nSoftware\\\\Microsoft\\\\Windows NT\\\\CurrentVersion\\\\Windows — Value to check — AppInit_Dlls\r\nhttps://www.offensiveosint.io/inside-of-danderspritz-post-exploitation-modules/\r\nPage 5 of 10\n\nSoftware\\\\Microsoft\\\\Windows NT\\\\CurrentVersion\\\\winlogon — Values to check — Shell, Userinit, known goods —\r\n‘explorer.exe’, ‘‘C:\\\\Windows\\\\system32\\\\userinit.exe’\r\nSoftware\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run[OnceEx] — known goods — VMware Tools’: ‘“C:\\\\Program\r\nFiles\\\\VMware\\\\VMware Tools\\\\VMwareTray.exe”’, ‘VMware User Process’: ‘“C:\\\\Program\r\nFiles\\\\VMware\\\\VMware Tools\\\\VMwareUser.exe”\r\nSoftware\\\\Microsoft\\\\Windows NT\\\\CurrentVersion\\\\AppCompatFlags\\\\Custom\r\n%%SystemRoot%%\\AppPatch\\Custom\r\nWhat is interesting here, it executes ‘dir’ on %%SystemRoot%%\\AppPatch\\Custom. I found one case when this method was\r\nused for persistence, however it was 1 year ago. First Black Hat talk has occurred in 2016 but script is quite older than that\r\n— 2013\r\npersistence.py\r\nSo let’s jump into “get_dirlisting” method in lib\\ops\\files\\dirs.py, as far as I’ve learned, each module is executed this same\r\nway. So situation looks identical with ‘registryquery’ command, which retrieves mentioned registry keys.\r\nThis one is straightforward, it creates new instance of getDszCommand, which refers to DanderSpritZ command and then\r\nchecks if results haven’t been cached.\r\nget_dirlisting function\r\nStructure of system commands like ‘dir’, ‘registryquery’ or ‘processes’ is organized this same way as plugins for survey but\r\neach module is in lib\\ops\\cmd directory. “getDszCommand” method parses delivered commands and after that it imports\r\nspecified plugin from ops\\cmd. At the end it returns callable object, as it’s presented on below screenshot.\r\ngetDSZCommand function\r\nReturned object is checked against cache database in method “generic_cache_get” (2 screenshots up) in ops\\project. For\r\neach project local database is created and goal of ‘generic_cache_get’ is to check db cache based on proper tags and target\r\nID\r\nhttps://github.com/francisck/DanderSpritz_docs/blob/86bb7caca5a957147f120b18bb5c31f299914904/Ops/PyScripts/lib/ops/project/__init_\r\nI will omit this part, it’s subject for separate article. After all of checks, finally actual command is execute by calling\r\ncommand.execute() method. Command object was given from ‘getDszCommand’ and include ‘execute’ method.\r\nhttps://www.offensiveosint.io/inside-of-danderspritz-post-exploitation-modules/\r\nPage 6 of 10\n\ngeneric_cache_get function\r\nFinally, actual command is executed with help of ‘_actual_execute’ method, you can see that RunEx in called from dsz\\cmd,\r\nwhich refers to another project ‘dsz’ and interact with DanderSpritz directly, you can find decompiled code of dsz\\cmd.py\r\nhere.\r\nExecuting command\r\nAt the end lets look at execution flow of persistence Survey.\r\nFlow of execution\r\nhttps://www.offensiveosint.io/inside-of-danderspritz-post-exploitation-modules/\r\nPage 7 of 10\n\nWriting own post exploitation Danderspritz modules\r\nNow, we are armored with all necessary information to build our own plugin. Scripts collection contains almost everything\r\nbut I found no checks for virtual machines and last connected networks. To obtain information about first of them we need\r\nto go to [username]\\Documents\\Virtual Machines directory. Details about connected networks are located in\r\nHKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\NetworkList\\Profiles\\ID.\r\nOutput of checking last connected network and virtual machines\r\nRetrieving network information\r\nThis might be helpful to track victim travels based on his WIFI SSID in for example hotels. Network name, last connected\r\ntime and category are the most interesting fields. Places that stores network profiles are\r\nComputer\\HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\NetworkList\\Profiles\\ID,\r\nSOFTWARE\\Microsoft\\Widows\\CurrentVersion\\HomeGroup\\NetworkLocations\\Home and\r\nwindows\\system32\\networkprofiles. We can use second one to obtain profile ID and then pass it to retrieve more detailed\r\ninformation about each profile. At the end script shows nice output thanks to pprint function.\r\nCode for checking last connected networks\r\nVirtual machines\r\nIt’s always good to know if trojanized machine is used for something more than regular mail checking. It may turn out that it\r\nbelongs to researcher or contains top secret VM’s\r\nFirst script enumerates all users in c:\\Users folder and then checks if each one has directory “Virtual Machines” in his\r\nDocuments. This example includes interacting with Danderspritz in order to retrieve content of possible found directories.\r\nIt’s possible to ask user about next decision, it can be achieved by “dsz.ui.Prompt” method.\r\nhttps://www.offensiveosint.io/inside-of-danderspritz-post-exploitation-modules/\r\nPage 8 of 10\n\nVirtual machines check\r\nFull script — https://github.com/woj-ciech/other/blob/master/example.py\r\nConclusion\r\nAs it was shown, the reconnaissance scripts are not rocket science, however there are lot of interesting tricks to gather\r\nintelligence from infected machine. Thanks to modular design, Danderspritz can be easily scalable and it’s very simple to\r\nwrite additional plugin and put it into Danderspritz. I’m not surprised of amount of the reconnaissance scripts, where every\r\ninformation can be priceless and possible save lives.\r\nOriginally published on 20th of November, 2019\r\nhttps://www.offensiveosint.io/inside-of-danderspritz-post-exploitation-modules/\r\nPage 9 of 10\n\nInside of Danderspritz post-exploitation modules\r\nDanderspritz, NSA post-exploitation tool, has some interesting reconnaissance scripts, which were used in\r\ncovert operations. Basically, they gather as much information as possible about drivers…\r\nWojciech\r\nPlease subscribe for early access, new awesome things and more.\r\nSource: https://www.offensiveosint.io/inside-of-danderspritz-post-exploitation-modules/\r\nhttps://www.offensiveosint.io/inside-of-danderspritz-post-exploitation-modules/\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.offensiveosint.io/inside-of-danderspritz-post-exploitation-modules/"
	],
	"report_names": [
		"inside-of-danderspritz-post-exploitation-modules"
	],
	"threat_actors": [],
	"ts_created_at": 1775434126,
	"ts_updated_at": 1775791323,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/f817b88484abc2ca00c0fd022a74dfcd6b3e0167.pdf",
		"text": "https://archive.orkl.eu/f817b88484abc2ca00c0fd022a74dfcd6b3e0167.txt",
		"img": "https://archive.orkl.eu/f817b88484abc2ca00c0fd022a74dfcd6b3e0167.jpg"
	}
}