Hack Invasion

Prioritizing Vulnerabilities with Exposure, KEV and Business Impact

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

Why it matters

A long vulnerability list is not a remediation plan. Prioritization becomes actionable when a finding is tied to the affected asset, reachable attack surface, evidence of exploitation and the consequences of failure. A severity number is one input, not a complete ordering rule.

Vulnerability prioritization: investigation path. Validate the finding; Establish reachability; Authenticated inventory and vulnerability findings with scan time and detection method.; Assign a defensible priority; Escalate; assess containment impact; Verify remediation — Original conceptual investigation workflow. No real customer data is shown.

Required telemetry and evidence

Authenticated inventory and vulnerability findings with scan time and detection method.
Vendor affected-version and remediation guidance, including prerequisites and mitigations.
Current CISA KEV evidence and any source-supported exploitation statements.
Asset exposure, criticality, ownership, dependencies and change-window constraints.

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

Step-by-step investigation

1. Validate the finding

Confirm the installed product, version and vulnerable component. Distinguish a scanner inference from verified inventory. Do not attempt exploitation to prove exposure.

2. Read the vendor guidance

Check affected configurations, fixed releases and supported mitigations. A generic CVE summary may omit a prerequisite that changes the local risk or remediation plan.

3. Establish reachability

Map actual access paths and controls with the system owner. An internet-facing hostname does not prove the vulnerable interface is reachable, and an internal host can still be exposed to important threat paths.

4. Check exploitation evidence

Use the current KEV catalog and primary advisories. Distinguish public disclosure, a public proof of concept and confirmed exploitation. Absence from KEV is not proof that exploitation has never occurred.

5. Assign a defensible priority

Combine exposure, affected configuration, business impact and confirmed exploitation with the organization’s policy. Record an owner and target date rather than publishing a context-free risk score.

6. Verify remediation

Confirm the deployed fix or mitigation and retest using approved non-invasive validation. A closed ticket is not evidence that every affected instance changed. Track exceptions with review dates.

Vulnerability prioritization: evidence checklist. Authenticated inventory and vulnerability findings with scan time and detection method.; Vendor affected-version and remediation guidance, including prerequisites and mitigations.; Current CISA KEV evidence and any source-supported exploitation statements.; Asset exposure, criticality, ownership, dependencies and change-window constraints. — Original conceptual evidence checklist. No real customer data is shown.

Read-only investigation pseudocode

INPUT validated findings and asset inventory
JOIN product, version, exposure and owner
ENRICH with vendor guidance and verified KEV status
APPLY organization priority policy and document reasons
TRACK remediation evidence and time-bound exceptions

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

Backported fixes, disabled components and scanner fingerprints can complicate version-only findings. Record the evidence supporting a not-affected decision. Conversely, a failed scan or compensating control with untested scope does not establish safety.

Tuning and false positives

Deduplicate repeated observations by asset and component without losing history. Separate unsupported products from routine patch work. Review exceptions after exposure or vendor guidance changes, and avoid permanent risk acceptance without an accountable owner.

Escalation, containment and documentation

Escalate urgent exposure through vulnerability and service owners. Emergency mitigation can affect availability and requires a rollback and verification plan. If evidence suggests compromise, initiate an incident investigation alongside remediation; patching alone does not resolve that question.

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

This is a control-improvement workflow, so no adversary technique is assigned automatically. Map a specific exploitation behavior only if incident evidence supports it.

Key takeaways

Validate the finding: define the question before broadening the search.
Assign a defensible priority: corroborate the explanation with independent evidence.
Keep the observed facts, assumptions and response decisions separate.

References

CISA: Known Exploited Vulnerabilities Catalog

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

Reviewing New Cloud Access Keys and Their First Observed Use

AmitVijayan 10:00:00 Add Comment

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

Why it matters

A newly created access key changes the credentials available to an identity, but the creation event alone says little about subsequent use. Investigate the creator, the intended workload and the first use visible in your retained telemetry; do not mistake that for the key’s first use anywhere.

Cloud access key review: investigation path. Define the account scope; Review expected purpose; IAM credential creation and change events from authorized CloudTrail sources.; Compare scope and behavior; Escalate; assess containment impact; Record and improve — Original conceptual investigation workflow. No real customer data is shown.

Required telemetry and evidence

IAM credential creation and change events from authorized CloudTrail sources.
Caller identity, target user, event result and relevant credential identifiers; never collect secret key values.
Subsequent recorded API activity, regions, services and response errors.
Workload ownership, rotation tickets, role policies and available credential usage summaries.

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

Step-by-step investigation

1. Define the account scope

List the accounts, regions, period and log sources being reviewed. Record retention and collection boundaries. A partial view cannot establish that a credential was unused elsewhere.

2. Find successful creation

Separate failed requests from successful changes and identify creator versus target user. Preserve the event ID and relevant credential identifier internally, without exporting secret material.

3. Review expected purpose

Ask the workload owner why a long-lived key was needed and how it is managed. Compare the explanation with the approved rotation or integration record and effective access.

4. Trace observed use

Review subsequent API events attributable to the credential within available coverage. Last-used summaries are useful leads, not a complete chronological event trail.

