Threat Detection & Research

Start with a question the evidence can answer

My security work includes configuring Wazuh and Microsoft 365 Defender, maintaining IT infrastructure, and helping restore operations after a ransomware incident. The research side of that work is about understanding how activity becomes visible: what a system records, what an alert means, and what remains unknown.

A useful investigation needs a specific question. An unexpected process, a suspicious email, and a new network connection may be related, but their proximity alone does not establish a chain of events. The goal is to build an explanation that can be checked against the available records.

Build a timeline before drawing a conclusion

For endpoint activity, useful fields to look for include the device, account, timestamp, process name, parent process, command line, and any associated destination or file hash. Availability depends on the telemetry and configuration. For email, the analogous context includes the recipient, message identifiers, delivery information, and the URLs or attachments involved.

A practical timeline keeps the raw event time and its time zone alongside a normalized time. It also records the source of each observation. That makes it possible to revisit an apparent sequence without confusing when something happened with when an alert was generated or reviewed.

Time (UTC) | Source | Device / account | Observation | Evidence reference
[time]     | [log]  | [entity]         | [fact]      | [event or capture ID]

Use lab work to test an explanation

Hack The Box Academy and home lab work support my study of Active Directory, network environments, and bug bounty methodology. A lab is useful for asking a narrow question and repeating the same action while observing its traces. It also makes it easier to identify missing telemetry before relying on it during an incident.

A repeatable exercise records the starting configuration, the action, the expected evidence, and the observed result. If an expected event is absent, check collection and parsing before treating that absence as proof that the action did not happen. A test result should describe the environment it actually covers.

From an alert to a detection hypothesis

Consider a hypothetical alert involving a command interpreter. The process name alone provides little context: administrators and business software use those tools too. Parent process, command line, account, and nearby activity can help distinguish an ordinary task from something that needs investigation. This is an example of the reasoning process, not a claim about a specific incident.

The next step is to state a detection hypothesis and test both suspicious and ordinary examples. Document why a condition was selected, which legitimate workflows might match it, and what evidence would justify escalation. An exception should be narrow enough that its purpose remains understandable when someone revisits it later.

Connect investigation to recovery

Helping with ransomware recovery tied security monitoring directly to operations for me. Identifying the compromise path, removing the attack vector, and restoring service require both technical evidence and an understanding of how the environment is used.

That experience shapes the questions I want research to answer: which records would help reconstruct the event, which controls would interrupt the path, and how would we verify the environment after remediation? The useful output is a finding or improvement that another person can understand, reproduce, and act on.