Chapter 10
Security Operations and Monitoring

---

THE COMPTIA CYBERSECURITY ANALYST (CYSA+) EXAM OBJECTIVES COVERED IN THIS CHAPTER INCLUDE:

• Domain 3.0: Security Operations and Monitoring
  • 3.1: Given a scenario, analyze data as part of security monitoring activities.
  • 3.4: Compare and contrast automation concepts and technologies.

---

Monitoring systems, devices, and events throughout an organization can be a monumental task. Endpoint devices, servers, applications, and almost every other connected devices in your organization can, and likely do, log what happens on them and to them. Those logs can be an invaluable resource for security analysts, allowing detection of misuse and compromise, but they can also bury important information in mountains of operational data.

Learning how to analyze data from the many sources is a critical part of being a security analyst. Techniques like email header analysis, rule writing for event management systems, and basic scripting and query writing techniques should all be part of your toolkit.

In this chapter, you will explore how security monitoring data is captured and analyzed. You will learn the details of how endpoint and network monitoring techniques and technologies are applied as well as some of the artifacts that security analysts commonly look for. Along the way, you will explore logging tools, how to access common logs on Windows and Linux systems, and the log review concepts that are used to analyze firewall, IDS/IPS, system, and event logs.

Security Monitoring

The foundation of most security designs relies on the concept of defense-in-depth. In other words, a single defensive measure should not be the only control preventing an attacker (or a mistake!) from creating a problem. Since there are many potential ways for a security breach to occur, a wide range of defenses must be layered together to ensure that a failure in one does not endanger sensitive data, systems, or networks.

Analyzing Security Data

Organizations can end up with a massive volume of security data from monitoring and logging various systems and services. Security analysts are often asked to help analyze that data to identify security issues and to respond to security events.

This means that analysts need to know how to quickly assess the organizational impact of an event and must be able to determine if the event is localized or if it has a broader scope. Analyzing the impact of an event requires the following:

• Knowing if other events are correlated with the initial event
• Understanding what systems, users, services, or other assets were involved or impacted
• Data classification for any data assets that are part of the event
• Other information that may influence organizational decisions about the event

Analyzing data will also require the ability to sort through it, either using a security information and event management (SIEM) tool, through logging and aggregation technologies like Splunk or an ELK (Elasticsearch, Logstash, and Kibana) stack implementation, or using more manual techniques.

In addition to assessing organizational impact versus localized impact, analysts must determine what the immediate impact of an event or incident is versus the total impact. A single incident may result in little or no harm, but it may also be a sign of a larger compromise or a broad scale attack against an organization.

Understanding what is occurring across an organization may involve trend analysis techniques that help analysts see changes from a baseline or normal levels for events. They can also help analysts compare events against industry norms or historic patterns.

Logs

Applications, services, systems, and many other assets in your organization's infrastructure will either generate logs or will have the ability to generate logs if you configure them properly. The sheer volume of logs and logging sources can quickly become overwhelming, and finding meaningful data in logs from even a small organization may feel impossible.

Security analysts need to know what logs exist by default on systems, how to access them, how to find information about the content of those logs, and how to interpret that content. In addition, you need to understand how the organization uses logs, whether those logs are properly secured, and what gaps exist in log collecting and analysis infrastructure.

---

Exam Note

The CySA+ exam objectives list a few specific items for log review: event logs, syslog, firewall logs, web application firewall (WAF) logs, proxy logs, and intrusion detection and prevention system logs. We will discuss the basics of each of those types of logs in this chapter. If you haven't encountered an example of one or more of these types of logs, you may want to dig a little deeper outside of this book to familiarize yourself with that type of log data and the specifics of how to analyze it.

---

Event Logs

The Windows event log can be viewed directly on workstations using the Event Viewer from the Start menu. By default, Windows includes Application, Security, Setup, and System logs, which can all be useful for analysts. In Figure 10.1, you can see an example of the Application log showing installer events. Tracking when a specific package was installed and by whom is a common part of many investigations into malware events and other forensic or incident response processes.

FIGURE 10.1 Windows Event Viewer entries

Event Viewer also works for Active Directory logs, although you'll quickly find that even a moderately sized domain can generate more logs than you may want to directly view in Event Viewer. Exporting your logs to a purpose-built log aggregation and analysis system can be an attractive option.

Syslog

Linux maintains information about the state of the system, events, and many other details, typically in the /var/log directory. Additional logs may be in application-specific directories, or other locations on the system based on specific configurations or application and service defaults.

Figure 10.2 shows the auth.log file on an Ubuntu server with a variety of sudo events that occurred. Searching for known events that include the use of administrative privileges is a common part of incident investigations.

Security Device Logs

Security devices capture information about security events, system events, and other details that can be useful to security analysts. While most devices are capable of sending syslog compatible messages, what those messages contain and the way they are formatted can vary significantly from vendor to vendor.

---

Exam Note

The CySA+ exam is vendor neutral, which means you're not expected to be an expert in any specific vendor's log format, messages, or error codes. That also means that you need to understand how to read log entries without knowing the specifics of the log format. Here, we focus on log entry concepts and provide a handful of examples for you to review. If you find these challenging, you should spend some additional time with logs from sources you're not familiar with so that reading new types of logs becomes more natural to you.

---

FIGURE 10.2 Linux syslog entries in auth.log with sudo events

