marklon : viruses

Measure and counter measure – malware and anti-malware

marklon — Mon, 21 Apr 2008 23:04:00 GMT

There is a small, high-tech and rather geeky war going on and the battlefield is your PC. Like any war, each side is trying to learn from the other. This war is for the ownership of resources – and ultimately for money. Maybe most wars are. Let us look at some of the details.

Much as it irritates users, sometimes the kindest thing that an administrator can do is to limit the abilities of an unskilled user to harm themselves. There is also the corporate network to consider – the safety of organization sometimes requires that individuals are limited. IE has features to limit what the user can do which an administrator can set. They are detailed here:

http://technet.microsoft.com/en-us/library/bb457144.aspx

These can be turned against the user by malware and that does sometimes happen. Let us consider a few of them and how malware has used them to protect itself rather than the user:

Download signed ActiveX controls – disable that and pretty much every online virus scanner will stop working.

Various settings allow the administrator to block the downloading of various file types including .exe files – which would prevent the user from downloading a lot of the “quick fix” type of malware removers.

Sites can be added to the restricted zone – and if security sites are added to this zone, the user is effectively blocked from them.

Group policies can also be set even if the machine is not in a domain.

We have seen malware doing these things lately. Of course, if the user is an admin (and home users generally are) then the changes can be reversed if the user knows how - but many home users do not.

For quite a while, one tool in the arsenal of the techie removing malware is to alter the rights on an executable using cacls to prevent it running. The same trick has been used maliciously to block access to cmd.exe – The black hats have access to all the same tricks as we do.

The white hat community has stolen a trick or two in their turn. Anti-virus solutions increasingly hijack the kiservicetable or overwrite function prologues to try to prevent malware doing the same or to detect malware by getting underneath it. One of the truisms of malware detection is that you can only trust the layer above you because you have complete visibility of it. Conversely, it is hard to see what has happened below you because it may be changing your behavior without you knowing – a malicious kernel fooling a benign application. The phrase that we most commonly use is “He who hooks lowest wins”. Anti-virus and virus are both heading down the stack from userland to kernel and eventually to hypervisor level.

Malware tries to hide from antivirus programs and kills AV products when it can. Some AV software is now using stealth technology to hide from malware and try to avoid being killed or more commonly, crippled to leave the appearance of function without actually blocking the malware. It can be a challenge to work out whether subversion of the kernel is benign or malicious without a good rummage around in the debugger.

So, we have measure and counter measure, each sharing the same tools. The legitimate software community has more resources but the malware industry has everything to play for. The balance shifts all the time and it may well be that user education and not technology has the most to contribute. Social engineering remains the number one way to compromise a system… and maybe limiting the user is the lesser of the two evils.

Of course, we have done this in a very small but important way. Later versions of the browser on later operating systems run content with fewer rights. Most users never notice.

We live in interesting times, my friends

Signing off

Mark

Malware that wants to stay - Some passive protection tricks

marklon — Thu, 20 Mar 2008 22:31:00 GMT

Hello again

I wanted to talk about some of the things that malware does to make itself hard to remove. Most Trojans are designed to work on an average XP workstation and make assumptions based on that – which typically breaks servers in rather nasty ways.

I was recently looking at a Russian written malware implemented in VB6 – a curious choice and the developer had an odd style to his coding. It didn’t use a kernel mode rootkit which is the more common approach but relied on registry settings to do the dirty work. You might want to check these if you find yourself cleaning up a box:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\SystemRestore]

DisableSR = 0x00000001

If it is a 1, you can’t do a system restore. Simple enough to fix if you can edit the registry.

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System]

DisableTaskMgr = 0x00000001

DisableRegistryTools = 0x00000002

Except that you can’t because he disabled the registry tools and task manager. Well, task manager is no great loss. Process explorer from http://technet.microsoft.com/en-us/sysinternals/default.aspx will do the job at least as well. Disabling the registry tools is more of a problem unless you are on a network and able to remotely edit.

[HKEY_CURRENT_USER\Software\Policies\Microsoft\MMC]

RestrictToPermittedSnapins = 0x00000001

