1

I have been at the receiving end of some classic spoofed emails where the sender sends an email looking like it has come from a senior executive of the company. Of course, these are always asking for some money or the other to be transferred.

Closer examination of the email headers reveals a spoofed "From" address field and also a spoofed "Reply-to" address field.

My question(s):

  1. Is there any way to prevent this?
  2. Is there any way to report this given that it comes from the great internets?
  3. What security precautions (apart from please check emails carefully before replying) can I advise the finance and other teams?

closed as too broad by Steffen Ullrich, Anders, kasperd, Steve, Xander May 8 '17 at 14:09

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1. No, 2. report to whom? 3. This might be the only part of the question that is answerable. – schroeder May 5 '17 at 6:48
  • 3
    I propose to close the question as too broad. There are many questions on this site asking about how spoofing can be prevented or detected and the specifics depend on your actual (and in this case unknown) environment. So please do your own research first based on already existing answers. Also, please ask a single and specific question instead of asking multiple broad questions. – Steffen Ullrich May 5 '17 at 6:58
4
  1. Is there any way to prevent this?

Yes and no. You can't prevent email from being spoofed. But you can use electronically signed emails, and you can advise the IT staff to start using DKIM or similar, to prevent such emails from being accepted. After that:

  • a non-DKIM or non-signed email will be considered a forgery and rejected.
  • users will need to send emails through the organization's servers and/or sign them digitally with their private key.
  • users will need to only check the company email through the company server (no simply forwarding to convenient GMail accounts readable from the cell phone. You can still do that, of course; it just gets more complicated).
  1. Is there any way to report this given that it comes from the great internets?

Not really. You can try checking the headers and report them to the appropriate abuse office (i.e. that of the originating domain). Most such emails come from either zombied individual systems (maybe operating in groups - so-called bot nets) and/or domains and organizations that have been found to be either unresponsive or straight away friendly to forgers and spammers. There are actually lists of "promising pasture" networks circulating that allow abusers to find new victims.

  1. What security precautions (apart from please check emails carefully before replying) can I advise the finance and other teams?

Other people (the IT team) should implement what precautions can be taken, and the necessary infrastructure (for example, if lots of employees need to send emails while on the go, they might need to be equipped with VPN software so that they can securely use the organizational infrastructure even while on insecure grounds such as an Internet café somewhere). The other people should need do nothing except, as you suggested, carefully double check; and of course use properly whatever infrastructure they've been equipped with.

So, for example, if you do have a secure mail server, you need to go through the bother of actually firing up the VPN connection, authenticating, and sending the email, rather than just shooting an email from the hip from some unsecured hotel room WiFi.

That's particularly important for "weighty" individuals which, in my experience, often are tempted to consider themselves above the law, and will insist on having their emails read and immediately acted upon whatever the source, as they "haven't the time" of jumping through the various IT hoops (they are right up to a point: the security infrastructure must be as easy to use as possible, or it will be seen as a burden, will be routinely worked around, and thereby made useless).

One thing to carefully consider is how the various users connect now to the organizational infrastructure. In-house employees are obviously the easiest. But some OSes and cell phones, for example, cannot use certain security measures. So you either replace those devices, make do without those measures, or resign to some users being cut off from the network in certain circumstances.

In a pinch, you might need to set up some emergency procedure should the CEO ever find himself really stranded in Elbonia with no luggage, no documents, and need money to be sent over to catch a flight back home.

  • DKIM alone doesn't really help much with incoming mail, though. I can probably set up an account like uspresidentdonaldjtrump@gmail.com pretty easily, and anything I send from it will be properly DKIM signed by Google. That doesn't mean the email address corresponds to my true identity, which is a very different (and much harder, particularly in the general case) problem from establishing that the sender e-mail address corresponds to the real-life sender. – a CVn May 5 '17 at 8:10
  • @LSerni: Thank you for the detailed reply. Signed emails look very attractive. However, I just wanted to point out that we use third-party service providers for emails and not our own servers. Can we still use signed emails with third party service providers? – Sriram May 5 '17 at 10:28
  • Yes. You need to supply all employees with (a) a signing certificate of their own, (b) an automated tool/configuration/whatever that automatically signs outgoing emails, (c) some filter that clearly marks unsigned emails. When all emails with bad signature have a blood-red background, it becomes difficult to fall for a scam. AFAIK, Mozilla Thunderbird has provision for both the above. Not sure about Microsoft Outlook (it probably does it, but possibly requires some MS-style tweak). You will also need procedures for certificate revoking, expiry and reissuing – LSerni May 5 '17 at 10:37
2

First the basic rules concerning email headers: any single header can be spoofed, but they cannot be all spoofed at the same time.

That means that detection of a spoofed e-mail is rather easy for a human being with some knowledge about SMTP and the expected emails, but designing an algorithm to allow automatic detection is almost impossible. What is easy is to qualify a risk for an mail to be spoofed, but you will have to balance between false positive and non detection.

For my personnal mail, it would not be very important if I rejected a mail from a friend because if looked suspect. It will end in something like you didn't answer my last message - what message? - here is what I've sent - you fool, it was caught by my ansti-spam filter - you stupid, I'm not a spammer! - ok filter was too strict, I owe you a beer... No high risk here. But for a commercial company, automatic reject of a mail can have serious consequences, if a legitimate customer inadvertently sent a suspect mail.

A common usage in that case is to setup a suspect mail detection system. Simply suspect mails should not be rejected but their subject header should be prepended with a warning like [-*-*- SPAM -*-*-]. That way the recipient still receives the mail but is warned that something could be wrong with it. So she can eventually ask the supposed sender whether he has actually sent it or ask help form the IT support team. Of course, this assumes that the company has an internal mail server which is common for large organizations, but not for smaller ones. In that last case you can only rely on the filtering set up by the mail provider.

  • Many modern MUAs include some degree of spam filtering, usually Bayesian. Though you'd need to train it on whatever qualifies as "suspect" in your particular situation, and the sample set of such emails might not be very large. – a CVn May 5 '17 at 8:13

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