Virus Hunting

Understand Common Virus Attacks Before They Strike to Better Protect Your Apps

Jason Fisher

Code download available at:VirusHunting.exe(115 KB)

This article assumes you're familiar with Visual Basic .NET

Level of Difficulty123

SUMMARY

Developer's machines can often be more vulnerable to viruses than the average corporate user because of their more frequent access to remote machines and shares, and the differing administrative privileges they maintain across mutiple machines. Reliance on antivirus software is fine as a first line of defense, but you need a basic arsenal of skills for securing the executables on your system and coping with viruses on your own. This article reviews proactive methods you can use to defend yourself against malicious executable code in resources, component libraries, scripts and macros, as well as how to avoid a handful of other potential vulnerabilities.

Contents

Preparing to do Battle
What Constitutes Executable Code?
A Wolf in Sheep's Clothing
Libraries Can Be Dangerous
Scripts and Macros—Increased Flexibility Brings Increased Risk
Virus Activation Methods
Registration Files
Path Vulnerabilities
On the Scrap Heap
The Best Offense is a Strong Defense
Conclusion

Depending on how destructive their payload, computer viruses can result in a significant loss of data, time, and money. In the best scenario, you may just lose the time it takes to disinfect your computer. At worst, a mission-critical server may be reduced to little more than an expensive door-stop. Unfortunately, antivirus software isn't perfect, and there's always some lag between the emergence of a new electronic predator and the availability of virus definitions to protect against it. Moreover, many writers of today's more diverse and sophisticated computer viruses are taking the preemptive step of disabling or removing antivirus software as part of their activation.

I'm not suggesting that you shouldn't rely on your antivirus programs for day-to-day virus protection, especially since antivirus programs are very good at keeping you safe from known threats. However, if you've never had to fight a virus without your antivirus software, then it's only a matter of time before you will.

Because virus protection changes every day, I won't pretend to be exhaustive in my coverage. Rather, I'll attempt to arm you with information to help you start thinking like a virus writer.

Preparing to do Battle

In general, how do viruses work? Well, first, the author has to write the executable code required to carry out the virus's activation process. What does the author want the virus to accomplish? Should it reformat your hard drive? Delete JPG files? Mail copies of itself to your friends and coworkers? Making any of this happen requires executable code of some kind. Second, in order for this code to execute, the virus needs to be activated. The usual way a virus's executable code is run is the direct method: some unwary user receives an e-mail attachment called "Double-Click Here for Some Real Fun.exe" or something equally enticing. This runs the program and the virus is unleashed.

As easily avoided as this result seems to be—it still works far more often than it should—virus writers have discovered a number of other, less obvious techniques for getting a virus to take over your computer. Let's take a look at some of these techniques, beginning with the question of what constitutes executable code, then I'll move on to examine several sneaky activation methods. These activation methods are particularly important, as this is how you'll unhook viruses from your system in order to regain control of it following an infection.

What Constitutes Executable Code?

Of course, you know that .exe files are executable, as are other similar file types such as .cmd and .com. Because word processing documents can contain macro code to perform customized tasks, they too can run unsafe code. There are also many other file types that contain or launch executable code, and any executable code can be unsafe. In general, executable code falls into three broad categories: standalone programs, code included within resources or libraries, and script or macro code executed by an interpreter of some kind.

In a broad sense, a standalone program is pretty much any file type that relies on the operating system for it to execute. How do you know which these are? The answer lies in the Windows® registry. To battle against viruses on their own turf, you'll have to be very comfortable delving into the registry. So let's take a look at how executable programs are invoked.

Launch the Registry Editor, regedit.exe, and expand the HKEY_CLASSES_ROOT (HKCR) node, the operating system's repository for information on file associations and commands. Under HKCR, you'll see nodes representing all the file type extensions registered on your computer. Navigate down the tree until you locate the key named .exe. Select this node and observe that its default value (shown in the right-hand pane) is exefile. This is a pointer to another key under HKCR (the exefile key).

The exefile key contains a shell subkey. This is where a file type's available actions are defined. In OS terminology, these actions are known as verbs. For example, a Microsoft® Word document might have a print verb defined, which allows you to right-click the file in Windows and choose Print from the context menu. Expand the shell subkey for the exefile node to view the available verbs for EXE files. You'll probably see two or three different subkeys, depending on your system. The one to be concerned with is "open." Expand this node and select its command subkey. Each verb has its own subkey, and each of those keys in turn has its own command subkey. The default value in this subkey dictates exactly what happens when that verb is executed.

Double-clicking the file icon in Explorer has the same effect—it executes the default verb's command (open for EXE files). As you can see, for EXE files, the open command verb has a value of: %1 %*. If you remember MS-DOS® batch files, this probably looks somewhat familiar. The basic idea is that the path and file name of the EXE file you activated are substituted for the %1 parameter, while any switches or command-line parameters that go along with it are passed through the %* parameter.

So it would stand to reason that any other file types whose open verb evaluates to some flavor of %1 would tend to pose a risk. There are a number of these, and they're all potentially dangerous. You should consider that a virus writer knows that many people won't double-click a file with a .exe extension, and they probably wouldn't run a .bat file either, but what about running a .cmd file? What about .com, .pif, or .vbs? All of these file types have a default open verb of %1. A virus writer could simply change the .exe extension of his virus executable to .com, for example, and he's probably just increased the chances that the unsuspecting masses will run it. Particularly dangerous is the humble screen saver file type (.scr extension).

A Wolf in Sheep's Clothing

In your Registry Editor, compare the open verb's command default value for EXE and SCR files, respectively. As you can see, they're pretty much identical—"%1" %* for EXEs and "%1"/s for Screen Saver files. Screen savers are, as it turns out, standalone executables. The only difference between these two default verbs is the /S switch for the SCR file type. The intended purpose of the screen saver's "open" verb is to allow for testing a screen saver, and the screen saver executable interprets the /S switch accordingly. There's nothing to stop a virus writer from giving their application an .scr extension and then simply ignoring the /S switch passed to it when the user invokes the program.

Exploiting the popularity of screen savers is even easier because the caption of the screen saver's open verb is shown as "Test" in the context menu. A user thinks he's just testing a screen saver, but what he's actually doing is activating a virus. A particularly clever virus might even display an actual screen saver, preoccupying you while it destroys files on your hard drive in the background. This caption is stored in the default value for the open key itself. You might want to change this to "O&pen and Test", which is more accurate since in order to test a screen saver, the operating system has to "open" it. That way, users should realize that when they select that menu item, any executable code inside the screen saver will execute—a potentially unsafe condition in the event that code has been infected by a virus.

Libraries Can Be Dangerous

Executable code can also live inside resources or component libraries of many different varieties. These may not seem like obvious candidates for viruses, but they can certainly be exploited in that way. These file types include Dynamic Link Libraries (DLL), Control Panel Applets (CPL), various Type Libraries (TLB, OLB, and so on), ActiveX® Controls and COM Components (OCX, VBX, DLL, and others). This code isn't directly executable with a %1 command verb like EXE, CMD, COM, and others are, but this doesn't mean that the code can't be run.

Just about any function exported from a DLL can be invoked using a helper application called RUNDLL32.EXE. Consider the following example:

rundll32.exe shell32.dll,OpenAs_RunDLL c:\winnt\win.ini

The OpenAs_RunDLL function exported from SHELL32.DLL accepts one parameter, a file name. When invoked, it displays the Open With dialog box, as shown in Figure 1. You can select an application from the list, click OK, and the file name passed as a parameter is opened in the target application. There are a great many examples of this type of call in the system registry. You might want to take a look at some of them to get a better feel for how they work and what sort of system functions they provide. Just search the registry for RUNDLL32.

Figure 1** Exploiting the Helper App **

A virus could employ two possible attacks here. One would be to replace an existing DLL with a compromised version, in which a particular function is replaced by one of the same name but with altered functionality. Then, whenever the system invokes this function, instead of having the desired result, the virus is activated instead. The second approach is simply to write a DLL from scratch and invoke its functions using RUNDLL32.EXE when needed. This isn't quite as straightforward as invoking the code in an EXE file, but a DLL, OCX, TLB or other library file is more likely to be accepted by an unsuspecting user or to be overlooked by an antivirus program, so it may well be worth the greater effort on the virus author's part.

Scripts and Macros—Increased Flexibility Brings Increased Risk