This was used to make MMC effectively useless. By default, no snap-ins (things like perfmon or event viewer or SQL management or whatever) are in the permitted list.

Disabling CMD.EXE is a pain when trying to remove malware so he setting the following registry key

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System]

DisableCMD = 0x00000001

That is especially problematical for some tools that rely on batch files and some security tools do since old school can sometimes be the only way of doing something.

In this case, a few minutes work with WinPE was enough to rain on his parade but a bit of remote registry manipulation would have done the job just as well.

Hope that this helps someone

Signing off

Mark

Security Updates - Are they the answer?

marklon — Tue, 12 Feb 2008 16:23:00 GMT

Ah, another “update Tuesday” – known to the rest of the world as “patch Tuesday” but we are not supposed to call it that.

We have a fine crop of updates for you but I am not going to talk about those, partially because we won’t be releasing them for several hours and partially because that is the province of my much respected colleagues in the MSRC – you can always get the straight dope here: http://blogs.technet.com/msrc/

This month so far has been a fairly quiet time for me. We are seeing fewer new infections recently though the ratios of where this stuff comes from are pretty consistent. You might find the threat map at www.threatexpert.com to be an interesting read.

The Storm botnet is recruiting again, this time with Valentine cards instead of Christmas cards or promises of applications to help you track football scores. A lot of people are now aware of the techniques used by this bot and infection rates seem to be dropping a little though it is a little hard to tell. Storm uses a peer to peer protocol for its command and control mechanism and so there is no one place to monitor the network. The packets look very much like eDonkey file share activity unless you know to look for the 40 byte encrypted packet at the start.

On the subject of Storm, this is a malware that, in its most recent versions, has been very much based on social engineering. It is apparently remarkably easy to persuade people to install malware on their computers. No really, I am not making this up. Independent research shows that around 75% of malware on systems got there because a user installed it while under the impression that it was a good idea. Some of it is installed because a popup tells them that they need a video codec so they download an EXE file. Some of them respond to a popup saying that there is evidence of malware or visiting adult sites on their computer. They download the program to “fix” this problem and then the problems start. Now, you, gentle reader, I know that you would never fall for such blatant social engineering but consider your cousin, the person at the supermarket checkout, yourself when you were a kid still learning what you know now… well, they will. Not every unskilled user will fall for these tricks but enough will that it is a fertile recruiting ground. 75% of malware gets on systems this way. Who needs security vulnerabilities to spread malware?

Is it heresy to say that on a patch Tuesday? Of course, vulnerabilities matter. Wormable vulnerabilities matter a lot. A corporate network can be taken down in less than an hour by an aggressive worm if there are no mitigations in place. Targeted attacks pretty much always use some vulnerability in software. Vulnerabilities matter a lot. Updates are critical. What they are not is all of the story. Many people seem to think that they are.

One of the most common questions that I get asked when people learn what I do for a living is “Why don’t Microsoft make Windows more secure?” The answer is “We did. Look at Vista and Server 2008. We are. Look at the bulletin release schedule. Look at the malicious software removal tool.” I don’t generally say the next bit. We work very hard to improve security but we don’t have much control over the things that get exploited most often: People.

Ah, but wait a minute, I hear you say. If vulnerabilities are not the be all and end all, why are there so few malwares on (insert name of alternate OS here). The answer to this is simple and I am far from the first to say it. Why do criminals rob banks? Well, that is where the money is. Malware used to be written for bragging rights. Now it is written for money. Either way, the malware writer wants as many systems as possible affected. 19 out of 20 desktop systems run some flavor of Windows. If I want to affect as many systems as possible, which do I attack? It is a no-brainer. You develop exploits for the biggest payoff.

Does this depend on which system has the most vulnerabilities? No, not at all. If Linux had 5 times as many vulnerabilities as Windows (which I don’t think for a moment that it has) and you had a 100% success rate at compromise Linux desktops then you would have… 5% of the market. If you had a 10% success rate at compromising Windows systems then you have 9.5% of the market. It doesn’t make sense to go for Linux as a platform for malware.

