How they swindle $100,000 without blinking an eye – Forensic Analysis of a BEC (Business Email Compromise) (IV)

See the first part of this series, with some notes on the full series content, the second part and the third part

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.

MORE

How they swindle $100K without blinking an eye – Forensic Analysis of a BEC (Business Email Compromise) (III)

See the first part of this series, with some notes on the full series content, and the second part.

In the previous article we verified that a series of emails had been sent from the MINAF CEO’s account to the CFO, and through social engineering a series of unauthorized transfers had been made. We are at a point in the investigation where we want to know more about those emails, and for this we have to go to the low-level database of Exchange: EventHistoryDB.

EventHistoryDB is a database that collects with minute detail the entire life cycle of an email in Exchange. Thanks to EventHistoryDB we can know such granular details as:

  • When an email was written.
  • When it was sent.
  • Whether or not it was read by the recipient, and when.
  • If the mail was moved to a folder.
  • If the email was answered.
  • If the mail was sent to the trash, or even if it was deleted from it.

Unfortunately, not everything is perfect in the EventHistoryDB. It is only accessible via Powershell (no nice graphical interfaces), and only the last 7 days are saved by default. However, in this case the MINAF has reacted very quickly and this has allowed us to enter comfortably within that time frame, so it is possible to fully recover the records for the two affected users.

[Read more…]

How they swindle $100K without blinking an eye – Forensic Analysis of a BEC (Business Email Compromise) (II)

See the first part of this series, with some notes on the full series content.

We left the previous article with many gaps in the mail coverage from both the CEO and CFO of the MINAF. A first (and above all) quick solution is to use the MessageTracking logs. As we have already mentioned, MessageTracking is a high-level Exchange log that provides us with some basic data about the message (origin, destination, date and subject) along with some low-level identifiers (of which we will tell something in due course since they will be fundamental in our investigation).

To give you an idea, this is what a MessageTracking log (that we have minimally adapted) looks like:

If we open the log and take a quick look at it, we find a wave of messages (about 1000) quite worrisome:

(Remote data device deletion confirmation / abelardo.alcazar@minaf.es)

Apparently someone ordered the remote deletion of Abelardo Alcázar’s mobile device, something that can be done from Exchange if the terminal is configured correctly (very useful in case of theft or loss, since we do not require a remote management solution for mobile terminals or MDM).

This log agrees with Abelardo Alcazar’s statement, coinciding with the dates (remember that in Spain in summer we are at UTC + 2, so 18.47h UTC becomes 20.47h Spanish time).

[Read more…]

How they swindle $100K without blinking an eye – Forensic Analysis of a BEC (Business Email Compromise) (I)

Note 0: This series of articles is a description (hopefully entertaining) of the case study (fictional, beware) that Maite Moreno and myself presented at the c1b3rwall digital security and cyber-intelligence conference, organized by the Spanish National Police. If you want more information on CEO scams you can check the (in Spanish) slides of our talk,full of data as well as a real case that we researched.

Note 1: We emphasize that this case is fictitious. However, the techniques and procedures used are identical to those used by the attackers, with the difference that we offer evidence to study them in detail. Note that he investigation could have been done more efficiently, but we wanted to show some interesting elements and techniques to deep into Exchange, hence the steps taken.

Note 2: Before starting the case study… you can play it! We have set up an open-access forensic CTF you can use to practice your technical skills. Try it before reading these articles (recommended), or later to reinforce concepts. If you only want the raw evidence, you can get them here. You can also download the step-by-step guide with all the tools and evidence needed for each step of the articles, perfecto to continue with the slides.


Those of us who work in incident response and forensics would love want attackers to warn us before doing their wrongdoing. We want it together with the Lamborghini, the yacht and the unicorn with a rainbow in the background, but we get the same response in almost all cases: no f****** way.

What a pain in the ass it is to have an incident at 14:55 on a Friday,” you would think. There are worse things: a call from your boss at 15h on a Saturday while you are taking a nap: “Grab your incident suitcase, ‘we’re going to party’».

The party consists of about 4 hours of travel from Madrid to Ponferrada, where the headquarters of the MINAF (Minerías Alcázar y Ferrán) is located. MINAF is a mining company that will not ring a bell, but which has a turnover of more than 40 million euros and operates in 12 countries.

[Read more…]

I discovered a crime … and now what?