5. Compare scope and behavior

Check whether requested services, regions and resources match the intended workload. An expected SDK or source address is supporting context; it cannot by itself prove that the credential is controlled by the right party.

6. Record and improve

Document creation, observed use and unobserved intervals. Review whether short-lived workload credentials would reduce risk, without making an unplanned production change during the hunt.

Cloud access key review: evidence checklist. IAM credential creation and change events from authorized CloudTrail sources.; Caller identity, target user, event result and relevant credential identifiers; never collect secret key values.; Subsequent recorded API activity, regions, services and response errors.; Workload ownership, rotation tickets, role policies and available credential usage summaries. — Original conceptual evidence checklist. No real customer data is shown.

Read-only investigation pseudocode

INPUT authorized credential-change and API event exports
SELECT successful key creation for scoped accounts
ASSOCIATE creator, target identity and credential identifier
FIND first observed subsequent use within retained coverage
COMPARE services and resources with the approved workload

Legitimate activity versus suspicious activity

Rotation can briefly create overlapping keys, and a deployment may use a key from a new network range. Validate the exact rollout and owner. A key with no currently visible events may be dormant, outside the collection scope or simply not yet used.

Tuning and false positives

Baseline workload-specific services and regions. Treat emergency maintenance separately from regular rotation. Avoid suppressing all API activity from a common automation identity or all use from a corporate egress address.

Escalation, containment and documentation

If use is unexplained, coordinate with cloud and application owners. Disabling or rotating a key can break services; preserve evidence and use the approved credential-response procedure. Review related access and persistence, not only the single key.

MITRE ATT&CK context

Additional Cloud Credentials (T1098.001) may apply when an adversary adds credentials to maintain access. A routine rotation is not sufficient evidence of that behavior.

Key takeaways

Define the account scope: define the question before broadening the search.
Compare scope and behavior: corroborate the explanation with independent evidence.
Keep the observed facts, assumptions and response decisions separate.

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

AmitVijayan 18:00:00 Add Comment

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.

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.

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.

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.

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

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.

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.

References

Microsoft: task creation event 4698

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

Investigating Unusual DNS Activity Without Overcalling Tunneling

AmitVijayan 10:00:00 Add Comment

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

Why it matters

Long domain names, frequent requests and failed lookups can draw attention, but each can occur in normal software. A useful DNS hunt connects the request to its process, device role and surrounding activity instead of labeling unusual strings as a covert channel.

Unusual DNS activity: investigation path. State a bounded hypothesis; Query candidate patterns; Resolver or endpoint DNS logs with timestamps, query names, types and response status.; Test normal explanations; Escalate; assess containment impact; Improve coverage — Original conceptual investigation workflow. No real customer data is shown.

Required telemetry and evidence

Resolver or endpoint DNS logs with timestamps, query names, types and response status.
Process creation and endpoint DNS telemetry with stable device/process identifiers where available.
Proxy or network connection evidence and approved software inventory.
Resolver coverage, collection filters, time synchronization and known encrypted-DNS visibility limits.

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

Step-by-step investigation

1. State a bounded hypothesis

Choose a device group and a behavior to investigate, such as repeated unusual queries from an unexpected process. Avoid a universal length threshold across servers, browsers and developer systems.

2. Check collection semantics

Determine whether the source records cached requests, failures and process attribution. Sysmon DNS events can record successful or failed process queries, including cached queries; do not assume resolver logs have identical semantics.

3. Query candidate patterns

Summarize query frequency, unique names, result status and time distribution. Retain representative records. Aggregation can conceal short bursts, and high uniqueness alone does not identify the content or purpose of a query.

4. Enrich with the process

Join on a supported stable process identifier and device, then review ancestry and the executable’s role. Time proximity alone is weaker evidence. Check whether a browser, security tool or approved agent explains the pattern.

5. Test normal explanations

Compare peers and version changes. Content-delivery, telemetry and service-discovery traffic can look machine-generated. Look for corroborating unexplained execution or network behavior before escalating.

6. Improve coverage

Document which request paths were visible. If encrypted DNS or unmanaged endpoints bypass the source, record the blind spot rather than treating no matches as a clean estate.

Unusual DNS activity: evidence checklist. Resolver or endpoint DNS logs with timestamps, query names, types and response status.; Process creation and endpoint DNS telemetry with stable device/process identifiers where available.; Proxy or network connection evidence and approved software inventory.; Resolver coverage, collection filters, time synchronization and known encrypted-DNS visibility limits. — Original conceptual evidence checklist. No real customer data is shown.

Read-only investigation pseudocode

INPUT authorized DNS event export
GROUP by device, attributed process, domain suffix and time window
SUMMARIZE request count, unique names and response status
COMPARE with role-specific peers
REVIEW unusual groups with process and connection evidence

Legitimate activity versus suspicious activity

An application update can introduce a new telemetry endpoint or a burst of failed service-discovery queries. Consistent behavior across approved peer devices supports that explanation. It does not automatically explain an unrelated process using the same domain suffix.

Tuning and false positives

Tune by software role, resolver source and expected query pattern. Keep exception owners and expiry dates. Avoid broad allowlisting of shared hosting domains or treating every newly seen domain as malicious.

