Penetration Testing Methodology, Traceability, and the Boundaries of Authorization

Disclaimer: This article is a personal technical study note. Any operations described should only be performed in authorized environments. Users bear full responsibility for any misuse.

Abstract: This document reviews an authorized penetration test as a methodology rather than as a sequence of exploits. It covers scoping and authorization, information gathering, vulnerability verification, privilege analysis, lateral movement, and — in more detail — the log sources that make an intrusion traceable afterwards. Attack techniques are discussed at the level of principle and of their defensive consequences; concrete payloads, exploitation command lines and anti-forensic procedures are deliberately omitted. The material is intended as teaching reference for security coursework and for engineers who need to understand what an assessment looks like from the inside.

Keywords: Network security, penetration testing methodology, log analysis and traceability, authorization and scope, least privilege, web security

Introduction

In recent years, with the continuous evolution and advancement of the Internet, cybersecurity has become an issue of common concern to the international community. At present, public awareness of cybersecurity remains relatively low, and many people are unfamiliar with protective measures. As a result, they are easily deceived, may inadvertently download malicious software, and engage in actions that not only endanger themselves but also others. Therefore, through a series of penetration testing experiments, this study aims to highlight the importance of cybersecurity in everyday life.

The experiments described below were carried out in a self-built laboratory. The emphasis is placed on two questions that are more useful than any individual exploit: how a real assessment is structured, and what evidence an assessment leaves behind when it is examined from the defender’s side.

Main Text

The Concept of Penetration Testing

Generally, penetration testing refers to the process of applying one’s penetration-testing knowledge to progressively infiltrate a target website or system, identify vulnerabilities and risks, and produce a test report. It is an authorized activity: the tester operates inside a written scope, and the value of the exercise lies in the report rather than in the access obtained.

Depending on the specific goals of a penetration test, and on what level of information or access the target system grants the tester, the tester will choose and stick to one of the following approaches:

• White-box testing: The tester has access to the system and its files, source code, binaries, Docker containers, and even servers used to run the system remotely.
• Black-box testing: The tester has no knowledge of the internal structure; in this scenario the tester typically acts like an attacker, probing for weaknesses that can be exploited from the outside.
• Grey-box testing: The tester has partial knowledge—one or more sets of credentials or some understanding of the target’s internal structure, algorithms, and code. The tester can also build testable vulnerabilities or examples based on design documents (topology diagrams, architecture diagrams).

Scoping and Authorization

Before any technical work, the engagement must be defined in writing. The following points determine whether the activity is a legitimate assessment or an incident:

• Scope of assets. The exact hostnames, address ranges, applications and interfaces that may be tested, and an equally explicit list of what is excluded.
• Window and intensity. The permitted testing hours and the boundaries on activities that carry availability risk, such as traffic flooding, brute force or resource exhaustion. Destructive tests on production systems require separate, specific consent.
• Rules of engagement. What the tester may do on discovery of a critical issue in progress, who is the emergency contact, and the procedure to stop immediately on request.
• Data handling. How credentials, personal data and business records encountered during the test are stored, transmitted and destroyed, and the obligation to report a breach of the client’s data rather than to retain it.
• Reporting. Deliverables, severity criteria, and a remediation timeline. Findings must be reproducible from the report, which is another reason to keep exploitation evidence inside the report rather than in public write-ups.

The distinction between an assessment and an intrusion does not lie in the techniques used — they overlap almost completely — but in consent, scope and documentation.

Environment Topology and Status Description

The environment topology is as follows:

Here, penetration testing will be conducted over the public internet. The objective is to infiltrate the target’s internal network, obtain important information files, and document how far an adversary could move inside the target’s LAN — the purpose of doing so being to quantify exposure, not to retain access.

• The XX campus network hosts two web services and is protected by a web application firewall:
  • Campus website
  • Student information management system
• The XX enterprise network does not host web services and is not connected to the public internet.

At the start only the domain name of the XX campus network is known; no other information is available and must be gathered independently.

Information Gathering Phase

In penetration testing, getting started is often the hardest part. To gain access to a system, the early information-gathering phase is usually the most important. From the defensive side, the same activity describes the organization’s external exposure: everything the tester can enumerate is, by definition, visible to any adversary.

