Goner combined a familiar-looking invitation with an attack on the software that protected a computer. The useful lesson is to follow the whole sequence: what the recipient ran, what the program changed and whether the system's defenses remained trustworthy.
This is a retrospective of a Windows worm reported in December 2001. The filenames and applications of that period provide historical context; use the current response guide for an incident today.
A screensaver that was executable code
F-Secure’s Goner analysis dates its discovery to December 4, 2001 and identifies a Visual Basic mass-mailer. It describes a GONE.SCR attachment, Outlook address-book propagation and transfer through ICQ. The program displayed animation and a false error, and attempted to interfere with antivirus and firewall software.
The screensaver presentation encouraged a recipient to treat the file as entertainment. Running it gave the code an opportunity to act. The case illustrates why a friendly message and an apparent display error are weak evidence about what executed.
Keep the actual file type in view. Microsoft’s file-extension reference explains how names and extensions relate to file types and how to show extensions in Windows. An icon or familiar-looking name is only part of the information needed to assess a file.
Check the defenses after suspicious execution
A security tool can be present on disk while its protective function is unavailable. For a modern investigation, record the active provider, reported protection status, recent alerts and any unexpected changes. On managed equipment, let the responsible administrator compare local observations with management records.
Modern systems may include controls intended to resist changes to security settings. For example, Microsoft documents tamper protection for specified Defender settings. Check the actual deployment and supported management process. The existence of such a feature is a reason to verify its state, not a substitute for investigating an unexpected failure.
An absent tray icon, a service error and a confirmed malicious change are different observations. Record precisely what occurred and when before deciding what it means.
Use a baseline as evidence
A baseline records an expected state at a particular time. Comparing files or configuration with that state can reveal changes worth investigating. Ask who established the baseline, whether it was trusted and which parts of the system it covered.
A list of changed files supports questions about those files. A complete recovery decision also considers accounts, persistent access, other devices and whether the original entry point has been addressed. Replacing an obvious missing application may leave those questions open.
For a work device, follow the incident responder's direction before deleting files or reinstalling software. Preserve observations that help establish the sequence. Use a separate trusted communication route if the device itself may be compromised.
Fictional example: the warning disappeared
A user runs an unexpected attachment, sees an error and then notices that the usual security status is missing. The support team records the attachment source, approximate execution time and missing status. An administrator checks the management console and finds that the device has stopped reporting.
The disappearing warning is not treated as successful cleanup. The team follows its incident procedure, investigates the lost reporting and requires evidence of a trustworthy system before returning it to normal use.
Carry forward the useful lesson
Goner is useful history because it links persuasion, execution and defensive interference. A good explanation keeps those events separate and asks what each observation establishes.
For prevention and routine checks, use the antivirus protection guide. For a wider investigation after a deceptive attachment, Mydoom’s backdoor lesson explains why the visible file may be only one part of the compromise.