Escalation, containment and documentation

Preserve candidate queries and correlated endpoint evidence internally. Escalate an unexplained behavior chain to the network/endpoint responder. Blocking a domain can disrupt shared services; validate impact and use the approved containment path.

MITRE ATT&CK context

DNS application-layer protocol use (T1071.004) applies when evidence supports adversary command-and-control over DNS. DNS anomalies alone do not justify that conclusion.

Key takeaways

State a bounded hypothesis: define the question before broadening the search.
Test normal explanations: corroborate the explanation with independent evidence.
Keep the observed facts, assumptions and response decisions separate.

References

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

Suspicious Inbox Rules: Investigating Intent, Scope and Delivery

AmitVijayan 18:00:00 Add Comment

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

Why it matters

A mailbox rule can organize legitimate work or silently redirect important messages. Finding a forwarding rule does not establish that mail left the organization. Investigate configuration, authorization and actual delivery as separate questions.

Inbox rule investigations: investigation path. Preserve the changed configuration; Query related changes; Mailbox and inbox-rule change audit events with actor, target and parameters.; Validate the business explanation; Escalate; assess containment impact; Record the outcome — Original conceptual investigation workflow. No real customer data is shown.

Required telemetry and evidence

Mailbox and inbox-rule change audit events with actor, target and parameters.
Current rule inventory, including hidden rules when supported by the authorized tooling.
Message trace or equivalent delivery evidence and relevant mailbox access/sign-in records.
Approved workflow documentation, destination ownership and mailbox delegation records.

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 changed configuration

Capture rule conditions, actions, enabled state and target mailbox. Include forwarding, redirecting, deleting or moving messages. Avoid changing the rule while collecting the first evidence snapshot unless urgent response authority requires it.

2. Identify who changed what

Resolve the user or application that initiated the operation. Check delegations and administrator activity. A familiar display name is insufficient to establish the actor’s identity or authorization.

3. Query related changes

Review creation, modification and mailbox-forwarding operations around the event. Include later changes that could make the current state differ from the state when the alert fired.

4. Establish delivery scope

Use message trace and available access records to test whether matching messages were processed and delivered. A configured external destination may be blocked by policy. Do not equate a rule definition with confirmed information disclosure.

5. Validate the business explanation

Confirm destination ownership and workflow using trusted contacts. A legitimate support mailbox can explain routing; an unexplained external address and unrelated sign-in anomalies require deeper review.

6. Record the outcome

Separate unauthorized configuration, attempted forwarding and verified delivery in the report. Record affected time ranges and evidence limitations so downstream decisions do not assume more than the records show.

Inbox rule investigations: evidence checklist. Mailbox and inbox-rule change audit events with actor, target and parameters.; Current rule inventory, including hidden rules when supported by the authorized tooling.; Message trace or equivalent delivery evidence and relevant mailbox access/sign-in records.; Approved workflow documentation, destination ownership and mailbox delegation records. — Original conceptual evidence checklist. No real customer data is shown.

Read-only investigation pseudocode

INPUT authorized mailbox-change and message-trace exports
SELECT rule or forwarding changes for the target mailbox
EXTRACT conditions, destination, actor and result
CORRELATE matching message delivery during the active interval
CLASSIFY configuration, attempted delivery and confirmed delivery separately

Legitimate activity versus suspicious activity

Rules used for ticketing, executive delegation and application notifications can be expected. Their scope should match the approved purpose. A broad rule affecting unrelated messages, silent deletion or an unowned destination weakens that explanation.

Tuning and false positives

Baseline rule purpose and destination ownership rather than rule names. Names can be misleading. Recheck exceptions after mailbox migrations and include both user rules and administrator forwarding settings in coverage.

Escalation, containment and documentation

Escalate confirmed unauthorized changes to the email-response owner. Disabling a rule, securing sessions and investigating related mailbox activity should follow the organization’s procedure. Preserve relevant delivery evidence before retention expires.

MITRE ATT&CK context

Email Forwarding Rule (T1114.003) is relevant when evidence supports adversarial email collection; a legitimate rule alone is not that technique.

Key takeaways

Preserve the changed configuration: define the question before broadening the search.
Validate the business explanation: corroborate the explanation with independent evidence.
Keep the observed facts, assumptions and response decisions separate.

References

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

Cyber News of the Day — September 10, 2026

AmitVijayan 12:07:00 Add Comment

September 10, 2026 | Breaches | Identity Security

Veradigm discloses patient-data theft through vendor API credentials

A recently disclosed healthcare breach highlights a practical question for defenders: how much data can a partner-held credential retrieve without touching the wider corporate network?

What is confirmed

In its September 8 filing, Veradigm says an unauthorized party obtained credentials from a third-party vendor's environment and used a limited company API to download patient personal information, including Social Security numbers in some cases. The company says no clinical or medical data was involved, broader systems were not accessible through those credentials, and operations were not disrupted. Its investigation and notifications were ongoing. These are the company's reported findings, not an independent forensic conclusion. Source: Veradigm Form 8-K, September 8.

