FaresMorcy
  • Whoami
  • Footprinting Labs
    • Lab - Easy
    • Lab - Medium
    • Lab - Hard
  • Shells & Payloads
    • The Live Engagement
  • Password Attacks
    • Lab - Easy
    • Lab - Medium
    • Lab - Hard
  • Active Directory Enumeration & Attacks
    • Active Directory Enumeration & Attacks
    • AD Enumeration & Attacks - Skills Assessment Part I
    • AD Enumeration & Attacks - Skills Assessment Part II
  • SOC Hackthebox Notes & Labs
    • Security Monitoring & SIEM Fundamentals Module
    • Windows Event Logs & Finding Evil Module
    • Introduction to Threat Hunting & Hunting With Elastic Module
    • Understanding Log Sources & Investigating with Splunk Module
      • Introduction To Splunk & SPL
      • Using Splunk Applications
      • Intrusion Detection With Splunk (Real-world Scenario)
      • Detecting Attacker Behavior With Splunk Based On TTPs
      • Detecting Attacker Behavior With Splunk Based On Analytics
      • Skills Assessment
    • Windows Attacks & Defense
      • Kerberoasting
      • AS-REProasting
      • GPP Passwords
      • GPO Permissions/GPO Files
      • Credentials in Shares
      • Credentials in Object Properties
      • DCSync
      • Golden Ticket
      • Kerberos Constrained Delegation
      • Print Spooler & NTLM Relaying
      • Coercing Attacks & Unconstrained Delegation
      • Object ACLs
      • PKI - ESC1
      • Skills Assessment
    • Intro to Network Traffic Analysis Module
    • YARA & Sigma for SOC Analysts Module
      • Developing YARA Rules
      • Hunting Evil with YARA (Windows Edition)
      • Hunting Evil with YARA (Linux Edition)
      • Sigma and Sigma Rules
      • Developing Sigma Rules
      • Hunting Evil with Sigma (Chainsaw Edition)
      • Hunting Evil with Sigma (Splunk Edition)
      • Skills Assessment
  • TryHackme SOC 1
    • TShark
      • TShark: The Basics
      • TShark: CLI Wireshark Features
      • TShark Challenge I: Teamwork
      • TShark Challenge II: Directory
    • Tempest
    • Boogeyman 1
    • Boogeyman 2
    • Boogeyman 3
  • TryHackme SOC 2
    • Advanced Splunk
      • Splunk: Exploring SPL
      • Splunk: Setting up a SOC Lab
      • Splunk: Dashboards and Reports
      • Splunk: Data Manipulation
      • Fixit
    • Advanced ELK
      • Slingshot
    • Threat Hunting
      • Threat Hunting: Foothold
      • Threat Hunting: Pivoting
      • Threat Hunting: Endgame
  • TryHackme Rooms
    • Investigating Windows
    • Splunk 2
    • Windows Network Analysis
  • Powershell Scripting Fundamentals
  • SANS SEC504 & Labs
    • Book one
      • Live Examination
      • Network Investigations
      • Memory Investigations
      • Malware Investigations
      • Accelerating IR with Generative AI
      • Bootcamp: Linux Olympics
      • Bootcamp: Powershell Olympics
    • Book Two
      • Hacker Tools and Techniques Introduction
      • Target Discovery and Enumeration
      • Discovery and Scanning with Nmap
      • Cloud Spotlight: Cloud Scanning
      • SMB Security
      • Defense Spotlight: Hayabusa and Sigma Rules
    • Book Three
      • Password Attacks
      • Cloud Spotlight: Microsoft 365 Password Attacks
      • Understanding Password Hashes
      • Password Cracking
      • Cloud Spotlight: Insecure Storage
      • Multipurpose Netcat
    • Book Four
      • Metasploit Framework
      • Drive-By Attacks
      • Command Injection
      • Cross-Site Scripting
      • SQL Injection
      • Cloud Spotlight: SSRF and IMDS
    • Book Five
      • Endpoint Security Bypass
      • Pivoting and Lateral Movement
      • Hijacking Attacks
      • Establishing Persistence
      • Defense Spotlight: RITA
      • Cloud Spotlight: Cloud Post-Exploitation
  • SANS SEC511 & Labs
    • Resources
      • Primers
      • References
      • Tools
        • Network
        • Elastic Stack
      • Printable Versions
    • Book One
      • Part One
      • Part Two
      • Part Three
    • Book Two
      • Part One
      • Part Two
      • Part Three
      • Part Four
    • Book Three
      • Part One
      • Part Two
      • Part Three
      • Part Four
    • Book Four
      • Part One
      • Part Two
      • Part Three Lab
      • Part Four Lab
    • Book Five
      • Part One Lab
      • Part Two Lab
      • Part Three Lab
  • CyberDefenders
    • XXE Infiltration Lab
    • T1594 Lab
    • RetailBreach Lab
    • DanaBot Lab
    • OpenWire Lab
    • BlueSky Ransomware Lab
    • Openfire Lab
    • Boss Of The SOC v1 Lab
    • GoldenSpray Lab
    • REvil Lab
    • ShadowRoast Lab
    • SolarDisruption Lab
    • Kerberoasted Lab
    • T1197 Lab
    • Amadey Lab
    • Malware Traffic Analysis 1 Lab
    • Insider Lab
    • Volatility Traces Lab
    • FalconEye Lab
    • GitTheGate Lab
    • Trident Lab
    • NerisBot Lab
  • Practical Windows Forensics
    • Data Collection
    • Examination
    • Disk Analysis Introduction
    • User Behavior
    • Overview of disk structures, partitions and file systems
    • Finding Evidence of Deleted Files with USN Journal Analysis
    • Analyzing Evidence of Program Execution
    • Finding Evidence of Persistence Mechanisms
    • Uncover Malicious Activity with Windows Event Log Analysis
    • Windows Memory Forensic Analysis
  • Hackthebox Rooms
    • Campfire-1
    • Compromised
    • Brutus
    • Trent
    • CrownJewel-1
  • WEInnovate Training
    • Weinnovate - Active Directory Task One
    • Build ELK Lab
      • Configure Elasticsearch and Kibana setup in ubuntu
      • Configure Fluent-Bit to send logs to ELK
      • Set up Winlogbeat & Filebeat for log collection
      • Send Logs from Winlogbeat through Logstash to ELK
      • Enable Windows Audit Policy & Winlogbeat
      • Elasticsearch API and Ingestion Pipeline
    • SOAR
      • Send Alerts To Email & Telegram Bot
      • Integrate Tines with ELK
    • SOC Practical Assessment
    • Lumma C2
    • Network Analysis
  • Build ELK Lab
    • Configure Elasticsearch and Kibana setup in ubuntu
    • Configure Fluent-Bit to send logs to ELK
    • Set up Winlogbeat & Filebeat for log collection
    • Send Logs from Winlogbeat through Logstash to ELK
    • Enable Windows Audit Policy & Winlogbeat
    • Elasticsearch API and Ingestion Pipeline
  • Build Home Lab - SOC Automation
    • Install & configure Sysmon for deep Windows event logging
    • Set up Wazuh & TheHive for threat detection & case management
    • Execute Mimikatz & create detection rules in Wazuh
    • Automate everything with Shuffle
    • Response to SSH Attack Using Shuffle, Wazuh, and TheHive
  • Home Lab (Attack & Defense Scenarios)
    • Pass-the-Hash Attack & Defense
    • Scheduled Task Attack & Defense
    • Kerberoasting Attack & Defense
    • Kerberos Constrained Delegation
    • Password Spraying Attack & Defense
    • Golden Ticket Attack & Defense
    • AS-REProasting Attack & Defense
    • DCSync Attack & Defense
  • Home Lab (FIN7 (Carbanak Group) – Point of Sale (POS) Attack on Hospitality Chains)
  • Home Lab (Lumma Stealer)
