Malware spotlight: Wabbit

Introduction

Beginnings are often steeped in myth, legend and a good helping of storytelling, with malware being no exception to this rule. Way back in 1974, before many of our readers were born, malware was still in its infancy, with early pioneers inventing different types of malware to simply explore what could be done. 

One such creation was the Wabbit — the first self-replicating malware. It was simple and crude, to be sure, and while the original Wabbit was not malicious, variants of the Wabbit can be programmed to exhibit malicious capabilities. 

This article will detail the Wabbit type of malware and will explore what Wabbit is, the history of Wabbit, how Wabbit works, the fork-bomb Wabbit variant, and potential applications for this early type of malware. 

What is Wabbit?

To properly discuss Wabbit, we first need to discuss the proverbial rabbit — I mean, elephant — in the room. The name Wabbit is in reference to Elmer Fudd’s way of saying rabbit from the old Looney Tunes cartoons. 

This name is incredibly accurate for what this malware is, as it refers to the fact that rabbits reproduce very fast. Wabbit is the first self-replicating malware to ever exist (some historians will argue that Creeper was) and can reproduce so fast that the system it is installed on literally chokes as its resources are all used up by Wabbit.

While the first instance of Wabbit was not malicious per se, killing a computer system is certainly malicious to the system owner if they are not expecting it. Moreover, Wabbit can be programmed to perform conscious malicious actions. One such variant of Wabbit is called the fork-bomb, which will be discussed later in this article. 

Due to the rarity of Wabbit and some of its unique peculiarities, modern malware discussions do not mention it as a type of malware. Looking back at it historically, however, it is clear to see that not only is it malware but possibly one of the best, as it has solid potential as an educational tool and for historical purposes as well.

The history of Wabbit

The history of Wabbit begins at literally the origin of malware as a concept, and like all good creation stories, this one is steeped in legend. 

There is only one known instance of Wabbit in its original, non-malicious form and this occurred back in 1974. In 1988, an individual known as Bill Kennedy recounted a story about a coworker who was working on an IBM OS/360 mainframe. This “bright young fellow” wrote a program named Wabbit that, as it ran, would eat up the resources of the system and cause a kind of resource constipation. 

Instead of infecting other network devices, Wabbit was only capable of infecting the system it was installed on. This constipation ultimately killed the system and ended up costing this bright young fellow his job. Since then, variants have been created that have had a more pointedly malicious intention. 

Wabbit is indeed a relic of a past computing age, essentially designed to take advantage of the way the IBM OS processed information. You see, IBM used to use what was called the ASP job stream, which would communicate with its console less and less as resources were consumed. Looking at this malware through modern eyes, Wabbit most closely matches up to the denial-of-service attack (DoS). 

How does Wabbit work?

The original inception of Wabbit worked a little differently than modern variants. This was mainly because of the older system framework (IBM OS) in place back in 1974, but the basic idea is the same. Wabbit creates an infinite loop that continually creates system processes and creates copies of Wabbit. This consumes operating system resources and creates a high number of CPU cycles which constipates the system, causing it to get slower and slower until it eventually crashes.

Later variants took this wascally Wabbit (pardon the Elmer Fudd reference) ability to newer operating systems — most notably Unix and Linux. 

The fork-bomb variant

The most well-known Wabbit variant is the fork-bomb. This version of Wabbit had the ability to run on Linux, Unix and Unix-like operating systems (Debian, Ubuntu, Red Hat and so on). 

In fork-bomb attacks, child processes self-replicate and consume a high amount of operating system resources, which ultimately stops legitimate processes from being created and running. As the attack progresses, the infected system ignores keyboard inputs, including logout attempts. The fork-loop consumes resources until the maximum allowed processes is reached which causes what is called kernel panic — where the kernel crashes because it cannot keep up with the fork loop. 

Most systems infected with fork-bomb stay frozen until restart, most commonly in the form of a hard restart. This will most certainly cause data loss. 

Wabbit application

Wabbit is most applicable in the arena of computer science and information security education. While Wabbit can cause damage to systems, it is a relatively simple piece of malware that can be used to demonstrate process and program replication in education. 

Computer science students can be given a time limit to stop Wabbit, where the natural end of the exercise is either stopping Wabbit or the infected system crashing. This would also have value in teaching students about just how simple malware can be and how you sometimes need to understand it to stop it.

Conclusion

Wabbit is one of the first instances of malware ever to exist. While simple, it can devastate a system by squandering all operating system resources until the infected system crashes. 

Wabbit was originally meant to be more tongue-in-cheek than malicious. However, this malware can easily be programmed to not only be malicious but also to infect modern systems, making it a bona fide type of malware.

Sources

1. Two old viruses, Risks Digest
2. Rabbit, Malware Wiki
3. The very first viruses: Creeper, Wabbit and Brain, InfoCarnivore
4. What is a Rabbit Virus or Fork Bomb or Wabbit?, The Security Buddy
5. Fork bomb attack (Rabbit virus), Imperva