mastouille.fr est l'un des nombreux serveurs Mastodon indépendants que vous pouvez utiliser pour participer au fédiverse.
Mastouille est une instance Mastodon durable, ouverte, et hébergée en France.

Administré par :

Statistiques du serveur :

645
comptes actifs

#threathunting

0 message0 participant0 message aujourd’hui

Okay, so I wanted to share a little incident from a few months back that really hammered home the power of knowing your Linux internals when things go sideways. I got a frantic call, "something weird is going on with our build server, it's acting sluggish and our monitoring is throwing odd network alerts." No fancy EDR on this particular box, just the usual ssh and bash. My heart always sinks a little when it's a Linux box with vague symptoms, because you know it's time to get your hands dirty.

First thing I did, even before reaching for any specific logs, was to get a quick snapshot of the network. Instead of netstat, which honestly feels a bit dated now, I immediately hit ss -tunap. That p is crucial cause it shows you the process and user ID for each connection. What immediately jumped out was an outbound TCP connection on a high port to a sketchy-looking IP, and it was tied to a process that definitely shouldn't have been making external calls. My gut tightened. I quickly followed up with lsof -i just to be super sure no deleted binaries were clinging on to network connections.

With that IP and PID in hand, I moved to process investigation. pstree -ap was my next stop. It showed the suspicious process, and more importantly, its parent. It wasn't a child of systemd or a normal service. It was spawned by a build script that shouldn't have been executing anything like this. That hierarchical view was key. Then, to really understand what this thing was doing, I dared to strace -p <PID>. Watching the system calls unfurl was like watching a movie of its malicious intent: it was reading from /etc/passwd, making connect() calls, and trying to write to some odd /tmp directories. Simultaneously, I checked ls -l /proc/<PID>/exe to confirm the actual binary path (it was indeed in /tmp) and /proc/<PID>/cwd to see its working directory. No doubt, this was a rogue process.

Knowing it was a fresh infection, I immediately shifted to the filesystem. My go-to is always find / -type f -newermt '2 days ago' -print0 | xargs -0 ls -latr. This quickly pulls up any files modified in the last 48 hours, sorted by modification time. It's often where you find dropped payloads, modified configuration files, or suspicious scripts. Sure enough, there were a few more binaries in /tmp and even a suspicious .sh script in a developer's home directory. I also scanned for SUID/SGID binaries with find / -perm /6000 just in case they'd dropped something for privilege escalation. And while stat's timestamps can be tampered with, I always glance at atime, mtime, and ctime on suspicious files; sometimes, a subtle mismatch offers a tiny clue if the attacker wasn't meticulous.

The final piece of the puzzle, and often the trickiest, is persistence. I checked the usual suspects: crontab -l for root and every other user account I could find. Then I cast a wider net with grep -r "suspect_domain_or_ip" /etc/cron.* /etc/systemd/system/ /etc/rc.d/ and similar common boot directories. Sure enough, a new systemd timer unit had been added that was scheduled to execute the /tmp binary periodically. Finally, I didn't forget the user dotfiles (~/.bashrc, ~/.profile, etc.). It’s surprising how often an attacker will drop a malicious alias or command in there, assuming you won't dig deep into a developer's setup.

Long story short, we quickly identified the ingress vector, isolated the compromise, and cleaned up the persistence. But what really stuck with me is how quickly you can triage and understand an incident if you're comfortable with these fundamental Linux commands. There's no substitute for getting your hands dirty and really understanding what strace is showing you or why ss is superior to netstat in a high-pressure situation. These tools are your best friends in a firefight.

Who loves YARAify? We do! 💛 And now there’s even more to love with the latest cool features making threat hunting easier🕵️‍♂️. Now you can...

👉 Auto-delete files after scanning! If enabled, YARAify now deletes raw files after 7 days - while keeping scan results and metadata available. Want to keep those juicy files private? You can still disable file sharing ⛔

👉 Trigger a file rescan for a previously uploaded sample! Also accessible via the API. ✨ Bonus: Grab Python 3 script from our GitHub repo: github.com/abusech/YARAify

👉 Deploy YARA rules directly via the API! ✨ And, yes, there’s a sample script on GitHub for that too!