The Record's September 9 coverage corroborates the disclosure and reports a separate criminal claim. We do not treat that claim as proof of attribution, patient count or the type of records stolen. Read The Record's coverage.

What remains unclear

The filing does not identify the vendor, provide a patient count or specify the dates of unauthorized downloads. A disclosure date is not necessarily the breach date. Avoid combining this incident with older Veradigm disclosures or interpreting limited network access as absence of data impact.

Conceptual sequence: vendor credentials obtained, limited Veradigm API accessed, and patient personal data downloaded, according to the September 8 company filing. — Original conceptual diagram based on the company disclosure; not a forensic reconstruction.

Why it matters to defenders

Analysis: Restricting an integration's network reach and restricting the data it can retrieve are separate controls. A narrowly exposed interface can still carry sensitive information. Review both the identity's permissions and the business purpose of the data access.

Practical checks for your environment

Inventory partner access. Identify vendor-held API credentials, accountable owners, permitted datasets and the process for revoking access. Do not collect secret values in a spreadsheet or case note.
Preserve relevant telemetry. Review authorized authentication and API audit records for identity, endpoint, time, result and available volume information. Document retention and missing fields before concluding that no unusual activity occurred.
Validate unusual retrieval. Compare requests with the approved job, expected dataset and partner confirmation through a trusted channel. A large batch may be legitimate; a familiar credential alone does not validate its operator.
Coordinate response. If comparable unexplained access appears, preserve evidence and involve identity, application, incident-response and privacy owners. Credential rotation or revocation should account for service dependencies and follow the approved response process.

These are general defensive recommendations, not findings about Veradigm's controls or instructions issued by the company. Affected customers should obtain incident-specific guidance through established vendor contacts.

Key takeaways

Separate confirmed company disclosures from criminal claims.
Assess accessible data as well as network boundaries.
Base response scope on evidence, not assumed patient counts or attribution.

Sources and editorial note

Reviewed September 10, 2026: Veradigm's September 8 SEC filing and The Record, September 9. This original brief uses public reporting. No private records or criminal-site material were accessed. Material changes will receive a dated correction note.

Investigating Unexpected MFA Method Changes: An Evidence-First Workflow

AmitVijayan 10:00:00 Add Comment

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

Why it matters

A new authentication method can change who is able to satisfy an account challenge. The same audit trail may also describe an ordinary phone replacement. Treat the change as an investigative lead: establish the initiating identity, the affected account and the explanation before making a compromise claim.

MFA method changes: investigation path. Scope the change; Query the surrounding sessions; Authentication-method audit events; Validate competing explanations; Escalate; assess containment impact; Document and improve — Original conceptual investigation workflow. No real customer data is shown.

Required telemetry and evidence

Authentication-method audit events: actor, target, activity, result and timestamp.
Interactive and non-interactive sign-in records, device context and authentication details where available.
Approved help-desk recovery records and the account owner’s confirmation through a trusted channel.
Current method inventory and the retention, ingestion delay and permissions of each evidence source.

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

Step-by-step investigation

1. Scope the change

Preserve the original event and its identifier. Distinguish an attempted registration, a successful registration, a deletion and a default-method change; they do not have identical consequences. Use a short initial window and expand it when the sequence demands it.

2. Reconstruct the actor and target

Resolve stable account identifiers rather than relying on display names. Determine whether the actor was the user, an administrator or an application. A privileged actor is relevant context, not an automatic explanation.

3. Query the surrounding sessions

Look for sign-ins before and after the change, noting authentication detail, device and application. IP location alone cannot establish the operator’s physical location. Separate event time from ingestion time when ordering the sequence.

4. Enrich with recovery evidence

Match the exact account and change time to a support ticket or device replacement. Contact the owner using a known channel, not contact details introduced by the questionable change. Record whether the explanation can be independently corroborated.

5. Validate competing explanations

Compare the method change with the normal registration process. An unexplained new method plus unfamiliar session activity deserves escalation; a confirmed support action with matching audit evidence may support closure. Missing records leave the case unresolved.

6. Document and improve

Record what changed, who authorized it and what remained uncertain. If a detection missed the activity, decide whether the gap is collection, parsing or logic before widening thresholds.

MFA method changes: evidence checklist. Authentication-method audit events: actor, target, activity, result and timestamp.; Interactive and non-interactive sign-in records, device context and authentication details where available.; Approved help-desk recovery records and the account owner’s confirmation through a trusted channel.; Current method inventory and the retention, ingestion delay and permissions of each evidence source. — Original conceptual evidence checklist. No real customer data is shown.

Read-only investigation pseudocode

INPUT authorized method-change audit export
FILTER successful changes within the investigation window
GROUP by stable target account identifier
CORRELATE actor and target with sign-in and recovery records
REVIEW unexplained changes; retain evidence and uncertainty

Legitimate activity versus suspicious activity

A planned device replacement may generate several registration and deletion events. A help-desk recovery may originate from a different administrator session. Neither should be judged using a single source IP. Conversely, a ticket with the wrong user or timing does not explain the observed change.

Tuning and false positives

Baseline self-service and administrator-assisted recovery separately. Review narrowly scoped exceptions by actor, target group and approved workflow. Avoid globally suppressing all registration events or all activity from help-desk accounts.

