ThreatDefence is the only SecOps as a Service company providing broad coverage across your entire technology stack with evidence-based security.
We provide security teams with full-stack SecOps infrastructure – you get deep visibility from day one, gain control over your security data, and get access to a comprehensive set of ready-to-use tools, detections, workflows, playbooks and scenarios.
24×7 managed detection and response across endpoint, network, cloud, identity, and log sources
Eyes-on-glass SOC and continuous threat hunting
Protect your entire technology stack and build your SecOps on your own pace
White-labeled AI SOC for every client tenant, co-managed with our SOC team
Launch your SOC business without any upfront investment
Get ultimate assurance that your environment is free from threat actors
Quickly recover from cyber attacks and breaches
24×7 SOC, Continuous Monitoring, Threat Containment and Incident Response
Visibility and actionable insights for all IT assets
Leverage our Cyber Range to train defenders based on real-world scenarios and simulations
OT and industrial cyber security services for critical infrastructure
Cloud-based SIEM platform providing visibility across all your data sources
Manage your external footprint, publicly available data, and Dark Web leaks
AI triage, investigation and response on the tools you already run
Fully featured distrubuted NDR for on-premises and public cloud environments
Deploy honeypots and honeytokens and stay ahead of threat actors
Every alert investigated, with a verdict and the evidence behind it
Integrated endpoint agent providing deep visibility, response and forensics
Log management and threat detection across any of your log sources
A SecOps platform purpose-built for industrial and OT environments
ThreatDefence puts security and compliance at the heart of our service, keeping your data protected at all times.
See how we keep your data secure.
Guides, case studies, and advisories in one place
Read what our customers say about us
Solution briefs and datasheets
Technical support and knowledge base
What to check in your Microsoft 365 tenant
Remote code execution flaws that need patching now
Essential Eight monitoring, reporting, and evidence for ongoing compliance
Privacy Act reform impacts, obligations, and practical security considerations
Monitoring and compliance support for critical infrastructure environments
A practical guide to Incident Response and Digital Forensics
Read how cyber range helps to train cyber defenders
How AI agents investigate alerts and run security operations
How AI SOC platforms work, from integrations to autonomy
Free ebook: a practical guide to adopting an AI SOC platform
How brand impersonation works and how to detect and stop it
How lookalike domain attacks work and how to take them down
A practical guide to securing critical infrastructure with continuous monitoring
A practical buyer’s guide for schools evaluating SIEM and SOC services
A practical guide to selecting the right SIEM and SOC service for local government
We provide end-to-end SecOps solutions for Managed Security Service Providers (MSSPs), Managed Service Providers (MSPs), and Value-Added Resellers (VARs).
Find out how you can become a ThreatDefence partner.
Where SOAR playbooks fit, where AI agents take over, and how the two work together.
AI SOC hyperautomation transforms cybersecurity ops by autonomously detecting, analyzing, and remediating threats.
Honored to Support the Launch of the University of Technology Sydney Cybersecurity Precinct!
ThreatDefence Cyber had the privilege of meeting with Honeywell Dubai’s Digital City leadership to explore synergies in OT/SCADA and…
Read More
Equinox to support companies with ready to use, end-to-end SecOps infrastructure, including a full stack platform able to capture and…
ThreatDefence had an amazing time at AISA CyberCon 2024, connecting with industry leaders and advancing cyber security conversations.
Endpoint forensic artifacts are the records left by operating systems and applications. Investigators use them to establish what ran, who accessed a system, what changed, and how an incident developed.This guide explains which artifacts answer common investigation questions and how to collect them across Windows, Linux, and macOS.
An effective collection starts with what you need to establish. A suspected account takeover needs different evidence from ransomware, although both investigations may eventually reach the same endpoints.
Most conclusions require evidence from several sources. One artifact may identify a suspicious file; another may show that it executed and what happened afterward.
Windows records program activity in several places. Each source has a different purpose, so its meaning needs to be understood before it becomes part of a finding.
Security event 4688 records process creation when the relevant auditing is enabled. Command-line arguments require an additional policy setting. Sysmon event 1, where deployed and configured, provides another source of process creation evidence. These records can connect an executable to its parent process, account, and launch time.
Prefetch can provide evidence that a program executed, including recorded run times and files referenced during startup. Available detail varies by Windows version and configuration. Prefetch may be unavailable on some systems, particularly servers. Its absence does not establish that a program never ran.
Amcache contains application and file information that helps identify programs present on a system. It can remain useful after a file has been removed, but an entry alone should not be treated as proof of execution.
ShimCache, also called AppCompatCache, records information about files encountered by Windows. On modern Windows, it is primarily supporting evidence of file presence rather than proof that a program ran.
PowerShell script block logging can expose script content that is difficult to understand from the command line alone. Module and other PowerShell logs can add context where enabled. Coverage depends on configuration, PowerShell version, and retained records. A logged script block does not by itself prove that every operation in the script completed successfully.
The System Resource Usage Monitor database records application resource usage, including network usage information. It can help identify applications worth investigating and support a broader activity timeline. SRUM is not a packet capture. It does not establish which documents were transferred or reveal the contents of a connection.
Persistence configuration shows how software may start again. Authentication and remote access records help establish who reached a host and what followed.
Collect from both ends of suspected lateral movement where possible. The source may show the tool being used, while the destination records the logon and subsequent activity.
File system metadata and application artifacts help reconstruct changes that process logs may no longer cover.
Interpret these records carefully. A USB connection does not prove data was copied. A browser visit does not prove an upload. A shortcut may reference a file without establishing who opened it.
Collect personal activity only where it is relevant to the investigation and within the organization’s authorized scope.
Linux evidence varies by distribution, installed services, and logging configuration. Some systems retain extensive audit records; others provide little beyond application logs and shell history.
Authentication may be recorded in /var/log/auth.log, /var/log/secure, the systemd journal, or centrally forwarded logs. Examine SSH access, privilege changes, sudo activity, and failures. Where present, wtmp, btmp, and related login databases provide additional session information. Availability and implementation differ between systems.
/var/log/auth.log
/var/log/secure
wtmp
btmp
Shell history can reveal commands worth investigating, but it is incomplete by design. Commands may not have been written to disk, timestamps may be missing, and history can be disabled or modified. An empty history file is not, on its own, evidence of tampering.
Examine system and user crontabs, systemd services and timers, startup scripts, and other mechanisms relevant to the distribution. Look for unusual commands, unexpected execution paths, and changes that do not match approved administration.
Review authorized keys, SSH configuration, account changes, and related authentication records. An unfamiliar key needs investigation, particularly on privileged or externally accessible accounts.
The systemd journal can contain service, authentication, and system activity. Historical availability depends on storage and retention settings. Where configured, Linux Audit provides more detailed records of selected system calls and security-relevant activity. It does not automatically record every process or file operation.
macOS investigations combine system logs, persistence configuration, application records, and file system history. Artifact locations and formats change between releases.
The Unified Log contains system and application events useful for investigating authentication, service activity, and other behavior. Retention and privacy redaction affect what investigators can retrieve. It should not be treated as a complete process execution history.
Property lists in system and user locations define jobs managed by launchd. Inspect the executable, arguments, ownership, and referenced paths, then look for evidence that the job actually ran.
launchd
Login items and background task records help identify software configured to run automatically. Review unfamiliar registrations alongside application installation and execution evidence.
These stores can provide application and device activity information. Their availability and interpretation depend on the macOS version, user context, and collection method.
FSEvents records file system changes and can help identify affected paths and periods of activity. Events may be coalesced and do not provide a complete, precise record of every file operation.
Quarantine metadata and databases can help establish the source of files downloaded through participating applications. Not every download creates the same records.
Running processes, connections, sessions, and memory can change while an investigator is deciding what to collect. A reboot may remove important evidence, while continued attacker activity can create an urgent need for containment.
Plan collection around both evidence value and operational risk.
Where practical, capture relevant volatile evidence before disruptive actions. Urgent containment may take priority, and isolation does not automatically erase memory or stop every process.
Record what was collected, what changed, and why the team chose that sequence.
A triage collection retrieves selected artifacts. A forensic image captures a broader representation of a disk or volume, depending on the acquisition method.
A physical image may include unallocated space, but that does not guarantee recovery of deleted content. It also does not capture volatile memory unless that is acquired separately.
Many investigations begin with triage across relevant endpoints, followed by deeper acquisition where the findings justify it.
Fleet-scale collection helps determine whether suspicious activity is isolated or shared across multiple systems.
Prepare the process before an incident:
Unusual entries help prioritize review, but rarity alone does not make something malicious. A legitimate application installed on one server can be just as rare as an attacker’s tool.
Forensic collection cannot retrieve logs that were never generated or have already been overwritten. Logging and retention decisions directly affect what an investigation can establish.
Useful preparation includes:
Enable appropriate process creation telemetry, including command lines where justified.
Configure relevant logging and protect access to potentially sensitive script content.
Enable and validate the specific event sources needed for these changes.
Preserve important logs beyond local retention and reduce dependence on a potentially compromised host.
Configure persistent logging and targeted audit coverage where appropriate.
Maintain reliable clocks and retain enough context to interpret timestamps.
Confirm that tools retrieve and parse the expected artifacts on supported operating systems.
Test the result rather than relying on policy settings alone. Generate representative activity and confirm that the expected records reach the investigation platform.
Endpoint artifacts explain only part of an incident. Identity records may show how access was obtained, email evidence may reveal the lure, and network telemetry may help establish communication or movement between systems.
An AI SOC platform brings these sources into the same investigation. AI agents can search collected artifacts, assemble timelines, and identify follow-up checks, while analysts verify conclusions against the underlying records.
Explore AI Endpoint Forensics
ThreatDefence collects endpoint telemetry and forensic artifacts across Windows, Linux, and macOS. Investigators can examine individual hosts or run authorized hunts across the fleet, with results linked to the relevant case.
The AI SOC platform connects endpoint findings with identity, email, network, and other security evidence. AI agents help prepare timelines and assessments, while ThreatDefence’s SOC and DFIR specialists support investigation and response under agreed procedures.
Explore Endpoint Visibility and DFIR
CountryAustraliaUnited StatesNew ZealandUnited KingdomCanadaSingaporeOtherI'm an MSP, MSSP, or reseller
Δ
They are records created by operating systems and applications, including logs, registry entries, file system metadata, caches, and application databases. Investigators use them to reconstruct activity and test explanations.
Process creation logs, Prefetch, and relevant script or application records can support execution findings. Their meaning depends on the source and configuration. Amcache and ShimCache require careful interpretation and corroboration.
On modern Windows, a ShimCache entry alone does not prove execution. Use it to identify files worth examining, then look for supporting process, Prefetch, or other relevant records.
A triage collection retrieves a selected set of evidence rather than imaging an entire disk. It is useful for initial assessment and investigations involving many endpoints.
No. Collection order depends on the investigation, system support, and operational risk. Memory can be important, but urgent containment may take priority.
Common sources include authentication records, the systemd journal, audit logs, shell history, scheduled tasks, service definitions, and SSH configuration. Availability varies by system.
Common locations include LaunchAgents, LaunchDaemons, login items, and background task registrations. Other mechanisms exist, so collection should follow the suspected behavior.
There is no universal retention period. Log sizes, system activity, operating-system behavior, cleanup, and deliberate deletion all affect availability. Central forwarding can preserve selected records for longer.
Sometimes, but many artifacts provide only supporting evidence. File access, archive creation, USB connections, or network usage do not independently establish which data left the organization.
Yes. Attackers may delete logs, modify timestamps, or remove files. Compare independent sources and preserve central records to reduce reliance on evidence from one host.
AI Endpoint Forensics
DFIR for MSSPs
Endpoint Visibility and DFIR