Lateral movement techniques constitute a core component of sophisticated cyber-attack campaigns, particularly those conducted by Advanced Persistent Threat (APT) actors. From an initially compromised host, the adversary systematically extends access to additional systems in order to reach high-value resources such as mailboxes, shared folders, and credential stores. These assets are subsequently leveraged to compromise further systems, achieve privilege escalation, or harvest additional credential material of elevated sensitivity. Successful progression of this activity may culminate in the compromise of the Domain Controller, thereby conferring complete administrative control over the Windows-based infrastructure or critical business-operator accounts.
The source host is characteristically a previously compromised system situated within the targeted Windows environment. In the majority of observed campaigns, initial access is achieved through a spear-phishing vector containing either a malicious attachment or a hyperlink directing the victim to an attacker-controlled resource. Upon successful compromise, the adversary typically establishes persistent command-and-control by initiating a callback to a designated C2 infrastructure, resulting in the instantiation of a reverse shell. Following local privilege escalation on the foothold system, the adversary proceeds to extract credential material resident on that host. The harvested credentials are subsequently employed to authenticate to additional systems, thereby initiating the lateral-movement phase of the intrusion.
Systematic auditing of network shares constitutes a high-value artifact source across diverse investigative scenarios. Whether the inquiry targets unauthorized internal access by privileged or non-privileged personnel or intrusion activity originating from external threat actors, reconstruction of share-level interactions yields critical insight into data movement, access patterns, and potential exfiltration pathways.
Mounting of remote file shares remains a prevalent adversary technique for lateral movement, enabling both the staging and propagation of malware payloads and the systematic enumeration and collection of target data prior to exfiltration.
To enable share-level auditing, the Advanced Audit Policy Configuration must be configured to activate the “Object Access → Audit File Share” subcategory. Once enabled, Windows Security Event ID 5140 records every successful or attempted access to network shares. The event captures the share name, the authenticated logon account, and the source remote IP address—attributes that support precise temporal and entity-based filtering during forensic analysis. Complementary Event IDs 5142 through 5144 document the creation, modification, and deletion of shares, respectively, thereby preserving the administrative lifecycle of the share objects themselves.
Event ID 5140 lacks file- or object-level granularity; the event does not enumerate the specific files or directories accessed within the share. To remediate, the “Object Access → Audit Detailed File Share” subcategory within the Advanced Audit Policy Configuration must be enabled. This generates Event ID 5145 records that log individual object access operations. Because the resulting event volume can be substantial, detailed file-share auditing should be applied selectively and only to high-sensitivity systems where the forensic benefit outweighs the operational and storage overhead.
An analyst identified a temporally adjacent evidentiary pairing as seen above: an Event ID 4624 successful authentication co-occurring, within the same one-second epoch, with multiple Event ID 5140 network share access events. Detailed examination of the event payloads establishes that the spsql account completed authentication and subsequently accessed the default administrative share ADMIN$.
ADMIN$ is rooted at the host’s C:\Windows directory and was originally provisioned to facilitate remote administrative functions, principally the distribution of software updates and patches. In contemporary environments that employ more robust and auditable deployment mechanisms, residual utilization of ADMIN$ for legitimate purposes is uncommon and therefore constitutes an investigative indicator of elevated interest.
In the observed instance, the Event ID 5140 record associated with the ADMIN$ connection is deficient in several expected contextual fields, including authenticating account attributes and source workstation identity. This incompleteness is anomalous and is consistent with an artifact introduced by the tooling employed—here, Cobalt Strike. A companion Event ID 5140 entry documenting the concurrent IPC$ connection supplies the missing attribution data. Because SMB/RPC session establishment mandates authentication against the default Inter-Process Communication (IPC$) share, the corresponding event captures the account name, security identifier (SID), domain, Logon ID, source IP address, and source port. Accurate reconstruction of the activity therefore requires correlation of both events in this instance; under routine conditions, comparable identifying information would ordinarily appear in each record.
Critically, an IPC$ connection alone achieves only authentication and confers no file-transfer capability. The subsequent mapping of ADMIN$ (or the functionally equivalent C$ share) is the operation that enables lateral movement and file-system interaction. Nonetheless, isolated IPC$ authentications retain forensic significance: numerous reconnaissance and post-exploitation frameworks generate this signature during network-based enumeration. An unsolicited IPC$ mapping performed with valid credentials—particularly from an unexpected source address—may therefore indicate adversarial activity even in the absence of a follow-on administrative-share connection, provided legitimate administrative behavior can be excluded.
The events, here illustrated, reflect lateral movement executed via Cobalt Strike. Attribution to any specific framework, however, is rarely achievable from Windows Security event data alone. Whether the share was established through the classic net use command, PowerShell’s New-PSDrive cmdlet, the WNetAddConnection API (as leveraged by WannaCry), or frameworks such as Metasploit and Cobalt Strike, the underlying network operations and resulting log artifacts remain substantially congruent.
This technical convergence is advantageous for detection engineering: by hunting for the common forensic residue left by widely employed lateral-movement techniques rather than tool-specific indicators, analysts can more efficiently surface anomalous activity. Such an anomaly frequently serves as the initial investigative pivot that ultimately reveals the adversary’s broader tooling and tradecraft. The associated Event ID 4624 (modern successor to legacy XP/Server 2003 event ID 528) record further corroborates the activity by documenting a Type 3 (network) logon—the logon type characteristically associated with SMB-based file and folder sharing operations.
Within a Windows enterprise environment, numerous legitimate and adversarial operations necessitate the substitution of authentication credentials. A computer account may need to impersonate a user principal to access a remote resource; Outlook may transition from domain-joined credentials to a Microsoft cloud identity for authentication against Microsoft 365 endpoints; an administrator may elevate to a higher-privileged account to execute maintenance tasks; or, of particular investigative interest, an adversary may switch credential sets to achieve lateral movement into systems that enforce distinct authentication boundaries. In well-segmented networks, progression across trust boundaries frequently demands a diverse credential inventory whose utility is confined to specific network zones. This operational reality can be leveraged defensively by hunting for the associated log artifacts.
Such activity is predominantly captured through two event classes: Event ID 4624 Logon Type 9 (NewCredentials) and the specialized Event ID 4648 (“A logon was attempted using explicit credentials”). After triaging out routine background noise—principally computer-account activity and Microsoft 365 authentication flows—the residual events are frequently limited to legitimate administrative operations and adversary (aspirant-administrator) tradecraft. Few non-administrative principals maintain multiple credential sets warranting explicit switching.
Critically, runas-derived Event ID 4648 (modern successor to legacy XP/Server 2003 event ID 552) records possess a distinctive forensic property: they are characteristically generated on the originating host rather than the destination (target system). This characteristic is operationally significant. Conventional lateral-movement evidence is typically observed on the target system, rendering source attribution non-trivial. Event ID 4648, by contrast, records the destination toward which a principal was directed from the system under examination, thereby enabling rapid incident scoping by the mapping of interconnected hosts. Certain scenarios produce dual logging on both origin and target (for example, RDP sessions initiated with alternate credentials). Differentiation is achieved by inspection of the Target Server field: a value of localhost indicates inbound activity recorded on the destination, whereas the presence of a remote IP address signifies outbound activity recorded on the origin. Although correlation of these events can introduce analytical complexity, the investigative return justifies the effort.
Importantly, Event ID 4648 may be generated even when no true credential substitution occurs. The governing criterion is the use of explicit credentials—i.e., authentication material supplied by a process rather than credentials already resident in memory. Adversary frameworks such as Cobalt Strike routinely require the operator to designate specific credentials for remote command execution; PsExec invoked with the -u and -p parameters supplies credentials on the command line; and scripted automation may embed explicit authentication material. Windows records the event whenever explicit credentials are presented, irrespective of whether those credentials match the tokens already present in the logon session. This behavior is commonly observed with malware and therefore constitutes an additional high-value hunting artifact.
A recurrent lateral-movement pattern involves the compromise of multiple accounts possessing heterogeneous privilege levels. To achieve effective traversal of the enterprise and remote process execution, adversaries routinely cycle among these credential sets. This operational necessity supplies defenders with a high-fidelity detection opportunity through analysis of Event ID 4648, which records every authentication performed with explicit or alternate credentials. Such events surface during network share mapping (as seen in the figure above), execution of lateral-movement scripts, WinRM and PowerShell Remoting sessions, and local privilege elevation via User Account Control or equivalent mechanisms.
In this example, an Event ID 5140 record on the target host documents the mounting of the administrative share IPC$. The account employed for the mapping is root, and the connection originates from 192.168.1.96. Under ordinary conditions, this would constitute the entirety of available telemetry. However, when the adversary elects to present a distinct credential set—for instance, an administrative account rather than the interactive user session currently resident in memory—an Event ID 4648 is generated on the originating host, furnishing an independent and complementary view of the lateral movement.
Event ID 4648 therefore provides a perspective orthogonal to the majority of lateral-movement artifacts: it enables direct tracking of outbound authentication attempts from the source system, a capability of particular investigative utility when an adversary establishes connections to multiple destinations. In this instance, credentials transition from the Chad account present in memory to those of the root account. Field nomenclature further clarifies directionality: The Target Server Name field records the destination of the authentication attempt as Asgard-HQ1920. Examination of that system would reveal the subsequent actions performed under the newly presented credentials; in the present case a share was mapped, generating a corresponding Event ID 5140 on the target.
Critically, the target system observes only the newly supplied credentials (root) and retains no visibility into the preceding credential switch. Sole reliance on the Event ID 5140 artifact would therefore leave the compromise of the Chad account undetected. Comprehensive reconstruction of the activity sequence consequently requires correlation of telemetry from both the originating and destination systems.
Herein we examine an alternate manifestation of "runas" telemetry. Recall that explicit credential provisioning denotes instances wherein a tool authenticates via newly supplied credentials rather than leveraging credentials already resident in the current logon session (memory). Numerous post-exploitation frameworks are architected to mandate the provision of such explicit credentials. Cobalt Strike is a representative example. Several of its native commands—most notably make_token and pth —instantiate a new logon session (i.e., explicit credentials) that is subsequently injectable into any designated payload. This requirement persists even when the operator is already authenticated under the target identity. Cobalt Strike’s lateral-movement and remote-interaction capabilities rely extensively on token manipulation; these commands therefore enable both manual and automated actions under an alternate security context while simultaneously generating high-value forensic artifacts.
In our example above, the explicit credentials supplied are identical to those of the currently authenticated session. A 4624 Logon Type 9 event records spsql as both the originating and resultant principal. Because the account identity remains unchanged yet the logon type is 9 (NewCredentials), the event establishes that the credentials were explicitly presented rather than inherited from memory. The Process Name field further attributes the request to 32-bit (SysWOW64) PowerShell.
A temporally correlated Event ID 4648 on the same host corroborates the identical credential pair while additionally recording the destination of the authentication attempt: BASE-WKSTN-05 appears as the Target Server. Although the specific Cobalt Strike command employed in this instance was make_token, the pass-the-hash (pth) variant produces indistinguishable log artifacts.
Windows furnishes highly granular logging of scheduled-task lifecycle events, encompassing both creation and subsequent execution. The Microsoft-Windows-TaskScheduler/Operational log, introduced with Windows 7, constitutes a dedicated operational log exclusively devoted to scheduled-task activity. Owing to its isolation from the Security log's retention constraints, entries herein exhibit substantially longer dwell times, rendering it a prime repository for excavating stale attacker tradecraft.
Although task-history recording was originally enabled by default, contemporary Windows releases (Windows 10 and Windows 11 inclusive) disable the feature by default. Re-enablement is therefore required and may be accomplished via Group Policy, the wevtutil command-line utility, or the Task Scheduler graphical interface. The principal Event IDs of forensic interest within the Operational log are:
- 106 – Scheduled Task Created
- 140 – Scheduled Task Updated
- 141 – Scheduled Task Deleted
- 200 – Scheduled Task Executed
- 201 – Scheduled Task Completed
Complementary Security-log telemetry — contingent upon Object Access auditing — yields richer contextual metadata via five discrete event types:
- 4698 – Scheduled Task Created
- 4699 – Scheduled Task Deleted
- 4700 – Scheduled Task Enabled
- 4701 – Scheduled Task Disabled
- 4702 – Scheduled Task Updated
Of particular investigative significance is the fact that tasks may be scheduled remotely. This capability elevates the artifact’s value, rendering it relevant to both persistence mechanisms and lateral-movement tradecraft. Neither the Task Scheduler Operational log nor the Security log, however, natively distinguishes local from remote task creation. Identification of remote scheduling therefore requires temporal correlation with Type 3 (network) logon events (Event ID 4624) occurring in close proximity to the task-creation timestamp. Automated detection logic that jointly evaluates these two event classes yields substantial analytic and hunting benefit.
Deleted-task events warrant particular scrutiny as a high-fidelity alerting vector. Adversaries commonly create tasks across multiple hosts and subsequently remove them post-execution. In the majority of enterprise environments, task-deletion events are either rare or readily distinguishable from legitimate administrative activity, thereby isolating residual malicious deletions for further scrutiny.
In the above example, evidence of a newly instantiated scheduled task is recoverable from both the Microsoft-Windows-TaskScheduler/Operational log and the Security log. The TaskScheduler Operational log constitutes an especially valuable forensic resource because its entries characteristically persist for substantially longer periods than those written to the higher-volume Security log. Comprehensive characterization of a potentially malicious task, however, necessitates the correlation of multiple discrete events within the Operational log.
Event ID 106 records the creation of a scheduled task yet supplies only the responsible user account and the attacker-supplied task name—the latter frequently crafted for camouflage against legitimate scheduling conventions. Deeper enumeration requires pivoting to Event IDs 200 and 201 (task execution and completion), which expose both the task name and the fully qualified execution path.
When Object Access auditing is enabled, Security Event ID 4698 furnishes a richer set of task properties, including trigger configuration, the account under which the task will execute, and the full command-line path of the intended payload. In the above example, identification of an executable designated winsvchost.exe staged within the C:\temp directory constitutes a strong indicator of malicious intent, given the path's atypical placement and the filename's evident typosquat against the legitimate svchost.exe.
.
The accompanying Event ID 4698 record documents a task created by the account Chad on 20 February 2015 at 22:35:11 and configured for daily execution at 22:01:00 (local system time). The event further captures the complete command to be executed: c:\temp\winsvchost.exe. Such granular detail is of high investigative utility; nevertheless, many enterprises lack the requisite Object Access auditing configuration, rendering this telemetry unavailable. Object Access auditing must be explicitly enabled and is not activated by default in every environment.
Beyond event-log telemetry, scheduled tasks generate persistent local configuration files. Beginning with Windows Vista and Windows Server 2008, Task Scheduler adopted the version 1.2 format. Upon task creation, a file bearing the identical name as the task is written to %SystemRoot%\System32\Tasks (superseding the earlier %SystemRoot%\Tasks location employed by version 1.0 tasks). Tasks instantiated via 32-bit code—an uncommon occurrence and therefore itself an investigative indicator—are stored in %SystemRoot%\SysWOW64\Tasks . These files lack extensions and are structured as XML, rendering them human-readable without specialized parsers. Relative to the legacy version 1.0 .job format, the version 1.2 files encapsulate substantially richer metadata, including:
- Task registration timestamp
- Account and system responsible for registration
- Trigger conditions and recurrence frequency (once, daily, etc.)
- Full command path of the scheduled action
- Security principal under which the command will execute
Account metadata is of particular forensic value when identifying remotely scheduled tasks, a technique frequently employed for lateral movement. Few artifacts natively distinguish remote from local task creation; even the associated event logs omit this distinction. Examination of the Author element under RegistrationInfo, however, discloses both the remote system name and the account used to register the task (locally-registered tasks omit a system name). When a different principal is designated to execute the command, that identity appears under the Principals/UserId element.
In the above example, a task file named YahooUpdateTask was examined. The task was registered remotely from host M4500 by the account NextGenHacker101 on 1 June 2016 at 20:55:23 (local system time). The command c:\windows\system32\srv1.exe was subsequently executed at 20:56:00 under the helpdesk account. Successful registration of the task under the helpdesk principal demonstrates that the registrant authenticated with those credentials; consequently, the helpdesk account must itself be treated as compromised when the task is assessed as malicious.
Although adversaries may delete these configuration files, they remain recoverable through traditional forensic techniques. Their presence across multiple hosts (identical filenames appearing on numerous systems) supplies an effective means of tracking adversary progression through the enterprise and usefully augments evidence obtained from the Security and TaskScheduler/Operational logs.
A purpose-built PowerShell utility, ParseScheduledTasksXML.ps1, is publicly available on GitHub and converts Task Scheduler XML files into CSV format. The script accepts either a single XML file or the entire %SystemRoot%\System32\Tasks directory, facilitating bulk analysis and rapid anomaly detection through standard filtering.
Legacy Task Scheduler Format (Version 1.0)
The original version 1.0 format, employed on Windows XP, Windows Server 2003, and earlier platforms, likewise stores task definitions in a Tasks folder located under %SystemRoot%. In this format, the files carry the .job extension and employ a binary structure. Although less richly annotated than version 1.2 files, the binary .job format retains the most operationally critical fields: registration date/time, user account, full command path, and execution date/time. Both At.exe and Schtasks.exe generate .job files of this type on XP/2003 systems. On newer Windows versions, residual .job files may also appear in the same directory as backward-compatibility duplicates of version 1.2 tasks; these can prove forensically valuable when an adversary removes the primary XML files but overlooks the legacy copies.
Two established utilities facilitate parsing of version 1.0 .job files: jobparser.py (authored by Jamie Levy) and the functionally equivalent Perl implementation jobparse.pl (authored by Harlan Carvey).
Post a Comment