🎥 Want a walkthrough? Jump to 11:08 in this demo to see these updates in action:
youtube.com/live/xobmSNfZ-sk

Hey Hey People,

DA Here.

Do you, have a Suricata sensor in your network?

Do you, use Suricata as a part of sandbox that you run?

Have you, been hammering away at finding evil, and want to find more?

I'm doing a webinar courtesy of OISF this Thursday. 3PM UTC, which translates to 10am EST.

I'll be talking about two things during this meeting: One, is making good use of the ET INFO rule category as an early warning system.

Sure, there is a lot of noise to sift out of ET INFO, and for that reason, some choose to just cut it entirely. I'm here to show you how to grab the stuff we've seen in our sandboxes that can help to lead anomaly detection.

In the second part of this talk, I will talk about how you can convert network and system-specific artifacts into a set of Honeytoken-like IDS rules that again, can lead to anomaly detection, and perhaps even catching advanced or unidentified threats.

Here is a link to register for the meeting: us02web.zoom.us/webinar/regist

ZoomWelcome! You are invited to join a webinar: Honeytoken IDS rules and ET INFO Rules for Anomaly Detection with Tony Robinson. After registering, you will receive a confirmation email about joining the webinar.This talk is going to be a double header, focusing on ways to spot anomalous activity for threats that may or may not have specific signatures. First, Tony will the value the ET INFO rule category can provide in spotting some of this anomalous activity. He'll discuss the rules use that provide value in spotting unusual activity, and how attendees can customize the ET INFO rule category to better suit their needs. The second part of this talk will show attendees how to use system specific artifacts to create IDS rules that can detect exfiltration of this data, for detecting anomalous activity. He'll also discuss using cyberchef to tranform and encode this data in various ways to create rules to detect obfuscation methods attackers use when exfiltrating this information. If there is time, Tony will talk about collaboration he has done with the maintainers of the secureworks dalton project that might make development of rules like this much easier.

🎯 Introducing PowerShell-Hunter: Your New Favorite Event Log Analysis Tool!

🔍 Tired of drowning in PowerShell logs? We've got you covered:
• Smart pattern detection for malicious behaviors
• Risk scoring to prioritize threats
• Export to CSV/JSON for your workflow
• Extensible pattern matching

🚀 Perfect for:
• Incident Response
• Threat Hunting
• Forensics
• SOC Analysis

🔥 Get started: github.com/MHaggis/PowerShell-

🚀 Exciting News: Kunai’s Latest Release is Here! 🎉

We’re excited to announce the newest release of Kunai, an open-source security monitoring and hunting tool for Linux systems! This version introduces many fixes and features to improve flexibility, performance, and usability.

What’s new?
🔧 Fixes: Improved process tracking ensures that even zombie processes can’t escape detection!

🌟 Enhancements: Simplified configuration and accurate process ancestorship tracking.

🚀 New Features:
- Composite Rules: Modular, reusable rules for efficiency and simplicity.
- String Templates: YAML-based templates for concise, maintainable rules.
- File Create Event Tracking and more!

📚 Documentation is updated with all the changes at: why.kunai.rocks/

Dive into the release details: github.com/kunai-project/kunai

why.kunai.rocksBring your Linux Threat-Hunting capabilities to the next level | KunaiDescription will go into a meta tag in <head />
#OpenSource#Linux#DFIR

Today training about #ThreatHunting with #Wireshark by Chris Greer was very good. Great selection of pcaps from various stages of the cyber attacks inspired us to ask questions and discuss together in depth details and anomalies hidden in the packets.
Also the private room on #Tryhackme platform works great. It is nice to see our progress during the course and receive the instant feedback.

To be humble, I do not know Chris before this training and I was not really sure what to expect from today (I originally registered for the different Threat Hunting training, which was later replaced by this one). But now I can really recommend Chris and his training to everyone interested in packet analysis and network intrusions. Good job and thank you.

#sharkfest #sf24eu @wireshark

RE: ioc.exchange/@wireshark/113424

IOC.exchangeWireshark (@wireshark@ioc.exchange)Attached: 1 image The pre-conference classes are underway at SharkFest'24 EUROPE! Chris Greer & Ross Bagurdes are teaching in depth classes on Wireshark. https://sharkfest.wireshark.org #sf24eu #Wireshark #PacketAnalysis