Blog: How Tos
Help users spot phishing. Tag fake “internal” emails for them
I spend a fair amount of my time trying to break into organisations using just their domain name as a starting point. We labelled this exercise ‘Brand Damage’, the process starts off with open source intelligence gathering and then a phish to try and gain remote access to the internal network. Once we have access we traverse the network looking for ‘interesting’ data and exfiltrate it thus simulating a breach and causing damage to the organisations’ brand.
These days phishing is a well known technique, but on almost all engagements we still get users executing content and disclosing credentials. The process for us trying to coerce users into performing these actions revolves around generating emails that purport to be from inside the business, i.e. from the IT team, HR, etc.
Tag emails from external sources
A simple “EXT” tag added to the subject line of emails from an outside source is a clear flag for users that it’s an external email:
So, even if an attacker registers a similar domain name to the organisation’s and then tries to impersonate an employee or internal group, the end user will be able to quickly identify that it is not from an internal source, and report it.
The tag you choose to use is entirely up to you. “EXT” is just one example. You could prefix the subject with “POTENTIAL PHISHING EMAIL” or “POSSIBLE THREAT”, or whatever your users will most likely react to. “EXT” is nice and short, so with the correct training it should be as effective.
Don’t forget, this will appear on ALL inbound mail from external sources.
This is achieved with transport rules and rule actions.
Our rule now looks like this:
You should test this first before applying globally, but once in place it will give your users more confidence in being able to identify both internal and external email and help thwart phishing emails that purport to be from internal sources.
Unauthenticated emails sent by equipment and software on your network will be classified as external email and will also have their subjects prefixed with EXT. To prevent messages from those services and devices being classified as EXT you need to configure those services and devices to send their messages authenticated. In most cases this is straightforward, but you may experience issues configuring some Linux software.
Examples of services and devices to consider are:
- Routers / Firewalls / Unified threat management
- Network Monitoring software
- Backup software
Mail flow / transport rules:
Transport rule actions:
Office 365 rules (change outbound to inbound):
Test a mail flow rule: