File

Monitor access to file resources that contain local accounts and groups information such as /etc/passwd, /Users directories, and the Windows SAM database.

If access requires high privileges, look for non-admin objects (such as users or processes) attempting to access restricted file resources.

Monitor for Keychain files being accessed that may be related to malicious credential collection.

Identify web browser files that contain credentials such as Google Chrome’s Login Data database file: AppData\Local\Google\Chrome\User Data\Default\Login Data. Monitor file read events of web browser files that contain credentials, especially when the reading process is unrelated to the subject web browser.

Consider monitoring file reads to Vault locations, %Systemdrive%\Users\\[Username]\AppData\Local\Microsoft\\[Vault/Credentials]\, for suspicious activity.^[3]

Monitor file reads that may acquire user credentials from third-party password managers.^[4]

Monitor processes that appear to be reading files from disparate locations and writing them to the same directory or file may be an indication of data being staged, especially if they are suspected of performing encryption or compression on the files, such as 7zip, RAR, ZIP, or zlib.

Monitor processes that appear to be reading files from disparate locations and writing them to the same directory or file may be an indication of data being staged, especially if they are suspected of performing encryption or compression on the files, such as 7zip, RAR, ZIP, or zlib.

Monitor for unusual processes accessing local email files that may target user email on local systems to collect sensitive information.

Monitor for files viewed in isolation that may steal data by exfiltrating it over a symmetrically encrypted network protocol other than that of the existing command and control channel.

Monitor files viewed in isolation that may steal data by exfiltrating it over a symmetrically encrypted network protocol other than that of the existing command and control channel.

Monitor files viewed in isolation that may steal data by exfiltrating it over a symmetrically encrypted network protocol other than that of the existing command and control channel.

Monitor for files being accessed that could be related to exfiltration, such as file reads by a process that also has an active network connection. Also monitor for and investigate changes to host adapter settings, such as addition and/or replication of communication interfaces.

Monitor file access on removable media that may attempt to exfiltrate data over a USB connected physical device.

Monitor for files being accessed to exfiltrate data to a code repository rather than over their primary command and control channel.

Monitor for files being accessed to exfiltrate data to a cloud storage service rather than over their primary command and control channel.

Monitor for files being accessed to exfiltrate data to a webhook as a malicious command and control channel.

Monitor for hash dumpers opening the Security Accounts Manager (SAM) on the local file system (%SystemRoot%/system32/config/SAM). Some hash dumpers will open the local file system as a device and parse to the SAM table to avoid file access defenses. Others will make an in-memory copy of the SAM table before reading hashes. Detection of compromised Valid Accounts in-use by adversaries may help as well.

Monitor for access or copy of the NTDS.dit.

Note: Events 4656 and 4663 (Microsoft Windows Security Auditing) provide context of processes and users requesting access or accessing file objects (ObjectType = File) such as C:\Windows\NTDS\ntds.dit. It is important to note that, in order to generate these events, a System Access Control List (SACL) must be defined for the ntds.dit file. Access rights that allow read operations on file objects and its attributes are %%4416 Read file data, %%4419 Read extended file attributes, %%4423 Read file attributes. If you search for just the name of the file and not the entire directory, you may get access events related to the ntds.dit file within a snapshot or volume shadow copy.

Events 4656 and 4663 (Microsoft Windows Security Auditing) provide context of processes and users creating or copying file objects (ObjectType = File) such as C:\Windows\NTDS\ntds.dit. It is important to note that, in order to generate these events, a System Access Control List (SACL) must be defined for the ntds.dit file. In order to filter file creation events, filter access rigths %%4417 Write data to the file and %%4424 Write file attributes.

Event 11 (Microsoft Windows Sysmon) provide context of processes and users creating or copying files. Unfortunately, this event provides context of the file being created or copied, but not the file being copied. A good starting point would be to look for new files created or copied with extension .dit.

Analytic 1 - Active Directory Dumping via NTDSUtil

(source=WinEventLog:"Security" EventCode IN (4656, 4663)) OR (source=WinEventLog:"Microsoft-Windows-Sysmon/Operational" EventCode="11") ANDObjectType="File" AND TargetFilename="*ntds.dit" AND (AccessList="%%4416" OR AccessList="%%4419" OR AccessList="%%4417" OR AccessList="%%4424")

Monitor for unexpected access to passwords and hashes stored in memory, processes must open a maps file in the /proc filesystem for the process being analyzed. This file is stored under the path /proc/\/maps, where the \ directory is the unique pid of the program being interrogated for such authentication data. The AuditD monitoring tool, which ships stock in many Linux distributions, can be used to watch for hostile processes opening this file in the proc file system, alerting on the pid, process name, and arguments of such programs.

Monitor for files being accessed that may attempt to dump the contents of /etc/passwd and /etc/shadow to enable offline password cracking. The AuditD monitoring tool, which ships stock in many Linux distributions, can be used to watch for hostile processes attempting to access /etc/passwd and /etc/shadow, alerting on the pid, process name, and arguments of such programs.

Monitor for files being accessed that may search local file systems and remote file shares for files containing insecurely stored credentials. While detecting adversaries accessing these files may be difficult without knowing they exist in the first place, it may be possible to detect adversary use of credentials they have obtained.

Monitoring when the user's .bash_history is read can help alert to suspicious activity.

Monitor access to files and directories related to cryptographic keys and certificates as a means for potentially detecting access patterns that may indicate collection and exfiltration activity.

Monitor for attempts to access SYSVOL that involve searching for XML files.

Monitor newly constructed files being written with extensions and/or headers associated with compressed or encrypted file types. Detection efforts may focus on follow-on exfiltration activity, where compressed or encrypted files can be detected in transit with a network intrusion detection or data loss prevention system analyzing file headers.

Monitor newly constructed files being written with extensions and/or headers associated with compressed or encrypted file types. Detection efforts may focus on follow-on exfiltration activity, where compressed or encrypted files can be detected in transit with a network intrusion detection or data loss prevention system analyzing file headers.

Monitor newly constructed files being written with extensions and/or headers associated with compressed or encrypted file types. Detection efforts may focus on follow-on exfiltration activity, where compressed or encrypted files can be detected in transit with a network intrusion detection or data loss prevention system analyzing file headers.

Monitor for newly constructed files that may modify the kernel to automatically execute programs on system boot.

Monitor newly constructed files that may modify or add LSASS drivers to obtain persistence on compromised systems.

Monitor for LNK files created with a Zone Identifier value greater than 1, which may indicate that the LNK file originated from outside of the network.^[8] Analysis should attempt to relate shortcut creation events to other potentially suspicious events based on known adversary behavior such as process launches of unknown executables that make network connections.

Monitor newly constructed files that may use port monitors to run an attacker supplied DLL during system boot for persistence or privilege escalation.

Monitor for newly constructed files that may abuse print processors to run malicious DLLs during system boot for persistence and/or privilege escalation.

Malicious XDG autostart entries may be detected by auditing file creation events within the /etc/xdg/autostart and ~/.config/autostart directories. Depending on individual configurations, defenders may need to query the environment variables $XDG_CONFIG_HOME or $XDG_CONFIG_DIRS to determine the paths of Autostart entries. Autostart entry files not associated with legitimate packages may be considered suspicious. Suspicious entries can also be identified by comparing entries to a trusted system baseline.

All login items created via shared file lists are viewable by using the System Preferences GUI or in the ~/Library/Application Support/com.apple.backgroundtaskmanagementagent/backgrounditems.btm file.^{[9][10][11][12]} These locations should be monitored and audited.

Monitor for the creation of and/or changes to login hook files (/Library/Preferences/com.apple.loginwindow.plist), especially by unusual accounts outside of normal administration duties.

Monitor for newly constructed files by unusual accounts outside of normal administration duties

Monitor for newly constructed /etc/rc.local file

Monitor for newly constructed files by unusual accounts outside of normal administration duties

Monitor for newly constructed files that may create or modify launch agents to repeatedly execute malicious payloads as part of persistence.

Systemd service unit files may be detected by auditing file creation and modification events within the /etc/systemd/system, /usr/lib/systemd/system/, and /home//.config/systemd/user/ directories, as well as associated symbolic links

Monitor for new files added to the /Library/LaunchDaemons/ folder. The System LaunchDaemons are protected by SIP.

Monitor for newly constructed files in order to manipulate external outcomes or hide activity

Monitor for newly constructed files in order to manipulate external outcomes or hide activity

Monitor publicly writeable directories, central locations, and commonly used staging directories (recycle bin, temp folders, etc.) to regularly check for compressed or encrypted data that may be indicative of staging.

Monitor publicly writeable directories, central locations, and commonly used staging directories (recycle bin, temp folders, etc.) to regularly check for compressed or encrypted data that may be indicative of staging.

Monitor for newly constructed files that may deface systems internal to an organization in an attempt to intimidate or mislead users.

Monitor for newly constructed files that may deface systems external to an organization in an attempt to deliver messaging, intimidate, or otherwise mislead an organization or users.

Monitor newly constructed files that may establish persistence by executing malicious content triggered by user inactivity.

Analytic 1 - Created on disk that are being used as Screensaver files

