CompTIA CySA+ Cybersecurity Analyst Certification: Incident Response - Analyzing Potential Indicators Of Compromise

Objective 4.3  Given an incident, analyze potential indicators of compromise

Analyzing Indicators of Compromise
Indicators of compromise (IOCs) are individual pieces of data that indicate that the infrastructure has been attacked or otherwise compromised in some malicious fashion. These indicators could be specific events that are flagged in audit logs, unusual network traffic, permission changes, file integrity changes, or other types of events. Any of these, and many others, could be a clue that something abnormal is going on within the network or on a host.

Rather than arbitrarily look for these indicators, organizations can determine their own IOCs based on historical and trend analysis, threat feeds, and experience. Also, professional and commercial organizations offer libraries of IOCs for organizations to include in their threat management programs. These IOCs can be very generic, such as a simple spike in network traffic, or very specific, such as an IOC for a Windows system indicating that a particular dynamic link library (DLL) has changed in a certain way.
Indicators by themselves don’t necessarily mean the infrastructure has been attacked or compromised; this requires analysis and context. When you observe an indicator, through log file entries or system behaviors, you should attempt to track down the reason for the indicator. Perhaps there is a network performance problem caused, for example, by an equipment malfunction such as a chattering network card. A department may be installing some new software or engaged in a particularly intense business activity that could produce false network or system indicators. These can be tracked down and explained with a little work. The difference between an abnormal event that is innocuous and a true indicator of compromise is context.

A cybersecurity analyst must ask questions such as the following:
- What could be the cause of this indicator?
- What changes occurred on the network or even within the business operations that can account for this indicator?
- What other data supports or disproves this is a true IOC?

Unfortunately, once the incident begins, there’s very little time to ask these questions and get conclusive answers. We have to balance between a thorough analysis and a quick response. But throughout every stage of the response, we should be analyzing data so we can learn more about the incident, its true cause, and its true nature. We may get three or four hours into a response only to discover it was a false alarm. And truthfully, that’s a much better alternative than discovering that we have a serious problem on our hands.
One key point that must be emphasized: if you do not monitor and audit your infrastructure, there will be no indicators of any type of compromise, because you won’t see them. Indicators are like warning signs or malware signatures—to see them, you have to already have an idea of what you’re looking for and be looking for them. Only those indicators you are actively monitoring for or auditing in your log files will show up. As you observe other new indicators, you should fine-tune your monitoring and auditing efforts to alert for those as well.
For the most part, we will examine indicators of compromise in this module that are fairly common and should be included in any organization’s IOC library. We will discuss three key categories: network-related IOCs, host-related IOCs, and application-related IOCs. While we can’t possibly cover every potential IOC for all operating systems and applications, the ones we will cover are both critical to detecting a potential incident and important to know for the CySA+ certification exam.

Note: You must first develop your library of indicators of compromise and then set your monitoring of auditing evidence to detect those indicators.

Network-Related IOCs
Any potential clues that a system or infrastructure has been attacked or compromised in some way will likely show up as part of a network IOC. This might be unusual bandwidth usage, intermittent beaconing from a host, unusual or irregular communications between two hosts on a network, the presence of unknown network devices, and possibly network scans from an unknown host. Network IOCs can also present themselves as strange spikes in network traffic or traffic using unusual ports and protocols. In any case, these are IOCs any organization should look for by including them in their intrusion detection signatures, firewall rulesets, and security information and event management (SIEM) analysis.

Bandwidth Consumption
If an organization has done its job and developed a baseline for system and network performance, then any host that uses bandwidth outside of its normal usage should be noticed. Bandwidth consumption should be one of those performance indicators that is monitored and analyzed on both host-based performance utilities and as part of aggregated usage that is fed to and monitored by a SIEM system. During the normal course of business operations, hosts may occasionally send out or receive more data than normal; there could be a spike in usage or increased activity during certain business operations such as the end-of-year processing. These can be expected and accounted for. But when hosts use bandwidth outside of their normal baseline, for other extended periods or during unusual hours or activities, this is something to pay attention to.

Bandwidth consumption IOCs could include the following:
- Specific hosts that use excessive bandwidth beyond the norm on an irregular but frequent basis
- Excessive bandwidth usage after normal business hours of operation
- Short but large bursts of bandwidth usage

Beaconing
Beaconing is an indicator of compromise that’s pretty cut and dry. If we discover that a host is sending out regular traffic (or irregular traffic, for that matter) to an external host for no good reason, there’s a good bet we’ve been compromised by a botnet of some sort. The problem is discovering a beacon that may be hidden in innocuous traffic, such as HTTP traffic. We need to look at the traffic flow between the host and the destination to determine what kind of traffic it is, what port and protocol it uses, its regularity, the amount of data sent and received, and why the traffic is being sent at all. Some internal applications routinely send and receive traffic to external sites for license updates, automated patching, and so on. These need to be recorded as part of the baseline so they can be eliminated quickly when investigating potential beaconing traffic. It may be necessary to put a traffic sniffer on the wire to intercept traffic from the host and capture it for further analysis. In the end, it also may be necessary to isolate or remove the host from the network and sever its connection to the external command-and-control server it is contacting.

Irregular Peer-to-Peer Communications
Depending on how your network is constructed, larger networks probably use Active Directory or another Lightweight Directory Access Protocol (LDAP) structure. This enables file sharing and other services from a client/server perspective. This typically cuts down on the necessity for host-to-host communications. There may be occasionally a need for one host to contact another; for example, local file shares might be a reason, although that should be highly discouraged on a large network. On small networks, this may be more commonplace. Again, you should track down and determine why the two hosts are communicating with each other. Try to determine if there is a common application on both of them that needs to communicate, if there are any legitimate file shares that should be accessed between hosts, or if there is any other good reason for them to communicate. If you can’t find a good reason that is recorded as part of the system baseline, then you may have to assume that there is an attempt to establish lateral movement by an attacker from one host to another. This also may be part of an automated bot system trying to establish lateral movement across the network. In either case, your best choice is to isolate the hosts, thus preventing their communications, and investigate the matter further.

Rogue Network Devices
Any unidentified or non-approved device connected to the network should also be an obvious indicator of compromise. Rogue network devices could take the form of unauthorized wireless devices that an attacker has inserted into the legitimate wireless network, or possibly a wired device that has been plugged into an open switch port by some malicious person. The indicators for such a scenario might be traffic from a previously unknown or unrecognized device. Unfortunately, the traffic may be lost in the general noise of the network, so this can be difficult to detect. If the organization has a very good inventory that it keeps up to date for all devices attaching to the network, as well as a network access control (NAC) solution, this should make it more difficult for a rogue device to connect to the network. Additionally, if devices must authenticate to the network to send and receive network traffic, such as authentication through Active Directory or an 802.1x protocol, this should also make it difficult for a rogue device to connect and communicate with the network.

Scans and Sweeps
Network scans and ping sweeps against a large organization by an external unknown entity are commonplace every day. Most of these are automated scans from a variety of actors—some of them malicious. Some scans are a prelude to a further attack, but for the most part, if your defenses are solid and multilayered, these scans are harmless. However, repeated scans of the same sort from the same origin are something that could be an indicator that an attack is imminent.

Unusual Traffic Spikes
In a well-run infrastructure, the organization knows what’s going on in its network. Cybersecurity and IT personnel record and document baseline host configurations, device configurations, and, of critical importance, network traffic.

Baselining network traffic means that analysts have recorded traffic throughout a variety of conditions:
- Time of day, day of the week, and so on
- Business process events (such as financial closeouts)
- Based on applications, such as those that might use higher-than-normal bandwidth at predictable times

A normal baseline is created by simply observing network traffic over time, during specific events, and taking into account routine consistent (and perhaps inconsistent or infrequent) types of traffic. As long as traffic can be explained, in the right context, it should be considered part of the baseline. All this is aggregated and analyzed to determine what “normal” traffic looks like.

Ideally, firewall rules have been created to allow permissible traffic and to deny traffic that is not part of the normal baseline. The same goes for intrusion detection signatures. SIEM systems have well-developed rulesets, queries, and analysis parameters so they can key in on all of this traffic and take into account what is part of the normal baseline. They should also be able to alert when unusual traffic happens.

Unusual traffic spikes could take many different forms:
- Spikes in the amount of traffic that a particular host sends or receives
- Spikes in the usage of a particular protocol or port
- Spikes in traffic originating from or going to a specific destination
- Increases in a particular file type or content of traffic

Any of these conditions is likely an indicator of compromise and should trigger alerts because the traffic is not normal on the network. In a well-managed infrastructure, these items will be brought to the attention of cybersecurity analysts through IDS alerts, SIEM analysis, log files, and other means.

Common Protocols over Nonstandard Ports
Closely related to spikes in network traffic would be spikes in unusual traffic over common ports, or common traffic over unusual ports. Either should indicate something abnormal and outside of the baseline. Seeing HTTP traffic over port 8080 might not necessarily be an unusual instance if a server has been configured to receive traffic over that port. That’s why it’s imperative that cybersecurity analysts record configuration settings for all devices, including those that may routinely send and receive traffic over unusual ports. Many organizations use nonstandard ports as a form of obfuscation—that is, “security through obscurity”—in the hopes that it will be less easily detected by attackers. A simple port scan would probably render this tactic useless, but there may still be merit to it, in that tactics like this would likely prevent an average user from accidentally finding an internal web server. As a general rule, however, organizations should probably stick to sending and receiving traffic over common ports, both for standardization purposes and to make it easier to troubleshoot and manage traffic.
As a baseline configuration, the organization should record ports and protocols used across the infrastructure. These can also be programmed into rulesets and signatures for all network security devices. This makes it easier for those devices to do their jobs when unusual traffic over a particular port or protocol is detected.

Exam tip: Remember that network IOCs include excessive bandwidth consumption or use, beginning from one host to another, unusual or unapproved peer-to-peer traffic, any rogue devices you discover on the network, network scans, any type of unusual traffic increases, and unusual port and protocol usage. Only by baselining your system will you be able to see any of these unusual occurrences.

Host-Related IOCs
Indicators of compromise are also found on hosts. When you detect them on a network, you should immediately start looking at your endpoints. If the organization has been proactive with endpoint protection and monitoring, you should get a wealth of information regarding indicators that there is a malicious event going on.

The keys to host-based monitoring include the following:
- Host-based IDS installed on all hosts
- Detailed logging with a centralized log collector
- Host logs and other information sent to a SIEM system
- Installed security agents for antimalware, vulnerability scanning, and so on

The information you get from the host that can indicate a malicious event includes information about processor utilization, hard disk or other media utilization, network bandwidth usage, security configuration, processes, any privileges on the host, and any potentially unauthorized software in use on the host. We’ll discuss each of these indicators, and others, in the following sections.

Processor Consumption
High processor utilization is one indicator of a problem on a host. It might not necessarily be malicious; it could indicate a hardware issue with the motherboard or CPU, or it could indicate a performance problem with a badly written application. However, it can also indicate that the host has been compromised by a malicious program or entity. Malicious programs can create processor utilization issues during their efforts to exfiltrate large amounts of data from the system, communicate with a botnet or a command-and-control host on the Internet, or disrupt the system in a denial-of-service attack.
As with all other things, if you have properly baselined your system and are aware of what should be considered “normal” performance, detecting excessive processor utilization shouldn’t be difficult. You can configure alerts on the system to notify the administrator when processor utilization gets too high. When you discover high processor use, you should try to determine what the issue is before you assume it’s malicious. Again, more often than not it is a hardware fault or a badly written piece of software. Usually, through process and performance monitoring utilities, you can figure out which process is causing CPU utilization to spike. Then you would track down what this process is, what spawned it, and whether or not it could be malicious. We discuss malicious processes a bit later in the module.

Memory Consumption
Memory, as a resource, is subject to the same utilization issues as central processing units (CPUs). Excessive memory utilization can be caused by several factors. Hardware issues such as a bad memory chip or stick can cause problems since the system can no longer use that particular piece of hardware. Poorly written programs can access memory in inefficient and troublesome ways. Even an operating system that is poorly optimized can cause memory utilization issues. On the malicious side, however, memory consumption issues closely mirror CPU utilization issues; high memory usage could be caused by a malicious process that is attempting to exfiltrate data, communicate with an elicit host, or disrupt the system.
Detecting excessive memory usage by a malicious process will usually start with noticing performance hits on the system. The system will bog down, run slow, fail to start applications properly, and have other performance issues. The system may hang or abruptly shut down if memory utilization becomes too high. You may also see an effect called “thrashing,” which means that the system has run out of memory and is trying to write to the paging file on the hard drive more than usual.
Tracking down the reason for memory consumption problems is similar to tracking down CPU utilization issues. You should look for processes that are using excessive memory, particularly for longer periods of time. If you have performance or process monitoring utilities on the system, these are usually good at tracking down processes that may be maliciously using the memory.

Drive Capacity Consumption
Yet another resource that could be the victim of a malicious process or software is media capacity consumption. One common tactic of an attacker’s intent to carry out a denial-of-service attack is to rapidly fill up a hard drive with useless data in an attempt to disrupt or halt a system. Another reason for losing hard drive capacity might be that an attacker is staging data exfiltration by consolidating large amounts of sensitive data from different systems across the network to a single system to make it more efficient to send it out of the network. If you see a hard drive rapidly filling up with compressed or encrypted files, particularly large ones, this could be an indicator that this is happening.
As with other resource consumption, such as CPU and memory use, if you have performance monitoring utilities on your system, they could send you an alert or log an event that the hard drive is losing capacity by filling up with files. Your best course of action is to quickly triage to determine what could be the cause of this event; unlike memory and CPU consumption, however, there are not too many things that could unintentionally cause excessive hard disk space consumption. Almost always this is the direct result of a malicious attack. Balancing the need for collecting forensics evidence with the need to stop the attack, you might be tempted to shut the system down or at least isolate it from the network in case it is the victim of malware that may spread across the network.

Unauthorized Software
Unauthorized software can be an indicator of something bad in a couple of different ways. First, it could indicate that users have too many privileges on the network and can install unauthorized software that is not approved by the organization. This can be detected by routine software inventories and remedied through software restriction policies or application whitelisting. Remember that application whitelisting enables only specific organization-approved software to be installed or run on the organization’s systems. Second, and more sinister, is that it could be malicious binaries or software installed by an attacker. Software of this type usually is harder to detect and may be under the guise of routine programs, such as office productivity software or some other innocuous program. Unauthorized software can even take the form of Trojans or compromised binaries that are part of an authorized software package. This is where antimalware detection for malicious binaries comes in handy, as well as periodic integrity checking of critical binaries and application files. In any event, if you have unauthorized software, either in the form of an unapproved software package or an unknown, unauthorized, and possibly malicious binary, you should take steps to restrict user privileges as well as implement application whitelisting and file integrity checking.

Malicious Processes
Malicious processes are those that run on a system that perform unauthorized, and typically unknown, actions. Examples of malicious processes could be keystroke loggers, e-mail servers, FTP servers, peer-to-peer file-sharing services, and so on. Any of these should be considered dangerous to the organization.
Malicious processes can be difficult to detect; they can be hidden from ordinary view of a process monitor, they could be obfuscated by being named something similar to an authorized process, or they can be hidden, like a Trojan, in a piece of authorized software or binary. System integrity checking is one way to detect compromised system files that may spawn unauthorized processes. Antimalware software is another way to detect those malicious binaries. When monitoring for malicious processes, you should look for those that access files they normally wouldn’t, use administrative privileges that they should not be allowed to use, excessively use CPU, memory, or network bandwidth, and so on. Essentially you are looking for processes that perform actions outside of the system’s normal performance baseline. Process monitoring utilities can look for trends that would indicate a malicious process running, and they help you identify those same processes.

