Keys You Must Not Paste in Reports

Confidentiality of a test is not only the target’s data. It is also the artifacts you created: screenshots, packet notes, copies of configs, toy keys you generated to demonstrate a fix. Module 1’s RoE already said written scope. Module 20 adds written hygiene for secrets inside your own deliverable. If a client can forward the PDF to a contractor, the contractor now has every unredacted secret. If you upload the PDF to a class portal, the class now has it. If you leave the report world-readable in Downloads, the next local account has it. chmod 600 on lab files is the same control as “do not paste.” They are one habit: secrets stay in a small, locked place; narratives stay in the document that moves. Empty ethics lines fail. A report that is “complete” only because it includes the PEM fails this lesson even if the TLS fields were correct.

Screenshots fail the same way. A terminal that still shows openssl genrsa output, a browser that still shows a session cookie, a cloud console that still shows a secret value — crop or regenerate. “I will remember to crop later” is how later never happens. If you must prove a key existed, prove the filename, the permission bits, the last four characters, or a SHA-256 of the key file you already stored under cyberlium-lab — Lesson 1’s fingerprint — not the key material itself. Matching a fingerprint is how you show you hashed the same file without publishing the file. That is the point of a digest in a report. Publishing the digest of a public ISO is fine. Publishing the digest of a private key is still better than publishing the key, but the private key file must not travel beside the digest.

cat >> "$NOTES" << 'EOF'
reports_travel: treat every paste as a publication
rule: narrative in the report; material in a locked lab file
EOF

Treat as secret unless a written policy says otherwise: private keys and PEM blocks (BEGIN PRIVATE KEY, BEGIN RSA PRIVATE KEY, BEGIN OPENSSH PRIVATE KEY), PKCS#12 passphrases, TLS client certs paired with keys, API tokens, cloud access keys, database passwords, password-reset links, session cookies, MFA backup codes, lab passphrases you generated for this course, hashes stolen from other people (Lesson 1 already refused dumps). Public keys and public certificates are not the same class — Lesson 2’s example.com leaf is public by design. Mixing public leaf and private key in one gist is how people leak the wrong file. Connection strings in screenshots are secrets. .env files are secrets. The word “example” in a filename does not make a live token safe. If you generated it, lock it. If you found it on a host in scope, put it in the vault your RoE named — in this course, that vault is a chmod 600 file under cyberlium-lab that is not the report notes — and write REDACTED in the report stand-in.

Production stores were named in Topic 8: HSM, cloud KMS, secret managers with IAM, OS keychains, password managers for humans. Local scripts: environment variables or a chmod 600 gitignored file — never the source tree you push. Public GitHub is not a vault. Slack is not a vault. Discord is not a vault. A world-readable USB stick is not a vault. Emailing yourself the PEM is not a vault. This course uses toy keys so you can practice the habit without burning a real tenant. A leak of a lab passphrase must not open your real accounts, which is why you will not reuse it. If a live key ever lands in git, treat it as burned: rotate, follow a real incident process, never “it was only five minutes.” This lesson will not walk you through purging someone else’s history. It will walk you through not putting the key in the file you are about to attach.

A usable report sentence looks like this: “Host in scope presented a private key file at path P with mode 644. Evidence stored in the engagement vault as object ID … Last four of fingerprint … Recommended: move to 600, rotate the key, reload the service.” A failing report sentence looks like this: then the next page is the entire PEM. Another failing sentence: “password is hunter2” in the executive summary. Another: a screenshot of AWS_SECRET_ACCESS_KEY in a Slack export you attached as Appendix C. Redaction is not lying. It is splitting audience. The owner who must rotate needs a handle and a location. The PDF audience needs the finding, the impact, and the fix. They do not need to become additional holders of the secret. If your class asks to “see the key to grade you,” show the locked file listing and the fingerprint, not the bytes — and in this course the grader is you plus the mission checkbox.

