Part Two
Application Control
Updating our software list boosts security. Reviewing it ensures all programs are allowed and needed. Although creating the list takes time, it helps find and remove harmful or unnecessary software.
This is the basis for our app control: allow only approved software and block or flag anything else as suspicious.
The Safelist
Application control involves creating a list of approved apps and then checking if each program that tries to run is on that list.
It's simple in theory, but tricky in practice: even if you've carefully built a safelist, how do you confirm if a program trying to run, like one named lsass.exe, is safe? Just because its name matches, should it be allowed?
Poorly set up safelists can let malware run if the names match. Checking if a file matches the safelist is crucial; if done poorly, malware might easily bypass the control.
If set to strict, managing the safelist can be a hassle, especially for SHA256 hashes. However, digital signatures are both strong and easy to manage.
Typical Flow of Executables
We need a flexible safelist for executable files to allow updates while blocking malicious files. To improve security, focus on how new executables are introduced, both by updates and by attackers.
Evil Executable Propagation
Adversaries are clever and persistent in finding ways to place harmful files on compromised machines, using any means necessary.
How do harmful files end up on our systems if updates are managed through patch or system tools like SCCM?
Email attachment (not anymore)
Download via HTTP/HTTPS
Download via TFTP/FTP
Download via DNS
Download via SMB
Download via whatever you allow outbound
Pivoted distribution from compromised host
Removable media (USB)
Identification of Source
On Windows NTFS, the Zone.Identifier Alternate Data Stream (ADS) can show where an executable came from by marking its trust level based on its source.
ADS can track a file's movement between NTFS drives. So, if an internet-downloaded executable ends up in Windows/System32, it could be easily spotted.
On recent versions of Windows, you can simply use dir /r to see ADS:
Zone.Identifier
Above, we see an example of using dir to see the Alternate Data Stream (ADS) exists. Afterward, the more command is used to determine the contents of the ADS.
Application Control Administrative Overhead
Application control boosts endpoint security but requires ongoing effort. The initial setup is tough, and many overlook the continuous maintenance needed. A three-phase approach can help make it sustainable long-term.
Phase 0: Safelist Building
Phase 0 is about creating the initial application safelist. While it's simple, care is needed in how it's done. We’ll look at the pros and cons of using the National Software Reference Library, capturing executables from systems (both fielded and pre-fielded), and trusting signed binaries from vendors like Microsoft.
NSRL RDS (Reference Dataset)
NIST manages the National Software Reference Library (NSRL), which stores known files from software and systems. The Reference Dataset (RDS) helps simplify forensic file reviews on acquired systems.
We can use the NSRL RDS for our safelist, but it has pros and cons:
Advantage: Easy to gather binaries without having to touch those icky deployed systems
Disadvantage: Does this generic list include all the software your organization uses?
Disadvantage: Only updated four times/year
Disadvantage: Will not include your custom applications
Fielded-System Executables
A major downside of using the NSRL RDS is that it's generic and not customized for your organization's specific needs.
Phase 0 of the safelist involves collecting working binaries from fielded systems. This approach has pros and cons:
Advantage: Can identify binaries used in your organization that are needed but not necessarily found in every other organization
Disadvantage: The system could have “after-market” user binaries that have not been vetted/approved
Disadvantage: The system could already include malicious binaries, now trusted
Pre-Fielded System Executables
Using pre-fielded system executables as a safelist source has pros and cons, lying between the NSRL RDS and fielded systems:
Advantage: Like the fielded system, it includes software leveraged in your organization
Advantage: Unlike the fielded system, the unfielded image is less likely to have “after-market” user binaries or malware
Disadvantage: This approach is limited by how strong your builds are
Trusting Signed Binaries by Specific Vendors
This method simplifies application control and is highly recommended. Signed binaries are more secure than hashes and also ensure file integrity.
Advantage: One rule may trust hundreds, or thousands, of binaries signed by a specific vendor
Advantage: Patches and software updates by the same vendor are also (very likely to be) automatically trusted
Disadvantage: Not all vendors sign all software -> For example: Microsoft signs most (99+% of their software), but some older software that is still in use (such as .NET framework software) may be unsigned
Hybrid Approach
The best approach for your organization could be a mix of the three methods, with ongoing adjustments and exceptions. One option is to begin by capturing executables on systems that are already set up, or even on those that aren't built well initially.
Set up a process to manage trust updates from patches and trusted binaries. Also, create a process to add trusted apps for specific users or groups, with approval and responsibility for exceptions.
Phase 1: Targeted Detection
We will first deploy the safelist in detect-only mode for a set period to enable targeted detection.
Detect-only mode in application control improves security, but using prevention is more effective. Phase 1 focuses on tuning by identifying false positives—binaries that are wrongly blocked but are needed for business.
True/False Positive
The best way to weaken application control is by letting people trust executables without proper checks. Every alert or block should be carefully reviewed to decide if it was needed. This review often uncovers previously unknown compromised systems.
Phase 1: Duration
Stay in phase 1 (detect-only mode) as long as needed. Moving to phase 2 too quickly can cause false positives, blocking legitimate programs and potentially keeping the system stuck in detect-only mode.
Phase 1 aims to set up strong processes for managing application control, not just finding missed items in the safelist.
Phase 2: Strict Enforcement
Some organizations never reach phase 2 (strict enforcement) or rush into it, only to return to phase 1 for a long time. While phase 2 aims to prevent untrusted executables, the main goal is to detect and review systems trying to run binaries not on the safelist. If phase 1 is done well, phase 2 can offer valuable detection.
Blocking -> Detection
Application control aims to block untrusted binaries and figure out how they got on the system and if they're necessary.
The blocked executable may be a trusted binary that wasn't identified or is an updated version. Either way, our process failed, as we need to prevent trusted binaries from being executed. We need to analyze how the binary got on the system, whether it’s trusted or not.
(Previously) Trusted Binaries
The discussion started with how to identify trusted binaries and verify that the binary being executed is the trusted one.
Common ways of identifying binaries in the safelist include:
Filename
File Location (path)
Integrity Hash (MD5, SHA1, SHA256)
Digital Signature
These are common ways to trust binaries, but attackers know them. So, think about how they might try to bypass our application control methods:
Filename: Adversary opts for known-good filename
Location: Adversary targets poorly secured, but commonly trusted locations
Filename + Location: Lax permissions might allow adversaries to replace our trusted file
Using hashes or code signing for application control makes it much harder for attackers to bypass.
Hash Bypass
Adversaries can't bypass SHA256 through hash collisions. Instead, they might alter running executable code using code injection techniques.
Advanced Application Control
Standalone application control products are better at preventing bypass, but endpoint security suites often lack strong protection against techniques like code injection. However, even if bypass is possible, these products still provide valuable protection and shouldn’t be ignored.
Linux AppArmor
The following Linux distributions support AppArmor:
Annvix
Arch Linux
Debian
Gentoo
Mandriva
openSUSE (integrated into default install) •
Pardus Linux
PLD
Ubuntu (integrated into default install)1
AppLocker
AppLocker can work alongside Software Restriction Policies (SRP) but has key differences. If your license supports AppLocker, it's better to use it over SRP.
AppLocker is free with the highest Windows licenses and doesn’t need extra software or a management server.
AppLocker is managed through Group Policy, which brings both benefits and challenges. While it’s not as feature-rich as third-party control products, it offers significant benefits if already in use.
AppLocker Phase 0: Rule Creation
Phase 0 is about creating the safelist. AppLocker can automatically create default rules to keep Windows working, and you can also use a reference system to create allow and block rules.
By setting up a folder for block rules, new malware or outdated apps can be placed there, and updated block rules can be shared across the domain using GPOs.
AppLocker Phase 1: Audit Only
Phase 1 with AppLocker is simple: set it to "Audit Only" mode. This helps identify what would be blocked and manage exceptions. AppLocker logs Event ID 8003 when it would block something, but doesn't in Audit mode.
Audit Only Mode
The slide shows Event ID 8003 from AppLocker. It indicates that nc.exe ran but would be blocked if AppLocker enforced execution instead of just auditing.
AppLocker Alerts
Tracking AppLocker events is key for app control. While block mode is ideal, audit mode helps avoid blocking good apps and alerts when unknown binaries run, making it a great monitoring tool.
Enforce/block mode is great for prevention. Don’t just set it and forget it—watch events 8004 and 8007. These show when a non-trusted program is blocked, which can happen in three cases.
Known, benign, and unimportant program was blocked (for example, minesweeper)
Unknown, benign, and business critical program was blocked (for example, a critical accounting program that is run quarterly or annually)
A malicious program was blocked
Defending Identity and Access
Despite our security efforts, like patching, hardening, and app control, an attacker could still exploit a vulnerable app and gain remote code execution.
Exploitation isn't impossible—it's inevitable. Preventive controls can be bypassed, so this course focuses on detection and response. The key questions are: What can the attacker do, and what will the impact be? A crucial factor is the attacker's level of privilege.
Adversary Privilege
The key point is the adversary's gained privilege: users with limited system rights face less impact than those with admin rights.
The impact depends on the adversary's gained privileges, usually linked to the user's account, especially with more client-side attacks.
Administrative Accounts
To reduce privileges, we need to count admin accounts, including those with "Administrator" in their name.
Built-in Administrator
Local Administrator
Domain Administrator
Enterprise Administrator
Global Administrator
What truly defines an admin account isn’t just the name. Once we understand its role and privileges, we can work to reduce and monitor them. Simply cutting down Domain Admins helps but doesn’t address the full scope of what being an admin entails.
What Does Admin Mean?
If I made a group called "notadmin" with the same powers as "admin" and moved users to it, security wouldn’t really change—just enough to satisfy some auditors.
It's not the name "Admin" that matters, but the rights and permissions tied to the account, which need to be controlled.
Rights/Permissions
If you find Linux complex, you haven't dealt much with Windows entitlements. Windows has many ways to manage permissions, like NTFS permissions, which are more complicated than they seem. Every object in Windows, from files to AD properties, has its own set of permissions.
User rights and privileges are different from NTFS permissions but still affect what you can do with files, systems, and objects controlled by NTFS.
Built-In Administrator
A simple fix is to question the need for the built-in local administrator account, as it lacks user accountability. If it's seen as a backup for emergencies, weigh the risks and benefits of keeping it.
The administrator account is widely known and easy for attackers to identify, even if renamed. It also doesn't lock out after failed login attempts, making it vulnerable to password-guessing attacks.
The default administrator account is a key target for pass-the-hash attacks, which will be explained soon.
Built-In Administrator Passwords
This account is a common target for password-guessing attacks, but it likely has a strong password due to its privilege. However, you may use the same password across multiple systems, which increases the risk of pass-the-hash attacks, where an attacker uses the password hash for network authentication without needing the actual password. More details on pass-the-hash attacks will be provided later.
Local Administrator Password Solution (LAPS) x 2
Microsoft's Local Administrator Password Solution (LAPS) tool manages local admin passwords in a domain, ensuring each computer has a unique, random password for the local admin account. It also lets domain admins control who can access these passwords.
Certain users or groups can view passwords in the LAPS interface. Passwords are randomly generated, can be scheduled for automatic changes, and are encrypted with Kerberos. Microsoft introduced Windows LAPS, a new version of LAPS for Windows endpoints, offering centralized backup and recovery of local admin accounts to either on-premises or Azure Active Directory, depending on the system's join state.
Service Accounts
Service accounts are often admin-level accounts used by applications to run with specific privileges, without user interaction. They are commonly targeted by attackers and are less controlled. Modern Windows versions offer Virtual, Managed, and Group Managed Service Accounts.
LSA Secrets
Services usually run as Local or Network Service, but when we talk about a "service account," it means a user account used for authentication. The purpose is to avoid needing a password for login, so how do services authenticate without it?
The LSA Secrets in HKLM\Security\Policies\Secrets store service account passwords. Accounts with the Debug Programs privilege can access and decrypt this data.
Persistence
After exploiting a system, attackers often try to maintain long-term access, focusing on gaining persistent, high-level privileges.
Exploitation today often relies on social engineering, like tricking the victim into clicking a link or opening a file. Once the attacker succeeds, they don't want to exploit the victim again because it gets harder over time. Instead, they aim to gain persistent access to avoid needing to exploit the victim repeatedly.
ASEPs
To survive a reboot, malware often sets itself to start automatically when Windows boots. These methods are called ASEPs (Auto-Start Extensibility Points), and some are well-known, while others are less obvious.
Monitoring ASEP changes helps detect attempts at persistence and indicates a deeper compromise.
Autoruns
Autoruns from Sysinternals is a popular tool for investigating ASEPs. It's widely used by security experts and can be run via its GUI or directly from the Sysinternals Live site. A great way to use it is through the command-line version, autorunsc.exe.
Autoruns allows saving and comparing reports, which helps track new autostart entries and their first appearance. The command-line version also provides an easy-to-parse text output.
Autoruns can check if a program's code is signed correctly using the "verify code signatures" option. It shows "Verified" or "Not Verified" next to the publisher to indicate the signature status.
Lab 4.2 - Autoruns
Objectives:
Become familiar with the usage of Microsoft Sysinternals' Autoruns tool.
Understand advanced use cases for Autoruns.
Review basic Autoruns output on a standard system.
Analyze Autoruns output from a compromised system.
Understand various methods for adversary persistence
Challenges:
Review Autoruns' output from the Windows VM as a non-compromised system.
Analyze an Autoruns capture from a presumed compromised system: The file is located in C:\labs\autoruns-after.arn
What is meant by items highlighted in red?
Identify highly suspicious findings.
Use Autoruns to perform a comparison of C:\labs\autoruns-after.arn and C:\labs\autoruns-before.arn
Open C:\labs\autoruns-after-virustotal.arn and inspect the six items that were previously researched via VirusTotal.
If the class has Internet access, you may view the VirusTotal results via this URL: https://sec511.com/lt
Bonus challenge, inspect the event logs:
C:\labs\autoruns-application.evtx
C:\labs\ autoruns-security.evtx
C:\labs\ autoruns-sysmon.evtx
C:\labs\ autoruns-system.evtx
1) Let's first check the Autoruns output from the Windows VM, assuming it hasn't been compromised.
Autoruns opens to the Everything tab by default.
Check the tabs, which show different ways programs can auto-start.
Notice the bottom-right corner, where it shows Windows entries are hidden.
2) Next, let's analyze an Autoruns file from a suspected compromised system. The file is at C:\labs\autoruns-after.arn.
3) What is meant by items highlighted in red?
The red often lands people at the Sysinternals forums searching for an answer. We notice the red highlighting in the autoruns-after.arn file and some of those items look suspicious
If "Verify Signatures" is enabled, unsigned items appear in red. If it’s not enabled, items without a company name or description are shown in red.
Note this suspicious entry with a blank publisher:
4) Identify any highly suspicious findings.
Files marked in red are suspicious, but even legitimate files might lack a description, publisher, or digital signature.
A suspicious item called dkdCYsoepc that links to a random file.
c:\users\student\appdata\local\temp\taslolpik.vbs
There is no publisher or digital signature.
The scheduled task gathernetworkinfo.vbs in C:\Windows\System32 doesn't have a publisher.
The syscheck73 entry has no description or publisher, and its path is suspicious: C:\Users\Instructor\AppData\Local\Temp\svhost54.exe.
5) Use Autoruns to perform a comparison of autoruns-after.arn and autoruns-before.arn, both of which are in the C:\ labs directory
Click Open
Select Compare.
Navigate to C:\labs\autoruns-before.arn
Click Open and review the results.
The changes between the before and after compromise Autoruns reports are shown in green, confirming two of the issues we found earlier.
6) Open C:\labs\autoruns-after-virustotal.arn and inspect the six items that were previously researched via VirusTotal.
Let's go through each report one by one.
dkdCYsoepc (tslolpik.vbs):
GatherNetworkInfo (gathernetworkinfo.vbs):
syscheck73 (svhost54.exe, detected as "nc.exe" by VirusTotal):
UdeCx (udecx.sys):
Both FaceCredentialProvider and IrisCredentialProvider link to facecredentialprovider.dll:
Bonus
There are several ways to search event logs with PowerShell, and we can choose the one we like best. In this guide, we'll use the Out-Gridview cmdlet.
Next, let's click on "Add criteria" and select "Message."
Then we'll search for svhost:
Let's search using two criteria: "cmd" and "temp". Searches are case-insensitive by default.
Let's search for .vbs:
Last updated