Powered by GitBook
On this page
  • Practical NSM Issues
  • NSM Sensors and Servers
  • Practical Issues: How to Sniff
  • Mirror Ports
  • Network Taps
  • Port Overload
  • Sniffing Virtual Traffic
  • Practical Issues: NTP, Time Zones, and Daylight Saving Time
  • Entropy and freq.py
  • Cornerstone NSM: Detecting Entropy
  • Programmatic Entropy Analysis
  • Get Your freq.py on
  • Domain Generation Algorithms DGAs
  • DGA++ – Beyond Domain Generation Algorithms
  • freq_server.py – for freq-ing at Scale
  • Tracking .EXE
  • Stage 2 .EXE
  • Tracking .EXEs
  • Identifying Windows .EXEs
  • "This Program Must Be Run under Win32"
  • Spot the Anomaly
  • Predictable Transfer of .EXEs
  • Defensible Executable Transfers
  • How .EXEs Should Not Move
  • Detecting Stage 2 Downloads
  • Targeted Anomaly-Based .EXE Rule
  • Lab 3.3 - Wireshark Merlin Analysis
  1. SANS SEC511 & Labs
  2. Book Three

Part Three

Practical NSM Issues

Before diving deeper into NSM, we need to consider some key practical aspects:

  • Server/sensor design

  • How to sniff

  • NTP

