How T1595 active scanning shows up before an intrusion starts
Scan traffic is constant at most internet-facing organizations, so the SOC lead's real question is which scans matter. Under the Reconnaissance tactic (TA0043), T1595 Active scanning describes an adversary probing your environment directly to learn what is reachable and exposed, so it can choose targets and plan later access. It is a planning step: the adversary is usually not inside yet, and the results decide where effort goes next. T1595 has three sub-techniques: scanning IP blocks to see which addresses respond, vulnerability scanning to check services for known weaknesses, and wordlist scanning to guess names of hosts, paths or files. A technique can sit under more than one tactic, so a mapping that lists T1595 once may matter to other phases as well.
This page targets MITRE ATT&CK Enterprise version 20.0. ATT&CK releases can rename, deprecate or revoke techniques, so confirm which version your SIEM rules and detection inventory were written against before comparing them with this page. The first decision is to define expected scan traffic. List the vulnerability scanners, asset discovery tools and external attack surface monitoring services your organization has authorized, with their source addresses and owners. Anything outside that baseline becomes a candidate for investigation, and the triage question is whether the source is a known scanning service, a partner, or an unidentified host. Agree that baseline with each scanner owner in advance so the SOC is not rebuilding it during every alert.
The second decision is coverage. Ask which of the three sub-techniques your current alerts can actually see. Confirm whether your sensors capture the network content for the services you expose, and whether web server or proxy logs reach the SIEM, because the ATT&CK data components Network Traffic Content (DC0085) and Network Traffic Flow (DC0078) are the ones most often referenced for Reconnaissance techniques. If you cannot answer these questions from a dashboard, that gap is the finding to bring to the next review. Record the answers with the owners of the sensors and log sources so the gap has a named owner and a date for closure.
Which telemetry reveals active scanning and which open-source tool collects it
This table maps the telemetry sources ATT&CK references for T1595 to the scanning signals a defender looks for and to open-source collectors that capture them. Read each row as a pairing of data component, observable pattern and collector, then confirm the mappings against the v20.0 STIX bundle before you build detections. The main takeaway is that network flow and content data carry most of the scanning signal, while application and response logs add context mainly for sub-techniques.
| Telemetry | Scanning signal to look for | Open-source collector | Confirm before use |
|---|---|---|---|
| Network Traffic Flow (DC0078) | Many destinations or ports contacted from one source in a short window, and high counts of failed or reset connections | Zeek connection logs, Suricata flow records, Security Onion dashboards | Mapping to T1595 sub-techniques in the v20.0 STIX bundle |
| Network Traffic Content (DC0085) | Banner grabs, malformed requests, protocol probes and content exchanges that do not match normal client behavior | Suricata signatures, Zeek protocol analyzers, Security Onion packet-based alerts | Which protocols your sensors decode and which content fields they retain |
| Application Log Content (DC0038) | Repeated requests for unusual paths, version strings or administrative endpoints from one client, often tied to vulnerability scanning | Wazuh log collection from web servers and application gateways, shipped to Security Onion | Whether the sub-techniques you care about are linked to this component in your target ATT&CK version |
| Response Content (DC0104) | Responses that reveal service banners, error pages or version details to a scanner, useful for measuring what an adversary learned | Zeek and Suricata content logs from externally facing services, reviewed in Security Onion | Whether this component is referenced for the sub-technique you are testing, since it is most useful as context |
| Source and asset context | Scans that touch hosts outside an approved inventory, or scans from addresses that are not your own monitoring or testing sources | Wazuh agent inventory and Security Onion asset data, correlated with Zeek and Suricata events | Accuracy of your asset inventory and whether external scanning sources are documented |
Detection logic for T1595 that SOC teams can tune
Active scanning produces traffic that looks like reconnaissance long before it looks like an intrusion, so the useful signals come from how one source touches many hosts and ports over time. The cards below describe four detection ideas, the thresholds to set against your own baseline, and the benign sources that will trigger them if they are not excluded.
Flow fan-out from a single source
Count distinct destination hosts contacted by one source address within a fixed window, using Network Traffic Flow records from your sensors or firewalls. Active scanning from an external or compromised internal host typically reaches far more destinations than normal client behavior, so a high distinct-destination count is the core signal for T1595 Active scanning. Tune the threshold per segment, since a jump server, DNS resolver or backup host may legitimately contact many hosts. Start by listing your known scanners and monitoring hosts so they are excluded by name, not by broad subnet.
Sequential and wide port spread
Track the number of distinct destination ports a source attempts against each target within a time window, and separately track how many targets share the same port. Sequential port walks against one host and the same port across many hosts are different patterns, and both should be alerted on with separate thresholds. Vulnerability scanners, asset discovery tools and uptime checks produce the same shape, so maintain an allowlist of their source addresses with an expiry date and review it at each scanner change. Sigma rules can express this logic as a count-by-source aggregation that you tune per data source.
Spikes in refused and reset connections
Scanning generates many connection attempts that receive resets, refusals or no response, so a rise in these outcomes for one source is a useful companion signal to flow fan-out. Measure the ratio of failed to completed sessions per source, not raw counts, because a busy but healthy service can produce many resets. Expect false positives from misconfigured clients, load balancer health probes, and cloud load balancers that reset idle connections. Compare against a baseline from the same hours and days over several weeks before you set an alert threshold.
Content signatures from Suricata or Zeek
Suricata rules and Zeek scripts can flag scanner fingerprints in packet payloads, banners and protocol handshakes, using Network Traffic Content for the inspected session. Content signatures are precise for known scanning tools but weak against custom or modified scanners, so treat them as confirmation rather than the sole detection. Most rule sets have fingerprints that also match legitimate security tooling, so pair each signature with the scanner allowlist and verify it in your own range before enabling it in blocking mode. Keep rule source, version and tuning changes in version control so each alert can be traced to the ruleset that produced it.
Scanner and monitoring allowlists
Each detection in this set depends on an accurate list of sanctioned sources that scan or probe your estate, including vulnerability scanners, external attack surface monitors, uptime checks and cloud health probes. Record the owner, source addresses, schedule and approval for each entry, and treat any traffic from an address outside the list during a scan window as an alert. Review the list when a vendor changes address ranges, and confirm with each provider how their probes originate. Without this control, analysts learn to dismiss scanner alerts, which removes the value of the other detections.
Separating internet background noise from targeted active scanning
Most external scanning of your public address space is constant, automated and low value, so the detection task for T1595 Active scanning is less about spotting that a scan happened and more about deciding which scans deserve attention. Start by baselining each exposed service on its own. For every internet-facing listener (VPN concentrator, web application, mail gateway, API gateway, remote administration endpoint), record the normal volume of connection attempts per source, the usual port and protocol mix, and the typical share of requests that end in errors or authentication failures over a period of several weeks. Confirm these baseline windows with your own traffic history, since the rhythm of background scanning differs between a public API and a branch VPN. Deviations from a per-service baseline are far more useful than raw counts from the perimeter as a whole.
Next, maintain an allowlist of authorized scanners, and make every entry traceable to a named owner. Typical entries include your own external vulnerability scanning provider, penetration testing firms during an agreed window, and uptime monitoring services. Each record should state the source addresses or ranges, the business owner, the contracted purpose, the start and end dates, and who approved it. Allowlisting should suppress alerts for those sources without suppressing their logs, so that a scanner whose ownership record has lapsed is noticed. Track sources that appear repeatedly across days rather than judging each scan in isolation, because a source that probes a different service each day for a week is a stronger signal than a single burst. Finally, correlate scan activity with what follows it: authentication failures against the same service, requests for paths or versions the source has just enumerated, or exploit-style payloads from the same address within a defined window. Treat a scan that is followed by any of these as a candidate for incident triage, and confirm the correlation window and thresholds in a pilot before relying on them.
How to validate that the T1595 detections fire
This sequence proves, in a private cyber range, that each T1595 Active Scanning detection raises the alert it was designed to raise, with the expected fields, within a measured time. It produces a documented record of expected versus observed alerts that the team can re-run after every tuning change.
Agree scope and rules of engagement
The detection owner, the range operator and the SOC lead agree in writing which networks, hosts and sensors are in scope, which sub-techniques will be exercised, who may start and stop activity, and how the range is isolated from production. The security lead signs off the plan before any traffic is generated. The step is complete when the signed plan names the target ATT&CK version, the sensors under test and the abort conditions.
Map expected alerts to each sub-technique
For each T1595 sub-technique (Scanning IP Blocks, Vulnerability Scanning and Wordlist Scanning), the team writes down the detection logic in plain words, the data component it depends on (Network Traffic Content or Network Traffic Flow), the rule or analytic that should fire, and the fields the alert must carry. This matrix is the expected-result baseline. It is complete when every sub-technique has one row with a named rule, a named data source and at least one expected field.
Define an authorized activity profile
The range team prepares a general activity profile that reflects the reconnaissance behaviors the detections target, such as broad address sweeps, service probing and repeated requests against web paths. The profile is described in the test plan only in general terms and is approved by the scope owner. It is complete when the profile is reviewed, bounded to range addresses and stored with the plan, so any engineer can explain what was generated and why.
Record start and end times for each run
Before each run, the operator logs the exact start time, the sub-technique under test, the sensor set and the rule version. When the activity stops, the end time is logged the same way. The times are recorded in UTC so that they line up with sensor and SIEM timestamps. The step is complete when each run has a labeled time window that the analyst can use to filter the evidence.
Confirm alerts and expected fields
The analyst searches the SIEM for alerts inside each run window and compares them with the expected matrix. For each sub-technique, they check that the alert fired, that it names the correct rule, and that the expected fields (source, destination, port or protocol, and observed count or timing where the rule uses them) are populated. Results are marked as expected, missing, partial or unexpected. The step is complete when every row in the matrix has a recorded result.
Measure time to alert in the SIEM
The analyst calculates the gap between the logged run start and the first matching alert in the SIEM, and records the sensor-to-SIEM ingestion delay separately so that tuning decisions can target the right stage. The team agrees in advance what delay is acceptable for the detection's purpose and confirms that figure with the SOC. The step is complete when each sub-technique has a recorded time to alert and the acceptance threshold is documented as agreed, not assumed.
Tune and re-run the detections
Where alerts were missing, partial or noisy, the detection owner changes the rule or its thresholds and records the change in version control. The same activity profile and run structure are then repeated against the new rule version. The team compares old and new results side by side so that improvements are measured and no previously passing sub-technique regresses. The step is complete when the second run's results are logged against the new rule version.
Retain the validation evidence
The team packages the plan, the expected matrix, run logs, SIEM query results, time-to-alert figures and tuning history into one dated record, referenced to the ATT&CK version used. This record supports internal review and any compliance readiness discussion, but it is not an audit report. The step is complete when the record is stored in the agreed evidence location and the SOC lead has acknowledged it.
Rehearsing T1595 detection and response in a private cyber range
This scenario uses a private range with deliberately exposed lab services (for example, a web application, a remote access gateway and a DNS resolver) and a passive or mirrored sensor tap on the segment that faces the scanning source. Because the traffic is the only activity on the range, the rehearsal isolates whether the sensors can see probing at all and whether the detection content fires on the right fields. Illustrative injects include a sweep of common ports across the lab address range, a slower scan spread over a longer window, and a scan that rotates source addresses. Ask the range provider to confirm which sensor placements are available before you fix the design.
- Sweep injects: Run a horizontal sweep across the address range and a vertical scan against one host, so the team can compare how each appears in flow records and in content-based alerts.
- Slow and distributed injects: Pace probes so they fall below simple rate thresholds, then check whether correlation over a longer window still surfaces them.
- Good detection: Flow telemetry shows many short connections from one source to many destinations, and content signatures or protocol parsers flag banner-grabbing or malformed requests on the exposed services.
- Good response: The analyst confirms the source, scopes the targeted hosts, checks whether any probe reached an application log, and opens a ticket with the sensor evidence attached.
- Evidence for review: Keep the packet captures or flow exports, the rule identifiers and versions used, the time each alert fired against the inject time, and any sensor gaps found.
Confirm that the chosen sensors actually retain payload content, since content-based detection fails silently when only headers are kept.
This scenario adds scanning to a range that also runs legitimate monitoring, such as an uptime checker, a vulnerability assessment appliance and an internal asset discovery job. The point is to test whether analysts can separate hostile reconnaissance from approved scanning without suppressing the signal. Illustrative injects include a hostile sweep that starts while the approved assessment is running, and a probe from an address that looks like a known scanner but is not on the approved list. Confirm with your own change records which scanners are sanctioned before the exercise so the answer key is accurate.
- Overlapping injects: Start an unapproved sweep during the approved assessment window so the two appear in the same flow data.
- Lookalike injects: Send probes from a source that resembles an approved scanner but is absent from the allowlist.
- Good detection: Analysts tie alerts to an allowlist of scanner sources, user agents or schedules, and the unapproved activity still raises an alert with its own record.
- Good response: The team validates the allowlist entry against the change record, escalates the unlisted source, and documents why the approved scan was or was not the cause.
- Evidence for review: Keep the allowlist version, the change tickets, the alert suppression rules and their owners, and any alerts that were closed as benign without a documented reason.
Review whether any suppression rule was broad enough to hide the hostile sweep, and record the change request that narrowed it.
This scenario treats active scanning as the first phase of a longer chain: a scan identifies a remote access service, then a login attempt follows against an account on that service. The rehearsal checks whether the team links the two phases across data sources, rather than treating the scan as an isolated low-severity event. Illustrative injects include a scan of an authentication portal followed by a burst of failed logins from the same source, and a later successful login that the analyst must trace back to the earlier probing. Ensure the range supplies authentication logs and network telemetry so the correlation is possible.
- Chained injects: Schedule a scan of a remote access endpoint, then a controlled login sequence from the same source within the agreed exercise window.
- Good detection: Flow records show the scan, authentication logs show the failures, and a correlation rule or analyst query links the two on source and time.
- Good response: The analyst blocks or restricts the source, forces a review of any account that reached a success state, and checks whether other exposed services were probed.
- Evidence for review: Keep the timeline linking the scan to the login events, the correlation logic and its version, the containment action with its timestamp, and the gaps in cross-source visibility.
Record which step the team would have caught first in production, since that reveals where investment in correlation is most likely to pay off.
What the SOC does when a T1595 alert fires
This sequence turns a scanning alert into a decision: whether the activity is authorized, whether anything was exposed, whether the scanner moved on to follow-on activity, and what the edge, asset owners and threat intelligence need to know. Each step closes with a recorded output so the case can be reviewed later.
Validate the alert and scope the source
The on-duty analyst confirms the alert is a genuine scanning pattern rather than a monitoring fault, then records the source addresses, destination ports, protocols, time window and target ranges. The analyst checks these fields against the network traffic flow and content telemetry feeding the detection, so the case shows what was observed and from where. The step closes when the case has a bounded source list and a time window that other steps can query.
Confirm the source is not an authorized scanner
The analyst compares the source addresses against the approved list of vulnerability scanners, penetration testing vendors, external attack surface monitoring services and internal assessment hosts. Scanning windows agreed with vendors or internal teams are checked against the change or assessment calendar. Confirm each authorization with the named owner, not only from a ticket that may be out of date. The step closes with a recorded decision: authorized, unknown or hostile.
Check which scanned services are exposed
For sources that are not authorized, the analyst determines which targeted addresses and ports actually respond and which services are reachable from the internet, using the asset inventory and external exposure data available to the team. Scanning that reached only closed or filtered ports carries a different risk from scanning that reached a management interface or an exposed application. The step closes with a list of exposed assets and services, each tagged with its business owner.
Pivot to authentication and application logs
The analyst searches authentication logs, web and API access logs, and VPN or remote access logs for the same source addresses during the scanning window and for a period afterward, looking for login attempts, unusual paths, error bursts or requests that follow a scan. The purpose is to find follow-on activity that suggests the scanner is moving from reconnaissance to exploitation. The step closes with either a clean result, recorded with the search terms used, or a list of events that move the case into incident handling.
Block or rate limit at the edge
For unauthorized sources that are hostile or disruptive, the network or security operations team applies a block, rate limit or temporary deny at the perimeter, such as firewall, load balancer, web application firewall or cloud network controls. Blocking is scoped to the confirmed sources and the affected services, and the change is logged with an owner and a review date. The step closes when the edge device or cloud control shows the rule in effect and a follow-up search confirms that traffic from those sources is dropped or limited.
Notify owners of exposed assets
The analyst sends each affected asset owner the scanned services, the observed source and time window, and the exposure finding, along with the actions already taken. Owners decide whether to restrict access, patch, retire the service or accept the risk, and record that decision in the case. The step closes when each owner has acknowledged the notice and the case lists their response or an open follow-up.
Update allowlists and detection exceptions
The team updates allowlists for sources that were confirmed as authorized scanners, and removes entries that can no longer be verified. Any exception added to a detection is written with its owner, reason and expiry review so it does not silently widen the blind spot. The step closes with a change record that shows the before and after state of each list and the approver for each change.
Feed confirmed sources into threat intelligence
Confirmed hostile source addresses and any indicators tied to the scanning tool are added to the threat intelligence platform with context, confidence and expiry, and are shared through the channels the organization already uses with peers or sector groups where appropriate. Sources are not shared as permanent blocks without review. The step closes when the indicator record exists, has an owner, and the case references it so future alerts can be matched back to this one.
Preventive controls mapped to ATT&CK mitigations for T1595
T1595 activity is largely outside your control at the moment it happens, so the preventive work focuses on what an adversary can learn and reach when they scan. The cards below connect the primary mitigation, Pre-compromise (M1056), with supporting mitigations that apply only where the mapping holds for your environment.
Reduce exposed attack surface
Pre-compromise (M1056) is the primary mitigation ATT&CK maps to this technique family, and for T1595 its practical meaning is shrinking what a scanner can find. Review every public address range, open port and service banner, and remove or restrict anything without a current business owner. Confirm the exact mapping against the v20.0 bundle before citing it in a control matrix, since mitigation links can change between releases.
Inventory internet-facing assets
You cannot limit what you have not listed. Maintain a continuously updated inventory of public IP ranges, domains, cloud endpoints and third-party hosted assets, and assign an owner to each. Compare this inventory against what external scans actually return, because gaps between the two show shadow infrastructure that defenders have not yet accounted for and that adversaries may already have mapped.
Tune software configuration
Software Configuration (M1054) applies where scanners fingerprint services through verbose banners, default pages or unnecessary protocol responses. Check whether your web servers, load balancers, VPN gateways and mail systems disclose version strings, and whether default error pages reveal framework details. Treat this as a hardening review to confirm with your platform owners, not a guaranteed block, because some fingerprinting cannot be fully suppressed.
Disable unused features and programs
Disable or Remove Feature or Program (M1042) can plausibly apply where scans reach administrative consoles, debug endpoints, legacy protocols or management interfaces that the business no longer uses. Remove them from the external footprint and from the internal network where practical. Ask your platform team to confirm which services are needed, because removing a dependency without validation can disrupt production.
Audit exposed configurations
Audit (M1047) plausibly applies as a recurring review of firewall rules, cloud security groups and DNS records against the asset inventory. Schedule these reviews, record who approved each exposed service, and retain the results as evidence. Auditing does not stop a scan, but it shortens the time between an unintended exposure appearing and someone removing it.
Guide developers on exposed applications
Application Developer Guidance (M1013) plausibly applies where web applications expose verbose errors, debug routes, or API documentation to the internet. Give development teams a short checklist covering error handling, default paths and version disclosure, and confirm that it is part of release review. Whether this mitigation maps to T1595 in the v20.0 bundle should be verified before you rely on it in audit documentation.
Keeping T1595 detections current across ATT&CK releases
Every T1595 detection rule should name the ATT&CK version it targets. Active Scanning and its sub-techniques (T1595.001, T1595.002 and T1595.003) are mapped in the ATT&CK knowledge base, and those mappings change between releases. ATT&CK v18, released October 28, 2025, replaced the detections in technique pages with detection strategies (DET IDs) and analytics, made major updates to data components (DC IDs) and deprecated some data sources. v19 followed on April 28, 2026, and v20 on October 13, 2026. A Wazuh rule, a Sigma rule or a Security Onion correlation that cites T1595 without a version tag cannot be checked later against the release it was written for. Record the version in the rule metadata, in the detection-coverage spreadsheet and in the change ticket that introduced it. Confirm with your own tooling team which version your current content uses before you start the review cycle.
Review the T1595 mappings after every release, and treat data component changes as the highest-risk item. The data components most often referenced by ATT&CK detection strategies for Reconnaissance techniques are Network Traffic Content (DC0085), Network Traffic Flow (DC0078), Application Log Content (DC0038) and Response Content (DC0104). If a data component is renamed, split or deprecated, a detection that depends on it may silently stop firing. Compare the new version's detection strategies for T1595 against your rules, confirm that the sensors feeding Zeek, Suricata or your web server logs still produce the fields the rule uses, and rerun a replay of recent scan traffic before you accept the change. Ask whether your assessor expects this review to be recorded as evidence.
Track renames, deprecations and revocations on the MITRE updates pages. Each release note on the MITRE ATT&CK updates page lists changes that can affect T1595 coverage, and the STIX bundle for each version shows revoked or deprecated objects. Assign one owner to read the release notes within a fixed window after each release and to log what changed for T1595 and its sub-techniques. The output should be a short list of rules to edit, retire or keep, with the reason stated. This habit matters most for compliance readiness, because an auditor asking how a detection was kept accurate will expect a dated record, not an assurance that it was reviewed.
Common questions from SOC leads about T1595 detection
How do we stop internet scanning from flooding the SOC with alerts?
Do not alert on every inbound probe that reaches the perimeter, because internet-facing hosts receive constant background scanning from unrelated parties. Instead, alert on scanning that targets your assets in ways that matter, such as a single source touching many ports or hosts within a short window, or scanning that reaches systems that should never be contacted from outside. Tune thresholds against a baseline of at least several weeks of your own perimeter flow data, and route the low-severity background noise to a dashboard or periodic review rather than to the on-call queue. Review which rules fire most often each month and retire or re-scope the ones that never lead to action.
Is network flow data alone enough to detect active scanning?
Flow data is enough to detect many reconnaissance patterns, but it is not enough to explain what the scanner was looking for. Network Traffic Flow (DC0078) shows who connected to what, on which port and when, which is the core signal for spotting horizontal sweeps and port scans. Network Traffic Content (DC0085) adds payload and protocol detail, which helps you separate a vulnerability probe from a harmless banner grab and is useful for triage. Most teams start with flow records from their perimeter firewalls and cloud network logs, then add content inspection from Suricata or Zeek on the segments where content matters most.
How should we handle authorized scanners such as our own vulnerability tools?
Authorized scanners should be recognized and labeled, not silently excluded. Maintain a documented list of scanner source addresses, the owning team, the approved testing window and the ticket or change record that authorized them. Tag matching events at ingestion so dashboards and alerts can separate expected scanning from unexplained scanning, and alert when an allowlisted source scans outside its approved window or reaches hosts outside its declared scope. Review the list whenever scanning vendors change IP ranges, because stale allowlists are a common way real reconnaissance goes unnoticed.
How can we test T1595 detections without disrupting production?
Run detection tests in a private cyber range that mirrors your perimeter logging path, not against production systems. Use authorized scanning from a source you control, record the exact scan profile, and confirm that the expected events appear in your SIEM with the right fields, timestamps and source attribution. Keep the range isolated from production networks, and agree the test plan and rollback steps in writing before any traffic is generated. Repeat the same test after each change to firewall rules, log forwarding or detection content so regressions are caught early.
How do we map our T1595 findings to ATT&CK v20.0?
Map each detection to the technique or sub-technique ID it targets, and record the ATT&CK version alongside the mapping. Technique IDs use the form T####, with sub-techniques adding a three-digit suffix, and a technique can appear under more than one tactic. Because ATT&CK releases can rename, deprecate or revoke techniques, check each mapping against the enterprise-attack STIX bundle for v20.0 before you publish coverage reports, and re-check it after each release. Note which data components each detection depends on, since ATT&CK v18 replaced detections with detection strategies and reorganized its data components.
Who should own T1595 detection: the SOC, the network team or the platform team?
Ownership works best when one team owns the detection logic and another owns the telemetry it depends on. The SOC typically owns rule content, thresholds and triage, while network or platform engineering owns firewall, flow and sensor configuration that makes the data exist. Agree the split in a written runbook that names an owner for each data source, the escalation path when a log feed breaks, and the review cadence. Without that agreement, perimeter logging often fails silently after a firewall migration and nobody notices until the next exercise.
How DeployOpen builds T1595 detections and range exercises
DeployOpen approaches T1595 Active scanning as a fixed-scope engagement inside the client's own environment, starting with the sensors and logs that can actually see outside-in probing. The work ends with detections, validation evidence and range exercises the client's own team can repeat.
How we scope
- Confirm which edge systems, networks and cloud ranges are in scope for scanning detection
- Inventory existing Network Traffic Content and Network Traffic Flow sources before writing any rules
- Agree in writing which ATT&CK version and sub-techniques the detection mapping will target
How we build
- Configure open-source sensors such as Zeek, Suricata or Security Onion to record scanning-relevant traffic
- Write detection logic in Sigma and map it to Wazuh or the client's SIEM for alerting
- Tune thresholds against the client's baseline of legitimate scanners, vulnerability tools and monitoring
How we hand over
- Deliver a written detection record listing data sources, logic, known gaps and false-positive handling
- Provide validation results from a private cyber range showing which scanning patterns were caught
- Document response steps for the client's analysts, including triage, blocking options and escalation
How we support
- Offer ongoing support and continuous testing as a retainer after the fixed-scope work closes
- Re-validate T1595 detections when ATT&CK releases rename, deprecate or revoke related techniques
- Review new sensor, cloud or edge changes that could alter what scanning traffic is visible