During initial scanning it is necessary to collect as much data as possible. For web targets you can collect items such as subdomains, C-class network ranges (C-blocks), CMS fingerprinting, WHOIS records, and sensitive directory listings. On the system side the range of collectible information is even broader — any vulnerability that an operating system exposes to the Internet can be fatal. The usual culprit is open system ports: system ports are like doors for attackers. Adversaries will try every method to break those doors open, and once opened they can easily gain entry.

When the target website provides only a domain name, the test is typically carried out as a black-box engagement because we do not know the internal logic of the system. One important early check is to determine whether the domain is using a CDN (Content Delivery Network). Some CDNs act as content caches to accelerate site access, while others also provide WAF (web application firewall) services and can absorb thousands or millions of DDoS flood attacks. When a CDN is in use, the real server IP is often hidden.

Common CDN detection methods include using the ping command. From the figure below we can tell that the target administration site is not using a CDN. Domains that do use a CDN often have DNS records of type CNAME; in such cases the visible IP will be that of the CDN provider rather than the origin server.

Hiding the origin behind a CDN is a partial control only, and one that should not be relied upon as the sole protection: an origin address that has ever been published — in historical DNS records, certificates, mail headers or scan data — remains discoverable long afterwards, and it is usually reachable directly, without passing through the CDN protection.

Once the site’s IP is known, scanning can begin. Using Nmap to scan the target revealed the host is running Windows Server 2008 R2 and has ports 80, 445, and 8080 open. In addition, Nmap detected that the operating system is potentially vulnerable to MS10-054, MS10-061, MS17-101, and CVE-2009-3103.

It was discovered that the target site has a directory traversal vulnerability; by accessing these files one can directly download the source code. In penetration testing this is often catastrophic: attackers can audit the code to analyze the application’s logic and identify dangerous functions in use. Once an exploitable statement or logic flaw is discovered, the system can be compromised. The defender’s counterpart is straightforward: source code, backup archives, configuration files and version-control metadata must not be reachable over HTTP, and the web server should be deployed from a build artifact that contains no such files.

The image above shows a vulnerable dynamic page; this will serve as an entry point for further examination of the internal network. Accessing port 8080 revealed that a web service is running on the system.

By sending a malformed request that the application does not handle, the framework and its version can be identified from the error output. In this case the response disclosed that the target is using the ThinkPHP framework, version V5.0.0.

Detailed error output is convenient in development and costly in production: framework banners, stack traces and path information shorten the reconnaissance phase for an adversary. Applications should return a generic error page to unauthenticated clients and log the detail server-side instead.

Vulnerability Verification Phase

In web security, attack types include SQL injection, XSS, CSRF, SSRF, SSTI (server-side template injection), command execution, and others. The most basic yet highly destructive class is SQL injection, which is used here to illustrate how a finding is verified and what evidence it leaves in the logs.

• Causes of SQL Injection Vulnerabilities

The essence of SQL injection is that malicious code is disguised as normal input data and concatenated with legitimate commands, forming executable statements that are submitted to the server’s database. These vulnerabilities primarily arise from developers’ insufficient knowledge of web security or lack of secure coding experience, resulting in incomplete or unsafe code.

• SQL Injection Testing

To verify SQL injection, the first step is to determine whether the target is vulnerable. Basic test conditions such as AND 1=1 and AND 1=2 represent true and false predicates: when the condition is true, the correct page is returned; when false, the page may appear blank or differ in some other observable way. Once the behaviour difference is confirmed, further information can be retrieved by identifying the number of columns in the query and by combining results from additional SELECT statements. Each of these steps leaves a distinctive request pattern in the web server log — repeated structurally similar queries with tautological conditions, UNION-shaped keywords, and comment markers — which is the basis for the detection rules described later.

During injection attempts, it is common to encounter a WAF. WAF, short for Web Application Firewall, is essentially a security system that protects web applications. When a request is blocked by the WAF, it typically returns a response containing the following data.

Common WAFs include D-Shield, Qi-anxin Defense System, WangFang110 Defense System, SafeDog, and others. Depending on the interception or error messages, the bypass methods vary widely. Below is an example of a WAF used by the target website.

In this engagement the WAF blocked the straightforward form of the request, but not its semantically equivalent variants: changing letter case and repeating keyword characters was enough to avoid the signature while the database still parsed the statement as intended. The lesson is not that a particular product is weak but that pattern matching on request text is a single layer: it recognises strings, whereas the database recognises a grammar. Anything that survives the difference between the two — case, redundant characters, alternative encodings, comments — defeats the signature while remaining valid SQL.

The response disclosed the database name used by the site.

By chaining queries, the schema and then the contents of application tables can be read.

The data obtained included the usernames and passwords of the website’s administrative accounts. Two design flaws are visible at this point, and both are common in real deployments:

• Credentials stored in plaintext. Passwords were kept unencrypted, so the disclosure of a single table was equivalent to the disclosure of every account. Password storage should use a slow, salted hash function, and hashes should never be reversible.
• Excessive privilege of the database account. The application’s database account could read tables it had no legitimate need for. Restricting it to the objects the application actually uses limits the blast radius of any injection flaw to that subset.

Because the recovered credentials were valid, the administration interface was accessible with them.

After logging into the site backend, various actions become possible, including uploading trojans, crafting dangerous execution statements, and so on. Here we introduce the concept of a WebShell.

A WebShell is essentially an attacker’s stronghold. A “shell” is a program written in a programming language, and a WebShell functions as a tool for managing a web server. With a WebShell you can perform many operations on a site—its capabilities are powerful: command execution, downloading or uploading files, manipulating the database, and more. In this assessment a one-line WebShell was placed through the upload functionality of the application, and the execution path observed was: content inserted through a page, stored in the database, and then written to disk as an executable script by a database backup routine.

That chain — upload, storage, and execution from a location the web server can serve — is the pattern defenders should be able to recognise. The corresponding controls are to keep upload directories outside the web root or serve them without script execution, to validate file type by content rather than by name, and to check web-accessible directories for unexpected script files and recent modification times.

Command Execution and System-Level Access

Command execution vulnerabilities generally refer to situations where data submitted by a user to a website’s backend is not filtered for dangerous functions by the developers, resulting in direct or indirect execution of system commands. Returning to port 8080, the tester found that the service on port 8080 uses the ThinkPHP framework. In recent years ThinkPHP has been plagued by numerous vulnerabilities; the version identified earlier was reachable through a routing and function-call path that the framework exposes, which allowed a file to be written and then requested.

The result is the same class of outcome as the upload chain above, and it confirms the same conclusion: framework-level entry points must be reviewed during upgrades, not only application code.

In addition, the target system also has port 445 open. SMB on ports 445 and 139 was exposed to the network, and the host was affected by MS17-010 (EternalBlue), an RCE vulnerability in SMB over TCP. This is the single most instructive finding of the exercise from a defensive standpoint, because no clever technique was required: an outdated, internet-reachable file-sharing service was the entry point. Legacy hosts of this generation should be patched, and — more importantly — SMB should never be reachable from outside the trusted network segment at all. Segmentation and a default-deny perimeter rule prevent the entire class of attacks regardless of whether a given host has been patched.

Using a post-exploitation framework, a session on the host was obtained and the system state was examined.

Credential material was then recovered from the host’s memory using a well-known credential-dumping utility. This step is worth dwelling on for two reasons. First, it shows that on Windows the compromise of a single administrative session frequently yields the credentials of every account that has logged on to that host, because cached secrets remain recoverable while the system is running. Second, it is directly detectable: reading the memory of the local security authority is unusual behaviour that endpoint detection and response tooling, and process-access auditing, are designed to flag.

At this point the administrator password for the target server had been obtained. In general, system administrators only enable Remote Desktop during updates or maintenance, so the Remote Desktop service is turned off in most cases; a remote-desktop session was nevertheless established in the lab environment.

From a monitoring perspective, this sequence produces a recognisable trail: a service configuration change, a new listening port, a logon of type 10 (remote interactive) for an account that does not normally use it, and a source address that is not part of the administrative network. Each of these is a candidate alert rule in a production environment.

