In this post, I’ll walk you through how to resolve the SOC141 — Phishing URL Detected event, which is the first event in the Phishing Email Analysis course on LetsDefend. 🛡️

This guide isn’t just about solving a single event; it’s about understanding the best practices for handling similar incidents effectively. Whether you’re a beginner looking to sharpen your skills or an experienced analyst aiming to refine your approach, you’ll find actionable insights here. Let’s dive in! 💡

Step 1: Accept the Event as a Case and Analyze Its Content

The first step in resolving this event is to locate it in the Monitoring section of LetsDefend, accept it as a case, and thoroughly analyze its details. Let’s break down the provided event data:

• Event ID: 86
  🆔 This unique identifier is used to track the event within the system.
• Event Time: Mar 22, 2021, 09:23 PM
  ⏰ Indicates when the event was logged, useful for timeline analysis.
• Rule: SOC141 - Phishing URL Detected
  🚩 The alert was triggered by a phishing URL detection rule, a common indicator of malicious activity.
• Level: Security Analyst
  🛡️ This highlights the role responsible for analyzing and resolving the case.

Key Indicators to Investigate

1. Source Information

• Source Address: 172.16.17.49
  🌐 This is the internal IP address of the device where the suspicious request originated.
• Source Hostname: EmilyComp
  💻 The hostname of the device, potentially belonging to a user named Emily.

2. Destination Information

• Destination Address: 91.189.114.8
  🌍 The external IP address of the destination, is suspected of hosting malicious content.
• Destination Hostname: mogagrocol[.]ru
  🛑 The domain associated with the destination IP, seems suspicious due to its structure and lack of trust signals.

3. Request Details

• Request URL:
  http://mogagrocol[.]ru/wp-content/plugins/akismet/fv/index.php?email=ellie@letsdefend[.]io
  📧 The URL includes a plugin path and email parameter, often used in phishing campaigns to harvest credentials.
• User Agent:
  Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36
  🖥️ The browser and OS used, potentially from an employee’s system.

4. Device Action

• Allowed
  ✅ The action indicates the request was not blocked, increasing the urgency to assess potential compromise.

Conclusion

This event contains multiple red flags, particularly the suspicious domain (mogagrocol[.]ru) and the phishing URL structure. 🕵️‍♂️ The next step will involve confirming the legitimacy of the destination and determining the intent behind the activity. Let’s proceed with the investigation! 🔍

Step 2: Investigate the Destination Hostname in Log Management

Now, it’s time to dive deeper into the destination hostname mogagrocol[.]ru by reviewing the logs in the Log Management section. This step is crucial to gather more context and confirm if the destination IP and hostname are associated with any suspicious activities. Let’s break down the relevant log information:

Log Details

• Field Type: Proxy
  🔄 Indicates that this log was captured through a proxy, which is a common method for monitoring network traffic.
• Source Address: 172.16.17.49
  🌐 The internal IP address of the device initiating the request (same as in the previous step).
• Source Port: 55662
  🔌 The source port number used in the connection attempt.
• Destination Address: 91.189.114.8
  🌍 The external IP address that was contacted, which is tied to the suspicious domain.
• Destination Port: 80
  🌐 This port indicates HTTP traffic, commonly used for web browsing and also exploited in phishing attacks.
• Time: Mar 22, 2021, 09:23 PM
  ⏰ The exact timestamp when this request was logged, which aligns with the event time.

Raw Log

• Request URL:
  http://mogagrocol[.]ru/wp-content/plugins/akismet/fv/index.php?email=ellie@letsdefend[.]io
  📧 The same URL seen earlier, still pointing to a suspicious path. The email parameter could indicate an attempt to capture sensitive information.

Analysis

By analyzing the log details, we can confirm that the connection to the destination IP address 91.189.114.8 was made over HTTP (port 80), which raises concerns. The URL path (wp-content/plugins/akismet/fv/index.php) is highly unusual, especially since Akismet is a legitimate anti-spam plugin, but here it’s being misused in a phishing attempt.

Conclusion

The log data supports the hypothesis that the destination is suspicious, and it’s critical to further investigate the reputation of the domain mogagrocol[.]ru and the involved IP address. In the next steps, we will explore the domain’s history and reputation. 🕵️‍♂️