Regardless of the type of log that you are reviewing, you should bear in mind what type of event you are looking for and what identifiers appear in it that match the event or entry that you're searching for. In many cases, you should look for related entries based on what you find in your initial search. For example, if you're looking for blocked traffic to a host with IP address 10.1.10.4, you may also want to look at other entries for that host, and you may choose to broaden your search to search for all entries for 10.1.10.4.

Similarly, if you were looking at blocked traffic and found that a host at 192.168.1.172 was sending traffic to 10.1.10.4, and that you saw hundreds of attempts on different ports, all of which were blocked, you might then search the logs to see if 192.168.1.172 was port-scanning your entire network.

Firewall Logs

Although there are many types of firewall logs, most have some similarities. They typically identify the source and destination IP address, the port and protocol, and what action was taken on the traffic. They may also include data like the role that was matched, if there is a specific threat identifier associated with a block, which interface or port the traffic entered or exited the firewall on, and details of how much traffic was sent.

In Figure 10.3, you can see an example of firewall entries for the Ubuntu UFW firewall. Note that the entries show the source and destination hosts, and that the service that was being accessed was on port 22. In this case, the firewall was blocking access to the OpenSSH service, and a client was retrying access until it failed.

FIGURE 10.3 UFW blocked connection firewall log entry examples

WAF Logs

Web application firewalls are a specialized type of firewall that operates at the application layer to filter out attacks against web applications. Many WAF systems have default rulesets that look for attacks that match the OWASP Top 10 (owasp.org/www-project-top-ten/) or other common application security risks, allowing administrators to quickly enable a common ruleset.

Figure 10.4 shows an example of a ModSecurity entry for an OWASP Top 10 match, which found a request for the bash shell (/bin/bash) in the arguments for the request. This type of log entry can help identify active attacks based on content in the logs.

FIGURE 10.4 ModSecurity log entry examples

Proxy Logs

Much like firewall logs, proxy logs can provide useful information about connections and traffic. Proxies are often used to either centralize access traffic or to filter traffic. Thus, proxy logs will contain the source and destination IP address, the source and destination port, the requested resource, the date and time, and often the content type and HTTP referrer as well as details about the content, such as the amount of traffic that was sent.

When analyzing proxy logs, you should look for data such as the following:

• Target host IP, hostname, and what was requested.
• The amount of content requested. This may help indicate a compromise or match a known malicious package.
• The HTTP request method, which can provide details of the query string with GET requests (POST requests carry this in the body of the message, requiring you to read the full payload, which is more complex).
• Unusual user agents and protocol versions, which may be useful for identifying applications, malware, or other targets.

Intrusion Detection System (IDS) and Intrusion Prevention System (IPS) Logs

IDS and IPS systems rely on rules to identify unwanted traffic. That means that when a rule is triggered on an IDS and IPS, the logs will contain information about the rule that was activated and information about the traffic that was captured and analyzed to trigger the rule. Since IDS and IPS systems often analyze the content of packets and look at traffic across multiple packets or entire conversations to perform their functions, more data about what is occurring at the application level is often available. For example, if you are tracking a malware that uses an Internet Relay Chat (IRC)-based command and control network, you could search for rule hits that included a specific channel name or a nickname that was used.

Much like the other logs types we have discussed, finding the first log entry of interest will often lead to other interesting log entries. It helps to annotate the log entries, capturing details about what you need to pursue further and what other searches you should perform with what you know as you proceed through your log review.

Security Information and Event Management Systems

As the number of security appliances, software packages, and services that create security related logs have grown, tools to centralize, correlate, analyze, and alert on items found in those logs have proliferated. Modern security information and event management (SIEM) systems like Splunk, LogRhythm, QRadar, and other tools are a common part of security infrastructures.

Figure 10.5 shows a high-level view of the role of a SIEM system. Note the multiple sources of threat information, including analysts, threat feeds, and vendor-provided information, all of which helps to define the rules applied to the data the SIEM ingests, thus determining what the SIEM will search for. Log data is aggregated and centralized, and once the analysis is complete, alerts and/or active responses are the output of the SIEM device.

Adding additional data sources beyond your own is a form of data enrichment. Other data enrichment techniques include processes that improve or refine your original data. The analysts shown in Figure 10.5 will spend time reviewing data, ensuring that the right data is being logged and that the logs contain all the information needed to address issues they find. Data enrichment activities can also involve pruning or removing raw data, ensuring that resources are not spent on needless information.

Writing rules is a common task for security analysts tasked with managing a SIEM. Rule writing for most SIEM devices focuses on correlation rules, which look at activities or events and then match them to unwanted behaviors. A simple correlation rule may look for failed logins for administrative accounts, whereas a more complex version of the same rule might look for those failures and then a success paired with the use of escalated privileges or data leaving the system.

FIGURE 10.5 SIEM data acquisition, rule creation, and automation

A common example of correlation rules involves use of known-bad Internet protocol (IP) addresses from IP reputation lists with suspected malicious behavior. The high-level description of a rule that uses information from a DNS or IP address blacklist that uses an active response might look like this:

Block traffic from internal hosts if an outbound attempt to connect to 
a known bad IP address is made, then alert the responsible 
administrator or security analyst via a ticket, email, or text message.

When writing SIEM rules, you need to balance the desire to alarm on unexpected or unwanted actions and events and the likelihood of false positives. If you create a rule that creates too many false positives, you will quickly find that the rule is ignored, resulting in events that should have been noticed being missed.

---

Exam Note

The CySA+ exam objectives specifically call out known-bad Internet protocol as an item in this section. That's a bit vague, but you should be aware of IP and domain reputation services as well as manual identification of known-bad IPs and domains. Some organizations also block entire netblocks because of malicious behavior. While this can help, the huge increase in the availability of cloud computing and VPNs means that attackers have a much easier path to getting an IP address that you will be less likely to block.

