0

I want to be able to spot a phishing email. What are the things to check when investigating and doing forensics on one?

There are some things I know to look for already but I want to get moer technical with it. Here are some things I already look for:

  • verify the sender (actually looking at the senders email rather than just the displayed name)
  • hover over the link in the email and look at the URL address listed at the bottom. If the URL looks suspicious, dont click it. I almost never click links in my email anyways.
  • only attached .txt files are safe, otherwise I do not download anything attached to the email unless I was expecting it and I verified it is from the person I knew it was supposed to come from. Found a good write up here on how to check attachments https://security.stackexchange.com/a/32931/22691
  • I believe there is a way to check the header of the email. Checking the domain name and IP address in the “Received” field which will validate if it was spoofed by a email spoofing site or someone with a suspicious email address. If it is just the IP address you can check it using a site like whois.com.
  • Also checking the validation results in the Received-SPF field in the header. Mail sent from permitted servers will show up as “Pass” in the Received-SPF field, which is a very strong indicator that the email is legitimate. If the results show “Fail” or “Softfail”, that’s a sign the email may be spoofed, though it’s not 100% certain since some domains don’t keep their SPF records up to date, resulting in validation failures.
  • Look out for how the email was written. If it is misspelled a lot, similar spellings to what you would expect making it look suspicious, sounds urgent or threatning, asking for any personal data like passwords/social security numbers/etc

Is there anything that I am missing?

  • 1
    Your assumption about .txt files being safe is wrong. Notepad, vim and many other text editors/IDEs have features or suffered from vulnerabilities that could have been exploited via a .txt file. You should review all potentially malicious data in isolation if possible – wireghoul Feb 12 at 5:52
1

You've got a few important ones on your list already, such as spelling mistakes and display names vs. sender address. Also the redirection links are good to investigate before clicking.

But then there are also some serious erroneous assumptions that can get you in trouble:

  1. .txt files are not necessarily safe. Editors have vulnerabilities and sometimes extensions are hidden by your OS which only make it look like a text file.
  2. Good spoofing attacks will generally come from a server that has been compromised and still has a good reputation. IP address look-ups don't necessarily tell you anything about trustworthiness.
  3. Besides the IP address itself, there are many companies that use third party email services to send out legitimate emails. It is hard to tell if an IP address belongs to a legitimate service simply because there are so many.
  4. Trusting the SPF check result in an email header as an indicator of spoofing is a bad practice. Legitimate emails that get forwarded generally have failing SPF checks, while good spoofers of malicious emails generally have passing SPF checks. This is because the SPF check is being executed on the domain that corresponds with the Return-Path address, where bounces / Non-Delivery Reports (NDRs) are sent. While most email clients show the From: field of an email, which is not technically linked to the Return-Path domain.

What to look for then?

DMARC is a newer standard that works on top of SPF and DKIM (DomainKeys Identified Mail). It actually demands alignment between the domains used in both authentication checks, with the domain used in FROM field address. The DMARC result is usually added to the Authentication-Results header. It passes if either one of both SPF or DKIM produces a Pass result in alignment with the From: field domain.

If a DMARC record is not present for the From: address domain, you can check yourself if the SPF domain or DKIM domain (d= tag) match up with the domain in the From: header (not the Sender: header or Reply-to: header or any other header).

Holy grail

There is no such thing as the holy grail of anti-phishing. There are DNS and ASCII-art attacks possibly impacting DMARC results. DMARC can pass on a common domain A while the Display Name used was from common domain B. ex: From: Bank of America <support@uber.com>. You need to apply all tactics and always think twice when you are requested to fill out PII, credentials, banking information or download attachments or click links.

0

Check the headers of the email, verify the domain name and IP address in the “Received” field and the validation results in the Received-SPF field.

That's pretty much it,

enter image description here

  • SPF is actually a bad indicator. SPF usually breaks in case of forwarding. It also only authenticates the Return-Path domain, not the domain in the From: address. Therefor, SPF can pass on Domain A while spoofing Domain B (general practice with more sophisticated phishing). – Reinto Feb 12 at 15:45
  • Knew I had to star this post, good to know this, thanks a lot for sharing your knowledge – IceeFrog Feb 12 at 16:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.