Security monitoring
CS 3710
Security monitoring and detection
Our last major topic is security monitoring and detection.
In this part of the course we get to look at all of the different offensive techniques that attackers use and flip it on its head:
How might we use the knowledge we've gained to detect a breach?
Security monitoring and detection
Q: How might you detect the following?
- Attempts to scan your server to see what ports are open and what services are running on the machine
- Malware installed on your machine communicating back to a ransomware operator
- An attempt to exploit a remote code execution vulnerability in a web server that you're running
Security monitoring and detection
We've already seen a few of these ideas in Labs 5 and 6!
Security monitoring and detection
Source: Nextron Systems / Florian Roth
Challenges in detection
As we talk about detection, there are a few key challenges that we'll have to consider:
- What kinds of data are we looking at? How can we transform raw data into a form that makes it suitable for analysis?
- How do we filter data? How do we avoid false positives?
- How do we scale this up to thousands (or even millions) of machines?
Indicators of compromise
Indicators of compromise
An indicator of compromise (IOC) is any data point that might suggest that a machine has been breached.
Part of the defender's job is collect IOCs, enrich them with additional context, and analyze them to determine whether or not an actual breach has occurred.
Once a breach has been detected, a defender can build signatures for artifacts left by the attacker (malware, C2 patterns, etc.) to make it easier to detect them in the future.
Application logs
Most of the serious applications and services that you will deal with in the real world perform some sort of logging.
Application logs typically include information about actions taken, requests processed, diagnostics, and more.
Application logs
Example: the figure below shows Apache HTTP server's access logs after
running an nmap scan (with -A) against the server:
Application logs
Most programming languages have some kind of logging facilities (either built-in, or in a popular library):
import datetime
import logging
logging.basicConfig(
format="[%(asctime)s] (%(levelname)s) %(message)s",
level=logging.DEBUG,
)
if __name__ == "__main__":
logging.debug("Started server at %s", datetime.datetime.now())
...Outside of security, you typically want some kind of logging for performance metrics, detecting outages, debugging, and more.
Authentication activity
IOCs may also come from authentication activity -- records of who's trying to log in, when, and from where.
Network artifacts
Another source of information is network activity -- records of what traffic hosts are generating and when.
This can include firewall records, proxy logs, DNS logs, and more.
Filesystem artifacts
You can also check the filesystem for potential evidence of a breach, by monitoring changes to disk and/or by performing regular scans.
System auditing
Most operating systems also have provide some kind of API for monitoring events at the kernel level.
This can provide a more granular means of detecting a potential compromise.
System auditing: Sysmon (Windows)
Source: Sophos
Sysmon is a Windows system service and driver that records system activity to the Windows event log.
System auditing: auditd (Linux)
On Linux, the audit framework provides facilities for monitoring system events.
Source: RedHat
System auditing: auditd (Linux)
auditd is a Linux service that runs in the background and hooks into the audit
framework. Here are some examples of things you can detect with auditd:
# -w watch a specific path # -p [r|w|x|a] # specifies an attempt to access a file with a specific # permission request # # 1. Detect when /etc/shadow is accessed in any way # 2. Detect when /bin/bash is executed # 3. Detect when /etc/passwd is read # 4. Detect when /var/log/lastlog is written to -w /etc/shadow -w /usr/bin/bash -p x -w /etc/passwd -p r -w /var/log/lastlog -p w
Detect different types of file accesses
# -S specifies a syscall # # The memfd_create syscall creates a file handle to a location # in memory. It can be combined with execveat to execute a binary # entirely from memory without touching disk. -a always,exit -F arch=b32 -S memfd_create -a always,exit -F arch=b64 -S memfd_create
Detect individual syscalls
# Log attempts to perform one of the syscalls specified by the -S options # that results in an EACCES (permission denied) exit code # # -F auid>=1000 filters events to only users with a UID >= 1000 -a always,exit -F auid>=1000 -F arch=b64 \ -S creat -S open -S openat -S open_by_handle_at \ -S truncate -S ftruncate \ -F exit=-EACCES
Log "permission denied" events for specific users
After a breach: forensic analysis
All of these sources of information aren't just useful for detecting breaches, but also for analyzing the extent of a breach and performing post-mortem analysis.
Detection tools
Intrusion detection systems
As we discussed in the section on network security, many different network intrusion detection systems (NIDS) exist for potentially flagging activity at a protocol level.
YARA
In recent years, YARA has emerged as an industry standard for defining malware signatures. These are patterns that (ideally) uniquely identify a particular malware family.
YARA
YARA's syntax is flexible enough to support detecting IOCs over a wide range of data sources, including:
- Files: detect malicious scripts and binaries corresponding to various malware families
- Netflows: look at network traffic run YARA rules against them to identify C2 (command-and-control) patterns.
- Logs: create rules to identify exploitation attempts from logs.
- RAM: dump the RAM of a machine and see whether there's any evidence that there is malware in machine memory.
YARA
rule IsElf { meta: description = "Check if content is an ELF file" strings: // Magic bytes used in the header of an ELF file $header = { 7F 45 4C 46 } condition: $header at 0 }
rule IsElf { meta: description = "Check if content is an ELF file" strings: // Magic bytes used in the header of an ELF file $header = { 7F 45 4C 46 } condition: $header at 0 }
rule IsElf { meta: description = "Check if content is an ELF file" strings: // Magic bytes used in the header of an ELF file $header = { 7F 45 4C 46 } condition: $header at 0 }
YARA rule for checking whether a file is an ELF (Executable and Linkable Format) file
The strings section typically contains various strings / byte sequences that
appear in the malware
The condition section determines whether or not the file matches the rule.
YARA
rule M_APT_Downloader_BEATDROP {
meta:
author = "Mandiant"
description = "Rule looking for BEATDROP malware"
reference = "https://www.mandiant.com/resources/tracking-apt29-phishing-campaigns"
date = "2022-04-28"
score = 90
strings:
$ntdll1 = "ntdll" ascii fullword
$ntdll2 = "C:\\Windows\\System32\\ntdll.dll" ascii fullword nocase
$url1 = "api.trello.com" ascii
$url2 = "/members/me/boards?key=" ascii
$url3 = "/cards?key=" ascii
condition:
uint16(0) == 0x5a4d and uint32(uint32(0x3C)) == 0x00004550
and filesize < 1MB and all of them
}YARA
rule drovorub_unique_network_comms_strings
{
meta:
description = "NSA/CISA Drovorub network detection rules"
author = "NSA / FBI"
date = "2020-08-13"
strings:
/*
* These rules check whether all of these strings that are associated
* with Drovorub communications are present (this is just a subset of
* the original list)
*/
$s_01 = "action" wide ascii
$s_02 = "auth.commit" wide ascii
$s_03 = "auth.hello" wide ascii
/* ... */
condition:
all of them
}Source: NSA/CISA
YARA
rule EXPL_Log4j_CVE_2021_44228_JAVA_Exception_Dec21_1 {
meta:
description = "Detect exceptions in logs indicating potential Log4j exploit"
author = "Florian Roth"
reference = "https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b"
date = "2021-12-12"
score = 60
strings:
$xa1 = "header with value of BadAttributeValueException: "
$sa1 = ".log4j.core.net.JndiManager.lookup(JndiManager"
$sa2 = "Error looking up JNDI resource"
condition:
$xa1 or all of ($sa*)
}Source: Florian Roth
How do we develop YARA rules?
There are a lot of different ways to go about writing YARA rules to identify an exploit or malware family:
- Look at uncommon strings that exist in the malicious binary
- Run the malware in a sandbox and record a trace of its execution
- Automated tooling like YarGen
and much more.
What matters is identifying a pattern that (a) exists across the malware family, and (b) is unlikely to be triggered by non-malicious data.
Incident response
Incident response
After a breach, it's important to start gathering evidence about what systems and data were accessed by an attacker. This process serves a few purposes:
- Retaining the trust of the people you're serving.
- Compliance with regulations
- Figuring out the attack vector and tools used by the attackers
- Determining whether you're still breached (!)
Trust and safety
As engineers, you have a moral obligation to protect the people who depend on your services.
Trust and safety
Legal responsibilities
Depending on what state or country it's in, an organization will typically have a legal responsibility to report data breaches to regulators.
Legal responsibilities
For companies that do business internationally, they may have to make reports to multiple government agencies, especially in regions with stronger privacy laws.
Examples: GDPR, CCPA
Malware analysis
Most attackers use malware in some form or another. Once a breach is suspected, it can be difficult to prevent an investigator from recovering artifacts left by that malware.
This is especially true of malware that touches disk in any way.
Malware analysis is the practice of analyzing these artifacts.
Malware analysis is traditionally broken into two categories: static analysis and dynamic analysis.
Static analysis and reverse engineering
Reverse engineering (RE) is one common form of static analysis.
RE is the act of taking a compiled or otherwise obfuscated program and recovering clues about its operation.
Source: NSA / Ghidra
Dynamic analysis
In dynamic analysis, you run malware in a sandboxed and isolated environment to try to figure out what it does.
You can trace syscalls it's performing, network requests it's making, files it's accessing, and so on.
Source: Cuckoo Sandbox
Case study: WannaCry
Source: Frank Augstein, Associated Press
Planning for a breach
It's important to prepare a breach ahead of time so that you can properly respond. That means:
- Make backups. You also have to ensure that those backups are secure, since they're a valuable target for attackers.
- Collect logs and other IOCs. Beyond being useful for detection, they're invaluable in determining the extent of a breach.
Recovering from a breach
Once a breach has occurred:
- Assess the damage. Determine what systems have been affected and how severe it is.
- Create a recovery plan. There isn't much use in panicking. You should focus on damage control above all else.
- Verify the integrity of machines and backups. Compromised machines may need to be completely replaced.
- Rotate credentials. People should change their passwords, API tokens, etc.