Free Offensive Security Reporting, Documentation and Methodology Practice Test 2026

Master Reporting, Documentation and Methodology with free offensive security practice questions covering professional report writing, engagement scoping, penetration testing methodology (PTES), and remediation guidance. Each question includes a detailed explanation — no signup required. This domain accounts for 5% of the mock exam and maps to skills tested across eJPT, OSCP, PNPT, OSWE, and OSEP.

Key Reporting, Documentation and Methodology Topics

Free Reporting, Documentation and Methodology Sample Questions with Answers

Each question below includes 4 answer options, the correct answer, and a detailed explanation from the FlashGenius Offensive Security question bank.

Sample Question 1 — Reporting, Documentation & Methodology

You are performing an internal penetration test for a financial client. During the engagement, you: 1. Obtained a low-privilege shell on an internal web server via a deserialization bug. 2. Enumerated the network and discovered an internal MSSQL server with weak credentials. 3. Used xp_cmdshell to pivot and eventually performed a DCSync attack from a compromised member server. 4. Extracted the NTDS.dit hashes and cracked several high-privilege passwords offline. The client’s legal team has explicitly stated in the Rules of Engagement (RoE) that: - No password cracking is allowed. - No direct interaction with the domain controller is allowed. - Only evidence that can be reproduced by the client’s internal team should be included in the final report. You already performed steps 3 and 4 before noticing the RoE restrictions in the provided documentation. You now need to document this chain in the final report. Which of the following reporting approaches BEST aligns with professional penetration testing methodology, legal considerations, and defensible documentation practices? A. Fully document every step, including the DCSync and password cracking, and provide all cracked passwords in the main report. Argue that the RoE was unrealistic and that real attackers would do the same. B. Omit all mention of the DCSync and password cracking from the report to avoid legal issues. Only report the initial web server compromise and MSSQL weak credentials. C. Document the attack path up to the point allowed by the RoE (web server → MSSQL → ability to perform DCSync), clearly mark that actions beyond the RoE (actual DCSync and password cracking) were performed in error, summarize the risk and impact without including cracked passwords, and immediately notify the client and your management. D. Only mention that “domain compromise is possible via misconfigurations” without describing the specific path or tools used, to avoid self-incrimination and keep the report high-level.

  1. A. Fully document every step, including the DCSync and password cracking, and provide all cracked passwords in the main report. Argue that the RoE was unrealistic and that real attackers would do the same.
  2. B. Omit all mention of the DCSync and password cracking from the report to avoid legal issues. Only report the initial web server compromise and MSSQL weak credentials.
  3. C. Document the attack path up to the point allowed by the RoE (web server → MSSQL → ability to perform DCSync), clearly mark that actions beyond the RoE (actual DCSync and password cracking) were performed in error, summarize the risk and impact without including cracked passwords, and immediately notify the client and your management. (Correct answer)
  4. D. Only mention that “domain compromise is possible via misconfigurations” without describing the specific path or tools used, to avoid self-incrimination and keep the report high-level.

Correct answer: C

