Bagel is back (again)

happygeek 0 346 Views

According to my Finnish friends, F-Secure, Bagle looks like it might be back in business. Not that it has ever really gone away of course, as it is one of the most prevalent of worm families.

F-Secure have noticed new activity during the last couple of days, which sees a number of old Bagle update URLs activated again. This time they are making a new executable available, which can be downloaded and executed by those machines already infected by previous variant. Of course, one thing never really changes and that is the payload, so expect to see spams containing infected attachments, this time with filenames that refer to price lists as an inducement to open them. Handily, the spam also comes complete with an image that illustrates the password required to decode the attached Zip archives.

What has changed is that Bagle.GO, as F-Secure has christened it, will use an SSDT rootkit in order to hide the fact that it has installed upon an infected system. As well as ensuring your AV system is up to date with signature files, you might want to keep an eye on firewall logs for any access to either or which are used by Bagle.GO

The worrying thing is that given the number of unpatched systems out there, and given the number of Bagel variants, and given the number of machines therefore infected with it the coming of another Bagel driven spam wave is, well, a given…

Dani AI

Generated

As points out, Bagle has a long history of reappearing and of using infected hosts to send large volumes of spam. That behaviour — harvesting local addresses, running its own SMTP engine and updating infected systems from remote URLs — is well documented for the Bagle family. Bagle (computer worm).

A key escalation here is the use of kernel-level hiding (SSDT hooking). An SSDT-style rootkit modifies the System Service Descriptor Table so selected system calls are redirected to malicious code; as a result in‑OS tools and some scanners can be shown “clean” while the malware remains active. This is why kernel/rootkit infections need a different response than ordinary malware. System Service Descriptor Table • Rootkit overview and examples.

Practical checklist for admins/operators:

  • Isolate suspected hosts immediately and preserve volatile data (netstat, running processes, memory image) for analysis.
  • Look for unusual outbound SMTP or large spikes in mail volume at the gateway; Bagle-type bots will attempt direct mail delivery from endpoints.
  • Do not rely solely on an in‑OS scanner when a kernel hook is suspected — boot from trusted rescue media and run offline scans, or use specialized anti‑rootkit analysis tools to collect evidence first. Tools historically used for rootkit discovery include RootkitRevealer (Sysinternals) and specialist memory/boot scanners; treat their output as diagnostic input, not a guaranteed cleanup. RootkitRevealer docs • Rootkit detection notes.

If a kernel/rootkit is confirmed, rebuild from known‑good media (wipe/reimage) rather than trusting an in-place “fix” — rootkits can alter kernel state and persistence mechanisms that are hard to prove removed. Preserve logs, block direct outbound SMTP from endpoints (force authenticated gateway mail), quarantine suspicious attachments at the gateway, and make sure backups used for restore are clean. Why reimage is recommended for deep rootkits.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.

Edit Preview