Skip to main content

Testing the internal network

From the point of view of someone already inside: a standard account, a network socket, and the question of how far that carries.

Infrastruktur-Penetrationstest Rand, Server und Dienste, Verzeichnisdienst und die Segmentgrenze: was ein interner Test anfasst, und wo die Befunde typischerweise sitzen. ONE PORT OR ONE ACCOUNT EDGE FIREWALL VPN-GATEWAYNO MFA REMOTE MAINTENANCE SERVERS AND SERVICES WEBSERVER MAILSERVEROLD PATCH LEVEL DATABASE FILE SERVEROPEN SHARE HYPERVISOR WORKSTATIONS DIRECTORY SERVICE ACTIVE DIRECTORY · ENTRA IDGROUPS, RIGHTS, SERVICE ACCOUNT SEGMENT BOUNDARY PRODUCTION · CONTROL SYSTEM ? INTERNAL PENETRATION TEST
Trusted by
The opening question

Assume somebody is already on the network

An internal test begins where the outward defence has already been bypassed: through a phishing mail, a device in a meeting room, a service provider access. How they got in we set aside, because that question is tested elsewhere.

What gets tested is what is possible afterwards. With an ordinary user account, sometimes without one, with only a network socket.

What gets tested is the infrastructure: servers and services, the directory service and the transitions between networks. Web servers, mail servers, databases, file servers, VPN gateways, firewalls, virtualisation, Active Directory or Entra ID. The same test is called an infrastructure penetration test elsewhere; we name it after the point of attack, not after the object.

What belongs in it

Directory service, servers, segmentation

The directory service is the core but not the whole. The systems beside it often supply the first step.

Directory service

Active Directory or Entra ID: permissions, nested groups, service accounts with old passwords, delegations, and the question of which accounts lend themselves to attacks on Kerberos.

Servers and services

Web, mail, file and database servers, VPN gateways, management and backup systems. Patch state, configuration, and access that is reachable from the network without authentication.

Segmentation

What a workstation reaches, what a meeting room reaches, what the guest network reaches. And whether there is a boundary between office and production, or only a network plan asserting one.

A finding, as it looks

The share with the password on it

Interner Test: Kennwort im Wartungsskript Eine fuer alle lesbare Dateifreigabe enthaelt ein Wartungsskript mit einem Kennwort im Klartext, das auf drei weiteren Systemen gilt. \\fileserver\data EVERYONE · READ quotes/ templates/ it-scripts/ backup_nacht.ps1 backup_night.ps1 $u = "FIRMA\svc-backup"$p = "Winter2019!"net use \\nas01 /user:$u $p THE SAME PASSWORD ON THREE MORE nas01 sql02 hv-adm PASSWORD UNCHANGED ONE FINDING · SHARE, SCRIPT, PASSWORD

A file share that everyone on the network may read, because it was once meant for everyone. Inside it a folder of scripts from systems administration, and in one of them a password in the clear, so that the scheduled run goes through at night without asking.

The account belongs to no person but to a service, and because nobody knows where it is all entered, its password has not been changed for years. The same password sits on three further systems.

No step in that is an attack in the technical sense. It is a share, a script and a habit. Something like that gets found by going through the shares on the network; a scanner reports the share as a low-severity note and does not read what is inside it.

Why a tool does not do this

The route comes out of small things

The findings of an internal test rarely stand high on their own: a readable share, a password valid in two places, a group with a right that once made sense. No single point justifies the effort.

The route comes out of the order. The share gives the password, the password gives an account, the account gives a group, the group gives a right on the domain controller. Only at the end is there something a management board cares about.

No tool does that chaining. It rates every find on its own, and the connection between them is the part a person sits at the test for. So our report ends with a path and its intermediate steps, not with a list of servers and version numbers.

How it runs

How an internal test works

The effort follows the number of sites and the size of the domain. Testing follows the BSI practical guide for IS penetration tests, PTES and OSSTMM; every report goes through a second-pair-of-eyes review.

1

Fix scope and access

Which sites, which network areas, which time window. We settle whether testing happens with or without a user account, and who inside is reachable if something stands out.

2

Survey

Reachable systems and services, shares, network transitions. Plus the group, permission and trust structure of the directory service.

3

Testing

Patch state, configuration, passwords and permissions, system by system. Every finding is evidenced, not derived from a version number.

4

Chaining

What can be joined up: from the open file server to the password, from the password into the directory service, and the question of whether the segment boundary stops it.

5

Report and retest

Findings with reproduction steps and a risk rating, and on request the check that the fixes work.

What you receive

A report your team can work from.

Every finding comes placed: with risk, effort and the route to a fix.

Management summary

The position on one page, readable for management and the board.

Technical findings

Every finding with a unique finding ID, evidence and reproduction steps.

Risk rating to BSI

A traceable rating of every find against a recognised scheme.

Prioritised recommendations

Concrete recommendations in the order in which they take effect.

Closing meeting

On request, a joint walk-through of the results with your teams.

Retest

On request, a re-examination of the fixed weaknesses, with confirmation of the state.

The frame

What we need, and what is not included

From you we need a network socket in the area under test, on request an ordinary user account, a contact for the duration of the test and a written release. Nothing more: credentials with elevated rights are precisely what the test is meant to reach.

Not included are attacks on people and on availability. Social engineering and phishing simulations are services of their own with their own arrangements, we do not carry out denial of service tests, and production and control technology belongs in the OT penetration test, because different rules apply there. Anyone who wants weeks of testing on whether detection and response work is in the right place at red teaming.

Common questions

Common questions about the internal test

Both are common. Without an account we test how far someone gets with network access alone; with one, the far more common case after a phishing mail. The second usually yields more.

Not necessarily. We work through a device you put on your network, or through an access you provide. Being on site makes sense when the physical side is being tested at the same time.

They are not named in the clear in the report, only far enough for you to identify the account concerned. After the engagement the data is deleted, and that is in the contract.

Credentials

Certifications and memberships.

Certifications held in the team
Memberships
eco – Verband der Internetwirtschaft
networker NRW
Next step

Talk to us.

A first conversation usually takes 30 minutes. We look at where you stand and tell you frankly whether we are the right partner.

Telephone
0231 39814905
Mon–Fri · 9am–5pm CET
Email
info@yekta-it.de
PGP key available
Location
Dortmund
Ruhrallee 9 · 44139