Post-Exploitation and Privilege Escalation

The goal of post-exploitation, from an adversary’s point of view, is to maintain persistent control of the machine for potential future use. A machine’s value depends on the sensitivity of the data stored on its disk and its usefulness for further lateral attacks against other hosts. The current penetration-test topology is as follows: the XX campus network server has already been compromised.

Typically, when we obtain a system shell during a penetration test, the privileges are very low—usually Guest or a member of the Users group—so many operations are restricted. Without elevating privileges, tasks such as lateral movement or gathering additional data are very difficult to perform.

Privilege escalation methods are generally divided into two types: vertical escalation and horizontal escalation.

• Vertical privilege escalation: a low-privilege account gains higher-level privileges.
  Example: Xiao Ming works as the toilet cleaner in a department store. One day the boss notices how well he cleans and suddenly promotes him to CEO. From a system perspective, this is like a Guest account being elevated to Administrator.
• Horizontal privilege escalation: obtaining the privileges or access of another account at the same level.
  Example: Xiao Ming is in line with ticket number 12 but doesn’t know the numbers or identities of people around him, so he goes and asks each person their name to learn about them. Similarly, user1 may not know user2’s information; through horizontal escalation, user1 acquires user2’s information.

The conventional workflow after obtaining a low-privilege shell — enumerating the host, matching the collected version and configuration information against known issues, and applying an escalation technique — is also the workflow that defenders should invert into an audit checklist: unpatched local software, weak service permissions, writable directories in the service path, and misconfigured scheduled tasks account for the majority of successful escalations.

Privilege Escalation on Linux

Common Linux escalation methods include exploiting kernel vulnerabilities, abusing SUDO misconfigurations, wildcard injection, and so on. Common privilege-escalation vulnerabilities include: CVE-2021-33909, CVE-2021-3156, CVE-2020-14386, CVE-2014-9922, CVE-2021-22555, CVE-2017-7184, CVE-2021-33909, CVE-2017-16939, …

Privilege Escalation on Windows

On Windows, common escalation vectors are kernel vulnerabilities, incorrectly configured service permissions, DLL injection, credential harvesting/storage, etc. Notable escalation advisories/vulnerabilities include: MS16-032, “Brazilian barbecue” (literal translation: 巴西烤肉), CVE-2016-0095, …

Internal Network Intrusion and Lateral Movement

In the previous section, access to the XX campus network has already been obtained and Remote Desktop login is possible. At the same time, it was discovered that the XX campus network and the XX enterprise network reside on the same local area network, which means the XX campus network can be used as a pivot to reach the XX enterprise network. The pivot is established by having the compromised host initiate an outbound connection to an external listener.

A C2 (command-and-control) server functions as an attacker’s relay: it allows compromised hosts with shells to call back and establish a reverse connection to the attacker’s infrastructure. Outbound-initiated connections are precisely why egress filtering matters: a host that cannot open connections to arbitrary internet addresses cannot be operated through an external relay, however completely it has been compromised internally.

A post-exploitation framework was used to generate an agent that was placed on the XX campus server.

Internal Network Information Gathering

The internal network contains a vast amount of information; blindly probing it will encounter many obstacles. Therefore, the compromised host can be used as a pivot to enumerate other hosts. In this phase the tester collected domain membership, domain controllers, domain administrators and trust relationships through the standard administrative interfaces that Windows provides for that purpose. This is the direct argument for least privilege in a domain: any account or host capable of querying the directory can map the entire environment in minutes, so the discipline of not using domain administrator accounts for routine work, and of separating administrative tiers, determines how much of that map an intruder obtains.

From the several screenshots above, it can be seen that the XX campus network is a domain member of a particular host, so the campus host can be used to reach the domain infrastructure directly.

Lateral Penetration of the Domain Server

Before gaining access to the domain controller, two situations may be encountered: some servers can directly reach the domain controller, while others cannot be reached directly and require a proxy or a reverse tunnel to continue. In this engagement, credential data was exported from the compromised host to enable further movement.

A tunnel through the compromised host was then established, and a live-host scan of the internal subnet was performed through it.

