jq

clusters/mitre_attack-pattern.json

@@ -74,7 +74,7 @@
       }
     },
     {
-            "description": "Per Apple\u2019s developer documentation, when a user logs in, a per-user launchd process is started which loads the parameters for each launch-on-demand user agent from the property list (plist) files found in <code>/System/Library/LaunchAgents</code>, <code>/Library/LaunchAgents</code>, and <code>$HOME/Library/LaunchAgents</code>[[Citation: AppleDocs Launch Agent Daemons]][[Citation: OSX Keydnap malware]][[Citation: Antiquated Mac Malware]].  These launch agents have property list files which point to the executables that will be launched[[Citation: OSX.Dok Malware]].\n \nAdversaries may install a new launch agent that can be configured to execute at login by using launchd or launchctl to load a plist into the appropriate directories [[Citation: Sofacy Komplex Trojan]] [[Citation: Methods of Mac Malware Persistence]]. The agent name may be disguised by using a name from a related operating system or benign software. Launch Agents are created with user level privileges and are executed with the privileges of the user when they log in[[Citation: OSX Malware Detection]][[Citation: OceanLotus for OS X]]. They can be set up to execute when a specific user logs in (in the specific user\u2019s directory structure) or when any user logs in (which requires administrator privileges).\n\nDetection: Monitor Launch Agent creation through additional plist files and utilities such as Objective-See\u2019s  KnockKnock application. Launch Agents also require files on disk for persistence which can also be monitored via other file monitoring applications.\n\nPlatforms: MacOS, OS X\n\nData Sources: File monitoring, Process Monitoring",
+      "description": "Per Apple’s developer documentation, when a user logs in, a per-user launchd process is started which loads the parameters for each launch-on-demand user agent from the property list (plist) files found in <code>/System/Library/LaunchAgents</code>, <code>/Library/LaunchAgents</code>, and <code>$HOME/Library/LaunchAgents</code>[[Citation: AppleDocs Launch Agent Daemons]][[Citation: OSX Keydnap malware]][[Citation: Antiquated Mac Malware]].  These launch agents have property list files which point to the executables that will be launched[[Citation: OSX.Dok Malware]].\n \nAdversaries may install a new launch agent that can be configured to execute at login by using launchd or launchctl to load a plist into the appropriate directories [[Citation: Sofacy Komplex Trojan]] [[Citation: Methods of Mac Malware Persistence]]. The agent name may be disguised by using a name from a related operating system or benign software. Launch Agents are created with user level privileges and are executed with the privileges of the user when they log in[[Citation: OSX Malware Detection]][[Citation: OceanLotus for OS X]]. They can be set up to execute when a specific user logs in (in the specific user’s directory structure) or when any user logs in (which requires administrator privileges).\n\nDetection: Monitor Launch Agent creation through additional plist files and utilities such as Objective-See’s  KnockKnock application. Launch Agents also require files on disk for persistence which can also be monitored via other file monitoring applications.\n\nPlatforms: MacOS, OS X\n\nData Sources: File monitoring, Process Monitoring",
       "value": "Launch Agent",
       "meta": {
         "mitre_data_sources": [
@@ -131,7 +131,7 @@
       }
     },
     {
-            "description": "Windows uses access tokens to determine the ownership of a running process.  A user can manipulate access tokens to make a running process appear as though it belongs to someone other than the user that started the process.  When this occurs, the process also takes on the security context associated with the new token.  For example, Microsoft promotes the use of access tokens as a security best practice.  Administrators should log in as a standard user but run their tools with administrator privileges using the built-in access token manipulation command <code>runas</code>. [[Citation: Microsoft runas]]\n  \nAdversaries may use access tokens to operate under a different user or system security context to perform actions and evade detection.   An adversary can use built-in Windows API functions to copy access tokens from existing processes; this is known as token stealing.  An adversary must already be in a privileged user context (i.e. administrator) to steal a token.  However, adversaries commonly use token stealing to elevate their security context from the administrator level to the SYSTEM level.[[Citation: Pentestlab Token Manipulation]]\n\nAdversaries can also create spoofed access tokens if they know the credentials of a user.  Any standard user can use the <code>runas</code> command, and the Windows API functions, to do this; it does not require access to an administrator account.\n\nLastly, an adversary can use a spoofed token to authenticate to a remote system as the account for that token if the account has appropriate permissions on the remote system.\n\nMetasploit\u2019s Meterpreter payload allows arbitrary token stealing and uses token stealing to escalate privileges. [[Citation: Metasploit access token]]  The Cobalt Strike beacon payload allows arbitrary token stealing and can also create tokens. [[Citation: Cobalt Strike Access Token]]\n\nDetection: If an adversary is using a standard command-line shell, analysts can detect token manipulation by auditing command-line activity.  Specifically, analysts should look for use of the <code>runas</code> command. Detailed command-line logging is not enabled by default in Windows.[[Citation: Microsoft Command-line Logging]]\n\nIf an adversary is using a payload that calls the Windows token APIs directly, analysts can detect token manipulation only through careful analysis of user network activity, examination of running processes, and correlation with other endpoint and network behavior.  \n\nThere are many Windows API calls a payload can take advantage of to manipulate access tokens (e.g., <code>LogonUser</code>[[Citation: Microsoft LogonUser]], <code>DuplicateTokenEx</code>[[Citation: Microsoft DuplicateTokenEx]], and <code>ImpersonateLoggedOnUser</code>[[Citation: Microsoft ImpersonateLoggedOnUser]]).  Please see the referenced Windows API pages for more information.\n\nPlatforms: Windows Server 2003, Windows Server 2008, Windows Server 2012, Windows XP, Windows 7, Windows 8, Windows Server 2003 R2, Windows Server 2008 R2, Windows Server 2012 R2, Windows Vista, Windows 8.1, Windows 10\n\nEffective Permissions: SYSTEM\n\nContributors: Tom Ueltschi @c_APT_ure",
+      "description": "Windows uses access tokens to determine the ownership of a running process.  A user can manipulate access tokens to make a running process appear as though it belongs to someone other than the user that started the process.  When this occurs, the process also takes on the security context associated with the new token.  For example, Microsoft promotes the use of access tokens as a security best practice.  Administrators should log in as a standard user but run their tools with administrator privileges using the built-in access token manipulation command <code>runas</code>. [[Citation: Microsoft runas]]\n  \nAdversaries may use access tokens to operate under a different user or system security context to perform actions and evade detection.   An adversary can use built-in Windows API functions to copy access tokens from existing processes; this is known as token stealing.  An adversary must already be in a privileged user context (i.e. administrator) to steal a token.  However, adversaries commonly use token stealing to elevate their security context from the administrator level to the SYSTEM level.[[Citation: Pentestlab Token Manipulation]]\n\nAdversaries can also create spoofed access tokens if they know the credentials of a user.  Any standard user can use the <code>runas</code> command, and the Windows API functions, to do this; it does not require access to an administrator account.\n\nLastly, an adversary can use a spoofed token to authenticate to a remote system as the account for that token if the account has appropriate permissions on the remote system.\n\nMetasploit’s Meterpreter payload allows arbitrary token stealing and uses token stealing to escalate privileges. [[Citation: Metasploit access token]]  The Cobalt Strike beacon payload allows arbitrary token stealing and can also create tokens. [[Citation: Cobalt Strike Access Token]]\n\nDetection: If an adversary is using a standard command-line shell, analysts can detect token manipulation by auditing command-line activity.  Specifically, analysts should look for use of the <code>runas</code> command. Detailed command-line logging is not enabled by default in Windows.[[Citation: Microsoft Command-line Logging]]\n\nIf an adversary is using a payload that calls the Windows token APIs directly, analysts can detect token manipulation only through careful analysis of user network activity, examination of running processes, and correlation with other endpoint and network behavior.  \n\nThere are many Windows API calls a payload can take advantage of to manipulate access tokens (e.g., <code>LogonUser</code>[[Citation: Microsoft LogonUser]], <code>DuplicateTokenEx</code>[[Citation: Microsoft DuplicateTokenEx]], and <code>ImpersonateLoggedOnUser</code>[[Citation: Microsoft ImpersonateLoggedOnUser]]).  Please see the referenced Windows API pages for more information.\n\nPlatforms: Windows Server 2003, Windows Server 2008, Windows Server 2012, Windows XP, Windows 7, Windows 8, Windows Server 2003 R2, Windows Server 2008 R2, Windows Server 2012 R2, Windows Vista, Windows 8.1, Windows 10\n\nEffective Permissions: SYSTEM\n\nContributors: Tom Ueltschi @c_APT_ure",
       "value": "Access Token Manipulation",
       "meta": {
         "mitre_platforms": [
@@ -406,7 +406,7 @@
       }
     },
     {
-            "description": "Per Apple\u2019s documentation, startup items execute during the final phase of the boot process and contain shell scripts or other executable files along with configuration information used by the system to determine the execution order for all startup items[[Citation: Startup Items]]. This is technically a deprecated version (superseded by Launch Daemons), and thus the appropriate folder, <code>/Library/StartupItems</code> isn\u2019t guaranteed to exist on the system by default, but does appear to exist by default on macOS Sierra. A startup item is a directory whose executable and configuration property list (plist), <code>StartupParameters.plist</code>, reside in the top-level directory. \n\nAn adversary can create the appropriate folders/files in the StartupItems directory to register their own persistence mechanism[[Citation: Methods of Mac Malware Persistence]]. Additionally, since StartupItems run during the bootup phase of macOS, they will run as root. If an adversary is able to modify an existing Startup Item, then they will be able to Privilege Escalate as well.\n\nDetection: The <code>/Library/StartupItems</code> folder can be monitored for changes. Similarly, the programs that are actually executed from this mechanism should be checked against a whitelist. Monitor processes that are executed during the bootup process to check for unusual or unknown applications and behavior.\n\nPlatforms: MacOS, OS X\n\nData Sources: File monitoring, Process Monitoring\n\nEffective Permissions: root",
+      "description": "Per Apple’s documentation, startup items execute during the final phase of the boot process and contain shell scripts or other executable files along with configuration information used by the system to determine the execution order for all startup items[[Citation: Startup Items]]. This is technically a deprecated version (superseded by Launch Daemons), and thus the appropriate folder, <code>/Library/StartupItems</code> isn’t guaranteed to exist on the system by default, but does appear to exist by default on macOS Sierra. A startup item is a directory whose executable and configuration property list (plist), <code>StartupParameters.plist</code>, reside in the top-level directory. \n\nAn adversary can create the appropriate folders/files in the StartupItems directory to register their own persistence mechanism[[Citation: Methods of Mac Malware Persistence]]. Additionally, since StartupItems run during the bootup phase of macOS, they will run as root. If an adversary is able to modify an existing Startup Item, then they will be able to Privilege Escalate as well.\n\nDetection: The <code>/Library/StartupItems</code> folder can be monitored for changes. Similarly, the programs that are actually executed from this mechanism should be checked against a whitelist. Monitor processes that are executed during the bootup process to check for unusual or unknown applications and behavior.\n\nPlatforms: MacOS, OS X\n\nData Sources: File monitoring, Process Monitoring\n\nEffective Permissions: root",
       "value": "Startup Items",
       "meta": {
         "mitre_data_sources": [
@@ -524,7 +524,7 @@
       }
     },
     {
-            "description": "Keychains are the built-in way for macOS to keep track of users' passwords and credentials for many services and features such as WiFi passwords, websites, secure notes, certificates, and Kerberos. Keychain files are located in <code>~/Library/Keychains/</code>,<code>/Library/Keychains/</code>, and <code>/Network/Library/Keychains/</code>.[[Citation: Wikipedia keychain]] The <code>security</code> command-line utility, which is built into macOS by default, provides a useful way to manage these credentials.\n\nTo manage their credentials, users have to use additional credentials to access their keychain. If an adversary knows the credentials for the login keychain, then they can get access to all the other credentials stored in this vault.[[Citation: External to DA, the OS X Way]] By default, the passphrase for the keychain is the user\u2019s logon credentials.\n\nDetection: Unlocking the keychain and using passwords from it is a very common process, so there is likely to be a lot of noise in any detection technique. Monitoring of system calls to the keychain can help determine if there is a suspicious process trying to access it.\n\nPlatforms: MacOS, OS X\n\nData Sources: System calls, Process Monitoring",
+      "description": "Keychains are the built-in way for macOS to keep track of users' passwords and credentials for many services and features such as WiFi passwords, websites, secure notes, certificates, and Kerberos. Keychain files are located in <code>~/Library/Keychains/</code>,<code>/Library/Keychains/</code>, and <code>/Network/Library/Keychains/</code>.[[Citation: Wikipedia keychain]] The <code>security</code> command-line utility, which is built into macOS by default, provides a useful way to manage these credentials.\n\nTo manage their credentials, users have to use additional credentials to access their keychain. If an adversary knows the credentials for the login keychain, then they can get access to all the other credentials stored in this vault.[[Citation: External to DA, the OS X Way]] By default, the passphrase for the keychain is the user’s logon credentials.\n\nDetection: Unlocking the keychain and using passwords from it is a very common process, so there is likely to be a lot of noise in any detection technique. Monitoring of system calls to the keychain can help determine if there is a suspicious process trying to access it.\n\nPlatforms: MacOS, OS X\n\nData Sources: System calls, Process Monitoring",
       "value": "Keychain",
       "meta": {
         "mitre_data_sources": [
@@ -801,7 +801,7 @@
       }
     },
     {
-            "description": "Per Apple\u2019s developer documentation, when macOS and OS X boot up, launchd is run to finish system initialization. This process loads the parameters for each launch-on-demand system-level daemon from the property list (plist) files found in <code>/System/Library/LaunchDaemons</code> and <code>/Library/LaunchDaemons</code>[[Citation: AppleDocs Launch Agent Daemons]]. These LaunchDaemons have property list files which point to the executables that will be launched[[Citation: Methods of Mac Malware Persistence]].\n \nAdversaries may install a new launch daemon that can be configured to execute at startup by using launchd or launchctl to load a plist into the appropriate directories[[Citation: OSX Malware Detection]]. The daemon name may be disguised by using a name from a related operating system or benign software [[Citation: WireLurker]]. Launch Daemons may be created with administrator privileges, but are executed under root privileges, so an adversary may also use a service to escalate privileges from administrator to root.\n \nThe plist file permissions must be root:wheel, but the script or program that it points to has no such requirement. So, it is possible for poor configurations to allow an adversary to modify a current Launch Daemon\u2019s executable and gain persistence or Privilege Escalation.\n\nDetection: Monitor Launch Daemon creation through additional plist files and utilities such as Objective-See's Knock Knock application.\n\nPlatforms: MacOS, OS X\n\nData Sources: Process Monitoring, File monitoring\n\nEffective Permissions: root",
+      "description": "Per Apple’s developer documentation, when macOS and OS X boot up, launchd is run to finish system initialization. This process loads the parameters for each launch-on-demand system-level daemon from the property list (plist) files found in <code>/System/Library/LaunchDaemons</code> and <code>/Library/LaunchDaemons</code>[[Citation: AppleDocs Launch Agent Daemons]]. These LaunchDaemons have property list files which point to the executables that will be launched[[Citation: Methods of Mac Malware Persistence]].\n \nAdversaries may install a new launch daemon that can be configured to execute at startup by using launchd or launchctl to load a plist into the appropriate directories[[Citation: OSX Malware Detection]]. The daemon name may be disguised by using a name from a related operating system or benign software [[Citation: WireLurker]]. Launch Daemons may be created with administrator privileges, but are executed under root privileges, so an adversary may also use a service to escalate privileges from administrator to root.\n \nThe plist file permissions must be root:wheel, but the script or program that it points to has no such requirement. So, it is possible for poor configurations to allow an adversary to modify a current Launch Daemon’s executable and gain persistence or Privilege Escalation.\n\nDetection: Monitor Launch Daemon creation through additional plist files and utilities such as Objective-See's Knock Knock application.\n\nPlatforms: MacOS, OS X\n\nData Sources: Process Monitoring, File monitoring\n\nEffective Permissions: root",
       "value": "Launch Daemon",
       "meta": {
         "mitre_data_sources": [
@@ -1100,7 +1100,7 @@
       }
     },
     {
-            "description": "In OS X prior to El Capitan, users with root access can read plaintext keychain passwords of logged-in users because Apple\u2019s keychain implementation allows these credentials to be cached so that users are not repeatedly prompted for passwords.[[Citation: OS X Keychain]][[Citation: External to DA, the OS X Way]] Apple\u2019s securityd utility takes the user\u2019s logon password, encrypts it with PBKDF2, and stores this master key in memory. Apple also uses a set of keys and algorithms to encrypt the user\u2019s password, but once the master key is found, an attacker need only iterate over the other values to unlock the final password.[[Citation: OS X Keychain]]\n\nIf an adversary can obtain root access (allowing them to read securityd\u2019s memory), then they can scan through memory to find the correct sequence of keys in relatively few tries to decrypt the user\u2019s logon keychain. This provides the adversary with all the plaintext passwords for users, WiFi, mail, browsers, certificates, secure notes, etc.[[Citation: OS X Keychain]][[Citation: OSX Keydnap malware]]\n\nPlatforms: OS X\n\nData Sources: Process Monitoring",
+      "description": "In OS X prior to El Capitan, users with root access can read plaintext keychain passwords of logged-in users because Apple’s keychain implementation allows these credentials to be cached so that users are not repeatedly prompted for passwords.[[Citation: OS X Keychain]][[Citation: External to DA, the OS X Way]] Apple’s securityd utility takes the user’s logon password, encrypts it with PBKDF2, and stores this master key in memory. Apple also uses a set of keys and algorithms to encrypt the user’s password, but once the master key is found, an attacker need only iterate over the other values to unlock the final password.[[Citation: OS X Keychain]]\n\nIf an adversary can obtain root access (allowing them to read securityd’s memory), then they can scan through memory to find the correct sequence of keys in relatively few tries to decrypt the user’s logon keychain. This provides the adversary with all the plaintext passwords for users, WiFi, mail, browsers, certificates, secure notes, etc.[[Citation: OS X Keychain]][[Citation: OSX Keydnap malware]]\n\nPlatforms: OS X\n\nData Sources: Process Monitoring",
       "value": "Securityd Memory",
       "meta": {
         "mitre_data_sources": [
@@ -1214,7 +1214,7 @@
       }
     },
     {
-            "description": "To prevent normal users from accidentally changing special files on a system, most operating systems have the concept of a \u2018hidden\u2019 file. These files don\u2019t show up when a user browses the file system with a GUI or when using normal commands on the command line. Users must explicitly ask to show the hidden files either via a series of Graphical User Interface (GUI) prompts or with command line switches (<code>dir /a</code> for Windows and <code>ls \u2013a</code> for Linux and macOS).\n\n===Windows===\n\nUsers can mark specific files as hidden by using the attrib.exe binary. Simply do <code>attrib +h filename</code> to mark a file or folder as hidden. Similarly, the \u201c+s\u201d marks a file as a system file and the \u201c+r\u201d flag marks the file as read only. Like most windows binaries, the attrib.exe binary provides the ability to apply these changes recursively \u201c/S\u201d.\n\n===Linux/Mac===\n\nUsers can mark specific files as hidden simply by putting a \u201c.\u201d as the first character in the file or folder name [[Citation: Sofacy Komplex Trojan]][[Citation: Antiquated Mac Malware]]. Files and folder that start with a period, \u2018.\u2019, are by default hidden from being viewed in the Finder application and standard command-line utilities like \u201cls\u201d. Users must specifically change settings to have these files viewable. For command line usages, there is typically a flag to see all files (including hidden ones). To view these files in the Finder Application, the following command must be executed: <code>defaults write com.apple.finder AppleShowAllFiles YES</code>, and then relaunch the Finder Application.\n\n===Mac===\n\nFiles on macOS can be marked with the UF_HIDDEN flag which prevents them from being seen in Finder.app, but still allows them to be seen in Terminal.app[[Citation: WireLurker]].\nMany applications create these hidden files and folders to store information so that it doesn\u2019t clutter up the user\u2019s workspace. For example, SSH utilities create a .ssh folder that\u2019s hidden and contains the user\u2019s known hosts and keys. \n\nAdversaries can use this to their advantage to hide files and folders anywhere on the system for persistence and evading a typical user or system analysis that does not incorporate investigation of hidden files.\n\nDetection: Monitor the file system and shell commands for files being created with a leading \".\" and the Windows command-line use of attrib.exe to add the hidden attribute.\n\nPlatforms: Windows Server 2003, Windows Server 2008, Windows Server 2012, Windows XP, Windows 7, Windows 8, Windows Server 2003 R2, Windows Server 2008 R2, Windows Server 2012 R2, Windows Vista, Windows 8.1, Linux, Windows 10, MacOS, OS X\n\nData Sources: File monitoring, Process Monitoring, Process command-line parameters",
+      "description": "To prevent normal users from accidentally changing special files on a system, most operating systems have the concept of a ‘hidden’ file. These files don’t show up when a user browses the file system with a GUI or when using normal commands on the command line. Users must explicitly ask to show the hidden files either via a series of Graphical User Interface (GUI) prompts or with command line switches (<code>dir /a</code> for Windows and <code>ls –a</code> for Linux and macOS).\n\n===Windows===\n\nUsers can mark specific files as hidden by using the attrib.exe binary. Simply do <code>attrib +h filename</code> to mark a file or folder as hidden. Similarly, the “+s” marks a file as a system file and the “+r” flag marks the file as read only. Like most windows binaries, the attrib.exe binary provides the ability to apply these changes recursively “/S”.\n\n===Linux/Mac===\n\nUsers can mark specific files as hidden simply by putting a “.” as the first character in the file or folder name [[Citation: Sofacy Komplex Trojan]][[Citation: Antiquated Mac Malware]]. Files and folder that start with a period, ‘.’, are by default hidden from being viewed in the Finder application and standard command-line utilities like “ls”. Users must specifically change settings to have these files viewable. For command line usages, there is typically a flag to see all files (including hidden ones). To view these files in the Finder Application, the following command must be executed: <code>defaults write com.apple.finder AppleShowAllFiles YES</code>, and then relaunch the Finder Application.\n\n===Mac===\n\nFiles on macOS can be marked with the UF_HIDDEN flag which prevents them from being seen in Finder.app, but still allows them to be seen in Terminal.app[[Citation: WireLurker]].\nMany applications create these hidden files and folders to store information so that it doesn’t clutter up the user’s workspace. For example, SSH utilities create a .ssh folder that’s hidden and contains the user’s known hosts and keys. \n\nAdversaries can use this to their advantage to hide files and folders anywhere on the system for persistence and evading a typical user or system analysis that does not incorporate investigation of hidden files.\n\nDetection: Monitor the file system and shell commands for files being created with a leading \".\" and the Windows command-line use of attrib.exe to add the hidden attribute.\n\nPlatforms: Windows Server 2003, Windows Server 2008, Windows Server 2012, Windows XP, Windows 7, Windows 8, Windows Server 2003 R2, Windows Server 2008 R2, Windows Server 2012 R2, Windows Vista, Windows 8.1, Linux, Windows 10, MacOS, OS X\n\nData Sources: File monitoring, Process Monitoring, Process command-line parameters",
       "value": "Hidden Files and Directories",
       "meta": {
         "mitre_data_sources": [
@@ -1342,7 +1342,7 @@
       }
     },
     {
-            "description": "Per Apple\u2019s developer documentation, there are two supported methods for creating periodic background jobs: launchd and cron[[Citation: AppleDocs Scheduling Timed Jobs]].\n\n===Launchd===\n\nEach Launchd job is described by a different configuration property list (plist) file similar to Launch Daemons or Launch Agents, except there is an additional key called <code>StartCalendarInterval</code> with a dictionary of time values [[Citation: AppleDocs Scheduling Timed Jobs]]. This only works on macOS and OS X.\n\n===cron===\n\nSystem-wide cron jobs are installed by modifying <code>/etc/crontab</code> while per-user cron jobs are installed using crontab with specifically formatted crontab files [[Citation: AppleDocs Scheduling Timed Jobs]]. This works on Mac and Linux systems.\n\nBoth methods allow for commands or scripts to be executed at specific, periodic intervals in the background without user interaction. An adversary may use task scheduling to execute programs at system startup or on a scheduled basis for persistence[[Citation: Janicab]][[Citation: Methods of Mac Malware Persistence]][[Citation: Malware Persistence on OS X]], to conduct Execution as part of Lateral Movement, to gain root privileges, or to run a process under the context of a specific account.\n\nDetection: Legitimate scheduled jobs may be created during installation of new software or through administration functions. Tasks scheduled with launchd and cron can be monitored from their respective utilities to list out detailed information about the jobs. Monitor process execution resulting from launchd and cron tasks to look for unusual or unknown applications and behavior.\n\nPlatforms: Linux, MacOS\n\nData Sources: File monitoring, Process Monitoring",
+      "description": "Per Apple’s developer documentation, there are two supported methods for creating periodic background jobs: launchd and cron[[Citation: AppleDocs Scheduling Timed Jobs]].\n\n===Launchd===\n\nEach Launchd job is described by a different configuration property list (plist) file similar to Launch Daemons or Launch Agents, except there is an additional key called <code>StartCalendarInterval</code> with a dictionary of time values [[Citation: AppleDocs Scheduling Timed Jobs]]. This only works on macOS and OS X.\n\n===cron===\n\nSystem-wide cron jobs are installed by modifying <code>/etc/crontab</code> while per-user cron jobs are installed using crontab with specifically formatted crontab files [[Citation: AppleDocs Scheduling Timed Jobs]]. This works on Mac and Linux systems.\n\nBoth methods allow for commands or scripts to be executed at specific, periodic intervals in the background without user interaction. An adversary may use task scheduling to execute programs at system startup or on a scheduled basis for persistence[[Citation: Janicab]][[Citation: Methods of Mac Malware Persistence]][[Citation: Malware Persistence on OS X]], to conduct Execution as part of Lateral Movement, to gain root privileges, or to run a process under the context of a specific account.\n\nDetection: Legitimate scheduled jobs may be created during installation of new software or through administration functions. Tasks scheduled with launchd and cron can be monitored from their respective utilities to list out detailed information about the jobs. Monitor process execution resulting from launchd and cron tasks to look for unusual or unknown applications and behavior.\n\nPlatforms: Linux, MacOS\n\nData Sources: File monitoring, Process Monitoring",
       "value": "Cron Job",
       "meta": {
         "mitre_data_sources": [
@@ -1599,7 +1599,7 @@
       }
     },
     {
-            "description": "When the setuid or setgid bits are set on Linux or macOS for an application, this means that the application will run with the privileges of the owning user or group respectively. Normally an application is run in the current user\u2019s context, regardless of which user or group owns the application. There are instances where programs need to be executed in an elevated context to function properly, but the user running them doesn\u2019t need the elevated privileges. Instead of creating an entry in the sudoers file, which must be done by root, any user can specify the setuid or setgid flag to be set for their own applications. These bits are indicated with an \"s\" instead of an \"x\" when viewing a file's attributes via <code>ls -l</code>. The <code>chmod</code> program can set these bits with via bitmasking, <code>chmod 4777 [file]</code> or via shorthand naming, <code>chmod u+s [file]</code>.\n\nAn adversary can take advantage of this to either do a shell escape or exploit a vulnerability in an application with the setsuid or setgid bits to get code running in a different user\u2019s context.\n\nDetection: Monitor the file system for files that have the setuid or setgid bits set. Monitor for execution of utilities, like chmod, and their command-line arguments to look for setuid or setguid bits being set.\n\nPlatforms: Linux, MacOS, OS X\n\nData Sources: File monitoring, Process Monitoring, Process command-line parameters\n\nEffective Permissions: Administrator, root",
+      "description": "When the setuid or setgid bits are set on Linux or macOS for an application, this means that the application will run with the privileges of the owning user or group respectively. Normally an application is run in the current user’s context, regardless of which user or group owns the application. There are instances where programs need to be executed in an elevated context to function properly, but the user running them doesn’t need the elevated privileges. Instead of creating an entry in the sudoers file, which must be done by root, any user can specify the setuid or setgid flag to be set for their own applications. These bits are indicated with an \"s\" instead of an \"x\" when viewing a file's attributes via <code>ls -l</code>. The <code>chmod</code> program can set these bits with via bitmasking, <code>chmod 4777 [file]</code> or via shorthand naming, <code>chmod u+s [file]</code>.\n\nAn adversary can take advantage of this to either do a shell escape or exploit a vulnerability in an application with the setsuid or setgid bits to get code running in a different user’s context.\n\nDetection: Monitor the file system for files that have the setuid or setgid bits set. Monitor for execution of utilities, like chmod, and their command-line arguments to look for setuid or setguid bits being set.\n\nPlatforms: Linux, MacOS, OS X\n\nData Sources: File monitoring, Process Monitoring, Process command-line parameters\n\nEffective Permissions: Administrator, root",
       "value": "Setuid and Setgid",
       "meta": {
         "mitre_data_sources": [
@@ -2230,7 +2230,7 @@
       }
     },
     {
-            "description": "In macOS and OS X, when applications or programs are downloaded from the internet, there is a special attribute set on the file called <code>com.apple.quarantine</code>. This attribute is read by Apple's Gatekeeper defense program at execution time and provides a prompt to the user to allow or deny execution. \n\nApps loaded onto the system from USB flash drive, optical disk, external hard drive, or even from a drive shared over the local network won\u2019t set this flag. Additionally, other utilities or events like drive-by downloads don\u2019t necessarily set it either. This completely bypasses the built-in Gatekeeper check[[Citation: Methods of Mac Malware Persistence]]. The presence of the quarantine flag can be checked by the xattr command <code>xattr /path/to/MyApp.app</code> for <code>com.apple.quarantine</code>. Similarly, given sudo access or elevated permission, this attribute can be removed with xattr as well, <code>sudo xattr -r -d com.apple.quarantine /path/to/MyApp.app</code> [[Citation: Clearing quarantine attribute]][[Citation: OceanLotus for OS X]].\n \nIn typical operation, a file will be downloaded from the internet and given a quarantine flag before being saved to disk. When the user tries to open the file or application, macOS\u2019s gatekeeper will step in and check for the presence of this flag. If it exists, then macOS will then prompt the user to confirmation that they want to run the program and will even provide the url where the application came from. However, this is all based on the file being downloaded from a quarantine-savvy application [[Citation: Bypassing Gatekeeper]].\n\nDetection: Monitoring for the removal of the <code>com.apple.quarantine</code> flag by a user instead of the operating system is a suspicious action and should be examined further.\n\nPlatforms: MacOS, OS X",
+      "description": "In macOS and OS X, when applications or programs are downloaded from the internet, there is a special attribute set on the file called <code>com.apple.quarantine</code>. This attribute is read by Apple's Gatekeeper defense program at execution time and provides a prompt to the user to allow or deny execution. \n\nApps loaded onto the system from USB flash drive, optical disk, external hard drive, or even from a drive shared over the local network won’t set this flag. Additionally, other utilities or events like drive-by downloads don’t necessarily set it either. This completely bypasses the built-in Gatekeeper check[[Citation: Methods of Mac Malware Persistence]]. The presence of the quarantine flag can be checked by the xattr command <code>xattr /path/to/MyApp.app</code> for <code>com.apple.quarantine</code>. Similarly, given sudo access or elevated permission, this attribute can be removed with xattr as well, <code>sudo xattr -r -d com.apple.quarantine /path/to/MyApp.app</code> [[Citation: Clearing quarantine attribute]][[Citation: OceanLotus for OS X]].\n \nIn typical operation, a file will be downloaded from the internet and given a quarantine flag before being saved to disk. When the user tries to open the file or application, macOS’s gatekeeper will step in and check for the presence of this flag. If it exists, then macOS will then prompt the user to confirmation that they want to run the program and will even provide the url where the application came from. However, this is all based on the file being downloaded from a quarantine-savvy application [[Citation: Bypassing Gatekeeper]].\n\nDetection: Monitoring for the removal of the <code>com.apple.quarantine</code> flag by a user instead of the operating system is a suspicious action and should be examined further.\n\nPlatforms: MacOS, OS X",
       "value": "Gatekeeper Bypass",
       "meta": {
         "mitre_platforms": [
@@ -2396,7 +2396,7 @@
       }
     },
     {
-            "description": "Bash keeps track of the commands users type on the command-line with the \"history\" utility. Once a user logs out, the history is flushed to the user\u2019s <code>.bash_history</code> file. For each user, this file resides at the same location: <code>~/.bash_history</code>. Typically, this file keeps track of the user\u2019s last 500 commands. Users often type usernames and passwords on the command-line as parameters to programs, which then get saved to this file when they log out. Attackers can abuse this by looking through the file for potential credentials.[[Citation: External to DA, the OS X Way]]\n\nDetection: Monitoring when the user's <code>.bash_history</code> is read can help alert to suspicious activity. While users do typically rely on their history of commands, they often access this history through other utilities like \"history\" instead of commands like <code>cat ~/.bash_history</code>.\n\nPlatforms: Linux, MacOS, OS X\n\nData Sources: File monitoring, Process monitoring, Process command-line parameters",
+      "description": "Bash keeps track of the commands users type on the command-line with the \"history\" utility. Once a user logs out, the history is flushed to the user’s <code>.bash_history</code> file. For each user, this file resides at the same location: <code>~/.bash_history</code>. Typically, this file keeps track of the user’s last 500 commands. Users often type usernames and passwords on the command-line as parameters to programs, which then get saved to this file when they log out. Attackers can abuse this by looking through the file for potential credentials.[[Citation: External to DA, the OS X Way]]\n\nDetection: Monitoring when the user's <code>.bash_history</code> is read can help alert to suspicious activity. While users do typically rely on their history of commands, they often access this history through other utilities like \"history\" instead of commands like <code>cat ~/.bash_history</code>.\n\nPlatforms: Linux, MacOS, OS X\n\nData Sources: File monitoring, Process monitoring, Process command-line parameters",
       "value": "Bash History",
       "meta": {
         "mitre_data_sources": [
@@ -3055,7 +3055,7 @@
       }
     },
     {
-            "description": "As of OS X 10.8, mach-O binaries introduced a new header called LC_MAIN that points to the binary\u2019s entry point for execution. Previously, there were two headers to achieve this same effect: LC_THREAD and LC_UNIXTHREAD [[Citation: Prolific OSX Malware History]]. The entry point for a binary can be hijacked so that initial execution flows to a malicious addition (either another section or a code cave) and then goes back to the initial entry point so that the victim doesn\u2019t know anything was different [[Citation: Methods of Mac Malware Persistence]]. By modifying a binary in this way, application whitelisting can be bypassed because the file name or application path is still the same.\n\nDetection: Determining the original entry point for a binary is difficult, but checksum and signature verification is very possible. Modifying the LC_MAIN entry point or adding in an additional LC_MAIN entry point invalidates the signature for the file and can be detected. Collect running process information and compare against known applications to look for suspicious behavior.\n\nPlatforms: MacOS, OS X\n\nData Sources: Binary file metadata, Malware reverse engineering, Process Monitoring",
+      "description": "As of OS X 10.8, mach-O binaries introduced a new header called LC_MAIN that points to the binary’s entry point for execution. Previously, there were two headers to achieve this same effect: LC_THREAD and LC_UNIXTHREAD [[Citation: Prolific OSX Malware History]]. The entry point for a binary can be hijacked so that initial execution flows to a malicious addition (either another section or a code cave) and then goes back to the initial entry point so that the victim doesn’t know anything was different [[Citation: Methods of Mac Malware Persistence]]. By modifying a binary in this way, application whitelisting can be bypassed because the file name or application path is still the same.\n\nDetection: Determining the original entry point for a binary is difficult, but checksum and signature verification is very possible. Modifying the LC_MAIN entry point or adding in an additional LC_MAIN entry point invalidates the signature for the file and can be detected. Collect running process information and compare against known applications to look for suspicious behavior.\n\nPlatforms: MacOS, OS X\n\nData Sources: Binary file metadata, Malware reverse engineering, Process Monitoring",
       "value": "LC_MAIN Hijacking",
       "meta": {
         "mitre_data_sources": [
@@ -3450,7 +3450,7 @@
       }
     },
     {
-            "description": "MacOS provides the option to list specific applications to run when a user logs in. These applications run under the logged in user's context, and will be started every time the user logs in. Login items installed using the Service Management Framework are not visible in the System Preferences and can only be removed by the application that created them[[Citation: Adding Login Items]]. Users have direct control over login items installed using a shared file list which are also visible in System Preferences[[Citation: Adding Login Items]]. These login items are stored in the user's <code>~/Library/Preferences/</code> directory in a plist file called <code>com.apple.loginitems.plist</code>[[Citation: Methods of Mac Malware Persistence]]. Some of these applications can open visible dialogs to the user, but they don\u2019t all have to since there is an option to \u2018Hide\u2019 the window. If an adversary can register their own login item or modified an existing one, then they can use it to execute their code for a persistence mechanism each time the user logs in[[Citation: Malware Persistence on OS X]][[Citation: OSX.Dok Malware]].\n\nDetection: All the login items are viewable by going to the Apple menu -> System Preferences -> Users & Groups -> Login items. This area should be monitored and whitelisted for known good applications. Monitor process execution resulting from login actions for unusual or unknown applications.\n\nPlatforms: MacOS, OS X",
+      "description": "MacOS provides the option to list specific applications to run when a user logs in. These applications run under the logged in user's context, and will be started every time the user logs in. Login items installed using the Service Management Framework are not visible in the System Preferences and can only be removed by the application that created them[[Citation: Adding Login Items]]. Users have direct control over login items installed using a shared file list which are also visible in System Preferences[[Citation: Adding Login Items]]. These login items are stored in the user's <code>~/Library/Preferences/</code> directory in a plist file called <code>com.apple.loginitems.plist</code>[[Citation: Methods of Mac Malware Persistence]]. Some of these applications can open visible dialogs to the user, but they don’t all have to since there is an option to ‘Hide’ the window. If an adversary can register their own login item or modified an existing one, then they can use it to execute their code for a persistence mechanism each time the user logs in[[Citation: Malware Persistence on OS X]][[Citation: OSX.Dok Malware]].\n\nDetection: All the login items are viewable by going to the Apple menu -> System Preferences -> Users & Groups -> Login items. This area should be monitored and whitelisted for known good applications. Monitor process execution resulting from login actions for unusual or unknown applications.\n\nPlatforms: MacOS, OS X",
       "value": "Login Item",
       "meta": {
         "mitre_platforms": [
@@ -3884,7 +3884,7 @@
       }
     },
     {
-            "description": "Mach-O binaries have a series of headers that are used to perform certain operations when a binary is loaded. The LC_LOAD_DYLIB header in a Mach-O binary tells macOS and OS X which dynamic libraries (dylibs) to load during execution time. These can be added ad-hoc to the compiled binary as long adjustments are made to the rest of the fields and dependencies[[Citation: Writing Bad Malware for OSX]]. There are tools available to perform these changes. Any changes will invalidate digital signatures on binaries because the binary is being modified. Adversaries can remediate this issue by simply removing the LC_CODE_SIGNATURE command from the binary so that the signature isn\u2019t checked at load time[[Citation: Malware Persistence on OS X]].\n\nDetection: Monitor processes for those that may be used to modify binary headers. Monitor file systems for changes to application binaries and invalid checksums/signatures. Changes to binaries that do not line up with application updates or patches are also extremely suspicious.\n\nPlatforms: MacOS, OS X\n\nData Sources: Binary file metadata, Process Monitoring, Process command-line parameters, File monitoring",
+      "description": "Mach-O binaries have a series of headers that are used to perform certain operations when a binary is loaded. The LC_LOAD_DYLIB header in a Mach-O binary tells macOS and OS X which dynamic libraries (dylibs) to load during execution time. These can be added ad-hoc to the compiled binary as long adjustments are made to the rest of the fields and dependencies[[Citation: Writing Bad Malware for OSX]]. There are tools available to perform these changes. Any changes will invalidate digital signatures on binaries because the binary is being modified. Adversaries can remediate this issue by simply removing the LC_CODE_SIGNATURE command from the binary so that the signature isn’t checked at load time[[Citation: Malware Persistence on OS X]].\n\nDetection: Monitor processes for those that may be used to modify binary headers. Monitor file systems for changes to application binaries and invalid checksums/signatures. Changes to binaries that do not line up with application updates or patches are also extremely suspicious.\n\nPlatforms: MacOS, OS X\n\nData Sources: Binary file metadata, Process Monitoring, Process command-line parameters, File monitoring",
       "value": "LC_LOAD_DYLIB Addition",
       "meta": {
         "mitre_data_sources": [
@@ -4419,7 +4419,7 @@
       }
     },
     {
-            "description": "The <code>HISTCONTROL</code> environment variable keeps track of what should be saved by the <code>history</code> command and eventually into the <code>~/.bash_history</code> file when a user logs out. This setting can be configured to ignore commands that start with a space by simply setting it to \"ignorespace\". <code>HISTCONTROL</code> can also be set to ignore duplicate commands by setting it to \"ignoredups\". In some Linux systems, this is set by default to \"ignoreboth\" which covers both of the previous examples. This means that \u201c ls\u201d will not be saved, but \u201cls\u201d would be saved by history. <code>HISTCONTROL</code> does not exist by default on macOS, but can be set by the user and will be respected. Adversaries can use this to operate without leaving traces by simply prepending a space to all of their terminal commands.\n\nDetection: Correlating a user session with a distinct lack of new commands in their <code>.bash_history</code> can be a clue to suspicious behavior. Additionally, users checking or changing their <code>HISTCONTROL</code> environment variable is also suspicious.\n\nPlatforms: Linux, MacOS, OS X\n\nData Sources: Process Monitoring, Authentication logs, File monitoring, Environment variable",
+      "description": "The <code>HISTCONTROL</code> environment variable keeps track of what should be saved by the <code>history</code> command and eventually into the <code>~/.bash_history</code> file when a user logs out. This setting can be configured to ignore commands that start with a space by simply setting it to \"ignorespace\". <code>HISTCONTROL</code> can also be set to ignore duplicate commands by setting it to \"ignoredups\". In some Linux systems, this is set by default to \"ignoreboth\" which covers both of the previous examples. This means that “ ls” will not be saved, but “ls” would be saved by history. <code>HISTCONTROL</code> does not exist by default on macOS, but can be set by the user and will be respected. Adversaries can use this to operate without leaving traces by simply prepending a space to all of their terminal commands.\n\nDetection: Correlating a user session with a distinct lack of new commands in their <code>.bash_history</code> can be a clue to suspicious behavior. Additionally, users checking or changing their <code>HISTCONTROL</code> environment variable is also suspicious.\n\nPlatforms: Linux, MacOS, OS X\n\nData Sources: Process Monitoring, Authentication logs, File monitoring, Environment variable",
       "value": "HISTCONTROL",
       "meta": {
         "mitre_data_sources": [

clusters/mitre_course-of-action.json

@@ -276,7 +276,7 @@
       "value": "Source Mitigation"
     },
     {
-            "description": "Prevent users from changing the <code>HISTCONTROL</code> environment variable[[CiteRef::Securing bash history]]. Also, make sure that the <code>HISTCONTROL</code> environment variable is set to \u201cignoredup\u201d instead of \u201cignoreboth\u201d or \u201cignorespace\u201d.",
+      "description": "Prevent users from changing the <code>HISTCONTROL</code> environment variable[[CiteRef::Securing bash history]]. Also, make sure that the <code>HISTCONTROL</code> environment variable is set to “ignoredup” instead of “ignoreboth” or “ignorespace”.",
       "meta": {
         "uuid": "d684a482-645d-4ad9-8a3e-78ca61e188d6"
       },
@@ -360,7 +360,7 @@
       "value": "Process Hollowing Mitigation"
     },
     {
-            "description": "The sudoers file should be strictly edited such that passwords are always required and that users can\u2019t spawn risky processes as users with higher privilege. By requiring a password, even if an adversary can get terminal access, they must know the password to run anything in the sudoers file.",
+      "description": "The sudoers file should be strictly edited such that passwords are always required and that users can’t spawn risky processes as users with higher privilege. By requiring a password, even if an adversary can get terminal access, they must know the password to run anything in the sudoers file.",
       "meta": {
         "uuid": "eba326ab-299e-41b9-8c75-9a6b3f7bfc04"
       },
@@ -570,7 +570,7 @@
       "value": "Data Compressed Mitigation"
     },
     {
-            "description": "Enforce that all binaries be signed by the correct Apple Developer IDs, and whitelist applications via known hashes. Binaries can also be baselined for what dynamic libraries they require, and if an app requires a new dynamic library that wasn\u2019t included as part of an update, it should be investigated.",
+      "description": "Enforce that all binaries be signed by the correct Apple Developer IDs, and whitelist applications via known hashes. Binaries can also be baselined for what dynamic libraries they require, and if an app requires a new dynamic library that wasn’t included as part of an update, it should be investigated.",
       "meta": {
         "uuid": "5d9342dd-12f8-40ac-bf74-fb9d67824ae0"
       },
@@ -584,7 +584,7 @@
       "value": "Authentication Package Mitigation"
     },
     {
-            "description": "Since StartupItems are deprecated, preventing all users from writing to the <code>/Library/StartupItems</code> directory would prevent any startup items from getting registered. Similarly, appropriate permissions should be applied such that only specific users can edit the startup items so that they can\u2019t be leveraged for privilege escalation.",
+      "description": "Since StartupItems are deprecated, preventing all users from writing to the <code>/Library/StartupItems</code> directory would prevent any startup items from getting registered. Similarly, appropriate permissions should be applied such that only specific users can edit the startup items so that they can’t be leveraged for privilege escalation.",
       "meta": {
         "uuid": "e76834ef-0a68-4d78-818e-9f5d9482e011"
       },

clusters/mitre_intrusion-set.json

@@ -326,7 +326,7 @@
         ],
         "uuid": "6a2e693f-24e5-451a-9f88-b36a108e5662"
       },
-            "description": "APT1 is a Chinese threat group that has been attributed to the 2nd Bureau of the People\u2019s Liberation Army (PLA) General Staff Department\u2019s (GSD) 3rd Department, commonly known by its Military Unit Cover Designator (MUCD) as Unit 61398.[[Citation: Mandiant APT1]]", 
+      "description": "APT1 is a Chinese threat group that has been attributed to the 2nd Bureau of the People’s Liberation Army (PLA) General Staff Department’s (GSD) 3rd Department, commonly known by its Military Unit Cover Designator (MUCD) as Unit 61398.[[Citation: Mandiant APT1]]",
       "value": "APT1"
     },
     {
@@ -560,7 +560,7 @@
         ],
         "uuid": "9e729a7e-0dd6-4097-95bf-db8d64911383"
       },
-            "description": "Darkhotel is a threat group that has been active since at least 2004. The group has conducted activity on hotel and business center Wi\u2011Fi and physical connections as well as peer-to-peer and file sharing networks. The actors have also conducted spearphishing.[[Citation: Kaspersky Darkhotel]]", 
+      "description": "Darkhotel is a threat group that has been active since at least 2004. The group has conducted activity on hotel and business center Wi‑Fi and physical connections as well as peer-to-peer and file sharing networks. The actors have also conducted spearphishing.[[Citation: Kaspersky Darkhotel]]",
       "value": "Darkhotel"
     },
     {
@@ -733,7 +733,7 @@
         ],
         "uuid": "5ce5392a-3a6c-4e07-9df3-9b6a9159ac45"
       },
-            "description": "Putter Panda is a Chinese threat group that has been attributed to Unit 61486 of the 12th Bureau of the PLA\u2019s 3rd General Staff Department (GSD).[[Citation: CrowdStrike Putter Panda]]", 
+      "description": "Putter Panda is a Chinese threat group that has been attributed to Unit 61486 of the 12th Bureau of the PLA’s 3rd General Staff Department (GSD).[[Citation: CrowdStrike Putter Panda]]",
       "value": "Putter Panda"
     },
     {

clusters/mitre_malware.json

@@ -789,7 +789,7 @@
         "uuid": "53cf6cc4-65aa-445a-bcf8-c3d296f8a7a2"
       },
       "value": "NETEAGLE",
-            "description": "NETEAGLE is a backdoor developed by APT30 with compile dates as early as 2008. It has two main variants known as \u201cScout\u201d and \u201cNorton.\u201d[[Citation: FireEye APT30]]"
+      "description": "NETEAGLE is a backdoor developed by APT30 with compile dates as early as 2008. It has two main variants known as “Scout” and “Norton.”[[Citation: FireEye APT30]]"
     },
     {
       "meta": {

clusters/mitre_tool.json

@@ -338,7 +338,7 @@
         "uuid": "c9cd7ec9-40b7-49db-80be-1399eddd9c52"
       },
       "value": "Cachedump",
-            "description": "Cachedump is a publicly-available tool that program extracts cached password hashes from a system\u2019s registry.[[Citation: Mandiant APT1]]"
+      "description": "Cachedump is a publicly-available tool that program extracts cached password hashes from a system’s registry.[[Citation: Mandiant APT1]]"
     },
     {
       "meta": {
@@ -410,7 +410,7 @@
         "uuid": "3da22160-12d9-4d27-a99f-338e8de3844a"
       },
       "value": "Cobalt Strike",
-            "description": "Cobalt Strike is a commercial, full-featured, penetration testing tool which bills itself as \u201cadversary simulation software designed to execute targeted attacks and emulate the post-exploitation actions of advanced threat actors\u201d.  Cobalt Strike\u2019s interactive post-exploit capabilities cover the full range of ATT&CK tactics, all executed within a single, integrated system.Cobalt Strike leverages the capabilities of other well-known tools such as Metasploit and Mimikatz.[[Citation: cobaltstrike manual]]\n\nThe list of techniques below focuses on Cobalt Strike\u2019s ATT&CK-relevant tactics."
+      "description": "Cobalt Strike is a commercial, full-featured, penetration testing tool which bills itself as “adversary simulation software designed to execute targeted attacks and emulate the post-exploitation actions of advanced threat actors”.  Cobalt Strike’s interactive post-exploit capabilities cover the full range of ATT&CK tactics, all executed within a single, integrated system.Cobalt Strike leverages the capabilities of other well-known tools such as Metasploit and Mimikatz.[[Citation: cobaltstrike manual]]\n\nThe list of techniques below focuses on Cobalt Strike’s ATT&CK-relevant tactics."
     },
     {
       "meta": {