Network Security Monitoring needs the right technology and design to be effective.

NSM Sensors and Servers

A basic design uses sensors with a central server. Some data like NIDS alerts goes to the server, while other data like full packet captures stay on the sensors. Security Onion 2.0 calls these manager nodes and forward nodes.

Full packet capture data is kept local because centralizing it needs the same bandwidth as the captured traffic. Analysts can access it on local sensors when needed, with authorization based on data sensitivity.

High-volume data stays on the sensor, while low-volume and summary data is sent to a central server.

Practical Issues: How to Sniff

You need a spot to monitor all network traffic. It's easy on virtual networks but can be a bit tricky on physical ones. However, affordable taps and switches with mirror ports make this easier now.

Don't use a hub for sniffing. Hubs are old tech (Layer 1) and only support half-duplex at 10 or 100 Mbps, which slows down network traffic and reduces performance. TCP/IP needs full duplex.

A small hub can be used for incident handling if a single system is acting oddly and no tap or span port is available. Connecting the system to the hub and the hub to the switch lets you monitor traffic. The downside of slower speeds is minimal for just one PC.

Mirror Ports

Mirror ports have some drawbacks, like not forwarding bad frames or VLAN tags, but they work well if managed switches with mirror port support are already in place.

Managed switches with span ports are now much cheaper. It's not built for heavy use, but it shows how affordable this feature has become.

Cisco calls it a "span" port, but most others call it a "mirror" port. They mean the same thing, and we'll use "mirror port."

Network Taps

The small "throwing star" tap needs two cables to monitor both sides. More advanced taps with dual power and buffers can cost hundreds to thousands of dollars. Overall, adding network taps to production environments isn't usually hard or expensive, except for fiber or very high-speed connections (10 gig+).

Port Overload

Mirror ports and taps can get overloaded. If you send seven 100-megabit streams to a 100-megabit mirror port, it can drop frames. Some advanced taps have buffers to store frames during overload, but these buffers only work for short bursts of traffic. Prolonged overload will fill the buffer.

Regularly check your mirror ports and taps. Adjust as needed by reducing traffic or adding more taps or mirror ports.

Sniffing Virtual Traffic

Sniffing virtual traffic is easy. Just set up a virtual NSM sensor like Security Onion on the hypervisor, select the virtual network, and start sniffing. One sensor can monitor multiple networks, but make sure it has enough virtual RAM, CPU, and disk space.

Practical Issues: NTP, Time Zones, and Daylight Saving Time

Using NTP for synchronization is a basic best practice and is usually free with internet access, using minimal bandwidth.

If your organization operates in different time zones, use Coordinated Universal Time (UTC) for consistency. It’s also better to skip daylight saving time since it varies by location, even within the same country. For example, most of the U.S. observes daylight saving time, but Hawaii does not.

Entropy and freq.py

Malware tries to hide by changing its MS-DOS headers to escape detection. Let’s find these changes!

Cornerstone NSM: Detecting Entropy

Entropy means disorder:

  • Strong encryption provides a ciphertext with high entropy

  • Random string: high entropy

  • Strings like “download” or “files”: Lower entropy

