The Experiment Setup

Our test environment was configured for maximum network security, with both the server (SRV01) and the client (WIN11-01) explicitly set to support and require SMB signing.

1. The Attacker: We used a Kali Linux machine to act as the attacker and intermediary.
2. The Attack: We launched a bi-directional ARP Spoofing attack (Man-in-the-Middle) to intercept all traffic flowing between the client and the server.
3. The Capture: Wireshark was launched on the attacker’s machine to capture the SMB2 traffic.
4. The Test: From the client system, we accessed a file share (\\SRV01\CertEnroll) and created a new file with the content: “SMB signing test”.

The Critical Finding

Despite having SMB signing enforced on both endpoints, our packet capture yielded a critical, visible finding: the entire contents of the file, “SMB signing test,” were successfully captured and clearly readable in the Wireshark packets.

The conclusion is clear: SMB signing does not protect data from a passive traffic sniffer in a man-in-the-middle scenario.

The Security Takeaway: Signature ≠ Encryption

The reason for this failure is simple: A signature is not the same as encryption.

• SMB Signing is a mechanism that prevents session spoofing and relay attacks by verifying the identity and integrity of the data sender. It ensures that the traffic hasn’t been tampered with in transit.
• SMB Encryption is a distinct mechanism that scrambles the data, rendering it unreadable to anyone without the decryption key.

While SMB signing is vital for protecting the integrity of the communication, it does not automatically encrypt the data being transferred. As a result, an attacker who successfully performs an ARP spoofing attack can still read the unencrypted SMB traffic.For true confidentiality and to protect your data from passive snooping, SMB encryption must also be implemented alongside SMB signing.

Check out the Advanced Windows Security Course for 2026 offer >>

---

Transcript of the video:

Hi and welcome back to another episode of CQURE Hacks.

Today we will observe how packet sniffing behaves when SMB signing is enabled.

We begin in Kali Linux, the attacker’s machine.

The first step is to enable IP forwarding using the echo 1 command,

and that allows Kali to act as an intermediary for network traffic.

Next, we ensure the necessary tools are installed by checking for that dsniff package.

And with dsniff confirmed our environment is ready, we move to our target systems.

On the 1st system, SRV01 (at 10.10.10.20), we check the SMB configuration.

The settings confirm that the system supports and requires SMB signing.

We perform the same check on the client system, WIN11-01 (at 10.10.10.40).

From the client side we see it also supports and requires signing.

The connection we will test will run from the client, so .40 to the server .20.

Now we’ll launch the attack from our Kali machine.

We execute the ARP Spoofing attack.

The goal is to make the Kali host the intermediary.

The traffic flowing from host .40 to host .20 will be intercepted by Kali.

We poison the ERP cache in both directions, telling host .40 we are host .20 and telling host .20 we are host 40.

This establishes a bi-directional Man-in-the-Middle attack.

Next, we launch Wireshark to capture the traffic passing through our machine.

We’ll begin to capture on our active network interface and apply a display filter for SMB2 traffic.

On the Windows client, so .40 we initiate that file access by navigating to the server share and that is \SRV01\CertEnroll.

We then create a new text file and input the content:

SMB signing test.

We return to Kali. As we confirmed signing was enabled on both the server and the client.

Now we search the captured packets in Wireshark for the content we just wrote.

We search that packet bytes for the word signing.

The critical finding is visible.

We successfully capture the entire content of the file.

SMB signing test.

This demonstrates that signing does not protect against man in the middle attacks.

The reason is super simple.

A signature is not the same as encryption.

How good is the signature if a communication is not encrypted while the attacker can still read the unencrypted SMB traffic after performing an ARP spoofing attack?

While SMB signing prevents session spoofing and relay attacks, it does not automatically encrypt data being transferred.

Signing and encryption are two distinct mechanisms.

For true confidentiality, SMB encryption must also be implemented.

SMB signing does not provide encryption and fails to protect data from a passive traffic sniffer in a man in the middle scenario.

Thank you so much for watching our Secure Hacks episodes.

And as always, in order to continue this serial, please don’t forget to support us by hitting the subscribe button.

And as always, stay secure.

The post CQURE Hacks #69: SMB Signing – Why It Won’t Save Your Data from a Passive Traffic Sniffer appeared first on CQURE Academy.

We begin on the Domain Controller, where the Group Policy setting “Network security: Restrict NTLM: NTLM authentication in this domain” is initially set to Disabled. This allows NTLM-based authentication to proceed – opening the door for potential relay attacks.

On the attacker machine (running Kali Linux), the Responder and Impacket’s ntlmrelayx tools are launched. Once a network authentication attempt is triggered, the attacker successfully relays the NTLM authentication to another host, gaining access as CQURE\Administrator. From there, the attacker can enumerate hosts, check privileges, and simulate further connections — all using the relayed credentials.

Next, we tighten security by switching the Group Policy to “Deny All”, effectively disabling NTLM across the domain. When the same attack sequence is repeated, the relay attempt fails — the target returns “status not supported.” Authentication now requires Kerberos, which is not vulnerable to NTLM relay in the same way.

This demonstration clearly shows the real-world impact of disabling NTLM: the attack surface for NTLM relay disappears.

However, phasing out NTLM completely requires careful planning, monitoring, and identification of systems or applications that still depend on it.

For a deeper dive, check out the CQURE NTLM Phase-out Guide for Active Directory Environments – and start preparing your organization for a more secure, NTLM-free future.

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 Advanced Windows Security Course for 2026 offer >>

---

Transcript of the video:

Hi and welcome back to another episode of CQURE Hacks.

In this video, I’m going to demonstrate how NTLM relay attacks work and what happens when NTLM is disabled.

We start on the domain controller, checking the Group Policy.
We look at the setting:
Network Security → Restrict NTLM: NTLM authentication in this domain.

As you can see, it is currently set to Disabled.

Now on our attacker machine (Kali Linux), we will launch the tools.
First, we start Responder.
Next, in a second window, we set up the NTLM relay with the Impacket ntlmrelayx tool.

The tool initializes its servers and is ready for the attack.

Now we’re going to run \\test\123 just to trigger it.
There we go — back on Kali.

We immediately see the relay succeed.
The tool reports a connection and authenticates to the target as CQURE\Administrator.
That credential can be used for further actions.

Now that we have it, let’s try the connection.
As you can see, we have 11001, and we can pull full details about the hosts listed.
That lets us see what privileges we currently have while leveraging this attack.

In this context, we can also simulate connections to those hosts.

Now, whenever we get in here — as you can see, many poisoned responses — those are expected in verbose mode.

Next, we return to the domain controller and enforce a much stricter policy.
We change Restrict NTLM — NTLM authentication in this domain — from Disabled to Deny All.
Then NTLM version 2 will no longer be in place.

Let’s quickly apply the policy, then test whether these attacks still work so you can see the real-world effect.

On Kali, we restart our attack.
First, Responder is relaunched,
and then the ntlmrelayx tool is started again — ready to catch and relay authentication attempts under the new policy.

We are waiting for these authentications to happen so that we can grab that response.
Yep, we can do the same part — \\test\12345, whatever.

We capture the authentication attempt,
but the initial authentication to the target fails.

So, at this point, we no longer have the ability to authenticate using NTLM.

If we try to test with SMB netexec using the captured credential (for example, supplying the captured password),
the attempt fails — the target returns “status not supported.”

But if we check it with Kerberos, as you can see, we’ve got the possibility to get in.

So, at the end, it really depends on how we are doing this spray — how that activity is processed.

And in the end, you’ve got the possibility to compare what it means to have NTLM disabled or not.

Ultimately, this deprecation is about gathering information on which sources, applications, and services still rely solely on NTLM version 2.
That’s the key issue.

Basically, we can add exceptions, and those are applied directly within the policy.

And just for reference — this was a quick introduction because many people are concerned about one key question:
How do we actually phase out NTLMv2?

As you can see, the process is fairly simple —
but of course, don’t forget the monitoring component.
That’s crucial once you apply it in the field.

All right, if you’re interested in this topic and want to dive deeper,
our team has prepared a dedicated document:
NTLM Phase Out – Guiding Active Directory Environments.

You’ll find the link in the description, and I definitely encourage you to check it out.

Thank you so much for watching CQURE Hacks.
Hopefully, you enjoyed the content!

Don’t forget to subscribe to our channel and follow what we do on social media.

The post CQURE Hacks #68: NTLM Relay Attacks Explained and Why It’s Time to Phase Out NTLM appeared first on CQURE Academy.

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.

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.

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.

Minimizing who can access your data and when is one of the cornerstones of cybersecurity as it helps to decrease the chance of sensitive information falling into the hands of a malicious actor. It also protects data against being accidentally viewed (or even inadvertently leaked!) by an authorized user.

Because privileged user accounts hold higher levels of access than other user accounts, they need to be monitored more closely. PIM is a service in Azure Active Directory that allows you to restrict access in a variety of cool ways, from making it time-bound to implementing just-in-time access.

In her exploration of Privileged Identity Management in Azure Active Directory, Paula covers:

•     Assigning roles
•     Adding assignments
•     Giving global administrative rights to a user
•     Configuring limited time access that expires after a specified time
•     How to activate a role and monitor it using Assigned Admins

You’ll find more beginner-level episodes of CQ Hacks devoted to Azure Active Directory Security on the CQURE Academy blog.

 

Holiday time is approaching and we know that everyone loves to receive gifts! Especially at CQURE, the idea of sharing is close to us and we would like to invite you to our Great Racoon Giveaway Contest, where you will get a chance to win $3920-worth voucher for any of CQURE Academy Live Courses! 

Please click on the below banner to find out more about the contest:

The post Back to Basics: Using PIM in Azure Active Directory Security appeared first on CQURE Academy.

Identity Protection is a security feature in Azure Active Directory that helps to prevent, detect, and remediate identity risk in an organization. Using multiple detections, it monitors every login for identity compromise, sorting sign-ins into three categories of risk: low, medium, and high.

These risk ratings can be used to create automated user risk policies that balance employee productivity with corporate security. For example, multi-factor authentication can be set as a requirement for a sign-in that is high-risk.

Join Paula as she reviews the different policies in Azure’s Identity Protection (User Risk, Sign-in Risk, and MFA Registration) and explains how to:

•       Select which users you want to include in the policy
•       Exclude specific users (such as your ‘break-glass’ account so that you cannot be accidentally logged out of Azure Active Directory)
•       Specify risk levels as high, medium, or low in the User Risk section
•       Block access or allow access but require a password change in the Access section
•       Activate and enforce a policy that you have set up and configured

Paula shows how to monitor your organization for risky users and risky sign-ins in the Report section of Azure’s Identity Protection dashboard and takes you through how to delete the conditional access policies you create.

Discover what happens when a log-in to an organization’s Microsoft Office portal from a Tor browser is flagged as “something strange” by Azure AD’s Identity Protection. You’ll also learn how to mark identity as compromised if, for example, sign-ins have been made in two completely different locations using that identity.

Paula covers identity security from the perspectives of both the administrator and the user, giving a clear view of the steps an employee must take when their account has been identified as risky.

With this identity security lesson under your belt, you’ll be able to intelligently react to potentially dangerous situations.  Take a stroll around the CQURE Academy blog now for more Azure Active Directory security tips including ‘8 things to avoid’ in Azure AD.

Holiday time is approaching and we know that everyone loves to receive gifts! Especially at CQURE, the idea of sharing is close to us and we would like to invite you to our Great Racoon Giveaway Contest, where you will get a chance to win $3920-worth voucher for any of CQURE Academy Live Courses! 

Please click on the below banner to find out more about the contest:

The post Back to Basics: Identity protection in Azure Active Directory appeared first on CQURE Academy.

Regulating access to your company’s files, systems, and applications cuts the risk of your data falling into the hands of hackers, threat actors and thieves.

While standard privilege management stops at ID-based authentication, conditional access in Azure Active Directory gives greater flexibility and control by allowing remote connections only when certain conditions are met.

Using conditional access, an administrator can regulate access by user location, device type, the kind of application or file being used and more. To achieve this, the administrator creates an Azure Active Directory security policy that specifies which condition(s) must be met for access to be allowed.

In this back-to-basics CQURE Hacks episode, Paula J demonstrates how to create secure conditional access policies and monitor access in the Azure Active Directory.

>>> Controlling access by a user’s IP address

o   Add the IP range’s location

o   Define the range to be assigned to the policy

o   Name the policy e.g., ‘Corporate IP range’

o   Specify the trusted IP addresses related to the location

>>> Controlling access by the kind of user or group, e.g., corporate only

o   Create a new policy

o   In conditions, specify login from corporate IP addresses

o   Exclude sign-ins from other users and groups

>>> Controlling access by location

o   A demonstration using the United States and Poland as examples

>>> Creating emergency access accounts known as “break glass accounts” to prevent yourself being accidentally locked out of your Azure Active Directory

>>>   More ways to regulate access

o   Blocking access

o   Enforcing multifactor authentication

o   Session controls

>>> Final steps

o   Turning on policies

o   Testing polices

o   Monitoring user access via the dashboard

After you’ve set up conditional access in Azure Directory, browse our blog to discover more clever ways to secure your data.

 

 

The post Back to Basics: Conditional Access in Azure Active Directory appeared first on CQURE Academy.