Detecting Exploits - OMIGod (Linux Logging with Auditd)
Вставка
- Опубліковано 16 чер 2024
- 00:00 - Intro, how to install and configure auditd
01:15 - Installing Auditd
02:30 - Downloading a good baseline ruleset from github
03:40 - Going over the baseline file to understand how logging works
05:00 - What the -p flag does with files. Logging read/write/execute/attribute change events
07:10 - If you want CWD in your logs, uncomment this line
13:20 - Logging priv_esc events
14:40 - Excluding system accounts from log captures
15:40 - Fun detections to find recon and suspicious activity
21:40 - Logging when users fail to access files in special directories
24:16 - Running the omigod exploit and getting a reverse shell echo/base64
25:05 - Running ausearch to detect what we had done by searching for commands ran by root
28:00 - Using some bashfu to show only commands ran by a ppid
28:50 - Looking for the suspicious activity
30:40 - Analyzing a detection rule for this and understanding the importance of not excluding CWD from logs
34:15 - Checking if mkfifo is detected... yep
36:20 - Installing Laurel to convert Auditd's multiline format to singleline JSON
38:50 - Installing Rust then compiling Laurel
43:40 - Removing End Of Event from Auditd config to see if that fixes the Laurel bug (IT DOES!)
46:56 - Viewing our Auditd logs in JSON Format! SIEMS will love this!
48:30 - Going over aureport to show some things
50:30 - Looking for why we have so many syscall failures
Three videos in 2 days? Thanks a ton Ippsec, you material is always amazing and appreciated
Love this approach! When I pop a box I always run "whoami / whoami /all". We created a Azure KQL query to look for those command and additional arguments across the organization and run a custom detection rule when it finds such possible post exploitation activities on any endpoint. Dropping ATP EDR on Linux machine with custom KQL queries can help a lot , especially when one sees the offensive arguments being executed. We look for argument that contain "/dev/tcp/" for example. Very helpful. Every time I watch your videos I adjust the queries lol
One can always limit egress traffic on Azure NSG to just drop the revere shell if it gets popped and limit inbound traffic on NSG to limit the overall attack surface
Working with Microsoft a lot. , they are not fixing it because it does "not affect back-end infrastructure"
Preparing for OSCP your video's are helping so much ❤️❤️❤️❤️❤️
More Blue team stuffs please!! Big up ippsec
100% agree this was great!
Really insightful, thanks!!
Thanks so usefull you are the one IPPsec love you :)
Great video! I started using Laurel after your tweet, then watched the video. Unfortunately, wazuh does not have any rules for Laurel. And translating audit rules to laurel versions takes time. I gave up, for instance. Do you know if any other SIEMs can consume Laurel log easily?
Thanks for the vid!
This is really good.
Thanks for defender content
thanks for the A/D content from Twitter :)
Great video!!! Question for you - how could we send this information to Kafka? I saw an Rsyslog plugin to output to Kafka but do you have any recommendations? Maybe use something like Fluent and scrape the laurel audit.log?
Thanks for the video, very nice to see blue side here, but at the same time I feel like it shows how hard it is to create an universal auditd policy. Even with basic set of best practice rules and reasonably standard fresh Linux install, auditd still flooded logs by misbehaving package manager
Well you could just exclude dpkg/apt and then all those alerts are gone. They have minimal chance for abuse.
@@ippsec that is true, but dpkg is just an example here that you came by in a 1h video, I'm afraid many more like that will come. I guess it comes down to managing policies in a larger environment and that is not what the video was meant to be about.
@@SmoothestOperator Yeah at the end of the day the noise isn't great but it doesn't increase the difficulty all that much if you are just using it for threat hunting. Running some searches like show me EXECVE calls in path's that contain TMP, and suddenly all that dpkg noise goes away.
Or you make a broad hunt and go show me all the syscalls that failed and group by process then show me all the unique and reverse sort... Then you're just looking at the one off's which are generally more interesting than the ones that happen 24/7.
At the end of the day the main disadvantage to the noise is it is just eating up money, but at the end of the day its not much money and you can archive it off.
Fun fact:
You sound like the host of the LGR youtube channel 😊
Would be good to log the pathname for the mknod syscall
Echo is a builtin, it does not do any exec syscall (only write(1))
Question:
I‘m watching your video on my ipad while in bed…so, I apologize for my laziness to try it out by myself.
If a user deletes 1000000 files…what happens to the auditd log? Will it explode or insane IO?
21:00 I know asking is lazy but I assume doing a `chmod 4000 /bin/bash` would be recorded in the audit log
Yes that’s an attribute change. I think all attribute changes in /bin/ (and normal directories for $path) was logged. If not easy to add.
@@ippsec thanks for the reply. I installed auditd on my homeserver - had an old tower kicking about and trying to understand more around protecting an environment rather than breaking into it.
Can you make video about selinux to prevent system exploitation.
is there anyway you're seeing a pentester exploiting this "default" auditd rules?
how does this affect the logging of something like apparmor profiles in complain or enforce mode???
I'm not exactly sure what you mean by this, and honestly I've never really touched AppArmor. But I'll take a stab at trying to answer, let me know if this helps.
AppArmor does do some syscall monitoring, but I don't think it monitors everything. If you are just concerned about Process Execution/File Monitoring it may be fine... But AuditD could also go into network monitoring which.
At the end of the day, AppArmor/SELinux were built to prevent applications from performing actions, so they are tailored at that. When AuditD is specifically at discovering what your system is doing. So they data you'd get from the two are wildly different.
Dude…dnf is not a redhat firewall…it is the successor of the yum package manager AND the key also states software_mgmt. 😂😊
Am I the only one that can't get logging with apparmor to work when auditd is installed?
Can you please let me know if I can combine the following rules:
-a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=-1 -k perm_mod
-a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=-1 -k perm_mod
-a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=-1 -k perm_mod
-a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=-1 -k perm_mod
As:
-a always,exit -F arch=b32 -S chmod -S chown -S fchmod -S fchmodat -F auid>=1000 -F auid!=-1 -k perm_mod
OR
-a always,exit -F arch=b32 -S chmod,chown,fchmod,fchmodat -F auid>=1000 -F auid!=-1 -k perm_mod
Is this valid? thanks
RTFM! This video is so inaccurate that Steve Grubb is rolling in his grave - and the fella is not even dead yet...
Be helpful if you said what was inaccurate. Presume some auditd stuff based upon Steve Grubb. But yes, like all videos it's just my understanding of how it works. Alot of why I put videos out is to learn where my understanding is wrong.
@@ippsec I couldn't see your UMASK but...
- you created a new audit.rules with (probably) 0644 while originally it was 0640
- the same goes to your audit.log as you could ausearch in it locally with the ippsec (non-root) user. It's something what shouldn't happen. These logs can be really sensitive.
@@ippsec You mentioned the "cost of storage" which is ofc. a tipical security/logging team point of view while more the rules mean bigger the impact on the performance. It will mostly hurt before you would run out of log storage. So I would mention the performance impact as the real cost instead.
@@ippsec You jumped back and forth in the rules and the explanations were quite inaccurate, but comments are there so... maybe just a few notes:
- the rules at the beginning are also important.
- the purpose of opasswd is to store the "old passwords" and keep track of changes. (man pwhistory_helper)
- auid is the original ID the user logged in with. So even if you sudo/su/whatever to an another user, it will keep track of your user id. (man auditctl)
- who is moving towards ufw? It's a Canonical/Ubuntu "thingy". Linux distros are moving towards nftables for a while (which is quite painless because of iptables-nft) or eBPF maybe... ufw is a simple tool which works with iptables(legacy) on Ubuntu as they couldn't change to nftables yet for some messed up lxc-compatibility issue. But maybe I'm wrong.
- 0x06 was SIGABRT
The ippsec user is a member of adm, which has read access to the logs. It’s also a member of lxd, as that’s the default configuration when installing with vmware, and there’s a PrivEsc there too.
The point of that section was to demo the logs you can get out of linux and show why logging is important. Not perform perfect hardening, which I agree *should* be done. However, that takes actual time to prep so something I did start to finish on a Sunday afternoon, would take multiple days and multiple eyes to get it right.
That’s just not worth it when at the end of the day the video will earn me $30-40 over the course of a year. Which I put 6-7 hours into so my hourly rate for that was around $5/h. So at that rate I stick to shitty demos and hope people use it for inspiration and not to be a SME