🛬👨‍🏫🛫🔁 I love being a speaker. I also love meeting people, hearing their thoughts, and exchanging ideas.

While I was enjoying tapas in the charming old town of Donostia-San Sebastián, I had a lengthy conversation with an elderly gentleman from Glasgow.

One of his statements stayed with me for days: He said that traveling strengthens understanding between countries and peoples, that you should talk to each other more and be more open to different thoughts... which is precisely how I feel. In times like these, we should be reaching out to each other more, showing understanding, and building bridges instead of throwing bombs and occupying countries. 🕊️

Yesterday, I presented "Anti-Forensic" techniques for Windows and Linux at the Troopers conference in Heidelberg. This morning at breakfast, I was approached by an attendee and asked if I had looked at the zapper tool from The Hacker's Choice. [1]

I said no, but of course, my interest was piqued 🕵

The tool's description on GitHub states: A Linux tool to hide from 'ps'. And that's exactly what it does very well. As in the example from GitHub, I have started a tmux session in my lab, and based solely on the ps output, it is not possible to determine whether tmux is running.

However, /proc to the rescue 🥳. The exe link in one of the (malmoeb) /proc process folders points to tmux, and this way, we could find out relatively quickly what is running behind the process, even if we don't have the command line from the process available.

My team colleague, @hackerkartellet, and I have talked intensively about /proc, available on YouTube. [2]

[1] https://github.com/hackerschoice/zapper
[2] https://www.youtube.com/watch?v=eeYptKewVQ0&t=1s

A teammate of mine worked on an interesting incident where the attackers connected to the backup server via RDP, launched the Chrome browser, and searched on Google for "VirtualBox".

The VirtualBox installer was then downloaded to the home directory of the compromised user:
C:\Users\<user>\Downloads\VirtualBox-7.1.6-167084-Win.exe

This file is a Windows installation package that the attacker used to set up a VirtualBox environment, allowing them to create an operating system without endpoint protection. The newly created virtual machine had the hostname "WIN-D1V1F70QJLC".

The attacker then logged into this newly created virtual machine to carry out further tasks without logging, antivirus, or EDR monitoring.

An attacker downloaded a freely available webshell from GitHub and stored it under the installation path of the legitimate SAP installation in the recent SAP Visual Composer exploitation, "disguised" as a PHPMyAdmin file (see image).

The code itself is relatively simple, accepting a base64-encoded class via HTTP on a specified parameter, to dynamically load and run that class.

That type of Webshell, from the AntSwordProject [1], was also named by Mandiant last year in conjunction with an investigated APT41 intrusion, as well as in some reports from PaloAlto [2,3,4].

Given that most Linux servers are not equipped with an EDR or an AV, how would you detect such a webshell on your servers? The curated YARA rule from Florian Roth is a good starting point for hunting through your web and application folders to find hidden malicious files. [5] Velociraptor's Yara artifact is one example of how to accomplish this.

[1] https://github.com/AntSwordProject
[2] https://cloud.google.com/blog/topics/threat-intelligence/apt41-arisen-from-dust
[3] https://unit42.paloaltonetworks.com/cve-2022-22965-springshell/
[4] https://unit42.paloaltonetworks.com/actors-still-exploiting-sharepoint-vulnerability/
[5] https://raw.githubusercontent.com/Neo23x0/signature-base/a065133ff5763435e4e9e0f6bc72344c44b1824f/yara/gen_webshells.yar

The screenshot below is from a recent Incident Response case, investigated by my team colleague. The user "printer" suddenly sprang to life because an attacker brute-forced the VPN login (without Multi-Factor Authentication).

This was not the first time a "printer" account was breached in our investigations. This might indicate that companies are setting up regular accounts for service tasks, like printing (??), and equipping the account with a weak password and no MFA. Of course, such a "service account" should never be allowed to log into the network over VPN in the first place.

However, this is an interesting example of "User behavior analytics", as this account was never seen logging in over VPN, nor generating such a usage pattern. An anomaly that could stand out in monitoring.

