Dumping LSASS to a file named lsass.dmp is not exactly stealthy tradecraft anymore. However, I was reading the analysis of the BravoX ransomware group from my colleague Florian Scheiber, and he writes:

A memory dump of the lsass.exe process (lsass.dmp) was created on a server, hardly a subtle move, but when there is no one watching, there is no judge. [1]

I checked our case data, and this is more common than one might assume 🫣.

Elastic has had a detection rule since December 2020 [2]. Would your detection stack catch it?

[1] https://labs.infoguard.ch/posts/bravox/bravox/
[2] https://github.com/elastic/detection-rules/blob/f8fdc29f73df76b58038695769547cbd002dbcc0/rules/windows/credential_access_lsass_memdump_file_created.toml

One of our pentesters was tasked with assessing a customer's perimeter and found an exposed FTP server. They queried the server's FQDN on a specialized service and (surprisingly?) found leaked login credentials.

One set worked. Upon logging in, they discovered dozens of webshells! Someone had clearly found these leaked credentials before we did and tried to exploit the server. The first sign of exploitation dates back to 2024, although the credentials had already leaked in 2022.

The customer was lucky the upload directory wasn't directly reachable from the internet; otherwise, it would have been an RCE in under a minute.

Is monitoring for leaked credentials and secrets part of your security posture?

On a recent Linux-based Incident Response case, we found a dropped GSocket binary as a persistence mechanism [1]. The threat actor planted the dropped binaries under user-space directories to blend in, specifically masquerading as legitimate system processes:

./.config/dbus/php-fpm
./.config/htop/defunct

Persistence was established via standard execution vectors, either triggered through cron entries or embedded within profile startup scripts (.bashrc / .profile).

The "echo large-base64-blob piped to bash" is not really hard to miss (see image), but I had to laugh about the first line: DO NOT REMOVE THIS LINE. SEED PRNG. :)

As this was an older compromise, I took the secret from another file planted next to php-fpm (called php-fpm.dat, holding the secret) and tested the reverse shell locally using gs-netcat -s <secret_from_the_dat_file> -i, which gave me shell access under the user who started gsocket in the first place.

Global Socket is a pretty cool project, and the website goes to great lengths to explain the various scenarios. You might want to hunt for these binaries on your Linux fleet :)

[1] https://www.gsocket.io/

As today is the 10th of April, I'm giving away a 10% discount on my upcoming Anti-Forensics training in Belgium at the end of the month.

We still have seats left (somebody booked in just yesterday). Personally, I think it will be awesome, but I might just be biased 🤓

Register with code FORENSICS10!

Link:
https://www.brucon.org/training-details/anti-forensics-

CC: @brucon

📢 Hands-On Training: Anti-Forensics (and Anti-Anti-Forensics) Techniques for Incident Responders @ BruCON 2026

I’m excited to announce my upcoming hands-on training at BruCON 2026 in Mechelen. This in-depth technical course is designed for Incident Responders who want to understand and defeat modern anti-forensics techniques actively used by threat actors.

The training progresses from foundational anti-forensic concepts to advanced techniques observed on Windows and Linux systems, with a strong focus on real-world detection and analysis.

Key Learning Objectives:

🔹 Identify and analyze classic and modern anti-forensic techniques
🔹 Correlate specific anti-forensic techniques with telltale forensic artifacts, understanding what remains and what's altered
🔹 Learn real-world analytical methods to detect, reconstruct, and recover evidence affected by anti-forensic methods

📍 Location: Mechelen, Belgium (BruCON 2026)
📅 Training Dates: April 22–23, 2026

Register here: https://www.brucon.org/training-details/anti-forensics-

"Reverse Evidence", Log clearing, Anti-Forensics.

VoidLink – A Stealthy, Cloud-Native Linux Malware Framework discovered by Check Point this week - is equipped with techniques to delete or manipulate logs and traces, making it harder for Incident Response teams or security software to find forensic evidence.

I will be teaching my new course, Anti-Forensics (and Anti-Anti-Forensics) Techniques for Incident Responders, in Belgium this April at the BruCON Training (Spring Training 22-23 April), presenting a wide range of anti-forensic techniques and how to analyze your way around them.

Sign up to learn more about how to defeat modern threats 🤓

Here is the link to the training:
https://www.brucon.org/training-details/anti-forensics-

I recently thought about the different pop-ups I receive every day on my Mac, AND how malware does the same to trick people into entering their password.. and I wondered if I could tell a legitimate prompt from a malicious one. I found a good article, depicting exactly this topic:

"One of the primary aims of most malware is to trick you into giving it your password. Armed with that, there’s little to stop it gathering up your secrets and sending them off to your attacker’s servers. One of your key defences against that is to know when a password request is genuine, and when it’s bogus." [1]

If you are like me, don't worry no more. Read the article, and be maybe a bit safer out there :)

[1] https://eclecticlight.co/2025/12/18/how-to-recognise-a-genuine-password-request/

Neshta. The gift that keeps on giving. I wrote about Neshta two years ago, and now this week, we found traces of this malware strain on two domain controllers in a breached network. [1]

As last time, the TA brought infected files into the compromised network, helping spread the infection. The file and registry paths have not changed in our case and are still the same as in my old X post.

What's funny (not funny) is that I browsed the Malware Analysis section of VX Underground yesterday, and in 2006 (when this section started), there were only two papers about Malware families uploaded in that year. One of them was Neshta! [2]

19 years later - still alive and kicking 😂 Cheers to that!

[1] https://x.com/malmoeb/status/1646324779849482241
[2] https://vx-underground.org/Malware%20Analysis/2006/2006-01-15%20-%20Win32-Neshta/Paper

Companies frequently approach us to discuss their security posture, playbooks, architecture, etc., but I wonder how many of them also regularly check basic configuration settings? An example from a recent case:

We were investigating yet another compromised network, where we were at first puzzled by the missing logon records inside the Security event logs. Log clearing, anti-forensics?

It turned out to be something simpler. The company, for whatever reason, turned off logging for Logons, as a quick check with auditpol revealed (see image). However, "Logon and Logoff" auditing is enabled by default. [1]

You might want to consider checking your audit policy settings before writing yet another playbook 🤓

[1] https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/audit-policy-recommendations?tabs=winclient

During a recent engagement, we reviewed the collected AutoRuns data from all endpoints on the network. In that dataset, we identified the following scheduled task:

Name: 523135538
Command Line: C:\programdata\cp49s\pythonw.exe

There are a few things odd here. First, the name of the Scheduled Task (some random numbers). Second, the installation Path (Programdata\cp49s\). Third, Python is launched without any command-line arguments or a reference to a Python script, meaning the interpreter is started by itself.

Our initial hypothesis was DLL sideloading. After examining the Python directory, we identified a file named sitecustomize[.]py:

"Python's sitecustomize[.]py and usercustomize[.]py are scripts that execute automatically when Python starts, allowing for environment-specific customizations. Adversaries can exploit these files to maintain persistence by injecting malicious code." [1]

Path: C:\ProgramData\cp49s\Lib\sitecustomize[.]py
Content: See the image below.

So, this means that every time the Scheduled Task runs, the Python interpreter is executed, effectively loading the malicious Python file named b5yogiiy3c.dll. A pretty sneaky way, and something you should watch out for during your next hunting session or IR gig. 🤓

[1] https://detection.fyi/elastic/detection-rules/linux/persistence_site_and_user_customize_file_creation/