Step 3: Investigate on VirusTotal

At this stage, it’s crucial to dig deeper into the suspicious domain, IP address, and URL to assess their reputation and check for any known malicious activity. We’ll use VirusTotal and AbuseIPDB to gather more data on the following items:

• Domain: mogagrocol[.]ru
• IP Address: 91.189.114.8
• URL: http://mogagrocol[.]ru/wp-content/plugins/akismet/fv/index.php

VirusTotal

🔍 VirusTotal is an online service that aggregates results from multiple antivirus engines and tools to analyze files, URLs, domains, and IP addresses. Let’s break down what we will look for:

1. Domain Analysis
By submitting mogagrocol[.]ru to VirusTotal, we will check if it has been flagged by multiple security vendors as suspicious or malicious. Look for any alerts regarding phishing, malware hosting, or other malicious activities.

• Flagged for Phishing 🚨
• Associated with CRDF ⚠️
• Marked as Malicious 💀

2. IP Address Analysis
Similarly, submitting 91.189.114.8 will give us insight into whether the IP has been previously associated with any known cyberattacks, such as phishing campaigns or malware distribution.

• Reported for MalwareURL 🦠
• Marked as Malware 💀
• Associated with Abusix 🚨
• Listed as Clean ✅ (on some platforms)

This means that while the IP has been flagged for malicious activity and hosting malware, some sources report it as clean, so further investigation is needed to confirm its true nature.