Unauthorized Changes
As a cybersecurity analyst, you already know about the value of change control in an organization. Unauthorized changes can result in damage to systems or breaking the configuration baseline. If your organization has a mature change and configuration management program that works well, detecting unauthorized changes might not be very difficult. If you detect that changes have been performed on a system that aren’t logged or otherwise approved, this could be an indicator of compromise. Since the changes are unauthorized, you likely won’t detect them, however, unless you audit changes to a system’s configuration, critical files, and so on. If something changes on the system, it should be logged as an event, which may then feed into a SIEM system for alerting and analysis. There are also utilities you can install that will periodically check for the integrity of files to see if there have been any unauthorized changes or modifications to those files. This is particularly important for critical operating system files.
If you discover an unauthorized change, you should first look and see if there is any formal log of the change by whoever performed it, and if it was approved by the change control board. If it was an emergency change that was urgently needed before approval, there still should be some type of audit trail for it. These procedures should be built into your change management policies. If there is no explainable reason or context for the change, you start looking at other systems to see if similar changes have been made. You may need to quickly scan for vulnerabilities or malware to see if that could be the cause of the change. If necessary, you may need to isolate the system away from others so that potential malware can’t spread and cause other unauthorized changes.
Some changes may not be because of malware; they may be the result of a malicious insider with elevated privileges. When you discover unauthorized changes, through logs and other means, you should determine the last person who had access to the system, what their level of privileges are on the system, and what they may have changed.

Unauthorized Privileges
Auditing can only tell you about an event once it has already occurred; that is, once it is “past tense.” By this time, the damage may already be done, but at least you will know that someone has performed an illegal or at least questionable action. This is assuming, of course, that your organization audits privileged use of certain objects or certain actions. If you don’t audit these actions, you’ll probably never know whether someone is using unauthorized privileges on your network.
The other method of detecting unauthorized privileges is proactive; it involves periodically going through the properties of objects, usually the more critical ones, such as sensitive files and folders, to determine which user accounts have which permissions to perform certain actions on those objects. You also want to look at security configurations for hosts to determine which accounts have elevated privileges to perform specific actions on each host. This can be a painful aspect of security administration if you are looking at individual objects and hosts, one at a time. But there are utilities, some of them built into systems, such as Active Directory, that can actively monitor for privilege changes or dump an entire list of accounts and privileges in a file for you to examine.
In any case, a serious indicator of compromise is when you find, usually through the logs, that a user account has acquired new privileges or has used privileges that you were not aware they had.

Data Exfiltration
Data exfiltration is a problem itself during an incident, but it can also be an indicator of a bigger problem if you suspect that data is being slowly exfiltrated off of the network because this can indicate that your network has been compromised by an attacker. Data exfiltration can be difficult to detect, unless you have specific measures in place to do so, such as a Data Loss Prevention (DLP) solution, or if you monitor potential indicators of compromise relating to unusual data movement.

Such indicators might include the following:
- Excessive bandwidth consumption from a particular host
- Large files being sent across the network for no explainable reason
- Many files from the same data source, such as those that might be backed up from a particular database
- Compressed or encrypted files being sent across the network for no explainable reason
- Audit logs indicating attempted unauthorized access to sensitive files by persons

These are all indicators that someone could be stealing data through a network connection. However, other indicators could tell you that someone on the inside is stealing data by moving it to unauthorized media, such as removable USB sticks. In this case, you might look for log events that indicate the presence of a USB storage device on a system. In many environments, the use of external media is unauthorized, and USB ports have even been disabled physically or logically on a host. This should be done especially on hosts that process or store sensitive data, such as those in a hospital that might process medical information.

Abnormal OS Process Behaviors
It can be hard to describe or even detect operating system behaviors that are abnormal. Sometimes performance issues can cause an operating system, especially Windows, to behave in strange ways. Normal behaviors could include an abrupt system reboot, system hang-ups, abnormal application closing, applications starting up for no reason, quick screen flashes, and cryptic error messages.

Routinely, most of these behaviors don’t necessarily represent anything malicious going on with the host but could be because of faulty hardware, a bad network connection, or some other explainable reason. Explainable is the keyword here. When you’re investigating abnormal operating system behaviors, you need to look at it in context. What could be causing the behavior? Has the system changed recently? Have there been performance problems that can be attributed to hardware? During routine host issue troubleshooting, you should be able to determine if the behaviors are caused by an explainable reason, or if there is no explanation for the behavior. If there is no good explanation, then you may have to look deeper at the security aspect of the behavior.
As we keep mentioning auditing, you should go back and look at the system logs to see what has been happening with the operating system. Look for activity from unusual accounts. Look for abnormal service or process activity. There many different tools beyond the log files that can also help you. There are real-time process monitoring utilities that can tell you if a process is taking up too much memory, using up too much CPU time, or writing abnormally to the hard disk.
When you can’t explain abnormal system behavior as a performance or hardware issue, start looking for security explanations. Check your antimalware’s event logs to see if it has detected or quarantined any potential malware recently. Make sure your signatures are updated. Look at your event logs for unusual activity. If you can’t determine the cause of the abnormal behavior, collect forensic artifacts from the operating system, such as log files, lists of running processes, and so forth, for further analysis and then think about restoring the system from a backup. If an incident only affects a single host, that may be your best bet. However, if you’re starting to get indicators of compromise such as these from a host, look at other hosts and the overall network as well for other indicators.

File System Changes or Anomalies
It is difficult to change some characteristic of the underlying file system without that event being logged. This is another one of those indicators of compromise that should be fairly easy to detect if you are paying attention to your baseline configuration and you audit changes to the system. File system changes could manifest themselves as changes to the file system itself; for example, changing from FAT32 to NTFS might be one to look at. Changed default file or folder permissions that are given to new objects would also be an indicator that something might be amiss on the system. When a new object is created, you should pay attention to not only its default permissions but default ownership as well. If someone created a folder or file on a file system that was not authorized, it should be logged.
It’s also important to audit what is done to critical files on the system. If you have object auditing turned on, for certain files you may want to have attempted file deletion, file creation, or file change audited. This might prevent someone from making unauthorized changes in a file system.

Registry Changes and Anomalies
Any time-critical system files, such as binaries, dynamic link libraries, configuration files, and, in the case of Windows, the registry, have been changed, that could be a serious indicator of a compromise. Unless someone has a direct reason to edit or change the registry, or if it has been changed through an automated process, such as application installation, this is something you should be concerned about. Remember that the Windows registry is the central storage for all Windows configuration items. It is a hierarchical database that is very complex and very sensitive. Making any unauthorized changes to it or making any mistakes during editing the registry can result in serious system problems that may render the system unusable. Registry changes can be made by malicious entities to cause Windows to boot abnormally, hide malicious software or processes, run malicious binaries on startup, and so many other generally bad actions.
As part of a normal, healthy system backup strategy, the registry on your systems should be backed up on a routine basis. Normally the registry doesn’t change very much, but during some routine events, such as installing an application, it is common practice to back up the registry before and after the change so you can restore it in the event the change causes system problems.
To prevent and detect registry changes, registry files are protected and only authorized for editing by an administrative-level user.

Auditing of registry keys should be standard practice in an organization that is concerned with security. Any unauthorized changes, or any changes at all for that matter, would be detected and logged through auditing. Whenever you see a log entry for a registry change, unless you are sure it came from an authorized action, such as an application change, installation, or deinstallation, or some other good administrative reason, you should consider this an indicator of compromise on the host.

Unauthorized Scheduled Tasks
Automating tasks, especially those that are mundane, tedious, but routine, can save an administrator a lot of time and trouble. This could be a task as simple as copying event logs to a centralized backup location or running an automated script on a system every night. However, a malicious entity could schedule an automated task to run under the elevated privileges of an administrator, without them having to even be logged on to the system at that time. This is a common attack method that an attacker will use just in case they get kicked off of the system and need a script to run at a specific time.
As mentioned repeatedly, auditing is of vital importance to a cybersecurity analyst. If auditing is turned on and configured properly, it should be easy to detect if someone has scheduled automated tasks on the system. There are many different ways to automate a task on a system, including scripting or directly at the command line. There are also many different facilities used to enable automated, scheduled tasks. These include the AT command in Windows and the cron facility in Linux. Regardless of the method used, these events can be logged and reported to system administrators. When you see a scheduled task has been created, you need to investigate whether or not it’s a valid task and determine what it does.

Here are some questions you need to ask:
- Does the task execute a script at a specified time? Does it run a command or series of commands?
- Does the task set up communications with another host?
- Do the logs indicate who created the task?
- What time and date was the task scheduled to run? Is that an unusual time of day for normal operations?

Any of these might be indicators that a malicious user has created a scheduled job that may run under elevated privileges.

Exam tip: Combined with network-related IOCs, host-related IOCs are strong indicators of an attack. They include resource consumption, unauthorized software, abnormal or malicious processes, unauthorized changes, unapproved elevated privileges, unapproved accounts, data exfiltration, unapproved scheduled tasks, and changes to the file system and registry.

Application-Related IOCs
Network and host indicators of compromise are not the only ones you should be paying attention to. Even application software can show indications that a potentially malicious incident is occurring. You must first rule out any unauthorized software or potentially malicious binaries that are on the system. This should be easy for an organization that implements application whitelisting and also scans for changes to an operating system and its binaries. Once a cybersecurity analyst determines that the software on the host is authorized, there’s a possibility that it has been compromised in some way by an attack. Software can show signs of an attack through behaving strangely, throwing errors, and hanging up. But there are other indications that an application has been compromised that you should look for.

Anomalous Activities
What is defined as anomalous depends on the organization’s configuration baseline. As mentioned repeatedly during this module and others, the organization has to baseline everything about the infrastructure, including bandwidth utilization, processor and memory utilization on hosts, patch levels, and many other critical elements on the network, hosts, and even applications. For application baselining, the organization has to determine what “normal” behavior is for an application. This is usually done by observing the application in process—that is to say, how it communicates with other hosts on the network or with a host outside the network, its common error messages, its speed, files it may access, and permissions it may require. As a cybersecurity analyst, once you have baselined your applications, as with networks and hosts, you should be able to determine what is considered “unusual behavior.”

Introduction of New Accounts
So many indicators of compromise require that the organization has done its job in baselining configuration, understanding the traffic flow, and generally knowing what’s going on in its network. The introduction of new accounts as an indicator of compromise is no exception. Unless the organization is auditing the creation of new accounts, their privilege levels, their group membership, and what those accounts are doing in terms of interacting with resources, then the organization likely will have no idea when a new account is added that could indicate a compromise of its network.

That’s one important point about indicators of compromise that you need to understand: without the proper preparation done in advance in terms of auditing, monitoring, baselining, and so on, most of the indicators of compromise we discuss in this module will never be detected.
Assuming the organization has full knowledge of the accounts that are supposed to be on the network and what they are supposed to be used for, any new accounts would be relatively easy to detect and would serve as an early indicator of a potential compromise of the network. Administrative accounts are something to monitor for—particularly their usage or the appearance of a new administrator account. But even new routine, normal user-level accounts should be monitored, because sometimes the first thing an attacker does is attempt to create an account and then later elevate that account’s privileges. Even in an organization that does not have a complex security infrastructure, it’s relatively easy to run a series of scripts every night that list new accounts created during the previous day’s operations. In a more sophisticated network, it’s relatively easy to have mechanisms such as Active Directory log and feed information to a SIEM system so that administrators can be alerted if a new account is created. There’s almost no excuse for this indicator of compromise to go unnoticed.

Unexpected Output
What is unexpected output? It could be the output from an application that looks aberrant or strange, causes system crashes, or produces data that looks suspicious. It could be error messages or unusual events in the audit logs. It also could be unusual network traffic. No matter which form it takes, the unexpected output can be an indicator of a performance issue, an equipment or application malfunction, or even a malicious attack. In any case, unusual output is something that can be tracked using automated means to a certain degree; sometimes you must rely on the observations of users or administrators to notice unusual output from an application or device. Again, this is where baselining your system operations and network traffic comes into play. If you have an idea of what normal is, then detecting what is abnormal is so much easier.

Unexpected Outbound Communications
As with so many other indicators of compromise, unexpected communications from a host that attempts to exit the network to an external destination are relatively easy to detect if the proper processes-detection methods have been put into place first. If you know what normal traffic is supposed to look like, then detecting abnormal traffic can easily be accomplished by configuring rules on intrusion detection systems, proxies, firewalls, and other devices. An organization that has standardized and recorded all the ports and protocols used on the network can exclude those that are not used by denying them in the appropriate rulesets. Not only can attempts at outbound communications be detected, but they can also stopped before they cause harm to the network.

