And here is the second part of the Cleartext Password Series:
https://dfir.ch/posts/fantastic_passwords_windows/
Remote
Stephan Berger
@malmoeb@infosec.exchange
Head of Investigations @ InfoGuardAG
1180
Followers
1094
Following
31
Posts
Joined November 06, 2022
Blog:
Twitter:
Posts
In a recent ISC SANS Diary, Xavier Mertens discussed a malicious ZIP archive that led to Remcos, a pretty common RAT.
As Xavier noted, "Most of the files used in this infection path remain undetected by most AVs." [1]
PowerShell, AppData, Dynamic DNS, and Run Key as a persistence mechanism. Four of the eight areas I covered in my first blog post, N-IOCs to Rule Them All [2]. The information presented remains relevant, and finding such infections is not as hard as it sounds, even if they might bypass AV rules and signatures.
[1] https://isc.sans.edu/diary/From+a+VHDX+File+to+a+Remcos+RAT/33080/
[2] https://dfir.ch/posts/n-iocs/
I created two blog posts based on my Fantastic Cleartext Passwords talk, which I presented last year at BSides Munich, and I released the first part (Linux) today.
The second part (Windows) will be released next week.
Even if these techniques are not novel, I still consider them interesting enough to publish and, most importantly, to raise awareness of all the places an attacker could steal your password. Enjoy.
Link to the first part:
https://dfir.ch/posts/fantastic_passwords_linux/
Replying to
@cxiao@infosec.exchange
In March, I had the pleasure of attending the course “Advanced Linux Malware Reverse Engineering" with Marion Marschalek. Since reverse engineering isn’t my main area of expertise, my brain was completely fried by the end of each evening (I’d end up lying on the hotel bed watching episode after episode of House Hunters 😂). I hadn’t been challenged like that since the EDR Evasion course, about which I wrote a summary on my blog. I’ll most likely write a summary of Marion’s course as well.
And today… I solved the ShadowMonarch challenge on HTB!
“Your mission is to fully reverse engineer this sophisticated [Linux] backdoor, understand its BPF-based evasion mechanism, reconstruct the activation protocol, and extract all indicators of compromise.”
And it was really cool. I solved the challenge using Binary Ninja (coming from an IDA background), which, even though BJ is great, still required me to switch back and forth a bit within the menu at certain points…
We learned so much during Marion’s four-day training, and as I was reverse engineering the sample, I had that “aha, I recognize this” feeling so many times. System calls, how to start the analysis, and how to figure out which functions might correspond to which parts of the malware. Really cool! And, manual reversing combined with some AI support is incredibly fast, especially when analyzing BPF bytecode.
Thank you so much, Marion, for the extremely cool course! As you can see, you’re a great teacher; I definitely learned a thing or two :)
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?
Replying to
@Xavier@infosec.exchange
@Xavier@infosec.exchange do you still have problems accessing the site? works for me.
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 -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 :)
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! :)
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-
A big shout-out to the @toulousehacking@bird.makeup 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.
📢 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-
In the Metasploit Wrap-Up from last week, a new Python Site-Specific Hook Persistence module was released. [1]
I wrote a detailed blog about this persistence, which I think is pretty cool. [2] If you have never heard of this technique, you might want to read up on it.
[1] https://www.rapid7.com/blog/post/pt-metasploit-wrap-up-01-09-2026/
[2] https://dfir.ch/posts/publish_python_pth_extension/
To quote my teammate Evgen Blohm (@ChaplinSec): "Shadow IT at its best."
He responded to an intrusion involving (successful) brute-force attempts from an unknown IP range. Yup, not just an unknown IP address or device, from an unknown IP range (Yikes). The customer later informed us:
"We've now located the network. It was an SSL VPN network that was apparently still active on the FortiGate for several users. The VPN function has now been deactivated."
Oh well..
The observed hostname that conducted the brute-force was "packerp-qdo4b3v" - packerp-* was also mentioned on other blogs, see reference section below. Yet another use case for monitoring hostnames roaming around in the network 🤓 - and invest some time in the new year to get rid of your shadow IT. ☝
References:
https://arcticwolf.com/resources/blog/lost-in-the-fog-a-new-ransomware-threat/
https://thedfirreport.com/2024/12/02/the-curious-case-of-an-egg-cellent-resume/
My teammate Asger Deleuran Strunk worked on a case where the TA tried to dump LSASS with procdump on a server, resulting in Defender blocking the attempt:
1117 HackTool:Win32/DumpLsass.A Tool Remove No additional actions required CmdLine:_C:\Users\svc_ldap_sso\Desktop\procdump64.exe -accepteula -ma lsass.exe C:\programdata\over.png
See the username? My first impulse is that this username (svc_ldap_sso) should never run anything on a server, and definitely not execute malicious commands (procdump, per se, it's not malicious, but this combination is likely not legit). I consider such AV alerts critical because a) somebody is trying to dump LSASS, and b) service accounts should not have a dual purpose, especially not used for daily operations.
When we checked the security logs for that server:
Successful logon (type: Network) for account 'svc_ldap_sso' from 'kali' (10.10.10.180)
As I've preached so many times before, analyzing the hostnames roaming your network could be a great canary! It's simple alerts that could save your day, like the one that shows "kali" on your network (and no, this was not a pentest).
I loved the latest blog post from Huntress, "Why Some Malware Attacks Aren't as 'Sophisticated' as You Think", which reflects what we see in our daily Incident response work. [1] Yes, we respond to APTs, but many attackers (especially ransomware groups) are not what I would call "sophisticated".
[1] https://www.huntress.com/blog/trial-error-typos-malware-attacks-sophisticated
This was an interesting alert, raised by an EDR:
****
Uncommon creation or access operation of sensitive shadow copy by a high-risk process
The process HoboCopy.exe created or accessed a sensitive Shadow Copy volume path. This causality and actor pair were seen on 0 hosts and 0 unique days in the last 30 days.
The sensitive shadow copy path: \Device\HarddiskVolumeShadowCopy93\Windows\System32\config\SAM
****
Hobocopy?
"Hobocopy is a free, open-source backup tool for Windows. It can copy files that are locked, so you can do things like back up your Outlook .pst files without closing Outlook." [1]
Hobocopy is over 15 years old (😲), but it is still used by attackers today, maybe because vendors do not flag it as much as other backup tools (read, rclone, for example) used by ransomware groups.
I think the "causality and actor pair were seen on 0 hosts and 0 unique days in the last 30 days" is pretty cool, and one should definitely pay attention to such alerts.
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 🤓
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. 🤓
You might have a detection gap here. I was reading about some bash history shenanigans, where I learnt that if a terminal is stopped with the `kill` command, commands are still written to .bash_history. This is because, by default, kill sends the SIGTERM signal, which gracefully kills the process and allows Bash to write to .bash_history as it closes down.
However, if the -SIGKILL switch is used, commands are not written to .bash_history. SIGKILL kills the process immediately before the commands can be written to the file. [1]
Matt, in his scenario, noted that using the -SIGKILL switch ends the terminal process and SSH session immediately, but still writes the commands run during the session to the user’s .bash_history file. This is contrary to my testing on a new Ubuntu machine (where I was connected via SSH), where SIGKILL prevents bash history from being written.
Looking at the Elastic rule for "defense evasion - tampering of Bash command line history", SIGKILL is missing. [2] However, writing effective detection logic for this specific use case might not be as straightforward as one might think, because we are passing the PID of Bash to the kill command, and that PID varies every time I open a new instance of Bash. Plus, kill is a frequently used command. What are your thoughts here?
[1] https://mattcasmith.net/2022/02/22/bash-history-basics-behaviours-forensics
[2] https://github.com/elastic/protections-artifacts/blob/cce5ebfcaf4288a77a369546f0dd21b1dd549e99/behavior/rules/cross-platform/defense_evasion_tampering_of_bash_command_line_history.toml
My team colleague, Yann Malherbe, worked on a case where the attacker used Everything [1] (locate files and folders by name instantly) to search for password files on the beachhead.
The interesting thing here is that Everything keeps track of files opened from within its interface. This information is stored in the file Run History.csv.
The file consists of Filename (self-explanatory, with the full path), Run Count (how many times have I opened the file), and Last Run Date (represented in Windows FILETIME, a count of the number of 100-nanosecond ticks since 1 January 1601 00:00:00).
Despite the classic forensic artifacts that could show the attacker opened various files of interest, this was another fun artifact to discover (and surely yet another tool attackers use to stay under the radar).
The picture below depicts a (malicious) Inbox Rule. I slightly modified this Inbox Rule to protect our customer, but the gist is that it filters incoming mail from a specific bank employee, moves it to the RSS Folder, and marks it as read.
The owner of the mailbox will never see that email, because honestly, who is looking at the RSS folder anyway? At least not your regular employee.
This is a super common pattern in our investigations. Silly-named rule names (three stars in this example, a dash sometimes, three points, you get it), moving emails to specific folders (RSS, Conversation History), and marking them as read. Nothing you could not spot from your own investigation. It's also interesting how much of a giveaway such an Inbox Rule can be. Once you have found such a rule in the mailbox of one of your employees, the chance that it is a false positive is really small.
So, just based on such an Inbox Rule, you can immediately tell that the account is compromised, and you can start the full investigation circle. I still recommend the Business-Email-Compromise-Guide from PwC left and right, because it sums up all these cases around Inbox Rules well.
If you haven't read it or never heard of it, now is the time to read it
For a new project, I started to dig into older threat reports, like for example, "The ProjectSauron APT" from 2016. [1]
The interesting thing about these old reports is that you see techniques mentioned before that are still used 10 years later.
"ProjectSauron usually registers its persistence module on domain controllers as a Windows LSA (Local System Authority) password filter. This feature is typically used by system administrators to enforce password policies and validate new passwords to match specific requirements, such as length and complexity. This way, the ProjectSauron passive backdoor module starts every time any domain, local user, or administrator logs in or changes a password, and promptly harvests the passwords in plaintext."
There are various ways to register such "password filters", but the screenshot is from a recent case (and from one of my presentations) in which the attacker registered a new NetworkProvider to steal cleartext credentials. Techniques which are 10+ years old are still working and (mis-)used by attackers.. 🤷
We are familiar with eMClient and axios, so let me introduce Trufflehog, the new kid on the block.
Trufflehog made headlines during the recent "Shai-Hulud" campaign, in which threat actors used it to search for passwords and sensitive information. [1] According to the Trufflehog GitHub page:
"TruffleHog can look for secrets in many places, including Git, chats, wikis, logs, API testing platforms, object stores, filesystems, and more."
Recently, we responded to an incident in which Microsoft Defender identified compromised service principal accounts in a customer tenant. During the investigation, the sign-ins into both accounts with the User-Agent "Trufflehog" were a clear indicator that both service principals had been compromised.
Trufflehog has a module for the authentication with service principal secrets. [3] For teams monitoring Azure logs, this User Agent might be another one you want to look out for. See the article on the Wiz Cloud Threat Landscape here as well. [4]
[1] https://unit42.paloaltonetworks.com/npm-supply-chain-attack/
[2] https://github.com/trufflesecurity/trufflehog
[3] https://github.com/trufflesecurity/trufflehog/blob/b6389e24199ff37a98a48f90b95d775af819a95d/pkg/detectors/azure_entra/serviceprincipal/sp.go
[4] https://threats.wiz.io/all-tools/trufflehog
I was playing around with bincrypter from THC (The Hackers Choice) [1]. The interesting points, as you can see in the screenshot below, are that the binary is encrypted, obfuscated, and 100% in memory. No temporary files, etc.
I encrypted a local copy of netcat, and indeed, there are no strings or evident signs of its purpose within the encrypted binary. However, I started this new version of netcat on my lab host, in listening mode. I then dumped the netcat process's open file descriptor and got a fully working binary back (see the second screenshot).
Including cleartext strings, and with the ability to reverse-engineer that binary.
Yes, one thing might hinder our analysis ("lock a binary to a target system and make it fail to run anywhere else"). However, when you are doing live forensics, dumping malicious binaries directly from the open file descriptor(s) in /proc (or via maps) is a huge advantage against tools like bincrypter. Yes, I love /proc, and so should you 🤓