On the heels of my previous post on this subject, I ran across this little gem from Microsoft regarding the print spooler EOP exploitation. I like articles like this because they illustrate threat actor activities outside the "norm", or what we usually tend to see in open reporting, if such things are illustrated in detail.
Fig 4 (in step 1) in the article illustrates a new printer port being added to a Windows system as a step toward privilege escalation. This serves as one of the more-than-a-few interesting EDR-style tidbits from the article (i.e., detect the Powershell commandline), and also results in a fantastic toolmark that can be applied to DFIR "threat hunting".
The article illustrates, via fig 4, Powershell being used to add a printer port to the system, and that command results in a value being added to the Registry. There are other ways to go about this, of course, and this is only one example of how to achieve adding a printer port to a Windows system. For example, you can use "win32_tcpipPrinterPort" via WMI to add a TCP printer port.
Whichever means is used, the end result is a value being added to the Registry, which means if there is no EDR capability on the system at the time that the port is created, we can still determine if a port was, in fact, created. This would be reflected in a new value being added to the Registry key, and the key LastWrite time being updated accordingly. The RegRipper ports.pl plugin will extract this information, and creating a timeline that includes Registry key LastWrite times will likely show the Registry key modification within the timeline.
Other RegRipper plugins that address toolmarks from open reporting associated with printers on Windows include:
printer_settings.pl - retrieves printer attributes, looking for indications that printers were set to not delete print jobs after they were spooled and sent to the printer (per Project TajMahal open reporting), enabling local data staging.
printprocessors.pl - this open reporting on Winnti indicates that print processors have been used for persistence.
The purpose of this blog post (as well as the previous one) has been to illustrate a means by which open reporting can be incorporated into any analyst's process. In this example, I've shared the names of RegRipper plugins I've created, so that the toolmarks, along with the appropriate MITRE ATT&CK mappings and analysis tips, are always available to me during my analysis. As I've included the online resources in the headers of the plugins, I have those resources available should I need to refer to them. Overall, this adds breadth, depth, and most importantly, consistency to my analysis process, letting me get to the actual analysis much sooner. From this point, I can then curate any new findings or lessons learned based on that analysis, and bake that back into my process, extending that capability yet again.
There are, of course, other means to go about baking new findings and lessons learned back into your analysis process. However, it depends largely upon what you're able to ingest or incorporate. For example, if you're doing malware analysis or any sort of log analysis, Yara rules might provide a good option for you. The Nuix Investigate product includes extensions for both RegRipper and Yara rules, extending the capabilities of the product.
Yet another means is to use something like wevtx.bat, which uses eventmap.txt to provide a small modicum of enrichment to specific Windows Event Log records as they're added to a timeline.
These are all very basic means for extending your current analysis process with new toolmarks from open reporting, as well as baking new findings and lessons learned back into the process.
No comments:
Post a Comment