In the previous article, we saw how the attackers had been monitoring and manipulating the MINAF CEO’s email at will … and that they had done it through OWA (Outlook Web Access), the Exchange webmail.
To know how these logs work, we have to see how Exchange works. If we simplify it a lot, Exchange has two main components: CAS (Client Access Server) and DAG (Database Availability Group), which would be roughly equivalent to a web server and the database of a web application.
The CAS (which is actually an IIS, Microsoft’s web server), takes care of all interaction with clients, either through a desktop Outlook client, OWA or ActiveSync (the protocol used for mobiles).
CAS logs are always good news: they have no retention period (they are saved by default until the disk allows for it); we have seen computers with 5+ years of CAS logs. The format is quite standard (IIS logs, very well documented), and they are high-level (reasonably easy to interpret).
With that said, let’s get down to business. First of all, we are going to identify an email that we know for sure was sent by the CEO of MINAF. For instance, the one that the CFO sent with his mobile phone on the day of the incident, indicating that the negotiations had been successful. After carefully reviewing the logs, here it is:
This email has some markers that make us think it is authentic:
- ActiveSync is being used (it has been sent by a mobile terminal).
- The User-Agent is Android-Mail / 7.5.7.156101332.release (consistent with Android 8.1, MINAF corporate S9 OS).
- The source IP is 10.11.0.210 (the one offered by the VPN client installed in the corporate terminals of the MINAF).
On the other hand, if we check the first of the malicious emails we can see that the situation is quite different:
If we look carefully we can see the differences:
- Access is being done via OWA instead of ActiveSync.
- The User-Agent is Mozilla/5.0 + (Linux; +Android+7.0; +PLUS+Build/NRD90M) +AppleWebKit/537.36, which after some research turns out to be a Chrome with some extension that allows forging the User-Agent (to fake them as mobile in a quick review).
- The source IP is 101.132.122.100, which a bit of geolocation places in China (possibly a proxy used by attackers to hide their origin).
If we pivot a little on this IP that we have just found, we obtain an interesting number of contacts:
These logs, if we know how to interpret them, tell a story in detail.
At 15:04:12 UTC the attackers log into the OWA with the credentials of the CEO of the MINAF, and are constantly monitoring the mail. We can see how the malicious emails are sent and the email monitoring continues, finishing with the order to delete the remote email when the attackers see that the CFO of the MINAF has detected something wrong.
The attack was carried out like clockwork. But, no matter how good the attackers were, it is impossible that they could put together the attack with so little preparation. Everything indicates that the attackers managed to access the CEO’s account at least several days in advance, so let’s see if we can locate the first contact of the malicious IP.
The result is very interesting:
If we look closely at the logs we can see that none of the accesses have been successful: what we see is a mixture of 401 result codes (Unauthorized) and OWA links with “reason=2” (invalid password).
These failed accesses are repeated several times over several minutes, and if we look at the User-Agent, we can see that it is PowerShell. If we had to bet we would say that it is a brute force or password spraying attack (trying the same password against multiple accounts, so as not to block the accounts after several failed attempts).
The second part of the failed accesses has a different profile:
The time between requests seems more random, less rhythmic (as if there was a person behind the accesses), and the User-Agent in this case is just from a recent version of Chrome. It could be one of the attackers testing passwords manually (we would have to check if there are MINAF email addresses in services such as HaveIBeenPwned or similar).
We keep looking in the logs and our patience is rewarded: on June 6 the attackers manage to log in correctly to the computer:
After that successful login, the attackers read ALL the MINAF CEO’s mail (we assume that doing so allows them to recognize the Istanbul opportunity, the existence of COBALTO, and the CEO’s writing style).
The interesting thing is what happens just before that login. But what do we see in the logs? NOTHING. The attackers’ access has occurred directly, without hesitation or errors. One of the essentials of forensic analysis is “the absence of evidence is also evidence.” We need to investigate what may have happened to move the attackers from brute force access attempts to a clean entry at the first attempt.
The usual suspects in these cases are both mail and browsing, and fortunately we have that data: the export of the mailboxes and the collection of the triage with CyLR.
Let’s start with the email analysis. The truth is that it is a bit of a surprise to discover it now, because this email turns out to be quite obvious:
The attackers sent a spear-phishing message to the CEO with information of direct interest (his LinkedIn profile indicates that he is passionate about golf, and among the entities he follows is the Madrid Golf Federation).
If we correlate then the email was received with the attackers’ first access (remember that the CAS logs are UTC+0, and the Kernel Outlook PST Viewer logs are those of the system, UTC+2, so we have two hours of difference), it is hardly necessary to review the CyLR navigation logs:
These logs give us the chronicle of a tragedy foretold. About five minutes after receiving the email, Abelardo Alcázar visits the website:
which unfortunately is NOT the website of the Madrid Golf Federation:
… And in less than 10 minutes we have the attackers accessing Abelardo Alcázar’s email. The reason seems fairly straightforward: the reuse of credentials by the CEO, applying the same corporate password on other less important sites.
With all this information we can generate a timeline of events with everything that happened:
- On June 5th, the attackers carried out several brute force attacks against MINAF email accounts.
- On June 6th, they launched a spear-phishing campaign directed at the CEO based on his social preferences.
- Little previous attack surface and directed OSINT by the attackers.
- The CEO falls for the spear-phishing and reuses credentials, giving attackers access to his email account.
- On Jun 7th, they access the account pretending to be an Android and send an email to the CFO, requesting a series of transfers.
- They take advantage of the CEO’s unavailability (in negotiations).
- They make use of previous knowledge -> Reading of the mail by the attackers.
- They delete the fake emails after they are sent so that the CEO does not read them on the mobile terminal.
- They empty the trash when they finish forwarding.
- They monitor the account in search of possible emails.
- They delete the CFO’s response to the CEO.
- They perform a remote deletion to save time.
Clean and almost seamless execution -> Group of professional attackers.
The incident analysis allows you to determine all the necessary points in an incident response:
- Entry point used by attackers (email).
- Attack carried out (targeted spear-phishing).
- Movements made within the system (access to mail).
- Affected computers (actually, none).
- Affected information (user credentials, email).
- Time frame of the incident (June 6-7).
- Attackers’ target (performing a CEO scam).
- Impact caused (loss of € 100k).
If anything positive can be drawn from the incident, it is that MINAF’s information systems are unlikely to be compromised. The time frame of the incident (less than two days) and the actions taken by the attackers (clean and efficient, suggests that this is not the first time they have done it) indicate that they are likely to engage only in this type of attack.
The incident leaves the following lessons learned (although in this case their cost is rather high):
- Use double authentication factor: the use of 2AF (if possible with a physical token like a Yubikey, or an app like Google Authenticator, the SMS should be in disuse) would have prevented the attackers, even having valid credentials, from accessing the MINAF CEO account.
- Save the logs: in this case, MINAF realized it immediately, and several logs very relevant to solving the incident could be recovered. Considering extending the retention period of some logs (such as the “Recoverable Items” from Exchange) is a very interesting idea, always depending on the available resources.
- React quickly: right after the incident is detected, an immediate response is required. Contacting the bank and trying to stop the transfers is the first action to be taken. The second one: look for specialists in response to incidents and/or file a report with the authorities.
- Awareness to your users: users need to understand the importance of cybersecurity, because they are an integral part of it. If the CEO of MINAF had not fallen for the spear-phishing, and above all, if he had not reused credentials, the attack would not have occurred. Cybersecurity is not an IT task: it belongs to the entire organization.
- Control the money: establish strict procedures and controls for any transaction that exceeds a limit. Previous signatures, double authorization, confirmation of the accounts used (and a shielded form for changing current accounts, another very frequent attack used by cybercriminals).
In our case study the money was never recovered (in most cases it is never recovered). After the c1b3rwall talk (where we presented this case) we were talking with several members of the Police who confirmed the frequency of these attacks, and the severity of them. As an example, two cases managed in the last year:
- A company that was a victim, almost step by step what happened in our case study, but this time it was several hundred thousand euros. They were saved in extremis because the bank detected that the amount of the transfer was unusual and decided to wait until the next day to confirm it.
- A company with multiple business relationships with China: this company handles frequent invoicing with China. The attackers broke into the mailbox of the Chinese company and requested a change of bank account at both ends, swindling both parties for almost two months (with a total amount of several tens of thousands of euros).
This type of attack is very common, and is widely used by cybercriminals due to its low cost and exposure (the money transferred to these accounts is quickly redistributed through bank scams, making it very complicated or directly impossible to track), and above all for its high profit.
The solution is to increase the organization’s security posture (or as the CCN-CERT rightly preaches, “work as if you were compromised”). With so many cybercriminals eager to get into your wallet, it is the only possible alternative…
