Introduction

In this lab, I analyzed a compromised Windows memory image from the BlackEnergy challenge on the CyberDefenders platform.
The goal was to investigate suspicious processes, identify possible code injection activity, and detect hidden DLLs using Volatility.

The investigation focused on:

• Identifying the correct memory profile
• Enumerating running processes
• Detecting suspicious behavior
• Investigating injected code and hidden modules
• Extracting malicious artifacts from memory

Reference writeup used as inspiration:

Scenario

A company detected suspicious activity on one of its systems after a cyber attack involving a BlackEnergy malware variant.
A memory dump was acquired from the infected host, and the task was to perform memory forensics analysis to determine what happened on the machine.

Tools Used

• Volatility Framework
• strings
• VirusTotal

Q1 — Which volatility profile fits the memory image?

The first thing I needed to know was the operating system version and architecture of the memory image.
To do that, I used the imageinfo plugin because it provides suggested profiles and basic system information such as:

• OS version
• Service Pack
• Architecture
• Time of acquisition

Command used:

vol.py -f CYBERDEF-567078-20230213-171333.raw imageinfo

After reviewing the output, Volatility suggested the following profile:

WinXPSP2x86

This profile matches:

• Windows XP
• Service Pack 2
• 32-bit architecture

Answer

WinXPSP2x86

Q2 — How many processes were running when the image was acquired?

To enumerate running processes, I used the pslist plugin.
This plugin displays active processes directly from memory, including:

• Process name
• PID
• Parent PID
• Number of threads
• Creation time

Command used:

vol.py -f CYBERDEF-567078-20230213-171333.raw --profile=WinXPSP2x86 pslist

I manually counted all running processes displayed in the output.

The total number of active processes was:

19

Answer

19

Q3 — What is the process ID of cmd.exe?

Instead of manually searching through the entire process list, I filtered the output using grep to quickly locate the cmd.exe process.

Command used:

vol.py -f CYBERDEF-567078-20230213-171333.raw --profile=WinXPSP2x86 pslist | grep cmd.exe

The output showed the PID associated with cmd.exe.

Answer

1960

Q4 — What is the name of the most suspicious process?

I returned again to the pslist output and started reviewing the running processes manually.

While checking the process names, one process immediately looked suspicious:

rootkit.exe

This process name clearly stands out because legitimate Windows systems normally do not run a process called rootkit.exe.

The name itself strongly suggests malicious behavior or malware activity.

Answer

rootkit.exe

Q5 — Which process shows the highest likelihood of code injection?

To investigate possible code injection, I used the malfind plugin.

The malfind plugin searches memory for:

• Hidden executable memory regions
• Injected shellcode
• Suspicious memory protections
• Malware injections

Command used:

vol.py -f CYBERDEF-567078-20230213-171333.raw --profile=WinXPSP2x86 malfind

To verify our answer. At first, I dumped this process

After extracting the dump, I checked the file hash and analyzed it using VirusTotal to verify malicious behavior.

The process most likely injected was:
Answer

svchost.exe

Q6 — There is an odd file referenced in the recent process. Provide the full path of that file.

To search for suspicious artifacts inside the dumped memory region, I used the strings utility.

The strings command extracts readable ASCII text from binary files and is very useful for:

• Finding file paths
• Detecting URLs
• Identifying malware artifacts
• Recovering hidden references

Command used:

strings process.0x89aab590.0x980000.dmp

While reviewing the output, I found a suspicious driver path:

C:\WINDOWS\system32\drivers\str.sys

This driver looked abnormal and was likely related to the malicious activity.

Another possible approach for solving this question is using the handles plugin to enumerate open file handles.
Answer

C:\WINDOWS\system32\drivers\str.sys

Q7 — What is the name of the injected DLL file loaded from the recent process?

At first, I used the dlllist plugin to enumerate DLLs loaded inside the suspicious process.

Command used:

vol.py -f CYBERDEF-567078-20230213-171333.raw --profile=WinXPSP2x86 dlllist -p 880

However, the results contained many DLLs, making it difficult to identify the malicious one.

To detect hidden or unlinked DLLs, I used another plugin called ldrmodules.

The ldrmodules plugin compares multiple DLL lists maintained by Windows:

• InLoad
• InInit
• InMem

Malware often unlinks itself from these lists to hide from security tools.
One DLL appeared highly suspicious:

msxml3r.dll

The DLL did not appear correctly in the loader lists, which strongly suggests:

• DLL hiding
• Stealth injection
• Rootkit behavior

Answer

msxml3r.dll

8. What is the base address of the injected dll?

The base address is displayed in the 3rd column of the output of the malfind plugin.

python3 vol.py -f /home/remnux/Documents/BlackEnergy/CYBERDEF-567078-20230213-171333.raw windows.malfind

Answer

0x980000

This lab focused on investigating a suspicious memory dump using Volatility 3.

The analysis started by reviewing running processes and gradually moved into command-line analysis, network connections, and file extraction to identify the malicious activity.

During the investigation, I traced a suspicious executable, analyzed its external communications, extracted the malware from memory, and collected multiple IOC’s related to the attack.

This lab was also a good example of how analysts combine process analysis, network artifacts, and threat intelligence together during real-world investigations.

Q1 — What is the name of the process responsible for the suspicious activity?

The first question wanted us to identify the suspicious process.

So instead of relying on one thing only, we used multiple approaches to make sure which process was actually malicious.

First Method — Reviewing Running Processes

We started by listing all running processes using:

python3 vol.py -f memory.dmp windows.pslist

Then we started reviewing the processes one by one looking for anything unusual.

We found normal processes like:

• svchost.exe
• explorer.exe
• RuntimeBroker.exe

But then we noticed:

ChromeSetup.exe

This looked suspicious because it is unusual for a Chrome installer to be running like this inside memory.

Second Method — Reviewing the Command Line

After that, we wanted to see where this process was executed from.

So we used:

python3 vol.py -f memory.dmp windows.cmdline

And we found:

C:\Users\alex\Downloads\ChromeSetup.exe

This increased our suspicion because the executable was running directly from the Downloads folder.

Third Method — Reviewing Network Connections

Next, we checked whether the process was making external network connections.

We used:

python3 vol.py -f memory.dmp windows.netscan

While reviewing the connections, we noticed that:

ChromeSetup.exe

was communicating with external IP addresses.

At this point, we were almost certain that this was the malicious process.

Final Answer

ChromeSetup.exe

Q2 — What is the exact path of the executable for the malicious process?

After identifying the suspicious process, we wanted to retrieve its full executable path.

We used:

python3 vol.py -f memory.dmp windows.cmdline

Then we reviewed the command lines until we found:

C:\Users\alex\Downloads\ChromeSetup.exe

This confirmed even more that the executable was downloaded recently and was not part of normal system activity.

Final Answer

C:\Users\alex\Downloads\ChromeSetup.exe

Q3 — What IP address did the malware attempt to connect to?

Next, we wanted to identify which external IP the malware was communicating with.

We used:

python3 vol.py -f memory.dmp windows.netscan

Then we reviewed the active network connections until we found that:

ChromeSetup.exe

was communicating with the following IP address:

58.64.204.181

At this point, the behavior became much more suspicious.

Final Answer

58.64.204.181

Q4 — Which city is associated with the IP address the malware communicated with?

After obtaining the IP address, we performed a lookup using:

• AbuseIPDB
• VirusTotal

to identify its geographical location.

The IP address was associated with:

Hong Kong

Final Answer

Hong Kong

Q5 — What is the SHA1 hash of the malware executable?

This was probably the most important part of the lab.

At first, we attempted to dump the running process itself.

However, the SHA1 hash we obtained was incorrect.

This is where an important concept appears:

Process Dump ≠ File Dump

We needed to extract the actual file from memory, not the process memory dump.

First Step — Locate the File Object

We used:

python3 vol.py -f memory.dmp windows.filescan | grep "ChromeSetup"

to locate the file object associated with the malware.

Second Step — Dump the Actual File

Then we used:

python3 vol.py -f memory.dmp windows.dumpfiles --pid 4628

to extract the real executable file from memory.

Final Step — Calculate the SHA1 Hash

Finally, we calculated the SHA1 hash using:

sha1sum *Chrome*

The resulting SHA1 hash was:

280c9d36039f9432433893dee6126d72b9112ad2

Final Answer

280c9d36039f9432433893dee6126d72b9112ad2

Q6 — What is the compilation timestamp for the malware?

After extracting the real executable, we analyzed the file metadata.

We found the compilation timestamp to be:

2019-12-01 08:36

Final Answer

2019-12-01 08:36

Q7 — Identify the domains associated with this malware

While reviewing the network connections and DNS requests, we noticed a repeated domain associated with the malware activity.

The domain was:

dnsnb8.net

This was the domain the malware was communicating with.

Final Answer

dnsnb8.net

In this investigation, I analyzed network traffic from a compromised machine to uncover how the attack was carried out. Using tools like Wireshark and threat intelligence platforms, I traced the attacker’s activity from initial access to payload execution.

The analysis focused on identifying key indicators of compromise (IOCs), including malicious files, attacker-controlled IP addresses, and execution behavior. This lab simulates a real-world SOC scenario where timely detection and accurate analysis are critical to understanding and responding to a breach.

Scenario

The SOC team has detected suspicious activity in the network traffic, revealing that a machine has been compromised. Sensitive company information has been stolen. Your task is to use Network Capture (PCAP) files and Threat Intelligence to investigate the incident and determine how the breach occurred.

Q1: Which IP address was used by the attacker during the initial access?

The question indicates that a malicious file was used to gain initial access.
When analyzing the PCAP, there are two possible scenarios to consider:

1. Malicious File Uploaded (POST Request)
   The attacker may have exploited a vulnerability to upload the malicious file.
   In this case, we would expect to see an HTTP POST request indicating the file upload.
2. Malicious File Accessed (GET Request)
   Alternatively, the malicious file may have already been present on the server, and a victim accessed it.
   In this scenario, an HTTP GET request would reveal the retrieval of the malicious file.

Answer:62.173.142.148

Q2: What is the name of the malicious file used for initial access?

At first glance, the second request may seem more suspicious due to its unusual nature. However, from a logical analysis perspective, it is more appropriate to investigate the first request.

This aligns with Scenario 2, where:

• The malicious file is already present on the server
• A user accesses the compromised page

Therefore, we should ask:
Which request is more likely to have been triggered by normal user behavior?

Based on this reasoning, the first request is the most relevant candidate.

Analysis Step

To validate this, I followed the HTTP Stream of the first request in Wireshark:

• This allows reconstruction of the full request/response
• Helps identify any embedded or downloaded malicious files

Answer: allegato_708.js

Q3: What is the SHA-256 hash of the malicious file used for initial access?

Go to file and select the Export objects and select http and save all second open the terminal and excute the command to get sha256

Answer: 847b4ad90b1daba2d9117a8e05776f3f902dda593fb1252289538acf476c4268

Q4: Which process was used to execute the malicious file?

I submitted the SHA256 hash to a threat intelligence platform (VirusTotal).

Then navigated to:

• Behavior → Process and service actions

Answer: wscript.exe

Q5: What is the file extension of the second malicious file utilized by the attacker?

Answer: .dll

Q6: What is the MD5 hash of the second malicious file?

Repeat the steps on the Q3 and save the second file malicous and open the terminal and excute the command md5sum file

Answer: e758e07113016aca55d9eda2b0ffeebe

This analysis is based on the following CyberDefenders lab:

https://cyberdefenders.org/blueteam-ctf-challenges/3cx-supply-chain/

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

In this lab, I performed a hands-on analysis of the compromised MSI installer, extracted its contents, and investigated the malicious components hidden within. Throughout the process, I focused on identifying key indicators, understanding the techniques used by the attackers, and mapping their behavior to the MITRE ATT&CK framework.

This write-up walks through the full investigation process, from extracting the installer and analyzing DLL side-loading behavior, to identifying anti-analysis techniques and attributing the attack to a known APT group.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Before starting the analysis, I calculated the SHA256 hash of the MSI file to uniquely identify the sample and ensure its integrity.

The resulting hash is:

59e1edf4d82fae4978e97512b0331b7eb21dd4b838b850ba46794d9c7a2c0983

Q1 Understanding the scope of the attack and identifying which versions exhibit malicious behavior is crucial for making informed decisions if these compromised versions are present in the organization. How many versions of 3CX running on Windows have been flagged as malware?

When I researched the 3CX supply chain attack, I found an official report from Unit42 (Palo Alto Networks):

https://unit42.paloaltonetworks.com/3cxdesktopapp-supply-chain-attack/

According to the report, the affected Windows versions are 18.12.407 and 18.12.416. Therefore, the total number of malicious versions is 2.

Answer: 2

Q2 Determining the age of the malware can help assess the extent of the compromise and track the evolution of malware families and variants. What’s the UTC creation time of the .msi malware?

To determine the creation time of the MSI file, I checked its details on VirusTotal.

According to the VirusTotal analysis, the creation time of the malware is:

2023–03–13 06:33:26 UTC

This timestamp represents when the malicious MSI file was originally created.

ِAnswer : 2023–03–13 06:33

Q3 Executable files (.exe) are frequently used as primary or secondary malware payloads, while dynamic link libraries (.dll) often load malicious code or enhance malware functionality. Analyzing files deposited by the Microsoft Software Installer (.msi) is crucial for identifying malicious files and investigating their full potential. Which malicious DLLs were dropped by the .msi file?

To identify the malicious DLLs, I began by extracting the MSI file using 7-Zip. After extraction, I discovered that the installer contained an embedded archive named product.cab.

I focused on the product.cab file because MSI installers typically store their actual application files inside embedded CAB archives. By extracting this archive, I was able to access the real contents of the application, including the DLL files where the malicious payload was located.

After extracting the CAB file, I listed all the DLL files and checked them on VirusTotal. Most of the DLLs appeared to be legitimate system or graphics libraries with no malicious detections.

However, ffmpeg.dll and d3dcompiler_47.dll showed suspicious results and were flagged by security vendors. Based on these findings, I identified them as the malicious DLLs dropped by the MSI file.

Answer: ffmpeg.dll,d3dcompiler_47.dll

Q4 Recognizing the persistence techniques used in this incident is essential for current mitigation strategies and future defense improvements. What is the MITRE Technique ID employed by the .msi files to load the malicious DLL?

To determine the MITRE Technique ID used by the MSI file, I analyzed the file on VirusTotal and reviewed the “MITRE ATT&CK Tactics and Techniques” section shown in the image.

From this section, I observed that the technique used is “DLL Side-Loading” under “Hijack Execution Flow”, with the corresponding MITRE ID:

T1574.002 (DLL Side-Loading)

Answer:T1574

Q5 Recognizing the malware type (threat category) is essential to your investigation, as it can offer valuable insight into the possible malicious actions you'll be examining. What is the threat category of the two malicious DLLs?

To determine the threat category, I analyzed the malicious DLLs using VirusTotal. The analysis showed multiple classifications, including trojan, PUA, and dropper.

Among these, the primary threat category is identified as a Trojan, which indicates that the files disguise themselves as legitimate components while executing malicious actions.

Answer:Trojan

Q6 As a threat intelligence analyst conducting dynamic analysis, it’s vital to understand how malware can evade detection in virtualized environments or analysis systems. This knowledge will help you effectively mitigate or address these evasive tactics. What is the MITRE ID for the virtualization/sandbox evasion techniques used by the two malicious DLLs?

To identify the MITRE technique used for virtualization and sandbox evasion, I analyzed the malicious DLL file on VirusTotal.

In the “MITRE ATT&CK Tactics and Techniques” section, I found that the file is associated with “Virtualization/Sandbox Evasion”.

The corresponding MITRE ID shown in VirusTotal is:T1497

Answer:T1497

Q7 When conducting malware analysis and reverse engineering, understanding anti-analysis techniques is vital to avoid wasting time. Which hypervisor is targeted by the anti-analysis techniques in the ffmpeg.dll file?

To identify the targeted hypervisor, I analyzed the ffmpeg.dll file using the strings command and searched for virtualization-related indicators.

The output contained references such as “VMware Screen Codec / VMware Video”, which clearly indicates that the malware is checking for VMware environments.

Therefore, the targeted hypervisor is:VMware

Answer: VMware

Q8 Identifying the cryptographic method used in malware is crucial for understanding the techniques employed to bypass defense mechanisms and execute its functions fully. What encryption algorithm is used by the ffmpeg.dll file?

Answer: RC4

Q9 As an analyst, you’ve recognized some TTPs involved in the incident, but identifying the APT group responsible will help you search for their usual TTPs and uncover other potential malicious activities. Which group is responsible for this attack?

To identify the threat actor behind the attack, I researched the 3CX supply chain incident using threat intelligence sources such as Unit42 and other security reports.

These reports attribute the attack to the Lazarus Group, a well-known advanced persistent threat (APT) group.

Therefore, the group responsible for this attack is:

ِAnswer: Lazarus Group

Introduction

Cyber attacks are not random events. They follow a structured path where each step enables the next. What may initially appear as harmless activity — such as a spike in network traffic — can quickly escalate into a full system compromise if not properly investigated.

In this scenario, the attacker progressed through multiple stages: reconnaissance, exploitation, execution, privilege escalation, persistence, defense evasion, data collection, exfiltration, and finally impact.

Understanding each of these stages in depth is essential for any SOC analyst, not only to detect attacks but also to understand attacker behavior and intent.

1. T1595.002 — Active Scanning (Vulnerability Scanning)

Description

The first observable sign of the attack was a sudden spike in inbound traffic from a single external IP address. When analysts inspected the HTTP headers, they discovered the following user-agent:

Mozilla/5.0 (compatible; Nmap Scripting Engine;)

This user-agent is a strong indicator of Nmap Scripting Engine (NSE) usage. Nmap is not just a port scanner — it can actively probe services, detect vulnerabilities, and even attempt exploitation using scripts.

From an attacker’s perspective, this phase is about answering critical questions:

• Which ports are open?
• What services are running?
• Are there known vulnerabilities associated with these services?

Instead of blindly attacking, the attacker is mapping the environment intelligently.

Detection

Detecting this stage requires strong visibility at the network level:

• Identify unusual spikes in traffic from a single IP
• Detect repeated connection attempts across multiple ports
• Look for known scanning signatures (like Nmap user-agent)
• Use SIEM correlation rules to identify scanning patterns over time

A key challenge is that scanning may appear similar to legitimate traffic, especially if done slowly.

Prevention

• Block or rate-limit suspicious IP addresses
• Use IDS/IPS systems to detect scanning behavior
• Disable unnecessary services and close unused ports
• Apply network segmentation to reduce exposure

Impact

If not detected, the attacker gains a clear map of the environment, identifying exactly where to attack next.
This significantly increases the success rate of the next stage.

