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.^[2]

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

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 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.

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.^[5] 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.^[6][7][8][9] 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.

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. ^[10] 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 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 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 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 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 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 newly constructed files from a spearphishing emails with a malicious attachment in an attempt to gain access to victim systems.

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.^[12]

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).

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 unexpected deletion of Windows event logs (via native binaries) and may also generate an alterable event (Event ID 1102: "The audit log was cleared")

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.

Monitor for unexpected deletion of files from the 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/ower, 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.

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.

Monitor for contextual data about a file, which may include information such as name, the content (ex: signature, headers, or data/media), user/ower, 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/ower, 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. ^[13]

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.^[14]

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/ower, 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/ower, permissions, etc.

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

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. [18]

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).

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 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. ^[19]

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.^[6][7][8][9] 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.

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.^[20]

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. ^[10] 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.^[21]

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. ^{[22] [23] [24]} 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.^[25]

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 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.

Monitor for unexpected modifications to file timestamps

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.

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

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.^[27][28] Detection of this behavior may be difficult, detection efforts may be focused on closely related adversary behaviors, such as Modify System Image.

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/.^[30]

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

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.^[31][32]

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.^[33] 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.^[33]

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.