Max Harder | Atom Feed

Dissecting the ILOVEYOU Worm

2026-07-12T10:22:00+10:00

Introduction

ILOVEYOU (or LoveLetter) was a computer worm released on 4 May 2000 that infected tens of millions of Windows computers and caused damage estimated at USD 10 billion. It was written in Microsoft’s (now deprecated) VBScript by Manila-based Onel de Guzman, who was 23 years old at the time and a student at AMA Computer College. A part of the worm closely resembles a “trojan horse program” de Guzman outlined in a rejected thesis proposal three months earlier, which aimed to allow “Internet users to get Windows passwords such as Internet Accounts to spend more time on Internet without paying.”

The worm relied on social engineering in a novel way. Victims received an email with the subject line ILOVEYOU and a body telling them to “kindly check the attached LOVELETTER coming from me.” Those who clicked on the attached LOVE-LETTER-FOR-YOU.TXT.vbs file (the .vbs extension was often hidden to users), executed the malicious VBScript. It infected the system and, among other things, sent identical emails to all contacts in the victims’ address lists, spreading to other computers by impersonating a close contact with romantic feelings for the recipient.

Analysis

Finding a copy of the original ILOVEYOU worm that is completely unaltered at the byte level is difficult. The script was often reformatted and numerous variants began to spread shortly after its release. The most authoritative copy appears to be on Counterexploitation, which, however, was also reformatted and contains several formatting errors. A beautified and annotated copy of this version can be found on GitHub. The original script was named LOVE-LETTER-FOR-YOU.TXT.vbs and likely 10,307 bytes in size.

Structure

The script starts with two comment lines used by de Guzman to add his signatures:

rem  barok -loveletter(vbe) 
rem by: spyder  /  ispyder@mail.com  /  @GRAMMERSoft Group  /  Manila,Philippines

Barok is the name de Guzman (aka spyder) gave his password-stealing trojan, which the worm attempts to download. GRAMMERSoft was a group of hackers made up of AMA Computer College students, including spyder. Interestingly, de Guzman also provided his real location: Manila, Philippines.

Next, the script includes an instruction to ignore runtime errors, which allows it to continue even if one step fails (this is included at the beginning of almost every component of the script), global variables are defined, and a mechanism is set up that allows the worm to replicate itself by reading its own content. This is followed by a call of the first subroutine main(), which initialises the programme.

Overall, the ILOVEYOU worm is composed of eight subroutines (think named blocks of code that don’t return a value) that are in the following hierarchical order:

main() – initalises the worm

regruns() – downloads the trojan and creates persistence

regcreate(regkey,regvalue) – creates registry keys

html – creates an HTML version of the worm

spreadtoemail() – spreads the worm via email

listadriv() – iterates through folders in drives

folderlist(folderspec) – recursively iterates through subfolders

infectfiles(folderspec) – copies the worm into files and spreads the HTML version via IRC

In addition, three functions are defined, the first two of which are used in the regruns() subroutine, while the last one is never used:

regget(value) – reads registry entries

fileexist(filespec) – checks if a file exists

folderexist(folderspec) – supposed to check if a folder exists

Below, I describe the worm's five main steps in detail:

Initialise

Download trojan and create persistence

Create HTML version

Spread via email

Copy into files; spread via IRC

Step 1: Initialise

First, the main() subroutine ensures the Windows Scripting Host’s timeout is set to 0 to prevent interruptions in the scripts execution. It copies the worm into 3 files in the root and system folders (MSKernel32.vbs, Win32DLL.vbs, and LOVE-LETTER-FOR-YOU.TXT.vbs), and finally invokes the four main subroutines regrun(), spreadtoemail(), html, and listadriv().

Registry key changes:

HKEY_CURRENT_USER\Software\Microsoft\Windows Scripting Host\Settings\Timeout set to 0

Step 2: Download Trojan and Create Persistence

The regruns() subroutine uses regcreate() to set the two worm copies in MSKernel32.vbs and Win32DLL.vbs as registry entries for the registry keys listed below, ensuring they are executed every time the user logs on and also prior to that.

