MCA graduate building practical blue-team skills through evidence-led investigations—from SIEM and endpoint telemetry to honeypot and network analysis. Clear about what the evidence proves, and what still needs validation.
Review my cybersecurity resume here, or open and download the original PDF.
A guided view of separate, controlled security labs: collect the right evidence, test what it can support, and state clearly what remains unverified.
Report-based replay—not a live console. The animated lines summarize documented lab evidence; they do not execute searches or represent streaming telemetry.
Each environment had a specific purpose and boundary; these are not presented as one connected enterprise SOC.
Windows Security, System, Application and PowerShell logs forwarded to Splunk Enterprise on Ubuntu over TCP 9997. Investigated five Event ID 4625 failures from loopback against a local test account; SOC-001 was closed as controlled activity.
Cowrie 3.1.1 on an Ubuntu VM received one authorized Kali test session on TCP 2222. Logs showed one accepted login, five emulated shell commands and zero failed logins.
LimaCharlie sensor enrollment and benign scheduled-task activity are documented. The report records 0 of 13 rules tested; no custom-rule alert or investigation is claimed.
Used Wireshark to inspect controlled Nmap and hping3 traffic; separately assessed a self-hosted DVWA instance at Low security. Scans against other hosts were excluded from DVWA findings.
I’m Ranbir Mishra, an MCA graduate focused on SOC analysis and cybersecurity. I turn hands-on lab evidence into careful investigations, clear reports and practical next steps.
I’ve built a Splunk lab to examine Windows authentication events, investigated case SOC-001 through to a documented benign closure, and deployed both LimaCharlie endpoint monitoring and a Cowrie SSH honeypot in controlled virtual labs.
My work also includes Wireshark traffic analysis and scoped testing of a self-hosted DVWA application. I document what I observed, what I could not confirm, and what I would validate next—so a project report is useful to someone reviewing the evidence, not just a list of tools.
Education: MCA, Dr. Harisingh Gour Central University (2024–2026)
Target roles: SOC Analyst · Tier 1, Cybersecurity Analyst
Technical focus: Splunk · Windows Event Logs · EDR · Linux
Based in: Jajpur, Odisha, India
Languages: English · Hindi · Odia
Recognition: Smart India Hackathon 2025 — IDEATHON selection (“Discover Delight”)
Availability: Open to entry-level opportunities
A quick view of selected documented results. Each was produced in a controlled lab and is described within its actual scope.
Reviewed five controlled Event ID 4625 failures in case SOC-001 and documented the conclusion: benign test activity, not a real intrusion.
See SIEM project →Summarized an authorized lab session with five emulated command events. No failed logins or real attacker activity are claimed.
See Cowrie project →Documented five findings on a self-hosted training application at Low security, with clear scope and remediation guidance.
See assessment details →Transparency: These are educational lab projects—not production SOC employment or real-world incident-response claims. LimaCharlie rule efficacy is not yet validated; the project report records 0 of 13 rules tested.
Practical capabilities from lab work, each tied to something I've actually built and documented.
Tier-1 triage across Windows and Linux telemetry: review alert context, separate true positives from benign noise, escalate with evidence. Experience analysing failed logons (4625): account, source, logon type and status codes.
Writing SPL threshold searches for repeated failed logons and designing LimaCharlie rules for PowerShell, process chains, scheduled-task persistence and process-to-network activity, with false-positive tuning in mind.
Investigations that run from detection to analysis, validation and a closed case, with MITRE ATT&CK mapping, evidence tables and honest outcomes — including closing a case as benign when that is what the evidence shows.
Scanning and manual validation with Nessus, OpenVAS, Nikto, ZAP and Burp Suite; OWASP Top 10 testing; CVSS-rated findings with PoC and step-by-step fixes.
User and permission management, sudoers, services and processes, log review with journalctl/syslog, and Bash + Cron automation for routine tasks.
MERN applications with JWT auth and REST APIs — useful for security tooling, internal dashboards and understanding how applications are attacked and defended.
A practical security skill set across monitoring, endpoint telemetry, network and application security, Linux, scripting and clear evidence-led reporting.
Structured investigation, attention to detail, transparent status reporting, clear written communication, and continuous hands-on learning.
Concrete outcomes from the portfolio projects. These demonstrate specific lab work—not professional production incident-response experience.
Reviewed Security Event ID 4625 records, investigated five controlled failures in SOC-001 and closed the case as test activity.
SIEM project & detection details →Correlated one authorized test session and five emulated command events. The session contained zero failed logins; no brute-force result is claimed.
Honeypot project details →Examined a controlled full-range SYN scan in Wireshark and separately documented a ten-probe test in the isolated lab.
Network security project →Documented five findings on a self-hosted DVWA target at Low security, with severity and remediation guidance.
Assessment evidence & limitations →Clear status labels matter in security: completed activity, detection design, and validated detection outcomes are not interchangeable.
The same four-stage process I follow in every lab incident, from first alert to final report.
Six practical security projects spanning SIEM, AI-assisted analysis, endpoint detection, network defense, honeypot monitoring and application security. Each summary distinguishes documented capabilities from results still to validate.
Objective: make authentication-log review more structured by bringing suspicious-pattern detection, indicator extraction, investigation context, incident records, and report generation into one platform.
Approach: Flask provides the application layer; rule-based classification identifies candidate activity, while Ollama with Llama 3.2 adds analyst-assistance. SQLite stores incident-management data, and REST API functionality supports programmatic access.
Analyst value: findings and ATT&CK context are organized for review, with downloadable reports to support documentation and handoff.
Validation boundary: the portfolio describes implemented capabilities, not measured detection accuracy, production deployment, autonomous response, or a benchmark result.
More detail: Open the AI platform dossier →
Objective: study how an SSH honeypot records connection and session behavior, then turn its raw logs into a coherent analyst summary.
Environment: Cowrie 3.1.1 ran on an Ubuntu VM. A Kali VM made one authorized test connection to TCP 2222 inside the isolated VMware lab.
Analysis: text and JSON events were correlated by session, then reviewed for authentication, source, and command context. Five emulated shell commands were recorded and mapped only where the observed behavior supported the mapping.
Observed result: one accepted test login, five commands, and zero failed logins. This is a session-analysis exercise, not evidence of live attacker activity or credential guessing.
Important limitation: Cowrie presents an emulated shell. The commands did not run on the Ubuntu host; no host compromise or automated alert is claimed.
Objective: build a small SIEM workflow that collects Windows events, supports a repeatable authentication search, and records the analyst's decision for a candidate alert.
Data path: Windows 10 logs were sent by Splunk Universal Forwarder to Splunk Enterprise 10.4.3 on Ubuntu over TCP 9997 into a dedicated index. Collected sources included Security, System, Application, and PowerShell Operational logs.
Investigation: a threshold search grouped Event ID 4625 failures by source and account. Five failures from loopback against a local test account were examined in SOC-001 and closed as controlled activity; compromise was not observed.
Operational lesson: changing the server address interrupted forwarding. Recovery reinforced the need for stable destination configuration and checking the correct Windows event channel during investigation.
Evidence boundary: 1,767 ingested events are documented. The available report does not establish a saved alert firing or a completed six-panel dashboard.
Objective: establish endpoint visibility and document detection-and-response scenarios for common Windows activity patterns.
Work completed: a Windows 10 Pro VM was enrolled in LimaCharlie and baselined. Rule scenarios were documented for PowerShell, a cmd.exe-to-PowerShell chain, scheduled-task creation, and process-to-network activity.
Controlled exercise: a benign scheduled task was created, checked, and removed. This confirms the test action only; an alert or detection was not observed in the available evidence.
Current status: the report states 0 of 13 rules tested. Rule efficacy, custom-rule alerting, and incident-response outcomes remain unvalidated.
Next validation: run one safe scenario at a time and preserve the source event, matching rule, alert, and analyst disposition before making an effectiveness claim.
Objective: practice moving from network discovery to packet-level review, and describe traffic in context rather than labeling isolated packets as malicious.
Approach: Nmap-generated discovery traffic was inspected in Wireshark. A separate controlled exercise captured approximately 65,000 SYN packets across a full-range scan and ten SYN probes in a distinct test.
Analysis: five traffic patterns were documented. Service-discovery behavior was mapped to ATT&CK T1046 where supported, with the assessment kept within the isolated lab scope.
Evidence boundary: this demonstrates controlled traffic capture and analysis. It does not claim exploitation, access to data, a real-world compromise, or an automated network alert.
Objective: assess an intentionally vulnerable training application, keep the target boundary explicit, and tie each reported issue to in-scope evidence.
Scope: the target was a self-hosted DVWA instance at Low security in an isolated Kali Linux lab. Results from Nessus and OpenVAS scans of other hosts were excluded from the DVWA findings.
Findings: five issues were documented: SQL injection, reflected XSS, stored XSS, OS command injection, and security misconfiguration. The report rates command injection High and SQL injection/XSS Medium for this training target and provides remediation guidance.
Testing limits: brute-force testing was not performed, access-control testing was inconclusive, and no remediation retest is claimed. These limits prevent the assessment from overstating coverage or fix verification.
No projects match this search. Try another term or reset the filters.
Automated security log analysis and incident investigation, designed to turn authentication-log evidence into a structured analyst workflow. The platform combines deterministic rules with AI-assisted analysis while keeping the analyst responsible for review.
The project addresses a practical SOC task: reviewing authentication activity, identifying suspicious patterns, and organizing the resulting evidence so an analyst can investigate it consistently.
The analyst uploads log data for analysis.
Rule-based classification highlights suspicious login patterns and potential brute-force activity.
IOC extraction and ATT&CK mapping help organize the details for investigation; Llama 3.2 provides AI-assisted analysis through Ollama.
Incident information is managed through the platform, with SQLite storage, REST API support, and downloadable reports.
A project-by-project view of the telemetry paths and testing environments described in my reports. These are separate lab tracks—not one connected enterprise network.
Centralized Windows endpoint telemetry for authentication investigation and search-driven triage.
A separate EDR project focused on endpoint enrollment, telemetry and detection-and-response rule design.
A low-interaction SSH honeypot exercise that captures session and command events without exposing a real shell or public target.
Independent, authorized learning exercises against local or virtual lab targets—not public or third-party systems.
Safety boundary: These projects are described as educational work in isolated or self-hosted environments. No public-target assessment or production incident response is claimed.
Detection work is more than a rule name: it needs a defined signal, contextual triage, a tested outcome and an honest validation status. The use cases below separate observed evidence from detection efficacy.
Interpretation: This demonstrates a search and investigation—not a documented saved alert firing or a real brute-force incident.
Interpretation: Event presence confirms telemetry—not a tested detection or a malicious-script finding.
Interpretation: Packet behavior was observed and analyzed; an automated network alert was not demonstrated.
Interpretation: Detection logic is designed; alert efficacy remains unverified.
Interpretation: The shell is emulated; commands did not execute on the Ubuntu host. This is session analysis, not evidence of a real attacker or compromise.
Validation key: “Telemetry observed” means events were present; “traffic captured” or “session analyzed” means recorded activity was reviewed; “search demonstrated” means the documented analytic was used in a lab investigation. None implies production monitoring. “Rule validation pending” means no efficacy claim can yet be made.
A real investigation from my Splunk lab: five Event ID 4625 failures detected, triaged field by field, validated and closed as controlled test activity.
index=soc-project1 LogName=Security EventCode=4625 | eval target_user=mvindex(Account_Name,1) | stats count by Source_Network_Address, target_user | where count >= 5 | sort -count
Five failures for a local test account from loopback — a candidate investigated as controlled activity, not a confirmed incident.
Evidence boundary: SOC-001 is a closed benign lab case, not a real-world compromise. The source report does not include the saved-alert configuration screenshot or evidence of an alert firing, and it does not establish that the full six-panel dashboard was completed.
Three project reports add detail behind the portfolio summaries. Each write-up below separates observed lab evidence from tests or outcomes that still need validation.
A controlled investigation in an isolated Kali Linux and target-VM lab, following discovery, packet capture, analysis and written findings.
All activity was generated in the controlled lab. Findings describe observed lab traffic—not an external attack, a confirmed compromise, or successful exploitation. The report includes hardening recommendations; it does not claim production remediation.
Manual testing of a self-hosted DVWA instance at the Low security setting, using a local Kali Linux lab and an evidence register.
Brute-force testing was not performed and access-control testing was inconclusive. OpenVAS and Nessus results were excluded because those scans targeted other hosts—not the DVWA system. Only in-scope evidence supports the findings above.
Built and documented a Windows endpoint monitoring lab, enrolled a sensor and configured detection-and-response scenarios.
The report records 0 of 13 rules tested and does not show a custom rule firing or an alert being investigated. Rule efficacy, incident triage and response outcomes remain future validation—not completed results.
Public evidence note: These summaries use verified, non-sensitive details from the project reports. The original reports are not linked here because they contain student identifiers and internal-lab details and are marked for educational/internal use.
Public profile ranbirmishra2004. Screenshots below are taken from my own account on 9 Oct 2026.
Networking fundamentals and the OSI/TCP-IP model, Nmap scanning and host discovery, reconnaissance, traffic analysis, SIEM and EDR concepts, log analysis, OWASP Top 10 and basic exploitation in safe lab environments.
Cybersecurity lab practice, internships, education and verified hands-on learning.
Self-directed security operations lab. Monitored Windows authentication and PowerShell telemetry in Splunk, practised Tier-1 alert triage, analysed network traffic, ran vulnerability assessments, and wrote evidence-based investigation reports.
Hands-on application development, testing, troubleshooting and technical problem-solving.
82 completed rooms and 14 badges, including SOC Level-Up, Logging Legend, OWASP Top 10 and Blue, across networking, SIEM, EDR, log analysis and web security.
Selected in the internal round; collaborated with a cross-functional team to develop and present “Discover Delight”.
Dr. Harisingh Gour Central University, Sagar, MP · 8.67 CGPA
Utkal University, Bhubaneswar · 81.72% · 8.4 CGPA
Fakir Mohan Higher Secondary School, Balasore · 85%
Fifteen cybersecurity credentials and course certificates. Open a certificate or use the official verification link where available.
Data Analytics Job Simulation — Tata, Forage · Power BI Certification — Office Master · Front-End Development — Simplilearn · UNXT Soft Skill Foundation — Infosys Foundation, SGBS Unnati (165 hours)
The concrete next steps from my own project reports.
Validate 4624-after-4625 correlation, build the six-panel dashboard and trigger the five-minute brute-force alert with evidence.
Add Sysmon and Linux SSH logs, then fire and document each LimaCharlie rule with alert, process tree and response.
Multi-endpoint correlation, API-based reporting, and a recognised SOC / blue-team certification.
A quick overview of my target roles, practical experience and availability.
SOC Analyst (Tier 1), Cybersecurity Analyst, Linux Administrator and Application Support roles — full-time, remote or hybrid.
Three months of self-directed SOC lab work: Splunk SIEM monitoring and a closed investigation case, LimaCharlie EDR deployment and rule design, network analysis and VAPT, all documented as evidence-based reports.
Yes. I completed a Full Stack Web Development internship and built MERN projects, which helps me understand application-level attacks.
I have completed my MCA (2024–2026) and am open to opportunities. Message me to discuss timing.
Have a role, project, or cybersecurity question in mind? Share a little context and I’ll be glad to connect. Your message is prepared in your email app—this portfolio doesn’t store or send form data.
Choose a topic so I can quickly understand what you have in mind.
Choose whichever channel works best for you.
Open to discussing entry-level opportunities and practical cybersecurity work.