Escalation, containment and documentation

For unresolved high-risk changes, preserve the timeline and engage the identity-response owner. Session revocation, method removal and account recovery can interrupt legitimate access; perform them only under the approved response procedure and verify the account is securely restored.

MITRE ATT&CK context

Account manipulation may be relevant when evidence supports an unauthorized account change. Do not map a benign registration to adversary behavior solely because it appears in an audit log.

Key takeaways

Scope the change: define the question before broadening the search.
Validate competing explanations: corroborate the explanation with independent evidence.
Keep the observed facts, assumptions and response decisions separate.

References

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

Threat Hunting for LOLBins: A Practical EDR Guide to Detecting Suspicious Living-Off-the-Land Activity

AmitVijayan 19:31:00 Add Comment

Living-off-the-land activity is difficult to assess because familiar software can appear in both ordinary administration and an intrusion. An EDR event for rundll32.exe or PowerShell is a starting observation, not a conclusion. The defender’s job is to explain why that process ran, what it touched and whether the sequence fits the environment.

This guide presents a repeatable approach for SOC analysts, threat hunters and incident responders working in authorised Windows environments. It contains defensive searches and fictional examples, with no payloads or instructions to compromise systems.

What are LOLBins and LOLBAS?

LOLBins is shorthand for legitimate binaries whose capabilities can be misused as part of an attack. LOLBAS broadens that lens to binaries, scripts and libraries. The software may be trusted or signed, but that does not make every invocation trustworthy. Conversely, appearing in a hunting list does not make a utility malicious.

The public LOLBAS project maintains a catalogue of documented capabilities and associated ATT&CK mappings. Use it to inform investigation coverage, not as a list of process names to block indiscriminately. A technique mapping should reflect observed behaviour, not merely the executable present in an event.

01 · Same utility, different context

Expected workflowApproved management process↓ Known utility and approved input↓ Expected destination and timingConfirm against change records

Investigate furtherUnexpected document parent↓ Utility references unfamiliar input↓ Unexplained network or file activityCorrelate before deciding

Original diagram: context changes the investigative priority. Neither column proves a verdict by itself.

Build a hypothesis before writing a query

Start with a bounded statement: “On ordinary office workstations, a document application starting a native utility and producing unexplained network activity may indicate an unapproved workflow.” Define the device group, time range, expected business uses and evidence that would weaken that hypothesis.

03 · A repeatable hunting loop

1 · Telemetry →Verify coverage and time range

2 · Hypothesis →Define an unexpected behaviour

3 · Query →Find a manageable candidate set

4 · Enrichment →Add endpoint and business context

5 · Validation →Test benign and suspicious explanations

6 · Improve ↺Document, tune and review coverage

Original workflow diagram. A visibility gap is a valid outcome and should feed the next iteration.

Identify candidate utilities. Choose a small set relevant to your estate. Include their legitimate owners and workflows in the hunt plan.
Establish a baseline. Compare use by device role, parent process, account and change window. A maintenance server and a finance workstation should not share one undifferentiated baseline.
Examine ancestry. Review the direct parent and surrounding process tree. Establish whether an approved tool explains the chain.
Read the arguments. Review paths, input files and destinations in context. Unfamiliar arguments merit investigation but are not proof; do not execute a captured command to find out what it does.
Correlate evidence. Connect process activity with network, file, registry, identity and persistence events using stable identifiers where available.
Enrich and validate. Check change records, file provenance, approved software inventories and relevant intelligence. Keep competing explanations visible.
Document the result. Record an explained benign workflow, a supported escalation or a coverage gap. Turn only validated patterns into detection candidates.

02 · Read the process tree as a story

Approved installer

↓

regsvr32.exe

↓

Known component registration
Documented update

winword.exe

↓

powershell.exe

↓

Unexpected child process
Business reason not established

Original conceptual example, not a vendor screenshot. Parent-child relationships are leads to investigate, not automatic maliciousness labels.

Six utilities: legitimate use and investigative context

PowerShell

Expected use: administration, configuration and approved automation. Investigate: an unusual parent, an unexplained script location, unexpected child processes or network destinations outside the normal workflow. An approved job, known script provenance and matching change record reduce concern; a document-origin chain with corroborating anomalies increases it. ATT&CK reference: T1059.001.

rundll32.exe

Expected use: invoking functionality exposed by DLLs, including system and application components. Investigate: unfamiliar referenced modules, unusual execution ancestry and related file or network activity. Verify the module path and provenance as well as the utility itself. A known component in a documented workflow supports a benign explanation; an unexplained module in a user-writable location warrants closer review. ATT&CK: T1218.011.

regsvr32.exe

Expected use: registering and unregistering supported components during installation or maintenance. Investigate: execution outside deployment windows, unexpected parents and unfamiliar component references. Correlate the installation record and module origin. The binary’s valid signature does not establish the legitimacy of the content it is asked to handle. ATT&CK: T1218.010.

mshta.exe

Expected use: running legacy HTML applications where an organisation still depends on them. Investigate: use on devices without an identified business need, unrecognised input, unusual child processes and related network events. Confirm whether a legacy application explains the activity before deciding. ATT&CK: T1218.005.

