Mohammed
Alshehri
Information Systems graduate with hands-on SOC experience at TAHAKOM, resolving up to 15 security cases weekly through SIEM triage and MITRE ATT&CK threat hunting. CompTIA Security+ certified. I turn noisy alerts into decisions.
Where the work happened
Four months embedded in TAHAKOM's Information Security Department — real alerts, real escalations, real adversary tradecraft.
- SIEM incident triage. Performed triage and incident response on 6–15 security cases per week by analyzing LogRhythm SIEM logs, correlating IOCs, and validating email headers against SPF/DKIM/DMARC to separate real phishing from noise.
- MITRE ATT&CK threat hunting. Ran weekly hypothesis-driven hunts, mapping adversary TTPs to the ATT&CK matrix and surfacing anomalous behaviors for escalation — accelerating detection ahead of alerting.
- Phishing analysis. Dissected suspicious email campaigns end to end: header forensics, URL and attachment analysis, IOC extraction, and feedback into detection rules.
- Firewall configuration (FortiGate NGFW). Configured security policies, NAT rules, and interface segmentation on FortiGate hardware, plus application-layer egress filtering, as part of a structured network security lab build.
- Digital forensics & IR support. Applied network, email, and disk forensics techniques to case investigation and post-incident reconstruction.
Conducted threat intelligence analysis and dark web monitoring to identify emerging threats, leaked credentials, and fresh IOCs targeting the organization — feeding findings directly into SOC incident response workflows so exposure was actioned before it became an incident.
Six stages of an intrusion,
and what I did at each one
Scroll to travel the chain. At every stage: the MITRE ATT&CK techniques an adversary uses, with the ones I have personally triaged, hunted or analyzed highlighted. Click a highlighted technique for the detail.
Three case files, start to finish
One real supply-chain compromise briefed to the department, one simulated enterprise breach reconstructed from raw log data, and one firewall built from bare hardware.
Phishing-based 2FA bypass → malicious injection across 18 packages
A maintainer-targeted phishing campaign defeated two-factor authentication, giving the attacker publishing rights to widely-used NPM packages. Malicious code was injected downstream into 18 packages — turning a single credential compromise into a dependency-graph-wide exposure. I reconstructed the attack chain and presented it, with mitigations, to TAHAKOM's Information Security department.
ATTACK CHAIN
- Targeted phishing against package maintainers using a convincing lookalike registry domain
- Real-time credential and OTP relay defeating two-factor authentication
- Attacker-controlled publish of tampered package versions
- Malicious payload propagated through 18 packages and their dependents
MITIGATION GUIDANCE
- Phishing-resistant MFA (hardware / FIDO2) for all publish-capable accounts
- Dependency pinning with lockfile integrity verification in CI
- SBOM generation and continuous dependency monitoring
- Monitoring for anomalous package install and post-install script behavior
Reconstructing a breach from raw Splunk data, with no alert to start from
Boss of the SOC is a blue-team investigation lab — I worked the V1 dataset on CyberDefenders. You are dropped into an enterprise environment indexed in Splunk after a compromise has already happened: no alert to anchor on, no starting point, no summary. Just raw logs from web servers, IDS, endpoints and firewalls, and a set of questions you can only answer by reconstructing the events yourself. I worked it the way I would work a live case: establish the sequence before forming a theory, pivot on each confirmed indicator rather than broadening the search, and trust correlation across sources over any single log.
INVESTIGATION PATH
- Started from a raw index with no alert to anchor on — scoped the environment and available log sources first
- Used SPL to narrow from broad time windows down to the specific events that actually mattered
- Pivoted on each confirmed indicator — addresses, hostnames, file artefacts — instead of widening the query
- Correlated findings across web, network and endpoint sources to place events in the right sequence
- Documented it as a timeline so every conclusion traced back to a specific logged event
WHAT IT TAUGHT ME
- Pivoting beats searching — one confirmed indicator opens more than a broad query ever will
- Build the timeline first; conclusions drawn before the sequence is clear tend to be wrong
- The answer usually lives in the correlation between log sources, not inside any single one
- Knowing which questions the data cannot answer matters as much as the ones it can
Segmenting a network on physical hardware, then blocking what shouldn't leave it
Built on a physical FortiGate 71F rather than a virtual appliance, so every interface, cable and policy decision was real. Three interfaces, three jobs: a dedicated management port with static addressing reachable only from my own laptop, an internal port feeding an access point for client devices, and the WAN. From there I wrote the security policies and NAT that let the internal segment reach the internet, and then went the other direction — using application control and web filtering to stop specific categories from leaving the network at all, including Tor and public AI tools. That second half is the part that matters. A firewall that only decides what comes in is doing half the job; the traffic worth watching in a SOC is usually outbound.
WHAT I BUILT
- Interface segmentation — management, internal and WAN kept separate, with the management interface locked to a single static host
- Firewall policies and NAT to give the internal segment controlled outbound access
- Application control and web filtering to block Tor and public AI tools at egress, treated as a data-exfiltration control rather than an acceptable-use one
- Verified from both sides — confirmed the permitted traffic in the logs, then deliberately tried the blocked categories to prove the deny actually fired
WHAT IT TAUGHT ME
- Policy order decides everything. A rule I had written never matched, because a broader policy above it caught the traffic first — everything looked configured and nothing behaved as configured
- A configuration is not a control until you have tested the negative case; confirming what passes proves nothing about what should not
- Reading the same event from the firewall's side changes how you read it in a SIEM — you know which field the device chose to log and why
- Segmentation is cheap to design and unforgiving to retrofit
Three alerts. What would you do?
Read the alert, pick an action, and see how I'd read it. There's no score and no wrong answer — analysts disagree, and one of these three I deliberately wouldn't call either way.
Forty-eight hours of logs. One intrusion. No alert.
A working log-search console in your browser, over a synthetic enterprise that was actually breached. Query it yourself, or follow the six questions I worked it with.
THE SITUATION
DevTheH is a fictional company with a real problem. Three days ago an endpoint alert on a single workstation was closed as benign by whoever was on shift. Nobody has looked at it since.
You have forty-eight hours of logs from five sources and no alert to anchor on. Something did happen. The console below is real: type a query, get results. Nothing is pre-filtered and nothing is highlighted for you.
There are also two things in here that look bad and are not. Finding those matters as much as finding the intrusion.
THE DATASET
Sources: auth · endpoint · proxy · dns · firewall. Built in the browser from a fixed seed, so every visitor investigates the same environment.
WHAT I WOULD PUT IN THE TICKET
- 14 Jun 09:12External host 203.0.113.14 scans the VPN portal for thirty minutes. 342 connection attempts across eight ports, almost all denied.
- 14 Jun 11:58Password spray from the same address against fourteen accounts, including four that do not exist.
- 14 Jun 12:26One success. n.alharbi authenticates to the VPN from the scanner's address. This is the moment the intrusion starts.
- 14 Jun 12:41On WS-0412, outlook.exe spawns encoded PowerShell, which loads a DLL from the user's Temp directory.
- 14 Jun 12:43First contact with cdn-updates.devtheh-cdn.co, then beaconing every 300 seconds for the next thirty-five hours.
- 14 Jun 14:10A binary named svchost.exe runs from AppData\Local\Temp. Twelve minutes later the security log on WS-0412 is cleared.
- 14 Jun 15:02rundll32.exe reads lsass.exe. Credentials for svc_backup are used thirteen minutes later.
- 14 Jun 15:30svc_backup authenticates to SRV-FILE01 from the workstation's address, then robocopies the Finance share to a staging directory.
- 15 Jun 02:142.2 GB leaves the network in six chunks to a file-sharing host, at two in the morning.
Containment first, in this order: kill the VPN session and disable the account, isolate WS-0412 from the network but leave it powered on, rotate svc_backup and every credential that account could reach, then block the two domains at the firewall. The log clearing at 14:22 means the endpoint's own record is incomplete, so the proxy and the domain controller are now the primary evidence. I would not close this without knowing how the phishing email reached her inbox, because the same message almost certainly reached other people.
The stack I work in
Platforms and frameworks I've used on real cases, grouped by what they're actually for.
Core skill set
Built in a live SOC environment, not a lab simulation.
Alert triage and full incident response on 6–15 cases weekly in LogRhythm — log correlation, IOC enrichment, severity calls, and escalation with defensible write-ups.
Hypothesis-driven hunts mapping adversary TTPs to the ATT&CK matrix, surfacing behavior that never fired an alert and turning findings into escalations.
Continuous monitoring of underground sources for leaked credentials, exposed assets, and chatter — turning external signals into actionable internal IOCs.
Next-generation firewall policy design, NAT rule sets, and VLAN segmentation — building the network boundaries that shrink an attacker's blast radius.
Header forensics with SPF/DKIM/DMARC validation, URL and attachment analysis, sender infrastructure pivoting, and campaign-level IOC extraction.
Network, email, disk, and metadata forensics plus steganography analysis — reconstructing what happened, in what order, and what the attacker touched.
Certifications & training
A bit about me
Riyadh-based, Information Systems graduate. I spent my internship in TAHAKOM's SOC triaging six to fifteen cases a week, and it confirmed what I suspected about myself — I would rather reconstruct an incident than theorize about one.
The habit that got me here is daily practice. I work labs most days, and the structured ones moved me furthest: Tuwaiq Academy's Digital Forensics program took me through network, disk, email and metadata forensics properly rather than in passing, and Boss of the SOC on CyberDefenders taught me to pivot on a confirmed indicator instead of widening a search and hoping. There is always something I did not know yesterday. Turning up to it every day is the only method I have found that works.
I am early in this, and I would rather say so than write like someone who is not. What I have is a real SOC on my CV, Security+, and the habit of building the timeline before forming an opinion. What I want is a team that will push me harder than I would push myself.
Where to find me
Based in Riyadh, working across Saudi Arabia. Email gets the fastest reply. I read everything that comes in.