Chapter 13 — Identity and access

Lesson map

Lesson 13 published. Map, example, EX037.

flowchart TD
  N0["Learning outcomes"]
  N1["13.1 AuthN/AuthZ"]
  N2["13.2 Test accounts"]
  N3["13.3 Shared admins"]
  N4["13.4 MFA"]
  N5["13.5 Service accounts"]
  N6["13.6 Leavers"]
  N7["13.7 Expiring test accounts automatically"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX037"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["13.1 AuthN/AuthZ"]
  N2["13.2 Test accounts"]
  N3["13.3 Shared admins"]
  N4["13.4 MFA"]
  N5["13.5 Service accounts"]
  N6["13.6 Leavers"]
  N7["13.7 Expiring test accounts automatically"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX037"]

[Learning outcomes]
    |
    v
[13.1 AuthN/AuthZ]
    |
    v
[13.2 Test accounts]
    |
    v
[13.3 Shared admins]
    |
    v
[13.4 MFA]
    |
    v
[13.5 Service accounts]
    |
    v
[13.6 Leavers]
    |
    v
[13.7 Expiring test accounts automatically]
    |
    v
[Worked example] --> [Exercise EX037]

Learning outcomes

You will (1) separate AuthN and AuthZ; (2) least-privilege test accounts; (3) map shared accounts to T1078.

13.1 AuthN/AuthZ

Proving identity versus allowing actions. IDOR is AuthZ failure after AuthN.

Authentication answers who is making the request, through a password, passkey or token. Authorization answers whether that person may do this particular thing to this particular object. An insecure direct object reference happens when an application checks the first and skips the second. A customer logs in correctly, then changes an account number in a statement URL and receives someone else's statement. At TRB, Sam tests authorization by logging in as one synthetic customer and requesting objects that belong to a second synthetic customer, so a success proves the flaw without touching any real person's data.

13.2 Test accounts

Named, timed, vaulted, least privilege.

Each property prevents a particular failure. A named account, such as rt-sam-cust01, ties every action in the logs to one tester, which a shared account cannot do. A timed account expires when the window closes, so a forgotten credential becomes useless rather than becoming a back door. Storing credentials in the vault keeps them out of chat messages and notes files. Least privilege means the account has only the rights the planned tests need. Testing a customer-facing flaw with an administrator account would prove nothing about what a customer can do, and would add risk if the session were hijacked.

13.3 Shared admins

Accountability loss; ATT&CK T1078 Valid Accounts.

When five administrators share one account, the log shows that admin made a change but not which person made it. That hampers investigations and lets mistakes go unclaimed. Shared credentials also travel. They get written into scripts, onboarding documents and configuration files, so they outlive the people who knew them. ATT&CK lists the abuse of legitimate credentials as Valid Accounts because an attacker using a real admin password looks like normal administration. Sam's finding for a shared admin account recommends named accounts that can elevate rights, and it records where the shared password was found stored.

13.4 MFA

Verify by config review, not phishing staff.

The question is whether multi-factor authentication is enforced on every route that matters, and the identity provider's configuration answers it directly: which applications require it, which groups are exempt, and whether legacy protocols that bypass it are still enabled. Sending real staff phishing emails to find out would involve people who did not consent to being tested in this engagement and would measure their behaviour rather than the control. Sam exports the conditional-access policies and confirms one exemption with an authorized test account. The finding names the gap precisely, for example that an IMAP endpoint accepts passwords without a second factor.

13.5 Service accounts

Owners and rotation dates required.

Service accounts let applications talk to databases and APIs without a person present, which also means nobody notices when they are misused. An account with no named owner cannot be rotated safely, because nobody knows which systems will break when its password changes, so it usually never changes. Sam's review lists every service account with its owner, the last rotation date and the rights it holds, then flags those with no owner, those rotated more than a year ago and those with interactive logon rights they should not need. The most common fix is making the account non-interactive.

13.6 Leavers

Access lingering after HR termination is a classic finding.

The gap usually comes from a process with several hand-offs. HR records the leaving date, IT disables the directory account, and nobody removes the local accounts, the SaaS logins created outside single sign-on, or the VPN certificate. Sam tests this by taking a synthetic leaver record and checking each system the role had access to. Finding one surviving login is enough for a finding. The recommendation addresses the process, for example driving deprovisioning from the HR event and listing every system that sits outside single sign-on, not just the one account that happened to be found.

13.7 Expiring test accounts automatically

Test account expiry is enforced by a job that disables accounts at window end and pages Sam if disable fails. Manual reminders failed twice historically; the job is now a control, not a convenience.

The page on failure is the important part. A job that silently fails is worse than no job, because everyone believes the accounts are disabled. Disabling can fail when the identity service is in maintenance or when an account was renamed, and each failure leaves a working credential in the wild. The page goes to the tester and the security lead together. Neither may close the engagement until both confirm the account is disabled.

13.8 Break-glass accounts

Break-glass admins are monitored and rare. Sam's review checks that break-glass was not used as daily driver during the window.

A break-glass account exists for the day the normal identity system fails. It bypasses single sign-on and usually multi-factor authentication, which makes it powerful and dangerous. Its credentials are sealed, and any use should produce an alert and a written justification. The test is simple: count its logins over the last quarter and compare them with recorded emergencies. If logins outnumber emergencies, someone is using the account for convenience. The finding then recommends fixing whatever normal access problem drove people to it.

13.9 Confirming the vault denies access without MFA

Vault access for credentials requires MFA. Sam tested denial without MFA and filed the deny as a positive control demo.

Controls deserve evidence when they work, not only when they fail. The test used a test account with a correct password and no second factor, and recorded the vault's refusal along with its log entry. Filing that refusal as a positive control means the next audit can rely on dated evidence instead of a configuration screenshot. It also sets a baseline. If a later test with the same account succeeds, something has changed, and the earlier record shows exactly when the control was last known to work.

13.10 A rotated password found in a printer

A shared admin password on the loan system is rotated, but the same password is later found in a printer config. Sam's leaver-and-secrets checklist now includes "search for password reuse artefacts" after any shared-admin finding.

Rotation fixed one system and left the old secret working wherever else it had been reused. Someone had set up scan-to-folder on the printer with the loan administrator's credentials years earlier, and the printer's web interface showed the password to anyone on the network. A shared password usually has a history, so the search covers scripts, scheduled tasks, device settings and documentation, not only the system where it was first found.

13.11 Testing the break-glass alert

Break-glass use during a window pages the CISO channel automatically. Sam tested the page with a staging break-glass and got a stern but correct phone call.

The call was the evidence that the alert works, because it showed that a person responded, not just that a message was sent. Before the test, Sam agreed the time with the security lead and recorded it in the engagement log, so the call could be resolved quickly. The responder still followed the full procedure and asked who was using the account, why and under which authority. That is the right behaviour, since an attacker could claim to be running a test too.

13.12 Auditing the leaver automation

Leaver tickets auto-open from HR events within an hour; Sam audits the automation weekly.

Automation moves the risk rather than removing it. If the link between the HR system and the ticketing tool breaks, leavers silently stop generating tickets and nobody sees a missing ticket. The weekly audit compares that week's HR terminations with the tickets opened, and checks that each ticket was closed with every listed system confirmed. One week the counts differed by three. A schema change in the HR export had renamed the leaving-date field, so the integration had skipped those records without reporting an error.

13.13 Searching device configurations for secrets

Printer configs are now in the secret-search path after the reuse incident. Strange places hide passwords.

Printers, network storage, door controllers and conference-room systems often authenticate to servers, and their settings pages may store those credentials in readable form. Few teams think of them as places secrets live, so they are seldom rotated or reviewed. The expanded search uses configuration exports gathered by the device owners with permission, not logins to each device during testing. Found credentials are reported to their owners and rotated. The tester does not use them, because using a credential found in a device would test a system outside the agreed methods.

13.14 Keeping the secret search in scope

Secret-search path expansions are logged; scope creep in search is still scope.

Each new location added to the search, such as printer exports, a wiki space or a file share, is recorded with the date, the approver and the reason. A search for passwords reads data that may contain personal information and other teams' secrets, so it needs the same authorization as any other test method. The log also explains the results. A sudden jump in found secrets in one quarter is meaningful only if readers know whether the bank got worse or the search simply looked in more places.

Worked example (synthetic TRB)

Shared admin on loan system becomes F1 with score 6 in lab_rank.

Synthetic case — Riverstone Transit Bank (TRB). The bank, Sam Ito, TrackScope/FindingsDesk/PulseMap and all figures are invented for teaching.

Errors and limits

This book grants no authority to test real banks or payment systems. Labs use documentation-range addresses and synthetic data only; exploit code is never provided.

Exercises

• EX037 — T1078. Which technique fits shared valid admin passwords?
  Show marking criteria

  Rubric: 3 = T1078 Valid Accounts; 2 = name; 1 = wrong; 0 = none.
• EX038 — MFA method. How to verify MFA without phishing?
  Show marking criteria

  Rubric: 3 = configuration/policy review under ROE; 2 = partial; 1 = phish; 0 = none.
• EX039 — Test account traits. List three traits of a good test account.
  Show marking criteria

  Rubric: 3 = named, least privilege, time-bounded/vaulted; 2 = two; 1 = one; 0 = none.

Synthesis

Identity findings are precise about AuthN vs AuthZ and never require phishing colleagues.

Continue studying — chapter 13 of 40

← Chapter 12 (draft) · Course chapter index · Chapter 14 (draft) →