Skip to content
HackInvasionCybersecurity Knowledge Hub
Showing posts with label Windows Security. Show all posts
Showing posts with label Windows Security. Show all posts

Windows Security Log Cleared: Investigating Event 1102 Without Jumping to Conclusions

Why it matters

A cleared log creates two questions: who performed the action, and what evidence is still available? Treating the event as a complete explanation can lead to the wrong response. A maintenance explanation needs corroboration; an unexplained clearing deserves investigation even if no other alert is visible.

Microsoft documents event 1102 as a Windows Security audit-log clearing event. Its subject fields identify the account associated with the action, and its logon identifier can support correlation with other records. This event concerns the Security log; do not silently generalize it to every Windows log channel. Microsoft event reference.

Required evidence

Preserve the original event, machine identity, event time, collection time, account SID, domain, account name and logon identifier. Collect authorized forwarded records, endpoint telemetry and relevant change tickets. Record each source's retention and any delivery gaps. Avoid placing sensitive log contents in public analysis services.

Security-log investigation workflow: confirm event 1102, correlate the host and session, corroborate the explanation, and document uncertainty.
Original HackInvasion conceptual poster. Select to enlarge. Security-log investigation workflow: confirm event 1102, correlate the host and session, corroborate the explanation, and document uncertainty.

Investigation workflow

  1. Confirm the record. Verify the provider, channel and event identifier in the original data. A dashboard label is not a substitute for the underlying record.
  2. Anchor the timeline. Normalize timezones. Keep event and ingestion times separate. Identify the host and the surrounding session without assuming a logon identifier is unique across all machines.
  3. Preserve independent evidence. Locate previously forwarded events and related endpoint records. Document the time interval each source actually covers.
  4. Test the authorization claim. Match a change ticket to the exact host, operator and time window. A ticket for a different server does not explain this event.
  5. Correlate activity. Review available authentication and process evidence around the event. Record unexplained activity separately from confirmed malicious behavior.
  6. State the conclusion and limits. Classify the clearing as explained, suspicious or unresolved. Include the missing evidence that prevents a stronger conclusion.

Two simulated examples

Documented maintenance: A lab rebuild ticket names the host and operator, and the preserved timeline agrees. The event may be explained, but the team should still review whether clearing was necessary and whether retention requirements were met.

Unexplained production event: The account owner cannot explain the session, no matching change exists and the collector has a gap. Escalate the combined evidence. Do not invent the deleted contents or claim a specific attack solely from the missing interval.

Two simulated log-clearing scenarios: documented maintenance versus an unexplained production event requiring escalation.
Original HackInvasion conceptual poster. Select to enlarge. Two simulated log-clearing scenarios: documented maintenance versus an unexplained production event requiring escalation.

Read-only pseudocode

INPUT authorized Windows Security event export
SELECT records where event identifier equals 1102
PRESERVE host, event time, subject identity and logon identifier
CORRELATE within the same host and bounded time interval
COMPARE with approved changes and independent telemetry
REPORT supported observations and coverage gaps

Illustrative and untested. Adapt field names, time windows and joins in an authorized test environment. This example does not clear logs or alter a host.

Tuning and response

Do not suppress every administrator or maintenance window. Scope any documented exception to its host group, purpose and expiry. Review repeated clearing as a pattern, including whether the explanation stays consistent.

Escalate unexplained production activity to the incident lead. Preserve available evidence before remediation, and coordinate any account or device restriction with operational owners. Record who approved containment, what service impact was considered and what remains unknown. ATT&CK mapping requires evidence of adversarial behavior; the event alone is not a completed technique assessment.

Key takeaway: Investigate both the action and the visibility gap. A useful case record explains what happened, why the explanation is supported and which questions remain open.

Reviewed September 15, 2026. Examples are simulated. This guide is educational and does not replace organizational incident procedures.

Continue learning: Knowledge Base.

Windows Service Creation: Distinguishing Deployment from Abuse

Technique & Investigation of the Day · Educational, defensive guidance for authorized environments.

Why it matters

A new service can be a normal installer artifact or an unexplained execution mechanism. Service registration, binary execution and successful startup are different observations. Connect them before deciding what happened on the host.

HACK INVASION / VISUAL FIELD NOTES

Windows service creation

Windows service creation: investigation path. Capture the registration; Inspect the referenced file; Service-installation audit events, such as Security event 4697 where configured.; Validate the deployment; Escalate; assess containment impact; Document the sequence
Original conceptual investigation workflow. No real customer data is shown.
Explore the diagram