(source="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode="11") TargetObject="\Software\Policies\Microsoft\Windows\Control Panel\Desktop\SCRNSAVE.EXE"

Monitor for MOF files outside of the HKLM\SOFTWARE\Microsoft\WBEM folder, as almost all legitimate MOF files will be stored in the WBEM folder.^[13] Adversaries may create modified MOF files to be complied into WMI event subscriptions.

Monitor for newly constructed files that may establish persistence through executing malicious commands triggered by a user’s shell. For most Linux and macOS systems, a list of file paths for valid shell options available on a system are located in the /etc/shells file.

Monitor for newly constructed files that may establish persistence by executing malicious content triggered by an interrupt signal.

Monitor newly constructed files that may establish persistence and/or elevate privileges by executing malicious content triggered by accessibility features.

Locations where profile.ps1 can be stored should be monitored for new profiles. ^[14] Example profile locations include:* $PsHome\Profile.ps1* $PsHome\Microsoft.{HostProgram}_profile.ps1* $Home\My Documents\PowerShell\Profile.ps1* $Home\My Documents\PowerShell\Microsoft.{HostProgram}_profile.ps1

Monitor emond rules creation by checking for files created in /etc/emond.d/rules/ and /private/var/db/emondClients.

Monitor creation of files associated with installer packages that may be abused for malicious execution.

Monitor the file system and shell commands for files being created with a leading "."

Monitor for newly constructed files associated with running a virtual instance, such as binary files associated with common virtualization technologies (ex: VirtualBox, VMware, QEMU, Hyper-V).

Monitor for newly constructed files that may abuse resource forks to hide malicious code or executables to evade detection and bypass security applications.

Monitor for newly constructed files, especially those that are unexpectedly created in folders associated with or spoofing that of trusted applications. Also, consider prioritizing monitoring and analyzing file activity in known file/path exclusions.

Monitor newly constructed .manifest and .local redirection files that do not correlate with software updates.

Monitor for newly constructed files in common folders on the computer system.

Monitor for newly constructed dylibs

Monitor for newly constructed files to match an existing service executable, it could be detected and correlated with other suspicious behavior.

Monitor for newly constructed files that are added to absolute paths of shared libraries such as LD_PRELOAD on Linux and DYLD_INSERT_LIBRARIES on macOS.

Monitor for newly constructed files for files named after partial directories and in locations that may be searched for common processes through the environment variable, or otherwise should not be user writable. Also, monitor file creation for programs that are named after Windows system programs or programs commonly executed without a path (such as "findstr," "net," and "python"). If this activity occurs outside of known administration activity, upgrades, installations, or patches, then it may be suspicious.

Monitor file creation for files named after partial directories and in locations that may be searched for common processes through the environment variable, or otherwise should not be user writable. Also, monitor file creation for programs that are named after Windows system programs or programs commonly executed without a path (such as "findstr," "net," and "python"). If this activity occurs outside of known administration activity, upgrades, installations, or patches, then it may be suspicious.

Monitor file creation for files named after partial directories and in locations that may be searched for common processes through the environment variable, or otherwise should not be user writable. Also, monitor file creation for programs that are named after Windows system programs or programs commonly executed without a path (such as "findstr," "net," and "python"). If this activity occurs outside of known administration activity, upgrades, installations, or patches, then it may be suspicious.

Monitor for creation of binaries and service executables that do not occur during a regular software update or an update scheduled by the organization. This behavior also considers files that are overwritten.

Monitor for newly constructed files, especially unknown .NET assemblies and configuration files in user writable folder paths.

Monitor for newly constructed files that may register malicious password filter dynamic link libraries (DLLs) into the authentication process to acquire user credentials as they are validated.

Monitor for newly created files that may be used to register malicious network provider dynamic link libraries (DLLs).

Monitor for newly constructed files for payloads

Monitor for newly constructed files via JavaScript, developing rules for the different variants, with a combination of different encoding and/or encryption schemes, may be very challenging. Consider monitoring files downloaded from the Internet, possibly by HTML Smuggling, for suspicious activities. Data and events should not be viewed in isolation, but as part of a chain of behavior that could lead to other activities.

Monitor for newly constructed files containing large amounts of data. Abnormal file sizes may be an indicator of embedded content.

Monitor for downloaded malicious files, though developing rules for the different variants, with a combination of different encoding and/or encryption schemes, may be very challenging. Consider monitoring files downloaded from the Internet, possibly by LNK Icon Smuggling, for suspicious activities. Data and events should not be viewed in isolation, but as part of a chain of behavior that could lead to other activities.

Monitor for files with large entropy which don’t match what is normal/expected given the file type and location.

Monitor for newly constructed files that may abuse Microsoft Office templates to obtain persistence on a compromised system.

Monitor for newly constructed files that may abuse the Microsoft Office "Office Test" Registry key to obtain persistence on a compromised system.

Monitor for newly constructed files that may abuse Microsoft Office add-ins to obtain persistence on a compromised system.

Monitor for the unexpected creation of memory dump files for the LSASS process (e.g., lsass{*}.dmp).

Monitor newly constructed files being written with default names that have extracted credentials from the Security Account Manager.

Monitor for newly constructed files from a spearphishing emails with a malicious attachment in an attempt to gain access to victim systems.

Monitor Windows Task Scheduler stores in %systemroot%\System32\Tasks for change entries related to scheduled tasks that do not correlate with known software, patch cycles, etc. In order to gain persistence, privilege escalation, or remote execution, an adversary may use the Windows Task Scheduler to schedule a command to be run at a specified time, date, and even host. Task Scheduler stores tasks as files in two locations - C:\Windows\Tasks (legacy) or C:\Windows\System32\Tasks. Accordingly, this analytic looks for the creation of task files in these two locations.

Analytic 1 - Scheduled Task - File Creation

(source="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode="11") (TargetFilename= "C:\Windows\System32\Tasks\" OR TargetFilename "C:\Windows\Tasks\*") AND Image!= "C:\WINDOWS\system32\svchost.exe"

Monitor for newly constructed files by using the logging agents on Kubernetes nodes and retrieve logs from sidecar proxies for application and resource pods to monitor malicious container orchestration job deployments.

Consider monitoring file locations associated with the installation of new application software components such as paths from which applications typically load such extensible components.

File monitoring may be used to detect changes to files in the Web directory of a Web server that do not match with updates to the Web server's content and may indicate implantation of a Web shell script.^[16]

Monitor for creation of files (especially DLLs on webservers) that could be abused as malicious ISAPI extensions/filters or IIS modules.

Monitor presence and use of CHM files, especially if they are not typically used within an environment.

Monitor for newly constructed files that may forge web cookies that can be used to gain access to web applications or Internet services.

Monitor use of HTA files. If they are not typically used within an environment then execution of them may be suspicious

Monitor for creation and use of .msc files. MMC may legitimately be used to call Microsoft-created .msc files, such as services.msc or eventvwr.msc. Invoking non-Microsoft .msc files may be an indicator of malicious activity.

malicious documents and files that are downloaded from a link and executed on the user's computer

Monitor for newly constructed files that are downloaded and executed on the user's computer. Endpoint sensing or network sensing can potentially detect malicious events once the file is opened (such as a Microsoft Word document or PDF reaching out to the internet or spawning powershell.exe).

While batch files are not inherently malicious, it is uncommon to see them created after OS installation, especially in the Windows directory. This analytic looks for the suspicious activity of a batch file being created within the C:\Windows\System32 directory tree. There will be only occasional false positives due to administrator actions.

For Windows, Sysmon Event ID 11 (File create) can be used to track file creation events. This event also provides the Process ID of the process that created the file, which can be correlated with process creation events (e.g., Sysmon Event ID 1) to determine if the file was downloaded from an external network.

For MacOS, utilities that work in concert with Apple’s Endpoint Security Framework such as File Monitor can be used to track file creation events.

Analytic 1 - Batch File Write to System32

(source="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode="11") file_path="system32*" AND file_extension=".bat"

Monitor for unexpected deletion of a file in order to manipulate external outcomes or hide activity

Monitor for unexpected deletion of a file in order to manipulate external outcomes or hide activity

Monitor for missing log files from machines with known active periods.

Monitor for unexpected deletion of Windows event logs (via native binaries) and may also generate an alterable event (Event ID 1102: "The audit log was cleared"). When an eventlog is cleared, a new event is created that alerts that the eventlog was cleared. For Security logs, its event code 1100 and 1102. For System logs, it is event code 104.

It is unlikely that event log data would be cleared during normal operations, and it is likely that malicious attackers may try to cover their tracks by clearing an event log. When an event log gets cleared, it is suspicious.

1. This is often done using wevtutil, a legitimate tool provided by Microsoft. This action interferes with event collection and notification, and may lead to a security event going undetected, thereby potentially leading to further compromise of the network.

2. Alerting when a Clear Event Log is generated could point to this intruder technique. Centrally collecting events has the added benefit of making it much harder for attackers to cover their tracks. Event Forwarding permits sources to forward multiple copies of a collected event to multiple collectors, thus enabling redundant event collection. Using a redundant event collection model can minimize the single point of failure risk.

3. Attackers may set the option of the sources of events with Limit-EventLog -LogName Security -OverflowAction DoNotOverwrite to not delete old Evenlog when the .evtx is full. By default the Security Log size is configured with the minimum value of 20 480KB (~23 000 EventLog). So if this option is enabled, all the new EventLogs will be automatically deleted. We can detect this behavior with the Security EventLog 1104.

4. Attackers may delete .evtx with del C:\Windows\System32\winevt\logs\Security.evtx or Remove-Item C:\Windows\System32\winevt\logs\Security.evtx after having disabled and stopped the Eventlog service. As the EventLog service is disabled and stopped, the .evtx files are no longer used by this service and can be deleted. The new EventLog will be Unavailable until the configuration is reset.

5. Attackers may use the powershell command Remove-EventLog -LogName Security to unregister source of events that are part of Windows (Application, Security…). This command deletes the security EventLog (which also generates EventId 1102) but the new Eventlogs are still recorded until the system is rebooted . After the System is rebooted, the Security log is unregistered and doesn’t log any new Eventlog. However logs generated between the command and the reboot are still available in the .evtx file.

Analytic 1 - User Activity from Clearing Event Logs

(source="WinEventLog:Security" EventCode IN (1100, 1102, 1104)) OR (source="WinEventLog:System" EventCode IN (104))

Monitor for unexpected deletion of a system log file, typically stored in /var/logs or /Library/Logs.

Monitor for unexpected deletion of a command history file, such as ConsoleHost_history.txt, ~/.zsh_history, or ~/.bash_history.

Analytic 1 - Deletion of command history files

(source="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode="23") OR (source="WinEventLog:Security" EventCode="4663") FilePath LIKE '%ConsoleHost_history.txt%' AND ObjectType == "File" AND (UserAccessList LIKE '%1537%' OR UserAccessList LIKE '%DELETE%'))

Monitor for unexpected deletion of files from the system

Monitor for deletion of generated artifacts on a host system, including logs or captured files such as quarantined emails.

On Windows 10, mail application data is stored in C:\Users\Username\AppData\Local\Comms\Unistore\data. On Linux, mail data is stored in /var/spool/mail or /var/mail. On macOS, mail data is stored in ~/Library/Mail.

Monitor for a file that may delete or alter generated artifacts associated with persistence on a host system.

Monitor the file system for files that have the setuid or setgid bits set.

Monitor for contextual data about a file, which may include information such as name, the content (ex: signature, headers, or data/media), user/owner, permissions, etc that would aid in the manipulation of data to hide activity

Changes to binaries that do not line up with application updates or patches are also extremely suspicious.

Consider enabling file/directory permission change auditing on folders containing key binary/configuration files. For example, Windows Security Log events (Event ID 4670) are created when DACLs are modified.

Adversaries sometimes modify object access rights at the operating system level. There are varying motivations behind this action - they may not want some files/objects to be changed on systems for persistence reasons and therefore provide admin only rights; also, they may want files to be accessible with lower levels of permissions.

Windows environment logs can be noisy, so we take the following into consideration:

• We need to exclude events generated by the local system (subject security ID "NT AUTHORITY\SYSTEM") and focus on actual user events.
• When a permission modification is made for a folder, a new event log is generated for each subfolder and file under that folder. It is advised to group logs based on handle ID or user ID.
• The Windows security log (event ID 4670) also includes information about the process that modifies the file permissions. It is advised to focus on uncommon process names, and it is also uncommon for real-users to perform this task without a GUI.
• Pseudocode Event ID is for Windows Security Log (Event ID 4670 - Permissions on an object were changed).
• Windows Event ID 4719 (An Attempt Was Made to Access An Object) can also be used to alert on changes to Active Directory audit policy for a system.

Analytic 1 - Access Permission Modification for Windows

(source="*WinEventLog:Security" EventCode IN (4670, 4719)) Object_Type="File" Security_ID!="NT AUTHORITY\SYSTEM"

Monitor and investigate attempts to modify ACLs and file/directory ownership. Consider enabling file/directory permission change auditing on folders containing key binary/configuration files.

This looks for any invocations of chmod. Note that this is likely to be more noisy than the Windows-specific implementation, although Linux does not generate logs for system triggered activities like in Windows. In addition, it may be necessary to whitelist cron jobs that regularly run and execute chmod.

Linux environment logs can be more noisy than the Windows-specific implementation, although Linux does not generate logs for system triggered activities like in Windows. In addition, it may be necessary to whitelist cron jobs that regularly run and execute chmod.

Analytic 1 - Access Permission Modification for Linux

source="linux:" CommandLine="chmod*"

Monitor for contextual data about a file, which may include information such as name, the content (ex: signature, headers, or data/media), user/owner, permissions may set files and directories to be hidden to evade detection mechanisms.

Monitor for contextual data about a file, which may include information such as name, the content (ex: signature, headers, or data/media), user/owner, permissions, may use NTFS file attributes to hide their malicious data in order to evade detection. Forensic techniques exist to identify information stored in NTFS EA. ^[17]

If the document is opened with a Graphical User Interface (GUI) the malicious p-code is decompiled and may be viewed. However, if the PROJECT stream, which specifies the project properties, is modified in a specific way the decompiled VBA code will not be displayed. For example, adding a module name that is undefined to the PROJECT stream will inhibit attempts of reading the VBA source code through the GUI.^[18]

Identify files with the com.apple.ResourceFork extended attribute and large data amounts stored in resource forks.

Monitor for file modifications that collects information on file handle opens and can compare timestamp values

Collect and analyze signing certificate metadata and check signature validity on software that executes within the environment, look for invalid signatures as well as unusual certificate characteristics and outliers.

Monitor for common formats of RTLO characters within filenames such as \u202E, [U+202E], and %E2%80%AE. Defenders should also check their analysis tools to ensure they do not interpret the RTLO character and instead print the true name of the file containing it.

Collecting and comparing disk and resource filenames for binaries by looking to see if the InternalName, OriginalFilename, and/or ProductName match what is expected could provide useful leads, but may not always be indicative of malicious activity.

Collect file hashes; file names that do not match their expected hash are suspect. Perform file monitoring; files with known names but in unusual locations are suspect. Likewise, files that are modified outside of an update or patch are suspect.

Monitor for spaces at the end of file names, that can easily be checked with file monitoring. From the user's perspective though, this is very hard to notice from within the Finder.app or on the command-line in Terminal.app. Processes executed from binaries containing non-standard extensions in the filename are suspicious.

Monitor for contextual data about a file, which may include information such as name, the content (ex: signature, headers, or data/media), user/owner, permissions, etc.

Depending on the method used to pad files, a file-based signature may be capable of detecting padding using a scanning or on-access based tool. When executed, the resulting process from padded files may also exhibit other behavior characteristics of being used to conduct an intrusion such as system and network information Discovery or Lateral Movement, which could be used as event indicators that point to the source file.

Use file scanning to look for known software packers or artifacts of packing techniques. Packing is not a definitive indicator of malicious activity, because legitimate software may use packing techniques to reduce binary size or to protect proprietary code.

Detection of steganography is difficult unless artifacts are left behind by the obfuscation process that are detectable with a known signature. Look for strings or other signatures left in system artifacts related to decoding steganography.

Monitor for contextual data about a file, which may include information such as name, the content (ex: signature, headers, or data/media), user/owner, permissions, etc.

Depending on the method used to obfuscate API function calls, a file-based signature may be capable of detecting dynamical resolution.^[21][22][23]

Detecting the presence of stripped payloads may be difficult and unwarranted in real-time, though analyzing contextual data about files (such as content and character entropy) may highlight attempts at obfuscation.

Monitor contextual data about a file that may highlight embedded payloads, which may include information such as name, the content (ex: signature, headers, or data/media), file size, etc.; correlate with other suspicious behavior to reduce false positives.

Scripts containing obfuscated content may have higher entropy of characters/strings.

Monitor contextual data about a file that may highlight embedded malicious content, which may include information such as name, the content (ex: signature, headers, or data/media), file size, etc.; correlate with other suspicious behavior to reduce false positives.

Monitor for and analyze files which contain content with large entropy, as this may indicate potentially malicious compressed or encrypted data.

Scan file objects reported during the PsSetCreateProcessNotifyRoutine, ^[24] which triggers a callback whenever a process is created or deleted, specifically looking for file objects with enabled write access. ^[25] Also consider comparing file objects loaded in memory to the corresponding file on disk. ^[26]

Review false values under the LSFileQuarantineEnabled entry in an application's Info.plist file (required by every application). false under LSFileQuarantineEnabled indicates that an application does not use the quarantine flag. Unsandboxed applications with an unspecified LSFileQuarantineEnabled entry will default to not setting the quarantine flag.

QuarantineEvents is a SQLite database containing a list of all files assigned the com.apple.quarantine attribute, located at ~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2. Each event contains the corresponding UUID, timestamp, application, Gatekeeper score, and decision if it was allowed. ^[27]

Collect and analyze signing certificate metadata on software that executes within the environment to look for unusual certificate characteristics and outliers.

Monitor files (especially those downloaded from untrusted locations) for MOTW attributes. Also consider inspecting and scanning file formats commonly abused to bypass MOTW (ex: .arj, .gzip, .iso, .vhd).

Use verification of distributed binaries through hash checking or other integrity checking mechanisms. Scan downloads for malicious signatures and attempt to test software and updates prior to deployment while taking note of potential suspicious activity.

Use verification of distributed binaries through hash checking or other integrity checking mechanisms. Scan downloads for malicious signatures and attempt to test software and updates prior to deployment while taking note of potential suspicious activity.

Monitor for changes made to files that may perform shell escapes or exploit vulnerabilities in an application with the setsuid or setgid bits to get code running in a different user’s context.

On Linux, auditd can alert every time a user's actual ID and effective ID are different (this is what happens when you sudo). This technique is abusing normal functionality in macOS and Linux systems, but sudo has the ability to log all input and output based on the LOG_INPUT and LOG_OUTPUT directives in the /etc/sudoers file.

Monitor for changes to files associated with TCC settings, such as /Library/Application Support/com.apple.TCC/TCC.db.

Monitor for changes made to detect changes made to the authorized_keys file for each user on a system. Monitor for changes to and suspicious processes modifiying /etc/ssh/sshd_config.

Monitor the start folder for additions or changes. Tools such as Sysinternals Autoruns may also be used to detect system changes that could be attempts at persistence, including the startup folders. ^[28]

Monitor for changes made to files that may modify the kernel to automatically execute programs on system boot.

Monitoring the specific plist files associated with reopening applications can indicate when an application has registered itself to be reopened.

Monitor for changes made to files that may modify or add LSASS drivers to obtain persistence on compromised systems.

Since a shortcut's target path likely will not change, modifications to shortcut files that do not correlate with known software changes, patches, removal, etc., may be suspicious. Analysis should attempt to relate shortcut file change events to other potentially suspicious events based on known adversary behavior such as process launches of unknown executables that make network connections.

Malicious XDG autostart entries may be detected by auditing file modification events within the /etc/xdg/autostart and ~/.config/autostart directories. Depending on individual configurations, defenders may need to query the environment variables $XDG_CONFIG_HOME or $XDG_CONFIG_DIRS to determine the paths of Autostart entries. Autostart entry files not associated with legitimate packages may be considered suspicious. Suspicious entries can also be identified by comparing entries to a trusted system baseline.

All login items created via shared file lists are viewable by using the System Preferences GUI or in the ~/Library/Application Support/com.apple.backgroundtaskmanagementagent/backgrounditems.btm file.^{[9][10][11][12]} These locations should be monitored and audited.

Monitor for changes to login hook files (/Library/Preferences/com.apple.loginwindow.plist), especially by unusual accounts outside of normal administration duties.

Monitor for changes made to files for unexpected modifications to unusual accounts outside of normal administration duties

Monitor for changes made to files for unexpected modifications to RC scripts in the /etc/ directory

Monitor for changes made to files for unexpected modifications to /Library/StartupItem folder

Launch Agents also require files on disk for persistence which can also be monitored via other file monitoring applications.

Systemd service unit files may be detected by auditing file creation and modification events within the /etc/systemd/system, /usr/lib/systemd/system/, and /home//.config/systemd/user/ directories, as well as associated symbolic links

Monitor files for changes that may create or modify Launch Daemons to execute malicious payloads as part of persistence.

Monitor for unexpected files with manipulated data in order to manipulate external outcomes or hide activity

Monitor for unexpected files with manipulated data in order to manipulate external outcomes or hide activity

Monitor internal and websites for unplanned content changes.

Monitor external websites for unplanned content changes.

Monitor for changes made to files that may establish persistence by executing malicious content triggered by user inactivity.

Note: Although there are no standard events for file modification, Windows Event ID 4663 (An Attempt Was Made to Access An Object) can be used to alert on attempted accesses of screensaver files (typically ending in a file extension of .scr).

Monitor for changes to /etc/profile and /etc/profile.d, these files should only be modified by system administrators. MacOS users can leverage Endpoint Security Framework file events monitoring these specific files.^[29]

Monitor for changes made to files that may establish persistence by executing malicious content triggered by an interrupt signal.

Monitor file systems for changes to application binaries and invalid checksums/signatures.

Monitor for changes made to files that may establish persistence and/or elevate privileges by executing malicious content triggered by accessibility features. Changes to accessibility utility binaries or binary paths that do not correlate with known software, patch cycles, etc., are suspicious.

Monitor for changes made to files that may establish persistence and/or elevate privileges by executing malicious content triggered by application shims.

Locations where profile.ps1 can be stored should be monitored for modifications. ^[14] Example profile locations include:* $PsHome\Profile.ps1* $PsHome\Microsoft.{HostProgram}_profile.ps1* $Home\My Documents\PowerShell\Profile.ps1* $Home\My Documents\PowerShell\Microsoft.{HostProgram}_profile.ps1

Monitor emond rules creation by checking for files modified in /etc/emond.d/rules/ and /private/var/db/emondClients.

Monitor for changes made to files that may use hidden users to mask the presence of user accounts they create or modify. Monitor for changes made to the /Library/Preferences/com.apple.loginwindow plist file for unexpected modifications to the Hide500Users key value on macOS.^[30]

Monitor for changes made to files that may use hidden windows to conceal malicious activity from the plain sight of users. In MacOS, plist files are ASCII text files with a specific format, so they're relatively easy to parse. File monitoring can check for the apple.awt.UIElement or any other suspicious plist tag in plist files and flag them.

There are many ways to create and interact with ADSs using Windows utilities. Monitor for operations (execution, copies, etc.) with file names that contain colons. This syntax (ex: file.ext:ads[.ext]) is commonly associated with ADSs. ^{[31] [32] [33]} For a more exhaustive list of utilities that can be used to execute and create ADSs, see https://gist.github.com/api0cradle/cdd2d0d0ec9abb686f0e89306e277b8f.

Detecting the use of a hidden file system may be exceptionally difficult depending on the implementation. Emphasis may be placed on detecting related aspects of the adversary lifecycle, such as how malware interacts with the hidden file system or how a hidden file system is loaded.

On MacOS systems, monitor for modifications to the RulesActiveState.plist, SyncedRules.plist, UnsyncedRules.plist, and MessageRules.plist files.^[34]

Monitor for changed made to .manifest/.local redirection files, or file systems for moving, renaming, replacing, or modifying DLLs. Changes in the set of DLLs that are loaded by a process (compared with past behavior) that do not correlate with known software, patches, etc., are suspicious.

Monitor for changes made to files for unexpected modifications to access permissions and attributes

Monitor file systems for moving, renaming, replacing, or modifying dylibs. Changes in the set of dylibs that are loaded by a process (compared to past behavior) that do not correlate with known software, patches, etc., are suspicious. Check the system for multiple dylibs with the same name and monitor which versions have historically been loaded into a process.

Monitor for changes to binaries and service executables that may normally occur during software updates.

Monitor for changes to environment variables and files associated with loading shared libraries such as LD_PRELOAD on Linux and DYLD_INSERT_LIBRARIES on macOS.

Monitor for programs metadata modifications such as deletion of the path to an executable since it makes programs vulnerable to this type of technique. Also, monitor modifications of files such as renaming programs using Windows system utilities names.

Monitor for changes made to files that may execute their own malicious payloads by hijacking vulnerable file path references.

Monitor for modification of binaries and service executables that do not occur during a regular software update or an update scheduled by the organization. Modification of files considers actions such as renaming and directory moving.

Monitor changes made to the /etc/audit/audit.rules file containing the sequence of auditctl commands loaded at boot time.

Monitor for changes made to system log files, typically stored in /var/log or /Library/Logs, for unexpected modifications to access permissions and attributes

Monitor for changes made to command history files, such as ConsoleHost_history.txt, ~/.zsh_history, or ~/.bash_history, for unexpected modifications to contents, access permissions, and attributes.

Analytic 1 : Modification of access rights to command history files

(source="WinEventLog:Security" EventCode IN (4663, 4670) AND Path="ConsoleHost_history.txt" AND ObjectType="File") AND (UserAccessList="1539" OR UserAccessList="WRITE_DAC") OR (ObjectNewSd=";FA" OR ObjectNewSd=";FW" OR ObjectNewSd=";BU*")

Monitor for unexpected modifications to file timestamps

Monitor changes to files that may be indicators of deleting or altering malicious network configuration settings as well as generated artifacts on a host system that highlight network connection history, such as Default.rdp or /var/log/.

Monitor for changes made to generated artifacts on a host system, including logs or captured files such as quarantined emails.

On Windows 10, mail application data is stored in C:\Users\Username\AppData\Local\Comms\Unistore\data. On Linux, mail data is stored in /var/spool/mail or /var/mail. On macOS, mail data is stored in ~/Library/Mail.

Monitor for changes made to a file may delete or alter generated artifacts associated with persistence on a host system.

Monitor for changes made to detect changes to files in the Web directory for organization login pages that do not match with authorized updates to the Web server's content.

Monitor for changes made to files for unexpected modifications to file names that are mismatched between the file name on disk and that of the binary's PE metadata. This is a likely indicator that a binary was renamed after it was compiled.

Note: There are no standard Windows events for file modification. However, Event ID 4663 (An attempt was made to access an object) can be used to audit and alert on attempts to access system utility binaries; the "Accesses" field can be used to filter by type of access (e.g., MODIFY vs DELETE).

Check and ensure that file headers/signature and extensions match using magic bytes detection and/or file signature validation.^[19] In Linux, the file command may be used to check the file signature.^[20]

Monitor for changes to functions exported from authentication-related system DLLs (such as cryptdll.dll and samsrv.dll).^[35]

Monitor PAM configuration and module paths (ex: /etc/pam.d/) for changes. Use system-integrity tools such as AIDE and monitoring tools such as auditd to monitor PAM files.

Monitor for changes made to the checksum of the operating system file and verifying the image of the operating system in memory.^[36][37] Detection of this behavior may be difficult, detection efforts may be focused on closely related adversary behaviors, such as Modify System Image.

Monitor for suspicious modification of files associated with hybrid identity authentication processes, such as configuration files. Monitor for access to certificates and cryptographic keys material.

Compare the checksum of the operating system file with the checksum of a known good copy from a trusted source. Some embedded network device platforms may have the capability to calculate the checksum of the file, while others may not. Even for those platforms that have the capability, it is recommended to download a copy of the file to a trusted computer to calculate the checksum with software that is not compromised.https://tools.cisco.com/security/center/resources/integrity_assurance.html#7

Many vendors of embedded network devices can provide advanced debugging support that will allow them to work with device owners to validate the integrity of the operating system running in memory. If a compromise of the operating system is suspected, contact the vendor technical support and seek such services for a more thorough inspection of the current running system. https://tools.cisco.com/security/center/resources/integrity_assurance.html#13

Monitor for changes made to the operating system of a network device because image downgrade may be used in conjunction with  Patch System Image, it may be appropriate to also verify the integrity of the vendor provided operating system image file.

Monitor for changes made to files that may abuse Microsoft Office templates to obtain persistence on a compromised system. Modification to base templates, like Normal.dotm, should also be investigated since the base templates should likely not contain VBA macros. Changes to the Office macro security settings should also be investigated

Monitor for changes made to files that may abuse the Microsoft Office "Office Test" Registry key to obtain persistence on a compromised system.

Monitor for changes made to files that may abuse Microsoft Office add-ins to obtain persistence on a compromised system.

Monitor for changes made to /proc files that may inject malicious code into processes via the /proc filesystem in order to evade process-based defenses as well as possibly elevate privileges. Users should not have permission to modify these in most cases.

On Windows, monitor Windows Task Scheduler stores in %systemroot%\System32\Tasks for change entries related to scheduled tasks, especially those that do not correlate with known software, patch cycles, etc. On Linux and macOS, all at jobs are stored in /var/spool/cron/atjobs/.^[39]

Monitor for changes made to files for unexpected modifications to access permissions and attributes.

Analytic 1 - Modified Files in Linux Cron Directories

source="Linux:" (Path LIKE "/etc/cron.allow.d" OR Path LIKE "/etc/cron.d/" OR Path LIKE "/etc/cron.hourly" OR Path LIKE "/etc/cron.daily" OR Path LIKE "/etc/cron.weeky" OR Path LIKE "/etc/cron.monthly")

Monitor Windows Task Scheduler stores in %systemroot%\System32\Tasks for change entries related to scheduled tasks that do not correlate with known software, patch cycles, etc.

Monitor for changes made to systemd timer unit files for unexpected modification events within the /etc/systemd/system, /usr/lib/systemd/system/, and ~/.config/systemd/user/ directories, as well as associated symbolic links

Monitor for changes made to files that may backdoor web servers with web shells to establish persistent access to systems.

Monitor for modification of files (especially DLLs on webservers) that could be abused as malicious ISAPI extensions/filters or IIS modules. Changes to %windir%\system32\inetsrv\config\applicationhost.config could indicate an IIS module installation.^[40][41]

Monitor unexpected changes and/or interactions with termsrv.dll, which is typically stored in %SystemRoot%\System32\.

The removal of the com.apple.quarantine flag by a user instead of the operating system is a suspicious action and should be examined further. Also monitor software update frameworks that may strip this flag when performing updates.

Periodically baseline registered SIPs and trust providers (Registry entries and files on disk), specifically looking for new, modified, or non-Microsoft entries.^[42] Also analyze Autoruns data for oddities and anomalies, specifically malicious files attempting persistent execution by hiding within auto-starting locations. Autoruns will hide entries signed by Microsoft or Windows by default, so ensure "Hide Microsoft Entries" and "Hide Windows Entries" are both deselected.^[42]

Every Launch Agent and Launch Daemon must have a corresponding plist file on disk which can be monitored. Plist files are located in the root, system, and users /Library/LaunchAgents or /Library/LaunchDaemons folders. Launch Agent or Launch Daemon with executable paths pointing to /tmp and /Shared folders locations are potentially suspicious.

There is no documented method for defenders to directly identify behaviors that reduce encryption key space. Detection efforts may be focused on closely related adversary behaviors, such as Modify System Image and Network Device CLI. Some detection methods require vendor support to aid in investigation.

There is no documented method for defenders to directly identify behaviors that reduce encryption key space. Detection efforts may be focused on closely related adversary behaviors, such as Modify System Image and Network Device CLI. Some detection methods require vendor support to aid in investigation.