Explanation: The scenario tests methodology, ethics, and reporting discipline, not just technical skill. Why C is correct: - Professional methodology requires: - Adherence to the Rules of Engagement (RoE) and scope. - Transparency when scope is accidentally exceeded. - Reproducible, actionable documentation. - Option C does all of this: 1. **Documents the attack chain clearly and technically** up to the RoE boundary: - Initial foothold: e.g., deserialization exploit on web server. - Lateral movement: e.g., using weak MSSQL credentials and `xp_cmdshell` to execute commands. - Demonstrated capability: showing that the compromised context has rights to perform DCSync (e.g., membership in `Domain Admins` or `Replication`-related groups, or ability to run `impacket-secretsdump` from that host if allowed). 2. **Explicitly flags the overstep** (DCSync and password cracking) as an error, which is critical for legal and ethical defensibility. 3. **Summarizes risk and impact** without including sensitive artifacts that violate the RoE (e.g., cracked passwords, full hash lists). 4. **Escalates internally and to the client** so that legal and management can decide how to handle the deviation. This aligns with real-world OSCP/PNPT/OSEP-style expectations: you must show the kill chain, but also show you understand scope, legal boundaries, and how to document responsibly. Why A is wrong: - While detailed technical documentation is normally good, this option: - **Ignores the RoE** and attempts to justify the violation. - Provides **sensitive data (cracked passwords)** explicitly disallowed by the client. - Argues that the RoE is unrealistic, which is not your call as a tester; your job is to operate within the agreed scope. - In a real engagement, this can create legal exposure for you and your company and damage client trust. Why B is wrong: - Completely omitting the DCSync and password cracking: - **Hides a critical risk**: the fact that domain compromise is achievable from the compromised path. - **Removes key context** about the severity of the MSSQL and AD misconfigurations. - Violates the principle of accurate, complete reporting. - You must be transparent about what actually happened, especially when scope was exceeded, but you can limit sensitive artifacts and clearly mark the mistake. Why D is wrong: - A vague statement like “domain compromise is possible” without: - The **specific path** (web server → MSSQL → DCSync capability), - The **conditions required**, or - **Reproducible steps** makes the report less actionable. - Professional methodology requires **clear, reproducible attack paths** and remediation guidance, not hand-wavy statements. - Also, avoiding detail to “avoid self-incrimination” is the opposite of transparent, defensible documentation. Relevant methodology points: - **Kill chain reasoning**: Show how an initial foothold can lead to domain compromise. - **Scope adherence**: Respect RoE; when violated, document and escalate. - **Reproducibility**: Provide commands and logic the client can follow, e.g.: - `sqlcmd -S mssql.internal.local -U sa -P <password>` - `EXEC sp_configure 'show advanced options', 1; RECONFIGURE;` - `EXEC sp_configure 'xp_cmdshell', 1; RECONFIGURE;` - `EXEC xp_cmdshell 'whoami /groups';` - **Risk communication**: Explain that the compromised account can perform DCSync (e.g., via `impacket-secretsdump`), even if you do not include cracked passwords due to RoE. Thus, C is the only option that balances technical accuracy, ethics, legal constraints, and professional reporting methodology.

Sample Question 2 — Reporting, Documentation & Methodology

You are writing the final report for a multi-week internal network penetration test of a large enterprise. During the engagement, you: - Identified a vulnerable internal web application (`https://intranet.hr.corp`) with an authenticated SQL injection in a POST parameter. - Used Burp Suite and manual payloads to extract employee PII (names, emails, partial SSNs) from the `employees` table. - Leveraged the same SQLi to write a web shell to disk and obtain a SYSTEM shell on the Windows web server. - From that host, you used `runas /netonly` with harvested credentials and `smbexec.py` to move laterally to a file server. - On the file server, you found a share `\fileserver\HR_Backups` containing weekly database backups with full SSNs and salary data. The client has asked for **clear, prioritized remediation guidance** and **validation steps** so their internal blue team can reproduce and confirm fixes. Which of the following report sections BEST demonstrates mature penetration testing methodology for this specific finding chain? A. Under a single high-level finding titled “Insecure HR Systems,” briefly mention that SQLi, privilege escalation, and lateral movement were possible, and recommend “perform a full security review of HR applications and servers.” No technical details or validation steps are provided to avoid overwhelming the client. B. Create separate, detailed findings for: (1) Authenticated SQL injection on `intranet.hr.corp`, (2) Insecure web server configuration allowing web shell write, and (3) Excessive access to `HR_Backups` share. For each, include: technical description, exact reproduction steps (e.g., example Burp request, sample `sqlmap` command, example `smbexec.py` usage), concrete remediation actions, and explicit validation steps the blue team can run after fixes. C. Focus the report on the most critical impact only: that full SSNs and salary data were accessible. Document only the final state (access to `HR_Backups` share) and recommend encrypting backups and enforcing stricter NTFS permissions, without describing the initial SQLi or lateral movement path. D. Provide a narrative-only attack story in the executive summary describing how you went from the HR web app to the file server, but keep the technical appendix minimal to avoid exposing specific payloads or commands that could be misused if the report is leaked.

  1. A. Under a single high-level finding titled “Insecure HR Systems,” briefly mention that SQLi, privilege escalation, and lateral movement were possible, and recommend “perform a full security review of HR applications and servers.” No technical details or validation steps are provided to avoid overwhelming the client.
  2. B. Create separate, detailed findings for: (1) Authenticated SQL injection on `intranet.hr.corp`, (2) Insecure web server configuration allowing web shell write, and (3) Excessive access to `HR_Backups` share. For each, include: technical description, exact reproduction steps (e.g., example Burp request, sample `sqlmap` command, example `smbexec.py` usage), concrete remediation actions, and explicit validation steps the blue team can run after fixes. (Correct answer)
  3. C. Focus the report on the most critical impact only: that full SSNs and salary data were accessible. Document only the final state (access to `HR_Backups` share) and recommend encrypting backups and enforcing stricter NTFS permissions, without describing the initial SQLi or lateral movement path.
  4. D. Provide a narrative-only attack story in the executive summary describing how you went from the HR web app to the file server, but keep the technical appendix minimal to avoid exposing specific payloads or commands that could be misused if the report is leaked.

