Below I will briefly explain the common vulnerabilities that are addressed by the scripts in this repo. Although scripts are very useful, they can not anticipate everything. These descriptions will come in handy when you need to manually threat hunt your system.

You can always reference [hacktricks](https://book.hacktricks.wiki/en/linux-hardening/linux-privilege-escalation-checklist.html) for a more thorough checklist.

## Table of Contents

### Running Scripts

[Linux Scripts](##Linux-Scripts)
[Windows Scripts](##Windows-Scripts)

### Linux Vulns

[System](#System)

- [PAM](##PAM)
- [Cron jobs](##Cron-jobs)
- [Set-uid/gid](##Set-uid/gid)
- [Path hijacking](##Path-hijacking)
- [Shared libraries](##Shared-libraries)
- [Symbolic linking](##Symbolic-linking)
- [Restricted environmennts](##Restricted-environments)
- [User](##User)
- [ACLs](##ACLs)
- [Capabilities](##Capabilities)

[Services](#Services)

- [SSH](##SSH)

### Linux Benchmarks

[AppArmor](#AppArmor)

### Windows Vulns

### Windows Benchmarks

# Linux Scripts

To get the scripts you can run `git clone https://github.com/pyukey/Vuln-Scripts.git`. However, many machines may not have git, so instead I will scp the files to you.

## rollPasswd.sh

First you should

cd Vuln-Scripts/Linux
sudo ./rollPasswd.sh

- If you see `New password: Retype new password:` that means that passwords were changed using `passwd` whcich **could be backdoored**. Check by running `which passwd` and then inspecting that binary.
- **Save these passwords somewhere**. Copy+paste in chat. If you lose access to the machine then you're cooked.
- **Make sure to update scoring services with the new passwds**

## backup.sh

Backups are optional. Run `sudo ./backup.sh` and it will make the backup (you will need to provide a passwd to encrypt the backup with). To retrieve, run

gpg -d /opt/.bk.tar.gz.gpg
tar -xzvf /opt/.bk.tar.gz

## userHardening

cd userHardening
./fixUsers.sh

These will enumerate all users on the system and prompt you for each vulnerability it finds.

- If you answer `y` it applies the change, anything else is ignored.
- If you're not sure if a user is needed check `essentialUsers.txt`. You should NOT mess with these.
Then check `serviceUsers.txt`. These users are optional depending on what services you are running.

If you want to see all the users on your system [displayed nicely](##User), run `sudo ./listUsersColor.sh`

## firewall.sh

Having a firewall isn't *that* important, so do this when you feel comfortable.

sudo ./firewall.sh [ad] [web] [ftp] [#]

- Depending on your machine, you will need allow certain services through the firewall. Do listing the ports as arguments.
For example, `sudo ./firewall.sh ad 1337 8080` would allow traffic for AD and on port 1337 and 8080.
- By default, icmp, ssh (22) and dns (53) are allowed. If you need to access the internnet, include `web`
- If you have AD users, include `ad`

**DON'T GET BURNED BY THE FIREWALL!**

If your services go down after running this, flush your rules with `sudo iptables -F` and think carefully.

## blackout.sh

Consider this scenario: your system is cooked, you have a 20+ active ssh connections, how can you deal with it all?!

This script is a **last resort for total isolation!** It blocks by ip so only *you* can access the network. If you screwed up, no worries the script fixes itself. Your terminal will probably be frozen, so just open a new terminal and ssh from there.

sudo iptables -F
sudo ./balckout.sh

## Next Steps

1. Secure your services
2. Check `.bash_history` to see if red team left any traces
3. Check [PAM](##Pam) by looking at `/etc/pam.d/common-auth`, `/etc/pam.d/su`, and maybe `/etc/pam.d/password-auth`. You also want to check if `/lib/x86_64-linux-gnu/security/pam_deny.so` has been backdoored with `pam_permit.so` by using `./checkSum.sh <file1> <file2>`
4. Run [lse.sh](https://github.com/diego-treitos/linux-smart-enumeration/tree/master) or [LinPEAS](https://github.com/peass-ng/PEASS-ng/tree/master/linPEAS) and address threats.
5. See if PATH has been [hijacked](##Path-hijacking) by running `echo $PATH`. Make sure to also switch to root user and check!
6. Run the yara rules to look for malicious binaries `yara <rule> -r <directory-to-scan>`

# Windows Scripts
See W section (pg 39) of the cheatsheet. Your goals should be:

1. Change passwords
2. Force credentials reset (e.g. Kerberos tokens)
3. Run sysinternals for threat detection

# System
## PAM
PAM handles authentication in Linux and consists of config files in `/etc/pam.d`, which reference so files in `/lib/x86_64-linux-gnu/security/`. You can read more [here](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/managing_smart_cards/pam_configuration_files). The most relevant config files are (with examples):

- `password-auth` (RHEL-based) and `common-auth` (Debian-based): handles authentication stuff

password  [success=1 default=ignore] pam_unix.so  obscure yescrypt
password  requisite  pam_deny.so
password  required  pam_permit.so

- `su` handles who can su

# If you want root to su w/o passwd then it should begin with
auth  sufficient  pam_rootok.so

- `common-password` for changing passwords

# Optional line if you're enforcing passwd policy
password  requisite  pam_pwquality.so  retry=3 minlen=12 difok=3
# If succeeds, skip next line (so jumps to permit). The yescrypt is secure hashing algorithm
password  [success=1 default=ignore]  pam_unix.so  obscure  yescrypt
password  requisite  pam_deny.so
password  required  pam_permit.so

Each line in these config files will consist of an interface:

- `auth`: authentication
- `account`: authorization (expired, time of day)
- `password`: changing passwd
- `session`: other stuff during login/logout

a flag:

- `required` must succeed.
- `requisite` must succeed and notifies immediately of first fail
- `sufficient` if succeeds (and no previous fails), then you pass
- `optional` only necessarry if there are no other modules
- `include`

and a module:

- `pam_console.so`: checks for `/etcc/security/console.apps` file
- `pam_cracklib.so`: checks new passwds against dictionary attack
- `retry=#` number of retries allowed- `pam_permit.so`: allows login
- `pam_deny.so`: denies login
- `pam_nologin.so`: fails if `/etc/nologin` exists and uid != 0
- `pam_rootok.so`: checks if uid=0
- `pam_securetty.so`: if logging in as root, check if tty is in `/etc/securetty`
- `pam_unix.so`: prompts and compares password to `/etc/shadow`
- `nullok`: allows blank passwd
- `shadow`: when updating passwd, stores in `/etc/shadow`

## Cron-jobs

Check these directories:

- `/var/spool/`
- `/etc/cron` stuff

## Set-uid/gid

If this bit is set, then you execute the file with the permissions of the owner. Check [GTFOBins](https://gtfobins.github.io/) if it is exploitable. You can read more [here](https://tbhaxor.com/demystifying-suid-and-sgid-bits/).

## Path hijacking

When you run a command like `ls`, the system checks your path from left to right to see if the file exists. If an attacker can place a directory they can write to at the start of your path, then they can put malicious executables there, which take priority over `/bin`.

## Shared libraries

This is similar to Path hijacking for dynamically linked libraries. I don't understand it well so you can read more [here](https://tbhaxor.com/understanding-concept-of-shared-libraries/). It has something to do with `LD_PRELOAD` environmental variable.

## Symbolic linking

If a priviledged program creates a file `filename` in a directory writable by the user, the user can create a symlink `filename` that points to whatever file they want. This gives them write access to their target fille! You can see examples [here](https://lettieri.iet.unipi.it/hacking/ch/5-symlink.pdf).

## Restricted environments

To prevent users from escalating, you can place them inside a restricted environment. However, these are often easy to break out of. One type is the **restricted shells** like `rsh`, which you can read about [here](https://tbhaxor.com/breaking-out-of-restricted-shell-environment/).

The other is a **chroot jail**, which limits what files you can accesss by changing your root directory. As long as you have access to:
1. A privileged shell
2. A program that can call **mkdir, chroot, chdir**

You can escape the jail, as shown [here](https://tbhaxor.com/breaking-out-of-chroot-jail-shell-environment/).

## User

You can check a lot of this by looking at `/etc/passwd`. If you want to learn more, [this blog](https://tbhaxor.com/linux-file-permissions/) is great.

- if the passwd field is blank, then a user can login w/o a passwd! Additionally, if you set a passwd for that user, it is stored in `/etc/passwd` instead of `/etc/shadow`

`/etc/shadow` is where encrypted passwds should be stored

- `*` (Debian-based) or `!!` (RHEL-based) means a passwd has never been set while `!` means the account is locked. Either way, the user can't login

`/etc/groups` lists the users in each group. This is referenced when checking group permissions for things like file access. You'll notice that the passwd field in this file also has `x`, which indicates a corresponding shadow file...

`/etc/gshadow` contains the passwds for groups. This allows users to add themselves to a group using `newgrp` if they provide the passwd. If a user is listed under that group, they don't need the passwd to add themselves to that group. This should never be enabled, so all passwd should be `!`


**UID = 0** means the user is effectively root

The `/etc/sudoers` file specifies who can run programs as root using the `sudo` command. Each line in that file follows the format
`<user> <hosts>=(<runas_user>:<runas_group>) <options>:<commands>`
so `root ALL=(ALL:ALL) ALL` would allow root to run all commands on all hosts as any user/group

- The `NOPASSWD` option is BAD. They can run sudo without passwd!
- instead of a user you can specify a group like `%admin`. You can specify a number insteaad of name with `#`
- `@includedir <dirpath>` adds any files in that path to `/etc/sudoers`. You shouldn't have anything in `/etc/sudoers.d/`

There are certain groups that if a user is a part of, they can exploit to run anything effectively as root:

- **sudo** (Debian-based) and **wheel** (RHEL-based) are typically included in `/etc/sudoers` file.

Check `.bash_profile` for login shells `.bashrc` for non-login shells:

- sus `alias` could be sued to backdoor command
- Could run commands at login

## ACLs

**Access control lists** (acls) are an *additional* set of *user-specific* permissions that you can assign to files. These don't appear normally in `ls -l` (you may see a `+`), so instead use `getfacl`.

## Capabilities

Capabilities are another set of permissions you assign to *processes*. Root can do a LOT of things, so to follow the principle of least privilege, Linux has grouped root's privileges into **capabilties**. This can be confusing, so here is a [detailed guide](https://github.com/huntergregal/mimipenguin/tree/master) and [practical overview](https://github.com/huntergregal/mimipenguin/tree/master).

# Services
## SSH

## FTP

## Docker

## Kubernetes

# AppArmor