Bagle.C shows why an email address appearing on a malicious message is only the beginning of an investigation. Addresses can be collected from files and placed into messages without the owner of that address sending them through their account.
The worm appeared in late February 2004. Some period reporting used the spelling “Bagel”; the threat descriptions cited here use Bagle.C. The exact variant matters when comparing historical dates and behavior.
What the period analyses establish
F-Secure’s Bagle.C analysis describes a ZIP attachment containing executable code, a spreadsheet-like icon, address harvesting, a built-in mail-sending engine and a forged sender field. It also records a remote-access component after execution. These are separate parts of the attack: the lure, the distribution method and the access left on the computer.
The discovery dates differ slightly across primary accounts. Kaspersky’s Bagle history lists the C variant on February 27, 2004; F-Secure places its first in-the-wild finding early on February 28. Those are attributed observations, rather than a reason to transfer details from another variant.
Separate the address from the account
A sender field is a claim made within a message. An address can also be exposed in a document, address book or archived message on somebody else's machine. Its appearance does not by itself identify which device supplied it or prove that the associated mailbox was accessed.
For a current investigation, the mail provider's authentication and delivery evidence may help explain how the message arrived. Microsoft’s email-authentication overview distinguishes mechanisms that assess sending domains and message signatures. Their results need to be read in the context of the receiving service. The sender-authentication guide explains the practical limits.
Account activity is a separate evidence source. Look through the provider's trusted interface for unfamiliar sessions, changed recovery details, forwarding rules or other relevant events. On an organizational account, preserve the message and ask the mail administrator to review it through the approved workflow.
Ask questions that distinguish the possibilities
- What was observed? A message displaying an address, a provider alert, an unfamiliar session, or confirmed unauthorized mail?
- Who observed it? Preserve the recipient's report and the receiving service's evidence.
- What access is known? Distinguish a forged address from an account session and from code running on a device.
- What remains uncertain? Record gaps instead of assigning blame from the visible sender field.
If an attachment ran, the investigation also needs to assess the device. Deleting a received message addresses that item; it does not establish what happened on a machine that executed its contents. The Mydoom guide develops the related problem of continued access after the initial lure.
Fictional example: a supplier appears to send malware
A customer reports an unexpected attachment apparently from a supplier. The supplier checks through its normal account interface and asks its administrator to examine the report. The administrator treats the displayed address as a lead, compares available mail evidence and investigates any unfamiliar account activity.
If the customer already ran the attachment, its own incident process proceeds independently. The sender investigation and recipient-device investigation answer different questions and may need different responders.
Read historical indicators carefully
A period report's subject lines, ports and programmed dates describe a particular sample or variant. They should not become a universal checklist for deciding whether a current email is safe. An apparently familiar subject can accompany either legitimate or harmful content.
Use the historical case to improve the questions you ask: what is claimed, what has been observed and which system can supply the missing evidence? For current containment and account recovery, use the Anti Virus response guide.