6:31 pm (UTC-7) | by Edward Sun (Software Engineer)
The combination of MBR rootkits with Web threats is becoming more and more popular these days, as detailed in this previous post.
Security providers and independent anti-rootkit authors also started to update their solution for the detection of this new rootkit threat. After those detection tools were released to the public, anti-rootkit makers might think the case is over. However the war has never stopped. Over the last weekend, a new MBR rootkit variation got released in the wild with new technology to prevent detection.
In the previous version, the MBR rootkit hooks the dispatch routine of storage driver (like disk.sys) to hide the real content of MBR. The method that anti-rootkits used to detect this is bypassing of this hook. Because the original dispatch routine of storage driver is an unreported routine of Classpnp.sys which called “ClassPnpReadWrite”, this makes it possible for anti-rootkits to bypass the hook via direct calling of “ClassPnpReadWrite”.
In order to call the “ClassPnpReadWrite” directly, anti-rootkit tools like “Gmer” will first locate the address “ClassPnpReadWrite” from Classpnp.sys in the memory. The algorithm they used to locate “ClassPnpReadWrite” address is by searching it with the disassembly code of “ClassInitialize”. Since the “ClassInitialize” is exported and it will reference “ClassPnpReadWrite” internally for initialization, anti-rootkits can easily go over the disassembly code of this routine, to find assembly code corresponding to the following C statement:
DriverObject->MajorFunction[IRP_MJ_READ] = ClassReadWrite;
DriverObject->MajorFunction[IRP_MJ_WRITE] = ClassReadWrite;
Then they get the address of “ClassReadWrite” from the raw assembly code.
However, the MBR rootkit author has discovered this, and made a clever and effective update for anti-rootkit in their new variation. What they did is not hook enhancement or going deeper, but replaced some special data in the assembly code of “ClassInitialize” to make anti-rootkits find the wrong “ClassPnpReadWrite”:
From the above screenshot, we can see the rootkit alternated the MOV instruction with their own address 0x8176742A, which is an address that exceeds Classpnp’s driver range, and an obvious rootkit routine address. With this method, the rootkit then successfully escapes from current anti-rootkits’ detection.
Trend Micro advises users to scan systems using the latest pattern file versions to block the rootkit. The content security feature of our products can block all related domains as well.
Share this article