Alex Hinchliffe McAfee
download slides (PDF)
Over the years, malicious software has attempted every trick in the book when it comes to hooking into an operating system, not only to remain persistent at the time of execution but also beyond system reboots.
The forthcoming paper will describe how hooking into the operating system has changed over the years, including some examples of the most 'interesting' methods from MSDOS, early Windows versions and in to present day Windows Vista. Such, somewhat more historical, methods include manipulations of hard disk partitions, critical operating system files and trivial system registry modifications whilst injecting code into running processes, hooking critical startup processes, creating system services and patching memory of running processes are much more contemporary methods.
Patching memory of applications running in a Windows environment is, to a certain extent, what some rootkits do to hide themselves or their behaviour. I will endeavour to cover some of the rudimentary skills such malware uses and the latest vector seen in this area - the patching of ntoskrnl.exe, the Windows NT kernel itself.
Looking ahead to the future of operating system hooking on Windows is the recent trend of patching system binaries on disk. Typical targets are applications like Internet Explorer due to their default existence and obvious prevalence. Research has shown that often such files are manipulated on disk such that subsequent executions cause unwieldy and often unnoticed events to occur. As applications such as Internet Explorer are, by default, innocent many Anti-Virus engines will not exhaustively interrogate them during scanning. So if the integrity of the file has been jeopardised engines rely on some other malicious object to hopefully reveal itself such that they can positively identify malicious behaviour.
With system application integrity in mind must we, as Anti-Virus vendors, monitor 'good' applications such that they remain pure? Must we understand who's attempting such patching behaviour to ensure only the patching for the greater good occurs? Say we don't, but we do remove a piece of malware this patch relies on. This could actually cause other problems for the customer, not to mention our support teams. That said, should we attempt to repair such patching and what are the implications of doing so for the customer and for in-house testing of our products against the myriad of operating system, patch and application combinations?
