Threat hunting service accounts in critical systems is one of the more productive exercises an operator can run under NCA CSCC, because the accounts involved are powerful, rarely reviewed and often forgotten. This article describes a hunt pattern we typically see applied in such environments, the reasoning behind it, and what should be left behind when the hunt ends. It is written so that you can adapt the hypothesis to your own estate.
Why service accounts deserve a hunt of their own
The National Cybersecurity Authority (NCA) issues the Critical Systems Cybersecurity Controls (CSCC) as an extension of its Essential Cybersecurity Controls for operators of critical systems. Among other things, the framework expects disciplined identity and access management, privileged access control and continuous monitoring. Service accounts sit across all three.
They are created for a task: a backup job, a database connector, an interface between an operational and an enterprise system. The project ends, the staff move on, and the account stays. It usually has broad rights, a password that never expires and no human owner who would notice odd behavior. For an intruder, that is close to ideal. Activity under such an account looks like infrastructure, not a person.
Detection tools do not always flag this. A valid credential used from a valid host at an unremarkable hour generates no malware alert. That is the gap a hunt is designed to examine.
The hypothesis
A workable statement is: an attacker is using a forgotten privileged service account to move through the environment and remain unnoticed.
This hypothesis is specific enough to test and narrow enough to finish. It also yields a useful result either way. If nothing is found, you hold a verified inventory and a baseline. If something is found, you hold evidence and a scoped incident.
Step one: reconcile the logs against the inventory
The first comparison is between two sources that rarely agree: the account inventory and the authentication logs.
Typical sources include directory records, privileged access tooling, configuration management data and application owner lists. On the other side are domain controller logs, server logon events, database authentication records and, where present, cloud identity logs.
The reconciliation produces three groups:
- Accounts in the directory that appear in no inventory, so nobody owns them.
- Accounts in the inventory with no recent authentication, which are candidates for dormancy.
- Accounts that authenticate frequently but are not recorded as service accounts at all, such as ordinary-looking names used for automation.
The second group needs care. Dormant does not mean harmless. An account that has been silent for a long period and then logs on once is more interesting than one that logs on daily.
Step two: test logons against the job pattern
Every legitimate service account has a rhythm. A backup account authenticates at a set window, from a known server, to a known set of targets. The hunt rebuilds that rhythm from historical logs and looks for departures from it:
- Logons at times outside the scheduled job window.
- Source hosts that have never been used by the account before.
- New target systems, especially those in a different network zone or tier.
- Authentication methods that differ from the account's history.
- Bursts of failed attempts followed by a success.
In the pattern we typically see, a small number of accounts look odd in this step, and most turn out to be undocumented but legitimate changes. That is itself a finding, since undocumented change on a critical system is a control weakness. The few that cannot be explained move to deeper analysis.
Step three: look for interactive use of non-interactive accounts
A service account should run processes. It should not sit at a keyboard. Interactive logon types, remote desktop sessions and console access under such an account are strong indicators of human use, and human use of a credential that no human should hold deserves an explanation.
The hunt checks for:
- Interactive and remote interactive logon types on accounts designated as non-interactive.
- Use of administrative tools, shells or scripting hosts under the account.
- Sessions that begin from workstations or jump hosts instead of application servers.
- Credential use that follows a change in group membership or a password reset.
Where the environment separates enterprise and operational networks, any such session crossing that boundary is prioritized.
Patterns by sector
The shape of the finding differs between sectors, although the cause is usually the same.
Energy and utilities. Accounts created for integration between historian, engineering and enterprise systems often outlive the vendor project that created them. They tend to hold wide rights on both sides of a network boundary.
Financial and payments infrastructure. Batch and reconciliation accounts commonly persist after platform migrations. Older database and middleware accounts are frequently found with rights that nobody remembers granting.
Telecommunications and transport. Monitoring and provisioning accounts are shared across teams and suppliers, so ownership is unclear and passwords are rarely rotated.
These are typical patterns, not descriptions of any single organization. Your own estate will show its own variations.
Mapping the hunt to attacker technique
A hunt is more useful when it is tied to how attackers actually behave. This hypothesis maps naturally to valid account abuse, lateral movement through remote services and credential access techniques in MITRE ATT&CK. Mapping helps you see which parts of the technique you can now detect and which remain blind.
What should remain after the hunt
A hunt that ends with a verbal briefing has limited value. Evidence and detections should remain in your hands. We structure our own hunts in four stages: plan, hunt, report and harden. Our process is described as follows.
Plan: choose hypotheses from threats facing your sector.
Hunt: search logs, endpoints and identity data.
Report: findings, evidence and risk.
Harden: convert findings into detections and fixes.
For this hypothesis, a reader should expect to retain the following:
- A reconciled account inventory with named owners and a decision for each unowned or dormant account: disable, rotate, restrict or retain with justification.
- A baseline of expected logon behavior for each privileged service account.
- Detection rules for logons outside the baseline, first-time source hosts, interactive logon types on non-interactive accounts and use of dormant accounts.
- Preserved log extracts and query logic so that a result can be reproduced and defended in front of an auditor or the board.
- A statement of coverage gaps, such as systems whose logs were missing or too short to support a conclusion.
That last point matters. A hunt can only examine the data that exists. If retention is short or a system does not forward authentication events, an honest report says so, and the gap becomes a remediation item in its own right.
Adapting the hypothesis to your environment
You can run a first version of this hunt internally. Begin with a bounded scope, for example privileged service accounts in one critical system, and a log window long enough to cover your longest job cycle, such as quarterly or annual processing. Document the queries, record the exceptions and decide in advance what counts as an unexplained finding. Then turn each useful query into a scheduled detection.
Repeat the exercise on a regular cycle. Service accounts accumulate again, and a baseline that is not refreshed becomes stale.
How we support this work
Our Proactive Threat Hunting service runs hypothesis-led hunts across your logs, endpoints and identity systems to find hidden activity. It is mapped to NCA CSCC, and also to NCA ECC and SAMA CSF. Hunts use the data you already collect, and where coverage is thin, the report says so. Deliverables include a hunt plan and hypotheses, a findings report with evidence, new detection rules and a coverage map against ATT&CK, with the new detections handed to your SOC. Hunts can run on a managed monthly or quarterly cycle, and quarterly suits most organizations, while regulated and high-risk ones often choose monthly.
If a forgotten privileged account is a question your team cannot yet answer with evidence, this hypothesis is a sound place to begin.
