![[Screenshot 2025-06-04 134949.png]] Playbook - Alarms escalated from Tier1 to Tier2 should be caused by a truly harmful event, but escalated alarms by Tier1 analysts are not always True Positive due to technical inadequacy, faulty/incomplete analysis, and authorization problems. Before initiating Incident Response processes, please verify that the alarm from the Tier1 analyst was caused by malicious activity. - Reconnaissance is an important phase of an attack where the attacker gathers information about the target system and network. This playbook aims to identify potential reconnaissance activity. - Identify the relevant log sources to be analyzed for the discovery activity (e.g. frewall, proxy, event, sysmon, etc.). Checks can be provided on the 'Log Management' page for related searches. - Firewall - logs show EmailDownloader.exe is allowed through the firewall at 11:22AM, with a destination address 136.243.108.14![[Screenshot 2025-06-04 141434.png]] - Proxy - Event Log - At 11:17AM, a request from source address 173.209.51.54 are sent to port 3389, indicating an RDP request. event log shows the account login was successful with eventID 4624 following immediately after.![[Screenshot 2025-06-04 141400.png]] - at 11:21am, a proxy is used: 172.16.20.3, to request to download multiple emails from the victim - Sysmon - Look for any unusual or suspicious domain name requests. Check for any unusual or suspicious HTTP requests. Look for any unusual or suspicious DNS requests. Against phishing for information, check email security. You can check Endpoint Security and Email Security for related searches. - Endpoint - Process EmailDownloader.exe run as process 6315 by user 'Arthur', indicating likely account compromise - Email Security - no mail was sent - As a result of the analysis made through Endpoint Security analysis which Reconnaissance technique does the attack match? - Gathering Victim Org Information - The attacker performing the Recon activity can be detected from the logs on IP Log Management. Is the attacker IP internal or external? - External - Perform a reputation check of the attacker IP address. You can use the following resources for this. - VirusTotal - Indicates Egyptian APT data extraction tools - You should fnd which systems are affected. Search on the Endpoint Security, Log Management, and Email Security for IOCs you found during your investigation. Is there more than one affected device? - Email Security and Log Management indicates a phishing campaign originating from 172.16.20.3, with many spoofed or compromised emails from internal addresses, as well as a few external phishing addresses - Therefore, yes, there are many affected devices as part of the campaign, though none have been compromised like Arthurs. However, I'll say the answer is No, because no other device is actively compromised. - Systems exposed to cyber attack should be isolated and the effect of cyber attack should be reduced. Does the device need the be isolated? - Yes - How did the cyber attack happen? - Email phishing campaign to obtain user credentials for remote access - How well did staff and management perform in dealing with the incident? - most staff dealt with the campaign adequately by not falling for the phishing campaign. I was not able to find any logs relating to Arthur in the email security logs, leaving how his account was compromised unknown. - What would the staff and management do differently the next time a similar incident occurs? - data exfiltration flags should be blocked, not just flagged - What corrective actions can prevent similar incidents in the future? - only certain users should be allowed to connect via RDP - blacklist malicious IPs - add malicious file hash to internal malware database - What precursors or indicators should be watched for in the future to detect similar incidents? - RDP requests should be flagged for unauthorized users Artifacts: File Hash: cd2ba296828660ecd07a36e8931b851dda0802069ed926b3161745aae9aa6daa![[Screenshot 2025-06-04 143954.png]] Malicious IP1: 173.209.51.54 Malicious IP2: 136.243.108.14 Compromised Internal IP: 172.16.20.3 Summary: The attack likely leveraged phishing to compromise a user account, enabling unauthorized RDP access and email downloads. External IPs linked to APT tools suggest a targeted campaign. Gaps in email log analysis left Arthur's compromise unexplained to me. Immediate isolation IP blocking are critical to prevent further damage. Add APT Hash to malware database TRUE POSITIVE Like I figured, I missed the recon that the malicious actor used to initially compromise Arthur's account. HOWEVER: The [official writeup](https://medium.com/@wilaco/soc250-apt35-hyperscrape-data-exfiltration-tool-detected-2e7ce7679a56) for this exercise 'deduce's' that the initial point of attack was a phishing email, like I mentioned. LetsDefend's email logs as well as other sources do not confirm this, leaving nowhere for me to drop that in my artifact gathering phase. LD once again pisses me off.