Khalid · Cybersecurity Portfolio

For students entering cybersecurity, internships are one of the best ways to build practical experience before stepping into a full-time role. Between 2023 and 2025 I completed three: a Cybersecurity Analyst role at Leonardo DRS, a cybersecurity internship at Dark Wolf Solutions, and an Information Security Operations internship at Seagate Technology. Each role covered a different area of the discipline: SOC operations, compliance, and detection engineering.

Leonardo DRS: Where It Started

My first role was a Cybersecurity Analyst internship in Dayton, where I was embedded within the CERT team supporting network and endpoint security operations. Being part of the CERT team meant working directly on active security operations: triaging alerts in Splunk, analyzing logs, and escalating verified threats. The volume was high and the environment operated at a consistent pace, and it established early that most SOC work is pattern recognition and structured triage, not reactive incident response.

Phishing investigation was among the most hands-on work. Proofpoint generated the initial alerts; from there, I'd trace the sending infrastructure, extract IOCs, and work the incident through to close. That repeated process contributed to a 40% reduction in mean time-to-close. On the network side, Zscaler Web Gateway provided visibility into outbound traffic, which was useful when correlating anomalies during threat hunting. Carbon Black Cloud and Microsoft Defender covered endpoint telemetry. Between the two, it was generally possible to reconstruct process execution and determine origin.

Participating in the annual tabletop exercise was a different kind of experience. That year's scenario was a ransomware incident, and working through it with the full team, working through detection decisions, containment steps, escalation paths, and recovery coordination, made clear how much of incident response depends on organizational process rather than technical execution alone.

Dark Wolf Solutions: The Compliance Side

Dark Wolf was a different area of security entirely. The work centered on Risk Management Framework activities: reviewing and assessing controls aligned with NIST SP 800-53 and supporting system authorization. It was process-driven and documentation-heavy rather than operational. I came in with limited exposure to compliance work and left with a clearer understanding of why the framework exists. An organization with strong technical controls but weak documentation is difficult to audit, and that gap creates real exposure.

Seagate Technology: Going Deeper on Detection Engineering

The Seagate Technology internship was structured differently from the previous two. I worked directly alongside security engineers, which gave me a clearer picture of what that role looks like in practice and confirmed it as the direction I want to go. Being embedded with people doing detection engineering and incident response at an enterprise scale made the career goal concrete rather than abstract.

The work itself centered on a Microsoft Sentinel SIEM deployment: building automated workflows that generated tickets in the IT case management system and writing KQL analytic detection rules that extended threat coverage across the environment. In CrowdStrike Falcon, I created and tuned Indicators of Attack and Indicators of Compromise to improve alert fidelity.

I also handled endpoint incident response directly, identifying and removing malware from affected systems. Working through that process end-to-end several times gave the incident response lifecycle a concreteness that theoretical study doesn't provide.

This writeup covers the setup and walkthrough of a home lab I built following the Project Security E101 curriculum. The goal was to simulate a realistic enterprise environment, then attack it, covering both the offensive and defensive sides.

The Environment

Everything runs inside VirtualBox on a single 10.0.0.0/24 NAT network with seven machines, each with a distinct role in a simulated small company. Before this, I'd only worked in environments where the detection infrastructure was already in place. Building it from scratch was a different kind of exercise.

Defensive Stack

Wazuh handled SIEM duties, ingesting logs from every machine in the domain. Security Onion handled network traffic analysis. MailHog ran as a fake internal mail server, which became relevant during the phishing stage. Getting everything configured and communicating correctly took longer than expected. That setup process was where most of the early learning happened.

One immediate observation: the event log volume on a Windows domain under normal operating conditions is substantial. Getting a clear sense of which event IDs actually matter, not just a memorized list but an intuition for what constitutes noise, required spending real time in the data.

The Attack

The offensive side used the tools from the curriculum: Hydra for credential brute-forcing, NetExec to validate and move laterally with stolen credentials, Evil-WinRM to establish a shell on the compromised workstation, and a PowerShell reverse shell for C2. The kill chain traces a realistic path from phishing through to domain compromise.

The more instructive exercise was going back afterward and trying to identify the attack in the logs. Some activity surfaced clearly: failed logon spikes, suspicious process creation, unusual outbound connections. Other things didn't appear at all, which led to rewriting Wazuh rules. That cycle of attack, detect, miss, and improve was the most useful part of the project.

What It Reinforced

The BTL1 is a 24-hour practical exam with no multiple choice and no memorization. You work through a set of investigation tasks inside a simulated SOC environment using real tools. Pass mark is 70%; scoring above 90% earns a physical gold coin.

I sat the exam with only Security+ completed at that point. It was my second certification, taken before any internship experience. In retrospect, the timing was useful. It required building investigation methodology before having a production environment to rely on.

The Six Domains

How I Prepared

The official course covers all six domains thoroughly. The Blue Team Labs Online free challenges were equally useful. There are many challenges mapped directly to BTL1 topics, and working through them builds the pace the exam requires. For Splunk in particular, the syntax needs to be second nature before exam day; time spent working out queries during the investigation is time not spent on the investigation itself.

Phishing analysis was the domain I underestimated going in. Reading raw email headers, identifying spoofed return paths, tracing infrastructure through passive DNS and URLScan. It is a distinct discipline that takes deliberate preparation before exam day.

The Exam Itself

The investigation tasks are interconnected. Context gathered from one question frequently informs an earlier one. Working forward rather than stalling on a single task, keeping detailed notes throughout, and treating the incident report as part of the work rather than a closing formality all made a difference to the final result.

Where It Sits in the Bigger Picture

CompTIA CySA+, PenTest+, and Network+ came after this, along with the SSCP from ISC2. Those are valuable certifications, but they are largely knowledge-based: multiple choice exams that test whether you understand the material. The BTL1 is different: it's a practical exam that tests whether you can apply that knowledge under realistic conditions. That distinction is what made it worth pursuing early, and what sets it apart from the rest of the stack.

DFIR NetWars is a SANS competition focused on digital forensics and incident response. You're given evidence files from compromised systems and six hours to reconstruct what happened: attack vectors, artifacts, and indicators of compromise, with a live leaderboard running throughout.

I used Zeek for network log analysis, Wireshark for packet inspection, and Elastic SIEM to search and correlate events across the evidence set. Most challenge questions are interconnected, so findings from one artifact inform others. The time constraint forces quick decisions about what to prioritize and what to revisit. That judgment is a separate skill from the technical analysis itself.

A timed competition surfaces gaps that self-paced study doesn't. Certain artifact types I hadn't worked with extensively, and some tools I was less efficient with than I realized. That kind of feedback is difficult to get any other way.