Understanding command and control incidents in Microsoft Sentinel environments

​What is Command and Control (C2) in Cybersecurity?

In the realm of cybersecurity, Command and Control (C2) is a pivotal component of cybercriminal strategies. Imagine a high-tech command centre where malicious actors orchestrate their attacks. C2 servers, also known as C&C servers or C2 nodes, act as the nerve centre of malware operations. They send crucial commands to compromised devices within a target company's network while also receiving stolen data in return. This unholy alliance of communication enables cybercriminals to manipulate infected machines, making C2 a critical element in the world of digital threats.

Command and control (C2) incidents are among the clearest signs that an attacker has moved beyond “trying to get in” and is now actively operating within your environment. In practical terms, C2 is the mechanism an attacker uses to remotely direct a compromised device (or identity) to perform actions such as data exfiltration, lateral movement, malware updates, and even botnet-style coordination.

For Microsoft Sentinel users, the challenge is rarely a lack of alerts. It’s separating genuine C2 activity from noisy network behaviour quickly enough to limit damage—especially when your SOC is stretched, or when customers expect a consistent response across tenants.

This guide explains how C2 activity typically shows up in Sentinel environments and how KQL-free Sentinel triage can help security teams act faster without relying on scarce query-writing skills.

What a C2 incident looks like in a Sentinel environment

A C2 incident is not just “a bad IP address”. It’s a relationship: an internal host (or workload) establishes external communications that enable remote control.

In a Microsoft Sentinel setup, C2 signals can be surfaced across common data sources, including:

• Microsoft Defender for Endpoint (process, network connections, device timelines)
• Defender for Office 365 (phishing entry points, URL clicks, attachments)
• Defender for Identity (identity-based compromise and suspicious authentications)
• Firewall, proxy, DNS and web gateway logs (network and name resolution patterns)
• Cloud workload and SaaS logs (Azure activity, conditional access, application telemetry)

The key is correlating these signals so you can answer two questions quickly:

• Is this host being controlled (or attempting to be controlled) from outside?
• If yes, what is the attacker trying to do next?

How attackers establish command and control

Most C2 chains begin with an initial compromise and then transition into “keep access and take actions”.

Common initial access routes

Attackers often gain a foothold through:

• Phishing emails leading to credential theft or malware execution
• Malicious attachments (macro-enabled files, weaponised PDFs, archives)
• Exploitation of internet-facing services (unpatched apps, weak configurations)
• Compromised credentials used for remote access (VPN, RDP, cloud portals)

Once inside, the attacker’s priority is persistence and reliable communication. That’s where C2 comes in.

What C2 enables the attacker to do

C2 is typically used to:

• Issue commands (run tools, enumerate systems, dump credentials)
• Exfiltrate data in chunks to avoid detection
• Deploy additional payloads (ransomware, information stealers, backdoors)
• Spread laterally and establish multiple access paths.

This is why C2 incidents should be treated as urgent, even if no data loss is confirmed yet.

Key detection signs of C2 activity (beyond obvious IOCs)

Indicators of compromise (IOCs), such as known malicious domains and IPs, still matter, but modern C2 is designed to blend in. A good triage approach looks for behaviour and patterns.

Suspicious DNS behaviour

DNS is a favourite channel because it’s everywhere and often under-monitored.

Watch for:

• Repeated DNS queries for domains with no business purpose
• High volume of unique subdomains (possible domain generation algorithms)
• Unusual record types or suspiciously long TXT responses
• Patterns consistent with DNS tunnelling (encoding data inside DNS traffic)

Even when attackers rotate infrastructure quickly, DNS patterns can remain a reliable thread.

Unusual ports and unexpected protocols

Not all C2 is on port 443, but attackers know defenders often trust “common ports”.

Signals include:

• Outbound connections on ports rarely used in your environment
• HTTPS traffic that doesn’t behave like real browser/API sessions
• Long-lived connections from endpoints that normally have short bursts of traffic
• Protocol mismatches (for example, “HTTPS” connections that fail TLS norms)

Known malicious domains and fast-changing infrastructure

Many C2 setups now use:

• Short-lived domains (registered and burned quickly)
• Compromised legitimate sites acting as redirectors
• Cloud-hosted fronting or CDN-like behaviour to mask origins

This is where threat intelligence enrichment is useful—but only if it’s applied consistently and doesn’t overwhelm analysts with “interesting” but low-confidence matches.

Anomalous packet characteristics and beaconing patterns

