Once upon a time

Back in 1987, the 13th November was a Friday. It was also the first trigger date for the Jerusalem virus. (You may think there are problems with virus naming now, but back in 1987, there were serious issues – Jerusalem was also called Friday the 13th 1813, Hebrew University, Israeli and Suriv-3.).

In 1988, Jerusalem caused the first major computer virus epidemic – it infected enterprises, government offices and academic institutions around the world. Now, we’ve got used to virus outbreaks, and it’s hard to imagine the world without them. My days in the antivirus world don’t go back to the days of the Jerusalem epidemic. But along with Stoned and Cascade, Jerusalem was still one of the big three infectors when I started doing antivirus technical support back in 1990.

At the time of the epidemic, connectivity meant sharing files over a LAN, and floppy disks were the main way that files were transferred. This meant viruses required time to reach critical mass. If the author of Jerusalem had picked a different (ie more frequent) trigger mechanism, the virus would have been more noticeable, and it might not have been able to spread so far.

Jerusalem was a memory resident infector of COM and EXE files, although it tried to be inconspicuous by not infecting COMMAND.COM. (In the early days of viruses it was a common misconception that you could spot a virus infection simply by checking COMMAND.COM to see if it had increased in size.)

The virus had several payloads. The best known of these was that on Friday 13th it deleted programs that were run on the infected machine. As Friday 13th doesn’t occur that often, most of the time Jerusalem spread without detonating its payload – this meant that it was able to spread unnoticed most of the time. 30 minutes after loading into memory, the virus would also slowed down a PC XT machine to around a fifth of its speed, and display a small black rectangle when the screen was in text mode.

Jerusalem was also notable for two bugs in its code. First, its self-recognition code, used to identify files that were already infected, did not work for EXE files. As a result, EXE files would continue to grow every time the user ran them, until they became too big to load into memory.
Second, the virus used INT 21 functions that were required by Novell NetWare, so the two were incompatible: Jerusalem would, among other things, cause workstations to be disconnected from the network, or generate large spool files.

In the years following its first appearance, Jerusalem spawned a great number of variants.

Kaspersky researchers have discovered new Mirage Kitten attacks using previously undocumented malware families: NodeRabbit in Node.js and PollCat in JavaScript.

Our experts discovered a new CoolClient backdoor variant with a kernel-mode rootkit driver that hides malicious processes, files, and network connections from security tools and threat analysts.

Kaspersky experts break down a new Armored Likho campaign that poses as a fundraising efforts and delivers a new Still Toolkit aimed at stealing Telegram data and eavesdropping on victims.

Kaspersky researchers reveal previously undocumented malware attributed to Mirage Kitten (UNC1549, Smoke Sandstorm, Nimbus Manticore): NightLedger backdoor, ArcBridge, and BridgeHead tunneling tools.