Someone from 22 Security scanned you

Confirming it was us

Source addresses

Forward and reverse DNS agree on all three:

dig +short -x 100.62.233.236                 # lagavulin.22security-scanner.com
dig +short lagavulin.22security-scanner.com  # 100.62.233.236

dig +short -x 52.2.108.65                    # talisker.22security-scanner.com
dig +short talisker.22security-scanner.com   # 52.2.108.65

dig +short -x 52.21.196.250                  # oban.22security-scanner.com
dig +short oban.22security-scanner.com       # 52.21.196.250

The requests carry a User-Agent that says the same thing:

Mozilla/5.0 (compatible; 22security-scanner/1.0; +https://22security.com/scanning)

A mail server sees 52.21.196.250 introduce itself as oban.22security-scanner.com, with verify@22security-scanner.com as the sender.

Traffic that claims to be us and fails those checks is not us, and we would like to hear about it.

Web checks

Headers, certificates, and server versions

For the hostnames under your domain that resolve, we request the homepage the same way a browser would and read what the server sends back. This is the bulk of the traffic you will see from us.

• What we read. The response headers, including the security headers a browser is told to honor, the server and platform version strings the server volunteers about itself, the TLS certificate and the protocol versions the listener accepts, and whether a content-management login is exposed to the internet. Where a version is disclosed we compare it against the vendor's own support lifecycle.
• One page, plus a few well-known paths. We fetch the homepage and a small number of standard, documented paths. We do not crawl, we do not follow links into the site, we do not submit forms, and we do not send anything a browser would not send on its first request. Every request carries the User-Agent above.
• Where it comes from. The automated pass originates from lagavulin.22security-scanner.com (100.62.233.236). When we validate a result by hand before contacting anyone, that comes from talisker.22security-scanner.com (52.2.108.65).

Service reachability

SSH, FTP, and other service ports

Alongside the web-layer checks above, we also check whether a small, fixed set of well-known service ports, like port 22 (SSH), port 21 (FTP), and port 990 (FTPS), are reachable from the open internet.

For each host and port we open one TCP connection to read the identification banner that the service sends on connect.

• Named ports, never a scan. We connect only to the specific service ports listed above, one connection each. We do not enumerate what else may be listening.
• We do not authenticate and we do not send credentials. We stop at the point where a credential would be the next thing on the wire. These services announce themselves the moment a connection opens: an SSH server sends its identification string (e.g. SSH-2.0-OpenSSH_8.9p1) before key exchange, and an FTP server sends its 220 greeting before any login. We read that line, understand what protocols and algorithms are used, and then disconnect.
• We identify ourselves where the protocol allows it. On SSH for example, our client announces itself as SSH-2.0-22security_scanner_1.0 +https://22security.com/scanning, so this page shows up in your logs. FTP has no client-identification banner, so there we send nothing at all. The connection simply originates from the address below.
• Why. A remote-access service like SSH that is open to the entire internet is an exposure normally kept behind a VPN or restricted to known source addresses. We note it the same way we note any other misconfiguration and do not test it for weaknesses.

This is the current set; if we add another well-known service port, it will be listed here. These checks originate from talisker.22security-scanner.com (52.2.108.65). Port 25 is used only by the email address checks below.

Mail authentication

SPF, DMARC, DKIM, and mail transport

We read the public DNS records that tell the world's mail servers who is allowed to send email as your domain, and whether mail to it travels encrypted. A domain that gets this wrong can be impersonated in phishing aimed at its own customers, and these records are published precisely so that they can be read.

• What we read. SPF, DMARC, and DKIM records, the MX records and whether they resolve, whether the zone is DNSSEC-signed, and the MTA-STS, TLS-RPT, and BIMI records if they exist. We check that each is present, well formed, and consistent with the others. The lookups go through the public resolvers run by Google and Cloudflare, so your nameservers see those resolvers rather than our addresses.
• The one direct request these checks make. If your domain publishes an MTA-STS record, we fetch the policy file it advertises with a single HTTPS GET to https://mta-sts.<domain>/.well-known/mta-sts.txt, carrying the User-Agent above and originating from lagavulin.22security-scanner.com (100.62.233.236). The email address checks below are separate, and come from a different address.

Email address checks

Confirming an address before we write to it

Before we email someone, we check that the address exists. We connect to the mail server your MX record names, on port 25, and ask whether it would accept mail for the address, the same way any mail server starts a delivery. We disconnect before a message would be sent.

In your mail server's log it looks like this:

EHLO oban.22security-scanner.com
MAIL FROM:<verify@22security-scanner.com>
RCPT TO:<the address we are about to write to>
RCPT TO:<24 letters and digits>@<your domain>
QUIT

• No message is ever sent. The checker has no DATA command, so nothing can be delivered. Every session ends with QUIT.
• The second address is made up. It tells a server that accepts every address apart from one that knows its mailboxes. It is the same made-up address every time we check your domain.
• One at a time. One address at a time, fewer than 200 a day, and only for people we are about to contact.
• Where it comes from. Every check originates from oban.22security-scanner.com (52.21.196.250). The sender address exists so your server can verify it, and nobody reads it; write to abuse@22security.com instead.

How we conduct ourselves

Deliberately conservative compared to the industry

• Minimum necessary. Every check on this page was designed to be more conservative than the routine internet-wide measurement you already receive from services like Censys, Shodan, or academic research institutions. Except instead of publicly releasing specific results like Shodan, we disclose them directly to you, along with the potential security and compliance implications of what we found and actionable recommendations.
• So much depends on reputation. We proactively monitor all three source addresses on AbuseIPDB and other threat-intelligence and reputation services. We are fully transparent with these services about our processes and care deeply about being good security practitioners.
• Results stay with us. What we observe about your specific infrastructure is shared only with you and never sold to third-party services.

Opting out

If you would rather not be included, email abuse@22security.com and we will remove your company from our scanning list and confirm the change within 2 business days. The removal covers every hostname under your domain and both scanning addresses, lagavulin and talisker.