Generate toy material with a CSPRNG: openssl rand -hex 16, Python secrets.token_hex(16), not time.time(), not four words from a meme. Write it once into $HOME/cyberlium-lab/toy-lab-secret.txt. chmod 600. Do not echo it into keys-reports-notes.txt. The notes that stand in for a report say: toy secret stored separately, mode 600, not pasted here, not reused on real accounts, not committed. If you already pasted it, rotate: generate a new toy, overwrite the secret file, leave REDACTED in the notes, do not try to “edit history” of a chat by sending it again. Least privilege still applies: one toy per job. The staging passphrase is not the production passphrase. In this course there is no production passphrase. That is the point.

Topic 8’s lifecycle still holds in a CEH-shaped domain. Generate with OS/crypto RNG and enough length. Store where access is controlled. Use with least privilege. Rotate on a schedule and after suspicion. Revoke when a name or key is dead — CAs revoke certificates; cloud IAM disables access keys; you disable a token in the control plane. The plan must exist before the breach. Homebrew XOR and verify=False stay refused. You will not invent a cipher to “practice report screenshots” against a classmate’s homework server. You will not disable TLS verification in a script you then point at a bank because a lab CA was annoying. Fix trust on machines you own. Fix certificates on stacks you run. Reports that recommend verify=False as a workaround fail this module the way café nmap failed Module 3.

Chain-of-custody from Lesson 1 helps here: if you must prove two copies of a config match, hash them. If you must prove you did not alter a public cert PEM you saved, hash that PEM — it is public. If you must prove a private key file did not drift in your vault, hash it locally and put only the hex in working notes that stay chmod 600, never in the traveling PDF. Do not hash /etc/shadow to “manage keys.” Do not hashcat anything you redacted. Redaction is not a puzzle for the class to invert.

A keys-and-reports note is boring on purpose. Date (UTC). What a traveling report may contain (finding, path, permission bits, fingerprint last-four or SHA-256 of a vaulted file). What it must not contain (PEM private blocks, tokens, cookies, live passwords, dumps). Where the toy secret lives ($HOME/cyberlium-lab/toy-lab-secret.txt, chmod 600, not in this report file). Ethics: NEVER paste private keys in PDFs/chat/git, NEVER reuse lab secrets on real accounts, NEVER commit .pem, NEVER hashcat the redacted material, NEVER screenshot cookies into Discord. Legal line: original Cyberlium teaching mapped to the CEH v13 cryptography domain — not official EC-Council training, not a cert, not exam dumps. Path: $HOME/cyberlium-lab/keys-reports-notes.txt, chmod 600. Empty files fail. Files that contain the toy secret in plaintext fail this lesson even if chmod is 600 — that file is the report stand-in, not the vault.

A useful feeling: the lesson is “too small” because you did not attach a real key. That feeling is how people leak tenants. The skill is splitting vault from narrative. Lesson 4 will not ask you to paste a key either. It will ask you to re-hash a file YOU created and recheck example.com fields. Keep the toy secret locked and unused on real accounts. Next after the lab is the path-final quiz.

On a computer you own, create cyberlium-lab if needed. Generate a toy secret into toy-lab-secret.txt only. Fill keys-reports-notes.txt with the redaction map and the word REDACTED where a bad report would have pasted the secret. chmod 600 both files. Do not print the toy into the notes. Do not add a real API key to make it “more realistic.” Windows: WSL, Git Bash, or py plus a restricted ACL. Do not commit either file.

You now split vault from narrative: toy secrets locked in cyberlium-lab, traveling notes REDACTED, lifecycle still generate-store-rotate-revoke. This is original Cyberlium teaching mapped to the CEH v13 cryptography domain — not official EC-Council training, not a cert, not exam dumps. Next — Lab — Re-hash a File and Recheck a Cert — Topic 8 labs again: SHA-256 of a file YOU created plus example.com certificate fields. Notes ceh-crypto-lab.txt chmod 600. No hashcat. No fake CAs against others.