C2 “beaconing” is the classic pattern: a compromised host checks in at regular intervals.

Common hints include:

• Very consistent periodic outbound traffic (e.g., every 60 seconds)
• Similar payload sizes repeated over time.
• Traffic at odd times for the device/user (overnight, weekends, unusual time zones)

Small details—when correlated—often reveal the control channel.

Irregular network traffic patterns that don’t match the asset

Context matters. A domain controller, a finance workstation, and a build server have different “normal” settings.

Be suspicious when:

• A user workstation begins behaving like a server (hosting or relaying)
• A server starts making outbound connections to unfamiliar geographies.
• A device suddenly starts communicating with many external destinations using similar patterns.

Why C2 triage can be slow in Microsoft Sentinel (and how to fix it)

Microsoft Sentinel is powerful, but triage often depends on:

• Having the right data connected and tuned
• Knowing which KQL queries to run for each hypothesis
• Having enough skilled analysts to investigate thoroughly and consistently

This becomes even harder for MSSPs and multi-tenant SOCs, where you need repeatable triage that doesn’t vary by who is on shift.

That’s why KQL-free Sentinel triage is becoming a practical requirement rather than a nice-to-have.

KQL-free Sentinel triage with Harvey AI: a practical workflow

KQL is valuable, but many teams don’t have enough time—or enough specialist talent—to rely on it for every incident. An AI-driven approach can standardise triage while still allowing analysts to retain control.

With Harvey AI, a conversational assistant designed for SOC workflows, teams can investigate C2-like incidents using guided steps rather than writing queries from scratch.

Confirm whether the incident resembles C2 behaviour.

AI-led triage can rapidly pull together key evidence across your connected sources, such as:

• Which host(s) are involved, and whether multiple assets show the same pattern
• Which domains/IPs are contacted and how frequently
• Whether the connection pattern matches beaconing or data transfer
• Whether any related identity events (impossible travel, risky sign-ins) appear nearby

The goal is to quickly separate “suspicious internet noise” from “likely active control”.

Identify probable initial compromise signals.

Once C2 is suspected, the next fastest win is finding entry point clues:

• Recent phishing activity tied to the affected user or device
• New processes, scheduled tasks, and suspicious persistence mechanisms
• Unusual PowerShell, script execution, or living-off-the-land tooling
• Freshly installed remote management tools that aren’t approved

A consistent, repeatable checklist here reduces the chance of missing the early breadcrumb that explains the whole incident.

Assess scope and containment priority.

C2 incidents are rarely isolated. A KQL-free approach should still support hard questions, fast:

• Is this one endpoint, or a pattern across a group?
• Is it a privileged identity, a server, or a high-value workstation?
• Is there any sign of lateral movement or credential access?
• Is there evidence of staging or exfiltration?

From there, containment becomes prioritised rather than reactive.

Decide on response actions with clear, auditable reasoning.

A good response is both fast and defensible. AI-supported triage helps teams document why a device was isolated, why an account was deactivated, or why a block was deployed—without producing pages of manual notes.

This is especially valuable for regulated sectors such as government and healthcare, where auditability and change control matter.

Proactive monitoring strategies for enterprises and MSSPs

C2 defence improves dramatically when you assume attackers will try to “look normal”.

A few high-impact strategies include:

• Baseline outbound traffic by device category (user endpoint vs server vs domain controller)
• Strengthen DNS visibility and alerting on tunnelling-like patterns.
• Harden egress controls (limit which systems can reach the internet and how)
• Enforce consistent enrichment (threat intel + asset criticality + identity risk)
• Automate triage so the first 15 minutes are always high-quality, regardless of shift.

The most resilient SOCs don’t just detect C2—they reduce the time an attacker can maintain control.

Where SecQube fits: faster C2 outcomes without increasing headcount

SecQube helps organisations simplify and accelerate Microsoft Sentinel operations with an AI-powered, cloud-native SOC platform. At the centre is Harvey AI, a conversational assistant built to support investigation, triage, and remediation—without forcing teams to rely on constant KQL work.

For SOC leaders, the outcome is straightforward:

• Faster, more consistent C2 triage
• Reduced dependency on specialist skill sets
• Stronger executive-level control and reporting
• A practical path to immediate operational ROI

If you’re exploring KQL-free Sentinel triage for enterprise SOC teams, MSPs, or MSSPs, the next step is simple: review SecQube’s approach and consider a proof of concept that demonstrates triage speed and consistency in your own environment.

Explore SecQube and Harvey AI