Cyber-attacks often start with mail phishing

Ransom

Last year's Clop ransomware attack on the University of Maastricht involved a combination of bulk-mailed phishing messages and the exploitation of a server vulnerability that had been known about for three years. The hackers encrypted files on 267 Windows servers (out of the university's 1647-server park), thus preventing access. Some of the university's backup systems were amongst those affected. A ransom of €200,000 was ultimately paid to get the decryption key from the hackers, but the overall cost of the incident will have been much higher. An investigation report by the Inspectorate of Education concluded that, while the university hadn't been negligent, its IT department could have done better. Fox-IT's technical report describes how everything began two months earlier when two simple (generic) phishing mails were opened. The readers proceeded to click a link to an online Excel file that included a malicious macro. That macro then fetched the first real malware from an internet server and ran it. From there, the trouble snowballed.

Modus operand

Fox-IT says that TA505, the group behind the heist, specialises in targeting Windows systems. And their modus operandi is based on the use of phishing to gain initial access. In the last year alone, TA505 has claimed more than 150 victims. The main way of countering phishing threats recommended by Fox-IT is end user training. According to the university's commentary on the Fox-IT report, some incoming phishing messages are caught by a spam filter, and the university's IT helpdesk regularly gives advice to people who receive those malicious messages that do get through. However, the Inspectorate of Education says that not enough was being done to follow up reports to the helpdesk from phishing mail recipients: "On 15 October 2019, a phishing mail was opened. Fox-IT established that, as a consequence of inadequate detection, monitoring and follow-up, hackers were able to launch a ransomware attack on part of the UM network on 23 December 2019." The university has since indicated that phishing awareness campaigns will be organised and that the processes for reporting and dealing with suspect mail will be improved.

"Not enough is being done in the Netherlands"

E-mail was also identified as the principal attack vector in the most recent State of Email Security Report by Mimecast (now owner of the DMARC Analyzer). A survey of more than a thousand IT managers revealed that people in Dutch organisations tend to be much less alert to (mail) spoofing attacks than their counterparts elsewhere. What's more, the increase in working from home driven by the coronavirus pandemic has complicated the task of safeguarding IT infrastructures. The new periphery is much more diffuse than what went before, and has been created and opened in considerable haste. Like Fox-IT, Mimecast emphasises the importance of training. End-user awareness is vital in terms of promoting the identification of (spear) phishing messages and preventing use of malicious links. Mimecast goes on to warn that not enough is done in the Netherlands to fight mail spoofing. Just 13 per cent of Dutch participants in the State of Email Security survey said that their organisations used DMARC -- far fewer than in any other national respondent group. The global average was 23 per cent. "DMARC is a powerful tool that not only protects the organisation itself against digital fraud, but also nips many phishing attacks on individual citizens in the bud," says Dirk Jan Koekkoek, DMARC Vice President at Mimecast.

Risk factors

Interestingly, Mimecast flags up security flaws in Microsoft 365 and the delivery of mail that should be filtered out as additional risk factors. Another issue is that, whenever Microsoft's mail service is down, users switch to their private e-mail accounts for work, thus introducing further hazards. Judging by The State of Email Security, Microsoft mail outages are by no means uncommon: nearly 60 per cent of surveyed IT managers reported experiencing problems with the cloud-based service. That's worrying, given that Microsoft handles the mail for nearly 10 per cent of domains, making it the second biggest mail service provider, after Google. Echoes of that tableau can be found in the Inspectorate of Education's report: amongst users who kept data in private Dropbox accounts, the Maastricht attack served to reinforce the belief that storing material outside the university network was a good idea, even though it was against university policy.

Mail testing on internet.nl

Notably, the University of Maastricht's primary domain, maastrichtuniversity.nl, continues to score badly in the mail test on the internet.nl portal: just 67 per cent. The domain doesn't support DNSSEC, DKIM or DANE, its SPF is open, and it merely has a placeholder for a DMARC policy.

DMARC (and the supporting SPF and DKIM standards) are vital security technologies for protecting mail domains. Authentication of outgoing messages, senders (mail addresses) and sending hosts (mail systems) are their primary function. However, DMARC validation has the added benefit of enhancing spam filtering processes by facilitating the identification of (spear) phishing mail, particularly where domain spoofing is involved.