2. Active Scanning (Main Technique)

Description

While the previous section focused on a specific sub-technique (vulnerability scanning), the broader technique is Active Scanning.

This means the attacker is directly interacting with the target system instead of passively observing it. This interaction can include:

• Port scanning
• Service probing
• Banner grabbing

The goal is to build a detailed understanding of the system.

Detection

• Sequential probing across ports or services
• Repeated requests targeting different endpoints
• Patterns indicating enumeration activity

Prevention

• Use intrusion detection systems
• Monitor abnormal connection patterns
• Limit external exposure

Impact

This phase defines the attacker’s strategy. A well-executed scan can reveal exactly where the system is weakest.

3. T1190 — Exploit Public-Facing Application (SQL Injection)

Description

After identifying a vulnerable service, the attacker exploited a SQL Injection vulnerability in a public-facing web application.

SQL injection occurs when user input is directly included in database queries without proper validation. This allows attackers to manipulate the query logic.

For example:

• ' OR 1=1 → forces authentication bypass
• UNION SELECT → extracts data from the database

Instead of interacting with the application normally, the attacker is communicating directly with the database through the application.

Detection

• Analyze web logs for SQL-related patterns
• Identify abnormal input in request parameters
• Monitor repeated failed queries or database errors
• Use WAF alerts to detect injection attempts

Prevention

• Use parameterized queries (prepared statements)
• Validate and sanitize all inputs
• Deploy a WAF
• Perform regular security testing

Impact

This is the entry point of the attack.
Once successful, the attacker can access data and potentially execute further commands.

4. S0225 — sqlmap (Automated Exploitation Tool)

Description

The attacker used sqlmap, an automated SQL injection tool.

Instead of manually testing payloads, sqlmap:

• Detects vulnerabilities
• Exploits them automatically
• Extracts database contents

This transforms the attack from manual effort into an automated process.

🛠 Detection

• High-frequency HTTP requests
• Repetitive payload structures
• Consistent request timing patterns

Prevention

• Rate limiting
• WAF with signature detection
• Monitor abnormal traffic

Impact

Automation allows attackers to scale attacks and compromise systems much faster.

5. T1059.003 — Windows Command Shell (cmd.exe)

Description

After gaining access, the attacker executed a reverse shell using cmd.exe.

A reverse shell allows the compromised machine to connect back to the attacker, giving them remote command execution capabilities.

This is a major turning point:
The attacker moves from exploiting a vulnerability → to controlling the system.

Detection

• cmd.exe executed by a web server process
• Event ID 4688 logs
• Suspicious command-line arguments

Prevention

• Restrict command execution
• Monitor process behavior
• Use application control

Impact

The attacker now has direct control and can run any command on the system.

6. Privilege Escalation — Token Impersonation (SeImpersonatePrivilege Abuse)

Description

After gaining initial access, attackers are often limited by the privileges of the compromised account. In this scenario, the attacker escalates privileges by abusing SeImpersonatePrivilege, a powerful Windows privilege that allows a process to impersonate another user.

Using the API:
ImpersonateLoggedOnUser

the attacker can take advantage of an already authenticated high-privilege token (e.g., SYSTEM or Administrator) and “act” as that user.

This technique is commonly used in real-world attacks (e.g., Potato attacks like JuicyPotato), where attackers exploit misconfigurations in Windows services to obtain elevated tokens.

From an attacker’s perspective:

• Initial access = limited control
• Privilege escalation = full control

This step is critical because it removes all restrictions.

Detection

Detecting privilege escalation is challenging because it often uses legitimate system functions:

• Event ID 4672 → Special privileges assigned
• Sudden privilege elevation (user becomes admin unexpectedly)
• Suspicious API calls related to token manipulation
• Processes accessing tokens they normally shouldn’t

Behavior-based detection is key:
A low-privileged process suddenly performing high-privileged actions is highly suspicious.

Prevention

• Apply the principle of least privilege
• Remove unnecessary privileges like SeImpersonatePrivilege
• Patch known privilege escalation vulnerabilities
• Monitor sensitive API usage and token access

Impact

Privilege escalation gives the attacker complete control over the system.

At this point, the attacker can:

• Disable security tools
• Modify system configurations
• Access all files
• Persist inside the environment

This is one of the most dangerous turning points in the attack.

7. T1543.003 — Persistence via Windows Service Modification

Description

After gaining elevated privileges, the attacker ensures long-term access by modifying a Windows Service.

In this technique, the attacker changes the service’s ImagePath so that it points to a malicious executable (e.g., reverse shell). This means:

Every time the system starts → the malicious payload runs automatically.

Windows services are trusted components that run in the background, often with high privileges. This makes them an ideal persistence mechanism.

From an attacker’s perspective:

• Access without persistence = temporary
• Access with persistence = long-term control

Detection

Persistence through services leaves multiple traces:

• Event ID 7045 → New service installation
• Changes in existing service configuration
• Suspicious service names or unusual executable paths
• Services pointing to uncommon directories (e.g., temp folders)

A key detection idea:
Legitimate services rarely change frequently — unexpected modification is a red flag.

Prevention

• Restrict permissions to create/modify services
• Monitor service-related registry keys
• Use EDR to detect persistence mechanisms
• Audit system changes regularly

Impact

Persistence ensures the attacker can return to the system anytime, even after:

• Reboot
• User logout
• Temporary cleanup

This makes eradication much harder and increases dwell time.

8. T1562.001 — Disable Security Tools (Defense Evasion)

Description

Once the attacker gains high privileges and persistence, the next logical step is to remove visibility.

In this scenario, the attacker disables the EDR (Endpoint Detection and Response) system. This is a classic defense evasion technique.

Attackers understand that:
“If defenders can’t see me, they can’t stop me.”

Disabling EDR may involve:

• Stopping security services
• Killing processes
• Modifying configurations
• Using admin privileges to bypass protections

This step often happens right before major actions like data exfiltration.

Detection

Detecting defense evasion is critical but tricky:

• Sudden termination of security tools
• Missing logs or telemetry gaps
• Alerts indicating tampering
• Unexpected service stoppage events

One of the strongest indicators:
Security tools going offline unexpectedly.

Prevention

• Enable EDR tamper protection
• Restrict administrative access
• Monitor health status of security tools
• Configure alerts for service stoppage

Impact

Disabling security tools creates a blind spot.

After this step:

• Attacker activity is no longer monitored
• Detection becomes extremely difficult
• The attacker can move freely inside the system

This significantly increases the success rate of the remaining attack stages.

9. TA0009 — Collection (Data Staging using ccf32)

Description

At this stage, the attacker has already gained full control over the system and is preparing for one of the most critical objectives: data exfiltration.

The presence of a suspicious file named ccf32 indicates that the attacker transferred a custom or unknown binary to the compromised host. This file is likely used for data collection and staging.

Data staging means gathering sensitive information from different parts of the system and organizing it in one place before exfiltration. Instead of sending data directly (which may trigger alerts), attackers often:

• Collect files gradually
• Compress or encrypt them
• Store them temporarily in a staging location

This behavior reduces noise and helps avoid detection.

From a SOC perspective, this stage is dangerous because:

• The attacker already has access
• The focus shifts from access → data theft

Detection

Detecting this stage requires visibility into file activity and system behavior:

• Monitor creation of unknown or uncommon files (like ccf32)
• Detect file access patterns (many files accessed in a short time)
• Identify abnormal file aggregation (e.g., many files copied to one directory)
• Use EDR to track execution of suspicious binaries

A key indicator is behavior change — the system suddenly starts reading or collecting large amounts of data.

Prevention

• Implement file integrity monitoring (FIM)
• Restrict execution of unknown binaries (application control)
• Use endpoint protection to detect suspicious file activity
• Apply least privilege to limit access to sensitive data

Impact

At this point, the attacker is preparing to steal data.
Even if no exfiltration has occurred yet, the organization is already at high risk of a data breach.

10. M1021 — Restrict Web-Based Content (Preventing Exfiltration via GitHub)

Description

After staging the data, the attacker proceeds with exfiltration by uploading the collected data to a public GitHub repository.

This is a very important detail.

Attackers often avoid using obvious malicious servers. Instead, they use trusted platforms such as:

• GitHub
• Google Drive
• Dropbox

Why?
Because traffic to these platforms is usually allowed and considered legitimate.

This makes detection significantly harder, as the traffic blends with normal user activity.

Detection

Detecting exfiltration through trusted platforms requires deeper monitoring:

• Monitor outbound connections to external services (e.g., GitHub)
• Detect unusual upload حجم أو timing
• Identify abnormal user behavior (e.g., server uploading data externally)
• Analyze API calls related to file uploads

One key indicator:
A server that normally does not upload data suddenly starts sending large amounts of data externally.

Prevention

• Restrict access to non-approved external services
• Implement Data Loss Prevention (DLP) solutions
• Use proxy filtering and allowlisting
• Monitor outbound traffic at network level

Impact

This stage results in actual data loss.

Consequences include:

• Exposure of sensitive data
• Legal and compliance issues
• Financial damage
• Loss of customer trust

This is one of the most critical stages in the attack.

11. T1491.002 — Website Defacement (Final Impact Stage)

Description

In the final stage, the attacker modifies the organization’s public-facing website to display unauthorized content, often propaganda or attacker messages.

This is known as website defacement, and it represents the Impact phase of the attack.

At this point, the attacker is no longer trying to stay hidden.
Instead, they want to:

• Prove they compromised the system
• Damage the organization’s reputation
• Send a message (political, ideological, or personal)

