Internal Infrastructure Testing

As a CREST-accredited provider, we can deliver internal infrastructure tests to the highest standards. In addition to CREST we are certified by other bodies to deliver best-in-class cybersecurity services. These include CHECK and Cyber Essentials Plus.

To keep ahead of new knowledge and techniques, our team of security consultants propagates their skills across the wider team.

The internal network of a business is often key to their operations, containing critical systems, information and functionality. We therefore recommended that internal networks are subject to regular security testing to ensure all data and systems are adequately protected against intrusion by malicious attackers.

Areas of testing

All systems within the specific network ranges are tested from an unauthenticated and, if requested, authenticated, perspective. The following aspects will be examined:

• Complete inventory of networks, with a focus on identifying all live hosts
• Enumeration of services that are hosted on servers
• Discovery of vulnerable or out of date software

Testing scenarios

We offer three main scenarios for an internal infrastructure test:

Blackbox testing

The consultant will receive no assistance from the client beyond that which is required to connect to the network. This testing will emulate a malicious attacker who has gained access to the network but does not have additional access, such as valid user accounts. The consultants will attempt to exploit systems to gain further, more privileged access to the network.

Greybox testing

The consultant is given assistance in accessing the network and provided with additional information, such as a set of valid user credentials. This allows the consultant to simulate a malicious insider or an attacker who has successfully phished or otherwise gained legitimate credentials. 

Whitebox testing

The consultant is provided full access to all resources they require, including network diagrams, physical access, console access, user accounts, and administrator access.  

Reporting 

A report is written detailing the processes carried out and the issues found. Generally, this will contain a prioritised list of vulnerabilities discovered grouped by functional area. Remediation advice will be provided, both in terms of an immediate fix and any defence-in-depth measures that could be taken to mitigate risk. Attack-chains, alongside their impact, will be documented. Any higher-level findings that can be abstracted from the testing will be provided. Any architectural or design weaknesses will be highlighted so that these can be avoided in the future. Finally, an executive summary is produced to allow the most severe issues to be communicated quickly to stakeholders.

Common vulnerabilities can include:

• Outdated operating systems
• Default or weak credentials
• Vulnerable software due to being out of date or poorly configured
• Active Directory misconfigurations
• Weak or no encryption found on services
• Legacy or previously unknown hosts, protocols, or services presenting unnecessary risk

Example attacks from previous engagements

To illustrate a real-world attack, the following is an example of a domain compromise achieved by leveraging vulnerabilities found on a previous test:

The consultant was provided with access to a laptop that was connected to a corporate VLAN of a network. During initial enumeration, the consultant identified a file server. This server hosted an SMB share that did not require authentication for access. The share was found to contain backups of virtual machines hosted within multiple VLANs of the network. By extracting these backups, the consultant was able to access sensitive information stored within the machines, including extracting passwords from the Windows SYSTEM and SAM hives.

Using a pass-the-hash attack, the consultant was able to access the live servers and extract further information from the domain. This included access as an administrator to the backup server. By extracting the encrypted authentication material used by the backup server, along with its keys, the consultant was able to recover the plaintext password for the default domain administrator, allowing total domain compromise to be achieved. 

Additionally, spraying this password along with other hashes identified earlier allowed the consultant to gain access to other machines that were not joined to the Active Directory domain, indicating that password reuse was prevalent within the network. 

CHECK testing

In some cases, testing may need to be conducted under the NCSC CHECK scheme. When this occurs, certain requirements must be met: 

Testing led by a CHECK Team Leader – Infrastructure (CTL INF).

On large or complicated tests, the CTL may be supported by one or more CHECK Team Members (CTM)

It is important to consider whether testing will need to be conducted under the CHECK scheme If you are unsure to whether this applies to you, you can talk to one of our consultants, and they can give you proper guidance and determine if you require CHECK testing. 

Considerations for SECRET Networks 

Where testing will be conducted on a network rated for SECRET information, additional requirements must be met:

Two CTL INFs are required at all times.

No storage devices may leave the facility upon testing being completed, requiring the use of new drives.

All testing and reporting must be conducted on-site.