People ask me what I see when I look at the data from our deep discovery. What patterns show up when you scan real infrastructure, across real organizations, day after day?

The answer is not what most people expect. It is not sophisticated zero-days or nation-state tradecraft. It is misconfiguration: overwhelmingly and consistently.

Systems deployed by people who understood what they needed to achieve but not fully what they were connecting to. APIs exposed because a default setting was never changed. Subdomains pointing at infrastructure that was forgotten three vendors ago. JavaScript files sitting publicly accessible, containing backend configuration details, across multiple audit cycles.

The door is open. Most of the time, nobody put it there deliberately. They just did not notice it was there.

The Curiosity Model of Hacking

Here is the shift I think about constantly. The hacker of today — and increasingly the hacker of tomorrow — does not need to be a technical expert in the traditional sense.

What they need is curiosity. The ability to understand how a system was built, how the Lego was put together, and then to ask: what happens if I do the reverse? What if I pull this piece out? What if I follow this connection somewhere it was not meant to go?

AI tools have made this dramatically more accessible. You can sit in a bedroom, describe what you are trying to understand, and get a working starting point. You do not need to write the code from scratch. You need to know what you are looking for and what to do when you find it.

Today's hacker and the hacker of tomorrow is going to be completely different. You don't need to know about code to understand how to hack things today. You could be sitting in your bedroom asking AI to build you a little tool, the moment you know where to go and what to look for.

The barrier to finding an open door is lower than it has ever been for an attacker. Once you find it, the barrier to walking through it is lower still.

What the ThingsRecon Data shows

When I look at what ThingsRecon finds in real infrastructure scans, the most common patterns are not what you would expect from a threat intelligence briefing.  

They are:

• APIs accessible without authentication because a development environment was promoted to production without a configuration review

• Third-party scripts serving code to production applications from domains that the security team has never seen

• Subdomains pointing to infrastructure that was retired, or to services that were acquired through vendor relationships nobody documented

• Cloud storage buckets exposed because the person who configured them understood the feature but not the permission model

• Certificates expired on systems that are still actively serving traffic, because nobody owns the renewal process

None of these require a sophisticated adversary to exploit. They require someone who knows how to look.

When Data Becomes a Weapon

In the latest episode of your All Things Cyber podcast, we discussed a recent case where 6.2 million consumer records were accessed through a misconfiguration. Not through a technical exploit, but through a social engineering attack that leveraged data the attacker had already found.

The chain worked like this: the misconfiguration exposed enough information to make a convincing call to a service desk. The service desk call got account access. The account access got everything else.

This is the thing about misconfiguration as an attack vector: it does not stay isolated. One exposed endpoint becomes the proof of identity for a social engineering attempt. One leaked configuration detail becomes the map for a lateral movement chain. The door is open in a way that points to other doors.

The Supply Chain Dimension

Every third-party integration in your environment is a potential misconfiguration waiting to be found by someone scanning your surface looking for it.

The scripts a vendor embeds in your application. The API endpoints their platform opens in your infrastructure. The subdomains that get created during integrations and never cleaned up when the vendor relationship changes. Each of these is a connection point that may have been correctly configured at the time and is now exposed by drift, by change, by the vendor's own infrastructure decisions.

You did not create the misconfiguration, yet you’re still responsible for the exposure.

The Discovery Argument

The only response to this pattern is visibility. Detection of exploitation is step three, but first you need to know what you have.

You cannot close a door you do not know is open. You cannot monitor a connection you did not know existed. You cannot govern a third-party integration that nobody mapped.

The tools available now make this possible in ways that were not practical five years ago. Discovery-led mapping of an organization's real digital surface (starting from external signals, not from a vendor list) is no longer a project that takes months. The question is whether it is being done, and whether it is being done continuously rather than once a year before an audit.

The barrier to attack is low and falling. The barrier to visibility is lower than most organizations realize. The gap between them is where most breaches happen.

‍

Stephane Konarkowski is CPO and Co-Founder of ThingsRecon, a supply chain intelligence platform that maps real digital connections between organisations and their suppliers. This post was adapted from Episode 5 of the All Things Cyber podcast.