Correct answer: B

Explanation: This question targets reporting structure, kill chain decomposition, and actionable remediation/validation. Why B is correct: - Mature methodology separates **distinct technical issues** into separate findings, even if they form a single attack chain. Here, that means at least: 1. **Authenticated SQL injection** on `intranet.hr.corp`. 2. **Web server misconfiguration / file write leading to web shell** (e.g., database user with `WRITE` to webroot, or lax IIS permissions). 3. **Excessive access to sensitive backup share** (`HR_Backups`). - For each finding, a strong report includes: - **Technical description**: what is wrong and why it matters. - **Reproduction steps**: so the blue team can confirm the issue. - Example for SQLi: - Burp request snippet: ```http POST /hr/search HTTP/1.1 Host: intranet.hr.corp Content-Type: application/x-www-form-urlencoded query=John' UNION SELECT 1,@@version,3-- - ``` - Or a `sqlmap` command: ```bash sqlmap -u "https://intranet.hr.corp/hr/search" \ --data="query=John" -p query --cookie="SESSIONID=..." --risk=2 --level=3 ``` - **Remediation guidance**: - SQLi: parameterized queries, ORM, input validation, WAF rules. - Web shell write: least-privilege DB accounts, hardened IIS/NTFS permissions. - Share access: proper ACLs, role-based access, segmentation. - **Validation steps**: - After fix, re-run the same Burp request or `sqlmap` to confirm SQLi is mitigated. - Attempt to write to webroot from DB context and confirm failure. - Attempt to access `\\fileserver\\HR_Backups` as a standard user and confirm access is denied. - This structure: - Makes the report **actionable** for engineering and blue team. - Preserves the **attack chain reasoning** by linking findings in the narrative. - Matches expectations in OSCP/PNPT/OSEP-style exams where you must show both exploitation and clear remediation/validation. Why A is wrong: - A single, vague finding like “Insecure HR Systems” with a generic “perform a full security review” recommendation: - Lacks **granularity**: teams don’t know what to fix first or how. - Provides no **reproducible steps** or validation guidance. - Fails to demonstrate a structured methodology or kill chain decomposition. - This is the opposite of the detailed, technical reporting expected in serious pentest certifications. Why C is wrong: - Focusing only on the final impact (SSNs accessible) and ignoring the **initial entry point (SQLi)** and **lateral movement path**: - Hides critical root causes: the vulnerable web app and misconfigured web server. - Prevents the client from understanding how an attacker would realistically get to the backups. - Undermines **defense-in-depth**: they might encrypt backups but leave SQLi and lateral movement paths intact. - Good methodology traces the full kill chain and breaks it into fixable components. Why D is wrong: - A narrative-only attack story in the executive summary is useful for non-technical stakeholders, but: - Without a **detailed technical appendix**, the blue team cannot reproduce or validate. - Avoiding specific payloads/commands out of fear of misuse is not standard; reports are confidential security documents. - Professional reports typically include: - High-level executive summary. - Detailed technical findings with commands, payloads, and PoC requests. - Clear remediation and validation steps. Relevant methodology points: - **Kill chain reasoning**: Show how SQLi → web shell → SYSTEM → lateral movement → sensitive backups. - **Finding decomposition**: Each misconfiguration or vulnerability gets its own finding. - **Reproducibility**: Include exact commands and requests used, e.g.: - `runas /netonly /user:CORP\j.doe cmd.exe` - `smbexec.py CORP/j.doe@fileserver.corp.local` - **Remediation + validation**: For each finding, say how to fix and how to verify the fix. Therefore, B is the only option that reflects a mature, exam-grade reporting methodology.

