Latest news about Bitcoin and all cryptocurrencies. Your daily crypto news habit.
Introduction
Danderspritz, NSA post-exploitation tool, has some interesting reconnaissance scripts, which were used in covert operations. Basically, they gather as much information as possible about drivers, memory, network traffic (DSky) or PSP (Personal Security ProductâââAV software).
Most of the scripts are in âOpsâ directory, inside âWindowsâ catalog which deserve additional attention, you can find full list here.
How to setup lab, run Fuzzbunch and Danderspritz here.
Everything was said about this framework, so I will focus only on post-exploitation modules. At the end of article, I will show how to write your own plugin, so bear with me.
Photo by Jefferson Santos on Unsplash
Not every tool can be accessed in Danderspritz at the beginning, you have to add an alias to make it work, example with SimonTatham module.
and after that it can be used with given alias. You can also execute it by typing âpython windows\SimonTatham.pyâ
SimonTatham module is responsible for getting session and credentials to WinSCP by looking in registry and storage. This module can be also accessed in Overseer.
Reboot history
In some cases persistent may be not necessary knowing that system is rebooted once per year. Moreover, together with other environmental data it may be used as sandbox detection. Script uses couple sources in order to determine history of rebootâââeventlogs, dumps, registry keys, and logfiles. Also It checks for Dr. Watson logs, which is error troubleshooting tool for old version of Windows, to gather even more information about OS.
Event logs
File reboothistory.py contains 12 functions responsible for retrieving and parsing information regarding reboot history. First one looks into event logs for following IDs:
- 6005âââEvent log startup
- 6006âââEvent log service was stoppped
- 6008âââLast shutdown was unexpected
- 6009âââUser restarted or shut down system
- 1001âââApplication crashed or hung
- 1074âââSystem shut down or restarted by other task
- 109âââShutdown by kernel power manager
- 42âââSystem went into sleep mode
- 41âââShutdown during sleep mode(?)
- 13âââProper shutdown(?)
- 12âââSystem started
Some of the IDs are weakly documented, but from what I found every one refer to restart, shutdown OS by user, other task or kernel. Also sleep mode wasnât omitted during checks.
In addition, boot log is created, which means it measures systemâs boot, shutdown and up time based on specific event IDs.
Code measuring boot timeRegistry, dumps and logs
As previously mentioned script checks for presence of specific registry entries and files to examine reboot history.
âHKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CrashControlâ is key that include useful information about unexpected applications behavior like crashes or hangs, extracted values are âDumpsâ and âMinidumpsâ.
When path is extracted from registry it calls checkdumps function in order to retrieve metadata from dump.
Function âcheckdumpsâ looks for files with extension .DMP in %%SystemRoot%% directory and finally displays metadata of found files. Dump file keeps memory dump of Windows crashes but in this case content is not important, only metadata like âModifiedâ, âAccessedâ, âCreatedâ are gathered.
Retrieving metadata from dump files
Windows Error Reporting (WER) functionality is also abused to retrieve errors and crashes information, from current user as well as from local machine, the information about WER can be found in software\\microsoft\\windows\\windows error reporting and ReportQueue is in Microsoft\\Windows\\WER\\ReportQueue
âCheckdirtyshutdownâ looks for registry key in âsoftware\microsoft\windows\currenversion\reliabilityâ, which tracks every shutdown. The most important keys here are DirtyShutdown and DirtyShutdownTime, more details about this keys.
Windows server logs every shutdown into âWindows\system32\logfiles\shutdownâ, this location is also checked in function âcheckshutdownlogfilesâ.
Dr. Watson is a tool for Windows 98, Millennium and XP and can help you troubleshoot issues with application by creating system snapshot and then analyze it.
What is interesting here, script checks only â%%allusersprofile%%\documents\DrWatsonâ directory, which is correct for Windows 2000. In XP and ME, paths are âAll Users\Application Data\Microsoft\Dr Watsonâ and âC:\Windows\Drwatsonâ adequately. It might indicate that script wasnât regularly updated even at that time.
You can find full script here https://github.com/francisck/DanderSpritz_docs/blob/master/Ops/PyScripts/windows/reboothistory.py
User query
This module tracks signs of activity of Windows Media Player, Internet Explorer, Remote Desktop Protocol and others. Check can be done for specific user or for every user in system. It achieves that by iterating through HKEY\USERS and picking Security Identifier Number (SID) between 42 and 49 characters. Additional, one function can convert SID to user name by using sidlookup command.
Windows Media Player last files are accessed by querying key Software\Microsoft\MediaPlayer\Player\RecentFileList. It is simple way to hijack what user was watching recently and then inspect it in details.
Only Internet Explorer is targeted in this reconnaissance script and last typed urls are gathered. Itâs worth to note that Ripper, other script from collection, is responsible for retrieving credentials, storage and history of other browsers. The key which is used in this case is Software\Microsoft\Internet Explorer\TypedURLs.
Even last Windows popups are in interest of script. It queries Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSaveMRU to get list of files that were accessed in Windows dialog popups i.e. during download or save.
Another interesting functionality is USB monitoring, in some cases it can proof that two separate people plugged this same USB stick or phone into his computer. Last connected devices can be found in SYSTEM\\CurrentControlSet\\Control\\DeviceClasses\\{53f56307-b6bf-11d0â94f2â00a0c91efb8b and itâs only key checked, however also {53f5630d-b6bf-11d0â94f2â00a0c91efb8b} class keeps history of connected removable devices. Moreover, this way may allow to detect virtual environment.
It has something common with next, very precise functionââââstart_runâ. Registry keeps track of your last commands, or displayed hints in autocomplete box in Windows Run. The responsible key is Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU.
UserAssist is next Windows functionality that collects detailed information about operating system and its usage. Precisely speaking, key SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\UserAssist keeps metadata like timestamp, number of execution or path to executed software on machine. Its structure requires couple words of introduction, in registry, key (path) is ROT13 encoded and value is binary representation of information data. This value is different for various systems, for 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, as well as for focus time value.
What you can dig from binary is number of execution (bytes 4â8 bytes), focus time (bytes 12â16) and timestamp (bytes from 60 to 68).
To find this module, we need to dig little deeper to another project called âdszâ, which then calls âhistoryâ and âUser Assistâ modules. https://github.com/francisck/DanderSpritz_docs/blob/master/Ops/PyScripts/windows/userquery.py#L45 (More about modules and structure later on).
This project required decompilation but after that, python code became easily readable. Below code clearly shows how described data are retrieved for Windows 7.
Obtaining data from UserAssist
Of course, script saves ROT13 decoded path of executed file and other useful data as well, I strongly encourage you to read about User Assist possibility in forensics and general usage here
You can turn off this feature in your system by setting key named âSettingsâ and creating DWORD with name âNoLogâ and value 1.
Last thing is history of RDP connections, whole cache is Software\Microsoft\Terminal Server Client\Default
Full scriptâââhttps://github.com/francisck/DanderSpritz_docs/blob/master/Ops/PyScripts/windows/userquery.py
PersistenceâââSurvey
If you donât know it already, each time when DanderSpritz connects to the target, survey takes place. It is bunch of python scripts trying to gather as much detailed information about environment, where implant is already installed. It has modular design, which means each script is in separate file in âlib/ops/surveyâ directory. Among others modules, persistence checking is present. The idea behind this module is simple, it investigates what software are running during startup. Itâs kind of similar to TeritorialDispute (TeDi) which looks for indicator of compromise of known malware and other APT groups. Now, letâs try focus more on structure of the code itself, first executed file is launcher.py from âsurvey/launcher.pyâ. The most important parameter it gets is ââââmoduleâ, which is obvious.
After some basic arguments and path checks, method âplugin_launcherâ is called with given parameters. Worth to highlight is that parameter âbgâ stands for âbackgroundâ and allows to execute script in background.
âplugin_launcherâ also parses flags and if everything is fine, it executes specific module with help of runpy.
The actual persistence.py script is in lib/ops/survey and takes only one parameter ââââmaxageâ which stands for âMaximum age of information to use before re-running commands for this moduleâ and is 3600 by default.
It contains dictionaries with registry keys, values to check and known good values. However, there is no checks for schedule task. In addition, paths to %Program Files%, %AllUsersProfile% and %WINROOT% are generated but no used in script.
Following items were extracted from script:
- system\\currentcontrolset\\Services\\tcpip\\Parameters\\WinsockâââValue to checkâââHelperDllName, known goodsââââwshtcpip.dllâ, â%%SystemRoot%%\\System32\\wshtcpip.dllâ
- Software\\Microsoft\\Windows NT\\CurrentVersion\\WindowsâââValue to checkâââAppInit_Dlls
- Software\\Microsoft\\Windows NT\\CurrentVersion\\winlogonâââValues to checkâââShell, Userinit, known goodsââââexplorer.exeâ, ââC:\\Windows\\system32\\userinit.exeâ
- Software\\Microsoft\\Windows\\CurrentVersion\\Run[OnceEx]âââknown goodsâââVMware Toolsâ: ââC:\\Program Files\\VMware\\VMware Tools\\VMwareTray.exeââ, âVMware User Processâ: ââC:\\Program Files\\VMware\\VMware Tools\\VMwareUser.exeâ
- Software\\Microsoft\\Windows NT\\CurrentVersion\\AppCompatFlags\\Custom
- %%SystemRoot%%\AppPatch\Custom
What is interesting here, it executes âdirâ on %%SystemRoot%%\AppPatch\Custom. I found one case when this method was used for persistence, however it was 1 year ago. First Black Hat talk has occurred in 2016 but script is quite older than thatâââ2013
So 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 way. So situation looks identical with âregistryqueryâ command, which retrieves mentioned registry keys.
This one is straightforward, it creates new instance of getDszCommand, which refers to DanderSpritZ command and then checks if results havenât been cached.
Structure of system commands like âdirâ, âregistryqueryâ or âprocessesâ is organized this same way as plugins for survey but each module is in lib\ops\cmd directory. âgetDszCommandâ method parses delivered commands and after that it imports specified plugin from ops\cmd. At the end it returns callable object, as itâs presented on below screenshot.
Returned object is checked against cache database in method âgeneric_cache_getâ (2 screenshots up) in ops\project. For each project local database is created and goal of âgeneric_cache_getâ is to check db cache based on proper tags and target ID https://github.com/francisck/DanderSpritz_docs/blob/86bb7caca5a957147f120b18bb5c31f299914904/Ops/PyScripts/lib/ops/project/__init__.py#L274.
I will omit this part, itâs subject for separate article. After all of checks, finally actual command is execute by calling command.execute() method. Command object was given from âgetDszCommandâ and include âexecuteâ method.
Finally, actual command is executed with help of â_actual_executeâ method, you can see that RunEx in called from dsz\cmd, which refers to another project âdszâ and interact with DanderSpritz directly, you can find decompiled code of dsz\cmd.py here.
At the end lets look at execution flow of persistence Survey.
Writing own post exploitation Danderspritz modules
Now, we are armored with all necessary information to build our own plugin. Scripts collection contains almost everything but I found no checks for virtual machines and last connected networks. To obtain information about first of them we need to go to [username]\Documents\Virtual Machines directory. Details about connected networks are located in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles\ID.
Output of checking last connected network and virtual machinesRetrieving network information
This might be helpful to track victim travels based on his WIFI SSID in for example hotels. Network name, last connected time and category are the most interesting fields. Places that stores network profiles are Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles\ID, SOFTWARE\Microsoft\Widows\CurrentVersion\HomeGroup\NetworkLocations\Home and windows\system32\networkprofiles. We can use second one to obtain profile ID and then pass it to retrieve more detailed information about each profile. At the end script shows nice output thanks to pprint function.
Code for checking last connected networksVirtual machines
Itâs always good to know if trojanized machine is used for something more than regular mail checking. It may turn out that it belongs to researcher or contains top secret VMâs
First script enumerates all users in c:\Users folder and then checks if each one has directory âVirtual Machinesâ in his Documents. This example includes interacting with Danderspritz in order to retrieve content of possible found directories. Itâs possible to ask user about next decision, it can be achieved by âdsz.ui.Promptâ method.
Full scriptâââhttps://github.com/woj-ciech/other/blob/master/example.py
Conclusion
As it was shown, the reconnaissance scripts are not rocket science, however there are lot of interesting tricks to gather intelligence from infected machine. Thanks to modular design, Danderspritz can be easily scalable and itâs very simple to write additional plugin and put it into Danderspritz. Iâm not surprised of amount of the reconnaissance scripts, where every information can be priceless and possible save lives.
Inside of Danderspritz post-exploitation modules was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.
Disclaimer
The views and opinions expressed in this article are solely those of the authors and do not reflect the views of Bitcoin Insider. Every investment and trading move involves risk - this is especially true for cryptocurrencies given their volatility. We strongly advise our readers to conduct their own research when making a decision.