lingo.lol is one of the many independent Mastodon servers you can use to participate in the fediverse.
A place for linguists, philologists, and other lovers of languages.

Server stats:

66
active users

#threathunting

0 posts0 participants0 posts today
sydney<p>New guest post on THOR Collective Dispatch from <span class="h-card" translate="no"><a href="https://infosec.exchange/@InfoSecSherpa" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>InfoSecSherpa</span></a></span>:</p><p>Don’t Let Mis(s) Information Take the Crown 👑</p><p>Even threat hunters can get tripped up by polished propaganda.</p><p>This post shows how to apply the Intelligence Cycle to news, helping you filter bias, validate sources, and structure OSINT like a pro.</p><p>Read it: <a href="https://dispatch.thorcollective.com/p/dont-let-miss-information-take-the-crown" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">dispatch.thorcollective.com/p/</span><span class="invisible">dont-let-miss-information-take-the-crown</span></a> </p><p><a href="https://infosec.exchange/tags/threathunting" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>threathunting</span></a> <a href="https://infosec.exchange/tags/thrunting" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>thrunting</span></a> <a href="https://infosec.exchange/tags/threatintelligence" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>threatintelligence</span></a> <a href="https://infosec.exchange/tags/OSINT" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OSINT</span></a> <a href="https://infosec.exchange/tags/infosec" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>infosec</span></a> <a href="https://infosec.exchange/tags/THORcollective" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>THORcollective</span></a></p>

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

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

global.ptsecurity.com/analytic

Intel 471 Cyborg Security, Now Part of Intel 471 #ThreatIntel #ThreatHunting #ThreatDetection #HappyHunting #readoftheday

global.ptsecurity.comMalicious packages deepseeek and deepseekai published in Python Package IndexAs part of our threat research and monitoring efforts, the Supply Chain Security team of the Threat Intelligence department of the Positive Technologies Expert Security Center (PT ESC) detected and prevented a malicious campaign in the Python Package Index (PyPI) package repository. The attack targeted developers, ML engineers, and ordinary AI enthusiasts who might be interested in integrating DeepSeek into their systems.

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.

bleepingcomputer.com/news/secu
#IncidentResponse

BleepingComputer · FBI wipes Chinese PlugX malware from over 4,000 US computers
More from Sergiu Gatlan

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.

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.

github.com/ssnkhan/adversarial

GitHubGitHub - ssnkhan/adversarial-threat-modelling: Supporting materials for my "Intelligence-Led Adversarial Threat Modelling with VECTR" workshopSupporting materials for my "Intelligence-Led Adversarial Threat Modelling with VECTR" workshop - ssnkhan/adversarial-threat-modelling

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.

about.gitlab.com/releases/2024

#ThreatIntel and #ThreatHunting examples are included at the link

GitLabGitLab Critical Patch Release: 17.3.3, 17.2.7, 17.1.8, 17.0.8, 16.11.10Learn more about GitLab Critical Patch Release: 17.3.3, 17.2.7, 17.1.8, 17.0.8, 16.11.10 for GitLab Community Edition (CE) and Enterprise Edition (EE).

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".

kostas-ts.medium.com/threat-hu

Medium · Threat Hunting Metrics: The Good, The Bad and The UglyBy Kostas

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
research.checkpoint.com/2024/u

Cyborg Security Intel 471 #CyberSecurity #ThreatIntel #ThreatHunting #ThreatDetection #HappyHunting #readoftheday