Sample Question 3 — Reporting, Documentation & Methodology

You performed an internal network penetration test and obtained a SYSTEM shell on a Windows file server hosting highly sensitive HR data. The statement of work (SoW) explicitly says: "No production data exfiltration. Demonstrate access using minimal, non-destructive proof-of-access artifacts only." You need to document this compromise in your final report. Which of the following is the MOST appropriate way to demonstrate impact while remaining compliant with the SoW and professional methodology?

  1. A. Compress the entire `D:\HR\Payroll` share into a password-protected ZIP, exfiltrate it over an encrypted channel, and include a screenshot of the ZIP file contents in the report.
  2. B. List directory contents of `D:\HR\Payroll` using `dir /b` and capture screenshots showing filenames and paths only, then redact any obviously sensitive filenames before including them in the report. (Correct answer)
  3. C. Copy a single random PDF from `D:\HR\Payroll` to `C:\Temp\proof.pdf`, open it to confirm it contains real employee data, and include a redacted screenshot of the first page in the report.
  4. D. Run `robocopy D:\HR\Payroll C:\Temp\Payroll_Backup /E` to demonstrate full access, then delete `C:\Temp\Payroll_Backup` and note in the report that all copied data was removed.

Correct answer: B

Explanation: Professional methodology and typical SoW constraints for production environments emphasize: minimize data exposure, avoid exfiltration of real sensitive data, and demonstrate impact with the least intrusive proof-of-access. Why B is correct: - `dir /b D:\HR\Payroll` (bare format) lists only filenames, not file contents: - Command example: `dir D:\HR\Payroll /b /s` - This shows directory structure and filenames, which is usually sufficient to demonstrate access and potential impact (e.g., `2024_Payroll_Export.xlsx`, `Employee_SSNs.csv`). - Capturing screenshots of filenames and paths proves: - You had SYSTEM-level access to the server. - You could access sensitive directories. - You respected the SoW by not exfiltrating or opening production data. - Redacting obviously sensitive filenames (e.g., those containing SSNs or PII) further reduces risk while still demonstrating business impact. - This aligns with common OSCP/PNPT/OSEP-style reporting expectations: show capability, not actual theft. Why A is wrong: - Compressing and exfiltrating the entire `D:\HR\Payroll` share clearly violates the SoW clause: "No production data exfiltration." - Even if the ZIP is password-protected, you are still moving real sensitive data off the client network. - This is excessive and non-minimal; it increases legal and ethical risk. Why C is wrong: - Copying and opening a real HR PDF to confirm it contains employee data is effectively accessing and processing sensitive data. - Even if you redact the screenshot, you have still violated the spirit (and likely the letter) of the SoW by viewing real production data. - Many professional methodologies explicitly discourage opening PII/PHI unless explicitly authorized. Why D is wrong: - `robocopy D:\HR\Payroll C:\Temp\Payroll_Backup /E` copies the entire directory tree, which is: - Non-minimal and potentially disruptive (disk space, I/O load). - Unnecessary to prove access. - Deleting the copied data afterward does not negate the fact that you handled large volumes of sensitive data, which conflicts with the SoW’s restriction. Relevant methodology points: - Respect SoW and rules of engagement at all times. - Demonstrate impact with minimal, non-destructive actions. - Prefer metadata (paths, permissions, directory listings) over content when dealing with sensitive data. - Document exact commands used (e.g., `whoami`, `dir /b /s D:\HR\Payroll`) and include sanitized screenshots as evidence.

