I Tried Detecting Ports Actually Reachable from the Internet with AWS Security Hub's New "Network Scanning" Feature
This page has been translated by machine translation. View original
Introduction
On July 9, 2026, the Network Scanning (network reachability scanning) feature was added to AWS Security Hub.
Until now, Security Hub performed control plane analysis, which analyzes settings such as security groups to determine whether a resource is "configured to be exposed to the internet." The newly added Network Scanning actually sends probes from the internet side and checks the responses from ports. For ports that respond with TLS, the handshake and certificate information are also obtained.
| Aspect | Conventional (control plane analysis) | New feature (Network Scanning) |
|---|---|---|
| Determination method | Statically analyzes rules such as security groups | Sends actual probes and checks responses (also performs a handshake for TLS responses) |
| Detection target | Ports configured to be open to the internet | Ports actually reachable from the internet |
| Evidence | Configuration values (SG rules, etc.) | Port responses, TLS certificate information, service detection |
| False positives | Can be detected if open by configuration, even if actually blocked by an OS-level firewall or a filter along the route | Detected when a response to the probe is confirmed at the time of the scan |
| Finding format | ASFF (get-findings) |
OCSF (get-findings-v2) |
In this article, we will check the steps to enable Network Scanning, the structure of the Finding (OCSF format), and the granularity of scan targets. The verification target is an EC2 instance exposing port 443 on a public IP.
Verification
Verification environment
- Region: ap-northeast-1
- EC2: t3.nano (Amazon Linux 2023)
- Elastic IP: xxx.xxx.xxx.xxx attached
- Security group: TCP 443 allowed from 0.0.0.0/0
- Nginx 1.30.2 + TLS 1.3 (ECDSA certificate issued via the ACME-compatible endpoint of AWS Certificate Manager)
- Security Hub: Essentials plan
For the certificate issuance steps, refer to the following article.
Enabling Network Scanning
Enable network reachability scanning from "Settings" > "General" in the Security Hub console.
After enabling, a Finding was generated within a few minutes in this verification.
Checking the Finding
On the "All findings" screen, filtering the type by "Network Scanning/Network Reachability" lets you see the Findings originating from Network Scanning.
A Finding for internet reachability of port 443 was generated for the EIP used in the verification.
The Finding includes the following information.
- Port scan result: 443/tcp is Open
- Service inference result: smb (described later)
- TLS evidence: TLSv1.3, issuer
CN=Amazon ECDSA 256 S07,O=Amazon,C=US, certificate expiration date - Resource:
AWS::EC2::EIP eipalloc-0xxxxxxxxxxxxxxxxxxxxx
Checking with the CLI
Network Scanning Findings cannot be retrieved with the conventional get-findings API (ASFF format). You need to use the new get-findings-v2 API (OCSF format).
aws securityhub get-findings-v2 --region ap-northeast-1 --max-results 5
Output of get-findings-v2 (excerpt)
{
"class_name": "Network Scan Finding",
"class_uid": 99802002,
"finding_info": {
"created_time_dt": "2026-07-09T16:08:14.293Z",
"desc": "Security Hub Network Scanning detected an open port reachable from the internet: xxx.xxx.xxx.xxx:443/tcp (smb) on AWS::EC2::EIP eipalloc-0xxxxxxxxxxxxxxxxxxxxx.",
"title": "xxx.xxx.xxx.xxx:443 is reachable from the internet (securityhub-network-scan-test)",
"types": [
"Network Scanning/Network Reachability"
],
"uid": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
},
"port_scan_result_list": [
{
"port_info": {
"port": 443,
"protocol_name": "tcp",
"protocol_num": 6
},
"status": "Open",
"svc_name": "smb",
"tls": {
"certificate": {
"expiration_time_dt": "2026-08-21T05:39:09.000Z",
"is_self_signed": false,
"issuer": "CN=Amazon ECDSA 256 S07,O=Amazon,C=US",
"serial_number": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
},
"handshake_dur": 8,
"version": "TLSv1.3"
}
}
],
"resources": [
{
"ip": "xxx.xxx.xxx.xxx",
"name": "securityhub-network-scan-test",
"type": "AWS::EC2::EIP",
"uid": "eipalloc-0xxxxxxxxxxxxxxxxxxxxx"
}
],
"severity": "Medium",
"severity_id": 3
}
In the OCSF-format Finding, the port scan results are structured in port_scan_result_list. A distinctive feature is that it even includes the TLS handshake duration (handshake_dur, in milliseconds) and certificate information.
Scan targets and detection unit
In this verification, the Finding's resource was generated per public IP address, not per EC2 instance. In addition to the target EIP, we also confirmed Findings for public endpoints related to an ELB in the same account.
Notes
- Finding format: Network Scanning Findings can be retrieved only with
get-findings-v2(OCSF format). They are not displayed with the conventionalget-findings(ASFF format). Be careful when referencing them via the CLI or API. - Scan frequency: According to the documentation, the first scan is run within up to 24 hours after enabling. When the creation of a new resource or a configuration change is detected, the scan may be prioritized.
- Exclusion method: According to the documentation, you can exclude a resource from scanning by attaching the
SecurityHubNetworkScanExclusiontag to the target resource. Follow the documentation for conditions such as the tag value (this article did not verify the exclusion behavior). - Cost: It is included in Security Hub's Findings billing. There is no additional charge for Network Scanning alone.
Summary
We enabled AWS Security Hub Network Scanning and confirmed that 443/tcp, reachable from the internet, was detected as a Finding.
Network Scanning does not rely only on configuration values such as security groups; it actually sends probes from the internet side and checks port responses. In this verification, in addition to the Open port, information such as the TLS version, certificate issuer, and expiration date was also included in the OCSF-format Finding.
When checking via the CLI or API, you need to use get-findings-v2 instead of the conventional get-findings. Also, since the service name inference result may not match the actual service, it seems best to treat it as a reference value.
Because you can check in Security Hub which ports are actually responding from the outside, I felt this feature is useful for understanding your external attack surface and discovering unintentionally exposed ports.
