Stephan Berger

Head of Investigations @InfoGuardAG

[Stephan Berger @malmoeb]

New Field Note: Reconstructing an Attacker’s Workflow

During a recent incident, we recovered several PowerShell scripts an attacker left behind. They revealed a surprisingly practical post-exploitation toolkit:

- File-based command execution
- Credential harvesting through Windows authentication prompts
- Active Directory reconnaissance and remote WMI access testing
- SMB share discovery and permission checks

Parts of this tradecraft overlap with activity Microsoft documented in its analysis of the TerminalFix campaign, a ClickFix variant that ultimately deploys a reverse tunnel into the victim network

Link: https://t.co/MHNqD5U98D

[Stephan Berger @malmoeb]

My teammate @mgreen27 put together a new Velociraptor artifact to "inventory PHP installations on Windows, Linux and macOS for remediation scoping. Collect package versions, common binary/module paths and running PHP processes."

https://t.co/AjKGlJFLlp

This might come in handy in the upcoming days 🙈

[Stephan Berger @malmoeb]

Unit 42 also published their findings recently:
https://t.co/Z0l76hNrfU

[Unit 42 @Unit42_Intel]

SEO campaign drops a trojanized MSI impersonating PuTTY that installs a Node.js loader alongside a legitimate, signed PuTTY GUI as a decoy. C2 server is resolved through #EtherHiding. Operator pushes JS for recon, exfil and live screen streaming. Details: https://t.co/Btq3FkwRMH

[Stephan Berger @malmoeb]

An investigation into an EtherRAT infection revealed how a malicious MSI impersonating Advanced IP Scanner was inadvertently distributed to four endpoints through a legitimate Microsoft Intune deployment. We trace the infection from a suspicious GitHub repository to the enterprise software distribution process and show forensic artifacts that helped reconstruct the attack.

https://t.co/9n6oxDarsB

[Stephan Berger @malmoeb]

@0gtweet Thank you. I just stumbled yesterday upon this short write-up from Unit42, using sc.exe sdset to "hide":

https://t.co/ebuEumHi1v

[Stephan Berger @malmoeb]

@MurmusCTF @littlelailo Status?

[Stephan Berger @malmoeb]

Python 3.15 (the final release is currently scheduled for October 9, 2026) introduces .start files as a structured replacement for executable import lines in .pth files.

A .start file in site-packages references a package.module:callable. Python imports the module and invokes the callable during interpreter startup, before the user-supplied Python code runs. From a DFIR perspective, this creates another startup artifact worth checking when investigating unexpected Python execution or persistence.

A wrote a short blog post about it, with an example showcasing the technique:

https://t.co/PTzIF7glb1

[Stephan Berger @malmoeb]

I would say the same :) As I've written:

"The rootkit is using insmod to load the malicious module, and the module itself resides on disk. Plus, after loading, you face various rootkit detection techniques. Loading it before any EDR / security tooling might be the easier part of the whole "stealth" journey."

The startup process was the interesting bit here for me, not the hiding one.

[Stephan Berger @malmoeb]

“Crucially, this service is configured with Before=sysinit[].target, ensuring the rootkit executes on every system boot prior to the initialization of any security tooling.” [1]

This is an interesting approach, but it may be worded too generically. With DefaultDependencies=no and Before=sysinit[.]target, the malicious systemd unit is deliberately moved into very early userspace initialization. That can matter from a detection perspective: if an EDR only attaches its eBPF programs, kprobes, tracepoints, or other telemetry after its userspace service starts, the rootkit may already have loaded and established its hooks by then.

But "before any security tooling" is too absolute IMO. In the analyzed unit (see blog post from TALOS), the rootkit is explicitly stating "After=systemd-modules-load.service", so kernel modules loaded through the normal early boot path may already be resident.

The rootkit is using insmod to load the malicious module, and the module itself resides on disk. Plus, after loading, you face various rootkit detection techniques. Loading it before any EDR / security tooling might be the easier part of the whole "stealth" journey.

[1] https://t.co/1tncRgzTPO

[Stephan Berger @malmoeb]

I published a short field note about TrickDump, and how we encountered this technique in a recent engagement:

https://t.co/UwGW6Ar4S4

[Stephan Berger @malmoeb]

My colleague @mgreen27 published velociraptor-skills, a set of reusable AI skills for DFIR with Velociraptor.

These skills guide artifact selection, collection, hunting, analysis, and context management. They use a shared Python harness, vraptor, through a command-line interface rather than an MCP server or individual AI tools. The goal of using a separate harness is to optimize token use, control performance, and standardize the format of generated analysis notes.

Read the full blog post here: https://t.co/RHFnuNEEnG

[Stephan Berger @malmoeb]

This GPO-based “ransomware without ransomware” technique is pretty cool: abuse trusted Group Policy to deliver the impact, without ever dropping an encryptor on Windows endpoints.

But there is something slightly amusing about framing “traditional ransomware detection wouldn’t catch this” as the big defensive challenge.

By the time an attacker has domain-admin-equivalent privileges, can create and link GPOs at the domain root, turn off the firewall domain-wide, and exfiltrate data, there have likely been plenty of opportunities to detect them before the ransom wallpaper appears.

Not detecting the ransomware binary isn't the same as not detecting the attack. 🙂

https://t.co/BF5t1zugKC

[Stephan Berger @malmoeb]