---

SIEM systems typically provide the ability to create a dashboard, which shows the status of rules, data sources, actions taken, and other critical operational and analytic information that the SIEM provides. If you haven't worked with a SIEM before, you can view them, and in some cases try hands-on online demos, from many of the major SIEM vendors. Simply search for a demo for tools like Splunk, Fortinet's SIEM, or others to give them a try and to see what the dashboards and rules look like. Some vendors also provide trial editions and/or limited-functionality versions that you can set up and use in your home lab.

Security Orchestration, Automation, and Response

Security orchestration, automation, and response (SOAR) is a concept that relies on a stack of security tools to collect data from a variety of security sources and then automatically respond. While SIEM tools include many of these components and capabilities, Gartner coined the term to describe a set of tools that are often put in place to complement SIEM tools. Garner describes SOAR's three major components as

• Threat and Vulnerability Management Components include threat management tools and vulnerability scanners as well as workflow, reporting, and collaboration tools that support them.
• Security Incident Response IR suites that provide the tools to manage incidents from start to finish.
• Security Operations Automation Orchestration and workflow tools fit into this category, as well as reporting, policy, and process management tools.

SOAR systems and services tend to add a layer of workflow management. That means that SOAR deployments may actually ingest SIEM alerts and other data and then apply workflows and automation to them.

SIEM and SOAR tools can be difficult to distinguish from each other, with one current difference being the broader range of tools that SOAR services integrate with. The same vendors who provide SIEM capabilities also provide SOAR systems in many cases with Splunk, Rapid7, and IBM (QRadar) all included. There are differences, however, as ITSM tools like ServiceNow play in the space as well.

As an analyst, you need to know that SOAR services and tools exist and can be leveraged to cover additional elements beyond what traditional SIEM systems have historically handled.

---

Exam Note

SOAR is a relatively new concept, and the technologies and players in the space are changing very quickly. Gartner's 2019 SOAR market report noted that fewer than 5% of organizations used SOAR tools when the report came out. While they predict that 30% of organizations with more than five employees will use SOAR tools by 2022, SOAR is still a very new market. Thus, you’ll most likely need to know the concepts behind SOAR and what it is rather than a specific technical question for the exam.

---

Endpoint Data Analysis

Endpoints of all types are found throughout organizations. From desktops and laptops to mobile devices, IoT (Internet of Things) sensors, and many other types of endpoint devices, all gather data, including logs and other information. Security analysts need to consider what data may exist on an endpoint device, how to access it, whether that data should be sent to a central log collection and analysis point, and what you would do with that data if you need to monitor for security issues or to investigate an incident.

Malware Analysis

Security analysts often encounter malware as part of their practice, whether it is detected by antimalware tools or discovered as part of an incident response process. In-depth malware analysis is a complex skillset, but analysts should know about the approaches that are commonly used to analyze malware. These include reverse engineering, applying heuristic analysis techniques, and using tools to identify malware packages.

Reverse Engineering

Reverse engineering malware requires using tools like disassemblers, debuggers, monitoring tools, unpackers, and code and binary analysis tools to pull apart malware packages to determine what they do, who wrote them, and other details of their functionality and construction. Reverse engineering tends to be a specialized discipline, with generalist security analysts rarely doing more than cursory analysis. You should, however, be aware of the common types of tools used for reverse engineering:

• Debuggers allow you to run programs in a controlled environment, modifying variables and how the program is running, including adding stop points and monitoring what it is doing.
• Disassemblers are used to convert machine code into assembly language, whereas decompilers attempt to convert machine code into a high-level language like C or Java.
• Unpackers and packer identifiers are used to identify what packing and encryption techniques were used to obfuscate a program and then to undo the packing process.
• System monitoring tools are used to monitor impact to a system like changes to the filesystem, registry, or other settings or configuration changes.

---

Since this is a test preparation book, we won't go into great depth on malware reverse engineering techniques and tools. If you'd like to learn about this topic, classes like the SANS FOR610 course and books like Monnappa K. A.'s Learning Malware Analysis (Packt Publishing, 2018) and Michael Sikorski and Andrew Honig's Practical Malware Analysis (No Starch Press, 2012) are good places to learn a lot more.

---

Heuristics

Antimalware tools often use heuristic analysis to analyze suspected malware. They may do things like decompile a binary to see if the code is similar to existing samples, or they may run the program and analyze its behavior while looking for things that malware often does, like modifying the Windows registry or creating hooks to the filesystem to conceal files. This may be done by running the code in a container or in a virtual environment, but in all cases, it relies on heavily instrumenting the environment in which the code is executed to be able to detect changes and actions that the code takes.

Heuristics can be exceptionally valuable because they can detect unknown malware. That advantage comes with a potential downfall, however: heuristic analysis tools can have a hard time separating malware behavior from that of legitimate software. A common example is one antimalware package detecting another antimalware package because of the techniques they use to capture malware behavior!

---

Exam Note

If you're following the CySA+ exam objectives, you may wonder why we put heuristics here instead of under its own heading. In most cases, heuristics are most closely aligned with antimalware activities, where they are used to monitor for malware-like behavior. Heuristic techniques may be used elsewhere, but you're most likely to encounter them in antimalware tools.

---

Tool-Based Analysis

For many analysts, most of your day-to-day malware analysis will be done via submissions to third-party tools like VirusTotal (virustotal.com), VirSCAN (virscan.org), Jotti (virsscan.jotti.com), and others that use multiple antivirus and antimalware engines to test submitted files against known malware profiles and signatures.

Locally installed tools and commercial antivirus and antimalware packages are a common part of the antimalware toolkit for endpoint protection and analysis.

Memory Analysis

Gaining insight into which services and applications are using memory, how much memory they are using, and what else they are connected to can be helpful when gathering information about systems.

For Windows systems, the Resource Monitor (resmon), can be a useful built-in tool. Figure 10.6 shows a typical Resource Monitor window, including applications like Chrome and Discord with their process ID (PID), memory that is being used, and a view of the total memory available to the system itself. The charts at the right also show usage over time, which can help you understand trends or see spikes in usage. Note that Resource Monitor can also show CPU, disk, and network usage, allowing analysts to check multiple data points in one interface.

FIGURE 10.6 The Windows 10 Resource Monitor

Linux and Unix systems provide a number of command-line tools that can also help with memory analysis, including top, which shows processes, their PIDs, the user who is executing the process, and the command executed to start it. That's a lot of useful data when hunting threats, especially if you see a binary running that doesn't make sense for the user who is running it.

The Linux ps command provides information about processes and their CPU and memory utilization. Figure 10.7 shows a typical ps output.

---

In this section we specifically cover operational memory analysis rather than forensic memory analysis. You will find more about memory forensics in Chapter 13, “Performing Forensic Analysis and Techniques.”

---

Antimalware and endpoint security solutions automatically scan memory for artifacts of malicious software and typically monitor memory for behavior that matches typical behavior patterns for malicious activities as well. That means that manual analysis is often reserved for cases where specific information is needed or when troubleshooting is required.

FIGURE 10.7 Linux ps output

System and Application Behavior

Understanding typical system and application behavior helps security professionals compare known-good behavior to suspected malicious or abnormal behavior. Tracking behavior requires a combination of tools that show things like CPU, memory, network, and disk usage as well as logs and real-time analysis tools. In addition to manual review, many tools provide automated capabilities to assess behaviors. Some also provide the ability to use heuristic detection methodologies.

Many heuristic tools start by building a baseline of information of known-good behavior by monitoring normal behaviors over a period of time and then tracking differences from those behaviors. Tools like Amazon's AWS Inspector tool check for expected behaviors and settings and then flag when they aren't correct. This also means that the tool needs to know about the anomalous behavior, or the behavior that doesn't match the normal behavior of the system or network. Much like antivirus systems, anomalous behavior detection systems and tools may rely on heuristics and signature-based detections in addition to using checklists of configuration information and likely problems.

---

If you capture a baseline for your organization, you're likely to be asked, “What if we're already compromised when we run it?” That's a valid question, but in most cases even small-scale malware infections won't invalidate the baseline's overall usefulness. Of course, if you do believe you have significant security breaches in progress, you should capture a baseline only on trusted systems.

---

Knowing which exploit techniques are most commonly used and how to find artifacts of those exploits helps analysts detect compromises. The ATT&CK framework discussed in Chapter 2, “Using Threat Intelligence,” provides a good starting point to better understand the many types of techniques that can be used, ranging from injecting code into Windows dynamic linked libraries (DLLs) to stealing web session cookies. You can read through them along with descriptions at attack.mitre.org.

Detecting these exploit techniques in action requires a combination of active detection tools, logging and analysis, and forensic and incident response tools for those occasions when something gets through your defenses.

Filesystem Monitoring

Monitoring filesystems can help detect unauthorized or unexpected changes. Tools like Tripwire, OSSEC, and commercial host intrusion detection system (HIDS) tools are used to monitor and report on filesystem changes. Some tools can actively capture changes and either provide the ability to roll back the changes that were made at will or prevent them from happening.

User and Entity Behavior Analytics

User and entity behavior analytics (UEBA) is a type of tool that is used to analyze normal user behavior and to detect anomalous behavior. It utilizes automated rule creation using machine learning and statistical analysis techniques to perform its detection work, making it a powerful tool. UEBA can be implemented as part of a SIEM or endpoint tool or as a separate application. The key differentiator for UEBA tools is the focus on user and entity behaviors and a focus on anomalous behavior based on previous normal behavior combined with typical indicators of compromise.

Network Data Analysis

Security practitioners need to know how to analyze network traffic, including the contents of packets that are sent, the destinations that traffic is sent to or where traffic is coming from, the overall flow of traffic, and the individual packets and protocols in use. While we can't cover all of those details in a study guide, we can point you to some of the high points for the CySA+ exam.

The first element that the CySA+ exam outline focuses on is URL and domain name analysis. URLs (uniform resource locators) are used to point web browsers and other tools to their destinations. That means that you need to know how to identify suspect URLs and the domains that they may point to.

Manual analysis starts with a review of the URL itself. Does it appear to be a legitimate domain name, or does it have suspect elements like a deceptive hostname or domain name, or an uncommon top-level domain (TLD) that may be easy to confuse with the normal TLD used for a legitimate service?

Google's Safe Browsing tool (safebrowsing.google.com) is one example of a tool that analyzes URLs. It also provides information about malicious content hosted on domains, allowing domain administrators to receive notifications if their domains are hosting malware.

The CySA+ exam outline calls out “dynamically generated algorithms” as a subset of URL and domain name analysis. Sometimes called DGAs (domain generation algorithms), these tools are used as part of malware packages to generate domain names from a known seed. The bot control infrastructure can then dynamically generate domain names knowing that bots will use the same seed to know where to send their traffic.

