Hack Invasion

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.

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

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.

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.

PSIRT Interview Preparation: CVSS, CWE and Scenarios

AmitVijayan 15:54:00 Add Comment

Preparing for a PSIRT interview? Practise explaining how you would take a vulnerability report from initial evidence to a validated fix and a clear customer advisory. Knowing a CVSS score helps; being able to defend your reasoning is what makes an answer useful.

In my own preparation, the most useful shift has been to separate what a scenario proves from what I would investigate next. This guide turns that approach into a repeatable framework for candidates moving from SOC, incident response or security engineering into product security.

By Amit Vijayan · September 6, 2026. These are original practice exercises and study notes, not a record of any employer’s interview questions.

What does a PSIRT do?

A Product Security Incident Response Team coordinates the handling of vulnerabilities in an organization’s products. Its work can include receiving reports, working with engineering to validate issues, assessing severity, coordinating remediation and communicating with researchers and customers. FIRST’s PSIRT Services Framework is a useful starting point for understanding this lifecycle.

For interview preparation, distinguish the product perspective from your operational response experience. A SOC investigation may ask whether an attacker compromised an environment. A PSIRT investigation also asks which product versions and configurations are affected, how engineering can remove the weakness, and what customers need to know. The teams can collaborate; their responsibilities depend on the organization.

A practical framework for PSIRT technical answers

I use the following sequence as a rehearsal tool. It keeps an answer structured without turning it into a memorized speech.

Restate the evidence. Identify the affected feature, input, required access and observed behaviour. Separate confirmed facts from assumptions.
Explain the mechanism. Trace attacker-controlled input into the vulnerable operation. Name the root cause before describing the consequence.
Bound the impact. Establish the execution context and what data or service can actually be affected.
Classify and score. Choose the most specific supported CWE and justify the CVSS metrics using the requested version.
Validate safely. Describe a representative, authorized lab and the telemetry needed to confirm or reject your hypothesis.
Fix and communicate. Address the underlying design, test the correction, identify affected releases and explain customer actions.

A useful sentence to practise is: “That is my initial assessment from the evidence provided; I would validate these assumptions before finalizing the impact and severity.” Follow it with the specific missing evidence. Uncertainty is useful when it produces a concrete investigation plan.

How to prepare for CVSS 3.1 and CVSS 4.0 questions

CVSS expresses vulnerability severity. A score alone does not tell you which issue a particular organization should address first. Explain the vector, then discuss exposure, exploitation evidence, customer impact and operational constraints separately.

CVSS 3.1: explain each decision

Practise Attack Vector, Attack Complexity, Privileges Required, User Interaction, Scope and confidentiality, integrity and availability impacts. Scope concerns a change in security authority; crossing a process boundary does not automatically establish it. Use the FIRST CVSS 3.1 specification to check definitions rather than relying on shorthand.

CVSS 4.0: do not translate the vector mechanically

Version 4.0 includes Attack Requirements and separates impacts to the vulnerable system from impacts to subsequent systems. It no longer uses the 3.1 Scope metric. Review the Base, Threat, Environmental and Supplemental metric groups in the CVSS 4.0 user guide. Supplemental metrics provide additional context without changing the calculated score.

For practice, explain what evidence supports each metric before opening the official calculator. Avoid guessing a decimal score from memory. Where the scenario leaves an important fact unresolved, state the assumption and show how a different answer could change the vector.

CVSS, EPSS and KEV answer different questions

CVSS: how severe is the vulnerability under the scoring assumptions?
EPSS: what is the estimated probability that a published CVE will be exploited in the wild in the next 30 days? See FIRST’s EPSS overview.
CISA KEV: is the vulnerability listed as known to have been exploited? Use the Known Exploited Vulnerabilities Catalog as an input to prioritization.

An issue’s absence from KEV is not proof that it has never been exploited. In a prioritization exercise, I would also ask whether the affected component is reachable, enabled and used in a critical customer workflow.

Worked example: reasoning about OS command injection

Fictional practice scenario: an authenticated user can submit a value to a product’s diagnostics feature. Engineering confirms that the value reaches an operating-system command without adequate separation between data and command syntax. A harmless lab test causes an unintended command to run as the diagnostic service account.

1. Separate root cause, weakness and impact

Root cause: unsafe construction of an OS command using attacker-controlled input.
Weakness: OS command injection, consistent with CWE-78.
Demonstrated impact: unintended command execution with the diagnostic service’s privileges.