Malware often creates random strings to evade detection. For example, if malware is named "evil.exe," it would be easy to spot through pattern matching.

Programmatic Entropy Analysis

We need a way to automatically detect this, even if analysts have to reduce false positives later. Luckily, there are free tools for entropy analysis, like ent, which can analyze input to measure its entropy. However, using these tools can be complicated.

Get Your freq.py on

A tool called freq.py detect randomness in small strings. It uses Natural Language Processing to analyze how often character pairs appear, improving the chances of finding unusual strings that are unlikely to occur naturally.

The file freq.py includes ready-made frequency tables in lowercase and mixed case, created from a lot of public English text. You can make your own tables with it, but you'll need a large amount of good, normal text to create accurate tables.

Domain Generation Algorithms DGAs

A key use of freq.py is to find automatically generated DNS names. Malware often uses algorithms called Domain Generation Algorithms (DGAs) to create future DNS names without needing a complete list. Analysts usually identify DGAs by reverse engineering malware. While this is helpful, it's even better to spot unknown malware by looking for unusual DNS requests, which freq.py can help with.

While you'll need to overlook some domains and services eventually, and this method won't always perfectly show malicious activity, the benefits of this single approach are significant. Since malware often uses DNS, any techniques that enhance our ability to detect it are valuable.

DGA++ – Beyond Domain Generation Algorithms

DGA detection is a key use for freq.py, but attackers create many other random artifacts to evade simple detection methods. As you learn about adversary tactics, look for items you can identify and use with freq.py.

Despite needing to ignore some domains and services, DNS-based techniques are valuable because malware often uses DNS, offering an extra advantage in detecting threats.

freq_server.py – for freq-ing at Scale

To scale freq.py, you can use a cron job or scheduled task. For advanced use, freq.py offers a server mode with a simple web API.

Tracking .EXE

Malware can bypass signature-based detection. Start using behavioral detection by tracking .EXE transfers. Don't dismiss it just because encryption is harder to catch.

We can detect encryption. Stage 1 malware usually just downloads the stage 2 executable, which then starts encrypting communications. We'll focus on finding these stage 2 downloads along with the other methods.

Stage 2 .EXE

We used the strings command on /pcaps/meterpreter.pcap with a minimum length of 14 to display the .EXE header and encryption functions like "OpenSSL," "AES," and "CAMELLIA."

strings -n 14 /pcaps/meterpreter.pcap | less

Camellia is a block cipher similar to AES, with comparable speed and efficient hardware design, making it ideal for low-power TLS applications.

Tracking .EXEs

The listed strings aren't essential to the DOS header and can be changed by malware to avoid detection. Old non-PE files may reverse the magic bytes to "ZM" on older systems like XP.

Identifying Windows .EXEs

wireshark /pcaps/virut-worm.pcap &

"This Program Must Be Run under Win32"

wireshark /pcaps/zeus-gameover-loader.pcap &

Spot the Anomaly

Many EXEs with obvious anomalies, like this one, often appear "clean" to antivirus at first. High ASCII characters 9d and 9a replace the low ASCII word "be."

Predictable Transfer of .EXEs

EXEs entering an organization should follow a trust model, ranked from most trusted to least trusted, like this: download.microsoft.com → internal WSUS server → desktop. Unfortunately, many organizations don’t use this secure design and let .EXEs be downloaded from almost anywhere, as long as they pass antivirus checks. This approach is unsafe and likely to fail.

Defensible Executable Transfers

The diagram shows an important network security idea: Executables should only come from trusted sources. Many organizations allow users to download any executable that antivirus software approves, which is risky because antivirus can miss some threats. Using malware detection tools like FireEye improves safety, but it's still not completely safe.

How .EXEs Should Not Move

A hallmark of malware is transferring .EXEs from client to client. This behavior is easy to detect, assuming basic network segmentation is in place, and a sensor is able to see the traffic.

Non-Defensible and Suspicious Executable Flow

The diagrams illustrate how malware enters and spreads in an organization. Anomaly-based detection makes it easy to spot these cases. The first example needs a strong network setup with clear sources for all .EXE files, which can be challenging for many companies.