certutil.exe

Expected use: certificate-related administration and other diagnostic operations. Investigate: activity whose file inputs, outputs or destinations do not fit a certificate or support workflow. Check what was produced and whether another process subsequently used it. A documented certificate task lowers concern; an unexplained transfer followed by further execution raises it. Map evidence to T1105 for adversary tool transfer or T1140 for relevant decoding behaviour, rather than mapping every invocation.

bitsadmin.exe

Expected use: management of Background Intelligent Transfer Service jobs, including legacy administrative workflows. Investigate: unexpected job owners, destinations, transferred files or follow-on activity. Check job metadata and the service context: the network connection may be recorded under a service process, not the command-line utility. Approved software delivery can explain transfers; unknown jobs with unexplained follow-on behaviour deserve escalation. ATT&CK: T1197.

04 · Build an evidence chain

Process instance + device + time window

↔ Command lineInput, path and stated purpose

↔ NetworkDestination, outcome and timing

↔ FilesOrigin, hash and subsequent use

↔ RegistryWhat changed and who initiated it

↔ IdentityUser, session and expected role

↔ PersistenceTasks, services and autorun evidence

Original correlation diagram. A nearby event is not necessarily caused by the process being investigated.

Defensive Falcon / LogScale sample queries

Read this before using the examples.

These examples target CrowdStrike Query Language (CQL) in Falcon environments using LogScale-style search. They are not legacy Splunk-style Event Search queries. Field names, event schemas and syntax vary by deployment, sensor version and source. The examples were reviewed against public documentation, not executed in a Falcon tenant. Test and adapt them in an authorised environment.

Start with a short time range in the console, such as 24 hours, and a known device group. Confirm that process and network events exist. Check whether your dataset uses tagged #event_simpleName, whether parent names and user fields are populated, and whether paths use the expected separator. Empty results can mean missing telemetry, parser differences or an overly narrow scope.

Query 1 — inventory the selected utilities

#event_simpleName=ProcessRollup2 event_platform=Win
| ImageFileName=/\\(powershell|pwsh|rundll32|regsvr32|mshta|certutil|bitsadmin)\.exe$/i
| table([@timestamp, aid, ComputerName, UserName, ParentBaseFileName,
    ImageFileName, CommandLine, TargetProcessId])

This establishes a candidate set from full image paths. It is not a malicious-activity detector. Confirm the returned fields, inspect representative events and compare with known administrative activity. Renamed binaries and execution outside this list are outside its coverage.

Query 2 — inspect unusual document parents

#event_simpleName=ProcessRollup2 event_platform=Win
| ImageFileName=/\\(powershell|pwsh|rundll32|regsvr32|mshta|certutil|bitsadmin)\.exe$/i
| ParentBaseFileName=/^(winword|excel|powerpnt|outlook)\.exe$/i
| table([@timestamp, aid, ComputerName, ParentBaseFileName,
    ImageFileName, CommandLine, TargetProcessId])

This looks for a specific parent-child pattern. Investigate the document workflow and full ancestry. It misses intermediate processes and legitimate integrations can match. Use the process-tree view to test the hypothesis rather than treating every returned row as an incident.

Query 3 — find low-frequency parent and image combinations

#event_simpleName=ProcessRollup2 event_platform=Win
| ImageFileName=/\\(rundll32|regsvr32|mshta|certutil|bitsadmin)\.exe$/i
| groupBy([ParentBaseFileName, ImageFileName], function=count(as=Executions), limit=10000)
| Executions <= 3
| sort(Executions, order=asc)

The threshold of three is illustrative. Counts refer to matching events in the selected scope and period, not global prevalence or unique hosts. Choose a baseline appropriate to your estate and account for duplicate events, collection gaps and new deployments. Check aggregation limits and partial-result warnings; rare results are not automatically suspicious.

Query 4 — correlate utility processes with IPv4 network events

#event_simpleName=NetworkConnectIP4 event_platform=Win
| join(query={
    #event_simpleName=ProcessRollup2 event_platform=Win
    | ImageFileName=/\\(rundll32|regsvr32|mshta|certutil|bitsadmin)\.exe$/i
  }, field=[aid, ContextProcessId], key=[aid, TargetProcessId],
  include=[ImageFileName, CommandLine, ParentBaseFileName], mode=inner)
| table([@timestamp, aid, ComputerName, ImageFileName,
    ParentBaseFileName, CommandLine, RemoteAddressIP4, ContextProcessId])

The association uses device ID aid plus Falcon process identifiers: network ContextProcessId and process TargetProcessId. Do not substitute a raw operating-system PID without validating its semantics. Review both event times and the connection outcome in your schema.

This query excludes unmatched network events. Join limits or an insufficient process-search window can hide matches, especially when a process started before the selected period. It covers IPv4 only and does not capture every DNS, IPv6, proxy, child-process or service-mediated action. A BITS transfer may therefore need job and service telemetry instead. Query matches show correlation, not proof of command-and-control or data theft.

How to tune this query set

Build exceptions from verified workflows, not convenient labels. For an approved deployment, record the owning team, expected parent, component or script identity, relevant device group, account and change window. Review exceptions periodically and retain a way to investigate deviations.

