Delegation is a powerful feature of Windows authentication which allows one remote system to effectively forward a user's credentials to another remote system. This is sometimes referred to as the "double-hop". This great power does not come without great risk however, as the delegation access tokens used for this purpose can be stolen by attackers and used for lateral movement. As such, it's important to be aware of this ability and to increase monitoring for malicious use of delegation.
In order to monitor delegation activity, you need to identify where delegation is occurring. Then from those in-scope systems where delegation occurs, look for suspicious activity, and potentially identify which users' accounts were actually delegated. I'll take you through these identification steps, but first let's start with a quick refresher on delegation. This should give you most of the background you need, although you can get even more details about the delegation process in
Initially identified fifteen years ago, and clearly articulated by a Microsoft Security Advisory, DLL hijacking is the practice of having a vulnerable application load a malicious library (allowing for the execution of arbitrary code), rather than the legitimate library by placing it at a preferential location as dictated by the Dynamic-Link Library Search Order which is a pre-defined standard on how Microsoft Windows searches for a DLL when the path has not been specified by the developer.
Despite published advice on secure development practices to mitigate this threat, being available for several years, this still remains a problem
Scammers, intruders and other miscreants often aim to conceal their actions from forensic investigators. When analyzing an IT support scam, I interacted with the person posing as the help desk technician. He brought up a web page on the victim's system to present payment form, so the person would supply contact and credit card details. He did this in a surprising manner, designed to conceal the destination URL.
During the examination of malicious files, you might encounter shellcode that will be critical to your understanding of the adversary's intentions or capabilities. One way to examine this malicious code is to execute it using a debugger after setting up the runtime environment to allow the shellcode to achieve its full potential. In such circumstances, it's helpful to take control of the instruction pointer to direct the debugger towards the code you wish to examine.
The modern computer has been designed to make life easy for the standard user. It is actually quite difficult to say to the computer "Hey, I've found some shellcode embedded in a file, could you run it for me?", and for good reason! If you don't get it exactly right, the chances are you're going to end up crashing something.
Scenario walkthrough - Analysing embedded shellcode
I have devised a simplified scenario which will allow us to consider how to analyse shellcode embedded ...
During the analysis of malicious documents designed to exploit vulnerabilities in the programs which load them (thereby allowing the running of arbitrary code), it is often desirable to review any identified shellcode in a debugger. This allows an increased level of control and flexibility during the discovery of it's capabilities and how it implements the payload of the attack.
MalHost-Setup, part of the OfficeMalScanner suite allows the analyst to generate an executable which runs the shellcode embedded in malicious documents. To use this tool, we first need to determine the offset within the infected document, or extracted OLE file at which the shellcode begins, we then specify this offset as a parameter to MalHost-Setup when generating the executable. This executable can then be loaded into a debugger,