Articles in the series “Exchange forensics: The mysterious case of ghost mail”: [1] [2] [3] [4]
[Note: This is a fiction story, the characters and situations are not real, the only real thing is the technical part, which is based on a mixture of work done, experiences of other colleagues and research carried out. with the same technical dose but with less narrative, you can consult the video of the talk that the author gave at the 11th STIC Conference of the CCN-CERT here]
We return to the investigation of the incident by examining what our colleague had found in the OWA logs. If we gather all the information regarding the accesses made from the two IP addresses with the Firefox User-Agent, we find several patterns of interest:
- Pattern 1: Direct access: We can see in the logs how the attackers access the login page, and then they get to the main mail screen.
- Pattern 2: Incorrect access: The cybercriminals access the login page, but the password is incorrect (we observe repeated attempts to log in, as if they were performing a manual brute force attack).
- Pattern 3: Incorrect accesses + correct: In a particular case, we see how the attackers try several times to log in and at the fifth try, they get to access.
This last pattern is the most curious. How have they been able to extract a user’s passwords (which are strong by having 12 characters and forced complexity) in a few attempts?
We ask for the logs of the last few months to the Systems department, and we look for the malicious activity that we have perfectly located thanks to the combination of User-Agent and IP addresses. The analysis of the logs allows us to verify that this behaviour is repeated to the millimeter in the rest of the users:
- From time T, the attackers manage to login to the user’s mail.
- T + n days later (being n <30 days) users lose access (we assume that’s because the system requires changing the password on a monthly basis)…
- On the same day T + n, the attackers make several login attempts, and with less than 20 attempts they manage again to get access the user’s account.
We have a theory of what is happening, but we need to confirm it with an empirical test. We speak to our patient zero again and we kindly ask him to change his password for a completely different one and to provide us with the old one. The answer confirms our suspicions:
JohnNovember2017
Taking this piece of information into account, you don’t need to be a genius to guess the user’s password from last month … or the one for the month we need. And the best thing of all is that this is a password that complies with the policy established in the Windows domain: it has 17 lustrous characters, uppercase and lowercase letters and numbers. And once the attackers have obtained one of these passwords with patterns, they can still access the system until the end of time.
Talking with the other comprimised users, the facts are confirmed: they all used password patterns with a high degree of reutilisation, which made it very easy for the attackers to figure out the new password with a minimum number of tries.
Once all the factors that have produced the incident are understood, we can move on to the recovery phase. First and foremost, it is necessary to estimate the impact suffered by the Organization. From what we have extracted from the analysis of the logs, the attackers had access to four user mailboxes for a period of approximately fifteen days to a month and a half, during which time they had access to all the emails in the mailbox.
On the positive side, the attackers were not able to access the archived emails (which are stored in local .pst files), nor to the emails deleted during working hours (As the attackers acted out-of-hours so as not to arouse suspicion).
The analysis of the computer has not detected any malware, and the analysis of the Exchange seems to indicate that it is clean, so the incident seems to be limited to the accesses to the mailboxes. María recalls that three months ago the Organization suffered a highly targeted phishing attack related to the provision of medical insurance, in which a good number of users may have been compromised. This attack could explain the attainment of credentials by the attackers.
Once the incident is solved, we can move on to the lessons learned, which in this case are the following:
Check the perimeter
It is imperative and a priority to review the perimeter: if the Organization had not had enabled the access of mobile devices through OWA, this incident would not have occurred. It is essential to control all services exposed to the Internet to avoid surprises of this type. We can use tools like nmap or online services like Shodan.
Use 2FA in external accesses
If double authentication (2FA) had been set for all external accesses, the attackers would not have been successful in their attack, since they would only have obtained half of the information necessary to access OWA.
In this case, the access to OWA is done after accessing a VPN (which could be considered as a certain 2FA), but even having closed the “pirated” OWA the attackers could have configured a mobile terminal with the access data and continued to login the email. To mitigate this risk, it is proposed that the corporate terminal itself acts as the 2FA (Exchange allows creating a white list of authorized terminals, which in this case are the corporate terminals), which would deny access to the attackers (and by the way, to the users who configure their mail in non-corporate terminals).
Raise awareness among users
The incident would have had a much smaller impact if the employees had been trained in good security practices: on the one hand, how to detect possible phishing attacks, and on the other how to maintain a proper hygiene of passwords.
Two initiatives are proposed: firstly, to carry out an audit of the strength of passwords (whose results may be discussed in another article), and secondly, to draw up a set of awareness-raising activities to improve the security culture of the employees of the Organization.
Increase log capabilities
We have been quite lucky with this incident, since we have been able to detect its origin very quickly. However, if it had taken us a few more days (imagine that we do not have those YARA rules in CARMEN and the attack is detected when the cybercriminals start to exfiltrate data), finding the entry point would have been much more complicated.
On this occasion, we recommend expanding the capacity of the EventHistoryDB to 3 months, although for reasons of hard disk space we have to settle for just one month. As for the Recoverable Items folders, we request another 3 months, but we accept the commitment solution of one month / 40Gb of space. In both cases, we expanded the scope of detection of attacks without compromising the performance of the service, which in itself is already a victory.
Check the logs
A correct review of the OWA logs could have detected the brute force attack and contributed to significantly reducing the impact of the incident. The recommendation here is to integrate the OWA logs into a log management platform such as GrayLog or Splunk.
In the end, all the pieces of the puzzle fitted, and the incident of the ghost mail was solved with a reasonably small impact for the Organization. We note down the need to improve communication with the rest of the ICT areas (a topic that is always pending in the response to incidents, but which we must work on every day), and we withdraw with the satisfaction of the fulfilled duty … until the next incident.
