πŸ›‘ Pentestas β€Ί help

Network scan

Point Pentestas at a host, hostname, or CIDR range; it scans ports, fingerprints services, looks up known CVEs by version, and runs protocol-specific probes (SSH, TLS, RDP, SMB, FTP, DNS, SMTP, IMAP, POP3, LDAP, Kerberos, SNMP, and a dozen more).

When to use

  • Perimeter audit after a firewall change.
  • Quarterly compliance (PCI 11.2.x, SOC 2 CC6).
  • Merger / acquisition due-diligence across an unfamiliar asset list.
  • Post-incident "what else is exposed?" sweep.

Targets

Accepts:

  • Hostname β€” mail.example.com
  • IPv4 address β€” 203.0.113.5
  • IPv6 address β€” 2001:db8::1
  • CIDR β€” 203.0.113.0/24 (capped at /16 on Free/Pro; unlimited on Enterprise)
  • Named host list β€” upload a .txt with one target per line.

All targets must belong to a verified domain or an allowlisted IP range in your tenant. Scanning random IPs you don't own is a no-go.

What it does

Port scan

  • Common mode (default): ~70 frequently-abused ports (21, 22, 23, 25, 53, 80, 110, 111, 135, 139, 143, 389, 443, 445, 465, 587, 636, 993, 995, 1433, 1521, 3306, 3389, 5432, 5900, 5984, 6379, 8000, 8080, 8443, 9000, 9200, 11211, 27017, …).
  • Full mode: all 65,535 ports. Much slower; Enterprise only.

Service fingerprinting

For each open port, Pentestas:

  1. Grabs the banner (first 256 bytes of the TCP connection).
  2. Probes with protocol-specific handshakes (SSH-2.0 banner, TLS ClientHello, RDP negotiation).
  3. Matches against a fingerprint DB to identify the service + version.

CVE lookup

Once a service + version is identified, Pentestas queries:

  • NVD β€” the official CVE database.
  • Exploit-DB β€” ranked exploit candidates.
  • Vendor advisories β€” Microsoft, Cisco, Juniper, etc.

Findings get ranked by severity (CVSS), exploit availability (PoC / weaponised / in-the-wild), and match confidence (exact version match scores highest).

Protocol-specific checks

Protocol Checks
SSH Weak ciphers (RC4, 3DES, MD5-MAC), Terrapin (CVE-2023-48795), CBC-etm missing, SSHv1, allow-root login, weak host keys
TLS Weak protocols (SSLv2/3, TLS 1.0/1.1), weak ciphers (RC4, DES, EXPORT), BEAST / POODLE / CRIME / Logjam / ROBOT / Heartbleed / FREAK, cert expiry, chain issues, OCSP stapling
RDP NLA disabled, weak encryption, BlueKeep (CVE-2019-0708), DejaBlue (CVE-2019-1181-82)
SMB v1 enabled, EternalBlue (MS17-010), SMBGhost (CVE-2020-0796), signing not required, null sessions
FTP Anonymous, cleartext-only, allow-writable-root
DNS Zone transfer (AXFR) allowed, recursion allowed, version disclosure
SMTP Open relay, VRFY/EXPN allowed, STARTTLS weak
SNMP Default community strings (public, private), SNMPv1/v2c, sysinfo disclosure

Brute-force (optional)

When enabled, Pentestas runs a bounded credential-guessing pass against SSH, FTP, RDP, SMB, and common web login forms. Uses a curated ~1,000-entry list of default creds (admin:admin, root:toor, Cisco/Juniper defaults, database server defaults). Not enabled by default β€” requires Pro+ and a scope acknowledgement.

Starting a network scan

From the UI

New scan β†’ Network. Paste targets (one per line or CIDR notation). Toggle:

  • Full port scan (Enterprise)
  • Brute-force default creds (Pro+, requires confirmation)
  • Protocol-specific checks (on by default)

From an agent

For internal networks, trigger from a deployed agent:

bash
curl -X POST https://app.pentestas.com/api/agents/{agent_id}/server-scan \
  -H "X-API-Key: aa_..." \
  -H "Content-Type: application/json" \
  -d '{"targets":["10.0.0.0/24"]}'

The scan originates from the agent host (inside your LAN) so you can reach internal subnets that Pentestas' cloud infra can't.

See Agents overview.

Output

Findings distinguish:

  • Open port (INFO)
  • Service disclosure (INFO / LOW β€” depends on banner sensitivity)
  • Weak configuration (LOW β†’ MEDIUM)
  • Known CVE match (severity = CVE severity, bumped if an exploit exists)
  • Active compromise (CRITICAL β€” brute-forced creds, confirmed EternalBlue, etc.)

Pitfalls

  • Cloud ASNs will sometimes block even legitimate scans. If you're scanning AWS/GCP/Azure from outside, the cloud provider may drop probes; running from an agent inside the VPC is the fix.
  • CDN-fronted hosts β€” network scan against example.com hits the CDN, not your origin. Use the origin IP directly, or run from an agent inside the origin network.
  • SYN scans require root on the agent; the default full-TCP fallback is a bit slower but runs unprivileged.

See also