One way to fail at malspam - give recipients the wrong password for an encrypted attachment

Published: 2021-07-14
Last Updated: 2021-07-14 11:06:36 UTC
by Jan Kopriva (Version: 1)
4 comment(s)

It is not unusual for malspam authors to encrypt the malicious files that they attach to messages they send out. Whether they encrypt the malicious file itself (as in the case of a password-protected Office document) or embed it in an encrypted archive, encryption can sometimes help attackers to get their creations past e-mail security scans.

In such cases, the one thing they have to make sure of is – of course – that they send the right password to the user along with the encrypted file. As the message that made its way to my spam trap this week shows, however, this may not always be as simple as it seems…

The message in question looked like a generic information about a parcel from DHL. Its author decided to spoof the sender address to make it look like the message originated from (which resulted in an SPF check failure, since DHL has a valid SPF record published) and to include the password to the attachment in the body of the e-mail, which was itself composed entirely of one large PNG file.

For attackers, the use of images instead of HTML/text content in the body of an e-mail can have some clear benefits. Since anti-spam and anti-phishing mechanisms on e-mail security appliances usually don’t do OCR and subsequent analysis of any text contained within the images, it can allow the attackers to use pretty much any verbiage without the need to fear that they will run into any linguistic/word list-based security checks. However, since this is a well-known technique, message containing nothing but an image can sometimes easily end up classified as suspicious... But back to our message.

The password that was included in the text (“AWB3604”) was – as you have undoubtedly guessed – not correct, and any attempt to extract the contents of the attached archive using it would fail. This means that even if the message did make it into someone’s inbox, the (most likely) malicious EXE contained within the attachment would not pose any danger to the recipient’s machine.

At this point, you migth ask how much of a mistake did the attackers really make. Was the password mentioned in the message entirely wrong or would a user willing to experiment with it a little be able to decrypt the attachment?

I tried to find out. At this point, my assumption was, that the attackers perhaps made a simple mistake in the digit portion of the password and that since the AWB number mentioned in the header portion of the text was “7253****8341”, the correct password might be either “AWB7253” or “AWB8341”.

Neither worked, so I have then decided to try to brute-force the digit part of the password (“AWB0000” – “AWB9999”). This was also unsuccessful, so I tried to do some simple substitutions and modifications (such as “ABW 0000” – “ABW 9999”, “DHL0000” – “DHL9999”, etc.) and even tried running few of the larger password lists against the file.

Since not even one of these attempts at decrypting the attachment resulted in success, it makes one wonder whether the attackers do any “testing” at all before they send their messages out…

Well, I guess that if they don’t, all the better for us.

Jan Kopriva
Alef Nula

4 comment(s)


Never skip the testing phase of your SSDLC. :) #mvp
Did they have a custom reply-to so that they would rely on the user to reply to the message to help the phishing compromise be successful.
I would be interested to see what happens if you try to reply to the scammer as a "clueless end user".
Nice idea, but no, any reply to this message would have gone to the folks at
I did it once, reply to the sender email after mail sandbox deleted the file asking him to send it to my gmail account with a password protected. He did it :)
Then after few weeks gmail was showing some warnings that probably some state-sponsor attackers are trying to hack you.

Diary Archives