During various Ivanti Endpoint Manager Mobile investigations (CVE-2025-4428), we (as others in our field) saw that the threat actors dumped heap memory from the Tomcat Java processes using jcmd, in order to search the dumped data for sensitive information.

Have others seen this behavior in other campaigns, from other actors? Dumping heap memory to steal sensitive information? Elastic, for example, does not have an (open source) rule for jcmd.

Example command:
ps ax | grep java | grep tomcat | awk '{print $1}' | while read p; do jcmd $p GC.heap_dump /tmp/th.$p; done;

If I were to start a new job at a company, and if I have one (security-related) wish .. If I could pick anything, I’d ask for a clear naming convention for all computers and servers. Additionally, I’d want DHCP and security logs to be stored centrally in a SIEM system.

That way, I could set up an alert for anything that stands out, such as devices with names that don’t follow the naming convention (but have requested an IP from the DHCP server), or logins or failed login attempts in the security logs coming from devices that, again, don't follow the naming convention.

As in the latest ransomware case, the attacker used a hostname like WIN* - instant red flag!

Sure, there are edge cases - such as people using personal devices — but we can address these by creating a whitelist or simply banning personal or edge-case devices from the network. I think this kind of monitoring could help detect intrusions very early on.

As I'm about to present about Linux Rootkits at the 10th edition of EuskalHack (🎉), here’s a nifty trick to detect a userland rootkit that tries to hide its presence by blocking access to /etc/ld.so.preload.

We are mounting the filesystem with debugfs (an interactive file system debugger. It can be used to examine and change the state of an ext2, ext3, or ext4 file system), and suddenly we see the malicious entry in the /etc/ld.so.preload file 😎

I successfully tested a LSASS dumping technique on a Windows 10 lab machine, which we encountered on a recent Incident Response engagement (no EDR, default Defender installed).

The "MiniDumpWriteDump" technique, as described here [1], was successful in writing the LSASS process to disk.

However, as soon as I tried to copy the dump to my Kali machine, Defender jumped into action, prohibited access to the LSASS dump, and removed the file to the quarantine. And here is the catch.

I browsed to the following folder:
C:\ProgramData\Microsoft\Windows Defender\Quarantine

In the ResourceData folder, you will find different sub-folders (or not, if Defender never quarantined something on that host), each folder containing a quarantine file.

The files are encrypted with a static key that leaked years ago, and this 10-year-old code snippet is still sufficient to decrypt the files back to their original state. [2]

Long story short: I copied the encrypted file to my Kali machine, decrypted it using the Python code from [2], and extracted the credentials and hashes with pypykatz. [3]

Classic example of "No, it's not enough when your AV blocked or removed a threat". As you can see, an attacker can easily get the LSASS dump, even if Defender removed it from the disk ¯\_(ツ)_/¯

[1 ]https://www.ired.team/offensive-security/credential-access-and-credential-dumping/dumping-lsass-passwords-without-mimikatz-minidumpwritedump-av-signature-bypass
[2] https://raw.githubusercontent.com/malmoeb/DFIR/refs/heads/master/quarantine.py
[3] https://github.com/skelsec/pypykatz

This might be a niche persistence mechanism, but during an investigation, I stumbled upon the following file on a Linux server:

/home/<user>/.config/autostart/set_trusted.desktop

With the following content:

[Desktop Entry]
Encoding=UTF-8
Exec=/usr/bin/set_trusted.sh
Name=Set trusted
Comment=Set desktop file trusted
Terminal=false
OnlyShowIn=GNOME
Type=Application
X-GNOME-Autostart-enabled=true

Do you spot the "exec" command? An attacker could replace the legitimate path to the "set_trusted.sh" file with an arbitrary file, thereby (potentially?) gaining code execution whenever the user logs in.

I don't know how widespread that feature is, and how many distributions are supporting it (Nautilus?), but maybe it will come in handy for someone :)