Scope known deployment tools to their expected paths, publishers and activity; avoid an unconditional allowlist for every child they launch.
Validate approved scripts and inputs. A trusted interpreter does not make an arbitrary script trusted.
Use expected service accounts as context, not a blanket exclusion. Investigate interactive or out-of-pattern use.
Separate server, workstation and administrative baselines, and revisit them after migrations or software changes.
Test known benign records and safe, labelled lab records. Measure noise and missed coverage before scheduling a detection.

A fictional triage example

A document application starts a listed utility on a workstation. The event is uncommon, but the owner identifies a reporting add-in. A matching change record, known input and consistent peer-device behaviour support closing it as an explained workflow. In a second case, there is no matching workflow, the input is unfamiliar and correlated file activity remains unexplained. Preserve the timeline and escalate the evidence; do not label the case confirmed compromise solely because the utility appears in LOLBAS.

Turn a hunt into an improvement

A useful report records the hypothesis, scope, data coverage, query version, relevant evidence, competing explanations and final disposition. Keep sensitive command lines and customer details in approved internal systems rather than public examples.

Before promoting a hunt to a detection, establish an owner, review thresholds, test representative benign activity and define what an analyst should do with the result. Sometimes the best outcome is a logging improvement or a clarified software inventory, not another alert. If containment is warranted, follow the organisation’s approved incident-response process.

References and further reading

LOLBAS project — maintained capability catalogue.
MITRE ATT&CK — individual technique references are linked in the utility sections.
LogScale join documentation and groupBy documentation — verify syntax and limits for your version.
CrowdStrike public LogScale community content — event-correlation examples and schema context.

Text and four conceptual diagrams created for Hack Invasion. No vendor-console screenshots or third-party graphics are reproduced.

PowerShell Threat Hunting: Two Practical KQL Examples

AmitVijayan 17:46:00 Add Comment

PowerShell threat hunting works best when a query tests a specific question. A PowerShell process alone is not evidence of compromise: administrators and management tools use it every day. The useful question is whether its parent process, user, timing and network activity fit the device’s normal role.

This guide uses hypothesis-driven threat hunting to investigate two patterns with Microsoft Defender XDR advanced hunting. The examples are fictional teaching scenarios, not accounts of real incidents. The queries are read-only starting points; they have not been executed against a live tenant and need validation against your environment.

The technique: start with a testable hypothesis

A hypothesis states what suspicious behaviour might look like and what evidence would support or weaken that explanation. Write it before searching, define the devices and time range, then compare the results with normal activity.

Define: describe the behaviour and the business context in which it would be unexpected.
Collect: check that the necessary endpoint events exist for the devices and period.
Investigate: connect process, account and network evidence instead of treating a query match as a verdict.
Conclude: record a supported finding, an explained benign result, or an unresolved visibility gap.

MITRE ATT&CK maps adversary use of PowerShell to T1059.001. That mapping describes a behaviour; it does not establish that an individual PowerShell execution is malicious.

Before running the queries

You need access to advanced hunting and relevant Defender for Endpoint telemetry. Microsoft documents DeviceProcessEvents for process activity and DeviceNetworkEvents for network activity. Check the in-portal schema and event coverage before interpreting results.

The queries use a seven-day window as a starting point. Adjust it to your retention, permissions and investigation scope. If the tables return no recent events for a known active device, resolve that visibility gap first. An empty result is not proof that a device is clean.

Example 1: an Office application launches PowerShell

Hypothesis: a document application launching PowerShell may indicate unexpected script execution on a workstation where that workflow is not normally used.

DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where InitiatingProcessFileName in~ (
    "winword.exe", "excel.exe", "powerpnt.exe", "outlook.exe")
| project Timestamp, DeviceId, DeviceName, AccountName,
    InitiatingProcessFileName, InitiatingProcessCommandLine,
    FileName, ProcessCommandLine, ProcessId, ProcessCreationTime
| order by Timestamp desc

This finds direct parent-child relationships. It will miss chains with an intermediate process, renamed executables and execution not captured by the sensor. Expand the investigation through the device timeline rather than assuming this query covers every PowerShell technique.

A fictional investigation

On FIN-LAPTOP-07, Word launches PowerShell shortly after a user opens a document. The parent relationship is unusual for this device, but it is only the starting observation.

Review the full process tree and command line. Establish which document and workflow preceded the process where telemetry allows.
Check the user’s role, relevant support activity and whether an approved document integration explains the behaviour.
Look for nearby file creation, child processes and network events associated with the same process instance.
Compare with similar workstations and earlier activity. Ask whether this is a new pattern or a known business workflow.

If an unapproved document launch is followed by an unexplained script and related external communication, preserve the evidence and escalate through the incident-response process. If a verified reporting add-in explains the chain and the activity matches an approved change, document that explanation. Neither the parent name nor the user’s recollection is sufficient on its own.

False positives and tuning

Reporting tools, document automation and support workflows can produce legitimate matches. Use narrow exceptions tied to a verified workflow and review date. Avoid excluding every PowerShell process launched by an entire user group: that would hide unrelated activity.