[Author’s note: The author of this article is a technician, not a lawyer. Although several jurists have been consulted to corroborate that no legal barbarity has been said, it is strongly recommended to consult with a trusted legal professional if necessary].
[Author’s note 2: I would like to thank the ideas and comments offered by the Forensic Computing Telegram group: https://t.me/forense, whose activity has fostered and promoted this article].

Let’s imagine that Mary is a forensic analyst who is working on a case of corporate espionage. While analyzing some compressed files with strange names, she discovers with horror that they are full of images of child pornography.

Imagine that Pete is a pentester whose objective is to take control of a mail server, having to submit as evidence a half dozen high-level emails. Once he has achieved his objective, he extracts several mails at random from the mail accounts, but verifies with indignation that they contain information about a civil servant being bribed for the granting of an important public contract.

Both Mary and Pete have signed a strict confidentiality agreement with the company in which they work, which clearly states that “all the information they have knowledge of during their working activity must be kept in the strictest secrecy.” [Read more…]

Exchange forensics: The mysterious case of ghost mail (IV)

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:
[Read more…]

Exchange forensics: The mysterious case of ghost mail (III)

Articles in the series “Exchange forensics: The mysterious case of ghost mail”: [1] [2] [3]

[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]

After a sleepless night (tossing and turning, brooding on the incident and trying to understand what may have happened, what we may have overlooked, what we still need to try), we return loaded with caffeine to the Organization.

Autopsy has finished the processing of the hard disk image, but after a superficial analysis of the results our initial theory is confirmed: the user’s computer is clean. In fact, it is so clean that the malicious email did not even touch that computer. Therefore, it is confirmed that everything that happened must have happened in the Exchange.

We keep thinking about the incident, and there is something that irks us: if the attackers had complete control of the Exchange, they could have deleted the mail from the Recoverable Items folder, which they didn’t. But what they did manage was to erase it from the EventHistoryDB table, which operates at a lower level … or perhaps they didn’t either.

[Read more…]

Exchange forensics: The mysterious case of ghost mail (II)

(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 )

On the previous article we left off with our views on the mail server of the Organization, a Microsoft Exchange 2010. The first thing we can do is ask Systems to do a message tracking of the email, using a graphical tool (although we can also do it by console) to locate the history of a high level email within Exchange.

First attempt, and the email still does not appear. We repeat the addresses and the Systems technician repeats the search without success. The email must necessarily be there, so we ask him to search again the whole day… and we finally find it, 14 minutes later than when it should have been sent.

Apparently the Organization has not implemented its time synchronization strategy well, and we have a 14 minute drift between the Exchange server and the clients (mental note: insist on the need to deploy an NTP server as soon as possible), but at last we have located the email. The screenshot sent by Systems would be something similar to this one (for confidentiality issues we cannot put any of the originals):

[Read more…]

Case study: “Imminent RATs” (III)

Articles from the series “Case study: “Imminent RATs”: [1] [2] [3]

Note: This is a fictional story; the characters and situations are not real. The only real thing is the technological part, which is based on a mixture of work done, experiences of other colleagues and research carried out.
These articles are part of a basic incident response workshop. Therefore, there are things that could be done more efficiently and elegantly… but the idea was to do them in a simple way so that they were easy to understand. And like any good practical workshop, you can follow it step by step: you can download a Remnux virtual machine with everything you need for the workshop here (for VMWare) or here (.ova format))

Additional analysis

The incident was practically solved in the previous article, but we still have some doubts in the pipeline:

  • What actions did the malware perform on the system?
  • What type of malware is it?

To get out of doubts we execute the document in a specially tuned virtual machine with anti-VM measures, which also has Noriben and Sysmon installed. In addition, we capture the outgoing traffic with WireShark to have as complete a view as possible of what the malware does.
[Read more…]

Case study: “Imminent RATs” (II)

Analysis (follow-up)

In the previous article, we had determined there was “something weird” in the computer, and we had downloaded both, a possibly malicious .doc and a user executable and mailbox. It’s time to get down to work to see what they may contain…

[Note: As a good security practice, malicious files should NEVER be shared without minimal protection. Therefore, you can download both files from here, but they are zipped with the password “infected”. Please, handle them with extreme care, you’ve been warned.]

To start with, we can open the user’s .pst to verify that the infection path is correct, something we can easily do from Windows with the Kernel Outlook PST Viewer:
[Read more…]