Script code requires a script engine to interpret and run, but it can still be exploited. Scripts come in several flavors. Obviously, the Visual Basic for Applications (VBA) macros contained in Microsoft Office documents are some of the best known and most frequently exploited. Microsoft has done a lot to tighten the security of these macros, but it's still easy for a macro virus to do a lot of damage, and far too many users are careless with documents containing macros. Another increasingly popular script category is Windows Script Host (WSH) files. These files, usually with .wsf, .js, or .vbs extensions, carry a default file association which causes them to be executed, no questions asked, when users double-click them. As you might imagine, this can be disastrous. You may very well want to change the default action on your machine from "open" to "edit" to avoid any accidents. You can do this either in the registry or through the Folder Options dialog box shown in Figure 2.

Figure 2** Changing the Default Action **

Web applications may also carry dangerous scripts. As you probably know, client-side scripts and ActiveX controls are fairly limited in their access to the host system for security reasons, but there's a little-known file type, the HTML Application (with an HTA extension), which works like a client-side Web application without the same security restrictions. Its purpose is to allow developers to use their Web development skills to build rich applications using the Web browser metaphor. But again, the unsuspecting user can unleash all sorts of chaos by downloading and executing such a file without first examining its contents. All of these scripts and macros can be readily examined before they're executed, so you should pay particular attention to any you may come across on your system.

Virus Activation Methods

As I've mentioned already, the most common way for a virus to be activated is for a user to execute an e-mail attachment. Virus writers will do just about anything to make you open the attachment using this action, but most developers are savvy enough not to just run an unknown executable. Of course, just about all of us have done it at one time or another—particularly now that viruses can access address books and can assemble a credible-looking e-mail message, ostensibly from someone you know and trust. Be that as it may, as users have become more aware, virus creators have gotten more devious, and there is now a host of new methods for activating a virus on a computer that don't require any code to be explicitly executed. Understanding how this happens is important for untangling the mess left behind by infection.

Registration Files

Files with an REG extension, as you probably know, are system registration files that hold information to be integrated into the system registry. The problem with them is that they carry a default verb of "open" (with the caption "Mer&ge"). This means that if any registration file is double-clicked, it immediately dumps its contents directly into the system registry, without any confirmation required (depending on your operating system). Even without the possibility for abuse, this is an awful idea. Stop reading right now and change the default verb for REG files from "open" to "edit." As you saw in Figure 2, you can make this change using the Folder Options dialog box. You can also edit the default value for the shell subkey of the regfile key by right-clicking on the entry and choosing "Modify" (see Figure 3). Either approach will result in making edit the default action for this type of file.

Figure 3 Avoiding a PATH Vulnerability

Why are registration files so dangerous? Consider this example. Last year, I had the opportunity to tangle with a virus on a friend's behalf. I noticed that every time I tried to launch any application, I got an error indicating that a particular executable (other than the one I'd asked for) couldn't be found. After some prodding, my friend confessed that in trying to "clean" his system himself, he'd come across this file and simply deleted it. But now he couldn't run anything at all. In theory, he was right to delete the virus executable, but clearly something was wrong with the registry settings for the EXE file type.

Of course, owing to his erasure of the virus program itself, he couldn't run any executable programs of his own, including the Registry Editor. The quick and dirty solution was to rename RegEdit.EXE to RegEdit.COM. I was counting on the fact that although the virus had obviously altered the registry settings for EXE files, it had probably left those for COM files alone. As luck would have it, this solution allowed me to run the Registry Editor. Just as expected, I saw that instead of "%1" %*, the open verb for EXE files had a command of "VirusExecutable.EXE %1". This allowed the virus program to run first any time the user attempted to execute any EXE program. The requested program was passed to the virus executable as a parameter, whereupon the virus could launch it, keeping the user largely in the dark about what was really going on. This is the danger of registration files: they can very easily affect changes of this sort. But if you understand the registry yourself, you can undo these modifications. A good option, but one beyond the scope of this article, is to consider establishing security control over certain key nodes in the registry. For more information on how to perform such tasks, go to A Crash Course: Editing the Windows NT Registry.

