Uptick in base64 encoded SPAM

[tgx]

We have noticed an uptick in spam being sent this way and our filters are not able
to match on them. What is the best way to reject base64 encoded SPAM? Thanks.

[JDunphy]

SA doesn't have any issue with base64 and their rules do run against it. They won't run against if it's an attachment of course but for html or text, they have no problem. Perhaps you could begin to look for patterns when its base64. Here is one we do.

Code: Select all

full __J_BASE64_HACK    /=D[01]=[A-F0-9][A-F0-9][A-Za-z]+\s*/i
tflags __J_BASE64_HACK   multiple maxhits=7
meta J_BASE64_HACK      (__J_BASE64_HACK > 5)
score J_BASE64_HACK     2
describe J_BASE64_HACK  mixing and matching plain text w/ base64 encoding to fool filters

Grab a few base64 spam emails and run it through SA in debug mode to see what other custom meta rules you might create from rules (tests/subtests) that fired. Dropping all base64 would be a huge mistake and would cause many FP's if that is where you were headed. Generally, this type of spam tends to stand out... here is a section of output from running a junk email message with SA in debug mode and the many rules that fired to give you an example.

Code: Select all

Jul  7 11:53:00.781 [7232] dbg: check: tests=HTTP_IN_BODY,J_BASE64_OBFUSCATE,MIME_BASE64_TEXT,RCVD_DOUBLE_IP_SPAM
Jul  7 11:53:00.781 [7232] dbg: check: subtests=__ANY_TEXT_ATTACH,__ANY_TEXT_ATTACH_DOC,__BODY_TEXT_LINE,__BODY_TEXT_LINE,__BODY_TEXT_LINE,__BOUNCE_RPATH_NULL,__CT,__CTYPE_HAS_BOUNDARY,__CTYPE_MULTIPART_ANY,__CTYPE_MULTIPART_MIXED,__DOS_HAS_ANY_URI,__DOS_RCVD_MON,__DOS_RCVD_TUE,__DOS_RELAYED_EXT,__DOUBLE_IP_LOOSE,__DOUBLE_IP_SPAM_1,__ENCODE_BASE64,__ENCODE_PRESENT_TXT,__ENV_AND_HDR_FROM_MATCH,__FORGED_SENDER,__FROM_ENCODED_B64,__HAS_ANY_URI,__HAS_DATE,__HAS_FROM,__HAS_MESSAGE_ID,__HAS_MSGID,__HAS_RCVD,__HAS_SUBJECT,__HAS_TO,__HAS_URI,__JM_REACTOR_DATE,__KAM_BODY_LENGTH_LT_1024,__KAM_BODY_LENGTH_LT_512,__KHOP_NO_FULL_NAME,__LAST_EXTERNAL_RELAY_NO_AUTH,__LAST_UNTRUSTED_RELAY_NO_AUTH,__LCL__ENV_AND_HDR_FROM_MATCH,__LCL__KAM_BODY_LENGTH_LT_1024,__LCL__KAM_BODY_LENGTH_LT_512,__LOCAL_PP_NONPPURL,__MIME_BASE64,__MIME_VERSION,__MISSING_REF,__MISSING_REPLY,__MSGID_OK_DIGITS,__MSGID_OK_HOST,__NAKED_TO,__NONEMPTY_BODY,__NUMBERS_IN_SUBJ,__RATWARE_0_TZ_DATE,__RCD_RDNS_MAIL_MESSY,__SANE_MSGID,__SUBJECT_ENCODED_B64,__SUBJECT_UTF8_B_ENCODED,__TOCC_EXISTS,__TO_NO_ARROWS_R,__TVD_MIME_ATT_TP

For a deeper look, take a look at /opt/zimbra/data/spamassassin/state/3.004001/updates_spamassassin_org for your latest rules and /opt/zimbra/common/lib/perl5/Mail/SpamAssassin/Plugin for the code. Lots of examples there for ideas.

Note: this website is a great reference for some quick cut/paste to see what you have given what is firing for your type of spam and viewing the source.

Ref: https://www.base64decode.org/

Kevin McGrail (Chair Emeritus Apache SpamAssassin Project) keeps his latest rules he runs himself at: https://mcgrail.com/downloads/KAM.cf
Great way to learn about writing rules by example given his vast knowledge of SA. Lastly the SA users mailing list can be very helpful if you post a sample of your spam via pastebin and ask specific questions about best method for a rule, etc.
Ref: https://cwiki.apache.org/confluence/dis ... ilingLists

We don't find base64 spam to be much of a problem so it's hard to be more specific of what else to recommend.

HTH,

Jim

[tgx]

What I am seeing is the email subject and body are base64 encoded.
It seems that no checking is being performed on them as they fly straight through
two different anti-spam systems I have in play.

I guess what I would like to see is a way to simply block base64 encoded emails as
I see no business case for allowing them.

[JDunphy]

What I am seeing is the email subject and body are base64 encoded.
It seems that no checking is being performed on them as they fly straight through
two different anti-spam systems I have in play.

Interesting, base64 sounds to be a reasonable spam hit as it would be obfuscating the subject line IMO. BASE64 by itself is not a reliable indicator of spam.

SA has a few rules already looking for this in Subject/From headers.

Code: Select all

header __SUBJECT_ENCODED_B64    Subject:raw =~ /=\?\S+\?B\?/i
header __FROM_ENCODED_B64       From:raw =~ /=\?\S+\?B\?/i
meta FROM_EXCESS_BASE64         __FROM_ENCODED_B64 && !__FROM_NEEDS_MIME2
describe FROM_EXCESS_BASE64     From: base64 encoded unnecessarily

Note: these __SUBJECT/__From B64 rules would lead to false positives by themselves with utf8 which is why they are part of more specific meta rules for point scoring.

Something does seem to be off if "no checking is being performed" in your environment... At the very least you should have seen __SUBJECT_ENCODED_B64 in the SA debug output for subtests when base64 is used in the Subject.
There are a ton of other base64 rules ... egrep '(BASE64|B64)' would show you most of the existing rules for base64. Sounds like a new rule or two will help you score your base64 spam to junk or discard.