Day 19 in the Advent of Cyber 3 (2021). McSkidy has received multiple reports of phishing attempts from various elves in the Best Festival Company. Is the Grinch Enterprises up to their shenanigans once again?
WARNING: Spoilers and challenge-answers are provided in the following writeup.
Official walk-through video is as well available at TryHackMe: Advent of Cyber Day #19 - Task 24 Phishing Walkthrough!.
Day 19 - Something Phishy Is Going On
One of the most beloved methods by adversaries to gain initial access/foothold, is through inattentive users and employee's. This is often done via emails, where phishing attempts is carried out.
A phishing mail, is a mail that is constructed in a way to deceive the user to think that it is legitimate and then click a link to a specially crafted malicious website, or to open a malicious attachment.
The MITRE ATT@CK Framework is a tool defining the different tactics, techniques and procedures adversaries use - we as blue teamers can then use this framework to have a common ground to talk from. And furthermore, use it to ensure one's defending mechanisms and link ongoing incident responses to the different tactics, techniques and procedures to visualize the attack and perhaps link it to a specific known adversary. The definition of phishing is as follows:
Adversaries may send phishing messages to gain access to victim systems. All forms of phishing are electronically delivered social engineering. Phishing can be targeted, known as spearphishing. In spearphishing, a specific individual, company, or industry will be targeted by the adversary. More generally, adversaries can conduct non-targeted phishing, such as in mass malware spam campaigns.
Adversaries may send victims emails containing malicious attachments or links, typically to execute malicious code on victim systems. Phishing may also be conducted via third-party services, like social media platforms. Phishing may also involve social engineering techniques, such as posing as a trusted source.
See more at https://attack.mitre.org/techniques/T1566/.
The Challenge
Firstly we are going to launch the provided AttackBox and open the Thunderbird Mail-application. Here we are presented with an email.
One of the first steps to perform when analyzing an email for phishing-attempts, is to take a look at the email headers. This is often done by navigating to "Message Source", "Message Headers", "Raw Message" or similar.
In the picture above some of the more interesting headers are marked. Headers can really be anything, as long it follows the format of <header-name>: <header-value>. Headers are defined by the MUA (Mail User Agent - aka Microsoft Outlook, Thunderbird etc.), MTA (Mail Transport Agent - aka Microsoft Exchange, Postfix etc.), MDA (Message Delivery Agent - aka Microsoft Exchange, Dovecot etc.) and what else comes in contact with a mail on its way from the sender to the receiver.
Some of the headers are mandatory, and instructs the mail-exchange-ecosystem where to deliver an email, defines where it comes from and the path it took. Just remember; All headers can be changed. And often different headers in relation to the sender can be used together to try fooling the user, for example. Looking through the Received: headers is also always a good idea, as this can give you an idea of what MTA started the mail, where it was from and what journey it took to be delivered. Many MTA's will on the what - especially the last MTA, add headers informing of SPAM-controls, SPF/DKIM/DMARC checks and more. These are used to determine if the mail is deemed delivery, delivery to the spam-folder for the user, or out-right denied delivery. These headers can be used for the analyzing.
The first three questions in todays challenge, can be answered by just looking at the headers - see the markings. In the header To: we know for sure, what mailbox this mail was intended for. In From: we are informed by the sender who they are. Especially in phishing, this header is often used to fool the user. Furthermore, we see a header Reply-To: - if a user is responding to the email, if will no be sent to the displayed mail in From: but rather to the mail listed here.
For the next question about a misspelled word in the mail - we can take a look at the first picture where we have the decoded mail at hand. Often phishing mails are not very well formulated, and have spelling- and grammar mistakes. A single, or a few, errors is not critical - we all make mistakes. But it adds up in an investigation, and with other clues the evidence of a phishing mail raises quickly.
Okay, we are then asked for the link-address in the mail.
When analyzing emails (and receiving in general) always be careful with links. As shown in the picture above, if you hover the mouse over a button, a hyperlink or similar, you can see the URL that the link will go to. Here it seems very odd and suspicious - why would "TBFC" be sending reset-password mails with button-links to a domain not their own?
We have the answer for the question. In a real-life analysis I often take an observable/artifact like that, and use it for a deeper investigation. What is the IP of that domain? Is the domain flagged for malicious or nefarious activities? Is it known at virustotal.com? Does sites like https://urlscan.io/ provide us with more intelligence into what the domain/url does? And the most interesting - sandboxing. We could try the link inside a sandbox environment where we can track everything happening, see what vulnerabilities it tries to leverage, see if the site is mimicking a Microsoft Login-page for credentials stealing or similar. There are many tools like this - one of the more popular ones is https://any.run/.
So, for the next answer we hare looking at the mail headers again. The very last header seems very odd and is indeed out answer. See previous picture with mail headers.
We are now informed that on the AttackBox' Desktop, in the directory Email Artifacts are an attachment another colleague reported.
The attachment just seems like a large blob of ASCII text, and it is. When attachments are sent with mails, they are encoded in base64 and embedded inside the mailbody for the receiver MUA to extract again and show correctly for the user. Here we have to do that our self.
The first line starting with --000 is an identifier that defines where the specific file attechment starts and stops. Then we have file-headers defining the type of attachment, its name, what transfer-encoding has been used etc. After that a single blank newline defines where the encided file blob starts.
For us to start investigating the file, we extract the encoded file blob to its own file called attachment_base64. Then we are going to use the following bash-code to decode the file and save it as the original attachment.
cat attachment_base64 | base64 -d > password-reset-instructions.pdfAnd with that, we have a readable pdf-file with the flag for answer. Remember that, when investigating email-attachments (and also in general when receiving attachments) with phishing-mails there is a high change that the file is stuffed with malicious and nefarious code just waiting to be opened, use an unpatched vulnerability and either deploy ransomware, botnet-enroling, RAT's, coinminers and more.
