A penetration test is scheduled work with a defined scope and a report at the end, and the substantial part of it takes days. What is more revealing, and considerably less discussed, is how much is usually found in the first hour, before anything difficult has been attempted at all.

The findings in that first hour are rarely sophisticated. They are the things that were configured once and never revisited, the exceptions that were granted for a good reason and never withdrawn, and the settings that arrived enabled by default and were never examined. They persist in businesses that are well run in every other respect, which is precisely why they are worth describing.

What follows are the patterns that recur most consistently. None of them are attributed to any client and none are exotic, and that is the point.

Before anything is touched: what the internet already says about you

The first phase of any assessment requires no interaction with the target at all. Staff names, roles and reporting lines are assembled from public professional profiles. The email address format is inferred from two or three examples and then applied to every name found, producing a list of likely valid addresses. Job advertisements are read carefully, because a posting seeking experience in a particular platform or version tells an attacker what is running inside the business more reliably than any scan.

Historical breach data is checked for corporate addresses, because credentials exposed in an unrelated breach elsewhere are frequently reused, and a password that leaked from a personal service three years ago is often still in use with a predictable modification. None of this is illegal, none of it is difficult, and all of it happens before the business has generated a single log entry.

The perimeter: services that should not be reachable

A scan of the external footprint routinely surfaces things that nobody currently at the business intended to expose. Remote desktop reachable directly from the internet, usually because it was opened during a period of remote working and never closed. Management interfaces for firewalls, network attached storage or virtualisation platforms answering on public addresses. Development or testing systems that were stood up temporarily and are now permanent, running software several versions behind and outside anybody’s patching process.

The recurring theme is that the exposure was created deliberately, by a competent person, for a legitimate reason, at a moment when it made sense. What never happened was the review that would have closed it once the reason expired, and nothing in the ordinary running of a business prompts that review.

Authentication: the gap between available and enforced

Multi factor authentication is now widely deployed, and the interesting question is no longer whether it exists but where it does not apply. The exceptions cluster in predictable places.

Service accounts, because applying it would have broken an integration. Shared mailboxes, because there is no individual to enrol. Legacy authentication protocols that remain enabled in the mail platform, allowing older clients to connect in ways that bypass the modern authentication path entirely. And a small number of senior individuals for whom an exception was granted on the grounds of inconvenience, which is a category worth naming plainly because those accounts usually hold the widest access in the business.

An attacker does not need to defeat multi factor authentication. They need to find the account it does not cover, and the exception list is usually short enough to work through methodically.

Credentials: attacking the login without attacking the account

Where a login portal is exposed, the productive approach is not to attempt many passwords against one account, which triggers lockouts and alerts, but to attempt one plausible password against every account. Seasonal and organisational patterns remain remarkably effective, and in a business of two hundred people it is rarely necessary to try more than a handful before something works.

What makes this worth describing is the detection question rather than the technique. A slow attempt spread across many accounts over several hours generates a pattern that is entirely visible in authentication logs and almost never noticed, because noticing it requires somebody to be watching those logs with an understanding of what the pattern looks like. Most businesses retain the logs and review none of them.

Inside the network: the position after a single foothold

Once any position inside the network is established, whether through a compromised account or a single workstation, the most common findings concern how far that position extends.

Local administrator credentials repeated across every workstation, so that access to one machine is functionally access to all of them. Service accounts with far more privilege than their function requires, often granted at installation and never reduced. Network shares readable by all staff containing payroll data, contracts or credentials in documents. Older name resolution protocols left enabled, which allow an attacker on the same network to intercept authentication attempts without exploiting anything.

The pattern across all of these is that internal controls receive a fraction of the attention paid to the perimeter, on an implicit assumption that anybody inside the network belongs there. That assumption has not been safe for a long time.

What the first hour actually tells you

The findings above are not evidence of negligence and they appear in businesses with genuine security investment. What they demonstrate is a different point, which is that security configuration decays in the same way that documentation does, because it is established at a moment in time and then subjected to years of reasonable exceptions, temporary measures and staff changes, with no mechanism that periodically asks whether each decision still holds.

This is also why a control being present is a weaker statement than it sounds. Every finding described here would sit inside an environment where the relevant policy exists and the relevant product is deployed. Multi factor authentication is implemented. Endpoint protection is installed. The firewall is configured. The gap is not in whether the controls exist. It is in the exceptions, the coverage and the absence of anybody looking.

The uncomfortable version of the question is this. Your controls satisfy a standard. Would they satisfy somebody who was actually trying?

Siyaxhuma delivers penetration testing and vulnerability assessment as part of a full managed security practice, which means findings are not handed over in a report and left with you, they are remediated and then verified. Get in touch to discuss an assessment.