Windows service creation: investigation path. Capture the registration; Inspect the referenced file; Service-installation audit events, such as Security event 4697 where configured.; Validate the deployment; Escalate; assess containment impact; Document the sequence

Select the image to open it separately for closer reading.

Required telemetry and evidence

  • Service-installation audit events, such as Security event 4697 where configured.
  • Service name, image path, start type and service account from the event or approved inventory.
  • Process creation, file provenance and service start/failure evidence.
  • Deployment records, software ownership and host role.

Before drawing conclusions, record collection scope, retention and any missing fields. Keep sensitive evidence in approved internal systems.

Step-by-step investigation

1. Capture the registration

Preserve the event and service configuration without starting the service. Record the device and timestamp, and distinguish current state from the original registered path.

2. Identify creator context

Review account and logon evidence associated with installation. A system-level context can be produced by an installer and still requires an explanation tied to the software change.

3. Inspect the referenced file

Check location, ownership, hash and signature through approved tooling. A signature supports provenance; it does not prove every invocation or configuration is safe.

4. Find startup evidence

Correlate service operational records with process events. Installation does not prove the binary ran, and a failed start should not be reported as successful execution.

5. Validate the deployment

Match the service’s exact purpose, file and host population to change records. Compare peers after the same rollout. Unexpected divergence deserves review even if the service name looks familiar.

6. Document the sequence

Record installation, configuration changes, startup and response. Identify which telemetry would make the next investigation quicker and more reliable.

HACK INVASION / VISUAL FIELD NOTES

Windows service creation

Windows service creation: evidence checklist. Service-installation audit events, such as Security event 4697 where configured.; Service name, image path, start type and service account from the event or approved inventory.; Process creation, file provenance and service start/failure evidence.; Deployment records, software ownership and host role.
Original conceptual evidence checklist. No real customer data is shown.
Explore the diagram

Windows service creation: evidence checklist. Service-installation audit events, such as Security event 4697 where configured.; Service name, image path, start type and service account from the event or approved inventory.; Process creation, file provenance and service start/failure evidence.; Deployment records, software ownership and host role.

Select the image to open it separately for closer reading.

Read-only investigation pseudocode

INPUT authorized service-installation and process exports
SELECT new service registrations for scoped devices
EXTRACT actor, image path, start type and account
CORRELATE startup outcomes with process and file evidence
MATCH to approved deployment records

Test and adapt: this is illustrative pseudocode, not executable vendor syntax or a tested production detector. Validate field semantics, time boundaries and results in an authorized environment. It does not change systems.

Legitimate activity versus suspicious activity

Endpoint agents, backup clients and updaters commonly install services. Expected paths and matching deployment evidence support a benign explanation. A service name borrowed from an approved product does not establish that relationship.

Tuning and false positives

Use scoped combinations of product provenance, expected service configuration and device group. Do not allowlist all services running as SYSTEM or all services with a signed executable. Track changes to existing image paths as well as new names.

Escalation, containment and documentation

Escalate unexplained execution with the host owner. Stopping or disabling a service may interrupt essential operations; preserve evidence and follow approved containment authority. Examine related processes and access to assess scope.

Close with an evidence-based disposition: explained activity, supported escalation or unresolved visibility gap. Include identifiers, times, source coverage, competing explanations and the response owner.

MITRE ATT&CK context

Windows Service (T1543.003) is relevant when evidence supports adversarial use of a service for persistence or privilege escalation. A normal installation is not sufficient.

Key takeaways

  • Capture the registration: define the question before broadening the search.
  • Validate the deployment: corroborate the explanation with independent evidence.
  • Keep the observed facts, assumptions and response decisions separate.

Related articles

References

Original educational workflow and conceptual diagrams for Hack Invasion. Public documentation informs source-specific details; investigation decisions require local validation.

New Scheduled Tasks: Correlating Creation, Execution and Ownership

Technique & Investigation of the Day · Educational, defensive guidance for authorized environments.

Why it matters

A task can be registered long before it runs, and an ordinary software installer can create many tasks. A defensible investigation separates registration, modification and execution, then connects each to an accountable owner and expected purpose.

HACK INVASION / VISUAL FIELD NOTES

New scheduled tasks

New scheduled tasks: investigation path. Preserve the task definition; Review action and trigger; Windows task-creation audit events, including event 4698 when the required auditing is enabled.; Validate ownership; Escalate; assess containment impact; Document a lifecycle
Original conceptual investigation workflow. No real customer data is shown.
Explore the diagram