All that said, vulnerabilities in the OS are less of a factor all the time. A lot of exploits target applications these days. The antivirus product, the reader for one of the common formats like Flash or PDF or Java or whatever it is this month are at least as good a target. The people are at least as good a target. In fact, looking at the numbers, the people are 3 times better targets. We can’t make better people – and we don’t want to limit what people can do because people resent that. Look at the reputation that user access control in Vista has.

It is a tricky problem. We can make better operating systems. We can not make better people.

(Edited - The original said that we could make better people - so not what I meant)

Signing off

Mark

Antimalware tools and tricks

marklon — Mon, 21 Jan 2008 19:50:00 GMT

Ah, I am back in the office and settling into to my normal day to day work.

I am fairly often asked to remove malware from systems which the anti-malware programs on that particular PC system can’t handle. In fairness, it is often not the AV products fault. Most (more than 75%) of malware is actually installed by the users of the system after some social engineering. I know that none of you out there in blog land would do that sort of thing but it does happen. We have all downloaded drivers from the web, codecs from the web and utilities. It is easy enough to get it wrong and some of the Blackhats can make some very convincing webpages and emails that would fool your brother/mother/dentist. Anyway, that is how a lot of this nasty stuff gets on systems and one of the first things that it normally does is try to break the AV solution. Sometimes it succeeds.

I am yet to find an instance in which this has happened where the machine could not be cleaned up with the SysInternals tools and a little ingenuity. I know that I have mentioned this before but I hadn’t linked to the excellent video presentation by Mark Russinovich video: http://www.microsoft.com/emea/spotlight/sessionh.aspx?videoid =359

I would also like to mention a really good tool called Rootkit Unhooker. This was written by a Russian team who have since joined Microsoft. It is excellent for finding hijacks in the kiservicetable, hidden files and processes and similar rootkit tools. If you work with malware on a regular basis and haven’t tried this tool then you might want to search it out. I have had considerable success with this tool where some others have not been as useful.

Anyway, hopefully I will be back to some more code related posts soon but thought that this tools update could prove useful

Signing off

Mark

Doing it yourself.

marklon — Fri, 26 Oct 2007 22:22:00 GMT

Hello again

Two blogs in less than 48 hours? Whatever could be happening? No, this is not a reference to the issue documented in http://www.microsoft.com/technet/security/advisory/943521.mspx which is interesting but certainly not widely exploited in Europe. No, today I would like to relate what I did on Wednesday night.

I was helping a friend redecorate – our American cousins would call it home improvements but we would call it "Do It Yourself". Now, I am a firm believer in having the right tools so I stopped off on the way to get sandpaper, sugar soap, flexible sanding blocks, disposable gloves, the whole nine yards. I was sure that I was well equipped for the job at hand. This turned out not to be the case.

While I was sanding down the paintwork, I had an odd request from one of the two daughters. Could I remove IE from the home PC as it was popping up a lot of windows and they preferred Firefox in any case. Uh, pop-up ads? I went to have a look. Adware was opening a new "message from our sponsors" every 20 seconds or so. Not so good. The PC was also responding very slowly indeed and a quick check showed that an invisible instance of IE was using 1.5GB of memory – rather more than the system had.

I have removed malware from quite a few systems but I normally go armed with some very specific tools and all that I had here was a sanding block and rather slow access to the internet. So, I had to improvise and here are some of the things that I did – I relate them here in case you ever have the need to do the same.

The first thing that I did was check if there was an antivirus solution installed and whether it was current. The engine of the AV was older code but still valid (Sorry, Mr Lucas) and the signatures were current. It had blocked a Trojan the day before and didn’t seem disabled. The event logs showed that it had been removing threats on a fairly regular basis for a couple of years. The system was XP SP2 in an indifferent update state and had 4 users (father, mother, 2 daughters), all admins. A scan from the AV product (intentionally nameless, not OneCare) reported that all was well when manifestly it was nothing of the sort.

