FIN7 (Carbanak Group) – Point of Sale (POS) Attack on Hospitality Chains
Last updated
Last updated
In 2017–2018, FIN7, a financially motivated cybercrime group, launched a sophisticated campaign targeting U.S. hospitality and restaurant chains, including Chipotle Mexican Grill, Arby’s, and Chili’s. The group stole over 15 million credit and debit card numbers from more than 6,500 POS terminals across 3,600 business locations in 47 states. Their primary method was spear-phishing to gain initial access, followed by deploying customized malware, including the Carbanak backdoor and POS-specific malware like Pillowmint, to exfiltrate payment card data.
This attack & defense scenario is based on this case, and I have attempted to simulate the phases that occurred. I hope you find this article useful.
Before we begin, ensure your home lab meets these requirements:
Domain Controller (DC01): A Windows Server configured as an AD domain controller.
Client Machine (Client02): A Windows client joined to the domain.
Kali Linux Machine.
Ubuntu Machine (Elasticsearch & Kibana) & C2 server
Let's proceed with installing Thunderbird on the Windows machine (Client02) to serve as the designated email client.
We also need to install the Office Administrative Templates on DC01.
You can download it directly from the following official Microsoft link: .
After extracting the files to the folder located at C:\OfficeTemplates, let's proceed with the following steps:
SYSVOL is a shared folder on Domain Controllers that stores:
Group Policy Objects (GPOs)
Logon scripts
Other domain-wide data that needs to be replicated to all DCs
Let's create domain accounts for Main.local to simulate FIN7’s targets.
Administrator: labadmin@Main.local, password: AdminPass456!, Domain Admin.
IT Admin: jody@Main.local, password: Welcome2025!, local admin on Client02.
Customer Service Rep: asmith@Main.local, password: Password123, standard user.
POS User: posuser@Main.local, password: POS2025, local admin on Client02.
Let's create an Organizational Unit (OU) named "Employees" to organize and manage these users.
Next, we will proceed to create the necessary users and groups.
Let's verify by opening Active Directory Users and Computers and reviewing the user accounts located in the Employees Organizational Unit (OU).
We need to log in to the Client02 machine using the accounts jody@Main.local and posuser@Main.local.
Next, we need to create a Group Policy Object (GPO) to intentionally configure the Client02 machine with vulnerabilities, simulating the conditions exploited by FIN7.
Open Group Policy Management, right-click on the Employees organizational unit (OU), select "Create a GPO in this domain, and Link it here…", and name the new GPO "Workstation_Security".
Next, we will proceed to modify this policy.
Enable Macros:
Path: User Configuration > Policies > Administrative Templates > Microsoft Word 2016 > Word Options > Security > Trust Center.
Set Enable VBA macros to Enable all macros.
This allows all Word macros to run without warnings, which could be risky if the document is untrusted.
Lower UAC:
Path: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options.
Set User Account Control: Behavior of the elevation prompt for administrators to Prompt for consent.
This makes admins click "Yes" instead of entering a password for UAC prompts, reducing security checks.
Enable RDP:
Path: Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections.
Set Allow users to connect remotely to Enabled.
This lets users remotely connect to this computer using Remote Desktop.
Enable SMB:
Path: Computer Configuration > Policies > Administrative Templates > Network > Lanman Workstation.
Set Enable insecure guest logons to Enabled.
This allows unauthenticated (guest) access to shared folders, which is a security risk.
Local Admin for POS:
Path: Computer Configuration > Policies > Windows Settings > Security Settings > Restricted Groups.
Add Jody and Posuser to Administrators group.
This gives the "posuser" and "jody" accounts full admin rights on the Client02 machine.
Let's also disable SMB signing on both DC01 and Client02 systems.
We also need to enable certain policies to ensure comprehensive visibility into our environment.
Audit Logon/Logoff
Audit Process Tracking
Audit Privilege Use
Audit Object Access
Enable Powershell Logging
We also need to install Snort to function as an Intrusion Detection System (IDS) for monitoring network traffic. Additionally, we need to install Fluent Bit to forward Snort logs to our ELK stack. Since Winlogbeat is designed specifically for collecting Windows Event Logs, it cannot be used to send Snort logs, so Fluent Bit will be used for this purpose.
Let's start by downloading and installing Snort. Ensure it is installed on both the Windows server and the Windows workstation.
After downloading the two files and completing the setup, I created a rule to log all traffic except on ports 9200, 5601, and 443 in order to minimize noise. Let's now add this rule to the local.rules file.
Next, we will run Snort to capture and log network traffic.
Next, let's download Fluent Bit and configure it to forward logs to the ELK stack.
I used the following regex to extract data from Snort.
Next, we need to modify the fluent-bit.conf configuration file.
We will extract data from the alert.ids file and forward it to the ELK stack for analysis.
FIN7 uses reconnaissance to identify employees, email addresses, and network vulnerabilities to craft targeted phishing campaigns and plan their attack. They often target hospitality chains (e.g., hotels, restaurants) to access POS systems for card data theft.
Assume that FIN7 targets employees with elevated privileges, such as IT administrators (Jody), for phishing attacks, while also identifying customer service representatives (Asmith) as secondary targets due to their comparatively lower security awareness.
Gain initial access to Client02 by phishing jody with a malicious Word document containing a macro.
FIN7 frequently uses spear-phishing emails with macro-enabled Office documents to deliver malware like Carbanak or GRIFFON. Macros are effective because many organizations have macros enabled or users are tricked into enabling them.
Let's proceed to generate the malicious document using msfvenom. The FIN7 threat group commonly employs macro-enabled Word documents to deliver initial payloads, such as a Meterpreter reverse shell.
Next, we need to create the malicious Microsoft Word document.
In Word, click File > New > Blank Document.
Add some text to make the document look legitimate.
Next, let's open the VBA Editor, where we will insert the malicious macro code.
The Auto_Open() subroutine ensures the macro runs automatically when the document is opened.
This embeds the malicious Meterpreter payload into the Word document. When opened, the macro will execute automatically.
FIN7 frequently incorporates deceptive messages to persuade users to enable macros, allowing them to bypass macro security prompts during real-world attacks. In this lab environment, however, this step is optional, as macros have already been enabled through Group Policy (GPO).
Next, save the document as a macro-enabled file.
Next we need to setup a listener. The VBA macro in Customer Complaint.doc will connect back to us when executed. We need a listener to catch this connection and gain remote access, just as FIN7 establishes a C&C channel with their malware.
After configuring the listener, let's proceed to send the malicious document to the target via email and observe the subsequent activity.
Let's download and open the file to verify whether it establishes a reverse shell connection.
Let's background the session and enumerate the currently running processes.
Let's check the running process on the victim machine:
After gaining initial access with a macro (Phase 2), FIN7 deploys a second-stage payload to solidify their control over the compromised system. The initial macro payload is often lightweight and may be unstable or easily detected, so a more robust payload is deployed for persistence and further exploitation.
Before deploying a second payload, let's first collect relevant system information.
FIN7 needs to confirm their foothold and understand the compromised system (OS version, architecture, user privileges) to select an appropriate second-stage payload.
We can also enhance the stability of our payload by migrating it to a more reliable and trusted process.
Let's create a second-stage payload to establish a more stable reverse shell, providing improved control over Client02.
Let's transfer this payload to the C2 server.
We are hosting payloads on our Command and Control (C&C) server for remote delivery, leveraging legitimate HTTP traffic to avoid detection.
Next, we will develop an obfuscated PowerShell downloader script.
Next, we need to obfuscate the downloader.ps1 script using the Invoke-Obfuscation tool.
Command Breakdown:
-ScriptPath: Specifies the input script.
-Command "TOKEN,ALL,1": Applies all token-based obfuscation techniques (e.g., variable renaming, string splitting).
OUT,/root/downloader_obf.ps1: Saves the obfuscated script to /root/downloader_obf.ps1.
Here we used obfuscation to transform scripts, making them unrecognizable to security tools that rely on static signatures.
Let's inspect the the obfuscated script:
Let's proceed with transferring this script to our Command and Control (C2) server as well.
We now need to configure a second listener on the Kali machine. This secondary listener serves as a fallback option and operates on a different port (1337) to prevent conflicts with the initial shell running on port 4444.
Here we execute the second-stage payload to establish a more robust foothold, replacing the initial macro-delivered shellcode with a more reliable Meterpreter session.
Next, we will utilize our Meterpreter session to download the obfuscated script.
Let's verify the new session.
Now, we’ll use built-in Windows tools (LOLBins) to download the needed files or payloads, helping us avoid detection from security tools. These downloads are important for the next steps.
Next, let's proceed to download Mimikatz onto the Client02 machine.
Downloading Mimikatz prepares us for privilege escalation.
Let's create a small reconnaissance script and upload it to our Command and Control (C2) server.
Next, we will download the script using the BITSAdmin utility.
Next, let's try to inject malicious code into legitimate processes like explorer.exe to evade detection, as the malicious activity appears to originate from a trusted process. DLL injection is a common technique where a malicious DLL is loaded into the target process’s memory space, allowing arbitrary code execution while masking the activity under the legitimate process.
Let's now generate a new malicious DLL payload that will be used for injection via injectallthings.exe.
Next, upload the malicious.dll file to the target system.
Next, we need to Inject the DLL into explorer.exe Using rundll32.exe:
This command tells Meterpreter to execute rundll32.exe on the victim system and load the malicious.dll from disk, calling the function at ordinal 0 to run its payload.
Let's initiate a listener on port 6666.
Let's use the netstat command to display all active network connections.
FIN7, a financially motivated cybercrime group, is known for its sophisticated and multi-layered approach to maintaining access to compromised systems. The use of multiple reverse shells mirrors their real-world strategy to achieve redundancy, stealth, and flexibility.
Additional techniques, such as fileless execution which allows code to run directly in memory and evade disk-based detection can also be employed. However, we will explore these methods in future scenarios.
Next, we will conduct reconnaissance using built-in system commands.
Establish multiple persistence mechanisms on Client02 to maintain access, ensuring we can return to the system even after reboots, network disruptions, or if the initial Meterpreter sessions are terminated by defenders.
Before setting up persistence, we need to gather additional system information to tailor persistence mechanisms.
FIN7 maps the system’s configuration to identify opportunities for persistence (e.g., existing scheduled tasks, services, or startup items they can mimic).
Now we'll uses scheduled tasks to execute payloads at regular intervals or on system events, ensuring persistence even after a reboot.
Let's upload it to our Command and Control (C2) server.
Next, proceed to download this file onto the Client02 machine.
Let's now create a scheduled task to execute the payload at system startup.
/tn "WindowsUpdateCheck": Names the task to blend in with legitimate tasks.
/tr "C:\Users\Public\document.pdf.exe": Specifies the payload to execute.
/sc onstart: Runs the task on system startup.
/ru SYSTEM: Runs as SYSTEM for higher privileges.
/f: Forces creation, overwriting any existing task with the same name.
Here we used scheduled tasks to ensure our payload runs after reboots.
Let's initiate a listener on port 9999 and manually execute the scheduled task to verify its functionality.
Next, let's modify registry keys to execute payloads on user logon or system startup, a stealthy and reliable method. Registry-based persistence is common, blends with legitimate configurations, and survives reboots.
Let's reuse the previously created payload.
This will execute whenever jody logs in, ensuring persistence.
Let's verify the registry key:
Additionally, we will configure services to execute our payloads with SYSTEM-level privileges, ensuring both persistence and elevated access. Leveraging Windows' native service framework allows the payloads to run with higher privileges and maintain functionality across system reboots.
Here we created a service to ensure our payload runs with SYSTEM privileges after a reboot.
We can also create a shortcut to the payload we're about to generate and place it in the user's Startup folder, ensuring it executes upon login.
Next, let's proceed to download the payload onto the Client02 machine.
Next, We’ll create a VBScript on Kali, transfer it to the victim, and execute it to place the shortcut.
After transferring this file to our Command and Control (C2) server, we need to download it onto the victim machine and executed to create a shortcut in the startup folder.
Let's execute the VBScript:
Although FIN7 has not been observed using this technique according to MITRE, it is still worth exploring.
This technique makes Windows automatically run our malware every time the user logs in, by putting a shortcut in the Startup folder, just like regular programs do.
To verify its functionality, let's initiate the listener on port 4446 and manually execute the shortcut to confirm if we receive a reverse shell.
FIN7’s Lateral Movement TTPs (Based on MITRE ATT&CK):
T1021.001 (Remote Services: RDP): FIN7 uses RDP to access target systems with stolen credentials.
T1078 (Valid Accounts): They steal and reuse domain credentials to authenticate to servers or POS systems.
T1003 (OS Credential Dumping): FIN7 dumps credentials from memory (e.g., using Mimikatz) to enable lateral movement.
T1047 (Windows Management Instrumentation): They use WMI to execute commands remotely without direct login.
T1021.006 (Remote Services: SMB/Windows Admin Shares): FIN7 accesses admin shares (e.g., C$) to deploy malware.
We previously downloaded Mimikatz under the name netdiag.exe. Alternatively, we can use Meterpreter to load Mimikatz and extract credentials.
Let's attempt this using Mimikatz and save the output to a file that we will later download to our local machine.
We have obtained the NTLM hash for the labadmin account; we can now use it to attempt access to the Windows server.
While attempting to use the NTLM hash of the labadmin account to establish an RDP connection to the Windows server, I encountered the following error.
To enable this feature, we need to add a new registry key.
Next, let's try again to login using the NTLM hash of the user labadmin.
We will leverage labadmin’s NTLM hash to access DC01 via SMB. Before proceeding, we will deploy a payload to establish an initial foothold.
Let's authenticate to DC01 using the labadmin hash:
This verifies the hash grants access to DC01.
Next, we will download the payload file to the Windows server.
Let's initiate a listener on port 4447 and execute the payload to verify if we can establish a reverse shell connection.
Let's attempt to crack the NTLM hash of the LabAdmin account using Hashcat.
Now that we have obtained the password for the labadmin account, let's attempt to locate the POS data on the Windows server. From our meterpreter session:
Let's move this file to C:\Users\Public in preparation for exfiltration.
Let's also download Mimikatz onto DC01 and attempt to dump the SAM database, aiming to extract local account hashes (such as the local Administrator) to enable redundancy or facilitate access to non-domain systems.
Then, let's proceed by executing Mimikatz and saving the output to a file, which we will exfiltrate at a later stage.
Let's extract the NTDS.dit file (Active Directory database) from DC01 to obtain NTLM hashes for all domain users (e.g., asmith, posuser, etc...).
Domain user hashes enable further lateral movement, persistence, or privilege escalation across the Main.local domain.
Let's begin by creating a Volume Shadow Copy.
A snapshot of the C: drive, including the C:\Windows\NTDS\NTDS.dit file, has been created. The next step is to copy both the NTDS.dit file and the SYSTEM hive.
FIN7 copies NTDS.dit for offline hash dumping.
We have placed all the files intended for exfiltration in the directory C:\Users\Public. However, let's proceed by downloading the ntds.dit and SYSTEM files to our Kali machine and attempt to dump it.
After downloading these two files, let's proceed with extracting the hashes using SecretsDump.
There are additional techniques employed by FIN7 that we can explore in greater detail in a future article.
Let's now compress the data we've collected in preparation for exfiltration.
To simplify the process, we will use Netcat to transfer files directly from DC01 to the C2 server over a TCP connection.
We need to start a listener on our C2 server.
Next, we will transfer the Netcat utility to DC01.
Let's proceed with sending the data.zip file.
FIN7 leverages common protocols like FTP to blend with legitimate traffic
Let's Install and Configure FTP on our C2 server:
Ensure these lines are uncommented or added:
We need to verify the upload directory exists and has correct permissions:
Restart FTP:
Then I connect to the DC01 using rdp and exfiltrate the data.zip file.
Let's confirm that we have received the file.
In this phase, I downloaded Covenant onto my Ubuntu machine. Next, I will set up a listener and generate the payload.
We are now listening on port 8080; let's proceed to create the launcher.
I have downloaded the payload and will now proceed to transfer it to DC01 and execute it.
Now, let's check Covenant
We can also interact with the DC01 machine via the Interact tab.
We are also capable of handling various tasks.
It is now time to begin the investigation. Let's use ELK to identify relevant artifacts and activities.
FIN7 frequently uses spearphishing with malicious Office documents to deliver malware, targeting retail and hospitality users. Their macros often execute PowerShell or command-line tools to fetch payloads from attacker-controlled servers, blending with legitimate user activity.
From here we can see that The file Customer Complaint.docm was opened from the user's Downloads folder (C:\Users\jody\Downloads\) by the user jody. The .docm extension indicates a Word macro-enabled document, which can contain embedded VBA macros.
Let's upload this file to VirusTotal for analysis.
Next, let's verify whether Word initiates a PowerShell or cmd process.
We observe that Microsoft Word (WINWORD.EXE) spawned cmd.exe after opening a macro-enabled document (Customer Complaint.docm). This behavior is a common malware tactic, as legitimate Word documents typically do not launch command prompt (cmd.exe) unless explicitly running malicious macros.
Next, we need to identify network connections originating from Client02 to determine whether the machine established a connection to a remote IP address after the user Jody opened the Word document.
We identified four connections to the IP address 192.168.204.152 on various ports commonly associated with reverse shells and backdoors. We have now confirmed the initial access vector to Client02: when Jody opened the malicious document, the attacker successfully established a reverse shell connection on port 4444.
Let's also review the Snort logs and apply a filter for this specific port.
Let's also create a visualization of the network connections that occurred.
FIN7 frequently uses multi-stage execution chains, combining macros, PowerShell scripts, and DLL injection to deploy malware after phishing (source: Mandiant, FireEye). Their execution tactics prioritize stealth, leveraging native tools (PowerShell, rundll32.exe) and obfuscation to evade detection (source: Trend Micro)
Let's examine the commands executed by the attacker after gaining a reverse shell through the malicious macro-enabled document.
Recognizable strings executed via cmd.exe or powershell.exe can be utilized to identify potentially anomalous or suspicious activity. Below are some examples of common PowerShell strings used for this purpose:
invoke / invoke-expression / iex
-enc / -encoded
-noprofile / -nop
bypass
-c / -command
-ExecutionPolicy / -ep
WebRequest
Download
The attacker initially downloaded a file named downloader_obf.ps1, executed it, and subsequently downloaded another file named scvhost.exe.
Let's begin by filtering for the first file the attacker downloaded after establishing a reverse shell to analyze its activity. To do this, we'll also apply a filter for Event Code 4104.
After obtaining an initial reverse shell, the attacker downloaded and executed a script named downloader_obf.ps1, which retrieved and ran a second payload called payload.exe. This second-stage reverse shell was likely deployed due to its increased stability, as the initial shell was prone to disconnection or crashes.
Let's also examine the Snort logs and apply a filter to isolate traffic associated with port 1337.
In addition to PowerShell and Command Prompt, threat actors often exploit other legitimate built-in Windows binaries to execute malicious commands. Many of these binaries referred to as Living Off The Land Binaries (LOLBAS).
The attacker downloaded several scripts and files, including netdiag.exe, recon.ps1, document.pdf.exe, and create_shortcut.vbs.
Let's apply a filter based on the initial script downloaded by the attacker (netdiag.exe).
In this case, the attacker downloaded mimikatz.exe but renamed it to netdiag.exe and executed it to extract credentials from system memory. However, there is a gap in the timeline. To accurately trace the attacker's actions, we need to proceed step by step based on the timestamps. Let's start by filtering the logs associated with the second script, recon.ps1, to identify related activity.
We can observe that the attacker downloaded and executed this script; our next step is to analyze its behavior and determine what actions it performed.
This script attempts to retrieve information about running processes and network adapters, and saves the collected data to files located in the C:\Users\Public directory.
During our analysis of network connections from the Client02 machine to the remote IP address 192.168.204.152, we identified four separate connections on different ports. So far, we have examined WINWORD.EXE and payload.exe. The third process, rundll32.exe, is communicating over port 6666. We will now filter by this process to investigate related events.
Let's also examine the Snort logs and apply a filter to isolate traffic associated with port 6666.
The attacker uses rundll32.exe to execute the first exported function (0) of malicious.dll, which is placed in a publicly accessible folder, a common tactic by malware to gain persistence called dll injection.
Next, the attacker downloaded a file called document.pdf.exe, let's filter by this file to see its relevant events and check its behaviour.
The attacker downloads a disguised malicious executable named document.pdf.exe from a remote server using certutil, then establishes persistence by creating a scheduled task named "WindowsUpdateCheck" that runs the file at system startup with SYSTEM privileges, adds a registry key under the current user's run settings to launch it automatically at login, and finally creates a fake Windows service named "WindowsUpdateSvc" configured to auto-start and execute the same malicious file, effectively ensuring the malware runs consistently across system reboots and user sessions.
We can also examine created scheduled tasks by reviewing events with Event ID 4698.
We can also examine registry keys that were added or modified by reviewing Event ID 13.
Let's examine the network connections associated with the file document.pdf.exe.
The attacker created a malicious executable disguised as a PDF (document.pdf.exe), then established persistence by creating a service, scheduled task, and registry entry to ensure the payload runs at system startup, granting the attacker a reverse shell on port 9999.
While reviewing the remote connections above, we identified an additional connection to the remote IP on port 4446 initiated by a process named scvhost.exe. We will now examine this process to analyze the associated logs.
The attacker first downloaded scvhost.exe, and two minutes later, retrieved a VBScript file named create_shortcut.vbs.
The command cscript C:\Users\jody\Downloads\create_shortcut.vbs executes a Visual Basic Script (VBS) file named create_shortcut.vbs from the user's Downloads folder using the Windows Script Host (cscript.exe), which typically creates, modifies, or manages Windows shortcut files (.lnk), it could be used maliciously to establish persistence, execute hidden commands, or deploy payloads via shortcut manipulation.
Let's open the create_shortcut.vbs file to examine its contents.
This VBScript code creates a malicious shortcut named NetworkDiagnostics.lnk in the Windows Startup folder (%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\), which ensures the file scvhost.exe (a rogue executable mimicking svchost.exe) automatically runs at system startup pretending to be a "Network Diagnostics Tool," potentially enabling persistence for malware or unauthorized actions.
When the attacker executed the shortcut file named NetworkDiagnostics.lnk, they received a reverse shell connection on their listener configured on port 4446.
While analyzing the files downloaded by the attacker, we discovered a file named netdiag.exe, which is actually a renamed version of Mimikatz. The attacker renamed the tool prior to transferring it to Client02, where it was executed to extract the NTLM hashes of users logged into the system.
The attacker now possesses the NTLM hashes of users logged into the Client02 machine. Let's investigate whether any of these hashes were used to authenticate and gain access to other systems.
We observed that the attacker has now used the NTLM hash of the domain administrator account "labadmin" to authenticate to the domain controller DC01.
Or using this query:
The attacker execute this command to disable Windows "Restricted Admin Mode" for RDP (Remote Desktop Protocol), making it easier to perform pass-the-hash (PtH) attacks or lateral movement in a compromised network.
After completing this action, he authenticated to the RDP service using the NTLM hash.
Next, we will analyze the commands executed by the attacker after gaining access to DC01 to determine whether any files were downloaded.
We observed that the attacker downloaded a file named updater.exe and saved it to C:\Windows\update.exe. Let's filter the logs by this file to analyze its behavior.
The attacker downloaded and executed update.exe, but no additional useful information was obtained.
I believe the attacker downloaded this payload so that when the victim clicked it, a reverse shell would be established.
Let's examine the additional commands executed by the attacker.
The attacker downloaded Mimikatz onto DC01 to extract the NTLM hashes of all user accounts and successfully cracked the NTLM hash of the user labadmin.
Additionally, the attacker attempted to create a Volume Shadow Copy (VSS) snapshot of the C: drive.
He copied the NTDS.dit and SYSTEM files to C:\Users\Public. Let’s examine the contents of that directory.
After the attacker created a shadow copy of the C: drive, he transferred the SYSTEM and ntds.dit files to the C:\Users\Public directory. Additionally, the files sam_creds.txt and credit_cards.xlsx were also present in the same location.
During our review of the commands executed by the user labadmin, I discovered that all the collected data was saved in a ZIP archive named data.zip.
The attacker then attempted to establish a connection to their Command and Control (C2) server at IP address 192.168.204.146 on port 1333 in order to exfiltrate the data they had collected.
Based on the two images above, the attacker downloaded and executed a file named GruntHTTP.exe. Subsequently, DC01 initiated a connection to the remote IP address (192.168.204.146) on port 8080.
We observer that the attacker downloaded and executed a malicious file called GruntHTTP.exe file, which then established an outbound connection to a non-standard port (e.g., 8080), signaling a likely command-and-control (C2) backdoor for remote access, data theft, or further malware deployment.
We also observed earlier that the attacker attempted to connect to their Command and Control (C2) server at IP address 192.168.204.146 via FTP, likely for the purpose of data exfiltration.
VBA macros possess significant capabilities, including the ability to directly invoke Windows APIs. This allows them to interact with the operating system and perform potentially malicious actions, such as downloading malware or executing harmful code. As a result, analyzing macros is essential, as they are often exploited by attackers to compromise systems.
When the file type is unknown, we can use trid.exe to extract basic information about the sample. This tool helps identify the nature of the file and provides insights into the type of data we are analyzing.
The most straightforward method to detect macros in an Office file is to use the oleid.py Python utility, specifying the document you wish to analyze.
We have identified the presence of VBA macros. To verify this, we will use the olevba utility, which is designed to open Microsoft Office files, detect embedded VBA macros, and extract and analyze the VBA source code.
These rules are not the final production-ready versions. When deploying them in real-world environments, they need to be continuously tuned to minimize false positives as much as possible.
When the victim opened the document, the VBA code runs, likely spawning powershell.exe or cmd.exe to download and execute a reverse shell payload (e.g., Meterpreter) from the attacker’s server (192.168.204.152), connecting back to port 4444.
In this rule, we will detect winword.exe spawning powershell.exe or cmd.exe, indicating macro execution on Client02.
This rule means:
At each execution (every 1 minute), the rule analyzes data collected over the last 5 minutes (the look-back time).
For example, if the rule runs at 5:21 PM, it will check data from 5:16 PM to 5:21 PM. Then, at 5:22 PM, it will check data from 5:17 PM to 5:22 PM, and so forth.
Let's save the rule and review the alerts to confirm if the rule was triggered.
Let's create a detection rule to identify a reverse shell connection originating from Client02 to a remote IP on a non-standard port, initiated by a process spawned by winword.exe.
During the attack simulation, once the victim opens the document, I receive a reverse shell on my listener. Subsequently, when I begin using cmd, the detection rule is triggered.
Let's save the rule and review the alerts to verify whether it was successfully triggered.
Let's create a rule to detect TCP connections initiated from Client02 to a remote IP address using a non standard port, which may indicate a reverse shell.
We can create a rule to drop the packet; however, the drop action requires Snort to operate in inline mode (IPS mode) to actively block packets. On Windows, inline mode is not natively supported without specific configurations, such as using a third-party packet driver or bridge setup. If Snort is running in IDS mode (passive sniffing), it will only log alerts, not block traffic.
Let's add this rule to the local.rules file and verify whether the remote connection to the attacker's IP on port 4444 is successfully logged.
We can also strengthen our defensive posture by disabling macros in Microsoft Office through Group Policy.
Prevent Macro Execution:
Let's open the Customer Complaint.docm document to review the policy.
Attackers download secondary payloads (e.g., EXEs, DLLs) from C2 servers using PowerShell or BITSAdmin, executing them to establish shells. The FIN7 group commonly leverages techniques such as rundll32.exe, regsvr32.exe, or process injection to execute malicious DLLs while bypassing detection mechanisms
Let's create a rule to detect powershell.exe execution with suspicious command-line arguments indicating payload download or execution.
Let's save the rule and verify if it functions correctly.
We need to create a rule to detect instances where the process rundll32.exe loads a DLL file into a process, which may indicate a potential DLL injection attempt.
Let’s verify the functionality of the rule.
Let's create a detection rule to identify HTTP GET requests made to remote IP addresses for downloading executable files.
content:"GET"; http_method; : ensures it's an HTTP GET request.
pcre:"/\/[^\/]*\.(exe|ps1|dll)(\?|$)/i" : regex that matches .exe, .ps1, or .dll file names in the URI.
http_uri; : tells Snort to match this regex against the URI part of the HTTP request.
We can also develop a rule to detect reverse shell connections, similar to the approach used previously.
Additional mitigation measures can be implemented:
Prevent Script Execution:
Right-click Executable Rules
We can repeat for Additional Folders:
Path: C:\Temp
Path: C:\Users\*\Downloads
Next, we will proceed with enabling AppLocker enforcement.
In AppLocker → Right-click Executable Rules → Properties.
Next, we need to initiate the Application Identity Service.
Open services.msc → Find Application Identity (AppIDSvc) → Set Startup Type to Automatic → Click Start.
AppLocker requires this service to evaluate and enforce rules. Without it, rules won’t apply.
Enforcement mode blocks execution, whereas Audit mode logs attempted actions without preventing them, making it well-suited for initial testing and evaluation.
Now, let's attempt to execute netdiag.exe from the Public folder.
Let's develop a rule that precisely detects persistence mechanisms, while also implementing a layered defense strategy with proactive mitigations to effectively disrupt such persistence.
FIN7 frequently uses scheduled tasks to ensure payloads run periodically or on boot. Therefore, we will create a detection rule to identify the creation of scheduled tasks.
Let's create a scheduled task and monitor the alerts to verify that the rule is functioning correctly.
Let's create a detection rule to identify modifications to the Windows Registry Run key that may indicate the execution of a malicious payload.
Next, we need to verify the functionality of this rule.
Let's verify the functionality of this rule.
Let's develop a custom detection rule to identify RDP authentication attempts involving domain administrator accounts such as labadmin and Administrator.
We used the labadmin hash to RDP from Client02 to DC01. Windows Security logs capture this as Event ID 4624 (successful logon) with Logon Type 10 (RemoteInteractive).
Let's save the rule and verify its functionality.
Effective detection rules should avoid relying solely on filenames such as mimikatz.exe, as attackers can easily evade such checks by renaming the binary. Instead, emphasis should be placed on identifying behavioral patterns and unique artifacts associated with the tool.
We now need to save the rule and verify its functionality.
ELK Rule 3: LSASS Unauthorized Memory Access
In this rule we'll filter for Sysmon Event ID 10, which logs memory access via OpenProcess(), specifically targeting cases where LSASS is accessed, a key indicator of credential dumping.
But we need to exclude legitimate system processes that may access LSASS during normal operation.
We can also configure alerts to trigger only when the access flags are considered suspicious. When a process attempts to access lsass.exe, Sysmon logs the type of access requested in the winlog.event_data.GrantedAccess field. This field contains a hexadecimal access mask that specifies the permissions granted, such as reading memory, writing to memory, or full control.
Not all access to LSASS is inherently malicious, some legitimate processes, such as Task Manager, only retrieve basic information. However, processes that request full memory access are more suspicious. To minimize false positives, alerts should focus on unusually high levels of access.
Let's create a rule to detect suspicious access to lsass.exe using GrantedAccess: 0x1010, while excluding known legitimate processes.
Let's define a rule based on this and verify if it successfully generates an alert.
Let's attempt the attack once more to verify the functionality of this rule.
This rule targets network logons (LogonType 3) that utilize the NTLM authentication package, a method commonly associated with Pass-the-Hash attacks where adversaries authenticate using stolen password hashes.
Q) Is it normal for users to authenticate using NTLM?
Yes, it can be normal in certain cases.
Legacy applications or services that don’t support Kerberos
Accessing file shares across workgroups or from non-domain devices
Cross-forest or cross-domain trust scenarios
When time synchronization fails, and Kerberos cannot issue a TGT
Local logon attempts (even if to a domain-joined machine)
Authentication from non-Windows systems or old clients (e.g., printers, Linux, embedded devices)
But it's still a Red Flag in these cases:
NTLM logon to a Domain Controller (DC)
DCs should primarily use Kerberos for authentication.
NTLM used on a DC, especially from unusual systems is suspicious.
If you see AuthenticationPackageName: NTLM combined with TargetUserName: Administrator or svc_* accounts and LogonType: 3, it's a big red flag.
NTLM isn't always malicious, but when combined with sensitive accounts, systems, or logon patterns, it becomes a strong signal of compromise, especially in Pass-the-Hash attacks.
NTLM over network logon (type 3) to a domain controller, especially for admin accounts, is not normal in modern, secure environments. Kerberos should be used for these authentications.
Let's verify the functionality of the rule.
Let's develop a Snort rule to detect Remote Desktop Protocol (RDP) traffic to DC01, which may indicate potential lateral movement.
Let's save the rule and verify its functionality.
There are additional defensive measures we can implement to further enhance the security of the environment.
Restrict NTLM Authentication:
NTLM is an old authentication protocol that allows attackers to use stolen hashes for PtH attacks without needing the password. Restricting NTLM means forcing Windows to use Kerberos (a safer protocol using tickets) or blocking NTLM entirely on DC01 and CLIENT01.
Enable Protected Users Group:
The Protected Users group in Active Directory restricts how sensitive accounts authenticate, preventing their credentials from being cached in memory (LSASS) on machines like CLIENT01 and limiting NTLM usage.
Enable LSASS Protection (RunAsPPL):
LSASS (Local Security Authority Subsystem Service) is a Windows process that stores credentials, like labadmin’s NTLM hash, in memory on CLIENT01 and DC01. RunAsPPL (Run as Protected Process Light) locks down LSASS, requiring processes accessing it to have a special digital signature. This prevents unauthorized tools, like Mimikatz, from extracting hashes.
In this phase, I will focus solely on creating a Snort rule to detect potential NTLM hash usage for authentication over SMB on port 445, without developing any ELK rules.
Let's attempt authentication using the NTLM hash and observe whether Snort logs the activity.
Let's now review the Snort logs:
Impacket's psexec.py leverages the SMB protocol (TCP/445) to execute commands remotely. We provided a NTLM hash, which is used for pass-the-hash (PtH) authentication over SMB.
Restrict Privileged Access:
Click "Add User or Group" → "Browse".
Please specify the machines that are permitted for access.
Let's attempt to authenticate via RDP once more using the NTLM hash of the labadmin account to verify whether access is still possible.
Thank you for taking the time to read this, I hope you found it helpful.
To set up Elasticsearch and Kibana on an Ubuntu machine, refer to the following guide: .
Also we need to download and install Winlogbeat on the Domain Controller to forward logs to our ELK stack. For detailed setup instructions, refer to: .
Please download the following files from the provided link: and
Kindly refer to this URL for detailed instructions on downloading Fluent Bit:
Ref:
Please refer to this article for more details:
Please refer to this article for more details:
Please refer to this article for more details:
