Prove network impact without causing damage
On this page
- Check first
- How do I prove access to a file share without copying it?
- How do I prove access to a privileged console?
- How do I show credential exposure without dumping hashes?
- How do I leave a single marker file?
- What must a tester never do on an impact step?
- The defender sees
- Done when
- Not covered
- Tools
- Related research
- Reviewed
- Situation
- A position the test already reached, such as a server admin account or access to a file share, and a statement of what the client wants proven. Everything here happens only on hosts, shares and consoles named in the scope letter, under rules of engagement that list the one artifact we may write.
- Goal
- An evidence set that proves what the position could reach, with one marker file as the only change made.
- Outputs
- Representative examples on placeholder hosts, trimmed to the lines that matter. Not captured from a public fixture yet.
Check first
- The rules of engagement say in writing what may be written to a client system. On our tests that is one marker file per position, and nothing else.
- The client named what they want proven: a share with payroll data, a management console, the reach of one admin account. We prove that and stop.
- An operator log is running from the first command, with times in UTC, so the client can read everything we did.
- An evidence folder on our own encrypted test laptop, never on a client host, never on a cloud drive the client did not approve.
- A client contact we can call if a step could touch production in a way nobody expected.
Steps
How do I prove access to a file share without copying it?
Get-ChildItem -Path \\fs01.corp.example.com\finance -Recurse -File -ErrorAction SilentlyContinue |
Measure-Object -Property Length -Sum
Expected output
Count : 18342 # <- files this account can read, none of them opened or copied
Average :
Sum : 41873520113
Maximum :
Minimum :
Property : Length
A count and a total size prove read access to the whole share. The report says "the account could list 18,342 files totalling 39 GiB in the finance share" and stops there. If the client wants proof of what the files hold, we list top level folder names, never file contents, which would put real personal data in our evidence.
Negative result. An access denied error on the share root, or a count of zero with errors suppressed, means the position does not reach it. Rerun without -ErrorAction SilentlyContinue to see where the denial sits, since partial access is a result too.
Fix. Share permissions follow the people who need the data, through groups the data owner reviews. Remove Everyone and Authenticated Users from shares that hold finance, HR or legal data, and turn on access auditing for those shares so a bulk read like this one is visible.
How do I prove access to a privileged console?
shasum -a 256 evidence/2026-10-24T1412Z-mdm-console-devices.png
Expected output
4f1d9c0a7b3e82d65a90c1f7e4b2d8a63c5e1f09b7d2a4c86e3f1b5d9a0c7e24 evidence/2026-10-24T1412Z-mdm-console-devices.png
A screenshot of the console, signed in as the account we reached, with the device count visible and the destructive actions visible but untouched, is the proof. We take it, close the console, and hash the file so the report can show it was not edited later. The UTC time in the file name lines up with the client's sign-in logs.
Device management consoles deserve the most care. The Intune wiper incident shows what an attacker does with one: the wipe button is the impact. We never open the dialog behind that button, not even to cancel it.
Negative result. A sign-in that ends at a conditional access block, a missing role, or a read-only view without the management actions is a result. Screenshot that too, because it shows a control working.
Fix. Console roles that can wipe, deploy scripts or push software sit behind privileged identity management with approval, and destructive bulk actions need a second administrator to approve them.
How do I show credential exposure without dumping hashes?
whoami /groups | findstr /i /c:"Domain Admins"
Expected output
CORP\Domain Admins Group S-1-5-21-1004336348-1177238915-682003330-512 Mandatory group, Enabled by default, Enabled group # <- membership is the proof
Membership in the group that can read every credential in the domain proves that the position could read them. We do not pull them. If the client wants the size of that exposure, the number of enabled accounts from a directory query is enough. No hash, ticket or password ever goes into our evidence folder.
Negative result. No matching line means the token does not carry the group. Check whether the membership exists but is not yet in the token, since a fresh sign-in may be needed, and whether the shell is elevated, before reporting the path as unproven.
Fix. Keep the tier zero groups empty except for named break glass accounts, and alert on every change to their membership.
How do I leave a single marker file?
$m = '\\fs01.corp.example.com\finance\ATARUS-TEST-2026-10-24.txt'
Set-Content -Path $m -Value 'Authorized security test marker. No other change was made. Safe to delete.'
Get-Item $m | Format-List FullName, Length, CreationTimeUtc
Expected output
FullName : \\fs01.corp.example.com\finance\ATARUS-TEST-2026-10-24.txt
Length : 76 # <- 74 characters plus CRLF
CreationTimeUtc : 10/24/2026 2:31:07 PM
One file per position proves write access, carries the test's name so nobody mistakes it for an intrusion, and is the only change the client has to find. The report lists its full path and creation time. The client chooses whether their team removes it as part of checking the finding or whether we delete it at close, which is one logged command that the report explains.
Negative result. An access denied error on Set-Content means the position is read only on that share. Report the read access and stop; do not try another path to write.
What must a tester never do on an impact step?
grep -ciE 'remove-item|copy-item|move-item|compress-archive|invoke-webrequest|robocopy|xcopy|cipher |(^| )(del|erase|copy) ' operator-log.txt
grep -c 'Set-Content' operator-log.txt
Expected output
0
1 # <- the marker file, and nothing else written
We never delete, encrypt, copy out or stage client data, and we never simulate ransomware on a client network, whatever the scope letter allows. A simulation that encrypts test files still runs code that encrypts files on production hosts, and the critical infrastructure analysis is a reminder that the consequences there reach past data. The self check above runs over our own log, and its result goes in the report appendix.
Negative result. Any count above zero on the first line needs an explanation in the report before anything else is written.
The defender sees
The share count shows as share access events (5140) and, with detailed file share auditing on, a burst of 5145 events for one account across thousands of paths. The marker file shows as a file creation event where the folder has an audit rule. The console screenshot leaves a sign-in record for the reached account at the time in the file name, and nothing after it, because no action was taken. The group check reads the account's own token and leaves no event of its own; a process creation event (4688) appears only where process creation auditing is on, with the command line only where that is enabled too. If the client finds none of these, the gap in auditing is a finding in its own right.
Done when
Each claimed reach has a count or a hashed screenshot, the marker file is recorded with its path and time, and the action log shows no delete, copy, archive or encryption command, apart from removing the marker if the client asked us to.
Not covered
Reaching the position in the first place, and destructive or ransomware simulations, which this page rules out; the outputs shown are representative examples on placeholder hosts, not captured runs.