Terminating IE resulted in an immediate relaunch, apparently explicitly as it was not the default browser on that system. Hmm. Not a BHO then. A malicious Browser Helper Object can certainly do some interesting things to a loaded instance of IE but not launch a copy when there is no loaded copy of IE to host it. Clearly we were looking at another process. I started killing off processes trying to get down to a manageable list so that I could find the rogue and lo… I got to a state where there were a reasonable number of processes and they were all identifiable as harmless. So, either a legitimate process had been hijacked in some way (unlikely) or there was a hidden process – which strongly suggested a rootkit.

I downloaded Rootkit Revealler from Sysinternals (now a part of MS) and ran that. Sadly, it came back saying that all was well. The MS Malicious Software Removal Tool said that there was no malware on the box. All the while, some hidden process was kicking off instances of IE as if there were no tomorrow.

Since the automated approaches had failed, I decided to use a more manual approach and pulled down the whole SysInternals suite. I was mainly after Process Explorer and Autoruns but show me tools and I am like a big kid. I want them all!

So, I started with Autoruns. If you are not familiar with the tool, it looks for every way of starting a process when Windows starts, lists those applications and enables you to disable them – it also lists some inprocess components too which was useful. There were a couple of known Trojan droppers in the startup so I took them out. There were a lot of legitimate helper processes which seem very common on home machines. iTunes needs these and some other media player needs those and pretty soon it all looks very cluttered. Anyway, I disabled some of the more obviously malicious and rebooted. The system came back in very much the same state – with IE instances spawned over and over and many of the removed startup entries back. Interesting.

I started in with Process Explorer and there were multiple instances of Internet explorer. I terminated one and back it came – damn. Oh, hang on, the launching application flashed up for a moment. I checked and there was no sign of the launching process in the list and it disappeared as the launching process moments after the new instance of IE popped up. Interesting again. I tried a few more times and managed to get the path of the executable – which was off the "My documents" pseudo-folder in a directory with a random name that didn’t show up in explorer when browsing but would open if I gave explorer the full path. Time to dig deeper.

The executable was packed and there were no strings to mention when I opened it with notepad though process explorer was able to make more of the strings in memory of the process – quite handy when looking at malware. Yes, this used all the APIs that I would expect for what it was doing. Ok, now I had a file to look at and that was a good step forward. Now, because it was already pretty late in the day by then and I was representing a member of the public, I felt no shame at all in using www.virustotal.com which can be a very handy site indeed. You can upload a file and they will pass it against a bunch of anti-malware applications and give you the results. I sent the file to the site and that started to give me results in less than 30 seconds… you have to like that. 50% of the scanners came back with nothing detected and the remainder all came back with generic results basically saying that they thought that the file was bad but didn’t have a specific classification. This normally means that it is waiting in a queue for some human to look at. That is pretty common with new malware or new variants of old malware but unfortunately that meant that I had no specifics of how to remove the cursed thing.

Ok, back to basics. Delete the file. Nope. File is in use, can’t delete or rename. Right. The process is hidden by a rootkit but the cover is not perfect and although it doesn’t appear in the process list, I can get the process ID when it hands it to a new instance of IE as parent. Using that, I killed the process and went to delete the file. Again, it was locked. A bit more poking around with process explorer showed that another hidden process was respawning the first one.

I shifted my attention to this newly discovered process and found that I couldn’t delete it because the first process looked after it in the same way – a sort of mutual protection process. I might have been able to write an app to terminate both processes and delete the files but I didn’t have any development tools here – it was just a home PC. Anyway, it would have been a race condition with no synchronization.

Deleting the registry keys that started it on boot was pointless because they came right back – it turned out that it had a thread waiting on the key to restore it.

All in all, quite a clever defense. However, it always launched the user mode processes under the context of the logged on user so that the spawned IE instance would appear on the desktop which made sense. Because all the users were admins (like most home users) this is a good solution for malware. I managed to break it in a reversible way by dropping down to a command shell and using cacls to deny access to the launching user to IE. That caused the first user mode malware process to AV because it didn’t have any error checking and assumed that the API would succeed. The second process turned out to be very much the same and when I changed the rights on the first malware exe, it crashed. I could now pretty much break the user mode components at will.

The kernel mode process was a little tougher but the same basic approach worked and it failed to load on startup.

I would still strongly recommend rebuilding the system but I was unable to find any problems after the service was disabled. It is amazing what you can do with publicly available free tools.

The malware will be submitted to the companies that failed to recognize it – including Microsoft. It is just a shame that I didn’t get more sanding done but Do-It-Yourself malware removal is useful too. I have to thank Christie and Sherry for letting me get this new malware submitted.

Until next time!

Mark

Can you break Law #1 and get away with it?

marklon — Mon, 24 Sep 2007 18:20:00 GMT

To save you scrolling down, let me restate Law #1 of the immutable laws of security:

"If a bad guy can persuade you to run his program on your computer, it's not your computer anymore"

Is there any possibility that it is safe to do business with a computer that has malware on it? The blanket answer is "no – there is no way to be sure". Like all generalizations (irony by design), this is not wholly true. Malware comes in many forms and not all malware will affect all aspects of system operation. If you know exactly what the malware does then it may be possible to still trust the machine to some degree. If you know that the malware just pops up unwanted advertising and has no other function at all then it is probably fine to still accept a low value online order from that customer. If the system has a keylogger which records credit card details then it might be perfectly safe for you to accept the order but very dangerous for the user to place it. So, the more accurate answer to the question would be "In general, no, it is not safe. In some specific cases, it may be".

So, the follow-on question is "Can you determine programmatically whether it is safe or not?"

This is, I think, a better question. However, the answer is unfortunately "Almost certainly not".

"Why do I say that?", I imagine you asking. I will be delighted to answer (I am easily pleased). The reason is twofold. The first is that you can’t tell what a bit of detected malware does without extensive reverse engineering. The second is that any machine (other than one in isolation that has been built from known clean sources) could be compromised with malware that hides well. One thing that rootkits do is hide. If something has modified system behavior below the level at which you run, the results of any investigation that you do is suspect – API calls can be subverted by malware. No automated or manual process can guarantee that there is no malware on a system because absence of evidence is not evidence of absence.

The logical conclusion is that since no real world machine is 100% safe then we must regard them as wholly unsafe. However, that is logical rather than sensible. In reality, we must accept a level of risk from the systems that run our applications. Where possible, we must mitigate the risks. We should always recognize them even if we can not mitigate against them.

In my next post, I will be talking about mitigation strategies.

Signing off

Mark

Targeted attacks - a sniper rifle, not a scattergun

marklon — Wed, 25 Jul 2007 19:44:00 GMT

Malware is often thought of as an equal opportunity nasty. After all, real viruses affect the rich and poor equally. However, things are not as they once were. In the heady days of Blaster and Slammer and Nimda et al, the malware would infect anyone that it could.

Worms are not often found these days (fingers and toes crossed) but Trojans that will add your machine to a BotNet are not so much common as ubiquitous. These are not at all targeted but once in a while, we see something a bit different.

A blackhat will pick a handful of important users in an organization and they will be targeted with malware. It might be done via an email with a document that exploits a vulnerability in Office or Adobe Reader or whatever document viewer is unlikely to have been patched – large organizations often take a little while to roll out updates and longer for third party products which don’t have an auto-update mechanism. It is quite likely to have content tailored to be of interest to the user – for example, if the sales manager of a PC company was being targeted, it would make sense for the mail to claim that the document is sales figures from a competitor.

That said, there is another, simpler way. Some blackhats have been known to send (via snail-mail) a USB key or a CD with the malware on it. Most non-technical staff (and managers are normally the targets) will put the CD in or USB key in their PC without question. One quick autorun later and that box is owned. However, the purpose here is not to make the machine a spambot but to install a quiet little backdoor that will allow someone to help himself to the contents of “My documents”. Typically, the backdoor software will allow access to a command shell and a simple file transfer mechanism. Sometimes the hacker gets lucky and finds that a senior manager has insisted that he should have a similar level of control over the network but that is a bonus.

Because these attacks affect very few users, they often slide under the radar, especially because most organizations would sooner not come out and say that they got hacked. Sometimes the backdoors are specifically created for that one target if it is high value enough and so AV solutions are not useful.