To achieve this, the attacker modifies web files such as:

• HTML
• PHP
• JavaScript

This requires sufficient privileges and access to the web server.

Detection

Detection involves both internal and external monitoring:

• File Integrity Monitoring (detect changes in web files)
• Web server logs showing unauthorized modifications
• Alerts for unexpected administrative actions
• External monitoring detecting visible content changes

A strong indicator:
Website content changes without authorized deployment.

Prevention

• Restrict access to web server directories
• Enforce strong authentication and access control
• Use file integrity monitoring tools
• Regularly patch and secure web applications
• Separate web servers from internal systems (segmentation)

Impact

Website defacement has a high visible impact:

• Immediate reputational damage
• Loss of customer trust
• Public evidence of compromise
• Possible business disruption

Even if no data is stolen, defacement alone indicates a serious security failure.

https://docs.google.com/forms/d/e/1FAIpQLSfQ2vHew0OwbzCSPnH54YPLLw4jPfCM5ch4wDUk4j71BKxYsA/viewform

Q1. Subject of the email

I started by reviewing the email body and noticed that the subject line creates urgency and fear to push the user to click on the link.

Answer:
FWD: All unverified accounts will be suspended on 10/30/2022

Q2. Return-Path

I checked the Return-Path field to understand where replies would be sent and identify the real sender.

Answer:
bounce+31a2a2.6303d-emily.jenkins=potentialsecurity.net@gorgias.io

Q3. Actual Return-Path Email

I extracted the full Return-Path email address from the header to identify the actual sending address.

Answer:
bounce+31a2a2.6303d-emily.jenkins=potentialsecurity.net@gorgias.io

Q4. Sending IP Address

I checked the SPF record in the email headers to identify the IP address that sent the email.

Answer:
143.55.227.147

Q5. IP Information (WHOIS)

I used a WHOIS lookup tool to gather detailed information about the IP address, including location and ASN.

Answer (City):
San Antonio

Answer (ASN):
AS396479

Q6. Sender Domain

I returned to the Return-Path and extracted the domain part after the “@”.

Answer:
gorgias.io

Q7. Email Authentication

I checked the authentication results (SPF, DKIM, DMARC) to verify the legitimacy of the email.

Answer:
SPF: pass
DKIM: pass
DMARC: fail

Q8. SPF Result

I reviewed the SPF result in the email authentication section.

Answer:
pass

Q9. DKIM Result

I checked the DKIM result to confirm message integrity.

Answer:
pass

Q10. Email Time

I checked the Date field in the email header to determine when the email was sent.

Answer:
2022/10/31 07:03:57

Q11. Domain Expiration

I performed a WHOIS lookup to find the domain expiration date.

Answer:
2030/11/20

Q12. VirusTotal Category

I analyzed the domain in VirusTotal to identify its classification.

Answer:
onlineshop

Q13. Domain Registration Date

From WHOIS results, I identified the domain registration date.

Answer:
2014/11/20

Q14. Click Phrase

I examined the email content to identify the main call-to-action phrase.

Answer:
Confirm my wallet

Q15. First URL

I hovered over the link to identify the initial URL.

Answer:
usertest.sciquest.com/apps/Router/ExternalSiteTransition

Q16. Redirect URL

I analyzed the URL parameters and extracted the final destination.

Answer:
https://drop-coin-availablenow.site44.com/

Q17. VirusTotal Score

I checked the URL in VirusTotal to see how many vendors flagged it.

Answer:
12/95

Q18. Associated IPs

I reviewed the analysis to determine how many IPs are associated with the URL.

Answer:
3

Q19. MITRE Technique

I mapped the behavior to MITRE ATT&CK to identify the attack technique.

Answer:
T1204.001

Q20. MITRE Mitigation

I identified the mitigation related to IDS/IPS from MITRE ATT&CK.

Answer:
M1031

Q21. Second Phrase

I reviewed the email source and found another phrase containing the same link.

Answer:
Get Help

Q22. Final Verdict

After analyzing all indicators, I determined the nature of the email.

Answer:
Yes, this is a True Positive phishing attack because it uses social engineering techniques and contains a malicious redirect link leading to a fake website intended to steal user information.

https://docs.google.com/forms/d/e/1FAIpQLSc01WiqErnbO3qbxDNvmEnhSk3cFLDCIXzVzne6wO86-5D28A/viewform

Q1. Identify one strong phishing indicator from the email subject line that reflects attacker intent. What is the exact subject?

Explanation:

The subject line contains clear social engineering techniques:

• “ACTION REQUEST” → creates urgency
• “violating our terms” → creates fear

This combination pressures the victim to act quickly without verifying the email legitimacy.

Answer:

[ACTION REQUEST] You have been red flagged for violating our terms

Q2. The attacker attempts to impersonate a trusted brand. What email identity is presented to the user?