Example 2: PowerShell makes an unfamiliar network connection

Hypothesis: PowerShell network activity deserves closer review when the destination and initiating command do not fit the device’s expected administrative tasks.

DeviceNetworkEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("powershell.exe", "pwsh.exe")
| where isnotempty(RemoteIP) or isnotempty(RemoteUrl)
| project Timestamp, DeviceId, DeviceName, ActionType,
    RemoteUrl, RemoteIP, RemotePort,
    InitiatingProcessAccountName, InitiatingProcessCommandLine,
    InitiatingProcessId, InitiatingProcessCreationTime
| order by Timestamp desc

This returns observed network events, not a list of malicious destinations. Review ActionType to distinguish the recorded outcomes; do not assume every row represents a successful connection. A blank RemoteUrl also does not mean the destination was harmless or that no network activity occurred.

A fictional investigation

On OPS-WS-12, PowerShell contacts a destination absent from the team’s approved automation inventory. Its unfamiliarity makes it worth investigating; it does not prove command-and-control activity.

Identify the exact process instance using the device, process ID and process creation time. A process ID by itself can be reused.
Inspect its parent process and full command line in the endpoint timeline. Determine whether a scheduled task, management agent or interactive user initiated it.
Review the destination in approved DNS, proxy and threat-intelligence tools. Treat reputation as one signal, not a final verdict.
Compare the timing with change records and other devices performing the same task. Correlate relevant file and child-process events.

Suppose the endpoint owner supplies an approved inventory job and its destination and timing match the evidence. That supports a benign conclusion. If the command, destination and process chain remain unexplained, record the uncertainty and escalate with the supporting timeline. Do not open a suspicious destination from a normal workstation just to investigate it.

False positives and coverage limits

Software maintenance and cloud administration can legitimately use PowerShell networking. This query does not automatically calculate rarity, prove data transfer or identify what was sent. Connections made by a child process may appear under that child instead. Use an appropriate historical baseline and additional telemetry to answer those questions.

What a useful hunt report should contain

Scope: hypothesis, dates, devices and data sources checked.
Evidence: timestamps, process relationships and relevant events, with sensitive details handled under your organisation’s rules.
Assessment: what supports the finding, what weakens it and what remains unknown.
Disposition: escalate, close with a documented benign explanation, or assign a follow-up for missing visibility.
Improvement: a logging fix, a narrowly scoped exception or a candidate detection to validate.

Validate a candidate detection with labelled benign and suspicious examples in an authorised environment before turning a hunt into an alert. Review the query’s coverage and false positives with the SOC; these examples are not ready-made production detection rules.

Common questions

Does unusual PowerShell activity always mean compromise?

No. Investigate the complete sequence and business explanation. Suspicion becomes more useful when several independent observations support it.

What if the hunt returns no results?

Confirm device onboarding, permissions, event availability and the time range. Then record that this specific search found no matches within its coverage, rather than claiming there was no malicious activity.

Can I use this technique with another SIEM?

Yes. Map the same questions to your process and network logs. The KQL shown here depends on the Defender schema and will need adaptation for other datasets.

For more defensive learning, browse the Knowledge Base Articles. To practise communicating evidence and risk, read the PSIRT interview preparation guide.

Practical Cybersecurity Knowledge for Defenders.

Find your next learning path.

Product security

Web security

Wireless security

Research & usability

Latest articles & news

Why it matters

Required telemetry and evidence

Step-by-step investigation

1. Validate the finding

2. Read the vendor guidance

3. Establish reachability

4. Check exploitation evidence

5. Assign a defensible priority

6. Verify remediation

Read-only investigation pseudocode

Legitimate activity versus suspicious activity

Tuning and false positives

Escalation, containment and documentation

MITRE ATT&CK context

Key takeaways

Related articles

References

Why it matters

Required telemetry and evidence

Step-by-step investigation

1. Define the account scope

2. Find successful creation

3. Review expected purpose

4. Trace observed use

5. Compare scope and behavior

6. Record and improve

Read-only investigation pseudocode

Legitimate activity versus suspicious activity

Tuning and false positives

Escalation, containment and documentation

MITRE ATT&CK context

Key takeaways

Related articles

References

Why it matters

Required telemetry and evidence

Step-by-step investigation

1. Preserve the task definition

2. Resolve registration context

3. Review action and trigger

4. Find execution evidence

5. Validate ownership

6. Document a lifecycle

Read-only investigation pseudocode

Legitimate activity versus suspicious activity

Tuning and false positives

Escalation, containment and documentation

MITRE ATT&CK context

Key takeaways

Related articles

References

Why it matters

Required telemetry and evidence

Step-by-step investigation

1. State a bounded hypothesis

2. Check collection semantics

3. Query candidate patterns

4. Enrich with the process

5. Test normal explanations

6. Improve coverage

Read-only investigation pseudocode

Legitimate activity versus suspicious activity

Tuning and false positives

Escalation, containment and documentation

MITRE ATT&CK context

Key takeaways

Related articles

References

Why it matters

Required telemetry and evidence

Step-by-step investigation

1. Preserve the changed configuration

2. Identify who changed what

Practical Cybersecurity
Knowledge for Defenders.