Threats in Depth: Threat Hunting, Threat Intelligence, Threat Modeling, APTs, and Indicators

4.1 Course Context and Roadmap

4.1.1 What We Covered in Chapter 1

We are working through chapter one of the course, which builds the core concepts of computer security. This session stands on that foundation, so let us revisit the pieces we have covered so far.

The first building block was the CIA triad — the three core goals of security: confidentiality (only authorized people can see data), integrity (only authorized people can change data), and availability (authorized people can access data whenever their business needs it). Next came the AAA concepts: authentication (proving who you are), authorization (what you are allowed to do once your identity is proven), and accountability (logging what you did so that actions can be traced back). We discussed what a threat is — anything that can harm an asset — and what threat events are: the specific moments when a threat acts against a system. We also met the basic idea of threat modeling, which today we revisit in much more depth. Finally, we covered the theory behind security functional requirements — the idea that when developers build code, they must add security functional requirements into the software rather than bolt security on afterward.

From there we moved to attack surfaces and attack trees. An attack surface is the sum of all the places an attacker can reach into a system — every open port, service, interface, and entry point. An attack tree is a diagram that breaks one attack goal into the sub-goals that must be achieved, so defenders can see where to block. Together they give two complementary ways to think about how an attacker could get in.

We then reached computer security strategies. The strategy discussion centered on a "wheel" that shows how controls are deployed at different layers with different methodologies. Each spoke of the wheel addresses one area of defense:

Cloud security deserves special attention, because most organizations are moving to public or private clouds. Cloud service providers (CSPs) such as AWS and GCP provide the infrastructure; we, as cloud clients, consume those services. The key question there is the RACI matrix — who is responsible for which activity. We went through the high-level service models and highlighted the important areas where the client's responsibility differs from the provider's:

If I am a customer of AWS, what is AWS responsible for, and what am I responsible for? That split depends entirely on the level of subscription — software as a service, platform as a service, or infrastructure as a service. And if the organization's whole focus is on data security controls, there are specific approaches and tactics to implement, which that part of the wheel discusses.

Real-world: AWS and GCP as cloud providers, the SaaS/PaaS/IaaS shared-responsibility split, and the RACI matrix (who is responsible for which activity) are exactly how real engagements between a client and a cloud vendor are structured — a vendor's proposal for a cloud migration project is built around these three questions before any security control is chosen.

4.1.2 What Comes Next: Models for Achieving the CIA Requirements

Before closing chapter one, we looked ahead to chapter two. When you want to achieve authentication, a simple username and password is one method of identifying a user; if authentication succeeds, the user can log into the server or system. But behind that front end sit models developed as a base. For each CIA goal, scientists designed back-end models that product developers can build on:

So for the CIA triad, at the front end we deploy tools, but those tools need to be built on these models at the back end. Bell-LaPadula is a confidentiality model: a subject cannot read data above its clearance level, and cannot write data down to a lower level — this stops secrets from leaking downward. Biba is the integrity mirror image: a subject cannot write up to a higher integrity level, and cannot read down from a lower one — this stops untrusted data from corrupting trusted data. Clark-Wilson protects integrity through well-formed transactions and separation of duties. Lipner's integrity matrix combines the Bell-LaPadula and Biba rules into a single matrix for practical systems. For availability — making sure legitimate people can access resources whenever they need to for their business — we will look at how to achieve it. The chapter goes into each model in depth; today we only need the preview to see where the roadmap leads.

We also previewed the policy side. Earlier we classified controls into physical controls, administrative controls, and technical controls. In the coming module we focus more on the administrative side: the policies related to confidentiality, integrity, and availability, and how exactly you develop a policy or procedure to achieve a CIA requirement. We will look at what a deadlock is — a situation where two processes wait on each other forever and neither can finish — when a deadlock occurs, and what our recommendations are during development or in the production environment to avoid it. We will also cover denial of service (DoS) and distributed denial of service (DDoS) attacks — what they are and how to overcome them — including worked examples like network flooding attacks and how they happen.

So chapter two answers: now that we understand the CIA triad, what models did the scientists develop so that people building software can use them to achieve the CIA requirements at the base level? We will also touch on what a security policy is and what it covers, the different types of access control (something you know, something you have, something you are), multi-factor authentication (MFA), and how to achieve CIA through policies and models with examples of overcoming availability issues. After that we shift toward networks: when a connection is considered an internet versus an intranet, how two systems connect, and the connecting devices starting from the hub (an unintelligent device) to switch to router and beyond, plus the basics of the seven-layer OSI model — physical, data link, network, transport, session, presentation, and application.

4.1.3 Today's Topics and Exam Scope

Today we go deeper into four connected topics and one pair of indicator concepts:

• Threat hunting — what it means and what to understand from it.
• Threat intelligence — what it means and where the information comes from.
• Threat modeling — a threat model perspective, with more scenarios and practical examples.
• Advanced persistent threats (APTs) — what they are, examples of real APT attacks, and how we can prevent or detect them. This is not in the syllabus, but people in the industry are commonly asked about it, so we go in depth to conclude chapter one.
• Indicators of attack (IOA) and indicators of compromise (IOC) — the newest part of the session.

Think of today's session as a pyramid: the syllabus topics (hunting, intelligence, modeling) form the examinable core that you must be able to explain and compare, while APTs and IOA/IOC form the professional layer beneath it — the vocabulary you will hear daily in a security operations job, even if no exam question asks for it directly.

4.2 Proactive versus Reactive Security

4.2.1 The Two Approaches

Would you rather treat a disease after it has spread, or stop it before it starts? That question is the whole debate between reactive and proactive security, and every method in today's session exists because of it.

There are two ways to approach security: reactive and proactive. In the reactive approach, you act only after something has happened — once an incident has occurred, you react to it, with the goal of minimizing the incident's impact as much as possible. In the proactive approach, you take measures before an incident happens — you look for weaknesses and threats while the system is still healthy, so that the incident either never occurs or lands on a smaller target.

The honest position underneath all of this: we can never make any system 100 percent secure. Security is not a switch that can be flipped to "safe"; every system has a residual risk that no amount of controls removes. So we try to maintain an infrastructure that is as secure as we can keep it, and at the same time, if something happens that is outside our control, the impact should be as small as possible. Both approaches chase that same goal — minimize the impact to the systems and to the organization — through different timing.

The analogy maps cleanly: reactive security = the fire engine (respond after the incident, minimize impact); proactive security = sprinklers, drills, inspections (measures taken before an incident happens). The analogy breaks where the physics differ — a fire engine's response time is measured in minutes, while a security incident's dwell time is often measured in days or months, which is exactly why proactive methods matter so much in security.

4.2.2 Control Classifications Recap

Two ways of classifying controls were recapped, and both classifications are needed to describe a single control. One classification is by nature:

• Physical controls are the things you implement at the physical level that you can actually see — locks, guards, walls.
• Administrative controls are the organization's policies and procedures — whatever has been drafted as documents.
• Technical controls are about using technology to achieve or control something — software, hardware, or configuration.

The second classification is by how the control works: is it trying to prevent something (preventive), detect something (detective), correct something (corrective), or deter somebody — make them afraid — (deterrent)? That gives preventive, detective, corrective, and deterrent controls, and so on. The two classifications are independent — an access-control list on a server is a technical, preventive control, while a security awareness training session is an administrative, preventive control.

4.2.3 Why Detection Speed Matters

Once this classification is clear, the principle follows: we should always try to prevent something — that is the first approach. If you are not able to prevent it, the next step is to detect it as early as possible. The quicker the time it takes you to detect that an incident is happening, the smaller the impact on the organization — "very very very minimum," as the class put it. But if the amount of time between the incident happening and your detection is long, then by the time you respond, the attack has already done the maximum damage it was trying to do.

That is exactly the reason threat hunting, threat intelligence, and threat modeling exist: they are different methodologies, different ways, so that we can at least reduce the impact that is happening to our systems or our organization. Each attacks a different part of the problem — threat intelligence tells you what is coming, threat modeling tells you where it can land, and threat hunting looks for what is already inside without your sensors having fired.

4.3 Threat Hunting

4.3.1 What Threat Hunting Is

The name says it: hunting means you are actively searching for something. In threat hunting, what you are hunting for is threats — things that can harm your assets. An asset is anything valuable to the organization: your laptop, your desktop, your databases, your networks — anything where the organization's data is stored. The activity is carried out by trained individuals and experts called threat hunters. They actively search to identify scenarios that may result in a threat to the organization, and once they identify one, they try to isolate those advanced threats — the ones that try to bypass the controls you have implemented. So threat hunting is a proactive process done by security engineers or threat hunters.

The key contrast: threat hunting is not about waiting for something to act. You are not waiting for the alerts in your SOC (security operations center) — where you have monitoring tools and around-the-clock alerts configured for your infrastructure — to be triggered so that you react and resolve an issue. Threat hunting proactively looks for the hidden areas, the hidden ways, where somebody is trying to bypass your existing security solutions. You are proactively seeking the hidden threats already lurking in your system.

Threat hunting is best understood as a process rather than a single tool or action — a loop that skilled analysts run again and again against the telemetry the organization already collects:

A typical hunt runs through five steps:

1. Form a hypothesis. Pick a specific behavior an attacker would need to show (odd logins, unusual outbound connections, unusual process chains).
2. Collect evidence. Pull the relevant records from the EDR, the log collection platform, or other telemetry sources for the time window of interest.
3. Search and analyze. Look for the pattern across the whole environment, not just one machine — attackers move laterally, so the evidence may be spread out.
4. Decide. Confirm the threat (and contain it), rule it out, or flag it for follow-up.
5. Improve. Turn what was learned into new detection rules or better hypotheses for the next hunt.

The one-line recap: threat hunting is a proactive, human-driven process that deliberately searches for threats that evaded automated detection — and it exists precisely because detection speed decides damage.

4.3.2 Assets and the Data Lifecycle

To hunt threats you have to know what you are protecting. Data flows through a data lifecycle management process: starting from collection, then processing, then sharing with sub-vendors or subcontractors (for example, sending data to AWS to process), then storage. Once a contract expires, retention rules apply — that is where retention comes in — and finally deletion of the data.

In every one of these phases, whether you are a service provider for a client, the data must be handled securely: data at transit (moving between systems), data at rest (stored), and data at processing (being worked on) all need security. Threat hunting is one of the processes that keeps all of these phases secure proactively, before an incident happens — because an attacker who exfiltrates during the sharing phase leaves different traces than one who tampers during processing, and a hunter checks both.

4.3.3 Event, Alert, Incident, Security Incident, Breach

A common chain of terminology runs through every security operation, and the class was asked to work out the interlink: events → alerts → incidents → security incidents → breaches.

The professor noted that only a handful of students respond to such questions even though the class has close to fourteen participants, and stressed that attempting is more important than being right — even a wrong answer helps you build the link, and for the teacher it makes the explanation easier to target. That is the point of the chain: each stage is a decision point, and you can only move along it if you understand what each term means.

The full explanation, step by step. Our systems generate many events — on Windows laptops, desktops, servers, and so on. An event is simply something that happened: a process started, a user logged in, a packet arrived. We do not need to monitor all of them. We define what is required for us to monitor and we set threshold values — values we define, and when something crosses them, the event is triggered to our monitoring tool. That is when an event turns into an alert.

The next stage: those alerts can turn into an incident. When we say an incident has happened, something resulted in an event — for example, a backup has failed, or somebody is unable to access a web server. Incidents can be operational incidents or security incidents. An incident is termed an information security incident when it impacts the CIA triad: if it impacts the confidentiality of your data, the availability of your systems, or the integrity of your data. And if the incident results in exposure of data — an exfiltration has happened, where an unauthorized person was able to view all the entries in your database or modify all the entries in your database — then that is a breach. A failed backup is an operational incident; a failed backup that lets an attacker restore their own data over your production database is a security incident; and an attacker who then walks out with the whole customer table has turned it into a breach.

Why did we go through all this? Because in threat hunting the point is: we should not wait for an alert to act. Threat hunting will have no alert involved. It is a proactive approach where experts proactively search for threats that are bypassing our security solutions.

4.3.4 Tools That Threat Hunters Use

The common tools deployed for threat hunting include EDRs (endpoint detection and response), IDS (intrusion detection systems), SIEM (security information and event management), and the application security testing family: SAST (static application security testing), DAST (dynamic application security testing), and SCA (software composition analysis). Threat hunters use these tools to identify — proactively, before anything is triggered — whether any threats are bypassing the security controls that have been deployed.

Real-world: EDR, IDS, SIEM, SAST, DAST, and SCA are the standard tool families in a modern security operations team; threat hunters work in these tools daily, and most of their hunts begin as a query in the SIEM and end as a deep dive in the EDR.

4.4 Threat Intelligence

4.4.1 What Intelligence Means in Security

Intelligence is all about knowledge — an individual's knowledge. When you call a device intelligent, it acts on its own. Take networking devices: a hub is a plug-and-play device with nothing like a brain inside it; it just repeats whatever it receives — an unintelligent device. But a router or a layer 3 switch is different: you configure how the traffic needs to be redirected from which port to which port, whether the source IP addresses coming in are on a whitelist or a blacklist, and how much bandwidth to allocate to which IP addresses. That configurability is what makes it an intelligent device.

Threat intelligence works the same way: it is knowledge that you apply to prevent or mitigate cyber threats. It is as simple as knowing who your enemy is. Once you know who is trying to attack your network, system, or database, the next phase is to understand: who are these people, what is their motivation, and what techniques are they using to bypass our controls? Based on that, you can decide the strategies and controls to deploy, and you defend your systems according to their thought approach.

So the sequence is: gather knowledge about the enemy → understand their motivation and techniques → choose controls that match their approach. The country's military does not buy one type of defense for all borders; a security team should not buy one control for all threats.

4.4.2 Sources of Threat Intelligence

Where does the information come from? We have different sources of threat intelligence, and the class listed four:

We cannot improve threat intelligence alone — we are dependent on external resources. The more threat intelligence we have, the more precisely we can deploy the respective security controls at the defending end, so that the impact to the organization can be minimized. This is why commercial threat intelligence is rarely home-grown: the best feeds blend all four sources, because no single one sees the whole picture.

The professor gave a group assignment on these sources: some teams take open source intelligence and provide platforms where we can get OSINT notifications; some take social media intelligence and provide methods for how an organization can gather threat intelligence from social media; and teams were also asked to Google and find out whether there is a fifth category of threat intelligence source. (Many practitioners do count one: intelligence from dark web and criminal-community sources, where stolen data and attack services are openly traded — the class assignment is exactly the kind of research that surfaces this fifth category.)

The reason behind giving an assignment every week: at least it forces you to search and study some terminology related to the topic. When the exam comes, you can recollect what you already wrote in your assignment — because whatever has been discussed in class is what appears in the questions. The pattern can be different and the questions can be different, but the context is the same. Ten to fifteen minutes of research on each assignment is enough to recall it in the examination; a little step ahead — like searching "open source intelligence" and comparing multiple URLs to pick the best — is how you study and gather information on the topic.

Real-world: open source intelligence (OSINT), social media intelligence, and human intelligence feeds are real practices in commercial threat intelligence teams, often sold as subscriptions that blend all four sources — and the fifth, dark web intelligence, is exactly what vendors sell as "dark web monitoring."

4.4.3 Why Organizations Need Threat Intelligence

The chain of reasoning: we want to understand more about threats so we can secure our network and infrastructure; organizations get business from that infrastructure because clients are confident that whenever they share data with us as a vendor or service provider, there are enough controls implemented. Clients do due diligence — different types of audits. Some banking clients come themselves and do their client audits. Non-banking or non-financial sector clients refer to a third-party independent assessment report: it can be a SOC 1, SOC 2, or SOC 3 report (service organization reports), or it can be an ISO 27001 audit. Which one depends on where the business is expanding: in the US, most clients trust the SOC 2 report; some UK companies go with ISO certification. Whatever the wrapper — SOC 2 or ISO — inside it, the controls defined and framed by ISO and AICPA have one overall agenda: achieving the CIA triad.

So as part of proving we achieve confidentiality, integrity, and availability for client data and employee data, one of the controls shown to clients is having a threat engineering team that continuously and proactively monitors possible threats to our environment — and one of those techniques is improving or adding threat intelligence. Threat intelligence is not a luxury add-on; it is a marketable control. A service provider that can point to an active threat intelligence capability answers the client's due-diligence question "what do you do when a new attack appears?" with evidence rather than promises.

Real-world: SOC 1, SOC 2, and SOC 3 reports and ISO 27001 audits are the standard due-diligence artifacts in outsourcing deals; US clients lean on SOC 2, UK clients on ISO certification — and inside both, an auditor checks that threat intelligence feeds actually reach the monitoring team.

4.4.4 Threat Hunting versus Threat Intelligence

Threat hunting is about identifying or neutralizing threats before they can cause significant damage — staying one step above the attacker's point of view and minimizing the impact of a breach. Note again: we are minimizing impact, not nullifying attacks, because no company can ever say "I am 100 percent secure." There is always a thin line of area where attackers can successfully avoid the threats being addressed. Threat intelligence, by contrast, is about understanding the landscape from which threats are coming: knowing who your attackers are, what tactics they deploy, and how we as the defending organization prepare for those attacks.

So: threat intelligence gets inputs from different sources to know the landscape; threat hunting is the proactive approach where our dedicated security experts hunt for where we have chances of getting threats. Both exist to keep the impact of what slips through as small as possible — pick hunting when you need to find what is hiding inside, pick intelligence when you need to know what is coming.

4.5 Threat Modeling

4.5.1 What Threat Modeling Is

Every day brings news of a new threat to information technology — from hackers, ransomware, or unauthorized information disclosure. As a CISO, or as a manager handling a threat hunting team or a threat intelligence team, if I want to ensure that threat impact stays minimum, I need to know where to start. A model, by definition, is already a predefined approach: this is where you start, phase one, phase two, phase three. Threat modeling is knowing where to start, how to identify the threats, and how to assess the impact of those threats being successfully exploited. In one line: a threat model identifies the risks happening to the organization and prioritizes them. Where threat hunting is a proactive approach and threat intelligence is about gathering information, threat modeling is the way we identify those risks, mitigate them, and respond to them.

In the current technology era, threat modeling is used to profile probable attackers and hackers and to identify the most likely avenues of attack — the hardware or software that will be most targeted. Profiling means behaving similar to the attackers: we try to see what avenues exist for them to use our hardware or software as a platform for attacks. As defenders, we then determine the controls needed to protect the system from those threats and decide which to implement based on a cost-benefit approach. The threat landscape overall comes down to hardware and software: we use hardware, deploy software on top of it, do processing, and generate output for our clients. Threats happen either to the hardware (the processing devices) or to the software we use to deliver the expected outcome — those are the two areas to focus on. The controls we choose remain the same families as before: physical, administrative, or technical; preventive, detective, corrective, or deterrent.

Threat modeling ultimately evaluates the threats and risks happening to our information systems. A note on terminology: "information system" versus "system" — the term is always the same, but it differs by context. In the auditing world we call them information systems; in the security world we call them normal systems. The evaluation tries to identify the likelihood — the chances — that a threat will succeed, and it assesses the organization's ability to respond to those threats — how well we can defend or respond. Both sides matter: a threat with high likelihood but easy to absorb may rank below a rarer threat the organization cannot handle at all.

4.5.2 Cost-Benefit Analysis

Even a good control is not automatically worth deploying. We must do a cost-benefit analysis: what is the cost incurred to deploy, for example, multi-factor authentication on an application before a user logs in, versus the actual value of the information sitting in that server? If the control cost is less than the value of the data, it is good. If the control cost is more than the value inside the server, there is no benefit.

The professor's worked example from daily life: you have a home. The value of the goods inside that home is 10 lakhs. The controls you implement in depth — a layered approach: a CCTV camera, a dedicated physical security person guarding around the clock, and a 10-foot wall surrounding the entire home — cost 15 lakhs every month. But the actual asset value inside that home is only 5 lakhs. Is that beneficial to the person who did it? No. Should you go ahead and apply those controls? 99 percent of the time, no. (Note: the asset value was mentioned as 10 lakhs at the start of the class example and 5 lakhs a moment later. Either way the verdict is the same — 15 lakhs a month of control cost exceeds both figures, so the controls fail the cost-benefit test.)

The one percent where you must think again: if that requirement comes from regulators, or from financial bodies based on your type of business, you are mandated to follow it or you cannot do business at all. A new company entering the banking sector — take Paytm — must follow what the regulator (the RBI, the Reserve Bank of India) sets. If it does not follow, you know what happened in the news about Paytm in the recent days. So even when deploying a control we do a cost-benefit analysis, and based on it the business owner decides how to take it forward.

Real-world: this regulatory override of pure cost-benefit logic is the standard practice in banking — think of RBI-regulated payment banks like Paytm, or any financial mandate that leaves no choice but to implement the control. The cost-benefit analysis decides which controls; regulation decides that some controls exist.

4.5.3 The Three Goals of Threat Modeling

Remember the three goals of threat modeling.

Goal 1 — Identify our security requirements. Security requirements exist to protect our data, our client data, or to adhere to regulatory requirements — we have different requirements for different situations. If we run a dedicated project for a client, the client has their own security requirements. A financial or banking client may say: "I need a dedicated ODC — an offshore development center. Only the people doing the project for that client are allowed access; nobody else." To win that project, a service provider like IBM, TCS, or Infosys creates an ODC and implements the physical controls the client demanded. The client may also require a background verification before an employee is onboarded, and they define what that background verification means — sometimes a drug test that must be completed by the employee working on the project. All of this is identifying security requirements.

Goal 2 — Identify the vulnerabilities. Vulnerabilities interlink with the assets we are using: what type of servers, what databases, what versions — so we can understand the appropriate loopholes in those systems. You cannot find the loopholes until you have listed the assets, which is why goal 2 depends on goal 1's inventory.

Goal 3 — Qualify or quantify the risks. In risk analysis you can either qualify or quantify. The qualitative approach rates the risk as low, medium, or high; risks rated high get first preference, then medium, then low. The quantitative approach puts a number on it: it multiplies likelihood and impact into an expected loss.

4.5.4 The Four Ways to Respond to Risk

Remediation means responding to the risk, and there are four different approaches:

So the four options: risk acceptance, risk transfer (insurance), risk mitigation (implement controls with cost-benefit analysis), and risk avoidance (stopping the business or project). Some frameworks split mitigation further into "reduce likelihood" (controls that make the attack harder) and "reduce consequence" (backups, disaster recovery, replication so the blow is softer), but the four-way classification is the standard core: accept, transfer, mitigate, avoid.

4.5.5 Common Threat Modeling Frameworks

When we say "model," somebody has already defined and developed it — we use those models for our organization. The available frameworks include STRIDE, DREAD, PASTA, VAST, OCTAVE, and NIST. NIST — the United States national standards body — must be followed by US organizations processing US government data. NIST has its own standards for everything: if you want to store data, there are controls to implement; for cybersecurity controls it publishes the NIST CSF (Cybersecurity Framework); for risk management there are the NIST SP 800-53 recommendations; even for hardening a Windows server, NIST has its list of controls to implement.

The one we discussed in the previous session is Microsoft's STRIDE — and STRIDE is an abbreviation, not a word. Each letter means a threat:

The other frameworks approach the same job differently, and the contrast is what you must be able to state in a few lines:

• DREAD is a rating system, not a list of threats: each threat is scored from 0 to 10 on Damage potential, Reproducibility, Exploitability, Affected users, and Discoverability, and the scores rank which threats to fix first.
• PASTA (Process for Attack Simulation and Threat Analysis) is a risk-centric, seven-stage process that goes from defining business objectives to decomposing the application, analyzing threats and vulnerabilities, simulating attacks, and modeling the risk and impact.
• VAST (Visual, Agile, and Simple Threat modeling) is built to fit Agile and DevOps: it uses an application view and an operational view so that developers and infrastructure teams each see the threats relevant to them.
• OCTAVE (Operational Critical Threat, Asset, and Vulnerability Evaluation) is organizational: the organization's own staff run workshops to evaluate critical assets, threats, and current security practices.
• The NIST approach frames everything around its framework (identify, protect, detect, respond, recover) and its control catalog (SP 800-53), and is mandatory for US government data.

Assignment: take one of the other models (DREAD, PASTA, OCTAVE, VAST, or the NIST approach) and give a gist of what its threat modeling is all about compared to STRIDE — three to four lines, for example "STRIDE approach is this, this, this, whereas OCTAVE's approach of threat modeling is this, this, this." Not ten pages. The point is that if tomorrow a question shows a person following a threat modeling approach based on OCTAVE, you should be able to segregate: this is related to STRIDE, this is related to OCTAVE, this is related to NIST.

4.5.6 Where Threat Modeling Goes Wrong

Another way to define threat modeling simply: it is a conceptual analysis of cyber threats which involves putting oneself in the position of an attacker. You think like an attacker and try to see the possible threats to your infrastructure. The aim is to systematically identify the vulnerabilities or risks to your applications or systems in a structured manner at every stage, and then derive the necessary security measures — the controls — based on cost-benefit analysis.

Threat modeling is also an elementary approach: you go element by element through your infrastructure or architecture diagram. You know what traffic is coming in, where it gets processed, where the data is stored, where authentication happens, and where the output is generated for the client. You visit each element of the architecture diagram and weigh how important it is; based on that, you see what threats will happen to those elements. Defining all possible threats for the organization is of elementary importance: you analyze and define which data and which areas must be protected in the company. Suppose you have 50 servers — you do not implement the same number and level of controls on all of them. You look at the criticality and sensitivity of the data being stored or processed in each server, the regulatory requirements applicable to each, and which servers process data for your top 50 clients based on the revenue they generate. From those criteria you say: servers of category A get a high number of controls, then category B, then category C. Some servers may process highly confidential data, some may process PCI data (payment card industry data) — so you understand what data is processed and stored on each server and apply the necessary controls.

Threat modeling is not a one-time design review; it is the discipline that turns "we have 50 servers" into "these three servers decide whether we survive an attack, and they get the controls first."

4.6 Advanced Persistent Threats (APTs)

4.6.1 The Meaning of Advanced and Persistent

As always in cyber security, we start from the base, dictionary meaning. Advanced: like basic level, middle level, intermediate level, advanced level — advanced means the expert level. Not a scripted attack run by a beginner, but a campaign designed and executed by people at the top of their craft.

A second word, just as important for this topic, was looked up next:

With those words clear: an advanced persistent threat (APT) refers to a complex and covert attack executed by highly skilled threat actors — super experts — usually targeting high-profile organizations. These attacks are often backed by nation states or sub-criminal organizations, and they remain undetected inside the victim's network for periods ranging from months to years. None of your detection systems were able to identify that the attack had succeeded in your infrastructure. Put the three words together and the name is the definition: expert-level ("advanced"), hidden ("covert"), and able to stay inside your network for a long time ("persistent").

Two terms worth locking in: infiltrate means entering into the network; exfiltrate means data coming out of the network. Entering a network with proper authorization is no issue. Entering without authorization, being successful, and then maintaining that access is the whole agenda of an APT: the attackers maintain persistence of access, and then collect whatever information they want or compromise whatever systems they want. Typically organizations and governments face this risk, because the losses are huge — financial damage, reputation damage, or the central data being stolen.

4.6.2 The Five Stages of an APT Attack

Just as ethical hacking has its phases (six or seven, starting with reconnaissance and information gathering), a successful APT attack runs through five important stages:

The stages are a campaign, not a single exploit: the attackers invest time and resources at every step, and the whole loop can run for months. Each stage feeds the next — you cannot infiltrate usefully without reconnaissance, and you cannot exfiltrate anything of value without lateral movement.

A separate administrative question came up about assessment planning:

4.6.3 Reconnaissance

In the first stage, attackers collect information about the target organization — the system or organization they are trying to attack — by inquiring into and reviewing its infrastructure, employees, partners, and customers. They may employ open source intelligence, social engineering tactics, or known vulnerabilities in publicly accessible systems. This is the same information-gathering discipline covered under OSINT in the threat intelligence section, applied offensively.

How do they investigate infrastructure? They want to understand your firewall configuration, which web server you deployed and its version, which email server you use and whether you have an email security gateway, which router brand you use (Cisco, DrayTek, and similar vendors), whether a firewall is in place and what type it is. Every one of these answers shapes the next phase: knowing the router vendor tells them which default credentials and known bugs to try; knowing the email server tells them which exploits are worth building.

They do this analysis using publicly available resources of the particular organization — a technique called passive reconnaissance, because it never touches the target's own systems. To find the DNS and public IP addresses of the organization, there are different online sites that help identify the public IP of the DNS server. They can run traceroute — a utility that shows the path a packet takes from your source to the destination, and reveals whether firewalls sit in between. They can also port scan the target — systematically testing which network ports are open — to learn which services are exposed; each open port is a candidate entrance.

Social engineering tactics are another route: on LinkedIn, a company posting a job requirement like "we need someone to support our Citrix servers" or "support Microsoft Office Exchange email servers" gives away that the organization uses Citrix or Exchange email servers. On the dark web, people keep posting or uploading gathered information. Using all of this, the attackers build at least a high-level understanding of how the organization is structured — and the higher the quality of this understanding, the smaller the chance they will trip a control later.

4.6.4 Infiltration

After gathering enough information about the target environment and knowing its vulnerabilities — for example, "this organization uses Sendmail OS version 10.1 while the latest is version 12" — they try multiple ways in. They may customize malware, or launch phishing attacks. There are two different attacks to keep apart here: phishing sends an email made to look legitimate; spear phishing sends that email to a specific group of people — for example only the executives of the organization: C-level execs, CEOs, CFOs, who are less knowledgeable in the information security domain. The message pretends "your password has expired" or "your account has been locked out, click here to regenerate your password" — the usual social engineering techniques. A mass email to a million addresses is phishing; the same email aimed at six named executives of one company is spear phishing. If the spear phishing succeeds, they gain unauthorized access to the system. The overall objective of this second phase, infiltration, is gaining unauthorized access to the systems.

4.6.5 Establishing a Foothold

Upon entering the network — usually by exploiting vulnerabilities or using the compromised credentials from the phishing attacks — attackers create a foothold by installing backdoors for getting remote access and establishing command and control communication with those servers. A backdoor means gaining access to a system in an unauthorized way, by bypassing the controls — as opposed to the authorized access that everyone knows about. It is a hidden door the legitimate owner never sees. There are countless attacks that show how a backdoor happened; recently, the SolarWinds attack succeeded in exactly this way, getting backdoor access to many organizations' systems. Once backdoor access is achieved, the next stage is command and control (C2): the attacker is commanding and controlling that server or device. Whatever command you pass, the server performs — that is the stage where you establish your control on the target system. The C2 channel also matters for stealth: attackers use it to install more tools, move data around, and hide the whole operation from the defenders.

4.6.6 Lateral Movement

After gaining access to the target network, attackers do not just leave. They move throughout the network to find what information is where: what different servers are available, what assets exist, and which has which type of information — all while ensuring they are not detected by the existing detection techniques. That is lateral movement: attackers move laterally within the network to find valuable assets while still avoiding detection of the malware or whatever was injected. This can involve privilege escalation techniques — for example pass the hash — or using stolen credentials to log in as legitimate users. Pass the hash works like this: Windows systems often authenticate using a password hash (a scrambled fingerprint of the password) rather than the password itself; if an attacker captures the hash from one machine, they can replay it to log in to other machines without ever knowing the actual password. If the attackers successfully log into a server where passwords are stored, they behave in such a way that even the behavior-based techniques you deploy for detecting abnormalities cannot detect them, because they are using legitimate credentials stored on those servers to access the shares and folders they want. From the defender's point of view, the traffic looks like a normal employee working late — which is why the hunt matters.

4.6.7 Data Exfiltration and Persistence

The final stage is data exfiltration — collecting the data and moving it out of the network — while maintaining persistence of the access. So the whole story: gather information, exploit vulnerabilities, establish command and control through backdoors, move across the infrastructure undetected by existing detection mechanisms, and finally exfiltrate the data and stay in. The "stay in" part is what separates an APT from a smash-and-grab: even after their first objective is achieved, the attackers keep the door open for the next round of theft or sabotage — which is why the response must include closing the backdoor, not just stopping the visible leak.

4.6.8 Famous APT Attacks

The class reviewed a few named APT campaigns for reference.

• Hafnium: Microsoft disclosed a Chinese state-sponsored group, Hafnium, that targeted Microsoft's Exchange servers using vulnerabilities to gain access to email accounts; overall they exfiltrated sensitive data. Hafnium is famous for performing attacks on defense, healthcare, and higher education.
• Nobelium: another group involved in the SolarWinds campaign, which continued its cyber-espionage campaign targeting various organizations. In May 2021, Microsoft disclosed that Nobelium launched a wave of attacks using the USAID email system to spread malicious phishing emails — a tool of a legitimate organization turned into a launch pad.
• APT41: targeted various industries including healthcare and telecommunications, gaining authorized access to computers and stealing sensitive information.

So in this way there are dedicated groups sponsored by states, and they follow the pattern: gather information, infiltrate, take command and control, and do the exfiltration of data.

Real-world: SolarWinds, Hafnium (Microsoft Exchange), Nobelium (USAID phishing), and APT41 are the four textbook APT case studies you will hear cited in security briefings — when a briefing says "another APT group was caught," these are the campaign shapes it means.

4.6.9 APT Scenarios You Might See in Monitoring Data

Beyond the theory, here are basic examples of what an APT scenario actually looks like in your environment:

Controls that counter these: in IAM (identity and access management) we have rule-based access (you define the rules), role-based access (you define roles for an end user and grant or deny access based on that role), and attribute-based access (you define attributes, and one parameter can be time — "this system access should happen only between 9 am and 6 pm"; even if you try outside that time, you cannot access). These are security controls you can show so that APT scenarios are minimized. Also: a spear phishing campaign where attachments with PDFs are continuously sent to all the C-level executives in the organization. These are general examples; there can be many more beyond these, but for academic purposes these are good APT scenario examples.

4.6.10 Best Practices to Minimize the APT Threat Landscape

The professor's list of practices organizations should employ so the threat landscape from APTs is minimized:

1. Sensor coverage. Whatever sensors you use for your detection systems, the organization must deploy capabilities that give defenders full visibility across the entire environment, to avoid any blind spots — unknown spots become safe havens for cyber threats. Sensors spot abnormal activity and pass that information to the management console, which analyzes how process-to-process communication is happening and whether any abnormal communication is occurring — triggering blocking of the events that need to be blocked.
2. Technical intelligence. Improve technical capabilities such as IOCs and IOAs (indicators of compromise and indicators of attack, covered next) and consume them into your SIEM. The well-known term SIEM has been replaced by the latest technology — XDR, extended detection and response systems — where data enrichment happens. This gives value-added intelligence because the system correlates multiple inputs: what is happening at the server level, at the network level, at our gateway level — and from that correlation you can find if something vicious is happening. A single event at one layer is noise; the same event echoed across server, network, and gateway is a campaign.
3. Service providers. Partner with the best-of-breed cybersecurity firms — that is important.
4. Web application firewall (WAF). A firewall can be implemented at different layers. If the firewall allows or blocks traffic based on source IP addresses, it is called a layer 3 firewall. If it allows or blocks based on MAC addresses (layer 2 is all about MAC-address-based communication), it is a layer 2 firewall. The web application firewall sits at the application layer — a layer 7 firewall — and is designed to protect the organization at the application level by filtering, monitoring, or analyzing the communication happening in HTTP mode (HTTP or HTTPS traffic) between your web application and the internet. Today, deploying a WAF is one of the techniques to counter zero-day exploits — attacks that exploit a vulnerability no one has patched yet, because the vendor has not even released a fix.
5. Threat intelligence. The intelligence we discussed helps create attacker profiling campaigns and track or identify the malware family involved. These days it is more important to understand the context of the attacker than just knowing the attack itself happened — context is always the most important thing whenever you deploy a control or think about the threats happening to your organization. Knowing "a file was deleted" tells you nothing; knowing "the same group that hit three banks this quarter deleted it" tells you where to look next.
6. Threat hunting. As discussed, threat hunting is performed by a group of security experts who continuously find out where exactly threats are getting in. Many organizations need 24x7 managed, human-based threat hunting to accompany the cyber security technology already in place. And nowadays we have gone beyond human-based: AI-based and machine-learning-based threat hunting — most organizations buying security products now focus not only on humans but also on current technologies that support AI/ML-based threat hunting techniques.

Real-world: CrowdStrike and Carbon Black (acquired by VMware) are examples of well-reputed endpoint security providers using this latest technology. Their agents continuously watch how communication happens between processes on a laptop; if an abnormal process-to-process communication appears — say a process suddenly accessing system configuration files from an external request — the tool triggers an alert or immediately blocks it. That is how endpoint security has moved beyond automation and signatures into EDR — endpoint detection and response.

4.7 Indicators of Attack and Indicators of Compromise

4.7.1 Two Kinds of Indicators

Always remember the method of this subject: when studying a new topic, first understand the base, English-dictionary meaning of the term. An indicator is a sign or signal — something that points to a condition. Here there are two kinds of indicators, pointing in two different directions in time.

Indicators of attack (IOA) means there are indications that some attack is about to happen. In practice, IOA focuses on detecting the intent of what an attacker is trying to accomplish — regardless of whether it is malware or an exploit used in the attack. Just like antivirus signatures, indicator-of-compromise-based detection cannot detect the increasing threats from malware-free intrusions and zero-day attacks; as a result, next-generation solutions are moving to an indicator-of-attack approach. Example: suddenly there is huge email traffic hitting your email gateway security where the attachments are more than expected — that would be considered, by the threat engines, as an indicator of an attack. No single malicious file has been confirmed yet; the behavior — a burst of attachment traffic — signals intent.

Indicators of compromise (IOC) means something has already happened — the compromise is already successful, and you are trying to find out at which stage the attack happened. The professor's shorthand: IOA shows the chances of an attack before it happens; IOC means the attack already succeeded and you are finding the indicators — "the attacker logged into this system and did this, this, this." IOCs are the artifacts or evidence that indicate a system or network has been compromised by a cyber attack. They are typically used in the incident investigation of security incidents: the moment a compromise happens, the incident security response team pitches in and finds out where exactly the compromise happened and whether there is any possibility to mitigate the impact of the breach. IOCs are also described in forensics — deep investigation to identify where exactly the breach happened. Investigators usually gather this data after being informed of a specific incident, on a scheduled basis, or after the discovery of unusual callouts from the network — for example, unusual requests from different ports trying to connect to your web server or to get access to your file servers. Ideally this information is gathered to create smarter tools that can detect and quarantine those files in the future — that is the main objective of IOCs: one benefit for forensic investigation, another for building smarter future tools that quarantine matching files.