Threat hunters need access to DNS query logs from the DNS servers in their organization to identify bots acting like this. Feeding DNS query information into a SIEM or other tool that uses IP and domain reputation data as well as correlation capabilities can help to detect behaviors that indicate use of a DGA infrastructure.

In addition to dynamic domain name generation algorithms, techniques that automatically register and deregister DNS entries as part of botnets and other malicious activities are commonly used as part of botnets and control infrastructure and are called fast flux DNS. There are two major models of fast flux DNS:

• Single flux continuously registers addresses as part of the DNS address A record for a DNS entry. When combined with a very short time to live for the records and a round-robin DNS that points to different systems as the record is called, this can help disguise malicious systems.
• Double flux is more complex, although similar. Double flux uses a similar technique to register and deregister DNS servers for the DNS zone, adding another layer of confusion when attempting to pin down malicious systems.

Since many systems will be pointed to over a relatively short period of time for a single DNS entry, fast flux DNS makes it hard to use traditional tools to identify malicious IP addresses and domains.

---

Exam Note

The CySA+ exam outline includes DGAs but doesn't call out fast flux DNS. We've included detail on fast flux because you're likely to encounter it as part of many botnets.

---

Network flows work a lot like telephone records: they capture data about which host talked to which host, via what protocol and which port, and how much data was transferred. Flow analysis can be helpful for detecting abnormal traffic patterns, as well as for providing a high-level overview of where traffic flows within your network.

NetFlow tools like those shown in Figure 10.8 typically allow visualization as well as drill-down detail views of traffic so that you can analyze what is happening on your network. Flow data is typically captured by network devices like switches, routers, and security devices but can also be captured by a wide range of devices if they are configured to do so. If you haven't spent time with flows, companies like SolarWinds provide demo flow analysis environments that you can explore to learn more about flows (oriondemo.solarwinds.com/Orion/SummaryView.aspx?ViewID=1).

FIGURE 10.8 SolarWinds network flow console

Packet and protocol analysis are performed using automated tools like IPS and IDS systems, as well as with manual analysis tools like Wireshark. As a security analyst, you will need to know the basics of using Wireshark or similar packet analyzer tools, as well as common protocols like DHCP, DNS, HTTP, and others.

Figure 10.9 shows some of the deep detail you can obtain using Wireshark. In this case, you can determine the user agent for the device that is browsing a website, what site was browsed, and details of the content. Note that the host is cdn.iphonehacks.com and that the device being used is identified as an iPad running iOS 13.2.2.

FIGURE 10.9 Wireshark packet analysis with packet content detail

Identifying malware on your network through packet and protocol analysis relies on a strong knowledge of what traffic should look like and what behaviors and content are abnormal. Packet lengths, destination IP addresses, ports, and protocols can all provide useful information if you know what you are looking for or what normal and abnormal traffic looks like. Finding malware traffic when you can't see the content of the packets due to encryption can be more challenging. In cases where packets are encrypted, you may have to rely on behavior-based analysis by looking at traffic patterns that are indicative of malware like visiting known-bad sites, sending unexpected traffic on uncommon ports, or other abnormal behaviors.

Although we can't teach you in-depth techniques for malware identification, you can practice using some great resources. Check out www.malware-traffic-analysis.net/, which provides examples and tutorials, including traffic captures that you can work with.

Protecting and Analyzing Email

Email remains a frequent vector for attacks, ranging from phishing attacks to spreading malware as email attachments or via other techniques. Security analysts need to know the basics of email analysis, including how to analyze email headers, how to identify common attack techniques, and the most common security techniques intended to prevent email attacks.

---

Exam Note

The CySA+ exam outline broadly describes a wide range of email protection, anti-spam and anti-phishing techniques, and general email analysis and review skills as “email analysis.” We have broken them down into analysis techniques and email security options.

---

Analyzing Email

Most organizations use automated email analysis as a first line of defense against malicious and spam emails. Automated tools look for indicators like known malicious or spam senders, often using blacklists built using information from around the world. They also scan every email looking for malicious payloads like malware or other unwanted files.

The same tools often perform header analysis and message content analysis. Header analysis looks at the content of the email's header. An example of a header from a spam email is shown in Figure 10.10. Note that the first two lines state that SPF is neutral. Further down we see that a domain notes.langdale.com is mentioned as well as a received from header entry that shows as efianalytics.com. The extensive reply-to list is strange, as is the message ID found later in the email.

FIGURE 10.10 Headers from a phishing email

This email was a very obvious phishing attempt; however, more elaborate and skilled attackers will have fewer obvious issues in both the body of the message and the headers themselves. Legitimate accounts are popular targets of attackers because they can be used to bypass many spam filters and will be more likely to be successful in phishing attacks.

If you're not familiar with the contents of an email header, you can review them at mediatemple.net/community/products/dv/204643950/understanding-an-email-header or https://blog.mailfence.com/email-header/, among many other sites. Email header analysis tools can also be handy, and many sites provide them, including www.whatismyip.com/email-header-analyzer/ and dnschecker.org/email-header-analyzer.php. You won't have access to automated tools like these on the CySA+ exam, so make sure you know how to read a header without help!

It is important for analysts to know that forwarded email messages will not include the original headers. Forwarding an email places the message content into a new mail “envelope,” removing the header information that you may need to investigate it. Most modern email clients do allow users to view headers if desired, but that is normally a manual process and isn't something most users will know how to do without instructions.

---

