Remsec driver analysis - Agnitum driver exploitation

In previous three parts of "Remsec driver analysis" research I've tried to show, how Remsec (aka Cremes) Ring 0 code works and how it is loaded into a system. We already know that attackers were interested only in one purpose - run own malicious code with SYSTEM privileges. But as we already saw, they have used AVers drivers for this purpose: Agnitum driver on 32-bit system & Avast driver on x64.
I've mentioned in first blog post that the conclusions that have been made by experts (Kaspersky, Symantec, FSB) after analysis of malicious toolkit, show for us potential marks of skilled researchers who can stay behind the malware. The malicious toolkit can be attributed to state-sponsored actor, who has corresponding resources to find flaws in legitimate drivers and write code for its exploitation.

[You can read this discussion in Twitter between The Grugq & Chaouki Bekrar who prove that such 0days use only by special services] Frankly speaking, I can agree with them, because researching such vulnerabilities & developing exploit are required from authors significant material resources.

Because I'm working into AV industry, I can't provide all details of exploitation that can lead to continue this exploitation trend. We can just see how it is possible to exploit driver for own purposes to load illegitimate code/driver into a system.

Let's try to see how authors use Agnitum driver to achieve SYSTEM privileges.

As I already mentioned, the driver (Sandbox.sys) is located as whole file into kgate plugin (.rdata section) and is extracted from it. Let's look on this process more detailed.

First action that plugin does, it drops driver into file with name sandbox.sys. loads in into memory with NtLoadDriver and tries to open its device \.\sandbox.
On the next stage, kgate builds own malicious driver with name aswfilt.dll taking Ring 0 code that is located into .rwxdrv section. Next, this file is dropped on disk.
This is a good question why malicious code is dropped into file with name aswfilt.dll. An answer is located into Agnitum driver.
We can see that Sandbox.sys contains reference to this file name into its body. Moreover, we can see that its code uses ZwLoadDriver to load mentioned files into system memory.
Function that I called fnCallZwLoadDriver performs check of file name and loads file into memory if file name belongs to Agnitum DLLs.
To trigger this feature client should send to driver special IOCTL code. After I've located Sandbox.sys DriverDispatchControl handler, I got answer.
Note that Agnitum driver does not check caller process on trusted when it tries to get handle to its device. In other words, it allows to open handle on device by any user mode client.