The EXE node is one of many locations in the system registry where you can find dangerous alterations. Two others are the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run and RunOnce keys. A REG file or a virus executable adds a value to either of these keys indicating the path and file name of any application or command the author wants to run on system startup. These items do not show up in the Startup group of the Start menu and are difficult to locate unless you're acquainted with this registry key. There are also Run and RunOnce keys in the HKEY_CURRENT_USER hive of the registry. Check both when you're wrestling with a virus.

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon is another vulnerable key. It contains several values which can be abused by viruses. The Shell key, for instance, determines the executable program used as the Windows shell, and it's usually set to "Explorer.exe", but it could be modified by a virus. The lesser known Userinit key, which ordinarily points to userinit.exe, can be modified to run any executable program on system startup quite beyond the user's level of awareness. A virus could point this value to its own executable, which could then launch userinit.exe normally, and the user would probably never notice. These are just a few of the more vulnerable keys to be aware of. If you're tangling with a virus on your own, some of these keys and values represent places to look for anything out of the ordinary. Of course, one person could never enumerate all keys that could possibly be exploited by a virus, but the point is to get familiar with the registry. Feel comfortable roaming through it and learn to establish some appropriate security settings for it.

Path Vulnerabilities

Another hazard is the PATH environment variable. As you know, you can collect all of your lengthiest and most frequently accessed system paths in a single PATH variable so that you don't have to type them out. If you put d:\Program Files\Microsoft Visual Studio\vb98\ into your PATH variable, for example, you can simply type "vb6" at a command prompt to launch Visual Basic® 6.0. There are numerous references to executable files in the system registry that also take advantage of this flexibility. The problem is that using this seemingly innocuous functionality is very lazy and fairly risky. Consider the following scenario.

Windows determines which executable application to use as the operating system shell from a value in the following registry location: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon. Within this key, the Shell value usually carries the value Explorer.exe. Makes sense, right? But what's missing is the path. Still, there's only one Explorer.exe—or should be—so why is it necessary to specify a path? Shouldn't Windows just be allowed to resolve the location through its ordinary path searching sequence (including the values in the PATH environment variable)? The answer is no! Variations of Nimda and CodeRed, among other culprits, have been known to infect and create new virus executables with the name Explorer.exe and to store them in common locations such as the root of the system partition. The virus can't overwrite your running instance of Explorer.exe, of course, because the OS has an exclusive lock on it, but the next time you reboot, the pathless setting in the Winlogon\Shell value will more than likely start up a bogus instance of Explorer.exe, loaded from the root of your system partition or another location that occurs earlier in your PATH variable than the system directory. If it's really nasty, now that an OS lock no longer protects %SystemRoot%\Explorer.exe, it may infect your original as well.

So, it's just laziness to leave the path off of this registry value. Again, stop reading right now and check your registry: if the value has no path, then change it immediately, as shown in Figure 3. Keep in mind that doing this may break some installer apps that don't use this properly. Also, start getting out of the habit of relying too heavily on the PATH environment variable. While you're at it, take a look at your PATH variable to make sure that a previous infection hasn't appended any other directories that have no business being there. This is a common exploit, but it's easy to avoid with a little care. You need to realize that another user on your network may have become infected (through any number of traditional methods, the most common is launching an infected attachment) and that the virus could copy an infected instance of Explorer.exe, or any other commonly used system file that suffers from a path vulnerability, to your computer via an open share. The next time you restart your computer, you're suddenly infected without ever having opened any attachments or running any questionable executable program yourself.

On the Scrap Heap

The last item I'll mention is the scrap object. There are actually two file types here (see Figure 4). Both are extremely dangerous because they can encapsulate executable code within a compound OLE document format. At your leisure, you should take a look at the registry settings that govern their open verbs to see how they work. Also, creating scrap executables isn't terribly difficult—see the related articles in the Summary box of this article.

Figure 4** Avoiding a PATH Vulnerability **

There are two additional reasons these files are particularly risky, apart from the simple fact that they can hide executable code. First, they're often overlooked by antivirus software. Even if one of them is included in the list of executable application types, the other is often omitted. You should ensure that your antivirus program includes both file types.

The second reason is much more subtle. As it turns out, the SHS and SHB extensions are always hidden by Explorer, even if you've configured Windows to display file extensions. The reason is that the registry keys for these file types include an undocumented value, "NeverShowExt." If present, this value overrides global settings in Windows. For this reason, a virus writer can create a scrap object, give it an icon corresponding to an image, then rename it something like "Look at This Funny Picture.jpg." Its actual file name, of course, is "Look at This Funny Picture.jpg.shs," but to the unsuspecting user it looks exactly like any other image. By the time the realization dawns that the file wasn't an image at all, the damage is done. So, delete the "NeverShowExt" registry value from both keys now. Then you'll be better prepared to recognize these little scraps of danger.