Registry key changes:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run\MSKernel32 set to worm copy in MSKernel32.vbs

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices\Win32DLL set to worm copy in Win32DLL.vbs

The subroutine then looks for the Internet Explorer’s download directory, and, if not found, sets C:\ as the temporary download directory.

It subsequently checks if a file named WinFAT32.exe exists in the system folder, which would indicate that the Barok trojan is already present. (Note that the function fileexist() inverts the FileExists() semantics.) If not, one of four URLs, selected based on a randomly generated number, is set as a registry entry in the registry key listed below, updating Internet Explorer’s start page to an attacker-controlled page that downloads the Barok trojan as WIN-BUGSFIX.exe.

Registry key changes:

HKCU\Software\Microsoft\Internet Explorer\Main\Start Page set to download URL for trojan in WIN-BUGSFIX.exe

After that, the worm script checks if the trojan already exists in the download directory. If that’s the case, the registry key listed below is created and set to WIN-BUGSFIX.exe, ensuring the trojan is executed every time the user logs on. Additionally, the registry key for Internet Explorer’s start page is set to a blank page.

Registry key changes:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run\WIN-BUGSFIX set to trojan in WIN-BUGSFIX.exe

HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\StartPage set to about:blank

Regarding Barok: While I don’t have access to the trojan’s source code, Marcus H. Sachs’s 2001 paper “Stealing Passwords from Microsoft Operating Systems” outlines how it works: Barok reads the Local Security Authority (LSA) secrets of a target computer and exfiltrates the contents to an SMTP mail account (MAILME@SUPER.NET.PH) on a remote computer by emailing them via a raw connection on TCP port 25, which leaves no evidence in the victim’s email client outbox of a sent message.

Step 3: Create HTML Version

The html subroutine replicates the worm as a web page named LOVE-LETTER-FOR-YOU.HTM in the system folder, which will be used later in an attempt to spread it via Internet Relay Chat (IRC) using the mIRC client.

HTML and JavaScript is used to create a window asking the victim to enable Microsoft’s (now deprecated) software framework ActiveX by clicking “Yes” in Internet Explorer’s confirmation window. More such windows are created on mouse movement and key press in an attempt to exhaust the victim.

ActiveX will be utilised to read the currently running script (the worm in LOVE-LETTER-FOR-YOU.TXT.vbs), which is then encoded.

Before that, however, VBScript code is provided that has the functionality to decode the encoded script, write it to the file MSKernel32.vbs in the system folder and include it in a registry key to ensure it executes every time the user logs on (just like in step 1). The code also contains (confusing) error handling for the ActiveX component, exiting silently if it failed or displaying the message “ERROR: can’t initialize ActiveX” if it succeeded.

Eventually, the file LOVE-LETTER-FOR-YOU.HTM is written to disk: first, the HTML / JavaScript part, then the encoded worm, and finally the additional VBScript code that has the ability to infect the system.

Step 4: Spread via Email

The spreadtoemail() subroutine launches Outlook and uses Microsoft’s Messaging Application Programming Interface (MAPI) to access the victim’s address lists.

The code that follows is easier to understand if I already explain what the subroutine does afterwards: It will add a registry key for each entry in an address list after the ILOVEYOU email is sent to the email address in that entry. This is to ensure that only one email is sent to each contact. Additionally, a registry key for each address list is added and set to the number of entries in that list. This allows the worm to check whether new entries were added to that address list the next time it executes.

The victim’s address lists are accessed, and then the worm iterates through them, checking for each list whether a corresponding registry key exists, and if that’s the case, it retrieves the registry entry. If the count inside the registry entry is smaller than the current number of entries in that address list (but larger than one), or if no registry key exists for that list, the worm’s signature ILOVEYOU email, including the malicious LOVE-LETTER-FOR-YOU.TXT.vbs attachment, is sent to all address list entries for which no registry keys exist yet.

After sending each email, the registry key for that address list entry is set. When the iteration through an address list is complete, the registry key for that address list is added or updated to keep the registry entry in sync with the current address list size.

Registry key changes:

HKEY_CURRENT_USER\Software\Microsoft\WAB\ set to 1 (for each entry in the address list)

HKEY_CURRENT_USER\Software\Microsoft\WAB\ set to number of address list entries (for each address list)

Note that emails are only sent out for address lists that contain more than one entry, which appears to be a bug.

Step 5: Copy into Files; Spread via IRC

The listadriv() subroutine checks for fixed and network drives and uses the recursive subroutine folderlist(folderspec) to iterate through the files in all folders and subfolders, which it “infects” using the infectfiles(folderspec) subroutine. The latter actually has two separate functionalities.

First, it iterates through the files in the current folder and checks their extensions to perform the following actions:

For .vbs or .vbe files, it copies the worm into them by using the mechanism set up in the very beginning of the VBScript, overwriting the original content.

For .js, .jse, .css, .wsh, .sct or .hta files, it creates .vbs files with the same base names, copies the worm into them, and deletes the original files.

For .jpg or .jpeg files, it copies the worm into them, creates copies of those files, maintaining the full names but adding .vbs extensions to them, and deletes the original files.

For .mp3 or .mp2 files, it creates copies of those files, maintaining the full names but adding .vbs extensions to them, copies the worm into them, and adds 2 to the attribute type of the original files, which turns “normal” files (0) into “hidden” files (2). (Already hidden files would be turned into system files [4]. For all other cases, the behaviour is undefined.)

Second, it looks for files related to mIRC (an IRC client), namely mirc32.exe, mlink32.exe, mirc.ini, script.ini, and mirc.hlp. If it encounters any of those files, a new file named script.ini is created, and an mIRC script is written to it that runs every time a person joins any channel the victim is a member of. It verifies that the person joining is not the victim themselves (if it was, the script would halt) and then, using the Direct Client-to-Client (DCC) SEND command, requests the person joining to accept the transfer of the file LOVE-LETTER-FOR-YOU.HTM to their computer.

Interestingly, the mIRC script also contains the following lines, which appear to be a social engineering attempt to prevent anyone opening the script from editing it:

; Please dont edit this script... mIRC will corrupt, if mIRC will ; corrupt... WINDOWS will affect and will not run correctly. thanks ; ;Khaled Mardam-Bey ;http://www.mirc.com

Summary

All in all, the ILOVEYOU worm was a relatively simple and slightly chaotic yet powerful piece of malware. Not only did it use novel social engineering techniques in a highly effective way, but it also excelled in replicating itself, with two separate ways of spreading to other computers. Additionally, the worm was able to infect systems with the Barok trojan and overwrite or delete victims’ files. While it had multiple dependencies that had to be met to reach its full potential, the worm was able to spread on such a large scale that it could compensate for this limitation.

Considering the devastating effects of the ILOVEYOU worm in the year 2000 and the fact that its author was a 23-year-old computer student in the Philippines whose radical idea of using password-stealing trojans to allow people to access the “Internet without paying” just got rejected by his lecturer as illegal, this is a unique malware that, in a strange way, deserves its place in history.

Communication Over Untrusted Networks

2025-10-26T00:00:00Z

Introduction

Communication makes you vulnerable – and that's not necessarily a bad thing. In fact, it's essential and allows you to form connections and grow as a person. But it also requires a great deal of trust. Some things, you may only want to share with someone who's very close to you, even if that person is actually very far away from you.

When you write down a message, you add an additional layer of vulnerability to your communication. The message continues to exist until it's destructed. This, too, can be something very valuable – love letters from your partner and the like. But love letters from your ex-partner? Well, normally it's not too difficult to dispose of them. But what about the love letters you sent? They're beyond your control now.

It can be even more difficult when the messages were sent over the Internet or any other digital network or medium. There are plenty of instant messaging services (and other apps that have a messaging functionality), and there's email and SMS, among other things. You probably have your own preferences when it comes to these services, and perhaps you would like a single, convenient app that everyone uses.

