I am a Cybersecurity professional with a growing focus on SOC Analyst work, including security monitoring, log analysis, incident investigation, and phishing analysis. I trace an attack from initial access to root cause, building practical, hands on experience one case at a time.
A short introduction to my background and how it shapes my approach to security work.
I am Precious Isioma Isiani, a Cybersecurity professional and engineer by profession. My background in Metallurgical and Materials Engineering, combined with hands on experience in quality control, materials inspection, and standards compliance, built my attention to detail, analytical thinking, problem solving, documentation, and ability to identify deviations from established requirements, skills I now apply directly to cybersecurity, particularly in security monitoring, log analysis, incident investigation, phishing analysis, threat detection, and compliance.
I also bring over five years of hands on experience in administrative and Executive Assistant roles, where I developed strong organizational skills, sharp attention to detail, and the ability to manage complex priorities under pressure.
My journey has taken me from engineering and administrative roles into cybersecurity, where I continue to build practical knowledge across security, technology, and digital systems.
Dated milestones: certifications, mentorship, and hands on labs completed along the way.
Red Team, Blue Team, and GRC fundamentals, with a practical focus on SOC operations: phishing analysis, log analysis, threat detection, and incident investigation.
Hands on SPF/DMARC verification using MXToolbox to assess email authenticity and spoofing risk.
Mentorship capstone with The Victor Akinode Initiatives (VA Cybersecurity Mentorship): full breach reconstruction using firewall logs, Wireshark packet capture, and a formal written incident report.
Nmap based reconnaissance against a deliberately vulnerable web application, enumerating open ports and services.
Investigated a simulated RDP brute force attack, correlating Windows Event Viewer logs into a full attack timeline.
Organized by SOC function. This is what each case study below demonstrates in practice.
Full breach reconstruction, root cause analysis, remediation planning
Windows Event Viewer, firewall syslogs, Linux CLI (grep/awk)
Packet inspection and anomaly detection in Wireshark
SPF/DMARC verification, header analysis via MXToolbox
Port scanning and service enumeration with Nmap
A collection of hands on investigations completed through structured training and self directed practice. Each case study documents the scenario, the method used, what was found, and what it means from a security standpoint.
A mentorship capstone (with The Victor Akinode Initiatives) simulating a real world breach against a fintech company, "KudiPay." The brief: reconstruct the full attack chain from network evidence and produce a formal incident report.
Filtered and analyzed firewall syslogs on a Kali Linux VM using grep and awk to isolate RDP (port 3389) traffic, cross referenced against a Wireshark packet capture of the same environment to confirm session behavior and DNS activity.
Web application exploitation (likely injection based) → internal reconnaissance → suspicious DNS query to data-sync.exfil-node.net → lateral movement via internal RDP → outbound RDP session to an external IP, transferring 29,825 bytes.
The breach could have been prevented at a single low cost control point: outbound traffic restriction, specifically egress filtering on RDP and DNS. No individual layer failed catastrophically. The attacker moved undetected by blending into normal looking traffic across layers that were only monitored in isolation, not correlated.
A simulated environment showed repeated failed logon attempts against a privileged "finance-admin" account over RDP (port 3389), originating from an external IP.
Built a timeline in Excel correlating firewall connection logs with Windows Security event logs, tracking failed logon attempts (Event ID 4625) through to the successful breach (Event ID 4624), then the attacker's follow up activity.
After 10 failed attempts, the attacker gained access via RDP brute force, then escalated privileges (Kerberos ticket, SeDebugPrivilege) and executed a Base64-encoded PowerShell command flagged as a suspicious decoded payload, consistent with post compromise tooling being staged on the host.
Verifying whether an email's claimed sending domain could be trusted, or whether it showed signs of spoofing commonly used in phishing campaigns.
Ran the email header through MXToolbox to check SPF record validity and alignment, then reviewed DMARC policy enforcement.
SPF and DMARC were both correctly configured and enforcing a quarantine or reject policy, meaning spoofed emails claiming to be from this domain would be rejected or flagged rather than reaching an inbox unchallenged.
Practicing the reconnaissance phase of a penetration test against a deliberately vulnerable target machine (TryHackMe's DVWA room).
Ran an Nmap scan against the target IP to enumerate open ports and identify running services before further investigation.
Identified an open SSH service with enumerable host keys, and an HTTP service hosting a DVWA login page with a missing HttpOnly flag on its session cookie and a disallowed entry in robots.txt, both worth flagging in a real assessment as configuration weaknesses.
Explored a SOC dashboard tool for endpoint detection and response (EDR) monitoring, covering fleet health and Windows Event Log correlation across a simulated domain.
Reviewed endpoint status across the monitored domain, then drilled into Windows Event Logs for a specific host to inspect logon activity and event severity.
The event log for DC-01 showed a pattern consistent with a password guessing attempt: a single successful logon (Event ID 4624) preceded by a run of failed logons (Event ID 4625) against different usernames in quick succession, worth escalating for follow up investigation.
A link styled as an airline booking page required assessment to determine whether it was legitimate, malicious, or suspicious before being trusted or acted upon.
Submitted the URL to VirusTotal to scan it against 92 security vendors and threat intelligence sources, with the goal of classifying the link as legitimate, malicious, or suspicious based on vendor consensus, delivery metadata, and content type.
All 92 vendors classified the URL as Clean, with no red flags in delivery status or content type, a result that indicates the link is likely safe to proceed with. That said, a Clean verdict from VirusTotal is an indicator, not a guarantee: vendor databases can lag behind newly registered or low traffic domains that haven't yet been flagged. For that reason, a clean scan should be treated as one data point in the assessment, and paired with manual review of the domain and page content before a URL is fully trusted.
Notes, logs, and additional lab work live on GitHub. This is the working record behind every case study above.
github.com/preciousisiani12 →I am currently open to SOC Analyst and Cybersecurity roles. If you are building a security team and looking for someone who documents thoroughly, correlates carefully, and is serious about growing in this field, I would love to connect.