Indicators of unexpected and unauthorized outbound communications include the following:
- Traffic from a host that does not normally communicate outside the network
- Traffic on a port or protocol that is not in use by any standard applications on the network
- Any traffic destined for an unknown IP address outside the network
- Traffic destined for an IP address belonging to the network that may be spoofed; in other words, an IP address belonging to the organization’s range but originating from outside the network perimeter or from a host that has not been recorded as a managed device on the network
- Excessive traffic beyond normal usage to an external point on the network by any host

Any of these can be easily detected and blocked if they are suspected as malicious traffic. Once this type of traffic is detected, it also might be useful to put a sniffer to work capturing the traffic for later analysis so the nature of the traffic can be determined, particularly if you feel you need to capture the traffic as evidence.

Service Interruption
A service interruption as an indicator of compromise could take several different forms. At the host level, it could be a service that is supposed to be running but has been paused, stopped, or keeps restarting. Often attacks on the host will change the start type of the service or stop the service for running.
Beyond the host level, service interruption could mean network-wide services, such as DNS or DHCP services. Services that are used across the network are often targeted by malicious entities in a denial-of-service attack. With appropriate logging and monitoring, service interruptions can be quickly detected and fixed. If the service repeatedly is disrupted or if the logs indicate any strange reasons for the service to be disrupted, you may have an indicator of an attack.

Application Logs
As a cybersecurity analyst, you can’t underestimate the importance of logging. Host logs, security logs, and application logs of the most commonly used logs. Application logs in particular can be an indicator of compromise if an application is producing unexpected output, hangs up, stops abruptly, or otherwise malfunctions. If an attack is far more subtle, application logs can provide traceability of what has happened in the application at its lower levels, such as system calls, resource access, and so on. Application logs can indicate whether or not the application services were successfully started, if someone logged in to the application remotely, or if the application attempted to access a resource that was otherwise not permitted. Application logs, like other sources of information on the infrastructure, can be fed into a SIEM system for aggregation, analysis, and to alert administrators of issues. However, more often than not, application logs are analyzed after the attack has already been detected through another indicator of compromise, as part of an effort to trace the lifecycle of the attack and develop a timeline for it. In any event, application logs can be rich in information as indicators of compromise.

Exam tip: Application-related indicators should cause you to look further into issues on the host and network to discover if you have performance problems or an actual malicious event. They include strange application activities, creation of new accounts, unexpected output or communications with an external host, or service interruptions of any kind. View your application logs regularly to look for indicators of compromise.

REVIEW
Objective 4.3: Given an incident, analyze potential indicators of compromise In this module, we covered the different types of potential indicators of compromise. We looked at three different areas into which indicators can be grouped: network-related IOCs, host-related IOCs, and application-related IOCs. Network-related IOCs include excessive bandwidth consumption, beaconing from a host to external unauthorized systems, peer-to-peer communications that should not be happening, potential rogue network devices, network scans that may be a prelude to an attack, unusual traffic spikes, and common protocols that are communicated over uncommon ports.
Host-related indicators of compromise include excessive resource consumption—CPU, memory, and drive space are all system resources that could be victims of excessive consumption by malicious processes or software. Unauthorized software in the form of non-approved programs that have been installed by ordinary users, malicious binaries, and compromised programs are the concerns here. Malicious processes are a chief cause of many of these IOCs. Unauthorized changes to the system could be in the form of changes to the configuration baseline, installation of unauthorized software, or other changes that could be either malicious or, at a minimum, unauthorized. Privileges should be monitored by the organization to detect unauthorized privilege elevation or use; these instances can frequently be determined by logged events. Data exfiltration is a problem unto itself, but it is also an indicator that the system or the network has been compromised by a malicious entity. Abnormal operating system problems include abrupt system reboots, halts, performance issues, and other issues that can’t be easily explained or diagnosed. These issues may be the result of malware or an active attack. File system and registry changes should be monitored as potential indicators of attacks as well. Finally, any scheduled tasks, created by unknown or unauthorized users, that perform potentially malicious or destructive activities should be watched for and addressed as suspicious.
Application-related indicators of compromise include any anomalous activities by software, any new and unexplained user accounts, unexpected output in the form of error messages, any irregular or unauthorized outbound communications to external hosts, service interruption issues that might include sudden starting or stopping of services, and, of course, events that are logged as a matter of regular auditing in application logs.