But how can you stay in control over your digital communication? I think, for a good reason, many people avoid asking themselves this question – it's complicated. Some people may even say ‘I have nothing to hide’ or something along that line. (Love letters, please.) But the truth is, the additional vulnerability that arises from handing over your messages and related data to an untrusted network – not only to someone else – is an actual threat.

Everyone is subject to personally identifiable data. Laws around the world differ, but if you're not residing in the European Union, it it likely that this data is the property of whoever collects it. It's beyond your control. Apart from corporations, there are also criminal actors and governments that systematically try to invade your privacy to sustain themselves (we all remember Edward Snowden's disclosures about government-led mass surveillance, including programmes like XKeyscore).

Encryption

You've probably heard about encryption, maybe even end-to-end encryption (E2EE). Encryption converts plaintext into so-called ciphertext that's unreadable by a human or computer without the proper encryption cipher and cryptographic key to decrypt it. That's nothing new. But service providers (or malicious actors) are technically still able to read the decrypted messages, as long as the encryption wasn't ‘end to end.’ With E2EE, only the sender and intended recipient can read the messages. No-one else. (Well, ideally. There are also things like backdoors so we still need trust, but we have a certain degree of autonomy here.)

Digital Communication Channels

When it comes to digital communication channels, there are plenty: dedicated instant messaging services, other apps that have a messaging functionality (think social media platforms), email, SMS et cetera, and each channel has its own implications for your privacy. Let me go into a bit more detail.

Transport-Encrypted

Many popular channels are, at best, only transport encrypted. Again, this means that at least the service providers or, at worst, anyone with the necessary technical skills, can read the messages sent over these channels, which include email, SMS, and lots of messaging applications and social media platforms. However, it should be noted that email and SMS are special in this context, as both use standardised communication protocols and hence avoid platform lock-in.

Email is probably the most common channel for formal correspondence. Most of us send and receive emails every day, and we often include – or have to include – sensitive information. Nowadays, transport-level encryption (between you and the server) is fairly common (such as STARTTLS) but not guaranteed. E2EE can be added, but it's cumbersome to use and unfortunately not very widely adopted. OpenPGP is a notable data encryption standard in this context, which associates each email address with a public/private key pair. (My public key is linked on my website, feel free to send me an email using E2EE with your comments on this post.)

SMS, short for Short Message Service, isn't Internet-protocol based and typically transmitted over cellular (or mobile) networks. While basic over-the-air encryption methods exist for SMS, they have significant limitations and vulnerabilities. But importantly, SMS does not support E2EE, and the mobile carriers involved in sending the messages have full access to them (and might even share data with third-party services). On top of that, SMS is likely the most costly way to transmit data in general if it's not included in your mobile plan.

Then there are Internet-protocol based instant messaging services like Tencent-owned WeChat and various other platforms with messaging functionality that don't support E2EE. Today, Transport Layer Security (TLS) often adds transport encryption, for example in HTTPS, short for Hypertext Transfer Protocol Secure, or MMTLS (a modified version of TLS 1.3) in the case of WeChat. However, the corporations behind those services can access all messages and usually collect as much data as possible about their users. On Instagram, there are optional chats with E2EE (‘this feature is only available in some areas’), but well, it's still Instagram (owned by Meta). Another notable example is Telegram (owned by Pavel Durov, who also co-founded VKontakte), which encrypts messages using its own layer of MTProto encryption, but it doesn't use E2EE by default. So-called Secret Chats that use E2EE have to be created separately, and this is only supported in one-on-one conversations (not in groups or channels).

Update: In March 2026, Instagram announced that E2EE messaging will no longer be supported after 8 May 2026.

End-To-End Encrypted

When discussing messaging apps using E2EE, it can be useful to focus on three dimensions: (1.) for-profit versus not-for-profit services, (2.) proprietary versus open-source code (which correlates with the former), and (3.) centralised versus decentralised infrastructure. I argue that not-for-profit services with open-source code and decentralised infrastructure are the preferred option for digital communication. This is because (1.) there's no interest in collecting and monetising user data as well as no barrier to entry, (2.) the source code is publicly accessible and anyone with the necessary technical skills can assess it or contribute to it (or even create their own version), and (3.) there are no single points of control and failure (such as technical outages, data breaches et cetera).

For-Profit, Proprietary, Centralised

WhatsApp (owned by Meta), and Facebook Messenger (also owned by Meta), which now appears to use E2EE for personal messages by default, fall into this category of for-profit services with proprietary source code and centralised infrastructure. In both instances, you have to trust Meta with your data, which is essentially its business model. In this context, the network effect that leads people into using these services is particularly problematic, as they inevitably become products themselves. The company also has a long history of lawsuits against it. For example, in May 2023, it was fined a record EUR 1.2 billion by the European Data Protection Board for breaching European Union data privacy laws. In addition, it has been shown that WhatsApp is particularly vulnerable to law-enforcement searches.

For-Profit, Open-Source, Centralised

Some services are for-profit and run on centralised infrastructure, but the code is (at least largely) open source. This includes Threema (the server code is proprietary) and Wire, for example. (If Telegram was using E2EE by default, it could probably also be mentioned under this category, though its server code is proprietary too.) The companies behind both services are headquartered in Switzerland and the servers are located either there or in the European Union, respectively, with relatively strong privacy laws protecting them. Both services aren't widely adopted for private communication. I assume part of the reason for this is the business model that isn't based on monetising user data but rather on selling apps (or licenses) and subscriptions.

Not-For-Profit, Open-Source, Centralised

Signal is an example of a not-for-profit service with open-source code and centralised infrastructure. The messenger, which has been endorsed by Edward Snowden on multiple occasions, is developed by the Signal Foundation (launched with initial funding from WhatsApp co-founder Brian Acton) and its subsidiary Signal Messenger LLC. Messages are encrypted with the Signal Protocol, which is generally considered secure and cryptographically sound (and has also been implemented into WhatsApp and Facebook Messenger, among others). However, the centralised nature of Signal makes it dependent on its large providers, as seen during the Amazon Web Services outage on 20 October 2025. Moreover, Signal requires a phone number from its users, which isn't ideal, and access to Signal was blocked in some countries, including Russia. Thanks to the open-source nature of the service (and to amazing developers), there's an independent, security-hardened, free and open-source fork of the Signal client called Molly (named after Molly Millions), which adds valuable features, such as database encryption and Tor support. The team behind Molly is also working on Flatline, a modified Signal server that won't use phone numbers to register accounts.

Not-For-Profit, Open-Source, Decentralised

Not-for-profit services with open-source code and decentralised infrastructure that use E2EE by default aren't exactly abundant, but I want to include the open communication protocol Matrix here, which is looked after by The Matrix.org Foundation. The protocol supports E2EE and modern clients like Element (developed by the for-profit company Element) enable it by default in private conversations. (The Foundation currently lists nearly 30 Matrix clients it's aware of, with different levels of maturity.) Matrix servers are federated, which means you can choose the ‘homeserver’ you want to use. Matrix also supports interoperability via bridges, which means that it's open to exchanging data and messages with other platforms, including Signal. My experience is that the use of Matrix is relatively common among free and open-source software developers, and Element also lists a number of large multinational corporations and government organisations as its customers. However, I think the onboarding can be quite complex, especially for those who aren't familiar with Matrix, as it does a lot of things differently.

Addition: There's also Delta Chat, which uses secure and interoperable chatmail relays. I won't go into detail here, but I think it definitely deserves a mention.

Conclusion

So, how can you stay in control over your digital communication? First of all, I highlighted that E2EE is a readily available and indispensable technology that significantly reduces vulnerability against malicious actors and mass surveillance in private conversations. Looking at messaging apps using E2EE, I introduced three dimensions: for-profit versus not-for-profit services, proprietary versus open-source code, and centralised versus decentralised infrastructure, and argued that not-for-profit services with open-source code and decentralised infrastructure are the preferred option for digital communication.

While the open communication protocol Matrix comes closest to my ideal, I also suggested that it might not be the most inclusive channel when it comes to usability. An alternative (with its own trade-offs) is Signal, which also has an independent fork called Molly with improved features. The point is that there are ways to protect our digital privacy. We just have to use them.