Given that, what are the best defenses? There are two:

1. User education. The information that executives hold is valuable. Someone needs to tell them how to protect it. Maybe that person should be you. Hey, it is something to put on your next review document.

2. Good network egress control. I speak to a lot of customers who regard any outgoing traffic (LAN/WAN to internet) as good and all unsolicited incoming traffic as bad. Now, consider that these are customers speaking to someone who specialized in compromised systems. Most malware can’t do much if it can’t call home. Good egress control is no substitute for good training but it is an excellent adjunct.

It is possible that an attacker could try the same thing anywhere in your organization since any access is better than none so you might want to spread the word to the whole company. It might save millions of dollars though you can never measure prevention. In the worst case, it is good and harmless. Please, spread the word.

Until next time, signing off

Mark

How malware likes to hide

marklon — Thu, 05 Jul 2007 18:58:00 GMT

Well, technically, how malware writers like to hide malware. In my last post, I talked about subversion – hacking the OS not to see the malware. That is part of the rootkit. Not all malware uses a rootkit and all malware has to avoid detection by signature based anti-malware tools like standard anti-virus solutions and anti-spyware solutions. The way that the first AV solutions worked was that they looks for the precise pattern of bytes or the MD5 hash of the file. Polymorphic viruses were built to defeat this although polymorphism is not limited to viruses. We habitually see it in Trojans as well. There are several ways that this can work.

The first and simplest is to include random junk data in the binary image and change it when you write a copy of the executable to a location. There are two good things about this approach. The good thing for the BlackHats is that it is really easy to do this. The good thing for the Whitehats is that it is pretty much ineffective if we are looking for byte patterns in files rather than just hashing the file. AV solutions that used signature files to look for matching patterns became the norm.

The next generation tried to alter the code in ways that didn’t much matter. Add a NOP here. Have multiple code fragments which do the same job and are the same length (easy enough if you pad with NOPs) or in the case of the terminally clever, moving things around into different “slots” within the code segment. This was a bit harder to counter but there are still a limited number of possible forms and so it just requires a LOT of different signatures. Annoying and it means that malware checks take a lot longer but still possible. Typically polymorphic code that works this way doesn’t want to change the length of a section of code because then they effectively have to relink themselves “on the fly” because the relative jumps will be off. That is fairly tricky to do and it would be difficult to write a re-linker that was itself polymorphic. Fixed code makes malware easier for automated systems to find.

What we see a lot of now is packed malware – it has a decryption engine built in to the malware and if you look at the malware in a disassembler, you see the code of the unpacking tool and not of the malware – it has become an encrypted payload deployed by the packer. This makes it very hard for an investigator to work out quite what the malware is doing. However, it doesn’t have quite the effect that the malware writers want. There are only a few packers available on the underground economy. Remember that I said that fixed code is easier for automated systems to find? If we find a packer designed to hide malware, we can assume that the file is malware. Thanks for the help, guys!

The war is far from won, of course. The botnets get ever larger and the varieties of malware multiply. Most botnets just spew SPAM of course – “pump and dump” schemes AKA boiler-room SPAM, adverts for V-I-A-G-Я-A or some other spelling of counterfeit drugs or the scam-du-jour. At the moment, we are seeing a lot of mails looking to recruit machines into botnets via social engineering – “run this trojan dropper to see your ecard”. Some attacks are smarter than others and some end users are better informed than others.

We are doing the best we can to make our SPAM filtering better, our code more secure and taking what legal measures we can to shut down the bad guys. The bad guys are throwing everything that they have at us and our users… just like every day.

Until next time

Mark

Malware over the years. It is only paranoia if they are not out to get you

marklon — Mon, 25 Jun 2007 23:56:00 GMT

In a slight change of pace, I would like to talk about malware and how things have evolved. I am not exactly a spring chicken which surprises some people because I am still part of the support organization. I like it here – I am working on real problems that affect real people. Working on pivot tables to make the stats say something different is not for me. Anyway, my hair is mostly white and I remember punch cards. The relevance of that is I have seen malware evolve from what it was to what it now.