The Best Offense is a Strong Defense

So what can you do about all of these nefarious little beasties? Clearly, total reliance on antivirus software is naïve, but at the same time, reacting to a virus after it's gotten a foot in the door is much more difficult. There should be a happy medium, a strategy by which you can avoid some infections before they occur, even though you don't know the exact nature of the virus trying to take over your system. To do that, you have to start thinking creatively.

Figure 5 illustrates one of many possible approaches to solving this problem. Here, in my Visual Basic .NET-based application, I've built a mechanism by which you may be able to prevent compromised programs from executing and thereby spreading the infection across an entire system or network. Before I explain what I've done, let me first say that this application is neither complete (you should add richer error-handling, for example, before deploying it to a production environment) nor infallible. Rather, it's a starting point, designed to get you thinking about proactive solutions to the virus problem.

Figure 5 Preventing Execution of Infected Files

Imports System.Security.Cryptography
Imports Microsoft.Win32
Imports System.Text
Imports System.IO
Module VerifyExe
    Private Function ByteArrayToString(ByVal Data() As Byte) As String
        Dim Counter As Integer
        Dim SB As New StringBuilder(Data.Length)
        For Counter = 0 To Data.Length - 1
            SB.Append(Data(Counter))
        Next
        Return SB.ToString
    End Function
    Private Function CompareHashValues(ByVal FileName As String) As Boolean
        Const RegPath As String = "SOFTWARE\VerifyExe"
        Dim R As Registry
        Dim RegKey As RegistryKey = R.LocalMachine.OpenSubKey(RegPath, True)
        If RegKey Is Nothing Then
            'When this program runs for the very first time, this key 
            'won't exist, so we'll have to create it. 
            RegKey = R.LocalMachine.CreateSubKey(RegPath)
        End If
        'Attempt to read the MD5 hash from the registry for the specified 
        'program. 
        Dim ExeHashValue As Byte() = RegKey.GetValue(FileName)
        If ExeHashValue Is Nothing Then
            'The value didn't exist. This either means that it was removed 
            'or that the specified program has never been run through this 
            'utility. In either case, we need to create the value for next 
            'time. 
            RegKey.SetValue(FileName, HashData(FileName))
            'Now go ahead and run the program. 
            Call Shell(Command(), AppWinStyle.NormalFocus)
        Else
            'The program has been run through our utility before. We need 
            'to compare the hash value read from the registry with the ad 
            'hoc hash value of the contents of the program as it exists 
            'now. 
            Dim AdHocHashValue As Byte() = HashData(FileName)
            If ByteArrayToString(ExeHashValue) = _
                ByteArrayToString(AdHocHashValue) Then
                'The two match, so run the program as expected. 
                Shell(Command(), AppWinStyle.NormalFocus)
            Else
                MsgBox("This executable program appears to have been" & _
                       "tampered with! " & _
                       vbCrLf & "Please reinstall the program from its" & _
                       "original source!", _
                       MsgBoxStyle.Critical Or MsgBoxStyle.OkOnly, _
                       "Potential Tampering Detected!")

            End If
        End If
    End Function
    Private Function HashData(ByVal FileName As String) As Byte()
        'Note that it's critical that the Shell\Open\Command registry key 
        'for each file type must be configured to pass "%1" as the 
        'argument; otherwise, paths and filenames containing spaces will 
        'fail to parse correctly. 
        Dim Fs As FileStream = New FileStream(FileName, FileMode.Open, _
                                              FileAccess.Read)
        Dim Result As Byte() = New  _
            MD5CryptoServiceProvider().ComputeHash(Fs)
        Fs.Close()
        Return Result
    End Function
    Public Sub Main()
        If Command() <> "" Then
            Dim Fi As New FileInfo(Environment.GetCommandLineArgs(1))
            'If you wish, you can add additional executable extensions, 
            'such as ".pif" or ".cmd". Bear in mind that the Shell function 
            'only supports directly executable file types; if you replaced 
            'the use of the Shell function with, for example, an API call, 
            'you could actually apply this technique to any arbitrary file 
            'type for which an association exists. 
