Analyze Endpoint Monitoring Output

OBJECTIVES COVERED

Given a scenario, analyze data as part of security monitoring activities.

Given a scenario, implement configuration changes to existing controls to improve security.

Network-based monitoring systems can be supplemented with host-based monitoring. While host-based detection methods can also rely on signature-based matching, behavioral analytics is increasingly important to cybersecurity. As an analyst, you must be able to use tools to identify behavioral anomalies, and identify the techniques used by malware code to achieve privileges and persistence on network hosts.

Analyze endpoint to find the process the attacker is using, such as using Process Explorer for Windows.

Look for reverse shell, or some type of command/terminal open that is not properly attached to a session, goofy indicators of compromise.

Example of a reverse shell shown in the Properties window.

Registry changes from an Eternal Blue attack.

ENDPOINT DATA COLLECTION AND ANALYTICS TOOLS

There have been many iterations of host-based or endpoint protection mechanisms. It is important to consider the contrasting functions performed, as individual software tools or protection suites often combine multiple functionality.

Antivirus (A-V)

The first generation of anti-virus (A-V) software is characterized by signature-based detection and prevention of known viruses. Products move quickly to perform generalized malware detection, meaning not just viruses but worms, Trojans, spyware, and so on. While A-V software remains important, it is widely recognized as being insufficient for the prevention of data breaches.

Host-Based Intrusion Detection/Prevention (HIDS/HIPS)

Host-based intrusion detection systems (HIDS), such as OSSEC (ossec.net) or Tripwire (github.com/Tripwire/tripwire-open-source), provide signature-based detection via log and file system monitoring. HIDS come in many different forms with different capabilities, some of them preventative (HIPS). File system integrity monitoring uses signatures to detect whether a managed file image—such as an OS system file, driver, or application executable—has changed. Most HIDS can also analyze system log files. Products may also monitor ports and network interfaces, and process data and logs generated by specific applications, such as HTTP or FTP.

Endpoint Protection Platform (EPP)

Endpoint protection usually depends on an agent running on the local host. If multiple security products install multiple agents (say one for A-V, one for HIDS, another for firewall, and so on), they can impact system performance and cause conflicts, creating numerous technical support incidents and security incident false positives. An endpoint protection platform (EPP) is a single agent performing multiple security tasks, including malware/intrusion detection and prevention, but also other security features, such as a host firewall, web content filtering/secure search and browsing, data loss prevention (DLP) enforcement, and file/message encryption. In an enterprise solution, there will also be a single management dashboard for configuring and monitoring hosts.

Endpoint Detection and Response (EDR)

Where EPP provides mostly signature-based detection and prevention, endpoint detection and response (EDR) is focused on logging of endpoint observables and indicators combined with behavioral- and anomaly-based analysis. The aim is not to prevent initial execution, but to provide real-time and historical visibility into the compromise, contain the malware within a single host, and facilitate remediation of the host to its original state. The term EDR was coined by Gartner security researcher Anton Chuvakin, and Gartner produces annual “Magic Quadrant” reports for both EPP (gartner.com/en/documents/3848470) and EDR functionality within security suites (gartner.com/en/documents/3894086/market-guide-for-endpoint-detection-and-response-solutio).

** Note that managed detection and response (MDR) is a class of hosted security service (digitalguardian.com/blog/what-managed-detection-and-response-definition-benefits-how-choose-vendor-and-more). **

User and Entity Behavior Analytics (UEBA)

A user and entity behavior analytics (UEBA) solution is less an endpoint data collection technology and more of the analysis process supporting identification of malicious behaviors from comparison to a baseline. As the name suggests, the analytics software tracks user account behavior across different devices and cloud services. Entity refers to machine accounts, such as client workstations or virtualized server instances, and to embedded hardware, such as Internet of Things (IoT) devices. The complexity of determining baselines and reducing false positives means that UEBA solutions are heavily dependent on advanced computing techniques, such as artificial intelligence (AI) and machine learning. These analysis resources would be part of the security service provider’s offering. Examples include Microsoft’s Advanced Threat Analytics (docs.microsoft.com/en-us/advanced-threat-analytics/what-is-ata) and Splunk UEBA (splunk.com/en_us/software/user-behavior-analytics.html).

** It is quite likely that a security software solution will combine EPP, EDR, and UEBA functionality. Protection suites with the ability to apply machine analytics, identify asset criticality, and apply some level of automated sandbox containment are often marketed as advanced threat protection (ATP), advanced endpoint protection (AEP), or NextGen AV (NGAV). **

SANDBOXING FOR MALWARE ANALYSIS

The nature of modern malware means that signature-based tools are less likely to automatically block execution. Manual analysis of malware can provide intelligence that identifies wider IoCs, which can inform the development of custom signatures, IDS rules, and behavior-based rulesets for EDR solutions. Malware analysis must take place in a controlled environment to mitigate risks of intrusion and data breach during the analysis process.

Sandboxing is a technique that isolates untrusted data in a closed virtual environment to conduct tests and analyze the data for threats and vulnerabilities. Sandbox environments intentionally limit interfacing with the host environments to maintain the hosts’ integrity. Sandboxes are used for a variety of purposes, including for testing application code during development and analyzing potential malware.

The analysis of files sent to a sandbox can include determining whether the file is malicious, how it might have affected certain systems if run outside of the sandbox, and what dependencies it might have with external files and hosts. Sandboxes offer more than traditional anti-malware solutions because you can apply a variety of different environments to the sandbox instead of just relying on how the malware might exist in your current configuration. To effectively analyze malware, sandboxes should provide the following features:

Monitor any system changes without direct user interaction.
Execute known malware files and monitoring for changes to processes and services.
Monitor network sockets for attempted connections, such as using DNS for Command & Control.
Monitor all system calls and API calls made by programs.
Monitor program instructions between system and API calls.
Take periodic snapshots of the environment.
Record file creation/deletion during the malware’s execution.
Dump the virtual machine’s memory at key points during execution.

The sandbox host that the malware is installed to should be physically or logically isolated from the main network. The host must not be used for any purpose other than malware analysis. This is often achieved using a virtual machine (VM). Some tools, like Cuckoo Sandbox (cuckoosandbox.org), are set up specifically to provide features like these. However, you can also create a sandbox by using virtualization software to create a VM and manually install the analysis tools you think you’ll need. Additional host patch management and network access control precautions must be taken as there are vulnerabilities in hypervisors that can be exploited by malware.

A complex honeypot type of lab might involve the use of multiple machines and Internet access, to study closely how the malware makes use of C&C and the domains or IP addresses it is communicating with. If so, this traffic must be isolated from the main corporate network. Care must be taken to ensure that the lab systems are not used to attack other Internet hosts.

REVERSE ENGINEERING ANALYSIS METHODS AND TOOLS

Reverse engineering is the process of analyzing a system’s or application’s structure to reveal more about how it functions. In the case of malware, being able to examine the code that implements its functionality can provide you with information as to how the malware propagates and what its primary directives are. In addition, like analyzing a person’s handwriting, you may be able to attribute the source of the malware according to how the code is written or the recognizable patterns that its execution follows. Some malware is easier to deconstruct than others. For example, the nature of the class files in the Java programming language allows them to be easily decompiled into source code. Apps written in Java can therefore be reverse engineered with freely available, easy-to-use tools. However, there are automated tools available that can obfuscate the malware’s code before it is assembled or compiled. Obfuscated code is difficult to dissect because it uses convoluted and non-straightforward expressions that are not friendly to human analysis.

Whatever the difficulty may be, reverse engineering of malware is typically done in a sandbox environment where it will have no impact on systems in production. This is especially necessary for malware that can detect when it is being deconstructed by certain software and set off a logic bomb in response.

Disassemblers and Decompilers

Disassemblers and decompilers are software that translate low-level machine language code into higher level code.

Machine code—The binary code executed by the processor, typically represented as 2 hex digits for each byte. Analyzing machine code directly is a specialist skillset, but one piece of information that you should remember is that Windows portable executable (PE) binaries, whether EXE, DLL, SYS, DRV, or COM, start with the hex characters 4D 5A, which can also be represented as the ASCII string MZ, or as TV when encoded as Base64.

** The file signature (or magic number) revealed by the binary header is usually a more reliable means of file typing than the extension applied to the name, which can be changed arbitrarily. You can search file types at a resource such as Wikipedia. It is possible for adversaries to perform anti-forensics and mask the file signature for storage or transmission. The correct header must be present for the code to execute, however. **

Assembly code—A disassembler converts machine code to assembly code. Assembly code is the native processor instructions used to implement the program.
High-level code—Assembly code is also difficult to interpret without specialist skills and experience. Some suites may be able to decompile assembly code to high-level pseudocode. Pseudocode makes it easier to identify individual functions within the process, track the use of variables, and identify branching logic, such as If … Then … Else statements.

One of the leading products is Interactive Disassembler (IDA) (https://hex-rays.com/ida-pro/).

Malware Strings

Other than identifying malware by its hash signature or by disassembling an entire executable, you can also perform static analysis by revealing the malware’s strings. A string is any sequence of encoded characters that appears within the executable file. String analysis can reveal everything from variables the program is using to API calls, and more. These strings may help you identify the nature or function of the malware. For example, if the malware contains a string with a function called InternetOpenUrl and another string that is a URL, you can reasonably conclude that the software attempts to download something from that web address.

Microsoft offers a freeware utility for download called Strings (docs.microsoft.com/en-us/sysinternals/downloads/strings) that dumps all character sequences greater than three characters (by default) that are encoded in either ASCII or Unicode. One downside to the Strings utility is that it will identify sequences of characters that are not actually strings, especially with the default minimum of three characters, so you need to exercise good judgment during your analysis. Unix-like operating systems also come with a command called strings,which has the same basic functionality.

Program Packers

A program packer is a method of compression in which an executable is mostly compressed. The part that isn’t compressed includes code to decompress the executable. This all combines into a single executable that, when run, begins to decompress the entire code before it runs. In this sense, a packed program is a type of self-extracting archive. There are two main advantages to program packing: reducing file size and increasing the difficulty of reverse engineering the file’s contents. Organizations or individuals who share proprietary software may use program packing to deter theft of intellectual property and violations of copyright.

However, this is also something an attacker can use to their advantage. Packing malware makes it more difficult to detect and analyze for many anti-malware solutions. They often compensate by identifying all packed programs as malware, but this complicates the matter with false positives. For a forensics analyst, it may be difficult to accurately mark an executable as a maliciously packed program without considerable effort to reverse engineer it. This is because packed malware, until it’s unpacked, can mask string literals and effectively modify its signatures to avoid triggering signature-based scanners. This can waste the analyst’s time and resources. However, an analyst can work around this by unpacking the executable in a controlled sandbox environment.

MALWARE EXPLOIT TECHNIQUES

An exploit technique describes the specific method by which malware code infects a target host. Legacy virus malware operates by rewriting or modifying the code within an executable or macro-enabled file on the target disk. When the infected file is run, the virus can execute its payload. Worm-like malware is defined by the ability to execute within memory only, such as infecting processes on different hosts over a remote procedure call (RPC) network protocol.

Most modern malware uses similar fileless techniques to avoid detection by signature-based A-V and file integrity monitoring security software. Fileless means that the malware code is executed by a script or small piece of shellcode to create a process in system memory without having to use the local file system; some fileless techniques do depend on dropping the initial script to a temporary directory, though. Modern malware with APT-like capability will complete a typical attack in the following stages:

Dropper/downloader—The first step for malware is to run lightweight shellcode on the victim system. This requires local administrative privileges unless the system is very poorly configured. To obtain administrative privileges, the malware can either exploit an unpatched or unknown vulnerability to execute without authorization or trick or persuade a user into running the code—by concealing it within a Trojan, for example.
Maintain access—The malware will install some type of remote access Trojan (RAT) to give the adversary a C&C mechanism over the victim machine. RATs are commercialized hacking tools. As well as a communications port and reverse shell, RATs may package tools such as key loggers, network scanners, and vulnerability/exploit kits designed to strengthen access. The RAT usually needs to establish some sort of persistence mechanism so that it runs again if the user logs off or the host is restarted.
Strengthen access—The RAT is used to identify and infect other systems, possibly of higher value. For example, on a Windows domain, if the adversary has compromised a workstation, the next step might be to obtain domain administrator privileges and then compromise the permissions on a file server for a different user group.
Actions on objectives—Once the attacker has enough permissions to assets of interest, he or she will use tools to covertly copy or modify the data or target system, depending on his or her motive.
Concealment—An attacker may choose to maintain access but put the tools into a dormant mode to avoid detection or may choose to try to eradicate any sign that the system was ever infected (anti-forensics).

Droppers, Downloaders, and Shellcode

Modern malware is typically introduced by a dropper or downloader application. A dropper will install additional tools from within the initial payload whose code has been obfuscated or encrypted to prevent detection. A downloader-type dropper will connect to the Internet to retrieve additional tools. Fileless droppers are typically delivered as shellcode. Shellcode originally referred to malware code that would give the attacker a shell (command prompt) on the target system. The term shellcode now refers to any lightweight code designed to run an exploit on the target. Shellcode might use any type of code format, from scripting languages to binary code.

Code Injection

Once the shellcode is created as a process on the target system, the dropper will try to run a payload covertly, usually by performing code injection against a valid process. The advantage of compromising a valid process is that the code runs with the permissions and identity of the host process, which can allow it to pass through firewall ACLs to download additional payloads. The following illustrate some common methods of performing code injection:

Masquerading—The dropper replaces a genuine executable with a malicious one.
DLL injection—The dropper forces the process to load a DLL, which can then execute malicious code.
DLL sideloading—The dropper exploits a vulnerability in a legitimate program’s manifest to load a malicious DLL at runtime.
Process hollowing—The dropper starts a process in a suspended state and rewrites the memory locations containing the process code with the malware code.

The dropper is quite likely to implement anti-forensics techniques to frustrate detection and analysis. For example, the malware may check for the presence of security products analysis tools, such as Wireshark, Process Explorer, Process Monitor, or Interactive Disassembler (IDA), and disable them.

Living Off the Land

Living off the land refers to exploit techniques that subvert existing architecture, such as Windows PowerShell, to perform the malicious activity. As the malware code is executed by standard tools and processes it can be harder to detect.

** Study MITRE’s Adversarial Tactics, Techniques & Common Knowledge (ATT&CK) database for more information about exploit techniques. The techniques listed under Initial Access, Execution, and Defensive Evasion are particularly relevant here (attack.mitre.org/techniques/T1036). This Microsoft blog provides a useful overview of fileless techniques (microsoft.com/security/blog/2018/09/27/out-of-sight-but-not-invisible-defeating-fileless-malware-with-behavior-monitoring-amsi-and-next-gen-av). **

KNOWN-GOOD AND ANOMALOUS BEHAVIOR ANALYSIS

Because shellcode is easy to obfuscate, it can often evade signature-based A-V products. Threat hunting and security monitoring must use behavioral-based techniques to identify infections. This means close analysis of the processes running in system memory on a host. To perform process analysis effectively, you should build up a sense of what is “normal” in a system and spot deviations in a potentially infected system. You also need to use appropriate analysis tools. Sysinternals (docs.microsoft.com/en-us/sysinternals) is a suite of tools designed to assist with troubleshooting issues with Windows, and many of the tools are suited to investigating security issues. Developer Mark Russinovich also writes a technical blog (blogs.technet.microsoft.com/markrussinovich) that deals with many common security issues.

When hunting for a malicious process using a tool such as Process Explorer (part of Sysinternals), you need to be able to filter out the legitimate activity—known-good behavior—generated by normal operation of the computer and look for the signs of anomalous behavior that could identify a process as suspicious.

** We are focusing on manual analysis here but do be aware of user and entity behavioral analysis (UEBA) products that can automate this process. These systems use machine learning to identify baseline behavior and anomalous behavior from large datasets. The capabilities of artificial intelligence (AI) and machine learning are discussed later in the course. **

To identify what might be suspicious on a typical Windows host, you must understand how legitimate processes are structured. The following represent the main processes launched by the SYSTEM account:

System Idle (PID 0) and System (PID 4)—Kernel-level binaries. They will generate CPU and network activity. System is the parent for Interrupts and the Windows Session Manager SubSystem (smss.exe). SMSS is the first user-mode process and should only appear as a child of System and launch from %SystemRoot%\System32.
Client Server Runtime SubSystem (csrss.exe)—Manages low-level Windows functions. It is normal for there to be several running (so long as launched from %SystemRoot%\System32) and for them to have no parent.

** CSRSS and WININIT are run by other instances of SMSS, which terminate after loading the child process. **

WININIT (wininit.exe)—Manages drivers and services. There should only be one instance of WININIT.
Services.exe—Hosts nonboot drivers and background services. There should only be one instance of services.exe, running as a child of wininit.exe. Each service process should either appear as a child process of services.exe or as a child process of a svchost.exe wrapper (which should always load from %SystemRoot%\System32). Check running services to ensure that they are digitally signed (show the Verified Signer column and run Options > Verify Image Signatures). Services will be started by the SYSTEM, LOCAL SERVICE, or NETWORK SERVICE accounts.
Local Security Authority SubSystem (lsass.exe)—Handles authentication and authorization. There should only be a single instance, running as a child of wininit.exe.
WINLOGON (winlogon.exe)—Manages access to the user desktop. There will be one instance for each user session. The Desktop Window Manager (dwm.exe) is likely to be a child process in modern versions of Windows.
USERINIT (userinit.exe)—Sets up the shell (typically explorer.exe) and then quits. You should only see this process briefly after log-on.
Explorer (explorer.exe)—This is the typical user shell, launched with the user’s account privileges rather than SYSTEM’s, and is likely to be the parent for processes started by the logged-on user.

Given the potential exploit techniques, to locate a malicious process you may be looking for a process name that you do not recognize, or for a valid process name that is not entirely as it should be in other respects:

Look for unrecognized process names, especially names that mimic a legitimate system process (scvhost for instance) or randomly generated names. You can use the Search Online function to look up known processes.
Look for processes with no icon, version information, description, or company name.
Look for processes that are unsigned—especially a process with a company name like Microsoft Corporation that is also unsigned.

** Do be alert to the possibility that malware may be digitally signed. The malware author might have stolen another developer’s private key, managed to install a root certificate, or compromised a CA’s identity checking processes. Process Explorer includes a function to check that signatures match the publisher identified in the “Company” field and the sigcheck utility (also part of Sysinternals) allows you to verify the certificate chain of a signed file. Also be aware that older software might be unsigned but legitimately installed. **

Examine processes hosted by service host executables (svchost.exe) and other Windows utilities (explorer.exe, notepad.exe, taskmgr.exe, iexplore.exe, and so on). Look closely at processes that do not have a valid parent/child relationship with the principal Windows processes.
Look for processes that have used packing (compression). Packed code might have been obfuscated or encrypted. These are highlighted in purple in Process Explorer.
When you find a suspect process, examine how it is interacting with the Registry and the file system:
How is the process launched? Is the image file located in a system folder or a temp folder?
What files is it manipulating?
If you delete the process, is it restored on reboot? If so, how?
If you cannot delete the process, what system privilege or service is blocking access?
Also identify how the process interacts with the network—which ports is it using? What domains or IP subnets is it contacting?

ANOMALOUS BEHAVIOR ANALYSIS WITH PROCESS EXPLORER

The Sysinternals tool Process Explorer is an enhanced version of Task Manager. You can view extra information about each process and better understand how processes are created in parent/child relationships. Right-click the column headers to view more or fewer fields.

*Viewing an uninfected system in Process Explorer. (Screenshot: Process Explorer* *docs.microsoft.com/en-us/sysinternals*)

For each process, you can view more information about how it is interacting with the system using the lower pane (View > Show Lower Pane or press Ctrl+L). Within the lower pane, you can show either DLLs loaded by the process (Ctrl+D) or handles (Ctrl+H), which are files and eRegistry keys or other resources that the process is interacting with. Right-click a process to show its Properties dialog. The Image tab shows where the process file is launched from plus any command line switches. The Strings tab lists strings found in the code. Network connections are listed on the TCP/IP tab.

Dropper Analysis Example

In this example, the Metasploit Framework is being used to obtain access via a remotely executed PowerShell prompt, with privileges obtained by passing a captured hash. This attack leverages the Sysinternals PsExec utility to drop a service executable into the Admin$ share on the remote machine. In this variant of the attack, the service starts PowerShell. Pointing to the powershell.exe image in Process Explorer shows the parameters that the process launched with. In this case, the command used to start this is not typical of PowerShell usage. There is a long string of characters, which is binary code represented in Base64. The script is injecting this into a new DLL, stored in memory only:

*Staging the psexec_psh (PsExec PowerShell) attack. (Screenshot: Process Explorer* *docs.microsoft.com/en-us/sysinternals*.)

The User Name field reveals that the powershell.exe process is running with the privileges of the local SYSTEM account. This exploits the default behavior of PsExec and services launched from the system root.

** You will not detect droppers in real time, unless you spend all day monitoring Process Explorer. Invoking PowerShell with this type of suspicious parameter should be detected by host-based EDR or a protection suite with behavioral analysis routines. **

Post-exploitation Analysis Example

At this point the attacker has a DLL sitting in the target’s memory that can manipulate files at the same level of privilege as the SYSTEM account and open a reverse shell connection to the attacking host. This communications channel allows the attacker to deliver additional payloads, in this case, run a Meterpreter command shell, use the target’s command interpreter, run a keylogger, and so on.

*Injecting a keylogger into the target. (Screenshot: Armitage running on KALI Linux* *tools.kali.org/exploitation-tools/armitage*)

The screenshot shows output from the keylogger, which has logged the use of the netstat command. The attacker is therefore alerted to the fact that the intrusion might have been detected. This reflects the adversarial nature of cyberattacks. Both attacker and defender need to be able to work through incident response cycles, adjusting their tactics as added information becomes apparent.

Discovering a modern malware process that has managed to execute with administrative privileges is difficult. It is harder for the attacker to conceal network communication though, so if you can trust netstat on the local host (better perhaps to monitor remotely) then look for evidence of the infected PID(s) communicating on the network to its handler. You can pipe the output from netstat to the findstr command to filter the results. For example, the following command searches for connections opened by PID 112120 on the 10.1.0.0 subnet:

netstat /no 30 | findstr "10.1.0 112120"

Filtering netstat output—the first query returns activity by a particular PID on the local subnet; the second returns any activity associated with the IP address identified in the first query. (Screenshot: netstat/Windows used with permission from Microsoft.)

Be aware that this “Reverse TCP” method of communication is less likely to be encountered these days. Handlers are more likely to use reverse HTTPS (port 443) and encrypt the traffic. In terms of remediation, this system needs to be taken offline or at least put under close observation, and we urgently need to go and find out who or what is operating 10.1.0.249.

ANOMALOUS BEHAVIOR ANALYSIS WITH PROCESS MONITOR AND AUTORUNS

While fileless malware does not always depend on the file system to achieve the initial exploitation, it is highly likely to interact with local and network files and with the Registry as the attacker seeks to obtain persistence and achieve actions on objectives. An EDR solution provides logging of this type of activity, but we can use Sysinternals tools to illustrate the process.

Process Monitor and System Monitor

Whereas Process Explorer is better used as an advanced Task Manager, enabling you to monitor processes and memory consumption, Process Monitor is more suited toward recording and analyzing how the process interacts with the system. With Process Monitor you can analyze every operation that a process is undertaking (including Registry key usage), the status of that operation, and any additional input/output detail of that operation. You can also analyze each operation’s thread stack to find its root cause. For example, if an application is attempting to access a file that doesn’t exist, you can review the stack to see if any of the modules there seem out of place with regard to what the application should or should not do. A malicious DLL, for instance, could be interfering with the process’s normal execution.

*Process Monitor utility showing file creation and network activity by the powershell.exe process. (Screenshot: Process Monitor* *docs.microsoft.com/en-us/sysinternals*)

System Monitor (sysmon) is a logging version of Process Monitor. It can log the same types of activity as Process Monitor, using a filter to focus on security-relevant event types. This can provide a basic intrusion detection system.

Autoruns

The Autoruns tool shows processes set to autostart and list where autostart entries are configured in the Registry and file system. User-mode malware that is attempting to run at startup should be identifiable in one of these locations.

ENDPOINT DETECTION AND RESPONSE CONFIGURATION CHANGES

Like any type of automated intrusion detection, endpoint detection and response (EDR) requires tuning to reduce false positives. Rules that generate alerts that do not actually require an analyst’s attention can be changed to log only or disabled completely.

If you identify previously unknown malware through threat hunting techniques, you need to process this information into actionable intelligence to enable detection on other systems, reducing the incidence of false negatives. You may also wish to share the threat intelligence you have developed through a community or industry portal. One basic method of doing this is to upload the malware binary to an analysis portal such as virustotal.com. You should always check for the presence of the malware signature before doing this, however. Adversaries monitor these sites to identify whether custom malware has been detected and uploaded. This gives them advance warning that their activity on a given network has been identified or is at elevated risk of being exposed. You can also submit samples to your A-V or CTI vendor.

In some circumstances, you may want to undertake development of custom malware signatures or detection rules yourself. These must be configured in a format that can be imported into your security monitoring software. A-V vendors have developed various proprietary systems for classifying and naming malware. The earliest system was developed by the Computer Antivirus Research Organization (CARO) in 1991 (caro.org/articles/naming.html). Most vendor systems follow this general approach, using some combination of type (virus, worm, Trojan, and so on), platform (OS type or script for instance), family (similar code characteristics or author attribution), and variant (some unique feature).

** For more information, consider Microsoft’s blog post explaining how they apply CARO principles to malware identification (docs.microsoft.com/en-us/windows/security/threat-protection/intelligence/malware-naming). **

The Malware Attribute Enumeration and Characterization (MAEC) scheme (maecproject.github.io/documentation/overview) is complementary to the STIX and TAXII projects to improve automated sharing of threat intelligence. Another notable tool for custom malware analysis is Yara (yara.readthedocs.io/en/v3.4.0/gettingstarted.html). Yara rule support is built into many security products. A Yara rule is a test for matching certain string combinations within a data source. The data source can be a binary file, or other data such as a log file, packet capture, or email. The strings could be ASCII or Unicode text or hex digits. The filter definitions can also use regular expression (regex) syntax.

BLOCK LISTING AND ALLOW LISTING

Most types of preventative endpoint and network security controls support the concept of block listing and allow listing.

Block listing

Block listing is the process of denying known applications, services, traffic, and other transmission to and from your systems. Block lists are created when the organization knows the source or mechanism of a potential threat and determines that this threat can be shut out from the organization entirely.

Block lists are useful in incident response for their ability to block the source of malware. The source can be external to the organization, or it can be positioned internally through persistence techniques like rootkits and logic bombs. As an example of an external source, consider that the users in your organization are having their workstations infected by malvertisements on seemingly legitimate websites. The advertisements are not necessarily localized to one site, so it may not be effective to simply prevent users from visiting one particular site. Instead, you can implement ad blocking or script blocking software on the user’s workstations or adjust your organization’s web filter to block URL requests for known advertisement domains. Constructing a block list of domains, sites, or technologies that can be a vessel for malware will help stop an infection from spreading.

As an example of an internal source of malware, assume that you’ve uncovered evidence of logic bombs going off under unknown circumstances. You do know the effect (encrypting the user’s drive to use as ransom), and you know how it spreads—through several different TCP/IP ports. So, your block list could include the port numbers that you know the logic bomb uses to spread, and if you implement the block list at the firewall, you can help prevent more hosts from being infected.

There are two main limitations of block lists. The first runs the risk of false positives, in which you block a site, services, port, and so on, that has legitimate uses. This can end up being a sort of collateral damage in an attempt to defend against a malware attack with many vectors or vectors commonly used in normal operations. The other main weakness of block listing is everything that you don’t know. You can’t know every single malicious attack vector out there, and the ones on the list might not be comprehensive enough. You’re running the block list from a limited perspective, one that can’t possibly catch up to the ever-changing world of malware and other threats.

Allow listing

Allow listing is a response to the block list’s problem of unknown threats. In an allow list, you block everything except what you trust. In the external malvertisement example, you could create a list of advertisement domains you know to be legitimate and filter the rest. It’s much easier to account for what you know is safe or acceptable.

In response to an ongoing incident, allow listing may be the better alternative when confirming and researching malicious sources of malware that are either too time-consuming or subject to change. You’re much more likely to know right away what’s friendly rather than to spend time identifying every possible foe. You may have missed a port that the logic bomb uses to communicate and that your block list doesn’t account for. That will enable the infection to spread, despite your efforts. If you enforce an allow list of all legitimate ports, however, then this unknown port would likely have been blocked.

Allow lists are usually a safer bet in incident mitigation, but they’re not flawless. They can be incredibly restrictive, preventing users and systems from transmitting data to new or changing recipients. They need to be constantly fine-tuned to avoid interference with business operations, which can be cost-prohibitive and time-prohibitive for some organizations.

Execution Control

One of the critical features of an EPP is execution control. Execution control is the process of determining what additional software may be installed on a client or server beyond its baseline. Execution control can be implemented as either an allow list or a block list. Allow listing will inevitably hamper users at some point and increase support time and costs. For example, a user might need to install a conferencing application at short notice. Block listing is vulnerable to software that has not previously been identified as malicious (or capable of or vulnerable to malicious use).

The program code underpinning service and applications software can be digitally signed to prove the identity of the publisher and ensure the code has not been modified by anyone else. Execution control is often enforced using a third-party security product, but there are some built-in Windows features that can perform the task:

Software Restriction Policies (SRP)—Available for most versions and editions of Windows, SRP can be configured as group policy objects (GPOs) to allow list file system locations from which executables and scripts can launch. Rules can also be configured by publisher signature or by file hash. There is also support for creating block list-based rules.
AppLocker—Improves configuration options and default usage of SRP. Notably AppLocker policies can be applied to user and group accounts rather than just computer accounts. However, AppLocker GPOs can only be configured for Enterprise and Ultimate editions of Windows 7 and later.
Windows Defender Application Control (WDAC)—Formerly Device Guard, this can be used to create Code Integrity (CI) policies, which can be used on their own or in conjunction with AppLocker. CI policies apply to the computer and affect all users. CI policies can be based on version-aware and publisher digital signatures, as well as image hashes and/or file paths. WDAC is a useful option for preventing administrator accounts from disabling execution control options (docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control). WDAC is principally configured using XML policy statements and PowerShell.

In Linux, execution control is normally enforced by using a mandatory access control (MAC) kernel module or Linux Security Module (LSM). The two main LSMs are SELinux (access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/deployment_guide/ch-selinux) and AppArmor (help.ubuntu.com/lts/serverguide/apparmor.html).

Configuration Changes

You will need to update the contents of block lists and allow lists in response to incidents and as a result of ongoing threat hunting and monitoring. Threat hunting may also provoke a strategic change. For example, if you rely principally on block listing, but your systems are subject to numerous intrusions, you will have to consider adopting a “least privileges” model and allowing only allow listed applications and ports to be used. This sort of change has the potential to be highly disruptive however, so it must be preceded by a risk assessment and business impact analysis.

Front of Flashcard 1 of 4

You are presenting an overview of security solutions to senior management. Using no more than one or two sentences for each, what are the main characteristics of EPP, EDR, and UEBA?

Back of Flashcard1 of 4

An endpoint protection platform (EPP) bundles a number of security functions—signature-based malware detection and IDS, firewall, encryption, and so on—into a single software agent managed by a single console. Endpoint detection and response (EDR) focuses on logging and alerting functions rather than prevention per se. The aim is to alert administrators to an intrusion and allow them to respond quickly. User and entity behavior analytics (UEBA) is a server-side process that applies machine learning generated algorithms to security data to identify malicious behaviors by user and device accounts.

Front of Flashcard 2 of 4

What are the principal techniques for reverse assembling malware code?

Back of Flashcard 2 of 4

The binary machine code can be disassembled to assembly code and potentially decompiled to high-level pseudocode. Another technique is to extract strings from the process image.

Front of Flashcard 3 of 4

You suspect that a host is infected with malware but cannot identify a suspect process using locally installed tools. What is your best course of action?

Back of Flashcard 3 of 4

Contain the host within a sandbox for further analysis. The best approach is to monitor the host for outbound network connection attempts. If the host attempts to connect to suspicious domains or IP address ranges, you can identify the process responsible.

Front of Flashcard 4 of 4

Which of the following processes would you NOT expect to be running under services.exe? Csrss.exe, Lsass.exe, Svchost.exe, SearchIndexer.exe, Spoolsv.exe.

Back of Flashcard 4 of 4

Csrss.exe and Lsass.exe