New scheduled tasks: investigation path. Preserve the task definition; Review action and trigger; Windows task-creation audit events, including event 4698 when the required auditing is enabled.; Validate ownership; Escalate; assess containment impact; Document a lifecycle

Select the image to open it separately for closer reading.

Required telemetry and evidence

  • Windows task-creation audit events, including event 4698 when the required auditing is enabled.
  • Task definition, action, trigger, principal and relevant Task Scheduler operational records.
  • Process creation records, executable provenance and available execution outcomes.
  • Software deployment history, change approvals and device role.

Before drawing conclusions, record collection scope, retention and any missing fields. Keep sensitive evidence in approved internal systems.

Step-by-step investigation

1. Preserve the task definition

Record the full task path and available XML definition without running its action. Capture event time and the originating host. The current definition may differ from the one that existed at registration.

2. Resolve registration context

Identify the account and logon context that created the task. Correlate with logon and deployment records. A service account may be expected, but its name alone does not validate the action.

3. Review action and trigger

Inspect referenced paths, arguments, principal and schedule. Treat unfamiliar content as evidence to examine, not something to execute. Compare the action with the software and access expected on the host.

4. Find execution evidence

Search for task execution and matching process instances. A creation record proves registration, not successful execution. Track failures and later changes that alter the interpretation.

5. Validate ownership

Match the task to a deployment, updater or approved automation owner. Confirm the exact path and purpose; a task with a familiar vendor-like name can still be unexplained.

6. Document a lifecycle

Produce a timeline of registration, modifications, executions and response. Use the result to distinguish a noisy creation detector from a coverage gap in execution telemetry.

HACK INVASION / VISUAL FIELD NOTES

New scheduled tasks

New scheduled tasks: evidence checklist. Windows task-creation audit events, including event 4698 when the required auditing is enabled.; Task definition, action, trigger, principal and relevant Task Scheduler operational records.; Process creation records, executable provenance and available execution outcomes.; Software deployment history, change approvals and device role.
Original conceptual evidence checklist. No real customer data is shown.
Explore the diagram

New scheduled tasks: evidence checklist. Windows task-creation audit events, including event 4698 when the required auditing is enabled.; Task definition, action, trigger, principal and relevant Task Scheduler operational records.; Process creation records, executable provenance and available execution outcomes.; Software deployment history, change approvals and device role.

Select the image to open it separately for closer reading.

Read-only investigation pseudocode

INPUT authorized task audit and process exports
SELECT task creation and modification records for scoped hosts
EXTRACT task path, actor, action, trigger and principal
CORRELATE with execution evidence and deployment history
REVIEW unexplained lifecycle changes

Test and adapt: this is illustrative pseudocode, not executable vendor syntax or a tested production detector. Validate field semantics, time boundaries and results in an authorized environment. It does not change systems.

Legitimate activity versus suspicious activity

Installers, inventory agents and backup products often register scheduled work. Consistent task definitions and matching deployment records strengthen a legitimate explanation. A one-off unexplained action on a sensitive host requires closer review even if its schedule is ordinary.

Tuning and false positives

Use the combination of task path, action provenance, device role and deployment context. Do not suppress all tasks created by administrators. Audit changes to previously approved tasks as well as new registrations.

Escalation, containment and documentation

Preserve the definition and relevant binaries through approved evidence handling. Disabling a task can affect backups or maintenance, so obtain response authority and confirm dependencies. Assess executed activity separately from the registered artifact.

Close with an evidence-based disposition: explained activity, supported escalation or unresolved visibility gap. Include identifiers, times, source coverage, competing explanations and the response owner.

MITRE ATT&CK context

Scheduled Task (T1053.005) is relevant when the task is used for adversarial execution or persistence. Ordinary task administration is not an attack by itself.

Key takeaways

  • Preserve the task definition: define the question before broadening the search.
  • Validate ownership: corroborate the explanation with independent evidence.
  • Keep the observed facts, assumptions and response decisions separate.

Related articles

References

Original educational workflow and conceptual diagrams for Hack Invasion. Public documentation informs source-specific details; investigation decisions require local validation.

Amit Vijayan

Amit Vijayan
Hack Ethically

About Me


I am an engineering student and i am very dedicated about Ethical Hacking. I have been learning "Ethical Hacking" for about 4 years now.
Though I'am not a pro hacker but also not a noob. I have enough knowledge to give others like me, a start for their Ethical Hacking & Cyber Security. As i keep learning new things, i keep updating them on the blog from basic to advanced level.
I started Ethical Hacking as a hobby which has now turned into my passion and i'am sure i will turn it into my profession through this blog.

Always be an Ethical Hacker.