Select Fi.Extension.ToLower
                Case ".exe", ".com", ".bat"
                    If Fi.Exists Then
                        Call CompareHashValues(Fi.FullName)
                    End If
            End Select
        Else
            'If no command line arguments are passed, error out. OR: you 
            'could use this path to establish the correct file type 
            'Shell\Open\Command registry associations! 
            MsgBox("This application requires that the filename " & _
             "and path to an" & vbCrLf &
             "executable program be passed " & _
             "as a command-line argument", _
             MsgBoxStyle.Exclamation Or MsgBoxStyle.OkOnly, "Argument Required")
        End If
    End Sub
End Module

I've coded the program to look for EXE, COM, and BAT extensions, but you can extend this to other file types if you like. My program looks in a particular registry location for a reference to the program. If such a value is found, it will contain an MD5 hash of the binary contents of the executable (see Figure 6). If no entry is found, it means that either the reference has been removed or the program hasn't been run on this system since the installation of the verification program. In either case, you have little choice but to go ahead and launch the program. First, however, you should perform an MD5 hash of the program's contents and store it in the correct registry location. Now, obviously, the program can't prevent a file that's already been infected (but hasn't been hashed yet) from executing. You could, however, add a confirmation dialog if you want, so that the user can make the final choice.

Figure 6 MD5 Hash Values

If a hash entry does exist, then the requested executable program is rehashed on an ad hoc basis and the two values are compared. If the hash values match, then the program's contents haven't been altered since the first time it was run and hashed. Hashes that don't match suggest that the file has been altered. This, in turn, is a likely indication of virus activity since most viruses infect executable files by modifying their contents. The way they do this is beyond the scope of this article, but if you can determine when an executable program's contents have been altered, you can generally prevent it from spreading a virus across your system or from carrying out any further destruction. In this case, the utility does not allow the program to execute. Rather, it displays the warning indicating that potential tampering with an executable has been detected.

I haven't built an installation program for this utility, so before it will take effect, you have to hook it into your system. To do this, modify the Shell\Open\Command value in the registry for each file type you want to verify. For instance, to hook into the EXE file type, you'll change the default value of the HKCR\exefile\Shell\Open\Command registry key from "%1" %* to "path\VerifyExe.exe" "%1" %*.

Of course, you should substitute the actual path to the VerifyExe.exe. This will allow the utility program to run for all EXE files. It will then pass along the original requested EXE file and any command-line parameters or switches. Make the same registry modification for the COM and BAT extensions and for any other file types you want to verify. You might want to build these associations into the program itself or into an installation program.

Now, I know what you're thinking. What if a virus gets wise to this approach and decides to delete an application's registry value before infecting it? Then, the next time the user runs that application, it will be allowed to execute, thereby spreading the virus. Or what if a virus simply deletes VerifyExe.exe altogether? Both could happen, but the unfortunate truth is that this is just the way it is. No matter what you do, a virus may circumvent it. You can, of course, modify the source code I've provided to use a different location in the registry—an INI file, or any other storage mechanism you like. This will probably make it more difficult for viruses to avoid detection, however any solution that works will itself eventually be targeted by viruses. This is why, as I said earlier, many of today's nastier viruses are attempting to detect and incapacitate your antivirus software. Still, the solution offers fairly good preventive security, and it should get your creative juices flowing so you can devise your own methods as well.

Conclusion

Understanding how viruses take hold is the first step in knowing how and where to untangle them from your system once it has been compromised. As viruses become more sophisticated, you can expect them to become more aggressive toward your antivirus software. If it hasn't happened to you yet, you can be sure that sooner or later, you will have to battle a virus on your own. Remember, the best defense is a good offense. Here you've seen how to secure the contents of executable programs on your system, so you can be ready in the event of an attack. Along with that offense, up-to-date antivirus software, and an understanding of the relevant keys in the registry, you can go head-to-head with any invader that manages to sneak by you.

For related articles see:
Wrapping Malicious Code in Windows Shell Scrap Objects
Scrap Files Can Tear You Up
F-Secure Virus Descriptions
Introducing HTML Applications: DHTML Goes out of the Browser

For background information see:
https://technet.microsoft.com/security/
https://www.mcafee.com
https://www.wildlist.org
https://www.cert.org

Jason Fisheris a technical architect, freelance writer, and editor. By night, he's a crime-fighting caped crusader, battling viruses, DDoS attacks, and other intrusions with his own ruthless brand of computer justice! When not on the prowl, he can be reached at jasef@swbell.net.