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.
Is anyone familiar with this kind of file name? Looks like it's generated from some sort of C2 framework but I'm not sure what. #threathunting
Netflow telemetry does show Tailscale DERP traffic over port 3478 so keep that port in mind if traffic starts to look strange. Actors have been seen switching from bare Wireguard tunnels to Tailscale for...reasons.
#ThreatHunting #Networking #Tailscale
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: https://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:
https://www.youtube.com/live/xobmSNfZ-sk
FWIW, 100% of #ClickFix attacks I've seen have added some kind of inline comment at the end of the command string like I am not a robot
to sell the ruse. Definitely worth a threat hunt on command line history.
Today's important #ThreatHunting lesson: If you're seeing a bunch of traffic over HTTP to qq[.]com
domains with /mmtls
URIs, it's WeChat.
Attention Thrunters!
Part 3 of the DEATHCon thrunting workshop is live! @Jotunvillur and I break down a hypothesis-driven scenario step by step. Grab your hammer and sharpen your skills!
Read now: https://dispatch.thorcollective.com/p/a-deathcon-thrunting-workshop-overview-part-3
Good day everyone!
While #DeepSeek is making headlines as a competitor to the leading AI tools, bad actors are taking advantage of the hype. Positive Technologies's Supply Chain Security Team detected and prevented a malicious campaign in the Python Package Index (PyPi). The targets were developers, ML engineers, and ordinary AI enthusiasts who were looking into DeepSeek. They noticed a user uploaded two packages, deepseeek and deepseekai that contained functions to collect user and computer data and steal environment variables from it's victims.
Go check out the article for the rest of the technical details and this is a nice example of the good guys getting a win, your work is much appreciated! Enjoy and Happy Hunting!
Malicious packages deepseeek and deepseekai published in Python Package Index
Intel 471 Cyborg Security, Now Part of Intel 471 #ThreatIntel #ThreatHunting #ThreatDetection #HappyHunting #readoftheday
I've had to analyze several MS Quick Assist compromises and found challenges during each one. Threat Hunting for malicious activity thru QA is not easy either.
So I wrote a blog post on what to look for: https://inversion6.com/resources/blog/january-2025/microsoft-quick-assist-an-it-security-primer
The #FBI has mass-removed the #PlugX #malware from infected US computers. The infections were attributed to #MustangPanda (aka #TwillTyphoon).
Remember this is just one botnet of #PlugX it's still used in the wild by many other threat actor groups.
For you #DFIR folks, ensure you know how to go #ThreatHunting for DLL-Side Loading to find #PlugX in your network.
https://www.bleepingcomputer.com/news/security/fbi-wipes-chinese-plugx-malware-from-over-4-000-us-computers/
#IncidentResponse
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: https://us02web.zoom.us/webinar/register/WN_MJogFww8S4mIpEOctaTZlw#/registration
openSquat - An open-source tool for detecting domain look-alikes by searching for newly registered domains that might be impersonating legit domains and brands.
I’ve updated the materials for my “Intelligence-Led Adversarial Threat Modelling with VECTR” workshop.
This latest release is a complete remaster of the presentation I delivered at @x33fcon, providing more detailed guidance and insights on the processes and methodologies, as well as expanding the hands-on aspect of the workshop with new exercises.
GitLab instances are inheriting the Ruby SAML Auth vuln #CVE202445409 that allows threat actors to forge SAML Assertions. #GitLab drops emergency updates for this CVSS 10/10.
Note that IdP SSO having MFA does NOT protect against this attack. Patching or MFA on the Instance is required.
https://about.gitlab.com/releases/2024/09/17/patch-release-gitlab-17-3-3-released/
#ThreatIntel and #ThreatHunting examples are included at the link
@CassandraVert @Kostas Very true, but it's worth figuring it out. Basically, it's "why is my team's work valuable?" If you can't answer that, you've got some problems coming your way, I think.
The #PEAK framework gives a core set of five metrics that most #ThreatHunting teams can use as-is, and most teams can probably come up with a few other that apply to their specific circumstances.
I love a good discussion of #ThreatHunting #metrics, like this one from @kostastsale. The #PEAK framework has a section on metrics which pretty much agrees with this article. My approach to metrics is "avoid measuring how hard you worked and concentrate on the impact your work had".
https://kostas-ts.medium.com/threat-hunting-metrics-the-good-the-bad-and-the-ugly-d662907379b2
You asked, and we delivered! Check out the new Microsoft Incident Response Ninja Hub for a compilation of the research and guides that the Microsoft IR team has developed over the years on threat hunting, case studies, and more.
If you have access to Azure AD / Entra / M365 / O365 / whateverTheyCallItThisWeek logs, Error ID 50053 can be super useful. If you take the events with the Failure Reason "Sign-in was blocked because it came from an IP address with malicious activity" and hunt on those IPs in other parts of the org, any hits are pretty high fidelity in my experience.
Since Microsoft doesn't make their malicious IP list available AFAIK, this is a way to use some of their threat intel in a way that's contextualized to your org. Be sure to look retroactively as far back as your org maintains logs. Sometimes the IP isn't considered malicious until months after your org sees activity from it.
This is definitely meant for retrohunting and not for up-to-the-minute lists to update firewall rules, but it's still proven quite useful for me.
Good day everyone!
Check Point Software researchers provide us a detailed report on a newly discovered malware the #StyxStealer! It is capable of "stealing browser data, instant messenger sessions from Telegram and Discord, and cryptocurrency" and contains defense evasion techniques. While the malware may be new, one technique that stood out isn't! The use of the Windows run registry key for persistence (Software\Microsoft\Windows\CurrentVersion\Run) is not.
This registry key is abused because of the function it carries with it: you can reference an executable or script or whatever you want in the registry details and it will execute once a user logs in. This removes the need for the adversary to have to social engineer or compromise a host over and over again.
Knowing that, enjoy the article and stay tuned for your Threat Hunting Tip of the Day!
Unmasking Styx Stealer: How a Hacker’s Slip Led to an Intelligence Treasure Trove
https://research.checkpoint.com/2024/unmasking-styx-stealer-how-a-hackers-slip-led-to-an-intelligence-treasure-trove/
Cyborg Security Intel 471 #CyberSecurity #ThreatIntel #ThreatHunting #ThreatDetection #HappyHunting #readoftheday