A lot of water has passed under the proverbial bridge since the Donut virus of 2002. W32.Donut was of course a concept virus (named "dotNET" by its creator) to demonstrate weaknesses in the Microsoft .NET architecture that, at the time, was brand new. Although Microsoft started development on the .NET framework in the late 1990s, version 1.0 wasn't officially released until February 13, 2002. With the release of Windows 7 this October, .NET has suddenly taken on a greater significance. While previous Microsoft operating systems did not include the .NET framework by default, starting with Vista and Windows Server 2008 and continuing into Windows 7, it is now a native part of the OS installation. What makes this especially significant is the widespread belief that Windows 7 will become the Microsoft operating system of choice, whereas the uptake of Vista was relatively poor. Wikipedia informs us the Microsoft .NET framework is a software framework that can be installed on computers running Microsoft Windows operating systems and is intended to be used by most new applications created for the Windows platform. The design is intended to address some of the vulnerabilities of operating systems, such as buffer overflows, that have been exploited by malicious software. Additionally, .NET provides a common security model for all applications, and there are many major packages that require the .NET framework, including IIS7, Visual Studio, Silverlight and Exchange 2007 just to name a few. .NET consists of several languages, two examples being C# and Visual Basic, and interestingly has many similarities to Sun's Java. Both are based on a virtual machine model that hides the details of the computer hardware on which their programs run. .NET employs an intermediate byte-code called Common Intermediate Language (CIL; formerly known as MSIL), and this byte-code is always compiled just before execution. Both .NET and most implementations of Java rely on JIT (Just In Time) compilation for high-speed code execution. This makes them fast and efficient, but unfortunately that efficiency also applies to any malicious code that is written for and able to be executed by these technologies. What essentially differentiates a .NET assembly program from Win32 programs is that a .NET program imports a DLL file (mscoree.dll) and jumps to a particular function of the DLL, but never returns control to the program which called the jump instruction in the first place. For standard Win32 operations control is always maintained by the program itself. .NET however distances itself from the underlying platform and instead maintains control within the .NET framework, hence .NET programs can be written to run on different platforms, provided the appropriate .NET Framework is installed on that platform. Currently such third-party frameworks are still under development and not widely installed. .NET programs are usually relatively easy to analyze because informative labels (specifically class and method names) exist within the program itself. One example of .NET malware we came across recently (detected as Backdoor.Trojan, and coded to run only on Windows operating systems) however has used strong encryption on its code making it much more difficult to analyze. Not impossible by any means, but certainly more time-consuming. The motivation behind adopting .NET along with the use of encryption was undoubtedly an attempt to avoid detection, as normally a .NET program would be obvious at a glance if encryption was not used. Antivirus vendors have developed all kinds of automated analysis tools to help in the fight against malware, and as a result "plain" back doors (i.e. a W32 file not obfuscated by encryption) are usually caught fairly quickly. In that sense .NET programs are still relatively rare and such automated analysis tools may not exist for them, thus freeing them from the close scrutiny W32 and other types of malware undergo. The Trojan sample mentioned above isn't particularly creative. It copies itself to a couple of locations on the hard drive, adds appropriate registry values to the Run key in order to run itself when the computer starts, and attempts to access a URL to open a back door in order to receive commands from the attacker. Even without antivirus protection, if a computer is running a firewall (either standalone or as part of a security suite) the firewall should block and alert the user to the back door's outbound attempts. Of course many threats will inject a remote thread into Internet Explorer (or any browser for that matter) in an attempt to bypass the firewall, but to its credit .NET makes it very difficult for this injection to take place, essentially making anything but the simplest .NET threat outside the scope of the average malware writer. So it could be argued that .NET programs are not a very attractive proposition for malware authors, but on the flip side of the coin if the extra obstacles can be overcome, the chances of survival are surely greater than for your common garden-variety threat. Over time, and certainly with the imminent release of Windows 7, hopefully that will change. Thanks to Masaki Suenaga for the analysis he provided.