Create Linux.Detection.BruteForce.yaml

[RCarras]

This module search for brute force attacks, basing its analysis on BTMP and WTMP logs.

Requirements: It's necessary to use velociraptor client with high privileges because of utmpdump command use.

[RCarras]

Hello @scudette should I do anything more to approve the module? Sorry for any inconvenience.

[scudette]

Couple of comments:

1. Use a temp directory so we dont leave files on the client
2. Lock the release down by hash

But mainly the issue is with the shell script - this type of analysis is easy to do with VQL so what does the shell script add? It also looks to be quite vulnerable (bash scripts are difficult to write securely) so I am not sure we really want to go that way?

[RCarras]

Hi @scudette, firstly, thanks for your support and contribution to improve the artifact. Replying to your suggestions and questions:

1. Use a temp directory so we dont leave files on the client. ✅
2. Lock the release down by hash. ✅
3. The script was firstly done by shell script that's why we present It as follows, It could be adapted (but could be a tedious process because of script length), anyway we saw other Shell scripts used by VQL artifacts (as CatScale for example that aren't adapted to VQL either) so we thought it could be fine.
4. Talking about possible vulnerabilities, we tested It many times to improve it and we did some bash scripts vulnerabilities tests (Example: shellcheck), so we think it's secure, anyway if you detect any issue we'll appreciate it and change the vulnerable part of the code.

[scudette]

I didnt take a closer look at the shell script to be honest but some things immediately stood out to me.

1. The script uses hard coded paths that leave files behind on the system as well as making it easy to do symlink attacks.
2. Using sudo is not needed in a script already running as root - will fill up the auth logs and may interfere with other evidence.
3. not using absolute paths to shell commands like date utmpparser etc opens the script up to path injection attacks.
4. I am not sure if there is shell injection in the awk parameters - at first I thought so but I think that might be ok actually due to non expansion single quotes.

It is also very hard for me to actually see what the script is doing without reading it very closely. A better comments or description would help. What constitutes a detection? Is 5 failed logins within 1 hour a detection? Is it doing more than that? Is it similar logic to https://docs.velociraptor.app/artifact_references/pages/windows.events.failedlogbeforesuccess/ ?

It is usually very difficult to write secure shell scripts so I am always a bit reluctant to include those. You are right that some other artifacts include shell scripts too (like for example UAC is also a shell script). It is a bit about risk mitigation.

We have on our road map an attempt to split the exchange into different categories of artifacts - particularly to put artifacts that use external tools and scripts in their own category because they do pose higher risk i think.

[RCarras]

Hello @scudette, thanks again for all your feedback and great ideas to improve the shell script. I've just update the shell script (repository) and VQL artifact locked hash.

Updates:

1. The script uses hard coded paths that leave files behind on the system as well as making it easy to do symlink attacks: Now it uses mktemp to create the dir ✅
2. Using sudo is not needed in a script already running as root - will fill up the auth logs and may interfere with other evidence: Now it doesn't use sudo inside the script ✅
3. not using absolute paths to shell commands like date utmpparser etc opens the script up to path injection attacks: Now commands are set with full path, that is searched with WHICH full path command ✅
4. Every script logic line is commented, except logs extracting one (utmpdump + rsync), to improve understanding of the script. ✅
5. BruteForce Detection: by default, after testing it a lot (by simulating with hydra brute force attacks) and taking into consideration previous incidents experience, it's set as: Time_Interval between attempts ~ no more than 45 secs, and Attempts to be considered as brute force ~ 80 attempts. Anyway it's a malleable variable, so depending on Incident Responder experience it could be change as it is a parameter in VQL artifact. ✅

I'd also want to add that the script has 3 flows to detect different type of brute forces:

• Basic Brute Force Attack: multiple consecutive attempts from an IP.
• Password Spraying: multiple consecutive attempts from different users with the same password.
• Dynamic IP Attack: multiple consecutive attempts from different IPs.

Kind regards, RCarras

[scudette]

Just FYI , point 3 does not fix the issue - which still searches the path for the command which is still vulnerable to path injection. Scripts need to specify the absolute path to all sub commands.

[RCarras]

Just FYI , point 3 does not fix the issue - which still searches the path for the command which is still vulnerable to path injection. Scripts need to specify the absolute path to all sub commands.

@scudette Solved. If it's necessary anything more to merge artifact with the exchange let me now. Thanks!!