Identifying Service-Based Persistence Through New Service Anomaly and Baseline Comparison

Why This Matters

At the entry level, service persistence investigations focus on a single, clear artefact: a new service that was not present before the compromise. Whether it appears as Windows Event 7045 in a log snippet, a systemctl list-units output, or a straightforward registry export, the analyst's task is to identify the malicious service, document its key attributes, and determine when it was installed. Mastering this pattern builds the foundation for more complex persistence analysis involving multiple services, disguised names, or living-off-the-land techniques.

Core Concept

A malicious service installed by an attacker has a set of identifiable properties that distinguish it from legitimate services:

• Unusual binary path: legitimate Windows services typically reside in C:WindowsSystem32, C:Program Files, or C:Program Files (x86). Malicious services often use C:Users, C:ProgramData, C:WindowsTemp, or randomly named subdirectories.
• Unusual service name or display name: attackers may use generic names (svchost32, Windows Security Helper) or random strings. Compare against known-good service lists.
• Installation timestamp: Event 7045 or the systemd unit file's ctime identifies when the service was created. Correlation with the incident timeline confirms it is attacker-installed.
• Service account: legitimate services use NetworkService, LocalService, or named service accounts. Services running as SYSTEM or as a specific user account warrant scrutiny.

For beginner challenges, the log artifact is typically small and the malicious service is clearly anomalous. The task is to apply a structured identification methodology and extract the key fields accurately.

Technical Deep-Dive

# Windows: filter Event 7045 from a JSON log export
jq -r '.[] | select(.EventID == 7045)
  | [.TimeCreated, .ServiceName, .ServiceFileName, .ServiceType, .ServiceAccount]
  | @tsv' events.json | column -t

# Windows: query live system for recently installed services
# (PowerShell — for reference)
# Get-WinEvent -LogName System -FilterXPath "*[System[EventID=7045]]" |
#   Select-Object TimeCreated,
#     @{n="ServiceName";e={$_.Properties[0].Value}},
#     @{n="ServiceFileName";e={$_.Properties[1].Value}} |
#   Sort-Object TimeCreated

# Linux: list all active services and their unit file paths
systemctl list-units --type=service --all 
  | awk '''{print $1, $2, $3, $4}''' | head -30

# Find services not installed by packages (potential attacker-installed)
systemctl list-unit-files --type=service 
  | awk '''{print $1}''' | grep -v "^$|^UNIT|^Legend" 
  | while read svc; do
      unit_file=$(systemctl show "$svc" -p FragmentPath --value 2>/dev/null)
      if [ -n "$unit_file" ] && echo "$unit_file" | grep -q "/etc/systemd"; then
        echo "CUSTOM UNIT: $svc -> $unit_file"
      fi
    done

# Examine a suspicious service unit file
cat /etc/systemd/system/suspicious.service
# Key fields to extract:
#   [Unit] Description
#   [Service] ExecStart   <-- the binary being run
#   [Service] User        <-- account the service runs as
#   [Install] WantedBy    <-- confirms persistence target (multi-user.target)

# Get the service installation time (unit file creation time)
stat /etc/systemd/system/suspicious.service | grep -E "Modify|Change"

-- Splunk beginner query: list all Event 7045 services installed in last 7 days
index=wineventlog EventCode=7045 earliest=-7d
| table _time ComputerName ServiceName ServiceFileName ServiceAccount
| sort _time

Analytical Methodology

1. For Windows challenges: filter all Event 7045 entries from the provided log file. Create a table: timestamp, ServiceName, ServiceFileName, ServiceAccount. If the log covers a specific incident window, any 7045 entry within or just before that window is a candidate.
2. Examine ServiceFileName for each candidate. Flag entries where the binary path is outside C:WindowsSystem32, C:Program Files, or C:Program Files (x86). Any path under C:Users, C:ProgramData, C:Temp, or containing random characters is suspicious.
3. Look up the ServiceName against a known-good baseline (Microsoft service name list, vendor service lists). Obvious misspellings, duplicate names, or generic names (svchost32) are red flags.
4. For Linux challenges: run systemctl list-units --type=service or examine the provided output. Focus on services with unusual unit file paths under /etc/systemd/system/ rather than /lib/systemd/system/ — the former indicates manual installation.
5. For each suspicious Linux service, read the unit file. Extract: ExecStart (the command executed), User (the account), and WantedBy (persistence target). Note the file creation timestamp via stat.
6. Record the installation timestamp — this is the primary forensic finding. Confirm it falls within the attacker's known activity window.
7. Identify the binary the service executes. Check if it exists on the system. If available, compute its SHA-256 hash. Note file creation time, owner, and permissions.
8. Write your answer: service name, installation time, binary path, service account, and your determination of whether the service is malicious (with reasoning).

Common Analytical Errors

• Reporting the service name but not the binary path: The binary path is more forensically significant than the service name, which an attacker can make look legitimate. Always extract and report both.
• Missing the service account field: Services running as SYSTEM grant the binary unrestricted access to the local machine. This significantly affects impact assessment and should always be noted.
• Confusing service state with installation: A service may be installed but disabled or stopped. Event 7045 records installation, not execution. Check Event 7036 (service state change) to confirm whether the malicious service actually ran.
• Not checking if the binary exists: A malicious service may reference a binary that has since been deleted (perhaps by a clean-up step). The absence of the binary does not eliminate the persistence registration — the service entry remains in the registry and will generate errors at next boot attempt.

NICE Framework Alignment

Further Reading

• Windows Sysinternals Autoruns — enumerates all persistence mechanisms including services
• systemd.service(5) man page — unit file field reference
• Microsoft Docs: Windows Security Log Event ID 7045
• SANS: "Tracking Malware with Import Hashing" — identifying malicious service binaries
• ATT&CK T1543: Create or Modify System Process — beginner-friendly technique overview