Sample Question 4 — Reporting, Documentation & Methodology

During a web application penetration test, you discovered an authenticated SQL injection in a reporting endpoint. You exploited it using sqlmap with the following command: sqlmap -u "https://reports.acme.local/api/report?id=42" \ --cookie="SESSION=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." \ -p id --dbms=PostgreSQL --risk=2 --level=3 --dump -D prod -T users sqlmap dumped the `prod.users` table, which contains password hashes and email addresses of ~50,000 users. The client’s security team later asks you to justify in your report why running `--dump` was necessary and how they can validate the finding without repeating full data extraction. According to sound penetration testing methodology, what is the BEST way to address this in your report?

  1. A. State that `--dump` is always required to prove SQL injection impact and recommend they rerun the exact sqlmap command in production to validate the issue and confirm the full extent of data exposure.
  2. B. Explain that `--dump` was used once to demonstrate real data exposure, but recommend that for validation they use a staging environment or limit queries to a small sample (e.g., `--where="id < 5"`) and focus on parameterized queries as remediation. (Correct answer)
  3. C. Omit mention of the `--dump` flag from the report to avoid alarming the client, and instead describe the vulnerability generically as "SQL injection with potential data exposure" without proof-of-concept details.
  4. D. Justify `--dump` by stating that automated tools decide the best exploitation strategy, and advise the client to rely on WAF signatures rather than changing application code, since sqlmap was able to bypass authentication.

Correct answer: B

Explanation: A strong methodology requires you to: - Justify intrusive actions (like `--dump`) as minimally necessary to demonstrate impact. - Provide clear, actionable remediation and safe validation steps. Why B is correct: - It acknowledges that `--dump` was used to demonstrate real impact (actual data exposure), which is often necessary in exam-grade and real-world tests to move beyond theoretical risk. - It then shifts to safer validation practices: - Use a staging or pre-production environment with representative data. - Or, if they must validate in production, limit extraction to a very small subset, e.g.: - `sqlmap -u "..." -p id --dbms=PostgreSQL --risk=1 --level=1 --dump -D prod -T users --where="id < 5"` - This aligns with the principle of minimizing data access while still verifying the vulnerability. - It emphasizes proper remediation: fixing the root cause with parameterized queries / prepared statements, input validation, and least-privilege DB accounts. - This is exactly the kind of reasoning expected in OSWE/OSEP-style reporting: explain why you did what you did, and how to reproduce/validate safely. Why A is wrong: - Claiming `--dump` is *always* required is incorrect and methodologically weak. - Advising them to rerun the full `--dump` in production is: - Operationally risky. - Unnecessary to validate the vulnerability. - Potentially in violation of internal data handling policies. Why C is wrong: - Omitting the use of `--dump` hides material facts about the test and reduces transparency. - The client needs to know the actual impact: that real user data was extracted. - Professional reports must include: - The exploitation method (e.g., sqlmap command line). - The scope of data accessed (e.g., number of records, types of fields). - Downplaying or obscuring this is contrary to ethical and professional standards. Why D is wrong: - Blaming the tool (“automated tools decide the best strategy”) is not a valid justification; the tester is responsible for controlling scope and impact. - Suggesting they rely on WAF signatures instead of fixing the code is poor remediation advice: - WAFs are compensating controls, not primary fixes. - Proper remediation is to fix the SQL injection in the application layer and enforce least-privilege DB accounts. - The fact that sqlmap used an authenticated session (via `--cookie`) is unrelated to WAF vs. code remediation. Relevant methodology points: - Document exact commands used and their rationale. - Be transparent about data accessed and limit it to what is necessary. - Provide safe reproduction/validation guidance (staging, sampling, reduced scope). - Focus remediation on root-cause fixes (parameterized queries, least privilege) rather than solely on perimeter defenses.