SPF, which we talk about in a moment, breaks when email is forwarded because the forwarding sender will now be the sender and SPF checks may fail at the new destination.

---

In addition to the information that can be lost when an email is forwarded, automatic email forwarding is a security concern that organizations need to address as well. Automatic forwarding is sometimes used by attackers who have successfully compromised an account to send all the emails received by that account to a destination of their choosing. Even if the account hasn't been compromised, forwarding can cause internal data that your organization doesn't want to leave to be outside your security perimeter.

Email Elements

In addition to the header, a number of elements may be of concern while performing email analysis. The first, and most common, element to review is an embedded link. Embedded links are often used as part of phishing scams because many users do not check where the link leads before clicking on them. Since an embedded link can differ from the text that it is linked to, many users fall for this technique. Even more sophisticated users may fall for URLs that appear to be legitimate at first glance. Fortunately, email security tools can scan for malicious links and will block many, though not all, links like this.

Email signature blocks can be useful to help identify phishing attacks, although more sophisticated attackers will simply clone legitimate signatures. Since email signatures often contain images and embedded links, they may also contain other dangerous elements that tell attackers if an email was opened or may actually be part of the attack.

Digital signatures rely on digital certificates and public key encryption and can help prove that the actual claimed sender was the real sender of the message and that the content of the message was not changed. When an email is digitally signed, a hash is created; then that hash is encrypted with the signer's private key to create the digital signature. The sender's digital certificate and signature are attached to the email. Recipients can then validate the hash against the email they received and can also decrypt the signature using the sender's public key, verifying that it matches. Many email services provide support for digital signatures and tools like S/MIME, but relatively few organizations make broad use of this capability.

Email Attacks

The most common forms of email attacks include phishing, impersonation, and the inclusion of malicious attachments. Phishing attacks focus on attempts to get unsuspecting users to click through to a site where they will provide their username and password, or other techniques that are focused on getting credentials or other information through deception.

Impersonation attacks are increasingly common, and they often include an email purporting to be from a trusted coworker or manager. The recipient is typically asked to perform an action like buying gift cards, changing banking information, or otherwise doing something that will benefit the attacker.

Malware is also spread via email, either as an attachment or via a clickable download link. Although antimalware software can help with this, there is a constant battle between attackers and defenders, and new techniques and tools appear all the time that help attackers get malicious software through the defenses that organizations have put into place.

Email Security Options

In addition to header analysis, additional technologies can be used to help provide greater protection to emails. These include the DomainKeys Identified Mail (DKIM), the Sender Policy Framework (SPF), and Domain-based Message Authentication, Reporting, and Conformance (DMARC).

DKIM allows organizations to add content to messages to identify them as being from their domain. DKIM signs both the body of the message and elements of the header, helping to ensure that the message is actually from the organization it claims to be from. It adds a DKIM-Signature header, which can be checked against the public key that is stored in public DNS entries for DKIM-enabled organizations.

SPF is an email authentication technique that allows organizations to publish a list of their authorized email servers. SPF records are added to the DNS information for your domain, and they specify which systems are allowed to send email from that domain. Systems not listed in SPF will be rejected.

---

SPF records in DNS are limited to 255 characters. This can make it tricky to use SPF for organizations that have a lot of email servers or that work with multiple external senders. In fact, SPF has a number of issues you can run into—you can read more about some of them at www.dmarcanalyzer.com/spf/.

---

DMARC, or Domain-based Message Authentication, Reporting, and Conformance, is a protocol that uses SPF and DKIM to determine if an email message is authentic. Like SPF and DKIM, DMARC records are published in DNS, but unlike DKIM and SPF, DMARC can be used to determine if you should accept a message from a sender. Using DMARC, you can choose to reject or quarantine messages that are not sent by a DMARC-supporting sender. You can read an overview of DMARC at dmarc.org/overview/.

---

If you want to see an example of a DMARC record, you can check out the DMARC information for SendGrid by using a dig command from a Linux command prompt: dig txt_dmarc.sendgrid.net. You should see something that looks like the following graphic.

If you do choose to implement DMARC, you should set it up with the none flag for policies and review your data reports before going further to make sure you won't be inadvertently blocking important email. Although many major email services are already using DMARC, smaller providers and organizations may not be.

---

Scripting, Searching, and Text Manipulation

The ability to write and use basic scripts to search for specific items in logs, as well as to do basic text manipulation and other tasks, is required in many security analyst roles. Python is one of the most popular languages right now, but other languages like Perl and even shell scripting like Bash scripting are still quite common. You should be familiar with a few basic techniques for the CySA+ exam.

Performing string (text) searches with grep is a frequent task for security analysts. You might be able to use the find command inside a graphical text editor, but text output from grep is often fed to other commands or used to quickly find text inside a large file.

A basic grep command calls grep and then provides the text you are searching for and the filename.

grep cysa example.txt

You can search multiple files by separating the filenames with commas, search an entire directory by using a -w flag, and use an asterisk as a wildcard. You can even search for all the lines in a file that don't contain a specific set of text. Table 10.1 lists some commonly used grep flags.

TABLE 10.1 grep flags

grep flag	Function
-c	Counts the number of occurrences
-i	Matches both lower and upper case
-n	Shows the matching line and line number
-v	Shows all lines that do not match the string
-r	Reads all files under each directory recursively
-e	When followed by a pattern, uses the pattern for a search (allows multiple patterns)

Regular expressions are also commonly used in grep searches to match a more flexible set of entries. Using letters between square brackets will match any of a set of characters, whereas an * will match any number occurrences of the previous character. Thus, to match all occurrences of text that matches cysa, cysb, and cysc, you could use the following command:

grep "cys[abc]" example.txt

grep is a powerful tool and is frequently combined with other command-line functions to perform complex searches or to prepare data to feed to other tools.

---

You can find a multitude of grep tutorials online. If you haven't used grep much, or if you're rusty, you may want to take a bit of time to practice. Grab a large file, like the syslog file from a Linux system, find some text, and build a search query for it. Try matching case-sensitive and case-insensitive versions of your query, try it against multiple files, and for the more advanced use cases, you may want to play around with regular expressions.

---

To send data from one command-line tool to another, you can use a pipe, represented by the | symbol. For example, if you grep for a string and know that you will see multiple pages of output and want to paginate the output, you can pipe the output of grep into the more command:

grep cysa example.txt | more

Knowing how to use pipes to combine data from multiple commands is a useful skill for security analysts.

Summary

Security analysts need to know how to analyze the data that security monitoring solutions and systems generate. That means understanding trends and how heuristics (behavior-based) analysis tools work. You also need to understand what you can detect on endpoint systems, networks, and email and how to review the logs that devices and applications generate. Once you know what is going on, you must assess the impact to the organization and what it may mean, both in the moment and in the long term.

Analysts also need skills that enable them to work with large volumes of log data. You should be familiar with the basics of rule writing for SIEM and other devices, configuration of dashboards, and how to write queries using common tools like grep and Bash.

Finally, you should understand the role of automation in log analysis and information gathering activities. Scripting, workflow automation, and other tools play a key role in dealing with the sheer volume of data found in a typical security environment.

Exam Essentials

Know the purpose of security monitoring. Capturing information about what is occurring throughout your organization allows you to identify security issues and to monitor the overall health of your systems and devices. Using behavior, or heuristics-based techniques, can allow organizations to find abnormal activities. Trend analysis uses monitoring data over time to identify directional changes. Data must be captured from endpoints, servers, network equipment, and any other important part of your infrastructure. Complete data can help with a full impact analysis when events do occur, letting you determine whether there is an organizationwide or localized impact, and whether the immediate impact is different from the long-term total impact.

Explain why log review is a critical component of security operations activities. Analyzing event logs, system logs, security device logs, and proxy logs can help you detect exploits, attacks, and compromises, as well as provide the information needed to create new rules and signatures. Centralizing logs to a SIEM or other log aggregation and analysis technology helps provide a broader view of your organization's status and activities and allows for correlation across multiple systems.

Define the purpose of email analysis. Email headers contain useful information that can help prevent phishing and impersonation attacks while also helping to identify where malicious email is coming from. Tools like DKIM, SPF, and DMARC are part of a modern email security infrastructure and help identify trusted senders, systems, and domains. Analysts should be able to use tools to identify malicious email payloads.

Explain why automation and scripting are part of security monitoring and log review. Security analysts need to know the basics of scripting and automation. Searching for text using grep and other text manipulation tools, use of regular expressions, and the ability to pipe data from one command-line tool to another are all useful skills when dealing with large volumes of text data.

Lab Exercises

Activity 10.1: Analyze a Network Capture File

Analyzing malicious network traffic is an important skill for security professionals. You will need Wireshark or a similar network packet analyzer for this exercise. Once you have Wireshark set up, visit www.malware-traffic-analysis.net/ to download a packet capture file.

• Part 1: Select a packet capture

Select and download a packet capture exercise from www.malware-traffic-analysis.net/training-exercises.html and load it into Wireshark. Then review the questions that are matched with the exercise.

• Part 2: Analyze the traffic

Using Wireshark, find as many answers as you can. If you don't know how to find those answers, you may need to start with a tutorial: www.malware-traffic-analysis.net/tutorials/index.html.

• Part 3: Check your answers

Use the provided answers to check your analysis. Did you get everything right? Were there items you did not know how to find or were unable to find? If so, try another exercise!

Activity 10.2: Analyze a Phishing Email

You probably already have great source material for this lab exercise: simply open your email spam folder and find a likely phishing attack email.

• Part 1: Manually analyze an email header

Once you have identified a suspected phishing email, you will need to open the headers for the email. If you're not familiar with the process, most email providers have help available on how to access the headers.

It can help to print the headers out for analysis or to import them into your favorite text editor to allow for markup as you track what you have found.

Review the headers and identify what clues you can find about where it was sent from, who sent it, and what path it traveled before you received it. What red flags stand out, and what would you do to identify future phishing emails based on the header information?

• Part 2: Analyze the email content

Now that you have reviewed the header, you can move on to the body of the email. In this phase, review the content of the message, paying particular attention to common artifacts found in phishing emails. You should look for embedded links and record any deceptive links or embeds. You can also identify typos, poor grammar, and other typical elements of a phishing email.

Once you have identified these components, check the links against a tool like those found at zeltser.com/lookup-malicious-websites/. Is the link or domain a known-bad link?

• Part 3: Use an automated tool

Use one or more automated email header analyzers to review the header from part 1. Note if you identify additional useful data and what that data is.

Many sites are available; you can start with www.whatismyip.com/email-header-analyzer/ or mxtoolbox.com/EmailHeaders.aspx.

Activity 10.3: Security Architecture Terminology

Match each of the following terms to the correct description.