The first malware that I ever saw was back in 1985 on the Atari ST. In those days, game rental was just beginning to happen and games came on one, two, or in the case of an epic, 3 disks. Of course, they still do but now we are talking DVDs with an 8.5GB capacity rather than 360KB floppies as then. The important difference was that floppy disks are writeable if the little tag was not covered by a sticky label or plastic slidy thing if you had those new fangled 3.5” drives… and the ST did. That early malware halted the process and displayed a banner saying that your computer was now alive.

Of course, that wasn’t the first malware. Some people credit Elk Cloner back in 1982, back on the Apple II. I would cite the much earlier “Cookie Monster” from 1960. This malware ran on Multics and required human intervention and social engineering to spread. It was relatively harmless in that it simply sent increasingly insistent requests for a cookie to the console of the user – this was all long before GUI interfaces. The program would “sleep” for a while if the user typed “cookie” on the console in response. The propagation method for Cookie monster was largely magnetic tape in contrast to the magnetic disks of the Atari ST. Malware didn’t spread across networks much because there were no networks. There was JANET in the UK and a fair few university (and US government) computers would allow a modem user to log on with the user name UCLA/Password “Guest” but we were years away from wide spread connectivity. ARPANET (which eventually became the internet which you may have come across) had its first virus (“creeper”) and first anti-virus (“reaper”) back in the 70s but this was before computers were common place.

Malware came to the PC in January 1986 with the Brain Virus. There was a second virus by the end of December. It was hard for malware to spread from machine to machine so it spread from disk to disk or executable to executable if you had a hard drive. Typically a virus would attach itself to a file and rely on the file being passed around. Boot sector viruses were sometimes seen on MS-DOS but they were not common.

Of course, the early malware had no stealth capabilities. I will be talking a bit about subversion in a later blog when it will all get very geeky again. Viruses were often named after the number of bytes that they added to the file. People got wise to those – and at this point, most computer users were professionals in the computer field. It was unusual to have a computer at home and they were not a part of everyday office life. For most people, windows were things that allowed fresh air in and a shortage of RAM was only a problem for sheep farmers. Things happened pretty rapidly after that but malware plodded along. By 1989, there were still fewer than 10 viruses in the wild for the PC.

1990 saw the first polymorphic virus that could change its signature to evade the first anti-malware solutions.

The first macro viruses appeared in Office around 1995. In those days, macros could automatically run with no warning. It was more innocent time. You can say “Naïve” and I won’t be offended.

May 2000 saw the “ILOVEYOU” worm. Not an especially clever bit of malware relying on some simple VBscript. It came on a world unprepared and computers the world over crashed. Things began to tighten up – and computers increased in numbers ever faster.

2003 was a bad year. SQL Slammer, Blaster, Sobig and Sober all hit that year. They had something else in common. They all used security vulnerabilities that we had released patches for quite some time before. There were some less famous viruses during this time.

2004 gave us MyDoom (spread via email) and Sasser. Oh, we had a patch for Sasser out before the malware hit. Some people are still reluctant to install patches. It was more common then than now. There were also a lot of lesser viruses and rootkits.

2005 saw Zotob which was not quite as bad as the press made out but it was not good. It only affected Windows 2000 which was not all that common by then. Oh, and the patch? Available before then. There were a host of other viruses by then, most of them using old vulnerabilities or social engineering.

2006 saw thousands of new malwares springing up – often dozens of variants of a single exploit and payload. The trend continued though 2007. There have been a few that have mildly successful but no pandemics so far – and don’t I know how like famous last words those sound!

What we see now is that malware writers are trying to reverse engineer our patches in the hope of creating a 0 day exploit – finding what we changed and then writing malware (be it rootkit or worm or whatever) that same day. The numbers make for scary reading. The patch for Nimda preceded the malware by 331 days. The patch for Slammer preceded the malware by 180 days. Nachi was 151 days. Blaster was only 25. Sasser was 17 days late. Zotob? 9 days.

Care to guess how long the next one will take?

Me? I advise patching early.

Signing off

Mark