Course / 12 Testing / Lesson 04 of 11

Privilege escalation as a list of questions

Estimated time: 16 min reading · 16 min activity

Initial access means obtaining some allowed interaction with a system. Privilege escalation means gaining rights beyond the intended identity’s permissions. A useful review question is who controls code that another, more privileged identity will run.

On Windows, a service is a program managed by the Service Control Manager. Its configured account determines its operating rights. An ACL, access control list, assigns rights on an object to identities. The supplied CSV is a simplified ACL model, not a complete Windows security descriptor. It lets you compare ordinary write access with a higher-rights execution path.

Before you begin

Estimated time
16 min reading, 16 min activity. Setup and optional practice may take longer.
Where you work
Use only the supplied North Desk fictional cards and source in a desktop or mobile browser. Keep predictions in private notes. No login attempt, recovery tool, framework module, permission change, domain setup or target connection is required. Optional later lab setup has a separate budget.
Without a lab
All evidence needed for the activity appears on this page. Copy it into notes if downloads are unavailable. Read the labeled model and predict each result; a paper trace practises the reasoning while tool operation waits for a lab. Reading needs no JavaScript. Answer checking needs JavaScript and a secure context; saving progress also needs usable browser storage.

After this lesson you can:

  • Separate a version lead from a permission row.
  • Name the ordinary account that can write run.bat and the identity the service uses.
  • Recommend removing that write on paper, without changing the file.

01Example

Fresh conceptual comparison, separate from the NightIndex activity.

Ordinary account can edit a maintenance program.
A higher-rights scheduled action is configured to run that program.
Risk: the editor can influence code executed with greater rights.
Review: remove unnecessary write control and verify the intended administrator retains access.
No program replacement or execution is performed.

02The Windows rows

NightIndex is the fictional service. Its account is LocalSystem, a highly privileged local identity. Its configured program is C:\lab\night-index\run.bat. Backslashes separate parts of a Windows path; .bat names a batch script. The model says the service executes this script, without supplying or running a real service configuration.

The CSV grants SYSTEM and Administrators full rights on run.bat and ordinary account lea write. That write lets lea alter code the privileged service is configured to start. The supported concern follows from both records together; the table does not show an actual restart, elevated session or exploited outcome.

A fitting remedy restricts the executable path and containing directories to intended maintainers, then checks effective rights and preserves required administration. The sudo manual gives the same general warning for programs a delegated user can replace, though its Unix policy is a different mechanism from Windows services.

Trace who can change a program and who would execute it to identify a risky rights boundary.Model. A teaching model drawn by hand. It shows the idea, not real tool output.

Read the full explanation below.

Playback is optional. Step through at your own pace.

Ordinary accountThe ordinary account can edit the maintenance program.
Maintenance programEditable code can become an execution-influence edge.
Higher-rights scheduled actionThe higher-rights scheduled action is configured to run that program; no execution occurs.
  1. Ordinary account → Maintenance programCan edit maintenance programSupplied permission relationship; no replacement occurs.
  2. Maintenance program → Higher-rights scheduled actionConfigured execution influenceA higher-rights scheduled action is configured to run that program.
Review write control
pending

The ordinary account has write control over maintenance code.

Follow the explanation

  1. The ordinary account has write control over maintenance code.
  2. The scheduled action would run that code with greater rights.
Read every state and value

1. The ordinary account has write control over maintenance code.

Messages shown
edit
Current message
edit
Policy decisions
Status: pending
Participant roles
Actor: Ordinary account; Text: The ordinary account can edit the maintenance program. · Actor: Maintenance program; Text: Editable code can become an execution-influence edge. · Actor: Higher-rights scheduled action; Text: The higher-rights scheduled action is configured to run that program; no execution occurs.

2. The scheduled action would run that code with greater rights.

Messages shown
edit · Configured execution influence
Current message
Configured execution influence
Policy decisions
Status: not-established
Participant roles
Actor: Ordinary account; Text: Review removal of unnecessary write control while retaining intended administrator access. · Actor: Maintenance program; Text: The maintenance program is the editable code named by the scheduled action. · Actor: Higher-rights scheduled action; Text: Configured relationship only; no execution performed.
Control of code executed with higher rights creates a supported concern; this is not an elevated-session record.

03Point at the writable program

Use the permission CSV and case card. The activity remains a paper review of rights.

Service question card
Label: original fictional Windows card. No service was started and no permission was changed.

Host name on the card: files-3.lab.invalid. It was not contacted.
Service: NightIndex
Started by: the Service Control Manager, the Windows component that tracks installed services.
Runs as: LocalSystem, a highly privileged local identity on this card.
Program configured: C:\lab\night-index\run.bat

Question, not a procedure: who can write run.bat, and who is the service running as?
If an ordinary account can rewrite the program a higher-rights service starts, the ordinary account can change what that service executes.
This card does not tell you to replace the file, restart the service, or collect a credential.

sudo note, different operating system: the sudo manual says not to grant sudo the right to execute a file the user can write, or a file in a directory the user can write. Same shape. This activity uses the Windows rows.

Download the service question card

identity,object,right
SYSTEM,run.bat,full
Administrators,run.bat,full
lea,run.bat,write
NightIndex,service-identity,LocalSystem

Download the simplified permission rows

  1. Find lea’s row for run.bat and copy write as the stated right.
  2. Find the NightIndex identity row and copy LocalSystem. Join the two facts through the configured path.
  3. Write the supported concern: lea could alter the program this service is configured to run. Record execution and escalation as unperformed.
  4. Stop after recommending a narrower write grant and a rights recheck. Do not edit the script or restart the service.

04Framework and privilege case

For about fifteen minutes, combine M-1 and NightIndex into a module note. Compare a version lead lacking behavioral evidence with a permission model whose risky control path is explicitly stated. Each entry needs source, claim, limit, proposed check and fitting remedy.

Framework and privilege case
Label: ungraded synthesis. About fifteen minutes.

1. Name proposal M-1 and the decision not to run it.
2. Name the file an ordinary account can write, and the service identity that runs the service.
3. Say who would be able to change the program a higher-rights service starts.
4. Recommend a fix you will not perform: remove the extra write, then read the list again.
5. Stop: no file changed, no service restarted, no module loaded.

The note is not graded. Do not include a payload or a command that changes rights.

Download the ungraded review case

  1. Keep M-1 as an unexecuted version lead under a reading-only grant.
  2. Cite the script write and service identity for the permission concern; do not add a claim of a successful restart.
  3. Propose removing unnecessary write access while retaining intended administration, followed by a rights review.
  4. Stop with the evidence note. A paper proposal is not a changed or tested service.

05Optional challenge

For about twelve optional minutes, add a retest rubric: ordinary users cannot rewrite the program or replace it through a writable parent directory, while intended administrators retain needed maintenance access. Keep all changes hypothetical.

06Fresh cases for the checks

Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.

Rights card A: fictional simplified configurationOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.

Service: DayArchive; configured identity: LocalSystem.
Configured program: C:\lab\day-archive\start.bat
Rights on start.bat: SYSTEM full; Administrators full; ordinary account neri write.
The model says DayArchive executes this script. No edit or restart is performed.

Repair card B: independent maintenance requirementOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.

Service: NoonCopy runs as LocalSystem and starts copy.bat.
Ordinary account sato can write copy.bat. Administrators have full rights.
Required job: administrators maintain the program; sato only reads its public status.
No other write/replace path is present in this simplified model.

07Explain the evidence and its limit

Optional self-check: draw ordinary writer → configured program → privileged service identity, then name a fitting rights-review retest.

Review it: cite both permission and configuration evidence, preserve administrator maintenance, check replacement paths, and keep the impact conditional.

08Common mistakes

If only the write row is cited, identify what privileged action trusts that path; a complete concern needs both relationships.

If a successful escalation is claimed, point to execution evidence. The model supplies none.

If the remedy removes every administrator, narrow the unnecessary grant while preserving a recovery/maintenance path.

References

  • sudo(8) manual

    Official framework, service, policy or assessment background for interpreting the supplied model.

  • Windows: About services

    Official framework, service, policy or assessment background for interpreting the supplied model.

  • Windows: Service Control Manager

    Official framework, service, policy or assessment background for interpreting the supplied model.

  • Metasploit: Using Metasploit

    Official framework, service, policy or assessment background for interpreting the supplied model.