CS 3710: Intro to Cybersecurity (slides): Security monitoring

# 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

</div>
<div class="fragment fade-in-then-semi-out" data-fragment-index=0>

- Malware installed on your machine communicating back to a ransomware operator

</div>
<div class="fragment" data-fragment-index=1>

- An attempt to exploit a remote code execution vulnerability in a web server
  that you're running

</div>

---

## Security monitoring and detection

We've already seen a few of these ideas in Labs 5 and 6!

</figcaption>
</figure>

---

## Security monitoring and detection

*Source: Nextron Systems / Florian Roth*

</figcaption>
</figure>

---

## 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?

</div>
<div class="fragment fade-in-then-semi-out" data-fragment-index=0>

- How do we filter data? How do we avoid false positives?

</div>
<div class="fragment fade-in" data-fragment-index=1>

- How do we scale this up to thousands (or even millions) of machines?

</div>

===

## Indicators of compromise

---

## Indicators of compromise

An _**indicator of compromise (IOC)**_ is any data point that might suggest that
a machine has been breached.

</div>
<div class="fragment fade-in-then-semi-out" data-fragment-index=0>

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.

</div>
<div class="fragment" data-fragment-index=1>

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.

</div>

---

## 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.

</div>
  <div class="col">

</figcaption>
</figure>

</div>
</div>

---

## Application logs

_**Example:**_ the figure below shows Apache HTTP server's access logs after
running an nmap scan (with `-A`) against the server:

</figcaption>
</figure>

---

## Application logs

Most programming languages have some kind of logging facilities (either
built-in, or in a popular library):

```python
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())
  ...
```

</div>
<div class="fragment" data-fragment-index=0>

Outside of security, you typically want some kind of logging for performance
metrics, detecting outages, debugging, and more.

</div>

---

## Authentication activity

IOCs may also come from _**authentication activity**_ -- records of who's trying
to log in, when, and from where.

</figcaption>
</figure>

---

## 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.

</div>
  <div class="col">

</figcaption>
</figure>

</div>
</div>

---

## 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.

</figcaption>
</figure>

---

## 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](https://support.sophos.com/support/s/article/KB-000038882?language=en_US)*

</figcaption>
</figure>

</div>
  <div class="col">

_**Sysmon**_ is a Windows system service and driver that records system
activity to the Windows event log.

</div>
</div>

notes:

SwiftOnSecurity's sysmon config: https://github.com/SwiftOnSecurity/sysmon-config

---

## System auditing: auditd (Linux)

On Linux, the _**audit framework**_ provides facilities for monitoring system
events.

*Source:
[RedHat](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security_guide/chap-system_auditing)*

</figcaption>
</figure>

---

## 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`:

<pre style="width: 100%;">
  <code class="bash" data-trim data-line-numbers="" style="width: 100%;">
# -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
  </code>
</pre>

Detect different types of file accesses

</div>

</div>
  <div class="fragment fade-in-then-out" data-fragment-index=0>

<pre style="width: 100%;">
  <code class="bash" data-trim data-line-numbers="" style="width: 100%;">
# -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
  </code>
</pre>

Detect individual syscalls

</div>

</div>
  <div class="fragment" data-fragment-index=1>

<pre style="width: 100%;">
  <code class="bash" data-trim data-line-numbers="" style="width: 100%;">
# 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
  </code>
</pre>
<div class="text-center">

Log "permission denied" events for specific users

</div>
</div>

---

## After a breach: forensic analysis

<div class="container container-center">
  <div class="col">
 
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.

</div>
  <div class="col">

</figcaption>
</figure>

</div>
</div>

===

## 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.

</figcaption>
</figure>

</div>
  <div class="col image-background">

</figcaption>
</figure>

</div>
  <div class="col">

</figcaption>
</figure>

</div>
</div>

---

## 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.

</figcaption>
</figure>

---

## 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

</div>
<div class="fragment fade-in-then-semi-out" data-fragment-index=0>

- _**Netflows:**_ look at network traffic run YARA rules against them to
  identify C2 (command-and-control) patterns.

</div>
<div class="fragment fade-in-then-semi-out" data-fragment-index=1>

- _**Logs:**_ create rules to identify exploitation attempts from logs.

</div>
<div class="fragment fade-in" data-fragment-index=2>

