Detecting email tha...
 
Notifications
Clear all

Detecting email that arrived over IMAP, not SMTP

3 Posts
2 Users
0 Reactions
1,097 Views
(@terracottafaceloth)
New Member
Joined: 6 years ago
Posts: 2
Topic starter  

Hello all, amateur here.

I have generally relied on email headers, particularly Received, to establish when faked email has been sent. However, I have discovered a method by which an email with wholly arbitrary headers may arrive in an IMAP Inbox.

Q GMail's "Account activity details" can be usefully used to rule out this particular trick. On an ordinary gmail account (ie, not G Suite), what other options do I have?

Process
Mallory has obtained Alice's email username and password and discovers she has an unread email containing an invoice. He takes a complete copy of the email and determines to upload an otherwise identical email with the banking details changed.

1. Mallory syncs an IMAP client with Alice's server
2. In the IMAP client he moves the target email to a folder of its own
3. He closes the IMAP client
4. He locates the target email in his local file system
5. He so edits the target email that the banking details in the invoice are changed
6. Mallory reopens his IMAP client
7. He marks the now forged email as unread
8. He moves it to the Inbox and removes the folder it was moved from, actions which are synced to the server
9. He disconnects his IMAP client and waits for Alice to read her email.

Notes
1. As Mallory at no point used SMTP, there are no changes to the original email other than those Mallory chose. That is, the forged email contains wholly authentic headers.
2. Gmail offers "Account Activity details" on their ordinary site, detailing the last ten accesses to that mailbox.
2a. Fewer than ten entries suggests all entries ever are recorded, per Google's docs
2b. IMAP not appearing in fewer than ten entries suggests IMAP has never been used to connect to that mailbox. Given this, Mallory could not have used the above process - the email must have arrived there by SMTP, and so at least one Received line is reliable.
2c. As the Date/Time of the entries are given, presence and absence of IMAP connections at particular points offers evidence. For instance, if the last IMAP connection was six days before the email appeared, and Alice checks her email daily, that lends weight that the email arrived via SMTP.

Some mitigations
1. If IMAP becomes aware of an email that was not received through SMTP, that could be identified with a header.
2. Making the SMTP log available, adding a hash of the email as saved to disk would help.

Background
I hunted spammers in my Email and on Usenet back in the day, when sysops loved to wield the banhammer, so I know my way around SMTP, NNTP; the above research arose after discovering invoice fraud perpetrated on a client of mine, when the purported sender turned out to be the actual sender. That was a first for me. It's unclear as yet whether the fraud was authorized by their board, or was as a result of the sender's computers being compromised. The case remains pending, but the analysis above would weigh in Alice's favor as to who is responsible for the loss. I confirmed the process to my own satisfaction using Gmail, Thunderbird and Linux.


   
Quote
gungora
(@gungora)
Eminent Member
Joined: 8 years ago
Posts: 33
 

A couple of ideas that might help with detection

1. As Mallory at no point used SMTP, there are no changes to the original email other than those Mallory chose. That is, the forged email contains wholly authentic headers.

I don't think this is entirely true. Once Mallory changes the contents of the message body and/or attachments, the DKIM signatures in the message header would no longer agree with the message contents and DKIM verification would fail.

8. He moves it to the Inbox and removes the folder it was moved from, actions which are synced to the server

When Mallory syncs the modified message to the server via IMAP, the email client would issue the APPEND IMAP command which would result in out-of-order IMAP UIDs within the target folder and possibly updated Internal Dates that reflect the time of the APPEND operation depending on how the APPEND command was issued. The effect of this would be less apparent if the message of interest is the last message in the folder and Mallory does the work relatively quickly.

I've posted a few quick writeups on DKIM verification and message authentication on IMAP servers. You might find these helpful

Using IMAP Internal Date for Forensic Email Authentication

Forensic Examination of Manipulated Email in Gmail

Leveraging DKIM in Email Forensics


   
ReplyQuote
(@terracottafaceloth)
New Member
Joined: 6 years ago
Posts: 2
Topic starter  

@gungora Many, many thanks for your careful response. In this case the bank now turns out to have incorrectly applied their blacklists and so made my client whole - case closed from his point of view. I on the other hand, thanks to you, consider myself just that little bit wiser for Next Time.

Cheers!


   
ReplyQuote
Share: