Most footholds come from something being wrong. This one comes from something never being done. A file service on the target was left accepting callers who present nothing, and nothing in the system was positioned to notice, because no one had ever decided that it should not.
That distinction is the whole lesson of the room, and it is the reason I paired the writeup with today's field note on an authentication control that silently switched itself off. Both are cases where the control is absent rather than broken, and both are invisible to a review that reads configuration instead of testing behaviour.
01 · Scope and authorisation
This companion documents the public TryHackMe Anonymous room, a standard beginner Linux room. I worked through it in my own session, everything below stays inside that environment, and I have published no flags, no quiz answers, no credentials, no target addresses and no copy-and-paste exploit. Where a step needs a tool, I describe the decision and the flags that matter so you run your own test rather than replaying mine.
The room chains four stages: service discovery on the host, anonymous access to a file service, a scheduled job that executes content from a writable directory, and local privilege escalation through a binary carrying unexpected authority. It maps to CWE-306, missing authentication for a critical function, CWE-732, incorrect permission assignment for a critical resource, and CWE-269, improper privilege management. On the ATT&CK side the relevant techniques are remote services over file sharing and valid accounts, specifically the local-account case.
02 · Learning objectives
- Separate a control that was configured off from one that was never configured.
- Enumerate the services a host advertises rather than the services you expect it to run.
- Assess anonymous access as a configuration finding with a stated exposure, not as a curiosity.
- Recognise when two individually reasonable behaviours compose into a trust boundary nobody verified.
- Treat local privilege escalation as a separate failure from the initial foothold, with its own remediation.
- Write up a configuration exposure without overstating it as a vulnerability in the software.
03 · Prerequisites and the loop I use
The room assumes basic Linux familiarity, a scanner, a file-service client and a shell. The loop I applied is the same one I use on any host:
- Observe what is actually being served, at the level of protocol and response, rather than what a banner claims.
- Hypothesise the control that is absent, or the user who is over-privileged.
- Choose the least invasive test that would falsify the hypothesis.
- Interpret the response as a property of the deployment.
- Update the model and decide whether the finding is a configuration exposure, a composition failure or a privilege problem, because those three have different owners.
The reason observation dominates here is that the interesting facts in this room are delivered by services answering questions nobody remembers asking them to answer.
04 · The model: a control can be off by decision or by omission
Before touching the lab, hold these two cases apart, because the remediation and the write-up differ.
A control is configured off when somebody decided this service needs no authentication, wrote it down, and intended it. A public file share for marketing assets is a real example. That is a decision, it is reviewable, and the correct response to finding it is to confirm whether the owner still wants it.
A control is never configured when nobody decided anything. The service was installed with its defaults, or with a configuration copied from a blueprint, or by a version of the installer whose defaults changed. Nothing in the file says authentication is disabled, because disabling it would require a change and no change was made. This is the case that reading configuration cannot find: there is no line to read. It is visible only by sending a request that should be refused and watching what happens.
That is the mental model for the whole room. The foothold is not a defect in a component. It is the absence of a decision.
05 · Stage one: enumerate what the host advertises
Goal. Establish the services the host is actually running, before forming any view about what it ought to be running.
What to look for. File and share services are the ones worth attention on a general-purpose Linux host, because their access model is per-share and per-user, and an old share can outlive the project it was created for. A scanner with service detection plus the protocol's own enumeration scripts is the right instrument, because a share list is protocol metadata rather than a guess.
Interpretation. A share that answers an enumeration request without credentials is already the finding. You have established that a service intended to distinguish callers is not distinguishing you. Note it as a configuration exposure, not yet as a vulnerability, and continue to the next stage to determine what it exposes.
Failure mode. The common mistake is treating a service as out of scope because it is not the one you expected. A host runs what it runs. The interesting finding in this room is in a service that a hurried assessment would have walked past because it was not the web application.
Transferable concept. In a professional engagement I record, for every file or share service, whether an unauthenticated request was served or refused. That single column is the difference between a report that says "SMB was tested" and one that says precisely which access paths were open to an anonymous caller.
06 · Stage two: read what anonymous access exposes
Goal. Determine what the unintended access actually reveals, and what it implies about everything else on the host.
What to look for. Anonymous access usually exposes more than the owner believes. The pattern to look for is not "secret" but "structure": a note about how a service is used, a backup of something that was edited by hand, a script that someone wanted scheduled, or a directory listing that reveals naming conventions elsewhere.
Interpretation. The value of this stage is that it teaches you what the host does. A file service that exposes a script tells you scheduling exists. A configuration backup tells you what the application expects at runtime. Neither is an exploit, and both narrow the search.
Failure mode. Two. Reading everything you can reach, which turns a controlled assessment into an uncontrolled collection and creates obligations you then have to disclose. And stopping once you have a credential, without asking what else the share exposed, because the same path usually contains more than one useful artefact.
Transferable concept. Anonymous access is a disclosure with a blast radius that is usually larger than the share it was granted on. The correct write-up names what was reachable, what it revealed about the system, and what the owner should assume is public, rather than listing files.
07 · Stage three: a scheduled job executing content someone else can write
Goal. Recognise the composition failure, and understand exactly why neither component is individually wrong.
The composition. A scheduled job runs a script on a timer. The script lives in a directory that the unintended access lets you write to. Both halves are ordinary: scheduling is how a small system does maintenance, and a directory being writable by the file service is how an operator lets content be dropped for processing.
The failure is the join. Whoever can write the file decides what the job executes, and the job executes it with the authority of whoever owns the schedule. No component is broken, no check is bypassed, and nothing in either configuration records that this decision was ever made.
Interpretation. This is the same shape as the composition problem I wrote about in the field note on a model loader executing a file it was pointed at: reading and writing are unremarkable behaviours, and the failure appears when one feeds the other. It is the class of issue that survives code review precisely because both sides look correct in isolation.
Failure mode. The mistake is reporting this as a command-injection or a remote-code-execution vulnerability in the scheduler or the file service. It is neither. It is a permission and ownership problem across two components, and it should be reported that way so the owner fixes the boundary rather than adding input validation to something that never took input.
Transferable concept. When you find a foothold that requires two components to cooperate, state both halves in the report. The remediation is usually a permission change plus an ownership statement, and a report that names only one half produces a fix that does not close the path.
08 · Stage four: local privilege escalation as a separate failure
Goal. Establish whether the account you reached carries more authority than it should.
What to look for. Enumeration on the host for binaries and configurations that grant authority unexpectedly. The category I care about is not "an exploit for a service" but "a file that carries authority nobody remembers assigning", which includes scheduled tasks, writable system files and executables that run with elevated permissions.
Interpretation. Keep this stage separate from the foothold in both your notes and your report. They are different failures with different owners: the host had an anonymous control absent, and separately an unprivileged account could reach root through something it should not. Fixing one does not fix the other, and a report that merges them under one title usually results in only one being addressed.
Failure mode. Testing escalations outside the scope of the lab, and treating a successful escalation as the end of the engagement rather than the point at which the useful questions begin. The questions worth answering are which misconfiguration granted the authority, who is responsible for that artefact, and how many other hosts share it.
Transferable concept. Privilege escalation findings are inventory problems more often than exploit problems. The fix is usually a review of who owns each artefact that carries authority, which is a process answer rather than a patch.
09 · Why the chain works
The four stages are independent, and that is the honest way to present them: any one of them alone would be a finding worth reporting. But there is a common structure worth naming, because it is what makes the room more than four steps.
Each stage is a place where authority was granted without anyone recording the decision. A file service that answers anonymous callers has authority nobody assigned. A share that exposes more than intended has a scope nobody defined. A scheduled job running a writable file has an owner nobody named. A binary carrying unexpected authority has a privilege nobody reviewed.
Read that way, the room is a lesson in inventory rather than exploitation. The technical work is discovery, and the finding is always the same shape: an artefact with authority and no owner. That is also why the fixes are boring, permission changes and ownership statements, and why they are so often skipped in favour of a patch that addresses the symptom.
10 · Defensive controls, logs and detections
| Weakness | Durable control | What to log and alert on |
|---|---|---|
| Unintended anonymous access (CWE-306) | Require authentication on every share and service by default, treat anonymous access as an explicit, documented exception with a named owner, and re-verify it after every upgrade or configuration change. | Unauthenticated sessions on services that expect credentials, and any change to a share's access configuration followed by an unauthenticated request. |
| Share scope wider than intended (CWE-732) | Scope each share to a directory, a purpose and a reader set; keep credentials, backups and scripts out of shared paths entirely. | Reads of credential, key or backup paths from a shared location, and directory listings that traverse further than the share's stated purpose. |
| Writable directory executed by a scheduled job (CWE-732) | Keep scheduled scripts in a root-owned, non-writable directory; if content must be dropped for processing, treat it as data and never execute it; run jobs with the least authority that completes the work. | File writes into directories referenced by schedules, and changes to script files owned by the scheduling user. |
| Unexpected authority on a local artefact (CWE-269) | Maintain an inventory of everything on the host that carries authority, with an owner for each; review it on change rather than annually. | New or modified executables carrying elevated permission bits, and scheduled entries referencing paths outside the standard directories. |
The first row is the one I would action first, and the fix is cheap: test the refusal. For every service that should require authentication, send one unauthenticated request on a timer and assert that it is rejected. That single check would have caught this room's foothold before anyone looked for it, and it is the same check that would have caught the fail-open advisory I wrote about today.
11 · Misconceptions and troubleshooting
- "Anonymous access is enabled intentionally and therefore a non-issue." Intent is a claim to verify, not an assumption. The question worth asking is whether the artefact that is now public was ever meant to be, and who is accountable for it.
- "The configuration does not disable authentication, so authentication is on." Absence of a disabling line is not evidence of enforcement. Only a refused request is evidence.
- "This is an SMB or FTP vulnerability." It is a configuration exposure. Reporting it as a software defect sends the fix to the wrong team, and the wrong team cannot close it.
- "Fixing the directory permissions is enough." It closes one path. The reason the path existed is that authority had no owner, and that condition usually applies elsewhere on the same host.
Troubleshooting the reasoning comes down to three questions asked of any unexpected access. Which decision made this possible, and by whom? What authority does the exposed artefact carry? And who owns it now? Where all three answers are "nobody", you have found the real finding, and it is a governance one with a technical symptom.
12 · Memory aids and practice checklist
Memory aid: nobody turned it off. When access is unexpectedly open, the instinct is to look for the change that opened it. Usually there was no change. The control was never on, and the useful question is who should have decided that it would be.
- Enumerate advertised services, not expected ones.
- For every file or share service, record whether an unauthenticated request was served or refused.
- Ask what the exposure reveals about the host's structure, not just what it contains.
- State both halves of any composition failure in the report.
- Keep the foothold and the privilege escalation as separate findings with separate owners.
- Test the refusal on a schedule rather than assuming enforcement.
- Confirm that every artefact carrying authority has a named owner.
13 · What the room teaches
The room's lesson, stated once: an open door is usually not a door somebody unlocked. It is a door nobody ever fitted a lock to, and the only way to find it is to try the handle.
That is the same verification discipline I argued for in today's field note on an authentication control that was removed by a rename and failed open. The MCP companion covers the case where a check exists and is applied at the wrong layer, and the file inclusion companion covers the case where a caller chooses what the application opens. Read together they cover the three ways a security control can be missing: absent, misplaced, or delegated.
Frequently asked questions
What is anonymous access?
It is a service configuration where a caller who presents no credentials is served rather than refused. On file services it is often enabled deliberately for public content, and left enabled accidentally on far more services than owners realise. The distinction matters because the remediation differs: one needs a scope review, the other needs a lock.
Why does reading configuration miss unintended anonymous services?
Because a control that was never configured leaves no decision to read. Nothing in the file says authentication is off. It simply was never turned on, so there is no line to find and no change to blame. The absence is visible only by sending a request that should be refused and observing that it was not.
Why is a writable directory executed by a scheduled job dangerous?
Both behaviours are individually reasonable. The composition is not: whoever can write the file chooses what the job runs, with the job owner's authority, and neither component verifies the other. It should be reported as a permission and ownership problem across two components, not as a code-execution vulnerability in either one.
How should anonymous access be assessed in a professional engagement?
Enumerate every file and share service, test one unauthenticated request against each, and record whether it was served or refused. Report the ones that were served as a configuration finding, stating what was reachable and what the owner should now assume is public. That column of results is more useful to a client than any list of tools used.
Primary references and further practice
- TryHackMe: Anonymous, official room
- CWE-306: Missing Authentication for Critical Function
- CWE-732: Incorrect Permission Assignment for Critical Resource
- CWE-269: Improper Privilege Management
- MITRE ATT&CK T1021.002: Remote Services, SMB and Windows Admin Shares
- OWASP Web Security Testing Guide, authentication and configuration testing