To easily detect the second example, set up basic network segmentation at Layer 3, putting clients on their own network. Then, just create an alert for any executable transfer between clients. If clients and servers share the same network at Layers 2 and 3, you need to redesign your network to fix this issue.

Detecting Stage 2 Downloads

Tracking .EXE transfers on a network is easy, but getting a clear view beyond a basic IDS is the real challenge. However, switches with mirror ports are now cheap, making it affordable to add IDS sensors to important servers and client networks, like those with VP laptops and desktops.

Many have stopped using anomaly-based methods because they produce too many false alarms. Monitoring .EXEs shared between clients is a straightforward and effective way to detect anomalies. A strong network setup and some easy adjustments to our detection systems let us create a practical form of anomaly detection that we can act on right away.

Targeted Anomaly-Based .EXE Rule

Rules like this are often turned off because they create too many alerts. These alerts aren't false positives; they're real alerts from harmless traffic, like downloads from microsoft.com. We should also look for UDP transfers.

Alert UDP $CLIENT_NET any -> $CLIENT_NET any (msg:"ET POLICY PE EXE or DLL
Windows file download"; flow:established,to_client; content:"MZ";
byte_jump:4,58,relative,little; content:"PE|00 00|"; distance:-64;
within:4; classtype:policy-violation; sid:5110420; rev:1;)

Lab 3.3 - Wireshark Merlin Analysis

Objectives:

  • Analyze artifacts of an attack using the Merlin post-exploitation framework.

  • Carve Microsoft EXEs from a packet capture using Wireshark.

  • Gain experience using Wireshark.

Challenges:

We previously investigated an exploit the Merlin post-exploitation framework. We will now dig deeper into this exploit with Wireshark. We used Zeek to carve EXEs from capture.pcap: we will now use Wireshark to do the same thing.

  • Open /labs/merlin/capture.pcap with Wireshark

  • View the TCP connection that sent the most data

  • Extract all EXEs and DLLs

  • Locate the cmd.exe connection

Let's start by opening /labs/merlin/capture.pcap with Wireshark:

wireshark /labs/merlin/capture.pcap

Now, let's check which TCP connection transferred the most data:

In Wireshark: go to Statistics -> Conversations.

Next, we'll click the "TCP" tab and sort by the number of bytes, from highest to lowest.

The connection that sent the most TCP data was from 10.5.11.11:53813 to 192.0.2.160:445.

Now let's right-click on either IP in the TCP stream and select "Apply as Filter" → "Selected" → "A ↔ B".

Next, let's close the "Conversations" window, go back to the main Wireshark window, click on a packet, and select Follow -> TCP Stream.

We previously extracted EXEs from capture.pcap using Zeek. We will now use Wireshark to do the same thing.

We might wonder why we do this step twice with different tools. It's because some tools can find data that others miss. Plus, it's important for an analyst to be independent of any single tool.

In Wireshark, let's go to File > Export Objects > SMB, then click Save All.

Then press Open.

Now, let's identify the sending and receiving IP addresses, filename, and MIME type used to transfer the EXE files. We previously analyzed capture.pcap with Zeek and found a cmd.exe connection. Let's use what we learned from the Zeek analysis to find and track that connection.

We earlier looked for "Microsoft Corporation. All rights reserved" to find the cmd.exe connection. Let's copy that text, then go to Edit -> Find Packet.

Let's open the "Find" bar at the top of Wireshark. Paste "Microsoft Corporation. All rights reserved" into it. The background will stay red. Next, switch "Packet list" to "Packet bytes" and change "Display filter" to "String." The background will then turn green. Finally, let's click "Find."

Then we'll right-click on the highlighted packet and choose Follow -> TCP Stream:

This connection displays data traveling from the sender (port 8443) to the receiver (port 53664). In Wireshark, data sent from the sender is shown in red, while data sent back from the receiver appears in blue. The command typed is shown twice: once when sent and once when echoed back. To view only the traffic from sender to receiver, let's change "Entire conversation" to 10.5.11.11:53722 -> 192.0.2.160:8443.

PreviousPart TwoNextPart Four

Last updated 7 months ago