SOC Analyst Training Bootcamp

Think of a Security Operations Centre as the nervous system of an organisation's digital defence. Just like a hospital emergency room monitors patients around the clock, a SOC monitors every computer, server, and network device around the clock — looking for signs that something is wrong.

The SOC has three jobs: see everything (collect logs from every device), understand what it sees (distinguish normal activity from attacks), and respond fast (contain and fix problems before they get worse).

The technology stack in a SOC has three layers. At the bottom is the data layer — firewalls, endpoint agents, servers, and cloud services all generate logs. In the middle is the analysis layer — the SIEM (Security Information and Event Management) platform that collects all these logs and runs correlation rules. At the top is the response layer — SOAR (Security Orchestration, Automation and Response) tools that automate repetitive response actions.

As a beginner, focus entirely on understanding the data layer first. You cannot investigate alerts without understanding what the underlying systems are actually doing.

Every single attack travels over a network. If you cannot read a packet capture, you cannot investigate an intrusion. This is non-negotiable for a SOC analyst — networking knowledge is the difference between someone who looks at alerts and someone who actually understands them.

Start with the OSI model, not because you'll be tested on it, but because it gives you a mental map. When you see a firewall log, that's Layer 3-4 data (IP addresses and ports). When you see an HTTP request in a proxy log, that's Layer 7 (application). Understanding which layer an attack operates at tells you where to look for evidence.

The most important skill here is reading packet captures in Wireshark. Every SOC analyst needs to be able to: open a PCAP file, filter for specific traffic, follow a TCP stream to see the full conversation, and identify anomalies like port scans, large data transfers, or unusual protocols.

Key Wireshark filters to memorise: tcp.flags.syn==1 && tcp.flags.ack==0 shows SYN packets (port scans). http.request shows all HTTP requests. dns shows all DNS traffic. ip.addr==192.168.1.1 filters by specific IP.

Attackers live inside operating systems. They create processes, modify the registry, access files, and authenticate to services — all of which generate logs. Your job is to read those logs and spot behaviour that does not belong.

Windows is the primary target in most enterprise environments, so understand it first. Windows generates event logs in several channels. The four you will use every day are: Security (logins, account changes, privilege use), System (service starts, crashes, driver loads), Application (software events), and Sysmon (detailed process, network, and registry activity — install this immediately, it transforms Windows logging).

For Linux, the critical log files are: /var/log/auth.log (authentication, sudo, SSH), /var/log/syslog (general system events), /var/log/apache2/access.log or /var/log/nginx/access.log (web server requests), and the output of journalctl (systemd journal).

The most important Linux skill for a SOC analyst is reading SSH logs. Failed SSH logins from multiple countries in rapid succession = brute force. A successful SSH login from a country where no legitimate user has ever connected = likely account compromise.

A defender who does not think like an attacker will always be reactive. Understanding the attack lifecycle means you can predict where an attacker will be next and look for evidence before they achieve their objective.

The Cyber Kill Chain (Lockheed Martin) describes 7 stages every targeted attack goes through. Attackers rarely skip stages — they almost always follow this sequence. If you catch evidence at stage 3, you know stages 4-7 are coming and can prepare.

The MITRE ATT&CK Framework is the most important reference document in your career. It maps 200+ specific attacker techniques to the tactics (goals) they achieve. When you see powershell.exe with -EncodedCommand, that is T1059.001 (PowerShell) under the Execution tactic. When you see a process accessing lsass.exe memory, that is T1003.001 (LSASS Memory Dump) under Credential Access.

You do not need to memorise all 200+ techniques. You need to understand the 14 tactics and the top 20 most common techniques in each one. The rest you look up as you encounter them.

The SIEM is the central nervous system of the SOC. All logs flow into it, correlation rules run against the logs, and when a rule matches it generates an alert for you to investigate. Your ability to search, filter, and query the SIEM determines how fast and how deeply you can investigate incidents.

The two SIEM platforms you will encounter most in Indian enterprises are Splunk and Microsoft Sentinel. Both have free tiers. Learn Splunk first — its SPL (Search Processing Language) teaches you how to think about log queries, and that thinking transfers to any other platform.

Alert triage is the core skill of Tier 1. You will receive 50-200 alerts per shift. Most are false positives. Your job is to quickly separate real threats from noise — and escalate the real ones with enough context that Tier 2 can act immediately.

The professional approach to every alert is the same five questions: WHO (which user or system), WHAT (what action was taken), WHEN (exact timestamp), WHERE (source and destination), and WHY (is there a legitimate reason for this?). Answer these five questions and you have 80% of your investigation done.

The most valuable tool in triage is context enrichment. When you see an IP address, immediately: check if it's internal or external, look it up in VirusTotal and AbuseIPDB, find it in your asset inventory if internal, and search your SIEM for all events involving that IP in the past 30 days. This takes 2 minutes and tells you whether you're looking at a known scanner, a compromised workstation, or an attacker's C2 server.

Write your investigation notes in a structured format every time, even for false positives. Your notes are the institutional memory of the SOC. Future analysts will thank you — or curse you — depending on the quality of your documentation.

You don't need to reverse engineer malware as a Tier 1 analyst. But you need to know enough about how malware behaves to recognise it in logs. There are five behavioural patterns that cover 90% of malware you'll encounter.

When you find a suspicious file, your first action is always to check its hash in VirusTotal. Upload the hash (not the file — never upload sensitive files to public services). A file detected by 30+ engines is confirmed malware. A file with 0 detections but suspicious behaviour is a new/custom tool — escalate immediately, as these are often used by sophisticated attackers.

Use any.run (free sandbox) to see what a suspicious file does when executed: what registry keys it creates, what network connections it makes, what child processes it spawns. This gives you behavioural IOCs within 3 minutes.

Threat hunting is proactive — you are not waiting for an alert to fire. You start with a hypothesis ("I think there is a Cobalt Strike beacon in our environment") and then search through logs to prove or disprove it. Skilled threat hunters find attackers who have been living in the network for months, completely undetected by automated tools.

Every hunt starts with a hypothesis drawn from threat intelligence. If a threat actor known to target Indian BFSI organisations uses a specific technique (e.g., WMI event subscriptions for persistence), you hunt for evidence of that specific technique in your environment.

The best hunting tool for Windows environments is Velociraptor (free, open-source). It lets you run VQL (Velociraptor Query Language) queries directly against endpoints in real-time. You can hunt across thousands of endpoints simultaneously — asking "show me every process that accessed lsass.exe in the last 30 days" and getting results in minutes.

When a confirmed incident is declared, everything changes. You shift from investigation mode to response mode. Speed matters — every minute the attacker is active, they are doing more damage. But panic leads to mistakes that destroy evidence and make recovery harder. The IR process is a structured approach that keeps you fast and methodical simultaneously.

India has a specific regulatory dimension: under CERT-In Directions 2022, all reportable incidents must be reported within 6 hours of detection. This means your IR process must include a parallel regulatory notification track, not just a technical response track.

Digital forensics is the science of recovering and analysing digital evidence. In a SOC context, you perform forensics to answer specific questions: What did the attacker do? How did they get in? What data did they access or steal? When did each event happen?

The single most important concept in forensics is evidence preservation. Everything you do to a system after an incident has the potential to destroy evidence. Always image first, investigate the image — never the live system — and document every action you take with timestamps.

Detection engineering is the craft of translating attacker behaviour into SIEM rules that fire reliably — not too often (alert fatigue), not too rarely (misses). A detection engineer is part analyst, part developer, part threat intelligence consumer.

The industry standard for writing portable detection rules is Sigma. Write a rule once in Sigma format, convert it to SPL for Splunk, KQL for Microsoft Sentinel, or EQL for Elastic. This is the lingua franca of detection engineering.

The quality of a detection rule is measured by two metrics: false positive rate (how often it fires on legitimate activity) and true positive rate (how often it fires on actual attacks). A rule that fires 100 times a day on legitimate admin activity is useless — analysts will tune it out. A rule that fires once on the most sophisticated attack is extremely valuable.

Start with high-fidelity, specific rules (low false positive rate) rather than broad rules. "PowerShell spawned by Word" is more precise than "PowerShell executed" and generates far fewer false positives.

Threat intelligence is the practice of collecting, analysing, and sharing information about attackers — who they are, what they want, what tools they use, and how they operate. Good threat intelligence transforms your SOC from reactive (waiting to be hit) to predictive (preparing for the specific attacks coming your way).

Intelligence has four levels. Strategic (for executives): which nation-states or criminal groups are targeting your industry. Operational (for IR teams): active campaigns, current attack infrastructure. Tactical (for detection teams): specific TTPs — which techniques are being used. Technical (for SIEM/firewall): specific IOCs — IPs, domains, file hashes to block.

The most sophisticated malware leaves no files on disk. It injects code into legitimate processes and runs entirely in memory. To find it, you need memory forensics — acquiring and analysing a snapshot of RAM to find hidden processes, injected code, encryption keys, and network connections that no other tool can see.

Volatility 3 (free, open-source) is the standard memory forensics framework. You run it against a memory image (.mem or .dmp file) and use plugins to answer specific questions: what processes were running, what network connections existed, what code is injected into which processes.

Purple teaming is the collaboration between red team (attackers) and blue team (defenders) to systematically test and improve detection coverage. Unlike a traditional red team exercise where the goal is to breach the organisation, purple team exercises are designed to test specific detections and answer a specific question: "If an attacker uses technique X, does our SIEM detect it?"

Atomic Red Team (free, open-source from Red Canary) provides over 1,000 atomic tests — individual techniques that can be executed in isolation to test a specific detection. Run the test, check if your SIEM alerted, and if not — write the detection rule that would catch it next time.

Every enterprise is moving workloads to cloud. An attack in AWS, Azure, or GCP looks completely different from an on-premise attack — different log sources, different attacker techniques, different detection approaches. A SOC analyst who cannot operate in cloud environments will find their role shrinking as workloads migrate.

The most important cloud log source is AWS CloudTrail — it logs every API call made in an AWS account. Attackers compromise IAM credentials, then use AWS API calls to enumerate resources, exfiltrate data from S3, and create backdoor accounts. All of this appears in CloudTrail.