Sednit cyberespionage group is already a well-known for AVers & security community. It is also known as APT28, Fancy Bear, Pawn Storm, Sofacy. Wide range of various researches show for us that this cybergroup operates by state-sponsored malicious toolkits. Malware from these toolkits are intended for cyberespionage and data exfiltration from compromised systems.
![]()
Recently my colleagues from ESET security firm released a comprehensive and very detailed paper about Sednit activity. You can find this excellent research [PDF] here. In last part of the research were mentioned and Ring 0 components: bootkit and rootkit. Both are used by authors to hide malware components from user eyes & for injection malicious code into processes.
Moreover, while I was preparing this blog post, Paul Rascagnères has issued his own detailed research about Sednit rootkit. Ok, let's start. Below you can see timestamps from dropper, 32-bit and 64-bit drivers. As we can see, 32-bit rootkit driver was compiled earlier 64-bit.
![]()
Interestingly to note that authors use similar code implementation like we already seen many times in older NtRootkit drivers family. It's not a secret that such rootkits have Russian origins and its authors have used famous Russian forum wasm.ru (for example, MS-REM articles) about Windows kernel mode exploitation.
For example, authors use cli/sti commands during disabling SSDT WP protection and dont't care about synchronization issues while modifying SSDT entry. This method of WP protection disabling was widely spread among authors of NtRootkits, who had not so much experience in drivers/rootkits development.
![]()
Sednit driver is pretty easy for analysis and if you are not familiar with Windows Internals & Rootkits world, you can start to study it from this rootkit. There are a lot of debug messages in the rootkit code with functions names, which was given them by authors. We can find also string to .PDB file with debug information inside the rootkit file (32-bit version).
d:\new\hideinstaller\Bin\Debug\wxp\x86\fsflt.pdb
Rootkit starts its execution from DriverEntry function, which is responsible for rootkit initialization: creating device object, symbolic link for it, hooking SSDT functions and other actions. Unlike authors of Cremes rootkit, who choose innovative approaches for driver loading, Sednit authors use a well-documented method of launching the rootkit with help of SCM.
In DriverEntry rootkit creates device object \Device\dfsflt and symbolic link \DosDevices\dfsflt. I suppose that such name was chosen by authors to hide malicious nature of device object.
![]()
Also note that authors use standard way for creating communication between client and device object, which based on symbolic link opening from Win32, while Cremes authors use internal NT name based on \\.\GLOBALROOT\Device\ for this.
During set up hooks for SSDT, authors also choosen not good method for lookup SSDT indexes of specific services. They use in-memory Ntdll image and scans export functions without SEH that should be used in driver, while it tries to read user mode memory.
![]()
The rootkit uses this registry key \REGISTRY\MACHINE\SYSTEM\CurrentControlSet\services\FsFlt for its service. It also supports special parameters to store configuration.
This debug string with .pdb path is located into 64-bit driver.
d:\!work\etc\hideinstaller_kis2013\Bin\Debug\win7\x64\fsflt.pdb
Major difference of 64-bit driver from 32-bit is that authors don't use SSDT hooks to control system operations. They rely on Filter Manager driver API (fltmgr.sys) for filtering file operations and CmRegisterCallbackEx for registry (Cm) related operations.
64-bit rootkit driver removes cryptbase.dll library from sysprep system directory. As was mentioned in ESET Sednit paper, sysprep tool is used by the dropper for UAC bypassing. I suppose that the rootkit removes cryptbase.dll file in its DriverEntry, because it contains malicious code that was written by the dropper. Sysprep has UAC auto-elevation ability and loads overwritten dll from its directory. Details about this method of UAC bypassing you can read here.
![]()
You can see similarities between WDK sample of registry filtering driver and that been used in rootkit on Github.
There are no reasons to repeat detailed analysis of rootkit functions, because it has already been done by other researchers. My purpose was concentrate on interesting places in drivers and are trying to focus attention on them.
Conclusion
Sednit rootkit really is not similar to state-sponsored malware of elite cybergroup...It is possible that if some AV analyst found its sample in-the-wild, he would hardly have thought that this driver was written or deployed by a state-sponsored actor. As we seen above, authors have chosen trivial rootkit methods are based on SSDT hooks and don't care about SMP system: they use CPU-specific instructions, do not use thread affinity to current processor and do not use MDL for disabling system code write protection (WP) security measure.
Nevertheless, it should be noted that both rootkit and bootkit were written pretty accurately. Information about bootkit part you can find in paper En Route with Sednit. Part 3. The authors had one goal - to hide the traces of their malicious software on the system and seems they have achieved this goal.
Recently my colleagues from ESET security firm released a comprehensive and very detailed paper about Sednit activity. You can find this excellent research [PDF] here. In last part of the research were mentioned and Ring 0 components: bootkit and rootkit. Both are used by authors to hide malware components from user eyes & for injection malicious code into processes.
Moreover, while I was preparing this blog post, Paul Rascagnères has issued his own detailed research about Sednit rootkit. Ok, let's start. Below you can see timestamps from dropper, 32-bit and 64-bit drivers. As we can see, 32-bit rootkit driver was compiled earlier 64-bit.
For example, authors use cli/sti commands during disabling SSDT WP protection and dont't care about synchronization issues while modifying SSDT entry. This method of WP protection disabling was widely spread among authors of NtRootkits, who had not so much experience in drivers/rootkits development.
Sednit driver is pretty easy for analysis and if you are not familiar with Windows Internals & Rootkits world, you can start to study it from this rootkit. There are a lot of debug messages in the rootkit code with functions names, which was given them by authors. We can find also string to .PDB file with debug information inside the rootkit file (32-bit version).
d:\new\hideinstaller\Bin\Debug\wxp\x86\fsflt.pdb
Rootkit starts its execution from DriverEntry function, which is responsible for rootkit initialization: creating device object, symbolic link for it, hooking SSDT functions and other actions. Unlike authors of Cremes rootkit, who choose innovative approaches for driver loading, Sednit authors use a well-documented method of launching the rootkit with help of SCM.
In DriverEntry rootkit creates device object \Device\dfsflt and symbolic link \DosDevices\dfsflt. I suppose that such name was chosen by authors to hide malicious nature of device object.
During set up hooks for SSDT, authors also choosen not good method for lookup SSDT indexes of specific services. They use in-memory Ntdll image and scans export functions without SEH that should be used in driver, while it tries to read user mode memory.
This debug string with .pdb path is located into 64-bit driver.
d:\!work\etc\hideinstaller_kis2013\Bin\Debug\win7\x64\fsflt.pdb
Major difference of 64-bit driver from 32-bit is that authors don't use SSDT hooks to control system operations. They rely on Filter Manager driver API (fltmgr.sys) for filtering file operations and CmRegisterCallbackEx for registry (Cm) related operations.
64-bit rootkit driver removes cryptbase.dll library from sysprep system directory. As was mentioned in ESET Sednit paper, sysprep tool is used by the dropper for UAC bypassing. I suppose that the rootkit removes cryptbase.dll file in its DriverEntry, because it contains malicious code that was written by the dropper. Sysprep has UAC auto-elevation ability and loads overwritten dll from its directory. Details about this method of UAC bypassing you can read here.
You can see similarities between WDK sample of registry filtering driver and that been used in rootkit on Github.
There are no reasons to repeat detailed analysis of rootkit functions, because it has already been done by other researchers. My purpose was concentrate on interesting places in drivers and are trying to focus attention on them.
Conclusion
Sednit rootkit really is not similar to state-sponsored malware of elite cybergroup...It is possible that if some AV analyst found its sample in-the-wild, he would hardly have thought that this driver was written or deployed by a state-sponsored actor. As we seen above, authors have chosen trivial rootkit methods are based on SSDT hooks and don't care about SMP system: they use CPU-specific instructions, do not use thread affinity to current processor and do not use MDL for disabling system code write protection (WP) security measure.
Nevertheless, it should be noted that both rootkit and bootkit were written pretty accurately. Information about bootkit part you can find in paper En Route with Sednit. Part 3. The authors had one goal - to hide the traces of their malicious software on the system and seems they have achieved this goal.