The scan revealed that, apart from the pivot host itself, a single other host was alive in the subnet, which was consequently identified as the domain controller. The same finding has a defensive meaning: flat internal network segments allow an attacker to enumerate the entire address space from a single foothold, whereas a segmented network with restricted east-west traffic forces each step to be a separate, detectable obstacle.

The domain controller was subsequently reached through the tunnel using the same class of SMB vulnerability identified in the perimeter host — a reminder that a single unpatched service, repeated throughout the environment, converts one compromise into a domain-wide one.

It can be observed that this host is the XX enterprise network server. A connection to it was then established from the pivot using administrative shares, and code execution was achieved through a service-based lateral movement technique. Notably, the credential used for this step was the same administrator password recovered earlier, which is exactly the risk that password reuse across hosts creates: on a network of identically configured machines, one recovered local administrator secret opens all of them.

Persistence Mechanisms and How to Detect Them

Sometimes attackers temporarily suspend active intrusion and, to retain access for future reconnection, implant special programs or user accounts in places that are inconspicuous to the system. Knowing these locations is useful chiefly because each of them is a place to audit. The mechanisms below are described for that reason.

Image Hijacking

Image hijacking (DLL/PE hijacking) occurs when a target program is launched but, due to manipulated search/load order or altered registry settings, the launched executable loads the hijacked module or a replaced program instead of the original system program. The registry location used for this purpose is:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Option

Any Debugger value written under this key redirects the corresponding executable to another program. Auditing therefore consists of comparing this key against a known-good baseline and treating every entry that was not deliberately configured as an incident.

Accessibility Binary Substitution

The Shift key is common in everyday life; in Windows it provides accessibility functions and can be launched before a user logs into the operating system. The accessibility binaries shipped with the operating system, such as sethc.exe and utilman.exe, can be replaced, so that whatever occupies their path executes before any user logs in. Because these files are legitimate components, their modification is a standard persistence indicator: the integrity of the accessibility executables in System32 (hash or signature verification against the vendor-signed original) should be part of host integrity monitoring.

Scheduled Tasks

On Windows there are two commands for creating scheduled tasks: at and schtasks. The main difference is that on newer operating systems the at command cannot run tasks in the foreground — it launches them as background processes — whereas schtasks runs scheduled tasks in the foreground. Persistence through scheduled tasks is detected by reviewing task definitions for actions that reference user-writable directories, script interpreters, or binaries outside the expected installation paths, and by monitoring the creation of new tasks through the security event log.

Clearing Traces Is Itself an Event

When a penetration test concludes, the environment is normally restored and the client is informed of every change made. From a defensive point of view it is useful to know which records an intruder would target: on Linux these are the system, authentication, mail and web-server log files kept under /var/log; on Windows they are the Remote Desktop connection records stored for the current user, the entries inspected through Event Viewer, and the log records that can be removed through the post-exploitation framework’s event-management module.

The important defensive property is that tampering is observable rather than invisible. Clearing or truncating a log is itself recorded by the logging subsystem, and the discontinuity is visible in the log’s own sequence; log files that stop at an unexpected point, gaps in sequence numbers, and services restarted for no operational reason are all signals of an attempt to remove evidence. Practical measures follow from this: forward logs to a central collector that the compromised host cannot write to or delete from, keep sufficient retention, keep host clocks synchronised so that records from different sources can be correlated, and alert on log-service restarts and on the deletion of log files. Any manipulation of logs in an authorized assessment must be agreed in advance and documented, both because it is an operation with operational impact and because it may destroy the client’s own evidence.

Analysis and Attribution

Now, from the perspective of the victim, the hacker has already infiltrated the server, but no additions, deletions, or modifications have been made to the server. Therefore, analysis and attribution can be approached from two angles:

1. Real-time (Present tense) – This is the emergency response scenario, where the server is actively under attack and engineers must respond to the hacker in real time.
2. Post-event (Past tense) – This refers to attacks that have already occurred. In this case, forensic analysis can reveal many details, such as actions the hacker performed in specific directories. For example, one can examine folder modification dates in descending order or analyze Windows event logs.