Hacking and the pandemic

"Since spring 2019, the University of Maastricht has been using SPF, DKIM and DMARC for three of its mail domains, via SURFmailfilter," explains CISO Bart van den Heuvel. "That has greatly improved the acceptance of mail from our domains by big players such as Google. It also enables us to compile information from DMARC reports." "In 2019, the university also allocated funds for the creation of a Security Operations Centre (SOC). Work on setting up the centre started as planned on 1 January this year, but by that time the ransomware crisis had already hit. Further investigation of SPF/DKIM/DMARC and DNSSEC/DANE was already on the agenda for the spring as well. In the meantime, however, we've had first the fallout from the hacking incident to contend with, and then the pandemic. Dealing with those challenges is currently our priority." "In complex organisations, the introduction of SPF/DKIM/DMARC is far from straightforward," adds Van den Heuvel. "It's particularly difficult to accommodate the use of mailing lists and auto-forwarding, both of which are commonplace here." "It's also worth remembering that, while SPF, DKIM and DMARC help to prevent spoofing, they're of limited value against phishing. For example, both the phishing messages that started the crisis and the messages that we later received from the hackers got through SPF/DKIM/DMARC validation without a problem. There's nothing to stop scammers using the technology as well, and they do just that."

False positives and negatives

"It's therefore impossible for the university to identify all phishing mail from the headers," continues Van den Heuvel. "We've got nineteen thousand students, five thousand staff and seventy thousand alumni, who can communicate freely with hundreds of thousands or even millions of other mail addresses about anything and everything. Including 'suspect topics' that are addressed by research projects. That landscape means that whitelisting isn't a viable option for us and that we have to constantly guard against false positives -- blocking legitimate mail." "Another significant point is that it's impossible to identify either of the following:

1. Mail from hacked, borrowed or purchased accounts in legitimate domains

2. Legitimate accounts in criminal or criminal-controlled domains that are set up in a completely proper way; the hackers who hit us, for example, used an anonymous mail service, which is also used by students for private mail"

"Our approach has three elements:

1. Detection of malware content on the basis of message content and attachments

2. Awareness: getting people to report suspect messages to our helpdesk; since the hacking incident, we have of course been receiving far more reports -- a thousand this spring, compared with two hundred in the same period last year

3. Following up reports by filtering, blocking domains and analysing logs; if a really dangerous phishing message is detected, an organisation-wide warning goes out"

"Last year's incident taught us that you can't intercept every single phishing mail. So we're focused on minimising the damage that can potentially arise from an individual user getting duped. That implies restricting the permissions assigned to admin accounts, for example, and placing restrictions on macro use. Another priority is making sure that we have enough logging and monitoring systems to ensure that the suspect activity that follows an initial infection is detected and followed up. We actually detect and re-set hacked accounts quite quickly. After all, we don't want an account linked to one of our domains getting blacklisted for spamming, because that can interfere with important business processes." Van den Heuvel acknowledges that the university's current approach relies heavily of human input. "We're acutely aware of the risk of both false positives and false negatives -- disregarding a phishing report on the grounds that the issue has already been addressed, when in fact the report relates to a subtly different and hazardous issue. The thousand reports we handled this spring included plenty about what proved to be legitimate mail, but our users have become very cautious. Then, while it's easy enough to block some providers, even on an automated basis, there are some that we can't block because they provide legitimate services. That goes for Dropbox and Google domains, for example, whose URLs are changing all the time. Some service providers have to be contacted by mail, others using web forms, and sometimes you even have to use a chat tool. In the period ahead, the SOC will be exploring the scope for automating various procedures, but our work will always have a significant manual component."

Implementing e-mail security

We've got a series of hands-on guides for anyone who wants to press ahead with DNSSEC, SPF, DKIM and DMARC implementation. The guides explain how the various standards work and provide specimen system configurations. On our DNSSEC page you'll find hands-on guides to the implementation of DNSSEC signing and validation in Unbound, Infoblox, PowerDNS and BIND. For the implementation of SPF, DKIM and DMARC, take a look at the following two articles [Postfix, Exim]. Hands-on guides to configuring DANE for Postfix and Exim follow shortly.