Explanation:

The attacker uses a trusted brand name “Amazon Help Center” to deceive the user.
However, the actual email domain is different from Amazon’s official domain.

Header Evidence:

The domain fareast.com.sg is not related to Amazon → this confirms impersonation.

Answer:

amz@fareast.com.sg

Q3. While analyzing the email path, determine the origin of the message. What IP should be considered the true sending source?

Explanation:

To find the real sender, we check the earliest “Received” header entry.
This reveals the actual source of the email.

Header Evidence:

Answer:

77.32.148.40

Q4. During transmission, attackers often rely on third-party infrastructure. What domain was used during the SMTP handshake (HELO/EHLO)?
“”SMTP HELO/EHLO is the first massage was sent between two servers before transfer an email””

Explanation:

The HELO value represents the identity the sending server uses during SMTP communication.

Header Evidence:

Answer:

hn.d.sender-sib.com

Q5. Based on infrastructure indicators, identify the country name that generates this attack.

Answer:

France

Q6. Despite appearing legitimate, analyze whether the sending server is authorized. What is the SPF verdict?

Explanation:

SPF checks whether the sending server is authorized to send emails on behalf of a domain.
Even if it passes, attackers can still abuse legitimate services.

Header Evidence:

Answer:

pass

Q7. Verify message integrity using cryptographic signatures. What is the DKIM result?

Explanation:

DKIM ensures the email content was not altered in transit.
However, it does not guarantee the email is legitimate.

Header Evidence:

Answer:

pass

Q8. Evaluate domain alignment policy. What is the DMARC result?

Explanation:

DMARC checks alignment between the sender domain and authentication results.
A failure indicates domain mismatch, which is a strong phishing indicator.

Header Evidence:

Answer:

fail

Q9. Using threat intelligence, determine the network name typically associated with this infrastructure.

Explanation:

WHOIS lookup shows that the IP belongs to Mailinblue (Sendinblue) infrastructure.

Answer:

FR-MAILINBLUE-20061213

Q10. When tracing bounce handling, what return domain reveals the actual sending infrastructure?

Explanation:

The Return-Path shows where bounce messages are sent.
This often reveals the real sending infrastructure.

Header Evidence:

Answer:

hn.d.sender-sib.com

Q11. Using ASN/IP intelligence, determine the organization name (ISN) typically associated with this infrastructure

FROM WHOIS

Answer:

Sendinblue SAS

Q12. During email analysis, identifying the exact time a message was processed by security infrastructure can help in timeline reconstruction. Extract the original arrival timestamp of this email based on 12 hour system.

I SHEARCHED ABOUT DATE IN E-MAIL HEADER :

The timestamp in the header is in 24-hour format and must be converted
00:43 → 12:43 AM

Answer:

2023/12/15 12:43:28 AM

Q13. Instead of directly embedding malicious domains, attackers often use tracking/redirection layers. Identify the main domain used for this purpose.

Explanation:

The email uses a tracking domain to hide the real destination and monitor user interaction.

Answer:

sendibt3.com

Q14. What phishing sub-technique name ?

Explanation:

The attack uses links instead of attachments to deliver malicious content.

Answer:

Phishing via Link (T1566.002)

Q15. From content and branding, which organization is being impersonated?

Explanation:

The content clearly imitates Amazon branding.

Answer:

Amazon

Q16. Identify the value (code) used to simulate legitimacy and urgency within the email body.

Explanation:

The attacker includes a fake code to simulate legitimacy and urgency.

Answer:

EWK1DOOSJ982

Q17. According to MITRE ATT&CK, Which software name associated with this sub-technique there contributors are Arie Olshtein, Check Point; Kobi Eisenkraft, Check Point ?

Explanation:

The phishing technique is associated with credential harvesting malware.

Answer:

Pony

Q18. Identify a hidden image used by attackers to track user interaction with the email, type the path of this image.

A hidden 1x1 pixel image is used to track when the email is opened.

Answer:

https://chdgiei.r.bh.d.sendibt3.com/im/2736848/efa8fa6d687f584a84b74f518d42f2b14e8b9491f2385af03a9162e0f4bc506f.jpg

Q19. Identify a hidden gif used by attackers to track user interaction with the email, type the path of this gif.

Explanation:

Another hidden image (GIF) is used for tracking user interaction.

Answer:

https://chdgiei.r.bh.d.sendibt3.com/im/2736848/4a8f10aadc4f0604542a2bd40dc49eafb457671PbWWqgKDBDorh525uecKaGZD21FGSoCeR.gif

Q22. Map this attack to MITRE ATT&CK. What is the main technique ID?

Explanation:

The attack falls under phishing in MITRE ATT&CK.

Answer:

T1566

Q23. Identify a mitigation strategy focused on increase awareness level.

Explanation:

Increasing user awareness is done through training.

Answer:

M1017