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

We recently analyzed an interesting piece of malware that utilizes the legitimate JavaScript runtime, Deno.

The malware was used as a first-stage implant after the user was tricked into downloading and running the malware.

Read the full article here:
https://labs.infoguard.ch/posts/anatomy_deno_rat/

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?

People who have been following me long enough should know by now how much I love these nitty-gritty details of forensics, the little breadcrumbs that give you critical clues about your ongoing case.

My colleagues Andreas Klaus and Bruno Koehle recently worked on a misconduct case involving an employee suspected of installing a residential proxy on a workstation. There were little traces left, as the relevant software had been purged before the investigation. However, there was one critical hint, an XML task file inside the folder: C:\Windows\System32\Tasks_Migrated. You read that right.

The Tasks_Migrated folder is a system-generated backup and staging directory. It is not a default folder in a clean, fresh Windows installation. Instead, it is created automatically by the Windows upgrade engine (Setup/Migration routines) during a major OS upgrade, such as moving from Windows 10 to Windows 11, or applying a major Windows Feature Update.

Its primary purpose is to safely back up existing Windows Task Scheduler jobs before the OS modifies the system state, ensuring that user-defined and third-party software tasks are not permanently lost if the migration fails or the tasks become incompatible with the new build.

I guess the upgrade process goes something like this:

1) The migration engine duplicates the contents of the live \Tasks folder into \Tasks_Migrated.
2) The engine then attempts to register and import these tasks into the new operating system environment.
3) If a task successfully migrates, it is placed back into the active \Tasks folder and properly linked in the TaskCache registry hive.
4) The Tasks_Migrated folder is left behind. It effectively becomes an inert graveyard of historical scheduled tasks as they existed at the exact moment the upgrade was initiated.

This is purely speculative; I haven't tested it out in a lab. However, isn't it super interesting how many places you can find artifacts that could help you solve your case? That's why I love digital forensics so much :)

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/

Here’s another IG Labs post. After my teammate Evgen published his research on ViperTunnel last week, my other teammate, @schnee_FLO_cke, published a blog post today on BravoX, a ransomware-as-a-service (RaaS) provider.

Well done - such a great team! :)

https://labs.infoguard.ch/posts/bravox/bravox/

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

A big shout-out to the @toulousehacking Review Committee. I submitted two talks, and one was accepted. Both talks were reviewed by three reviewers, and I received their comments along with the decision (Accepted/Rejected).

This is so valuable! Even though one of the talks was accepted, I can read the concerns (too deep for the time, too little time for the introduction, etc.) and, above all, the feedback on the talk that was not accepted. The feedback helps me refine the abstract for another CFP round and improve the talk in general.

This feedback will certainly also help less experienced speakers understand the review committee's decision. Hopefully, this will help mitigate some of the negative feelings that a rejection can trigger.

So once again: very cool! Keep up the good work :)

What I learnt today: Mandatory User Profiles

Praetorian named their blog "Persistence Through Forgotten Windows Internals", and true, at least I never heard of Mandatory User Profiles before reading this article.

In enterprise environments, administrators sometimes want to enforce a specific user profile that resets on each login. To accomplish this, Windows supports a file called NTUSER[.]MAN (the .MAN standing for “mandatory”), which takes precedence over the usual NTUSER.DAT registry hive stored in %USERPROFILE% when a user logs in.

Setting up persistence on a copy of NTUSER.DAT using the Offline Registry Library might evade some EDRs. The whole blog post is worth a read, but the TL;DR for defender is:

Consider monitoring for NTUSER[.]MAN file creation in user profile directories, especially when it doesn’t come from an enterprise profile management system.

Source:
https://praetorian.com/blog/corrupting-the-hive-mind-persistence-through-forgotten-windows-internals/

📢 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-