This post outlines how you can identify system configuration changes that were made by an intruder during an incident response investigation.
We were on a roll with this Intro to Incident Response series and then we had to get ready for all of our talks, workshops, and training at the OSDFCon conference.
But that is over, and we’re back to finish the series.
Last month, we wrapped up the “sub-series” on Malware with a post about looking for remnants. Now, we start the 3rd and final topic in our series outlining our approach to incident response: “System Configuration.” This topic is all about looking for changes that were made to the system to make the attacker’s job easier.
In this post, we’ll start with a refresher on the series, dive into the topic of system configuration, and then show some examples using Cyber Triage.
Incident Response Framework Review
If you’ve been following the series this summer, you already know this, but maybe you forgot in the past month.
The basic concept we’ve been working with is to break the big intrusion investigation questions into smaller questions that can be answered based on data.
There are three big questions under the question of, “Is this computer compromised?”:
- Is there suspicious user activity (such as sensitive files being accessed)?
- Are there malicious programs (such as malware)?
- Are there malicious system changes (such as relaxed security settings)?
The series has already covered users and malware. Now we are going to focus on system changes. For more information on the breakdown, refer to an earlier post.
Why We Investigate System Configuration Changes in Incident Response
We’ve already seen ways that attackers try to maintain access to your network after they compromise it.
They may try to steal account credentials so that they can later log in as those users (we covered this here). Or, they may install software that gives them backdoor access or that reaches out to a command and control server (we covered this here).
Some of these techniques will involve changes to the configuration of the OS. Examples include:
- Disabling security software to prevent detection
- Enabling remote access to allow access without malware
- Disabling backups to prevent recovery.
How You Should Break “System Configuration” into Smaller Questions During an Incident Response Investigation
As you know at this point, the theme of this series is to take big questions and break them into smaller and smaller questions until we know what data can answer that question.
We break the question “Were there system configuration changes made” into three questions:
- Was remote access enabled? I.e. did they make it easier to gain access?
- Was security software disabled or limited? I.e. did they make it easier for them to not get detected?
- Were backup systems disabled or limited? I.e. did they make it harder to recover once the incident was detected?
Let’s look at each of these.
Why You Should Look For Remote Access Enabling
An attacker wants to be able to regain access to an endpoint, but that may not be possible based on the system’s configuration.
For example, maybe the attacker got credentials for the user who clicked on a malicious attachment, but those credentials won’t get the attacker access to the machine if remote desktop is disabled (though they make work on other systems).
Here are some examples of how an attacker may modify a system to ensure he or she can get interactive access to it or its data in the future:
- Enable Windows Remote Desktop to allow stolen credentials to be used for an interactive login
- Enable Windows file sharing to allow data from the system to be accessed without an interactive login
- Configuring the accessibility features so that the attacker can get a command prompt by typing in a certain key combination to a remote login prompt (without needing a password)
- Create accounts with administrator privileges so that the attacker does not raise any alarms by changing the behaviors of an existing user.
Why You Should Look For Disabled Security Software
If security software has been disabled, then it allows the attacker to reduce their chances of getting detected and potentially the response. Though, making these kinds of changes may also trigger other detection systems if they are being monitored.
Here are some examples of changes that an attacker may make and hope you don’t notice:
- Disable firewall or modify rules to allow outbound or inbound access for a program
- Disable antivirus, including Windows Defender, to prevent malware from being detected
- Disable application whitelisting programs to enable malware to run
- Disable response tools to prevent remote visibility.
Other non-software examples of changes that may occur to prevent detection or a response include:
- Change audit levels to reduce the number of logs that exist. For example, to reduce the number of total logs stored and to not log logins or processes starting
- Disable accounts to make it harder to respond to the system
- Install malicious root encryption certificates so that the OS thinks that the malware is legitimately signed.
Why You Should Look For Disabled Backups
Attackers may want to create distractions when they are detected or may want you to pay them to get data back.
Some attackers will disable recovery or actively erase backups. For example, many ransomware applications will disable Volume Shadow so that you have no local backup to recover with after your computer has been encrypted.
Where To Find The Data
A huge challenge with answering the above questions is that they are settings scattered around the Window’s registry hives and may be stored in proprietary configuration files.
Some registry settings, such as if Windows Defender are well-publicized (example). Others, such as if a specific antivirus engine was configured to ignore a certain folder, are not.
You may be able to get some of the information using built-in command-line tools, or you may need to parse specific registry keys. For example, you can determine if Volume Shadow has been disabled by using typing “vssadmin list shadows” at a command prompt.
How to To Analyze the Data
Once you’ve collected the needed data, it’s time to decide if the settings are correct.
The ease of doing this depends greatly on knowledge of how the computer was initially configured.
If your organization has a standard baseline that all computers are configured from, this can become an easier task of comparing the current settings with the initial ones. Some tools offer a baseline comparison feature to make this easier.
If your organization does not have a standard baseline, then this can become more challenging given that different versions of Windows will ship with different configurations.
Finding Configuration Changes with Cyber Triage
Cyber Triage collects and analyzes artifacts associated with system configuration, and we’ll show you how.
The registry hives and other configuration settings are collected by one of our agentless collection methods. Our collection tool will use The Sleuth Kit to locate registry hives (even when they are locked), load the hive using our open source registry library, and parse the numerous keys and values:
The navigation menus on the left-hand side of Cyber Triage are organized based on the same ideas that this blog series uses. The first items are all about users. The next set is about malware. The last is about system configuration:
For the “System Configuration” questions we’ve talked about in this post, we will focus on the “System Configuration” section.
System Configuration Section
The “System Configuration” section contains the settings that were collected from the target system.
It is a bit different from the other parts of the Cyber Triage UI because it is a combination of name and value pairs, while the other parts of the UI are a list of artifacts of the same type (such as all startup items).
Examples of settings you may see include:
- Audit settings that you can know what to expect for login events
- If Windows Defender is enabled
- If the Windows Firewall is enabled.
You’ll also see settings here about the version of the collection tool that was used and what data types were collected.
Because these data types are simple name/value pairs and not full artifacts, the bottom, “Related Information” section does not allow you to pivot around and find processes or startup items.
Conclusion
Many people first think about malware and compromised credentials as part of intrusions, but it’s important to not overlook configuration changes.
These changes may be required for the attacker’s tools to operate or they could be the method that the attacker is using to maintain access. The big challenges with answering the question of “Are there malicious system changes?” is knowing where to find all of the settings and what the baseline values are.
If you’d like to try the automated collection and analysis techniques of Cyber Triage, then you can download today for free.