- _**RAM:**_ dump the RAM of a machine and see whether there's any evidence that
  there is malware in machine memory.

</div>

---

## YARA

<pre style="width: 100%;">
  <code class="bash" data-trim data-line-numbers="|5-7|7,9-10"
    style="width: 100%;" data-fragment-index=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
}
  </code>
</pre>

YARA rule for checking whether a file is an ELF (Executable and Linkable Format)
file

</div>
  <div class="fragment fade-in-then-out" data-fragment-index=0>

The `strings` section typically contains various strings / byte sequences that
appear in the malware

</div>
  <div class="fragment fade-in-then-out" data-fragment-index=1>

The `condition` section determines whether or not the file matches the rule.

</div>
</div>

---

## 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
}
```

notes:

`fullword` keyword checks that the string is delimited by non-alphanumeric
characters

---

## 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](https://media.defense.gov/2020/Aug/13/2002476465/-1/-1/0/CSA_DROVORUB_RUSSIAN_GRU_MALWARE_AUG_2020.PDF)*

</div>

---

## 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](https://github.com/Neo23x0/signature-base/blob/master/yara/expl_log4j_cve_2021_44228.yar)*

</div>

---

## 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

</div>
<div class="fragment fade-in-then-semi-out" data-fragment-index=0>

- Run the malware in a sandbox and record a trace of its execution

</div>
<div class="fragment fade-in-then-semi-out" data-fragment-index=1>

- Automated tooling like YarGen

</div>
<div class="fragment fade-in" data-fragment-index=2>

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.

</div>

===

## 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.

</div>
<div class="fragment fade-in-then-semi-out" data-fragment-index=0>

- Compliance with regulations

</div>
<div class="fragment fade-in-then-semi-out" data-fragment-index=1>

- Figuring out the attack vector and tools used by the attackers

</div>
<div class="fragment fade-in-then-semi-out" data-fragment-index=2>

- Determining whether you're still breached (!)

</div>

---

## Trust and safety

As engineers, you have a moral obligation to protect the people who depend on
your services.

</figcaption>
</figure>

notes:

DigiNotar on Wikipedia: https://en.wikipedia.org/wiki/DigiNotar

---

## Trust and safety

</figcaption>
</figure>

</figcaption>
</figure>

---

## Legal responsibilities

</figcaption>
</figure>

</div>
  <div class="col">

Depending on what state or country it's in, an organization will typically have
a legal responsibility to report data breaches to regulators.

</div>
</div>

notes:

H1290:

https://lis.virginia.gov/cgi-bin/legp604.exe?221+ful+CHAP0626

---

## 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

</div>
  <div class="col">

</figcaption>
</figure>

</div>
</div>

---

## 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.

</div>
<div class="fragment" data-fragment-index=0>

_**Malware analysis**_ is the practice of analyzing these artifacts.

Malware analysis is traditionally broken into two categories: _**static
analysis**_ and _**dynamic analysis**_.

</div>

---

## 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.

</div>

*Source: [NSA / Ghidra](https://ghidra-sre.org/)*

</figcaption>
</figure>

</div>

---

## 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*

</figcaption>
</figure>

notes:

https://cuckoosandbox.org/

---

## Case study: WannaCry

*Source: Frank Augstein, Associated Press*

</figcaption>
</figure>

notes:

Marcus's writeup: https://www.malwaretech.com/2017/05/how-to-accidentally-stop-a-global-cyber-attacks.html

---

## 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.

</div>
<div class="fragment" data-fragment-index=0>

- _**Collect logs and other IOCs**_. Beyond being useful for detection, they're
  invaluable in determining the extent of a breach.

</div>

---

## Recovering from a breach

Once a breach has occurred:

- _**Assess the damage**_. Determine what systems have been affected and how
  severe it is.

</div>
<div class="fragment fade-in-then-semi-out" data-fragment-index=0>

- _**Create a recovery plan**_. There isn't much use in panicking. You should
  focus on damage control above all else.

</div>
<div class="fragment fade-in-then-semi-out" data-fragment-index=1>

- _**Verify the integrity of machines and backups**_. Compromised machines may
  need to be completely replaced.

</div>
<div class="fragment" data-fragment-index=2>

- _**Rotate credentials**_. People should change their passwords, API tokens,
  etc.

</div>