“The attacker can execute commands” describes the consequence. It does not explain the programming error. Naming the unsafe operation makes the remediation discussion more precise.

2. Ask what the service account can actually affect

Before assigning high confidentiality, integrity and availability impacts, I would ask:

Which sensitive files, secrets or records can the service read?
Which data, configuration and executable files can it modify?
Can it disrupt an essential service, and how complete or persistent is that disruption?
What restrictions are imposed by its account, container, filesystem and network policy?
Is there evidence of impact beyond the vulnerable system?

Do not claim privilege escalation, lateral movement or a complete takeover solely because command execution is possible. Those conclusions need evidence about the actual execution context.

3. Describe the evidence and reproduction plan

In an authorized isolated lab, first record normal diagnostic behaviour on an affected version and configuration. Then use a benign test that demonstrates the unintended execution without collecting secrets or disrupting service. Correlate the application request with process-execution telemetry, including the parent process, account and resulting activity. Record the exact conditions and the observation that distinguishes the vulnerable path from normal behaviour.

After remediation, repeat the test and verify that legitimate diagnostics still work. Include regression cases that exercise the unsafe input-handling pattern, not just one originally reported input.

4. Propose a fix that addresses the mechanism

Prefer eliminating shell-command construction in favour of an appropriate library or safe process-execution interface. Keep executable selection controlled, validate allowable arguments and run with least privilege. Passing arguments separately helps avoid shell interpretation, but does not automatically prevent unsafe options or argument injection; the called program’s behaviour still matters. MITRE’s CWE-78 guidance discusses prevention and mitigation approaches.

5. Deliver a concise interview answer

“The evidence supports OS command injection caused by unsafe command construction in the diagnostics feature. The demonstrated impact is command execution as the service account. I would establish that account’s access before finalizing the impact metrics, document the affected configuration, and correlate the request with process telemetry in a controlled lab. I would work with engineering to remove the unsafe execution pattern, then verify both the fix and normal diagnostic behaviour.”

PSIRT interview questions to practise

How would you handle an incomplete vulnerability report?

Explain what you can confirm, then request focused information: product and version, configuration, prerequisites, expected versus observed behaviour, reproduction steps and supporting evidence. Describe how you would track the case and keep the reporter informed. Avoid asking for a large, unfocused collection of logs.

How would you assess a denial-of-service report?

Trace the triggering input to the processing behaviour, constrained resource and observed service degradation. In your proposed lab, distinguish node-local failure from cluster-wide impact. Explain how you would observe recovery, failover and the effect on legitimate requests. Define limits and stop conditions before any load testing.

What if engineering disagrees with your severity assessment?

Walk through the disputed assumptions one metric at a time. Identify the observation that would resolve the disagreement and record the rationale. Discuss customer prioritization separately from the technical severity score. A defensible shared assessment is more useful than winning an argument over a number.

What belongs in a customer security advisory?

Cover the affected products and versions, prerequisites, impact, identifier where assigned, severity rationale, fixed releases, practical mitigations and update history. Distinguish confirmed facts from investigation status. FIRST’s PSIRT framework describes disclosure coordination and advisory responsibilities.

How would you coordinate disclosure?

Discuss communication with the reporter, engineering and relevant product stakeholders; a shared plan for remediation and publication; and how changing exploitation evidence would affect urgency. Avoid presenting a single deadline as universally correct. Practise explaining how you would handle dependencies or multiple affected vendors.

How does incident response experience help in PSIRT?

Bring a real example of evidence collection, competing hypotheses, prioritization or stakeholder communication. Explain your own contribution and the result. Then connect that experience to product investigation, fix validation or advisory writing. Use only details you are entitled to share.

A seven-day PSIRT interview preparation plan

Day 1 — Map the role. Read the PSIRT framework and draw a vulnerability report’s path from intake to disclosure.
Day 2 — Classify weaknesses. Pick three public advisories. Separate the root cause, CWE and demonstrated impact for each.
Day 3 — Practise CVSS. Build vectors using the official definitions and calculator. Explain the assumptions aloud.
Day 4 — Plan validation. Write a safe reproduction plan, required telemetry and pass/fail criteria for a fictional issue.
Day 5 — Write an advisory. Summarize a public, already-fixed vulnerability in language a customer can act on.
Day 6 — Rehearse collaboration. Prepare examples of resolving disagreement, working under uncertainty and communicating risk.
Day 7 — Run a mock interview. Give a two-minute assessment, then let a partner challenge your assumptions. Revise the weak reasoning.

A final self-check before the interview