Sample Question 5 — Reporting, Documentation & Methodology

You are writing the final report for a multi-week internal assessment that included external recon, internal AD attacks, and post-exploitation. One of your key findings is: "Using a compromised workstation account, we performed Kerberoasting and cracked the service account `svc_sql` (SPN: `MSSQLSvc/sql01.corp.local:1433`) to obtain its cleartext password. We then used these credentials to log into `sql01.corp.local` and pivoted to the `FIN-APP` server, ultimately gaining local admin rights there." You need to document this finding in a way that clearly communicates the attack chain (kill chain) and provides actionable remediation and validation steps. Which of the following report sections and content combinations BEST aligns with professional penetration testing methodology?

  1. A. In the "Technical Details" section, include only the final impact (local admin on `FIN-APP`) and a brief note that "Kerberoasting was used" without commands or intermediate steps, to keep the report concise and non-technical for management.
  2. B. In the "Executive Summary", describe the Kerberoasting commands used (e.g., `GetUserSPNs.py`, `hashcat` syntax), and in the "Technical Details" section, focus only on business impact and high-level remediation.
  3. C. In the "Attack Path / Kill Chain" section, diagram and narrate each step (compromise workstation → Kerberoast → crack `svc_sql` → access `sql01` → pivot to `FIN-APP`), and in "Technical Details" provide exact commands and remediation such as service account hardening, SPN review, and constrained delegation. (Correct answer)
  4. D. In the "Remediation" section, recommend disabling all service accounts to prevent Kerberoasting, and omit the pivoting steps from the report to avoid revealing lateral movement techniques that attackers could copy.

Correct answer: C

Explanation: Professional methodology and exam-grade expectations emphasize: - Clear attack chains (kill chains) that show how one weakness leads to another. - Separation of audiences: high-level for execs, detailed for technical teams. - Actionable remediation and validation steps. Why C is correct: - An "Attack Path / Kill Chain" section is a best practice in modern reporting: - It visually and narratively shows the chain: initial foothold → Kerberoasting → credential cracking → lateral movement → privilege escalation. - Example narrative: 1. Compromised `WS-23` user account via phishing. 2. From `WS-23`, executed Kerberoasting: - `GetUserSPNs.py corp.local/jdoe:'Password1!' -dc-ip 10.0.0.10 -request` 3. Cracked `svc_sql` hash with hashcat: - `hashcat -m 13100 svc_sql_hashes.txt rockyou.txt --force` 4. Used `svc_sql` to access `sql01.corp.local`: - `impacket-mssqlclient corp.local/svc_sql:'P@ssw0rd!'@sql01.corp.local` 5. From `sql01`, pivoted to `FIN-APP` and achieved local admin via misconfigured local group membership. - The "Technical Details" section then provides: - Exact commands and tools used (Impacket, hashcat, RDP/WinRM/SMB for pivoting). - Validation steps (e.g., rerun `GetUserSPNs.py` to confirm SPNs, check `svc_sql` password policy, review local admin group membership on `FIN-APP`). - Actionable remediation: - Use long, random passwords for service accounts. - Enforce managed service accounts (gMSA) where possible. - Limit SPNs and review which accounts have them. - Implement AES-only encryption for service tickets and disable RC4. - Apply constrained delegation and remove unnecessary local admin rights. - This structure serves both management (via the attack path and impact) and technical teams (via commands and specific fixes), matching OSCP/PNPT/OSEP expectations. Why A is wrong: - Only stating the final impact and a vague note about Kerberoasting hides critical context: - The client cannot see how weaknesses chained together. - The blue team cannot reproduce or validate the path. - Management-focused content belongs in an Executive Summary, not as the only detail in Technical Details. Why B is wrong: - The Executive Summary should be non-technical and business-focused: - E.g., "An attacker with a single compromised workstation account could obtain a database service account and gain admin access to a finance application server." - Putting detailed commands (e.g., `GetUserSPNs.py`, `hashcat` syntax) in the Executive Summary is inappropriate for that audience and breaks standard report structure. - Technical details and remediation belong in the technical sections, not the summary. Why D is wrong: - Recommending disabling *all* service accounts is unrealistic and not actionable. - Service accounts are required for many enterprise services (SQL, IIS, etc.). - Omitting pivoting steps removes crucial context: - The client needs to understand how compromise of `svc_sql` led to `FIN-APP` admin. - Without this, they cannot properly prioritize or validate lateral movement defenses. - Security through obscurity (hiding techniques) is not a valid reporting strategy; attackers already know these techniques. Relevant methodology points: - Use an attack path / kill chain section to show end-to-end exploitation. - Separate executive and technical content appropriately. - Provide exact commands and tools for reproducibility. - Offer realistic, prioritized remediation and validation steps (service account hardening, SPN review, delegation controls, local admin review).