3. URL Analysis
Submitting the exact URL path (http://mogagrocol[.]ru/wp-content/plugins/akismet/fv/index.php) will provide us with a detailed report on its safety. VirusTotal will scan it for any harmful scripts, suspicious payloads, or associations with phishing campaigns.

• Flagged for Phishing by BitDefender, Fortinet, G-Data, Kaspersky, Lionic, Sophos 🕵️‍♂️
• Associated with CRDF ⚠️
• Marked as Malicious by BitDefender, CyRadar 💀
• Trustwave flagged it as Suspicious ⚠️
• Abusix lists it as Clean ✅

This confirms that the URL is widely recognized as a phishing attempt by multiple security vendors, making it a high-risk indicator for malicious activity.

Conclusion

By examining the results from VirusTotal, we can gather critical evidence to determine whether the domain, IP, and URL are indeed malicious. If these sources confirm any suspicious or malicious activities, we can proceed with more advanced containment measures. 🚨

Step 4: Investigate the URL in LetsDefend Linux Sandbox

Now, we’ll analyze the suspicious URL (http://mogagrocol[.]ru/wp-content/plugins/akismet/fv/index.php) in the LetsDefend Linux Sandbox using Mozilla. Here’s what we can expect:

1. Open the URL in the Sandbox:
Open the URL in the Linux sandboxed environment using the Mozilla browser to safely interact with the site without risking any system compromise.

2. Response:
Upon accessing the URL, you’ll likely encounter a 403 Forbidden error in Russian. 🚫 This indicates that access to the page is restricted, either due to location-based filtering or because the page is set to block specific users or requests. The error message in Russian is typically displayed as:

• Ошибка 403 (Error 403) — Forbidden

3. Analysis:

• Why 403?: This could be a common tactic used by attackers to limit access to certain regions or specific IPs. It may also be used to prevent sandbox tools or security researchers from analyzing the page directly.
• Context: A 403 error is not necessarily an indication that the URL is safe, but rather that the attackers are restricting access to only specific users or systems.

Conclusion

The 403 error confirms that the page is actively restricting access, which is a typical tactic for malicious sites trying to avoid detection. While we can’t fully interact with the page, this strengthens our suspicion that it’s part of a phishing campaign.

Step 5: Analyze Email Security and Investigate Phishing Messages 📧🔍

Now it’s time to dive into the Email Security section to see if any phishing-related messages have been delivered to Emily. During the investigation, we found a key clue that confirms the phishing attempt:

• Email Analysis: Emily received an email that appeared to be from Fake Netflix. Upon further inspection, it was clear that the email was a phishing attempt. 🚨
• Phishing Link: The email contained a suspicious link, which was likely designed to harvest sensitive information like login credentials or personal data. 🔗

Why is this important?

• Phishing emails often serve as the first entry point for attackers, leading victims to click on malicious URLs or download harmful attachments. In this case, Emily’s inbox contained such an email, which could potentially explain why she was directed to the suspicious website (mogagrocol[.]ru).
• Investigating phishing emails is crucial in identifying the initial attack vector and preventing further compromises. 🛡️

Conclusion

The presence of a phishing email in Emily’s inbox strengthens the case that the suspicious URL and IP address are indeed part of a larger, coordinated phishing attempt. We must now continue to track any network activities related to this threat.

Step 6: Investigate Endpoint Security for Network and Terminal Activities 💻🔎

Next, we dive into Endpoint Security to track the activities of the device in question (Emily’s machine). Our goal here is to check if Emily interacted with the malicious URL and if any suspicious processes were executed. Here’s what we discovered:

1. Network Activity 🌐

• Interaction with the Malicious Link: By reviewing the network activity logs, we confirmed that Emily’s machine interacted with the malicious link found earlier. This indicates that the device successfully communicated with the suspicious mogagrocol[.]ru domain. 🚨
• This step is crucial because it helps us confirm that the phishing link was indeed accessed, increasing the likelihood that the system is compromised.

2. Terminal History 💻

• KBDYAK.exe Execution: Moving on to the terminal history, we uncovered a disturbing finding: the malicious file KBDYAK.exe was executed on Emily’s machine. ⚠️
• KBDYAK.exe is known to be a keylogger, often associated with malware campaigns targeting user credentials. The execution of this file indicates that the attack might not only be stealing sensitive data but could also have given the attacker full control over Emily’s machine.

Why is this important?

• The network activity confirms that the phishing link was accessed, potentially compromising sensitive data.
• The presence of KBDYAK.exe raises the stakes significantly, as it suggests that the attacker might be trying to record keystrokes, which could include usernames, passwords, or other sensitive information. 🕵️‍♂️

Conclusion

These findings are alarming, and they highlight the serious nature of this incident. At this point, the device has likely been compromised and we need to proceed with containment to prevent further damage. 🚨

Final Step: Host Containment and Closing the Case 🛑🔒

After thoroughly investigating the phishing URL and all related activities, it’s time to take action to contain the compromised host and close the case. Here’s how we proceeded:

1. Host Containment 🛡️

• Based on the findings from the Email Security, Network Activity, and Terminal History analyses, it became clear that Emily’s device had been compromised. The next logical step was to initiate host containment to isolate the device and prevent the attacker from executing further actions.
• In the Endpoint Security page on LetsDefend, I located EmilyComp (the compromised host) and initiated the Containment action. This step ensures that Emily’s device is isolated from the network, blocking any further malicious communication or activity. 🚫

2. Closing the Case ✅

With the containment in place, the case could now be closed. As a True Positive, the investigation confirmed that this was indeed a real phishing attack. The IOCs (Indicators of Compromise) we identified throughout the process gave us strong evidence to classify this as a legitimate threat.

IOCs we encountered:

• Malicious URL: http[://]mogagrocol[.]ru/wp-content/plugins/akismet/fv/index.php
• Malicious IP address: 91[.]189[.]114[.]8
• Suspicious email with a phishing link targeting Emily’s Netflix account.
• Suspicious execution of KBDYAK.exe, a known keylogger, on Emily’s machine.
• This comprehensive analysis allows us to confidently mark the case as a True Positive, which is a real attack with clear malicious indicators. 🔐

Conclusion

By following a systematic approach, we were able to confirm that this was a phishing attack targeting Emily’s system. The combination of the suspicious URL, email, network activity, and malware execution led us to take the necessary containment actions to secure the environment. With the case closed, we can be confident that the threat was mitigated. 🛡️🚨

Thank you for reading! I hope these steps have been helpful in understanding how to effectively respond to phishing attacks. 🔐💡

For more updates and to follow my journey, connect with me on:

• LinkedIn: bbetulkaya💼
• GitHub: bbetulkaya 💻