Setting up the Attack 

We start with three machines: 

• DC01 – the domain controller (10.10.10.10) 

• Windows11-Client01 – a workstation (10.10.10.40) 

• Kali Linux – the attacker’s machine (10.10.10.106) 

On Kali, we enable packet forwarding and run the arpspoof tool to trick both the client and the domain controller into believing that Kali is the other host. This successfully poisons the ARP cache, redirecting their communication through our machine. 

Sniffing ICMP Traffic 

With ARP spoofing active, we capture traffic in Wireshark. When the Windows client pings the domain controller, we clearly see ICMP packets routed through Kali – confirming the attack worked. 

Sniffing SMB Traffic 

Next, we look at SMB2 traffic. When the Windows client connects to the domain controller and creates a file (e.g., Secret.txt containing SomePassword123), the traffic is transparently routed through the Kali machine due to the ARP-spoofing attack. As a result, the unencrypted SMB data can be captured in Wireshark, allowing the file and its contents to be intercepted and saved. Not only can we view it in real time, but we can also export the file directly from Wireshark and save it locally. 

Key Takeaway 

This demo shows how ARP spoofing combined with unencrypted SMB traffic can expose sensitive information. Even if no passwords are typed directly, files containing credentials or other secrets can be silently intercepted. 

The lesson: Always secure your protocols. Use SMB encryption, network segmentation, and proper monitoring to prevent these types of attacks. 

And if you’re hungry for more cybersecurity knowledge, we’ve opened the registration for our 6-weeks Advanced Windows Security Course 2026, ensuring you’re prepared for the threat landscape of the next year!

Check out the course offer >>

---

Transcript of the video:

Hi and welcome back to another episode of CQURE Hacks.
Let’s dive into a new video.

Here we have a domain controller, let’s check.
We use host name and it’s DC01 then IP config.
The address is 10.10.10.10.

Next the Windows workstation host name and then we see it’s Windows 11 client 01.
ipconfig shows the address 10.10.10.40.

Finally, the Kali Linux machine: ifconfig – the address is 10.10.10.106.

But first, we need to prepare it by switching to root with sudo -s.
For the ARP config attack to work we need to enable packet forwarding and we do this with the command:

echo 1 > /proc/sys/net/ipv4/ip_forward

We also need the dsniff package, but it’s already installed here.

We know that DC01 has the address 10.10.10.10 and the Windows client has 10.10.10.40 so we can use the arpspoof tool from the dsniff package.
We specify the eth0 interface, and the command is:

arpspoof -i eth0 -t [Domain controller's IP address] -r [client's IP address]

The -r option means that we act in both directions.
The domain controller thinks we are the client and the client thinks we are the domain controller.

Now we see ARP replies where both IPs 10.10.10.10 and 10.10.10.40 are mapped to the same MAC address ending with 61:18:ae.
That’s the MAC of our Kali machine.

On Windows, we can check with arp -a.
The MAC 61:18:ae is assigned to both Kali and DC01, which confirms that ARP spoofing is active.

Let’s start Wireshark on Kali Linux.
Wireshark is a packet analyzer.
It can analyse traffic similar to tools like TCP dump.
It also allows capturing network traffic.

We see available interfaces eth0 and any which captures all.
We select eth0 and start listening.
In the display filter we type ICMP.

On the Windows client, we run: ping DC01.
We can see the ping is working.
The traffic goes from 10.10.10.40 to 10.10.10.10, and then replies from 10.10.10.10 back to 10.10.10.40.

In Wireshark we see ICMP traffic, echo request and echo reply.
If we check the Ethernet source field, we see the replies are coming from MAC 61:18:ae – our Kali machine.
That proves the ARP spoofing attack was successful.

Next we change the Wireshark display filter from ICMP to SMB 2.
Now we see SMB 2 traffic.

On the Windows client we open File Explorer and connect to \\dc01.
That’s of course the domain controller.
We see the NETLOGON folder.

Let’s create a file there named Secret.txt with the content: SomePassword123.

Back in Wireshark we can use the search function.
So for that press Control + F.
Choose the display filter and set it to string.
In the packet list switch to packet bytes.
Now type what we want to search for.

For example: “some”. Click find.
We can see the captured file Secret.txt with the content: SomePassword123.

This shows that with an ARP spoofing attack, if SMB is not encrypted, we can read transmitted content – including files that may contain passwords.

At this point we can stop Wireshark to avoid capturing more packets.
Now, let’s go to File → Export Objects.
Choose the SMB protocol.
Here we see our file Secret.txt.
We select it and click Save.

We can now save this file to the desktop as Secret.txt.
The file is saved on our desktop.

On the desktop we have Secret.txt with exactly the same content we created on the server.

This demonstrates that with ARP spoofing and unencrypted SMB, we can intercept files being transferred, including sensitive ones like password files.

The post CQURE Hacks #67 ARP Spoofing + SMB Sniffing: Stealing Files from the Network appeared first on CQURE Academy.

Understanding Hidden Services 

Let’s learn how to hide and uncover a service. This is a very important technique for post-incident investigation, as manipulating a service’s security descriptor can be a powerful method for persistence. 

There’s no direct mechanism to hide a service in Windows, but we can manipulate the Security Descriptor Definition Language (SDDL). 

We can do this using the built-in sc command. For example, if we run: 

sc sdshow <service-name> 

That gives us the current SDDL string, which we analyze when investigating persistence. 

Of course, this isn’t the only method for service persistence, but it’s one of the most important to understand. 

Demonstration: CQService 

We’ll be working with a service called CQService. 

If you open services.msc and refresh, you’ll see that CQService is running. It uses CQGoodservice.exe located in the C:\Tools folder. 

The service name and display name are the same: CQService. 

Now, if we apply a modified SDDL string using: 

sc sdset CQService <new-descriptor> 

…you’ll notice the service disappears from the list. Pressing F5 to refresh confirms this. 

Why is it gone? 

We’ve changed the service’s security descriptor to deny visibility or access through certain interfaces. 

Understanding the SDDL Structure 

In the SDDL string, there are multiple sections. The two most important are: 

• DACL (Discretionary Access Control List) 

• SACL (System Access Control List) 

We’re focused on the DACL here. 

• D: means deny 

• A: means allow 

For example: 

• IU = Interactive User (users logged in interactively) 

• BA = Built-in Administrators 

• SU = Service logon user 

There are specific permissions encoded as well: 

• DC = Delete Child 

• LC = Query Status (ability to ask SCM for service status) 

• RP = Start service 

• WP = Stop service 

• DT = Pause/Continue service 

• SD = Delete service 

So, by denying these permissions to users like IU, we effectively hide the service from standard queries. 

What Happens with PowerShell? 

Try: 

Get-Service 

The CQService doesn’t appear. 

Try: 

Get-Service -Name “CQService” 

It returns an error: the service isn’t found. But this is misleading—it is still there. 

To confirm: 

Set-Service -Name “CQService” -Status Stopped 

Suddenly, the system finds it. 

Why? Because different APIs respond differently based on permissions and visibility. 

Finding Hidden Services 

Now let’s use Autoruns. 

I ran Autoruns before modifying the SDDL. Under the Services tab, you can still see CQService and its executable. 

If we rescan, Autoruns still detects the service. Why? 

Because Autoruns reads the registry, not the SCM API. That’s why it still finds the service, even when it’s hidden from other tools. 

To go a step further, you could restrict registry permissions as well—but that’s another layer of persistence, and a separate configuration. 

Unhiding the Service 

To reverse the hiding, simply replace the SDDL with a generic or default one—maybe from another service. 

After setting a valid descriptor and refreshing the view, CQService reappears. 

Try: 

Get-Service -Name “CQService” 

Now you see it listed again. 

You can also inspect its details: the executable is still there, and the service is fully functional. 

Advanced Techniques 

There is also a way to hide a process in Windows using DKOM (Direct Kernel Object Modification). But this requires deeper access at the kernel level and often involves rootkits. 

That’s a more advanced topic, and something we could cover in further CQURE Hacks video. Let us know if you’re interested. 

And if you’re hungry for more cybersecurity knowledge, we’ve opened the registration for our 6-weeks Advanced Windows Security Course 2026, ensuring you’re prepared for the threat landscape of the next year!

Check out the course offer >>

Final Thoughts 

As you’ve seen, auditing the security descriptors of services is essential after an incident. You need to check who has the ability to start and stop services on any impacted host. 

The SC command is a powerful built-in tool for this kind of quick analysis. 

And remember, SDDL is the language used to define permissions for many object types in Windows—not just services, but also files, folders, registry keys, Active Directory objects, certificate templates, and even event logs. 

There are many creative and powerful uses for SDDL in cybersecurity. 

I hope this video helped you understand how service hiding works, how to detect it, and how to investigate and respond to these kinds of persistence mechanisms. 

Thanks a lot for watching. 

The post CQURE HACKS #66 Hiding and Modifying Windows Services with Service Control appeared first on CQURE Academy.

The threat is real – legitimate users can engineer malicious programs that deceive target systems into establishing authentication with a fake SMB server. This exploitation method delivers maximum system authority to attackers, granting them comprehensive dominance over the infiltrated machine.

So, let’s see how granting this access looks like in practice.

Before attempting exploitation, two conditions must be verified:

• The target machine must have SMB signing disabled. This configuration weakness permits authentication relay attacks through the SMB protocol.
• COERCER Vulnerability: The target system must be susceptible to authentication coercion techniques, which force the machine to initiate authentication requests to attacker-controlled servers.

Attempt 1: exploitation without adding DNS record

In this approach, we run the relay on this machine. Afterwards, we run PetitPotam and direct it to ourselves.  

Result? PetitPotam worked, but the machine couldn’t authenticate without the mentioned DNS record. 

Attempt 2: using a dedicated DNS record

We’re adding the DNS record to the IP address of the domain controller, and indicating it to our machine. Now, let’s also put add in the place of remove.

With these conditions, the operation is completed successfully.

Attempt 3: using the indication of the added DNS record

After re-running the ntlmrelay again, we change our IP address by the DNS record.  

And just like that, we succeeded, and our machine is relayed to itself. We dumped SAM successfully.

Attempt 4: skipping the DNS record

First, we start with turning off the relay, clearing it and adding one more terminal. 

We delete the previously added DNS record to avoid conflict, and now we can run the Responder with LLMNR poisoning. The Responder should have it turned on by default.  

Second, we can run the impacket-ntmlmrelayx and use netexec with the coerce_plus module to exploit the printerbugPrinterBug vulnerability with this DNS indication.  

You’ll see that tt doesn’t exist, but LLMNR poisoning helps us to identify our attacker’s machine.

After using it, the effect would be the same if we hadn’t added the DNS record. 

At this stage, we have obtained the hash of the local admin, so we can authenticate locally.  

Now, if we use module LSA from netexec, we can dump the LSSAS.

Conclusion

CVE-2025-33073 exemplifies how legacy authentication protocols can be exploited through protocol manipulation techniques. The vulnerability’s severity stems from its ability to transform limited network access into complete system compromise. Organizations must prioritize SMB hardening and authentication modernization to defend against these sophisticated reflection attacks.

And if you’re hungry for more cybersecurity knowledge, we’ve opened the registration for our 6-weeks Advanced Windows Security Course 2026, ensuring you’re prepared for the threat landscape of the next year!

Check out the course offer >>

---

Transcript of the video:

OK guys, let’s start by enumerating the machine that we want to attack.

First of all, we have to check if the SMB signing is off.

This allows us to relay via SMB. Next, the machine must be vulnerable to coerce.

That’s going to be the attack component. Now I’ll show you that without a special
DNS record, this attack won’t work.

But let’s try it anyway.
We run the relay on this machine and then we run PetitPotam and direct it to ourselves.
As we can see, PetitPotam worked, but a machine couldn’t authenticate without the mentioned DNS record.
OK, so let’s add this DNS record and it looks like this.
Here you have the IP address of the domain controller.
I’m adding the DNS record and indicating it to our machine.

Let me show you the IP that’s actually our machine.
So let’s also change, remove with add. OK, the operation is completed successfully.
Let’s try to launch the attack again, but this time by using the indication of added DNS record.

We rerun the NTLM relay.
Next we change our IP address by DNS record.
As you can see, we succeeded and our machine is relayed to itself.
We dumped SAM successfully.

Now I will show you the second way. We won’t add the DNS record this time.
OK, so let’s turn off the relay, clear it here and add one more terminal.

Let’s put it here.

First of all, we must delete this DNS record to avoid the conflict and make sure that everything gets just like starting from the scratch.
Now we can run the responder with LLMNR poisoning.
The responder should have it turned on by default, as you can see it’s on.
Next we can run impacket-ntlmrelayx and this time we will use netexec with the
coerce_plus module and exploit the PrinterBug vulnerability with this DNS indication.

As we can see, the effect will be the same if we hadn’t added the DNS record.
OK, so let’s see what we can do now.
We have the hash of the local admin and type admin here with his hash and as a local user
so we can authenticate locally.
We can use the module LSA from netexec.

And as we can see, we’ve got a little bit more information at our disposal.

The post CQURE HACKS #65 NTLM reflection SMB flaw – CVE-2025-33073: From zero to Domain Admin appeared first on CQURE Academy.

During the demonstration, you will see how to use PowerShell to gather more information about a user, generate a Ticket Granting Service (TGS) ticket using the S4U2proxy protocol with Rubeus, and perform a DCSync attack using Mimikatz.

This attack will show you how an account with constrained delegation rights, when compromised, can be leveraged to impersonate high-privilege users and gain elevated access to domain resources, making proper configuration and monitoring of these privileges critical for domain security.

After watching this, you can make sure to keep your kerberos delegations secure!

And if you’re hungry for more cybersecurity knowledge, we’ve opened the registration for our 6-weeks Advanced Windows Security Course 2026, ensuring you’re prepared for the threat landscape of the next year!

Check out the course offer >>

---

Transcript of the video:

So, let’s start by running PowerShell.

After using the whoami command, we see that we are JamesJ. Let’s import the PowerView module into PowerShell and get more information about user James using the Get-DomainUser command.

The user James has the value TRUSTED_TO_AUTH_FOR_DELEGATION (T2A4D) in userAccountControl; that means he can get a TGS for himself on behalf of any other user. An account can get a TGS on behalf of any user to the service set in msDS-AllowedToDelegateTo.

To do so, it first needs a TGS from that user to itself, but it can use the S4U2self to get that TGS before requesting the other.

Let’s check the next command for what it specifically owns. We see that we have the ability to delegate to LDAP and CIFS services on DC01.cqure.lab. Close PowerShell and open the command prompt. After using klist, we can see our current tickets.

Try to open the c$ directory on the domain controller. Access denied. Let’s now prepare for the attack.

The first step will be using Rubeus to change the password of our user, in this case James, to hashes/keys.

We copy the AES256 key and use Rubeus again with the s4u function.

We authenticate as the Administrator user, so in the impersonateuser we type Administrator, and in msdsspn we now use the CIFS service to get the ticket. As you can see, the ticket was imported successfully. Let’s try opening the DC01 directory again. We have successfully got the permissions to do so.

Now let’s try to connect using PsExec to DC01. We have also succeeded, let’s make sure with the hostname command that this is indeed the correct machine.

You can use whoami /all to check our privileges. We see that we are the Domain Admin. Ok, now exit this host, fire up a new command prompt, and clear our tickets with the klist purge command.

The next step is to reopen the c$ directory on DC01 after clearing the Kerberos tickets. We don’t have the permission to do it. We will now use the LDAP service instead of CIFS to show what the difference is.

We use the same command, only in msdsspn we specify LDAP instead of CIFS, and this time we’ll save the file to dc. kirbi to import it later into Mimikatz. Now let’s turn on Mimikatz and import this ticket. As you can see, importing is successful. Let’s try to use DCsync.

DCsync has been executed, and now let’s exit Mimikatz and try to reopen the c$ directory to dc01 only with the LDAP ticket.

As you can see, we can’t do this because SMB uses the CIFS service, not LDAP. And vice versa, it also works the same way the other way around. If we wanted to do a DCsync with a CIFS ticket, we can’t do it until we get the appropriate ticket.

The post CQURE Hacks #64: S4U2self in Pieces – Attacking Active Directory by Abusing Kerberos Delegation appeared first on CQURE Academy.

Undetected Malware and the Cost of Inadequate Security Measures  

One of our clients had recently implemented a new log monitoring system within their company. Shortly after deployment, the system flagged suspicious network traffic originating from two employees’ work laptops. The traffic was being routed to a foreign domain, and logs indicated that this communication had been ongoing for the past three years. Alarmed by the discovery, they turned to CQURE for assistance. 

Investigation & Findings 

The Cqure team conducted a thorough analysis of network logs and disk images from the affected devices. During this process, we identified two distinct malware programs. One of them was specifically designed to steal sensitive company data and transmit it to the suspicious foreign domain.

Upon further investigation of the domain, we discovered that it had been blackholed (blocked) by the company’s internet service provider (ISP) at some point shortly after the malware was introduced. As a result, communication between the infected devices and the malicious domain was cut off, preventing the exfiltration of sensitive data.

While the company’s systems remained intact, this wasn’t due to proactive defense measures but rather a fortunate coincidence. Had the malicious domain remained active longer, the malware could have successfully transmitted sensitive information, leading to severe data loss and security consequences.

However, despite this stroke of luck, the company still suffered massive financial losses. They were forced to halt operations to prevent a potential malware outbreak, as their network lacked sufficient segmentation to contain the threat.

What Went Wrong? 

The financial impact of this incident stemmed not from actual data theft, but from the fear and uncertainty caused by the company’s lack of security visibility. Had proper security measures been in place, this situation could have been detected and mitigated years earlier. The key weaknesses were: 

Summary

This incident highlights the importance of proactive cybersecurity measures. To prevent similar incidents in the future, companies should:

By proactively securing their environment, organizations can avoid unnecessary disruptions and financial losses caused by undetected cyber threats.

The post Real Cybersecurity Breaches: Undetected Malware and the Cost of Inadequate Security Measures appeared first on CQURE Academy.

Unauthorized Software Leads to Admin Account Takeover 

One of our clients noticed a high number of login attempts to an administrator’s account, all originating from a foreign location. Before they could isolate the account, it was deleted. Concerned about what had happened and the potential consequences, they turned to CQURE for help. 

Investigation & Findings 

The CQURE team began the investigation by conducting cloud analysis and OSINT (Open Source Intelligence). 

During the OSINT process, we discovered multiple passwords associated with the affected user’s name and surname in online databases. Additionally, we found over 30 leaked passwords related to the company’s domain. 

Armed with this information, we performed a thorough examination of the victim’s work laptop. Our analysis revealed spyware responsible for credential theft, along with plaintext password files stored in text documents. The stolen passwords matched those we had found in online databases. 

The affected user later admitted that they had downloaded the spyware based on a recommendation from an online forum they actively participated in. The software was supposedly intended to assist with their work tasks, but in reality, it had been designed to steal credentials. 

Further analysis revealed that the account deletion was not the only malicious activity within the company’s infrastructure. Here’s a timeline of the attack: 

Attack Timeline 

Day 1 – The user’s passwords appeared in online databases. This was also the day they downloaded the malicious software onto their computer. 

Day 4 – The first login attempts were made by the attackers. 

Day 6 – The first successful login using the stolen credentials. The malware intercepted the victim’s access token, which likely allowed the hackers to access the account. 

Day 7 – The attackers created a new user account using the compromised admin’s privileges. 

Day 9 – A second unauthorized user account was created and secured with MFA (Multi-Factor Authentication). The MFA phone numbers were foreign. Using this second account, the attackers then deleted the original admin account. 

Impact & Potential Risks 

Our investigation indicated that the malware did not spread to other accounts. However, the attackers’ primary objective appeared to be data theft. Had they chosen to, they could have caused significantly more damage, leading to operational disruption and financial loss for the company. 

What Went Wrong? 

The primary cause of this breach was the use of unauthorized software. If stricter policies on software installation had been in place, the incident could have been prevented. 

Additionally, our team identified several other security vulnerabilities: 

Summary

Those events highlight how a single lapse in cybersecurity hygiene –such as downloading unauthorized software – can lead to a full-scale security breach. 

To prevent similar incidents in the future, companies should:

By combining strict access controls, user awareness, and proactive monitoring, organizations can reduce the risk of credential theft and stay one step ahead of cybercriminals.

The post Real Cybersecurity Breaches: Unauthorized Software Leads to Admin Account Takeover appeared first on CQURE Academy.

By leveraging snapshots, attackers can bypass security mechanisms and extract passwords or access tokens, allowing privilege escalation across the entire network. 

Watch the video above to find out how hackers can lay their hands on passwords by taking a snapshot of the running VM along with the memory and downloading the snapshot memory status files, VMM, and VMSN accelerate.

We hope this demonstration will help you understand how hackers work and how to keep your infrastructure secure from them.

Watch the full video with step-by-step guidance

The post Hacks Weekly #63 – Attacking LSASS memory through VM snapshot appeared first on CQURE Academy.

How can the Windows Mark-of-the-Web Protection be bypassed?

Amr Thabet, Malware Researcher & Incident Handler, presented some of the scenarios in episode 62 of our #HacksWeekly series!

Windows Mark-of-the-Web Protection is just the first layer of protection.

The problems start when users use 7-ZIP or delete the specific version of the file and download it again after some time—it won’t have a ZoneId, so the Mark-of-the-Web Protection won’t be there.

One might say that this is an exception and won’t happen to most users. Well, sure. However, even those 5% of users who accidentally bypass the protection can compromise your company’s safety

That’s why you should never rely 100% on one type of protection and always have multiple security levels implemented.

Watch the full video with step-by-step guidance

The post Hacks Weekly #62 – Bypassing Windows Mark of the Web Protection appeared first on CQURE Academy.

What is MITM6? 

MITM6 is an advanced penetration testing tool that exploits default Windows DNS configurations to facilitate man-in-the-middle (MITM) attacks. It targets mainly networks where IPv6 is enabled but not actively used. By responding to DHCPv6 messages, MITM6 can redirect traffic from vulnerable Windows machines to an attacker’s system. These redirections take place because the Windows operating systems prioritize IPv6 and regularly request DHCPv6 configurations. When a client sends out a request for an IPv6 address, MITM6 listens for these requests and responds with its own configuration, assigning the attacker’s machine as the primary DNS server. 

The mechanism of attack 

How to protect against MITM6 attacks? 

Curious to uncover the practical side of man-in-the-middle attacks? Head to our video with Mike!  

Feel free to revisit this episode anytime to brush up on those cyber tips. 

Thank you for being with us, and we look forward to the next one! 

Stay curious and #stayCQURE! 

The post Hacks Weekly #61 – Man in the middle with MITM6 and NTLMRelay appeared first on CQURE Academy.

We’re happy to share that the 2024 edition is also taking place with our involvement! 

And we have to admit, this year’s agenda looks promising. As always, we’re ready to share only the most relevant skills, thoroughly tested during real-life scenarios. 

System Forensics, Incident Handling and Threat Hunting 

On December 9, you’ll have the opportunity to participate in System Forensics, Incident Handling and Threat Hunting, delivered by Paula Januszkiewicz, Cybersecurity Expert, Microsoft MVP & RD, CQURE and CQURE Academy CEO. 

This 2-day training will equip you with effective strategies to prevent future attacks. We will dive deep into incident handling, identify malicious applications and network activities. Apart from this, get ready to examine system vulnerabilities and uncover common attack techniques. 
 
You can experience a foretaste of System Forensics, Incident Handling and Threat Hunting here: 
 

SIGN UP HERE!

---

Advanced Hacking and Securing Windows Infrastructure 

Mike Jankowski-Lorek, PhD, Cybersecurity Expert, Director of Consulting of CQURE, will guide you through Advanced Hacking and Securing Windows Infrastructure from December 9 to December 10. 

During his session, you’ll learn more about high-quality penetration tests and effective network mapping. If you want to dig deeper into vulnerability identification and securing techniques – there’s no better place to be. 
 
You can experience a foretaste of Advanced Hacking and Securing Windows Infrastructure  here:  

SIGN UP HERE!

About Black Hat 

For more than two decades, the Black Hat conference has been one the most recognizable infosec events worldwide. It brings together a diverse audience, ranging from industry enthusiasts, through corporate and government professionals, to cybersecurity leaders. Held each year, it provides access to not only workshops and training sessions, but also networking opportunities. 

Join one of the most globally renowned infosec events and benefit from real-world expertise.

The post BLACK HAT EUROPE 2024! appeared first on CQURE Academy.

Over the years, the Advanced Windows Security Course has amassed hundreds of satisfied students, building a supportive community of cybersecurity enthusiasts and rising talents. We repeat it yearly, each time brainstorming to deliver the freshest techniques for combating cyber threats. As a result, the formula just keeps getting better. 

At CQURE Academy, our Experts consolidate everything they know into practice-filled classes. Uncover only the most relevant knowledge under the guidance of:

• Paula Januszkiewicz, CQURE Academy CEO, Cybersecurity Expert, Microsoft MVP & RD,
• Sami Laiho, Windows OS Expert, Microsoft MVP,
• Peter Kloep, Cybersecurity Expert, Principal IT Architect,
• Amr Thabet, Cybersecurity Expert,
• Artur Kalinowski, Cybersecurity Expert,
• Marcin Krawczyk, Cloud & Cybersecurity Expert,
• Przemysław Tomasik, Cybersecurity Expert,
• Damian Widera, Data Platform MVP, MCT, Software Engineer, Cybersecurity Expert.

This year’s agenda looks promising – have a look at what awaits you this season: 

• Module 1: Attack Case Studies and Building Incident Response Readiness Strategy
• Module 2: Zero Trust in Practice: Building Secure Architectures Beyond the Perimeter
• Module 3: Discover Your External Perimeter and Open Source Intelligence in Azure
• Module 4: AI Agents for Attack Investigation
• Module 5: Azure Cloud Incident Response – Part 1: Detection
• Module 6: Privileged Access Abuse in Databases: Detection and Defense
• Module 7: Real-World Pentesting: Windows Tips, Tricks, and Countermeasures
• Module 8: PowerShell for Digital Investigation & Threat Hunting
• Module 9: Azure Cloud Incident Response – Part 2: Response and Recovery
• Module 10: Tiering, Just-In-Time, and Admin Forest in “Real Life” (Experience from the field)
• Module 11: How to Think About Azure Kubernetes Security
• Module 12: Securing Windows Server and Applications in .NET with TLS: Implementation, Pitfalls, and Best Practices

But that’s enough about theory for now. Let’s move to the more practical part, where the real learning takes place. There’s no better way you can get a taste of our training formula than to experience it yourself!

See what you can look forward to during our live meetings. Dive into Windows Internals: Memory Management with Sami Laiho, Windows OS Expert, Microsoft MVP. 

In this module, Sami will teach you how the most important aspect of an operating system works. Nothing in Windows works without memory, both physical and virtual. Windows can’t read things from the disk; it pages things into memory. Memory fundamentals are filled with myths about the Page File settings, memory leaks, amount of RAM needed etc. During this session, Sami will do a lot of myth busting and this knowledge is vital to anyone working with operating system security and troubleshooting. 

We’ve already shared a bit about the Advanced Windows Security Course with you. Now, discover what our participants have to say about it! 

By joining our training, you’ll gain access to session recordings, additional learning materials, and custom CQURE labs to practice your skills.  

After passing the final exam, you’ll receive a “Windows Security Master 2026” certificate to showcase your skills. 

We will meet from October 28 to December 4, 2025, just in time to kickstart 2026. 

This course is limited to a select number of students only. 

Send us your application and we’ll tell if it’s a good fit.  

See you at CQURE Academy!

The post Get a Sneak Peek into the Advanced Windows Security Course! appeared first on CQURE Academy.

PetitPotam: How an NTLM relay attack can threaten Active Directory, Active Directory Certificate Services and your network  

PetitPotam is an advanced coercing attack and in combination with NTLM relay (NTLM redirection) attack it creates a serious threat to Active Directory (AD) infrastructures. By exploiting vulnerabilities in the EFS (Encrypted File System) RPC calls, PetitPotam can invoke NTLM authentication and you can intercept credentials, escalate privileges, and access vital network resources such as Active Directory Certificate Services (AD CS). The result? It gives hackers an opportunity to take control of an entire AD domain, which makes PetitPotam and default unsecure AD CS configuration a particularly dangerous combination.  

And yes, you’ve guessed it right – “petit potam” does mean a “little hippo” in French. Quite ironic, considering how much chaos it can create! 

Understanding PetitPotam 

Threats associated with the PetitPotam attack  

PetitPotam can be used for a range of attacks, including (but not limited to):   

NTLM relay in the context of PetitPotam 

What exactly is NTLM relay? It is intercepting NTLM authentication and redirecting it to another server. With PetitPotam, the attacker forces the Windows server to send NTLM authentication request to the malicious server, allowing it to perform NTLM relay attack to authenticate to AD CS Web Enrollment services and obtain certificates in context of attacked Windows server. Through these certificates, the attacker can gain control over the network by impersonating Domain Controller and then using DCSync. 

PetitPotam and Active Directory certificate services  

One of the main targets of the PetitPotam attack is Active Directory Domain Controllers in combination with Active Directory Certificate Services (AD CS) web enrollment service.  

When attackers start manipulating the authentication process, they can get their hands on certificates that allow them to access network resources as privileged users. Once they obtain certificates from AD CS, they’re on the right track to claim full administrative rights across the network. As you can see, it already sounds quite dangerous. And these are only some of the consequences that this attack can lead to. 

Prepare yourself well before PetitPotam strikes back! 

How to minimize the risk of PetitPotam and NTLM relay attacks? Here’s a list of essential steps that you should never skip:  

Staying safe against attacks 

As you can see, PetitPotam is quite a sophisticated attack. It takes advantages of vulnerabilities in the EFS and NTLM protocol and AD CS, leads to privilege escalation, and gives attackers a chance to take control of network infrastructure. 

To keep your systems safe from this threat, it’s necessary to disable NTLM, secure AD CS Web Enrollment service and keep an eagle eye on network activity – all to detect potential threats immediately. You also can’t forget about performing regular IT security updates within your systems. This way, you can prevent the entire network from being compromised. 

If you’d like to explore PetitPotam in even greater depth – there’s still an entire video with Mike waiting for you at the top of this page. Make sure to hit play and discover real-world tricks for safeguarding your infrastructure. 

You can also return to this article anytime to refresh your knowledge. 

If you have any comments or questions, feel free to shoot us a message. We’d love to hear from you!  That’s all for today, thank you for staying with us – and until the next one! 

The post Hacks Weekly #60 – PetitPotam Strikes Back: From (almost) Zero to Domain Admin appeared first on CQURE Academy.