Patching. Is it always with the best intentions?
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?
