This blog post provides an in-depth analysis of #Turla's #Kazuar v3 loader and how it tries to slip past modern defenses:
• Sideloading via MFC satellite DLLs
• Control flow redirection trick (+ POC)
• Patchless ETW and AMSI bypasses (+ POC)
• Extensive COM usage for registry, file and folder operations (+ partial POC)
• Strings encryption (+ IDAPython decryption noscript)
• Including IOCs and Yara rules
https://r136a1.dev/2026/01/14/command-and-evade-turlas-kazuar-v3-loader/
• Sideloading via MFC satellite DLLs
• Control flow redirection trick (+ POC)
• Patchless ETW and AMSI bypasses (+ POC)
• Extensive COM usage for registry, file and folder operations (+ partial POC)
• Strings encryption (+ IDAPython decryption noscript)
• Including IOCs and Yara rules
https://r136a1.dev/2026/01/14/command-and-evade-turlas-kazuar-v3-loader/
R136a1
🇷🇺 COMmand & Evade: Turla's Kazuar v3 Loader
This blog post analyzes the latest version of Turla’s Kazuar v3 loader, which was previously examined at the beginning of 2024. The upgraded loader heavily utilizes the Component Object Model (COM)...
DumpBrowserSecrets has been updated to v1.1 featuring compile-time string obfuscation, API hashing, command-line argument and PPID spoofing via NtCreateUserProcess and more.
https://github.com/Maldev-Academy/DumpBrowserSecrets
https://github.com/Maldev-Academy/DumpBrowserSecrets
GitHub
GitHub - Maldev-Academy/DumpBrowserSecrets: Extracts browser-stored data such as refresh tokens, cookies, saved credentials, credit…
Extracts browser-stored data such as refresh tokens, cookies, saved credentials, credit cards, autofill entries, browsing history, and bookmarks from modern Chromium-based and Gecko-based browsers ...
Bypassing Windows Administrator Protection
https://projectzero.google/2026/26/windows-administrator-protection.html
https://projectzero.google/2026/26/windows-administrator-protection.html
projectzero.google
Bypassing Windows Administrator Protection - Project Zero
A headline feature introduced in the latest release of Windows 11, 25H2 is Administrator Protection. The goal of this feature is to replace User Account Cont...
Create local administrators with the SAMR API ✅Implemented in C#, Python, Rust or Crystal
https://github.com/ricardojoserf/AddUser-SAMR
https://github.com/ricardojoserf/AddUser-SAMR
GitHub
GitHub - ricardojoserf/AddUser-SAMR: Create local administrators with the SAMR API. Implemented in C#, Python, Rust or Crystal
Create local administrators with the SAMR API. Implemented in C#, Python, Rust or Crystal - ricardojoserf/AddUser-SAMR
There are two main password attacks leveraged by adversaries; one is called Password Spraying and the other is called Kerberoasting.
This post focuses on identifying accounts that may be targeted for Kerberoasting and how to harden the environment against Kerberoasting.
Password spraying involves the attacker using a list of passwords and for each password attempts to authenticate as each user using that one password. After working through all users with the first password, they move on to the next password in the list. Successful authentication is noted along the way as these are compromised accounts.
Kerberoasting is possible when an Active Directory account has a Kerberos Service Principal Name (SPN) associated with it. In order to enable Kerberos authentication for an application, the associated service account needs a SPN. Kerberoasting takes advantage of the fact that one can request a service ticket using the SPN associated with a target service account and take that Kerberos service ticket offline to attempt to crack it. Attackers are most likely to attempt Kerberoasting on the accounts with passwords that are about 5 years and older since they are more likely to have poor passwords, though attackers may just attempt kerberoasting all AD accounts that have SPNs.
For more information on how Kerberoasting works as well as detecting Kerberoasting. read this article: adsecurity.org/?p=3458
I wrote a short PowerShell noscript that identifies all accounts with SPNs as well as Active Directory admin accounts with SPNs (leverages the Active Directory PowerShell module):
github.com/PyroTek3/Misc/…
TO DO LIST:
1. Remove SPNs from AD Admin accounts associated with people since they shouldn't have any SPNs associated with them.
2. If the default domain administrator account is listed here, work to remove the SPN associated with it. This account should never have a SPN.
3. Remove SPNs from the other accounts associated with people since they shouldn't have any SPNs associated with them.
4. Identify service accounts identified as AD Admin accounts (those that are members of Administrators, Domain Admins, or Enterprise Admins). Remove accounts that don't belong and leave only those accounts that require these privileges (should be a minimal to 0 list of service accounts).
5. Identify the AD Admin accounts that have old passwords (> 5 years) and put together a plan to change those passwords, preferably with a password of >25 characters.
6. Identify the other accounts that have old passwords (> 5 years) and put together a plan to change those passwords, preferably with a password of >25 characters.
IMPORTANT NOTE:
Ignore the krbtgt account as this is required to be configured this way for AD Kerberos to work.
Do not modify the krbtgt account!
This post focuses on identifying accounts that may be targeted for Kerberoasting and how to harden the environment against Kerberoasting.
Password spraying involves the attacker using a list of passwords and for each password attempts to authenticate as each user using that one password. After working through all users with the first password, they move on to the next password in the list. Successful authentication is noted along the way as these are compromised accounts.
Kerberoasting is possible when an Active Directory account has a Kerberos Service Principal Name (SPN) associated with it. In order to enable Kerberos authentication for an application, the associated service account needs a SPN. Kerberoasting takes advantage of the fact that one can request a service ticket using the SPN associated with a target service account and take that Kerberos service ticket offline to attempt to crack it. Attackers are most likely to attempt Kerberoasting on the accounts with passwords that are about 5 years and older since they are more likely to have poor passwords, though attackers may just attempt kerberoasting all AD accounts that have SPNs.
For more information on how Kerberoasting works as well as detecting Kerberoasting. read this article: adsecurity.org/?p=3458
I wrote a short PowerShell noscript that identifies all accounts with SPNs as well as Active Directory admin accounts with SPNs (leverages the Active Directory PowerShell module):
github.com/PyroTek3/Misc/…
TO DO LIST:
1. Remove SPNs from AD Admin accounts associated with people since they shouldn't have any SPNs associated with them.
2. If the default domain administrator account is listed here, work to remove the SPN associated with it. This account should never have a SPN.
3. Remove SPNs from the other accounts associated with people since they shouldn't have any SPNs associated with them.
4. Identify service accounts identified as AD Admin accounts (those that are members of Administrators, Domain Admins, or Enterprise Admins). Remove accounts that don't belong and leave only those accounts that require these privileges (should be a minimal to 0 list of service accounts).
5. Identify the AD Admin accounts that have old passwords (> 5 years) and put together a plan to change those passwords, preferably with a password of >25 characters.
6. Identify the other accounts that have old passwords (> 5 years) and put together a plan to change those passwords, preferably with a password of >25 characters.
IMPORTANT NOTE:
Ignore the krbtgt account as this is required to be configured this way for AD Kerberos to work.
Do not modify the krbtgt account!
Russian state-sponsored threat group APT28 (aka Fancy Bear or UAC-0001) has launched a sophisticated espionage campaign targeting European military and government entities...
https://www.trellix.com/blogs/research/apt28-stealthy-campaign-leveraging-cve-2026-21509-cloud-c2/
https://www.trellix.com/blogs/research/apt28-stealthy-campaign-leveraging-cve-2026-21509-cloud-c2/
Trellix
APT28’s Stealthy Multi-Stage Campaign Leveraging CVE‑2026‑21509 and Cloud C2 Infrastructure
Russian state-sponsored threat group APT28 (aka Fancy Bear or UAC-0001) has launched a sophisticated espionage campaign targeting European military and government entities, specifically targeting maritime and transport organizations across Poland, Slovenia…