"Comment stuffing" in an HTML phishing attachment as a mechanism for evading AI-based detection?, (Fri, Jul 10th)

Anyone who deals with phishing messages caught by basic security filters knows that most phishing samples tend to blend into one another, since only a small set of techniques and approaches keeps reappearing in them. That is precisely why it is worth pausing on the occasional message that does something a little out of the ordinary. One such unusual message was caught on Tuesday by an e-mail security solution used by one of my clients. At first glance, both the e-mail body and the attached credential-stealing HTML page looked entirely generic, however, the fact that the attachment was fairly large, and that Outlook claimed the date on which the e-mail had been sent was None , caught my attention and made me take a second look Which was fortunate, because it appears that the large size of the attachment might be connected to the increasing role that AI is playing in e-mail security in an interesting way. Before we get to the attachment, however, the phishing message itself deserves a brief mention, since several small details in its headers suggest that it was not sent through any normal mail path, but rather generated by a simple, homemade script. The e-mail presented itself as a Microsoft Teams notification about a document shared over SharePoint, with another document attached directly to the message (note the text None in the upper right corner where a date should be). As you can see, the From header claimed that the message came from Microsoft Teams Notifications [email protected] . Unsurprisingly, this actually wasn t the case When looking at the headers, three interesting points stood out: It turned out that the envelope sender was empty (i.e., MAIL FROM: was used). In principle, the use of an empty envelope sender which is called a null reverse-path is perfectly legitimate[ 1 ]. It is what bounce messages are supposed to use, so this was not a violation of any standard. It did, however, mean that there was no envelope domain against which SPF could be evaluated, which is why the receiving system fell back to the HELO/EHLO identity and ended up checking postmaster@[10.88.0.3] i.e., an internal/RFC 1918 address presented by the sending host (which was actually hosted on the public IP 35.195.254.112 in the Google Cloud). Since we mentioned SPF, it is worth adding that no DKIM signature was present either (for obvious reasons), and that DMARC evaluation therefore unsurprisingly failed. The message carried no Date header whatsoever, which was the reason for the None date shown by Outlook. Unlike the empty envelope sender, this is against standardized requirements, as RFC 5322 requires an origination date field to be present[ 2 ]. A message put together by any normal e-mail client (or sent through a normal e-mail server) would essentially always have one, so its absence is telling. The X-Priority header was set to 0. This header was never formally standardized in an RFC, but per Microsoft s specification[ 3 ], which is the de-facto author