Erez Metula
.NET Framework Rootkits: Backdoors inside your Framework

This presentation introduces application level rootkit attacks on managed code environments, enabling an attacker to change the language runtime implementation, and to hide malicious code inside its core. This presentation focuses on the .NET Framework, while covering various ways to develop malware (rootkits,backdoors,logic manipulation, etc.) for the .NET framework, by changing its behavior. It includes demos of information logging, reverse shells, backdoors, encryption keys fixation, and other nasty things.

This presentation also introduces ".Net-Sploit" - a new tool for building MSIL malware that will enable the user to inject preloaded/custom payload to the Framework core DLL.

The Whitepaper, .NET-Sploit, and source code can be found here

Erez Metula is a senior application security consultant, working as the application security department manager at 2BSecure. He has extensive hands-on experience performing security assessments, secure development consulting & training for clients in Israel and abroad such as banks, financial organizations, military, software development companies, telecom, and more. Erez is also a leading instructor for many information security training, especially on secure software development methodologies & techniques. He had lectured on advanced .NET security (and other development platforms) for worldwide organizations and is constant speaker for conferences such as Microsoft .NET Security User Group, OWASP (Open Web Application Security Project), and more. He holds a CISSP certification and is toward graduation of Msc in computer science.
 

 

Another approach was taken, revealed during this research
It was found out that the signature is used just to map to the correct directory name on the GAC
the SN mechanism does not check the actual signature of a loaded DLL but just looks for a DLL inside a directory with this signature name !
 

Upon request for this DLL from other executables running inside the framework, the
framework will search for the required DLL based on his version and signature. The
framework will not check for the actual signature but instead will rely on the signature
mentioned in the directory file name.