Anatomy of a spam header - part 1 - forged virus scans
This is the first of a series of posts on the anatomy of spam headers (spamatomy). Throughout this series my common thrust will be that a great deal can be determined about the spammishness of an email by reference to headers alone.After the use of DNSBLs (suitably counterbalanced by whitelisting) to reject at source emails of dubious provenance, filtering on headers offers the first and best fallback. Headers either individually or in combination frequently contain unambiguous spam signs which can be used as the basis for a filter rule with complete confidence. Such a rule could be used to redirect spam to a holding mailbox somewhere for further analysis or to reject it outright by issuing a 554 at the end of the DATA phase of the SMTP transaction. NB - a rule should never cause an attempt to send a bounce or rejection message at any time after a message has been accepted.
Today's featured header (which I have mentioned here before) is the forged virus scan.
Largely in order to lend non-spam characteristics to spam emails and in an attempt to confuse content filters, much spamware by default inserts certain forged headers and increasingly frequently these include virus scans of various types.
However, as spamware authors have generally not taken care to ensure that their forged headers are valid, either singly or taken in combination, all that is needed for filtering purposes is an understanding of what the equivalent real header looks like.
Recently, many users here have begun to be troubled by spam which usually offers pornography, prescription medication or cheap software. Sources of these spams are invariably trojaned systems on domestic cable/DSL services and while protocol level blocking using DNSBLs probably takes out at least 95% of them, a fair few do still make it through. These spams all contain one of four purported anti-virus headers and presence of these headers, taken along with their content provides our opportunity to intervene before a user is inconvenienced.
Here is a list of significant variants of forged anti-virus headers taken from a large sample of recent spams.
- X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.10; AVE: 6.20.0.1; VDF: 6.20.0.46; host: [forged])
- X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.5; AVE: 6.17.0.2; VDF: 6.17.0.5; host: [forged])
- X-AntiVirus: OK! AntiVir MailGate Version 2.0.1; AVE: 6.15.0.0; VDF: 6.15.0.6
- X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/)
- X-GMX-Antivirus: 0 (no virus found)
- X-RAV-Antivirus: This e-mail has been scanned for viruses on host: [forged]
- X-RAV-AntiVirus: This message has been scanned for viruses on [forged]
- X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
- X-Virus-Scanned: by Ameriserv.net Anti-Virus E-Gateway
- X-Virus-Scanned: Symantec AntiVirus Scan Engine
- X-Virus-Scanned: Norton
- X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.5; AVE: 6.17.0.2; VDF: 6.17.0.5; host: [forged])
Now that we know what to look for, the next step is to look for it and act on what we find.
Sadly, ND6.5 does not make this very easy, but it is possible by using Daniel Koffler's "Hacking Domino mail rules to fight spam".
We have added four tests which work exactly like "Spam Assassin Report" in Daniel's article, but act on headers X-Antivirus, X-GMX-Antivirus, X-RAV-AntiVirus and X-Virus-Scanned.
A typical server mail rule to act on these headers is like this:
When X-Antivirus contains AntiVir MailGate AND X-Antivirus contains version: 2.0.1 move to database spamtrap.nsf
We currently have a total of six similar rules and these are preventing delivery of virtually all spams with forged AV headers. The false positive count remains zero.
I am aware that the rules could just as easily be like this:
When X-Antivirus contains AntiVir MailGate AND X-Antivirus contains version: 2.0.1 do not accept message
This would cause a 554 bounce before the end of the SMTP phase of message delivery. We currently prefer to receive samples though, to assist with tuning of local protocol level blocking.
Memo to Lotus: The ability to create server mail rules that can act on raw MIME would hugely improve the ability of the Domino administrator to react to new MIME header forgeries.
Category: Spamatomy
Technorati: Spamatomy
Unable to post a comment? Please read this for a possible explanation...
- 
