Error Message Phishing Attacks- Templates, Examples & Prevention Strategy
If your target is comprised of mostly low-tech staff members then attackers may opt to leverage seemingly legitimate technical data to entice users to follow a link or open a file. As with most targeted phishing attacks, the ruse that the attacker elects to use depends on the amount of publicly available information the attacker can gather. A favorite subject attackers like to profile is technical information related to the target organization’s personnel, security stack or email delivery system. The reason for this is two-fold:
- The attacker wants to identify any technical staff to make sure they are not included in the target list. Incorrect technical data in the phishing message will most likely raise a red flag if received by users of the technical community.
- Even if targeting non-technical staff, the attacker still wants to know the technology in the organization for multiple reasons, including spoofing it.
Since most organizations need to communicate with the internet in some form, the provides individuals with nefarious intentions a way of gather simple, yet valuable technical information that can be used in a social-engineering attack.
The image below shows how an attacker can perform a simple DNS query to gather DNS and SMTP information.
The idea of this attack is to use legitimate information to inundate the recipient with seemingly legitimate error messages along with a simple remediation recommendation. The attacker hopes that the victim would rather follow the provided instructions instead of opening a ticket with the company’s help desk. Of course the remediation procedures provided are in reality instructions for the recipient to infect himself or herself, but the attacker is betting that the user will not question anything as long as the error messages cease.
The image below is an example of the type of message an attacker would generate.
This particular technique requires sending repeated messages, spaced out over a period of time. By sending the message in pre-defined intervals aids in making the message appear to be an authentic system-generated message.
The image below shows an example of how the user’s inbox may look during this type of campaign.
In the example above, the attacker has leveraged the available DNS information and created a ruse stating the user’s mailbox is out of sync. The attacker has provided a simple resolution, which is to click a link in order to sync their resources. Of course this link will offer up some sort of malicious payload but like stated earlier, the attacker hopes that the user will find it more efficient to click the link instead of opening a ticket while their inbox continues to fill up. A lot of times the attacker is right.
Organizations are hard pressed to expect low-tech staff to be suspicious of these types of attacks. In a perfect world, the user community would be suspicious of everything, but this is not a perfect world. User awareness helps, it really does, but in cases like this you have to assume that awareness training is moot. Furthermore, most likely your organizations DNS information is publicly available, so there is really nothing that can be done to sanitize it. So being that you can assume that attackers are armed with legitimate network information, and the users are more than likely vulnerable to this attack, the remaining compensating controls will have to be preventive controls. Detective controls are nice but usually once a system has been compromised, the attacker has pivoted through the network and the damage is done.
As always – the strictest web proxy filtering rules will prevent many of these attacks. If possible, your web proxy should be configured by policy to only communicate to categorized domains. Furthermore, domains that have been registered in the last 30 to 90 should also be blocked, as this is usually indicative of a phisher registering a categorized domain that has recently expired.
The best preventive measure, albeit highly aggressive, is to explicitly whitelist allowed domains for both web access and SMTP negotiation. This is an extremely intensive undertaking, but it is also a solid method of protecting your organization from phishing and web-based attacks.