Windows logs are continuously updated during system operation. They can be categorized into different types: event logs, IIS logs, FTP logs, database logs, mail service logs, etc.

Event Logs

To view event logs, enter eventvwr.msc to open the Event Viewer and inspect the logs. Windows event log files are extremely powerful, recording almost every action of the operating system. This includes system security events, the execution and errors of applications, and more. Each logged event contains highly detailed elements, allowing system administrators to perform digital forensics and analyze the source of an attack. For the incident described in this article, the restart records left by failed attempts were among the first indications that something was happening.

IIS Logs

Windows Server IIS Log Paths:

• Windows Server 2003 (IIS 6): C:\Windows\System32\LogFiles
• Windows Server 2008 R2, 2012, 2016, 2019 (IIS 7 and above): C:\inetpub\logs\LogFiles

Web server logs are the most reliable source for reconstructing the entry phase, because they contain the request line, the status code, the user agent and the source address. The rule for using them in an investigation is to establish a baseline — what a normal day of traffic looks like for that application — and then look for the requests that do not fit: unusually high status-code churn from one address, repeated structurally similar parameter patterns, requests to paths that no page links to, and long parameter values carrying encoding or comment markers. Correlating those entries with the process-creation and authentication events on the host turns a list of suspicious requests into a timeline of the intrusion.

Hardening and Detection Recommendations

The findings above translate into a small set of controls that would have interrupted the chain at several points.

1. Patch and decommission legacy hosts. Windows Server 2008 R2-class systems that are still reachable should be patched against the SMB and RPC issues identified during scanning (MS10-054, MS10-061, MS17-101, CVE-2009-3103, MS17-010) or removed from the network entirely. Where an upgrade is not immediately possible, compensating controls should be documented with an owner and a deadline.
2. Segment and filter. Block SMB (445/139), RDP and other administrative services at the perimeter and between segments. Enforce default-deny east-west traffic so that one compromised host cannot enumerate the whole subnet.
3. Least privilege everywhere. Use a dedicated, low-privilege account for the web application’s database access, restricted to the objects it uses; avoid domain administrator accounts for routine work; and give each host a unique local administrator password so that one recovered secret does not open the whole environment.
4. Fix the application layer. Use parameterised queries or an ORM instead of string concatenation; store passwords with a salted, slow hash; never expose source code, backups or version-control data over HTTP; return generic error pages while logging the detail server-side; and keep upload directories non-executable.
5. Treat the WAF as one layer. Effective filtering normalises input before matching (case, encodings, redundant characters) and is combined with the application-side controls above. A signature set alone will always lag the many equivalent encodings of the same statement.
6. Monitor the post-exploitation behaviours. Alert on access to the memory of the local security authority (credential dumping), on the enabling or reconfiguration of RDP, on the creation of services and scheduled tasks, on writes to the Image File Execution Options registry key, and on the modification of accessibility binaries in System32. These are the actions that convert an initial entry into a lasting compromise.
7. Make evidence survive. Forward logs to a collector the monitored host cannot alter, keep retention long enough to cover the detection window, synchronise clocks, and alert on log-service interruption or deletion.
8. Control egress. Restrict outbound connections to what the business requires, so that a compromised host cannot establish a session with an external relay.

Conclusion

This study conducted penetration testing on a local lab environment, using virtualization to set up two Windows Server 2008 R2 target machines and a Kali Linux host. The exercise followed the phases described above — scope definition, information gathering, vulnerability verification, privilege analysis, lateral movement and traceability — and, after the tests were completed, both target machines were analysed from the defender’s side, which identified the source addresses of the activity.

These results illustrate that no Internet environment is completely secure. The experiments highlight the hazards posed by exposed legacy services, by SQL injection in applications that store credentials in plaintext, and by command execution paths in outdated frameworks. Equally, they show that the same environment offers many opportunities to detect and interrupt an intrusion: unpatched services are visible from outside, unusual authentication and process behaviour is logged, and log sources that are properly centralised cannot be quietly removed. In real-world production environments, security engineers should combine scope discipline in testing with layered technical controls — patching, segmentation, least privilege, input handling and monitoring — so that protection does not depend on any single measure.