Can you explain the unsafe operation, the evidence supporting impact, the missing information, the validation method and the fix? Can you give a customer a clear next step? If you can do those things without relying on memorized claims, your preparation is moving in a useful direction.

For my professional background, visit About Amit Vijayan or connect with me on LinkedIn.

A Usability Study On Ubuntu Operating System and Third Part Software Manager Using the Cognitive Walkthrough Method

AmitVijayan 13:20:00 Add Comment

A Usability Study On Ubuntu Operating System and Third Part Software Manager Using the Cognitive Walkthrough Method

Abstract

Operating system – As name self explains, it manages the operation between Computer hardware and software resources. Application program is one of the components of operating system. Application program requires operating system to function. Major operating system are Linux operating system, Windows operating system, Mac.

Ubuntu is an open-source Linux operating system, which is based on debian stable Linux distribution. Currently Ubuntu run across platforms such as laptops/desktops, servers and mobiles. Linux is similar to Unix but was developed without any Unix Code. Linux is an open license model, which has a general public license in which the Linux kernel code is available for studying and modification. Some of the popular Linux distributions are, red hat, Ubuntu, Linux mint, kali.

Introduction

How to install a third party software is one of the major tasks carried out in any operating system. The approach and procedure is different for the major operating system distributions, say windows, Linux and mac. So let’s walkthrough along to install a third party software in Ubuntu operating system which is based debian Linux distributions. Ubuntu comes with a default list of useful programs. However, most of the times, a specific software for serving the specific purpose is needed which is not served by default applications.

Software is a program which can be run on computer. However, for the smooth run of this software, it requires other resources in the operating system to work for it. So there are hundreds of files required just to make the program work. Upon that, the files has to be loaded onto the right locations, depending on different operating system architecture. Ubuntu stores all the needed files into a package, which has to be run. Thus package combines all files into a single file, which can be handled more easily.

Core tasks during the cognitive walkthrough are:

1. Validation of the software and installation of the system software.
2. Configuration of the fundamental services for the smooth and efficient run of the operating system.
3. The right way to start up and shutdown the operating system.
4. General Installation procedure for a user application.

Usability Guidelines

Guidelines used to evaluate the core task are as follows:

G1 - Users should be aware of the steps they have to perform to complete a core task.

G2 - Users should be able to determine how to perform these steps.

G3 - Users should know when they have successfully completed a core task.

G4 - Users should be able to recognize, diagnose, and recover from non-critical errors.

G5 - Users should not make dangerous errors from which they cannot recover.

G6 -Users should be comfortable with the terminology used in any interface dialogues or documentation.

G7 - Users should be sufficiently comfortable with the interface to continue using it.

G8 - Users should be aware of the application’s status at all times.

Ubuntu Operating System Installation:

The latest version of Ubuntu is 16.04.1 and is downloaded from the Ubuntu website. There are a couple of requirements to be met before kick starting the installation procedure. Validation of the software to check its health is important to start on. At times there are possibilities a software download can go corrupted. At the outset, if the hardware requirements fail, there is no point in continuing the installation, else if continued, the system would throw various errors during the operation of the system. Once this is met, the user interface of Ubuntu guides the user step by step. [G1,G3]

Ubuntu offers two types of installing the operating system

1. To externally install alongside another operating system

2. To inside the same operating system.

The advantage of installing inside an operating system is that, the files of the base operating system can be accessed through Ubuntu as it is. Therefore, by saving the switch over time between the operating systems and help solve duplicating the dataset. The next important aspect to be noted is the file system of Ubuntu. As in general NTFS/ fat 32 is used by Windows, likewise Ubuntu Linux considers ext3, ext4, ext5 as its file system. This is one of the critical step, a user should be aware of, as there are possibilities to lose valuable data in the hard disk. One of of the possibilities is, a user tends to have couple of operating systems to work on his machine. It is very important to know the number of partitions in the hard disk and its sizes. If confused with the partition name and formatted, then the user losses all data in that partition. After setting up these, the control shifts back to the system software to extract and copy the system files. Once done, asks the user to restart the operating system now or later, to complete the installation process.[G2,G5]

Configuration: Once the installation is done it is necessary to check for the available updates for the system. Configure default settings and preferences of audio, video, network applications. One of the good feature of Ubuntu is the use of terminal for most of the activities. Whether to update, install, traverse files terminal is a handy tool used extensively. [G8]

Installing Software

