faq

Frequently asked questions.

  • Why are you scanning me?

    We are conducting Internet-scale network scanning to provide information for cyber defense purposes. We scan the full IPv4 address space and part of IPv6 address space just like Shodan, Censys, LeakIX or ShadowServer are doing. We are in no way targeting you specifically, you are just part of what is connected on the Internet.
  • What is your intent?

    We are in the Attack Surface Discovery (ASD) & Attack Surface Management (ASM) markets. Our intent is to allow our customers to have the most complete view possible on their Internet facing assets. Our purpose is to identify initial access vectors before bad guys so our customers can fix their vulnerabilities before it is too late.
  • How ethical are you at such activities?

    We know Internet scanning activities may not be very-well perceived. That's why we want to bring together all actors to create a set of rules, or commandments, to do such in the most ethical way possible. Find out more in our write-up Our 10 Commandments for Ethical Internet Scanning. You may also be interested by a keynote given by our CEO at CTI Summit 2022.
  • What is the list of your scanners IP addresses?

    Here is the complete list of our scanners network ranges:
    • 51.255.62.0/28, 188.165.87.96/28, 37.187.215.240/28, 178.32.170.16/28, 45.43.33.218/32, 139.99.9.160/32, 178.32.197.80/28, 15.204.52.61/32, 142.4.218.114/32, 79.137.65.46/32, 213.32.25.76/32, 213.32.39.32/28, 51.254.49.96/28, 139.99.68.96/32, 15.235.189.144/28, 146.59.184.0/28, 144.217.24.0/28, 192.99.175.176/28, 5.135.173.112/28, 51.161.50.176/28, 147.135.236.160/28, 167.114.24.176/28, 51.255.109.160/28, 2001:41d0:403:1f43::1000/124, 134.209.101.182/32, 23.239.29.109/32, 45.43.33.210/32, 91.134.185.80/28, 151.80.91.208/28
  • How can I opt-out?

    You can do so in different ways. You could send us an email at abuse[at]onyphe{dot}io giving us your list of network blocks to be excluded from scanning. You could also block all our probes at your network perimeter, here is the list of our scanning network ranges:
    • 51.255.62.0/28, 188.165.87.96/28, 37.187.215.240/28, 178.32.170.16/28, 45.43.33.218/32, 139.99.9.160/32, 178.32.197.80/28, 15.204.52.61/32, 142.4.218.114/32, 79.137.65.46/32, 213.32.25.76/32, 213.32.39.32/28, 51.254.49.96/28, 139.99.68.96/32, 15.235.189.144/28, 146.59.184.0/28, 144.217.24.0/28, 192.99.175.176/28, 5.135.173.112/28, 51.161.50.176/28, 147.135.236.160/28, 167.114.24.176/28, 51.255.109.160/28, 2001:41d0:403:1f43::1000/124, 134.209.101.182/32, 23.239.29.109/32, 45.43.33.210/32, 91.134.185.80/28, 151.80.91.208/28
  • What kind of probing are you actually doing?

    We first send RFC-compliant SYN packets to 200+ ports on the full IPv4 address space and part of IPv6 address space. Then, we send application-level requests against found open ports with RFC-compliant protocol requests to perform service identification. From raw responses, we enrich the data to identify software & hardware versions, when possible, along with device classification. Finally, for some critical vulnerabilities, the one exploited at scale by cyber-criminals to deploy ransomware, we try to identify them in a non-intrusive way only.
  • What do you mean by non-intrusive?

    We only perform vulnerability identification in a non-intrusive way. That means we only send RFC-compliant application requests. Furthermore, we don't take the risk to crash a service, thus we only identify vulnerabilities by means which are completely innocuous for targetted services. For instance, we never try to identify vulnerabilities caused by buffer overflows. Another rule is that we don't want to leave traces on targetted services. That means if identifying a vulnerability needs to create a user account or a file, we won't be able to identify it and we will simply not do it.

    So how do we identify vulnerabilities in a non-intrusive way? We usually start by using a public PoC and by removing its malicious payload or by finding a way to elicit a response from targetted service that can be used to state if the vulnerability exists or not. For instance, read the following write-up Zimbra CVE-2022-27925 detection to understand from a specific example.

    Finally, we never perform login brute-force attempts, that would be too intrusive and we refuse ourselves to do that.

  • Are the results of vulnerability identification public?

    Of course not. We only provide access to such kind of data to well-known, well-identified companies. Usually, such information is accessible to companies having their internal CERT working on ASD & ASM to prevent possible intrusions on their networks. We received many thanks from our customers because we identify really critical vulnerabilities before bad guys can exploit them. We monitor every accesses to our data to make sure results stay in good hands, helping cyber defense instead of giving data to commit cyber offense.
  • I think that can be useful to me. How do I book a demo?

    Sure, just drop us an email at contact[at]onyphe{dot}io