Ethical › Module 6 › Lesson 3
Persistence and Logs as a Defender
Why testers document; why you never hide tracks on someone else’s box.
Visual · persistence_logs_defender
Testers write timestamps and tickets. Defenders keep logs, including off-box copies. Wiping someone else's audit trail is a crime, not a lab.
Opening
Testers leave a paper trail. Criminals hide one. This course trains the first job.
Lesson 2 left user vs admin as a control. Exam talk then jumps to “maintaining access” and “covering tracks.” Cyberlium splits those phrases on purpose. An authorized tester's job after a finding is documentation: what identity, what time (UTC), what evidence, what impact, what treatment — the same ticket habit as Module 5. Installing a backdoor so you can return next week is not a tester's deliverable unless a written RoE explicitly asks for a controlled, time-bounded proof on a system you are hired to test — and even then this course will not teach how to implant one. Hiding tracks on someone else's system — clearing their logs, timestomping their files, disabling their audit policy — is a crime, not CEH homework. This path is original Cyberlium teaching mapped to a CEH v13 domain — not official EC-Council training, not a cert, not exam dumps. Persistence, as a defender word, is “why we look at startup points and why we keep logs we cannot wipe from the box.” You will not get a registry-Run recipe, a scheduled-task implant, a crontab backdoor, or a log-clear command to run on a neighbor. You will write why logs must leave the machine, why testers do not wipe, and fill persistence-logs-notes.txt chmod 600. Next is a hardening checklist on a box YOU own.
1. Authorized testers document: evidence, time, owner — not a second home on the box
A finding that is not written down did not happen for the customer. Screenshots, command output you were allowed to collect, timestamps, the identity you used, and a sentence of impact are the tester artifact. That is persistence of knowledge in a report, not persistence of malware. If RoE forbids holding a shell overnight, you drop the session and keep the notes. If RoE allows a screenshot of a sudoers mistake, you take the screenshot and you do not add a startup implant “so the retest is easier.” Retest is a scheduled window with the owner, not a hidden listener you left behind. Module 1's permission line still holds: written scope, systems you own or are hired to touch, no “I was practicing.”
Students fail this lesson by copying movie logic: “real hackers leave a way back.” Real authorized testers leave a ticket. Real criminals may try to stay; defenders hunt that attempt with logs, EDR, and startup inventory — still without this course publishing an implant how-to. If a blog titled with a cert acronym teaches wevtutil-clear plus a Run key as the lab, that blog is not this course. Your lab is a notes file that says you understand the difference.
Command guide
Document evidence — WHAT/WHY (not a second home on the box)
═══ COMMANDS ═══
Command — copy this
date -u +"%Y-%m-%dT%H:%M:%SZ" cat >> "$NOTES" << 'EOF' evidence: (what I saw on MY box) time_utc: (paste date -u) owner: me / this lab not: a hidden account I leave behind EOF
2. Covering tracks on someone else's system is a crime — not a stealth elective
Audit logs, shell history on a shared server you do not own, Windows Security Event Log, cloud trail, and syslog exist so owners can reconstruct incidents. Deleting or altering them on a system that is not yours (or not in a written RoE that still usually forbids destruction) is evidence tampering and unauthorized modification. “I cleared the logs so I would not get caught” is a confession, not a methodology. This course will not give you the commands. It will give you the rule: you never hide tracks on someone else's box. You never practice wiping Event Logs on a campus PC. You never timestomp a classmate's files. You never disable logging on a family member's laptop “to see if they notice.”
On a machine YOU own, you may look at whether logging is on (Lesson 4 will check that as hygiene). Turning your own audit policy off to mimic an attacker is still a bad habit for a defender course: you lose the trail you need when your own account is phished. If you experiment, you restore logging before you walk away. You do not publish a wipe script. Empty ethics lines in the notes fail. Notes that contain wipe commands fail even if you claim you did not run them.
3. Logs as defender memory: local is fragile; off-box copies survive a wipe
A log that lives only on the same disk an attacker (or a ransomware event) can reach can be deleted with the disk. Off-box logging — syslog to another host you own, cloud audit exported to a store the endpoint cannot erase, a SIEM, even a USB rotation on a home lab — is how defenders keep memory after the box is hostile. You do not need a vendor name to write the sentence: copies that the endpoint cannot delete are the control. Local Event Viewer / journalctl are still useful for a machine you own; they are not enough by themselves if the threat model includes “someone with admin on this box.” Module 5's compensating control language fits: if you cannot ship logs yet, you still enable local audit and you write a revisit date.
What to log, conceptually: authentication success and failure (Lesson 1's noisy guessing), privilege use (Lesson 2's admin door), and changes to logging itself. If someone disables audit, that disable should itself be a record somewhere else. You will not configure a full SIEM in this lesson. You will write whether YOUR box has local logging enabled, whether you have any off-box destination (even “not yet — revisit date”), and the ethics line about never wiping others. chmod 600. Do not paste other people's log excerpts into a gist.
4. Persistence as a concept defenders hunt — not a kit you build in this file
In defender language, persistence means a mechanism that starts a program again after reboot or relogin without the owner asking. Exam lists name startup folders, service install, scheduled tasks, cron, browser extensions, and similar families. Literacy is: those families exist; owners inventory them; unexpected entries are findings. This course stops there. A how-to that adds a Run key, a malicious service, or a hidden scheduled task is an implant recipe. We will not write it. We will not “practice” it on a VM and then call the VM in-scope as if that made the recipe OK to share. If you want a lab, Lesson 4 is MFA, unique passwords, updates, and logging on YOUR machine — hardening, not a foothold.
A useful failure: you feel the lesson is incomplete without leaving a backdoor on localhost. That feeling is the same one Module 2 named when example.com felt “too easy.” Completeness here is a locked file that says testers document, covering tracks on others is a crime, and logs should leave the box. Next lesson is hands on that box you own.
5. Wrong vs right: wiping someone else's logs vs documenting and shipping yours
Worked failure — same word “persistence,” opposite job. Right never needs a wipe command or an implant to prove they understood tracks.
Wrong
Clear Event Logs or syslog on a campus PC, café POS, or neighbor laptop. Timestomp files you do not own. Install a startup implant “for retest.” Follow a covering-tracks blog and paste the commands into class chat. Skip notes because only a backdoor screenshot counts. This path is not official CEH training and does not give you that crime.
Right
Write: testers document findings with time and evidence. Covering tracks on someone else's system is a crime. Enable local logs; prefer off-box copies the endpoint cannot erase. Fill persistence-logs-notes.txt, chmod 600. No implant recipe. Next: Lab — Hardening Checklist for a Box You Own.
6. Hands-on: persistence-logs-notes.txt — document, do not wipe, chmod 600
On a computer you own, create cyberlium-lab if needed. Fill every ethics blank. Optionally note whether local logging looks enabled (Event Viewer / journalctl --header / a Settings toggle) — observation only. Do not clear logs. Do not add a startup implant. chmod 600.
Command guide
Logs must leave the box — WHAT/WHY
═══ COMMANDS ═══
Command — copy this
ls -l /var/log/syslog /var/log/auth.log | head
Mission: persistence-logs-notes.txt in cyberlium-lab (mode 600)
1) Write: authorized testers document findings; covering tracks on someone else's system is a crime. 2) Record local logging posture on a box YOU own (observation only) and whether any off-box copy exists (or a revisit date). 3) chmod 600 $HOME/cyberlium-lab/persistence-logs-notes.txt. No wipe. No implant. No neighbor logs.
Stuck? Ask Cyberlium AI Mentor
If “real system hacking means wiping logs and leaving a backdoor” still feels true, ask for a hint — not a clear-event command. Try: "Hint only: why testers document instead of implanting, why covering tracks on someone else's box is a crime, and why off-box logs matter?" You still fill persistence-logs-notes.txt. No wipe. No Run-key recipe.
You now keep tester documentation and criminal track-hiding on opposite sides of the permission line. Logs that leave the box survive a local wipe. Persistence is a defender inventory word, not a homework implant. Notes are locked. This is original Cyberlium teaching mapped to a CEH v13 domain — not official EC-Council training, not a cert, not exam dumps. Next — Lab — Hardening Checklist for a Box You Own — MFA, unique passwords, updates, and logging on YOUR machine.
Knowledge Check
APPLY: After a finding on a hired test, a teammate wants to clear the customer's Event Log “so we look stealthy like CEH.” What do testers do, and what is wiping?
Multiple choice
Knowledge Check
APPLY: True or False: Off-box logging is optional theater, so practicing timestomp and log-clear on a café POS makes persistence “real.”
True or False
Knowledge Check
APPLY: You are filling persistence-logs-notes.txt. Which pairing matches this lesson?
Multiple choice
Knowledge Check
APPLY: curl of http://192.168.0.1/ shows a home router login (TP-Link / Netgear / Huawei / "Router Admin"). Is that DEMO in scope as a hacking target?
Multiple choice