Role of binary file - Let’s look into the importance of the source code and binary file for installing a software. Generally, when a package is created, for a particular software or program, source code will be stored, for the program in the package. Source code is nothing but a set of instructions for the computer, in order to execute the software, which is written in human readable language. Machines cannot understand this human native-language and hence the need to interpret the source code. This task is taken care by interpreter or compiler. One of the best ways of achieving this is by converting the source file into a binary file, in which machines can understand. Binary packages are ones which have been made specifically for one type of computer, or architecture. [G1]

Package Dependencies – Sometime a program needs same file to support the installation of its own software. Instead of storing each file into each package, a separate package can be installed to provide, so that any program in need of that file, can use them directly. So, to install a program which needs one of these files, the package containing those files must also be installed. When a package depends on another in this way, it is known as a package dependency. By specifying dependencies, packages can be made smaller and simpler, and duplicates of files and programs are mostly removed. When we install a program, its dependencies must be installed at the same time. Usually, most of the required dependencies will already be installed, but a few extras may be needed. [G1,G5]

Package Managers - A package manager is an application which comes along with the operating system which deals with the downloading and installation of packages. Ubuntu includes a couple of package managers by default, and which we use depends on how advanced the package management tasks are that we want to achieve. The basic package manager, we are going to use here is the Add/Remove tool, which is very easy to use.[G1]

Repositories - Ubuntu stores all its packages at a location called repositories. Repository stores packages of similar types, which can be downloaded and installed using a package manager. A package manager will store an index of all of the packages available from a repository/ software channel. At times the index are rebuilt, to make sure that it is up to date and knows which packages have been upgraded or added into the channel since it last checked. In addition to the official Ubuntu repositories, it is possible to use third party repositories. Be careful, though - some are not compatible with Ubuntu and using them may cause programs to stop working or may even cause serious damage to your installation. [G6]

Installing a Package - This section explains how to install packages using the various tools available in Ubuntu. [G1,G6]

· Graphical method

· Text Based Methods (Terminal)

Let’s walkthrough the graphical method first. Not all the packages can be installed through graphical method. For such packages, text based methods are suitable. In Ubuntu we find most of the packages at "Software Centre ". Software from additional repositories may be installed. Once this has finished, click Close. Our new programs are installed and are ready to use.

Advanced graphical method - The Synaptic package manager is a more user friendly method for installation of the software packages. If any problem in finding the package with Add/Remove tool, we need to try using the search in Synaptic.[G6]

Text Based Methods - Text based methods demands the knowledge of how to use the terminal and its commands. While install packages, we should consider using an AptURL over apt-get or aptitude.[G5]

Aptitude - the text-based method - Aptitude is a text-based package manager, which must be run from a Terminal.

apt-get method

The apt-get program is a command-line package manager, which should be used if the Add/Remove tool and Synaptic ever run into problems. It provides an advanced interface to APT, the underlying package management system which Ubuntu uses, but is reasonably easy to operate.

Installing downloaded packages

We may wish to install a package you have downloaded from a website, rather than from a software repository. These packages are called .debfiles. GDebi is a simple tool to install .deb files. It has a graphical user interface but can also be used in terminal. It lets us to install local deb packages resolving and installing its dependencies. It automatically checks packages for their dependencies and will try to download them from the Ubuntu software repositories if possible. We may first need to install GDebi - simply install the gdebi package using one of the package managers listed above, or open a Terminal and type sudo apt-get install gdebi.

Double-click the package to open it with GDebi. If all dependencies have been met for the selected package, click the 'Install package' button to install it. GDebi will warn, if there are unmet dependencies, which means that there's dependencies that aren't resolved in the repositories that we are using. If all met and resolved, the software is installed and ready to use.[G1,G4,G6]

Practical Cybersecurity Knowledge for Defenders.

Find your next learning path.

Product security

Web security

Wireless security

Research & usability

Latest articles

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

3. Query related changes

4. Establish delivery scope

5. Validate the business explanation

6. Record the outcome

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

Veradigm discloses patient-data theft through vendor API credentials

What is confirmed

What remains unclear

Why it matters to defenders

Practical checks for your environment

Key takeaways

Related articles

Sources and editorial note

Why it matters

Required telemetry and evidence

Step-by-step investigation

1. Scope the change

2. Reconstruct the actor and target

3. Query the surrounding sessions

4. Enrich with recovery evidence

5. Validate competing explanations

6. Document and improve

Read-only investigation pseudocode

Legitimate activity versus suspicious activity

Tuning and false positives

Escalation, containment and documentation

MITRE ATT&CK context

Practical Cybersecurity
Knowledge for Defenders.