Heuristics	The process of disassembling or decompiling a malware package to understand what it does
DMARC	An email authentication technique that detects forged sender addresses
Reverse engineering	A technology designed to monitor end user behavior to prevent targeted attacks and insider threats
Digital signature	An email authentication, policy, and reporting protocol
UEBA	An email authentication method designed to detect forged sender addresses
DKIM	A means of providing assurance that an email has not been modified and that it was sent by the correct sender that relies on a certificate and public key cryptography
SOAR	A technique used to find previously unknown malware by observing behaviors common to malicious software
SPF	An email authentication method designed to detect forged sender addresses

Review Questions

1. Susan wants to use an email security protocol to determine the authenticity of an email. Which of the following options will ensure that her organization's email server can determine if it should accept email from a sender?
   1. DMARC
   2. SPF
   3. DKIM
   4. POP3
2. Ben wants to reverse-engineer a malware sample. Which of the following tools will allow him to view assembly code for the program if he only has a binary executable?
   1. A debugger
   2. A compiler
   3. grep
   4. A disassembler
3. Angela wants to review the syslog on a Linux system. What directory should she check to find it on most Linux distributions?
   1. /home/log
   2. /var/log
   3. /log
   4. /var/syslog
4. Charles is reviewing flow logs for his organization and notices that traffic has seen a 20 percent increase on the second Thursday of each month, after which the traffic returns to normal. What type of analysis is Charles conducting?
   1. Timeline-based analysis
   2. Threat hunting
   3. Trend analysis
   4. Heuristic analysis
5. Ian wants to view all of the data about current memory consumption on his Linux system but wants to be able to read it one page at a time. Which of the following commands will allow him to do so?
   1. top | more
   2. top | grep
   3. top -p
   4. top - n
6. Ben works with a team that includes a dozen security analysts who all write detection rules for his organization's IPS devices for multiple divisions around the world. What type of system could he implement to ensure that releases follow the proper testing and implementation processes?
   1. A CD pipeline
   2. A SIEM
   3. A workflow orchestration system
   4. A fuzzer
7. Chris is reviewing NetFlow logs while monitoring for systems that are participating in a botnet. Which of the following types of data will he not be able to see in his NetFlow records?
   1. Packet payload
   2. Source IP address
   3. Protocol
   4. Destination IP address
8. Alaina wants to deploy a tool that can monitor the behavior of users while correlating that behavior centrally to determine if a security incident has occurred. What type of tool should she acquire?
   1. A network analyzer
   2. A UEBA tool
   3. Antimalware with heuristics
   4. A DMARC tool
9. Chris wants to decrease the threat of malicious email links in email. What technique can he use to decrease their likelihood of success without having a significant business impact?
   1. Block all links in email
   2. Implement DNS blackholing using a DNS reputation service
   3. Turn on SPF and DKIM for all email
   4. Use a proxy to filter all web traffic from email links
10. Tim has assigned an analyst to add third-party threat data feeds to his organization's SIEM. Once the analyst is done, they will spend time reviewing syslog data feeds to ensure that they contain the information that is needed for responses. What is the analyst doing?
    1. Threat feed grooming
    2. Workflow orchestration
    3. Syslog combing
    4. Data enrichment
11. Michelle is analyzing a Wireshark traffic capture, and follows the TCP stream for a TIFF file download. What concern should she raise from the information displayed in the stream viewer?

    

    1. The file cannot be run in DOS mode.
    2. The file is an executable.
    3. The file was gzipped.
    4. The file is actually a JPEG.
12. Elaine wants to check for user logins on a Linux system. What log location should she check first?
    1. /var/log/syslog
    2. /var/log/auth.log
    3. /var/log/logins
    4. /var/log/messages
13. While analyzing a malware infection, Joseph notes that the malware has encrypted files, thereby preventing the organization's main web application server from serving files. What type of impact has he noted?
    1. Localized, immediate impact
    2. Organizational total impact
    3. Organizational, immediate impact
    4. Localized total impact
14. Ben's organization uses an IP reputation service to block outbound access to all sites that are flagged with a negative reputation score. What issue could this cause?
    1. Customers may be unable to access the organization's website.
    2. Inadvertent blocking of sites due to false positives.
    3. Too many SIEM entries due to blacklisted sites being accessed.
    4. This will not lead to any problems.
15. James wants to monitor a Linux system's filesystem for unauthorized changes. What open source tool can he use to perform this task?
    1. Tripwire
    2. Filemon
    3. Filecatcher
    4. ftracker
16. Charlene executes the following command against the file shown. What entries will it return?

     grep -v error /var/log/boot.log

    1. All lines with the string "error" in them
    2. All lines with successful boot messages
    3. All lines without the string "error" in them
    4. All lines without successful boot messages
17. Megan is trying to prevent impersonation attacks from impacting her company but receives a “No DMARC record found” error when she checks a frequent business partner's DNS information. What do they need to do to enable DMARC?
    1. Publish a SPF record
    2. Publish a DMARC record
    3. Set up DKIM authentication
    4. All of the above
18. While reviewing a Wireshark traffic capture, Mike discovers the following information. What does he know about the user's device based on this TCP stream?

    

    1. The device is an iOS device using Safari.
    2. The device is downloading a file.
    3. The device is a Samsung SM-N950U.
    4. The device is uploading a file.
19. Ian finds entries in /var/log/faillog on a Linux system. What types of events will be in the log file?
    1. Application start failures
    2. System errors resulting in reboots
    3. Failed login attempts
    4. Failed privilege escalation attempts
20. Tony wants to check the digital signature of an email. What key does he need verify that an email is from his friend Mal?
    1. Mal's private key
    2. Tony's private key
    3. Mal's public key
    4. Tony's public key