4.7.2 The Bank Robbery Analogy

To anchor the IOA idea, the professor walked through how a criminal would plan to rob a bank in the physical world.

4.7.3 Indicators of Compromise in Forensics and Detection

The contrast with IOCs: whereas IOAs point forward, IOCs point backward. For example, malware has executed in the system and is doing a lot — modifying the program files, deleting existing files. All of that indicates the system has been compromised. Once you know a compromise succeeded on one system, you quarantine that system so the compromise does not spread across your LAN, and forensic investigation identifies exactly where the breach happened.

The two indicator types work as a pair across time: IOAs try to catch the attack while it is still unfolding, and when one slips through, IOCs are what let the incident team find where it landed and what it touched. So your indicators of compromise and indicators of attack together help build a strong threat intelligence system in the organization, so that the chances of advanced persistent threats exploiting the vulnerabilities in your systems can be minimized — each confirmed IOC feeds the detection rules, and each observed IOA pattern feeds the next hunt.

Exam Guidance Summary

The exam-facing picture of this session, collected in one place:

• Syllabus scope: The first three topics of the session — threat hunting, threat intelligence, and threat modeling — are part of the syllabus. APTs and IOA/IOC are beyond the syllabus; they are for knowledge and depth, though they are common in industry conversations.
• The internal exam: An internal exam is scheduled for February 18th. The exact syllabus will be confirmed with the administration; typically it covers the first unit or the second unit. The professor plans to make sure the syllabus is completed before the examination so students are academically ready.
• Assignment-based study: Weekly assignments exist so that you study at least some terminology — 10 to 15 minutes of research is enough. In the exam, whatever was discussed in class is what the questions cover; the pattern can be different and the questions can be different, but the context is the same. Recollecting your own assignment work is the study strategy. The professor tracks every submission and shows a completion tracker around the fourth or fifth session.
• Definition-style questions: The recurring method in this subject is: understand the base, dictionary meaning of a term first (advanced, persistent, covert, indicator, threat). Expect definition and meaning questions built on that method.
• Model distinction questions: Be able to tell STRIDE apart from DREAD, PASTA, OCTAVE, VAST, and the NIST approach in a few lines — the kind of distinction that appears in a "which of the following options is correct" question. One identifying feature per framework is enough: STRIDE lists six threat types, DREAD scores them, PASTA simulates attacks, VAST fits Agile, OCTAVE uses in-house workshops, NIST follows its framework and control catalog.
• What is not on the exam: The five APT stages are beyond the syllabus; performing them requires tools and is not exam material. If there is time after the syllabus is completed, out-of-syllabus questions can be discussed in the remaining sessions — students were asked to email their questions about one week in advance.
• The one-line distinctions that anchor the session: reactive acts after, proactive acts before; hunting looks inside, intelligence knows the outside, modeling decides where to act; IOA signals before, IOC proves after.

Key Industry Applications

Where this session's concepts show up in real security work:

• Security operations: SOC and NOC teams, always-on monitoring, thresholds on CPU (85–90 percent) and memory, and the event → alert → incident → security incident → breach chain are the working vocabulary of every monitoring floor.
• Threat hunting tools: EDR (CrowdStrike, Carbon Black/VMware), IDS, SIEM, SAST, DAST, and SCA are the standard tool families threat hunters use to find threats that bypass deployed controls.
• XDR: SIEM has evolved into extended detection and response (XDR) with data enrichment, correlating events at server, network, and gateway levels.
• Threat intelligence sources: OSINT platforms, social media intelligence, human intelligence, and technical data analysis (malware samples, server logs, attacker IPs) feed real commercial threat intelligence teams; social media (LinkedIn job posts) and the dark web are practical OSINT sources.
• Due diligence and audits: SOC 1, SOC 2, and SOC 3 reports (trusted by US clients) and ISO 27001 audits (favored by UK companies) are the third-party independent assessment reports clients demand; inside, the controls framed by ISO and AICPA all target the CIA triad.
• Cloud shared responsibility: AWS and GCP as CSPs, SaaS/PaaS/IaaS models, and the RACI matrix (who is responsible for which activity) govern who secures what in the cloud.
• Regulatory override of cost-benefit: Regulators such as the RBI mandate controls (Paytm example) even when pure cost-benefit analysis says no — 99 percent no, 1 percent mandated yes.
• Banking outsourcing practice: Dedicated offshore development centers (ODCs) with background verification and drug-test requirements are how service providers like IBM, TCS, and Infosys meet banking client security requirements.
• Supply chain risk: The SolarWinds supply chain attack shows how compromising one IT management tool infiltrates US government agencies and Fortune 500 companies.
• State-sponsored groups: Hafnium (Microsoft Exchange; targets defense, healthcare, higher education), Nobelium (USAID email system phishing waves), and APT41 (healthcare and telecommunications) are named campaigns to recognize.
• Network defense layers: Layer 2 firewalls (MAC address based), layer 3 firewalls (source IP based), and the layer 7 web application firewall (filtering, monitoring, and analyzing HTTP/HTTPS traffic between web application and internet) counter zero-day exploits.
• Endpoint modernization: Beyond-signature EDR behavior analysis — process-to-process communication monitoring and blocking abnormal access to system configuration files — is how modern endpoints are defended.
• AI/ML threat hunting: Beyond 24x7 human-based threat hunting, AI-based and machine-learning-based threat hunting is what organizations now expect from security product providers.
• Cyber insurance: Risk transfer through cyber insurance is standard practice for any internet-connected organization, alongside risk acceptance, risk mitigation, and risk avoidance.