• Oxford: +44 (0)1865 877830 
  • Manchester: +44 (0)161 713 0176 
  • Edinburgh: +44 (0)131 541 0118 
  • New York: +1 646-781-7580 
  • Bucharest: +40 316 301 707 
  • Tokyo: +81 (3) 4588 8181 

Internal Penetration Test Case Study

You are here

This is a case study of an internal penetration test that Dionach performed at the head office of a medium-sized UK organisation. Some of the information has been changed or omitted to maintain confidentiality.


A Dionach senior technical consultant first met with the client to determine the purpose and scope of the test. The scope was agreed to be around 50 servers, with the purpose to identify as many vulnerabilities as possible. These were mostly Windows, with a number of Red Hat Linux servers. Technologies in use included Citrix, VMware, Exchange and SQL Server. There were a number of intranet applications based on both Java and .NET. Network devices and workstations were out of scope for this test. The Dionach penetration test team were provided with normal, unprivileged Windows domain accounts.

Dionach then proceeded with the different stages of the internal penetration test:

  • Information gathering
  • Scanning for services
  • Identifying vulnerabilities on external services and exploiting them
  • Producing a detailed report of issues and recommendations


Information Gathering

Prior to the onsite visit, Dionach will try and gather as much relevant information relating to the client. Many information resources are available to the potential intruder. Just connecting to the Internet demands an amount of information.

Internal networks generally allow DNS zone transfer. This was used to get information about hosts and IP addresses. This was also used to verify the scope. The Windows domain controller provided user accounts and groups. SQL Server discovery was also used to find local SQL Server instances, of which there were over 30. A number of other services such as Windows networking were also used to get information about hosts.

Scanning for Internal Services

The hosts in scope were then scanned for all TCP and UDP services, such as FTP, Mail, DNS, web, and Windows networking. The port scanning revealed widespread use of Arcserve for backup, VNC for remote connections to the servers, and SQL Server, as well as the expected Windows services.

Identifying And Exploiting Vulnerabilities

Vulnerability scans were run on each server. Each team member was allocated groups of services to manually check and scan with more specific tools if appropriate. The automated scans can reveal vulnerabilities, but a manual check usually reveals more information.

The manual tests revealed a number of interesting vulnerabilities:

  • Several SQL Server instances had weak administrator level passwords. In one case this allowed access to the VMware ESX server. This hosted the Windows domain controller and so gave full access to the domain.
  • A number of older Windows 2000 hosts had remotely exploitable operating system and backup software vulnerabilities.
  • Anonymous and low-privileged Windows network shares contained configuration files with database passwords, allowing privilege escalation and access to sensitive information.
  • Some Windows domain accounts had weak passwords, including some Domain Admin level accounts.
  • A number of hosts running JBoss had an unprotected JMX Console, which allowed control of the hosts through script in an uploaded WAR file.
  • Two intranet applications, developed by external commercial software companies, were found to be vulnerable to SQL injection and cross-site scripting. This allowed access to personal information given the purpose of one of the web applications.
  • The Citrix servers had a number of vulnerabilities due to their configurations and file permissions, which would allow a user in a remote office to access other users information and run any application.

A large number of lower risk issues were also identified.


These issues were compiled and put into the final report. The report noted the scope and the dates the test was carried out on. The issues were graded into the following risk levels: critical, high, medium, low and informational. These risk levels are based on impacts to confidentiality, integrity and availability and the likelihood of occurrence of the threats.

The executive summary concluded that the overall security represented critical risk in terms of what an anonymous or low-privileged user was able to do. The key critical issues were explained in a non-technical way. The number of issues identified at each risk level (critical, high, medium, low and informational) was presented graphically.

The number of issues identified at each risk level (critical, high, medium, low and informational) was presented graphically and key issues starting with the most critical were listed with recommendations given for resolution of each.

The technical part of the report followed the executive summary, which detailed:

  • Technical, in depth list of issues discovered and recommendations on reducing the risk. The issues were listed in order of descending risk.
  • Network scan results.
  • A custom appendix table with SQL Server instances and their vulnerabilities.
  • An issue resolution action plan.



Dionach then presented the report to the organisation face to face, which ensured that the organisation got the most value out of the report and a good understanding of the issues.