Sample Question 6 — Reporting, Documentation & Methodology

You’ve completed an internal network penetration test and obtained a SYSTEM shell on a Windows file server that stores HR data. The statement of work (SoW) explicitly says: "Demonstrate impact on sensitive data, but do not exfiltrate or modify any production data." You want to show business impact in your report. Which of the following actions is the MOST appropriate to perform and document, while remaining within scope and following professional methodology?

  1. A. Compress and exfiltrate a full copy of the HR share over an encrypted SSH tunnel to your VPS, then delete the archive from the server to avoid detection.
  2. B. List directory contents and capture a few redacted screenshots showing filenames and partial contents of one or two HR documents, ensuring no full records or PII are stored in your notes. (Correct answer)
  3. C. Use `icacls` to recursively remove write permissions for all non-admin users on the HR share to demonstrate that you could have altered data integrity.
  4. D. Run a PowerShell script that randomly modifies timestamps on HR files to prove you had full control over the data.

Correct answer: B

Explanation: The scenario tests your ability to balance impact demonstration with scope, ethics, and methodology. Why B is correct: - The SoW allows demonstrating impact but prohibits exfiltration or modification of production data. - Listing directory contents (e.g., `dir /s` or `Get-ChildItem -Recurse`) and taking carefully redacted screenshots is a standard, accepted practice. - You can show: - Access to sensitive locations (e.g., `\\fileserver\HR\Payroll`) - File names suggesting sensitivity (e.g., `2024_Payroll.xlsx`, `Employee_SSNs.csv`) - Partial, redacted content (e.g., first few lines with names blurred or replaced) without storing full PII. - This aligns with professional methodology: demonstrate impact, minimize data handling risk, and respect legal/ethical boundaries. Why A is wrong: - Compressing and exfiltrating the full HR share is explicitly against the SoW (no exfiltration of production data). - Even if encrypted and later deleted, you are still in possession of sensitive data, which is a major legal and ethical violation. - Professional methodology emphasizes least data necessary and strict adherence to scope. Why C is wrong: - Changing permissions with `icacls` (e.g., `icacls D:\HR /inheritance:r /grant Administrators:F`) is a destructive action. - It modifies the production environment and could disrupt business operations. - Demonstrating *capability* to modify integrity should be done by showing effective permissions, not actually changing them. Why D is wrong: - Randomly modifying timestamps is also a form of data tampering and can impact forensic timelines and compliance. - It violates the SoW (no modification of production data) and professional standards. Relevant methodology points: - Always operate under the constraints of the SoW and Rules of Engagement. - Demonstrate impact with minimal, reversible, and non-destructive actions. - In reporting, clearly document *how* you validated access (commands, screenshots) while sanitizing sensitive content.

Offensive Security Prep Pack Overview

Other Offensive Security Domains

Start the free offensive security Reporting, Documentation and Methodology practice test now | 10-question quick start | All offensive security domains | All Sample Tests