Skip to content
RootCut
Portal
All services

Internal

Internal network and hosts

We test what an attacker could do once inside: from a single foothold on your network we look for weak services, missing patches, insecure Active Directory settings and paths to your most critical systems.

How we test

The internal penetration test assessed the security of the client's internal network from the perspective of an attacker who has gained a foothold inside it, such as a compromised workstation, a malicious insider or a device plugged into a network port. Testing was limited to the IP addresses, ranges, hostnames and domains listed under Scope & dates. Excluded entries were not tested.

The approach follows recognised industry practice, including the Penetration Testing Execution Standard (PTES) and NIST SP 800-115. Attack techniques are described with reference to MITRE ATT&CK where relevant. Automated tools were used for coverage; every reported finding was verified manually.

Phases

  • Discovery: host discovery and port scanning of the in-scope ranges to identify live hosts and exposed services.
  • Enumeration: identification of services, operating systems and versions; enumeration of network shares, directory services (such as Active Directory) and name resolution protocols, with and without credentials where provided.
  • Vulnerability analysis: checks for missing patches, insecure protocols and configurations (for example SMB signing, LLMNR/NBT-NS, unencrypted management protocols), weak or default credentials, excessive permissions and weak encryption.
  • Exploitation and lateral movement: controlled attempts to confirm vulnerabilities, gain access to systems, escalate privileges and move between systems, to show what an attacker could reach from the starting position.
  • Reporting: each confirmed issue is documented with its severity, affected assets, evidence and remediation advice. Where issues combine into an attack path, the path is described.

Limitations

  • The test is a point-in-time assessment. Changes made to the systems after the test dates are not covered.
  • Actions likely to affect availability (such as denial-of-service attacks or account lockout) were avoided unless agreed in advance.
  • Sensitive data accessed during the test was only used to prove impact and was not kept after the engagement.
  • The absence of a finding does not guarantee that a system is free of vulnerabilities.