MacSync's iCloud Calendar trick is pretty cool. One MacSync downloader analyzed by Securelist contains a URL such as: https://caldav.icloud[.]com/published/...

It retrieves a public .ics calendar, creates an anonymous pipe, launches zsh -s, sets the pipe as stdin, and feeds the calendar into it line by line. Most of the iCalendar content is obviously not valid shell syntax, so zsh simply produces errors as it works through it. Eventually, however, it reaches attacker-controlled shell commands embedded after the DESCRIPTION: field, and executes them.

Those commands then download the next stage, again from iCloud. So, effectively, a public iCloud Calendar is being used as a trusted-hosted shell-script carrier.

icloud[.]com is already listed by the Living Off Trusted Sites (LOTS) Project for malicious downloads and exfiltration, but not, as far as I can see, for this particular technique. Definitely something to watch for.

Source: https://t.co/6k93Rbwhrf

[Stephan Berger @malmoeb]

As mentioned in yesterday’s post, several users downloaded a malicious installer that ultimately executed ChainScript.

Part of the Hands-On Recon chain involved taking screenshots using PowerShell. The screenshot below shows the relevant code. This becomes particularly interesting from a detection perspective when PowerShell logging is enabled, and the resulting events are collected centrally.

As is often the case, Elastic already has a detection rule covering this technique. It looks for PowerShell content containing:
CopyFromScreen AND ("System.Drawing.Bitmap" OR "Drawing.Bitmap")

A nice example of how relatively simple PowerShell Script Block Logging can expose attacker collection activity.

Source:
https://t.co/Ycr0oXy6Y7

[Stephan Berger @malmoeb]

Recently, we responded to a single-host infection that our SOC handed over to us. The user downloaded a malicious "Remote Desktop Connection Manager" - well, actually, a legitimate tool developed by Microsoft- but attackers were now misusing the brand. See the first screenshot, where the user followed a classical malvertising, landing on the site in the second screenshot.

After downloading and running the installer (leading to an infection), the attackers had full access to the infected device (and leveraged that access to take screenshots via PowerShell (more on that on another tweet) and use SSH to pivot to the internal network). The RAT was ChainScript, as nicely depicted here. [1]

As soon as we took over this case, we began hunting inside the network for traces of lateral movement and/or similar techniques (TTPs, IOCs). Additionally, we found 3 additional infected computers with the same malware, with infections occurring in a short time span.. which was like.. what happened here?

It turns out the devices belonged to employees on the same team, and the employee who had the first infection pasted the malicious link in a Teams Chat, encouraging the rest of the team to install the same software from the same malicious site (d'oh).

So the saying could not be truer: Trust, but verify. Always download trusted software from legitimate sites; as this example shows, an infection (infections!) can happen within minutes.

[1] https://t.co/XKeK4MNy0F

[Stephan Berger @malmoeb]

For the love of the (macOS) game. My new blog post covers a macOS DFIR blind spot:

zsh startup files such as .zshrc, .zprofile, and .zshenv can have compiled .zwc counterparts. If the compiled file is newer, zsh may use it instead of the plaintext version, meaning investigators could inspect a benign-looking .zshrc while missing the code that was actually executed.

.zwc files are not encrypted, and much of their logic, strings, commands, and control flow can still be recovered. The post demonstrates practical triage with zcompile -t and strings, introduces a static zwc-decompile parser for reconstructing compiled shell logic without executing it, and notes that several common macOS forensic tools do not explicitly collect these compiled startup files.

The full blog post here: https://t.co/Wf2xcZ2v0B

[Stephan Berger @malmoeb]

What I learned today: auto_prepend_file

auto_prepend_file is a standard PHP configuration directive. It names a file that PHP parses automatically before the script that was actually requested. Point it at a payload, and that payload executes on every single PHP request to the site.

.user.ini is how that directive gets set without server access. When PHP runs as FastCGI or PHP-FPM, which is the normal configuration on modern shared and cPanel hosting, PHP reads a per-directory .user.ini file that any account with file-write access can create. No root, no control-panel login, and no server configuration change is required. Write access to the web directory is enough, which is precisely what we encountered on a recent Incident Response engagement.

But a .user.ini file does not automatically mean your server is compromised.

In our case, we identified several such files in different directories. However, when you find a .user.ini with the content "auto_prepend_file = hpzgadna.php" (spot the random filename?), then you might want to have a closer look.

More information here:
https://t.co/hvexBeo4GI

[Stephan Berger @malmoeb]

On a recent Incident response case, we encountered VMkatz.

"It extracts Windows secrets - NTLM hashes, DPAPI master keys, Kerberos tickets, cached domain credentials, LSA secrets, NTDS.dit, BitLocker keys - directly from VM memory snapshots and virtual disks, on the NAS, the hypervisor, wherever the VM files are." [1]

Defender detected it with the following signature: VirTool:Win64/Vekesz.A

The out-of-the-box release from the GitHub page is also heavily flagged, but one could compile (and obfuscate) the code to stay under the radar. In our case, the attacker just disabled real-time monitoring and added an exclusion:

Set-MpPreference -DisableRealtimeMonitoring $true
Add-MpPreference -ExclusionPath "C:\"

And then pointing it to a directory, "and let it find everything", as pointed out in the documentation.

./vmkatz.exe C:\ClusterStorage\CSV01\node-002\

I think monitoring for AV alerts (and exclusions!) could go a long way. The basics make the difference. ☝️

[1] https://t.co/nH7mjCZiw7