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 :)

This might come in handy as an "Evidence of Execution" artifact, although I'm not sure when exactly DCOM will log this entry (example below from a recent case, showcasing the execution of Advanced IP Scanner by the attacker):

Source: Microsoft-Windows-DistributedCOM
Event ID: 10028

"DCOM was unable to communicate with the computer 172.17.4.12 using any of the configured protocols; requested by PID 1a68 (C:\Users\<user>\AppData\Local\Temp\4\Advanced IP Scanner 2\advanced_ip_scanner.exe)."

I just thought about my old FIRSTCON presentation and the accompanying blog post (N-IOCs to Rule Them All) while reading the HP Threat Insights Report from June this year. The presented malware either created a run-key, placed the binary in the startup folder, or used a scheduled task for persistence - all techniques I covered in my research.

Quotes from the report:

"The script downloads additional files and makes the malware persistent by adding itself to the startup folder."

"XRed is stored in the ProgramData\Synaptics folder and made persistent against system reboots through a Registry Run key. Meanwhile, LodaRAT is stored in the AppData\Roaming\WinData folder and is made persistent on the PC through a Registry Run key as well as the Startup folder."

"So that the malware can continuously access new data, it installs a persistence mechanism using the Windows Startup folder."

"To launch the malware after a system restart, the PowerShell script also takes care of persistence. In this attack, the malware uses two techniques. First, it creates a Registry CurrentVersion\Run key. An mshta.exe command is written as its value, which downloads and executes the malware again. Second, it registers a scheduled task that executes the same action as the Registry key every 116 minutes. The PowerShell script also creates a second Registry Run key to trigger the scheduled task each time Windows starts."

https://dfir.ch/posts/n-iocs/

I wrote about "Abusing the 'search-ms' URI protocol handler" back in August last year, and apparently, this technique is still going strong, as presented in the latest HP Threat Insights Report from June 2025:

"However, Windows libraries not only support local folders, but also external WebDAV shares. Here, the attacker took advantage of this feature by crafting libraries that include remote WebDAV shares containing malware.

If the user opens this file, a File Explorer window opens and displays the content of the embedded path. To the user, this appears as a local folder on their computer, rather than as a remote folder controlled by the attacker.

In one of the campaigns we analyzed, a shortcut (.lnk) file disguised as a PDF document was placed in the library. The shortcut starts the built-in mshta.exe utility and loads an external HTML file. The HTML file runs JavaScript code that downloads and executes a batch script."

https://dfir.ch/posts/search-ms_protocol_handler/

The platform Mega, which is popular among attackers for data exfiltration ("Online privacy for everyone"), also provides software for file transfer to the platform. As one of our customers found out the hard way, the software does not use a high port for data transmission. Instead, it utilizes standard web ports (80, 443, 8080) for data transfer.

Therefore, simply blocking high ports on the firewall is not sufficient to prevent potential unwanted data leakage. If possible, content inspection should be enabled on the proxy or firewall to block categories such as online storage, or at least restrict access to certain user groups.

"But in Q1, we also saw a new social engineering lure where the attackers started using fake website cookie banners to spread malware.

A cookie banner, which is required for GDPR compliance, is a pop-up message displayed on a website to inform users about the use of cookies and other tracking technologies. Since GDPR came to effect in 2018, these cookie banners have become commonplace on websites and are now a familiar part of our browsing experience. Attackers are exploiting users’ habit of “clicking through” cookie banners to spread malware.

If the user clicks on the “Accept” button, a JavaScript file is downloaded. The cookie banner imitates a loading icon and instructs the user to click on the downloaded file to accept the cookies. Since most users simply want to visit the website and get rid of the banner as quickly as possible, this social engineering technique is highly effective, especially when combined with other tactics, such as using lures that exploit the target’s sense of urgency or curiosity.

If opened, the JavaScript file downloads two PowerShell scripts in the background and runs them."

Source: June 2025 edition of the HP Wolf Security Threat Insights Report

Link: https://threatresearch.ext.hp.com/wp-content/uploads/2025/06/HP_Wolf_Security_Threat_Insights_Report_June_2025.pdf

I don’t know how many times I’ve discussed this topic before, but due to recent events, I'm bringing it up again: One of our customers experienced an Azure compromise - attackers gained unauthorized access to an account. The customer is a "cloud-only" organization that uses SharePoint and OneDrive for all document storage.

When we spoke with the customer's IT support technician, the first thing he said was:
"UAL (the Unified Audit Log) isn’t enabled. Why on earth can’t Microsoft just activate this proactively for all customers?"

He really struck a nerve with that statement. My team and I have preached time and again that everything else should be dropped immediately to run the following command:

Get-AdminAuditLogConfig

If the output says "AdminAuditLogEnabled : False", then it's overdue to enable UAL!

The Unified Audit Log tracks, among many other things, access to SharePoint and OneDrive. No UAL, no evidence.

It doesn't always require a hacked mailbox, for example, to send invoices with a fraudulent International Bank Account Number (IBAN). The following (modified) example from a real investigation clearly demonstrates how internal staff must also be trained to defend against this type of attack.

In this case, the HR representative changed an employee’s bank details, even though the email requesting the change came from an external source, not from within the company.

The fraud was only discovered a week later when the affected employee had still not received their salary.

Phishing awareness is important, but key personnel in departments such as Finance or HR also need dedicated training, particularly when it comes to handling requests to update banking information.

While investigating a compromised network, we found suspicious PowerShell code that ran on a domain controller. The script downloaded a file called chrome_installer.exe and installed it.

We checked the file and found it was signed by Google, so it’s a genuine Chrome installer. We searched for snippets from the code online and found the exact same script on a website titled "Install Chrome on Windows Server."

So basically, an (domain) administrator copied some random PowerShell script from a random site on the Internet and ran it - on a domain controller!

What could possibly go wrong? 🤯