Cyber Attacks

11.1 Incident Response Lifecycle Recap

11.1.1 The Lifecycle and Its Core Message

The session opened by recalling where the course stands and what the last session covered: how to identify, contain, and mitigate malware attacks, with a high-level look at how an incident response team should be organized. The key idea from that discussion is worth carrying into everything that follows: the quicker you can detect an incident, the less impact it will have on the organization. Detection speed is the lever that controls damage. The whole lifecycle is built around that one thought.

Why does detection speed matter so much? Because an attack is a race against time. The longer malware sits undetected inside a network, the more machines it can reach, the more data it can copy or encrypt, and the harder cleanup becomes. Think of a small fire in a kitchen: caught in the first minute, one extinguisher handles it; left for an hour, it takes the fire department and the building may be lost. Detection is the point where the organization stops reacting blindly and starts fighting back — every phase after detection (containment, eradication, recovery) only works as well as the time that detection bought.

11.1.2 Phases from Preparation to Post-Incident Activity

The incident response lifecycle has these phases:

Picture the lifecycle as a loop, not a one-way street. Preparation (the documented plan, the trained people, the monitoring tools) feeds detection; detection triggers containment; containment limits what eradication must clean; eradication makes recovery possible; and recovery closes with post-incident activity, whose whole purpose is to feed an improved preparation for the next incident. The loop exists so the next pass through the cycle starts stronger than the last one. NIST's well-known four-step formulation (Preparation, Detection and Analysis, Containment Eradication and Recovery, Post-Incident Activity) compresses these same ideas — the professor's six-phase version simply splits the middle into finer steps, but the logic is identical: detect early, isolate fast, clean thoroughly, and learn.

This earlier material was really the base vocabulary: containment, detection, and response are the key terms, and the whole lifecycle is how they link together in an incident management process or a security incident response process.

The visual shape of the lifecycle is a circle with six numbered stations, one per phase. If you picture it as a clock face, the top-left station (preparation) is where planning happens; moving clockwise, detection sits where monitoring tools watch the network, containment is the narrow gate that isolates the infection, eradication is the deep-clean stop, recovery returns services to normal, and post-incident activity is the last station that curves back to preparation. The key landmark is the detection station: everything after it exists to shrink the damage that a detected incident can cause. The one-sentence takeaway: the loop's value depends almost entirely on how early the detection station fires.

11.2 Ransomware

11.2.1 Encryption Background

Ransomware builds on encryption, so the background matters. Encryption is the process of converting plaintext — the original readable text — into ciphertext — the scrambled, unreadable form — using an encryption algorithm. Think of encryption as a lockable box for text: anyone can look at the box (the ciphertext), but only whoever has the key can open it and read the message inside. A key is the secret value that drives the transformation: you use one key for encrypting and one for decrypting. When the same key is used for both encryption and decryption, it is called private key encryption (also called symmetric encryption). The challenges of private key encryption — mainly, how to share that single key safely between sender and receiver — are what led to the development of public key encryption, where a public key encrypts and a separate private key decrypts.

Encryption sits inside the information security triad, the CIA triad, where it serves the confidentiality pillar: it makes sure only legitimate people can read the data, using the key that the sender shared with them. The description given in the session was: encrypting converts a plain text into a cipher text using an encryption algorithm, with a key for encrypting and a key for decryption. Reconstructed symbolically:

$$C=E_k(P)$$ $$P=D_k(C)$$

where $P$ is the plaintext, $C$ is the ciphertext, $E_k$ is the encryption operation using key $k$, and $D_k$ is the decryption operation. When the same key $k$ does both jobs, that is private key encryption.

A quick sanity check with real numbers makes the pair of equations concrete. Take the plaintext message $P=\text{"HI"}$, the key $k=1$, and the rule "shift each letter forward by $k$ positions in the alphabet" (a Caesar shift). Then $E_1(\text{HI})=\text{IJ}$, so $C=\text{IJ}$. Decryption reverses the shift: $D_1(\text{IJ})=\text{HI}$, recovering the plaintext exactly. Notice the essential property: $D_k(E_k(P))=P$ — decrypting an encryption gives back the original message. Every encryption scheme used in real products, from AES to RSA, must satisfy this round-trip property; it is what makes encrypted data usable by its owner.

The twist is that the same technology built to protect confidentiality can be used the other way around: the attacker is the one doing the encrypting, and the victim is the one who loses access. The victim holds $C$ (their own files, now scrambled) but not the attacker's $k$, so the victim's $D_k$ cannot recover $P$ — and the attacker sells the key back for a ransom. This is exactly why the CIA triad's availability pillar (the "A" in CIA) is what ransomware attacks: the data still exists, and its confidentiality is not breached in the classic sense, but the legitimate owner cannot get at it.

11.2.2 How a Ransomware Attack Works

Ransomware is malware whose main objective is to encrypt all the data on the victim's laptop, desktop, or server. It is not spyware quietly collecting data, and not a wiper that destroys it — the files must remain intact but unusable, because intact-but-locked files are what the victim will pay to unlock. The attack follows a fixed pattern:

Before an infection even lands, there are defenses that make access harder: check whether the email landing in the inbox is from a legitimate source; rely on the inbuilt tools most organizations have that scan attachments; when using open-source components, check that there are no vulnerabilities in them; and install patches whenever they are pushed to systems or software. A patch is a piece of code written by developers to overcome a loophole — a vulnerability — that has been identified in existing software. The patch and vulnerability pair is the classic race: vendors find flaws, ship patches, and attackers weaponize flaws faster than organizations install the patches. Every unpatched system is a standing invitation for the "gain access" step of ransomware.

Real-world: in 2023, the cyber reports detected an unprecedented surge in ransomware attacks — the statistics showed that the average monthly number of reported ransomware attacks in 2020 was 20, and between January 2020 and 2023 it reached 31. Because of existing vulnerabilities, ransomware became easy and common to perform both at the corporate level and at the individual level.

11.2.3 Identifying Ransomware

Some common ways to notice a ransomware attack early:

• Unusual system behavior — a sudden slowdown in system performance.
• Unfamiliar applications running — programs you never observed and that are not part of your day-to-day operations suddenly appear in the running list.
• Sudden access to system files — for example, in Windows, when somebody starts touching the system files under the C drive.
• The ransom note demanding payment appears on the screen.

The strategies for identification go deeper than these symptoms:

Why EDR catches what antivirus misses: antivirus compares file contents against a database of known signatures, so a brand-new ransomware strain with no signature sails through. EDR instead watches behavior — which process talks to which other process, which file is being touched, whether an executable is masquerading as a legitimate name. Ransomware must, by definition, do unusual things (mass-encrypt thousands of files, spawn unexpected processes, phone home to a command server), and those behaviors are what EDR detects even when no signature exists yet.

11.2.4 Containing Ransomware

Containment means making sure whatever is infected does not spread to the rest of the organization's network. The goal is to restrict the impact to the system that has been affected. The practical strategies implement controls that minimize the scope of the event and contain the effects of this unauthorized use within the environment:

The mental model for containment is the blast radius: the goal is not to fix the infected machine (that is eradication's job) but to make sure the damage is bounded to machines already touched. Every minute the infected laptop stays on the LAN, the ransomware has another minute to reach file servers, shared drives, and other desktops — which is why isolation and power-down are first-aid actions taken before anyone investigates the details.

11.2.5 Student Questions: Protecting Backup Systems

A question was posed about the interaction between backups and infection:

A follow-up sharpened the question:

The professor deliberately turned the question into a research assignment rather than answering from memory — and that shape (a scenario where the backup systems also got infected, and you must name what went wrong and what controls would have prevented it) is exactly the shape of the exam question. As starting points for the research, think about controls such as: immutable or write-once backup storage (backup data that even the backup software cannot overwrite), air-gapped or offline backups (a copy that is physically disconnected from the network during normal operation), separating backup server credentials from production credentials, requiring multi-factor authentication for backup administration, and scanning or sandboxing restored data before it returns to production. The key principle is that the backup channel must be one-way: production may push data into the backup store, but an infected production machine must never be able to reach back and modify the stored copies.

A student who had taken the makeup examination raised the recovery side of ransomware:

This question was logged as an explicit agenda item: the level of device sanitization (simple reformat vs. full disk wipe vs. rebuild-from-image vs. hardware replacement) before reintroducing a machine to the network is precisely the recovery strategy content the next session will deliver.

11.2.6 Mitigation: Zero Trust and Risk Response

Mitigation of ransomware starts with having an incident response plan (IRP) in place, slowing the attack down, identifying the ransomware, and implementing a zero trust approach.

The zero trust network, or ZTN (also called the zero trust security model), changes how trust is granted. Earlier, an organization's laptop was trusted based on MAC address binding, and the moment it tried to connect to the corporate network it was connected immediately. With the current technology, vendors such as JetScale and many others provide zero trust models where the device goes through its own set of sanity checks, and only when it has met all the requirements does it get access to the corporate network.

What does the verification actually check? The laptop's identity, and its device compliance — patch compliance and whatever checks the cybersecurity engineers have configured. Once those pass, the device is granted access to the shared drive, the corporate network, or whatever it is trying to access. Compare this with what used to happen with a VPN: provide credentials, or RSA token values, and the connection was made. In the ZTN architecture deployment model, organizations check the identity of the users and the integrity of the users and devices with respect to their locations; the checklist configured by the cybersecurity engineer must be met before the end user gets access.

When to pick which: a traditional VPN is a faster, cheaper fit for low-risk access; ZTN is the choice when the risk assessment says the cost of a compromised device is too high to leave trust implicit.

Whether an organization should go with zero trust or with a traditional VPN depends on the risk: you perform a risk assessment on the organization, project, or business process, and when the risk is identified as high, you do a cost-benefit analysis — will existing systems support this new technology, how much is the cost, how much effort is incurred, and do we have enough manpower with the technical skills to troubleshoot when something goes wrong. Installing a zero trust agent is not the end of the story; support capability matters, because security is just an enabler for the smooth running of business, and the day-to-day operations need confidentiality, integrity, and availability not to be impacted.

Real-world: the same reasoning explains why not every organization has moved to the cloud even though cloud technology has existed for close to five to ten years. The decision depends on regulatory requirements, the risk to the organization, and the cost. A financial organization doing payroll operations without technical people would compare the setup and maintenance cost of a traditional data center against the cloud options, and consider its global presence and availability needs before going with a public service provider — AWS, GCP, or Microsoft Azure — or with a private cloud service provider where requirements are highly regulated.

As part of risk response, remember there are four methods: accept the risk, transfer it (for example by insurance), or implement a control — that is the risk mitigation effort. Mitigation minimizes the risk from ransomware, but the risk will never be zero.

The mitigation approaches discussed were: quarantining the infected files, decrypting with antivirus (antivirus itself is now outdated — most companies have moved from AV to EDR, endpoint detection and response), patching and updating systems, implementing an EDR, and — last but not least — awareness and training.

11.2.7 Mitigation: EDR, Patching, and Awareness

The technical side of mitigation is EDR deployment, patching, and keeping software updated. The human side is equally important:

Most companies so make onboarding include all the cybersecurity modules and regulatory trainings: on a HIPAA-regulated account you are mandated to complete HIPAA training, and banking domains have their own mandated trainings.

This is the physical, administrative, and technical (PAT) control view. The session had discussed technological controls; from the administrative perspective, organizations must run awareness sessions, not only at onboarding but annually — in some organizations this is a mandated control in external audits such as SOC 1 or SOC 2, which require the training to happen at least once a year. Physical controls are the common physical security controls that were already implemented. Together, technical, administrative, and physical controls prevent the risk from ransomware.

The three categories work as a stack: a phishing email is stopped at the technical layer by the email gateway, at the administrative layer by a user who has been trained not to click, and if it still lands, physical controls protect the backup media that the recovery step needs.

11.2.8 Exam Notes

11.3 Denial of Service and Distributed Denial of Service

11.3.1 What DoS and DDoS Are

A denial of service (DoS) attack has one main objective: to make the legitimate users who are trying to access a server unable to reach it. The name says it — you are denying the service. Legitimate persons trying to access the system or network are made unavailable, the business gets disrupted, and the server cannot respond to requests because it is continuously busy with the number of hits arriving at it. The simplest mechanism is flooding the machine or making the system overload.

A distributed denial of service (DDoS) is the same idea executed with distributed computing power. Instead of the flooding traffic originating from one resource, it comes from multiple resources: not one machine attacking one server, but many machines flooding the traffic toward a single target. The main requirement is more computing power, which comes from enabling more systems to support the attack — typically using bots, also called zombie agents.

When to expect which: an attacker with modest resources and a small target may use DoS; anything facing a public cloud service, a large website, or a well-connected organization will almost certainly be DDoS.

The DoS attack exploits a vulnerability — a weakness in the system or network — and the objective is achieved by sending a large volume of traffic: it can be raw packets (back data) or connection requests. The TCP three-way handshake is a good example: the sender sends a SYN, gets a SYN-ACK back, and completes with an ACK. If an attacker continuously sends TCP half-way connections — a SYN flood, sending SYN, SYN, SYN — the server is kept continuously busy responding to SYN requests, and legitimate connections that are still waiting for the handshake to complete sit in the waiting queue. There are many such methods to make a denial of service happen.

With a single machine, the target system or network becomes overloaded and cannot answer legitimate requests. But when many devices form a network together and bombard the system with huge traffic distributed geographically from different machines, that is where the biggest challenge sits. Today, DDoS attacks happen most commonly in cloud service environments, and their number is increasing day by day. DDoS can also happen at the application layer: the user interface of the end user — the functions and features of the website — are attacked and malfunction, so the whole application layer is disrupted.

Real-world: recall the advanced persistent threats (APTs) discussed earlier. The same persistence appears in denial of service as advanced persistent DoS (APDoS): the attack goes on for a longer period, sending terabytes or petabytes of malicious traffic — it can persist for more than a month. The attackers tactically switch between different targets to create diversions among the countermeasures you have implemented. If the attack comes from a single entry point, you can find it and implement mitigating controls; but when advanced persistent attacks arrive from several targets through different mechanisms, it becomes very tough for cybersecurity engineers to identify what is happening. This was noted as one of the latest trends — beyond DoS and DDoS there are N number of attacks in the current environment.

A simple example: a legitimate user sends a web request to a web server, while attackers bombard the server with a large number of requests, so the server becomes busy and may even return a busy response. With a bot master, a distributed computing environment formed from multiple sources acts as one network and attacks one server — that is the distributed case.

Real-world: this is one reason people hesitate to move to a public cloud provider. In a public cloud you get a tenant; in one server there are multiple tenants, each isolated, but the exposure is huge because of the cloud technology. The more exposure you provide and the more you align with the latest technology, the more attacks happen. That is where risk assessment comes in: check what existing controls can address the risks when exposing networks or servers to cloud-based technologies.

11.3.2 Flooding Techniques

Flooding can happen through a number of ways:

The ping flood variant works the same way at a smaller scale: the ping utility's legitimate job is checking connectivity — you ping the IP address and see if it answers — but used continuously, the same tool turns into a bandwidth exhaust. The system stays "up" but its network link is saturated, so legitimate traffic cannot get through.

11.3.3 Identifying DoS and DDoS Attacks

The identification strategies are common and fairly easy to spot:

• Unusual traffic patterns — a sudden surge in traffic volume. With continuous monitoring tools, you see the number of incoming and outgoing packets hitting the load balancers or gateways; a sudden surge is an indication of a DoS or DDoS attack.
• Unfamiliar source IP addresses — packets arriving from IP addresses from which there have been no requests in the last six months or a year. Modern XDR (extended detection and response) tools, similar to SIEM, use AI- or ML-based reasoning: within six months the XDR knows which geographical regions the frequent requests come from. If a request suddenly arrives from Nigeria, South Africa, or another location that never sent requests, the tool immediately triggers alerts to confirm whether the request is from a legitimate resource.
• Slow system performance — responses from the application get delayed. If the typical response was three seconds and now it is taking more than ten or fifteen seconds, or users who normally connect in one or two seconds cannot connect, these are all indications of a DoS or DDoS attack.

The common thread: everything points to the server being busier than it should be, with traffic coming from somewhere it should not be coming from. The "typical response was 3 seconds, now 10–15" threshold is the kind of concrete number the professor gave as a practical alarm level — baseline first, then deviations from baseline are the alarm.

11.3.4 Containing DoS and DDoS Attacks

Containment means the attack must not spread — you block it before it takes the service down:

These are the recommended methods, not the only three — from the critical perspective there are more.

The logic behind each: filtering removes the traffic that should not be there (anomalous patterns, wrong geographies); rate limiting caps how much any single source can demand, so no one sender can monopolize the server; and mitigation-as-a-service moves the fight upstream — the service provider's giant network absorbs the flood and forwards only clean traffic to the production system. The last option is the practical answer to DDoS specifically: when the flood comes from thousands of machines, there is no "one source" to filter, so you need a bigger pipe that can swallow the whole attack.

11.3.5 Mitigating with XDR and API Controls

Mitigation measures include:

The professor's XDR explanation is worth unpacking: correlation is the key word. A single log is nearly meaningless — one server log showing traffic, one load balancer log showing a spike, one VPC log showing a connection — but the same evidence viewed together tells the story. XDR's process engine is the correlation layer: it joins endpoint events with network events with email events, and when the joined picture shows abnormal activity, it alerts. And because it is detection and response, it does not stop at an alert — the tool can act, and threat hunters can be dispatched to confirm and contain, which is what keeps the impact minimal.

Real-world: most security service providers — MSPs, managed security service providers — offer XDR capabilities: CrowdStrike, SentinelOne, Trend Micro, and others. Microsoft's Microsoft Defender has XDR enabled; Cisco has its own; IBM's QRadar now comes with XDR capabilities. Any MNC company subscribing to services at a global level typically goes with XDR. With XDR in place, DDoS attacks, phishing, zero-day attacks, and APTs can all be defended more easily.

11.4 Session Hijacking and Man-in-the-Middle Attacks

11.4.1 How Session Hijacking Works

Session hijacking happens when a legitimate session established between a client and a server gets hijacked by an attacker. The scenario: a victim authenticates to the server, and the server returns a session cookie to the victim. The victim's browser executes a script and sends the session cookie to the attacker; the attacker injects a script; in this way the attacker hijacks the session that was active between the victim and the server.

The hijack can be done in a number of ways, starting with eavesdropping — capturing the user's traffic and stealing the cookies. Cookies are very important here: a cookie is how the server remembers a user, and it allows faster responses to the client's requests — but cookies carry a lot of security challenges, and that is what has resulted in many of these attacks. When an HTTP connection is established, an HTTP cookie is generated: a small piece of information that captures data about the user — the IP address and whatever information the developer has configured to be captured. Attackers take that information, use it to act on behalf of a legitimate user, and try to establish a session as if it were coming from a legitimate person: when a legitimate request comes from person A, the attacker hijacks the session with those cookie values and pretends the request is legitimate.

The professor's scenario contains the full attack chain in miniature. The victim completes authentication (proving identity once), and the server answers with a session cookie — a small token that says "this user already proved themselves, remember them." The browser then executes a script that leaks the cookie to the attacker, or the attacker simply captures it from the wire. From the server's point of view, the cookie is the identity: whoever presents the cookie is treated as the authenticated user. So the attacker does not need the victim's password at all — the cookie has replaced the password as the credential, and stealing it is enough to take over the session. This is why the professor's closing advice in this section emphasizes short-lived session IDs and encrypted connections: if the credential (cookie) is captured and stays valid for hours, the theft is catastrophic; if it expires in seconds, the theft becomes useless.

11.4.2 Cookies, Cookie Banners, and GDPR

Whenever you browse a website, the cookies capture some of your information, and that is why you see the pop-up asking whether you would like to accept or reject the cookies: the site is asking whether you are willing to share that information. There are different types of cookies — functional, mandatory, and optional cookies. Without user consent, outside organizations should not be able to capture cookie information — that is one of the GDPR requirements. To be in compliance, most organizations show a cookie banner that asks for consent. If you reject, the information is not captured; if you accept, another pop-up explains the categories: functional and mandatory cookies need to be stored on your machine for the website to work as intended, while optional cookies are up to you — allow them and they capture, or do not.

The consent banner is not a formality — it is GDPR compliance: the regulation requires that personal data (and cookie data is personal data) be collected only with the user's consent, and that the user be told what is being collected. The banner is the mechanism by which the site asks that consent, and the accept/reject choice is the user exercising control over whether the optional categories may capture their information.

Real-world: earlier sessions were established in plain text; people used to authenticate to websites and the information bearing the cookies would be captured by attackers, who then pretended to be legitimate users. The evolution that followed: cookies were replaced by tokens, and tokens by session IDs, whose lifetime is kept short — valid only until the connection is active, or for a few seconds, for example 5 to 10 or up to 50 seconds depending on the security requirement and regulatory needs. The moment the lifetime is over, the session is invalid even if somebody captured it.

11.4.3 Methods of Session Hijacking

The different methodologies for session hijacking include:

The three methods form a natural sequence: first you must get the token (eavesdropping — a passive capture of traffic containing cookies or session tokens), then you use it in one of two ways — either immediately ride the victim's still-live session (side-jacking, "sidling up beside" the victim's connection) or store the captured token and present it later, when the attacker chooses (session replay). The distinction between side-jacking and replay is timing: side-jacking is same-time use of a live session; replay is delayed use of a captured token, which is exactly why short token lifetimes defeat replay — by the time the attacker replays it, the session ID has expired.

The OWASP project — the Open Web Application Security Project — documents application security vulnerabilities, including the different session hijacking methods, and a developer should write code to prevent them. That is also why session cookies moved to session IDs with short lifetimes: even if somebody captures the session, it becomes invalid once the lifetime expires.

11.4.4 Identifying Session Hijacking

Identification techniques:

The logic of each signal: an attacker using a hijacked session behaves differently from the real user — different IP/location/device (monitor the activity), attacker actions modify the account itself to lock out the owner (account changes), and the extra relay through the attacker degrades the connection (browsing performance). The third signal is subtle: after a successful login, the browser should be idle; if it suddenly slows, something extra — a man in the middle — may be sitting between the user and the server, adding latency to every request.

11.4.5 Preventing Session Hijacking

Recommendations:

These eight map onto the attack chain: terminate sessions and change passwords (undo the damage), short-lived session IDs (make captured tokens expire), HTTPS (stop the eavesdropping step — encrypted traffic cannot be read for cookie values), MFA (add a second proof of identity so a stolen session is not enough), antivirus (stop the keylogger/script that harvests tokens), avoid public Wi-Fi (remove the easy capture point), and awareness (stop the user behavior that starts the chain). Each measure breaks one link; defense in depth means several at once.

Real-world: with the advancement from cookies to tokens to session IDs, and with encrypted communication by default, there are also regulatory drivers: it is an RBI requirement in the banking sector that all communications be over HTTPS with TLS certificates. Note that even TLS has had its own vulnerabilities — TLS 1.1 had vulnerabilities, so the move went to 1.2, which most companies use, and TLS 1.3 has also come into existence — so certificates must keep being updated. Certificates are digital certificates that validate the server, confirming that the request or response comes from a legitimate resource.

11.4.6 The Eight Man-in-the-Middle Attack Types

A man-in-the-middle (MITM) attack is one where the man acts in between the communicating parties. Eight common types were listed (there can be more — this is the high-level list):

The eight types share one pattern: the attacker inserts themselves into the communication path. Sometimes the insertion is at the address layer (IP spoofing fakes the source; ARP cache poisoning rewrites the gateway mapping; DNS spoofing rewrites the name lookup), sometimes at the transport layer (session hijacking steals the token), sometimes at the application layer (email hijacking, cookie stealing, SSL stripping, Wi-Fi eavesdropping). In every case, one or both parties believe they are talking to the legitimate peer — the man in the middle is invisible precisely because he is the address they were told to use.

Real-world: SSL itself is no longer in use — SSL versions suffered many attacks, including the POODLE attacks — so the world moved to TLS (transport layer security), versions 1.0, 1.1, 1.2, and 1.3. The suggestion was to study how exactly SSL stripping works — it is easy to say "downgrade HTTPS to HTTP," but understanding how the downgrade actually happens is the valuable part; the full SSL/TLS handshake process will get more meaningful insight once the syllabus is done.

Identification of MITM attacks: monitor the browser, identify network issues, and — most important — check your site certificates: whether the security certificates are valid. That is why, when you browse a website with an expired certificate, you get a pop-up — the identity of the website is incorrect. Websites serving the public prove their identity by subscribing to a digital certificate, and whenever a user establishes a connection, the browser verifies the identity of the web server at the back end during the SSL handshake; the moment the certificate is confirmed expired or invalid, the connection is ended.

Containment methods: disconnect from untrusted networks, and close active sessions that you think have been compromised. Mitigation controls: software updates; avoid clicking unfamiliar links; use VPNs; always use websites that use HTTPS with valid TLS certificates — never go with a website that does not enable HTTPS.

11.4.7 Email Security: Phishing, Spear Phishing, SPF, DKIM, DMARC

Phishing means impersonating some person — typically by email — and creating a sense of urgency, so that the end user clicks links or attachments and viruses, worms, or other injections get in. Spear phishing is the same technique aimed at a specific group of individuals in the organization: for example the executive level — the CEO, the CFO, one level below the CFO — whose email addresses are available through social networking sites.

When to worry about which: spam filtering handles broad phishing; spear phishing is what threat intelligence, sender authentication (SPF/DKIM/DMARC), and user awareness exist to stop.

Mitigation of phishing and spear phishing:

• Scrutinize the sender's address — implement email gateway / email security gateway controls. The gateways continuously run their own spam rules; if a request comes from a domain that is blacklisted, it is blocked, and grammatical errors are also a sign of a phishing attempt.
• Administrative controls — do not be pressured into immediate action based on urgency; legitimate organizations typically do not threaten your account or demand immediate action. Avoid downloading attachments from unknown senders, especially when the attachment is unexpected. Before clicking a link, hover the mouse over it to see where it actually redirects — for example, in WhatsApp, an Amazon offer with a 30% discount that is not on an amazon URL is a phishing attack. Do not respond — report the phishing attempt to the IT department and delete the phishing email.
• Mitigation steps — education and awareness, enabling spam filters, and implementing email authentication: SPF, DKIM, and DMARC.

SPF — the Sender Policy Framework — is an email validation protocol. Domain owners publish SPF records: a list of the authorized email servers allowed to send email on their behalf, saying "these are my legitimate sender emails." When an email arrives, the receiver checks the record to see whether the sender's domain is an authorized source. If somebody uses spoofing tools to send email, the address the email was actually sent from differs from the domain name the email server is tagged with, and the spoof is caught — protecting one level of spoofing from the spam emails hitting the inbox. Example: for a domain like infosys.com, the SPF record lists the IP addresses authorized to send email for that domain; the SPF check should be cleared first, then further checks follow.

DKIM — DomainKeys Identified Mail — adds one more control: a digital signature binding the mail's identity. It is not only the domain name; the digital signature confirms that the email comes from a specific domain, and validates its authenticity and integrity. If somebody changes the message in between, there will be a DKIM failure — an indication that a spam email is being attempted. It works like the digital signature a sender uses as proof of a legitimate source: the DKIM signature authenticates that the mail came from a legitimate domain only, and it can detect emails sent from a fake domain created on behalf of a real one. These are multiple controls — defense in depth — against phishing and spear phishing.

DMARC — Domain-based Message Authentication, Reporting and Conformance — empowers domain owners to instruct email receivers on how to handle unauthenticated emails sent from their domain. It combines the capabilities of DKIM and SPF and adds reporting and a policy: when SPF has passed and DKIM has passed, the policy can approve the email and send it to the resource inbox; when things are not clear, the policy goes with either the reject option or the quarantine option, depending on how the email security expert has configured it.

Real-world: most email security tools work by enabling SPF, DKIM, and DMARC capabilities. The more controls you deploy, the fewer chances the organization has of being impacted by phishing attacks. A full discussion of SPF, DKIM, and DMARC would itself take one or two sessions; this was the high-level view.

11.5 SQL Injection

11.5.1 How SQL Injection Works

SQL injection is an attack where the attacker identifies a vulnerable input field within an application — such as a login form or a search bar — and crafts a malicious SQL payload: a string of code designed to manipulate the database query. The attacker injects this payload into the vulnerable input field of the application. Wherever there is a login form without restrictions on input validation — where the user can provide input and enter SQL queries, with no validation checks — there are chances of SQL injection. The server executes the malicious code: the application unknowingly submits the user's input, including the attacker's payload, to the database server; the database server interprets and executes the code, potentially compromising the database.

To see why this works, recall what SQL (Structured Query Language) looks like. A relational database stores data in tables: each row is one entity (one user), each column is one attribute (username, password). A login check is a query that asks the database "is there a row whose username and password match what the user typed?" — written in SQL along the lines of:

$$SELECT\ast FROMusersWHEREusername{=}^{\prime }jdo{e}^{\prime }ANDpassword{=}^{\prime }letmei{n}^{\prime }$$

The key detail is how the query is built: the application concatenates (glues) the user's typed input directly into the SQL string. Whatever the user types is treated as part of the query. If the user types jdoe and letmein, the query is exactly the innocent one above. But if the attacker types a payload instead of a normal value, the concatenated query changes meaning. The most famous payload for login forms is ' OR 1=1 -- :

$$SELECT\ast FROMusersWHEREusername{=}^{\prime \prime }OR1=1-{-}^{\prime }ANDpassword{=}^{\prime \prime }$$

The single quote closes the string the developer opened, OR 1=1 adds a condition that is always true, and -- starts a comment that swallows the rest of the query (the password check). The database now returns the first user row — or all rows — because the WHERE clause is satisfied for every row regardless of the password. The attacker is logged in without knowing any credentials. The reference text works the same attack with 'OR X=X' (X always equals X, so the condition is always true) — different letters, same tautology.

SELECT * FROM users WHERE username = '<input1>' AND password = '<input2>'

The danger goes far beyond logging in. The same injection technique can be used to read other tables (dumping customer records or password hashes), modify data, delete rows, or even execute stored procedures — anything the database user account is allowed to do. In one well-known incident, a single SQL injection was responsible for 94,057 attack requests against a site in a single day, which shows how automated the scanning for this vulnerability has become.

11.5.2 Identifying SQL Injection

Identification approaches:

The behavior signal covers cases where no error is visible: the page returns rows it should not (a search bar suddenly returns the entire table), or the application behaves nonsensically. Traffic analysis looks at the payload section of IP packets — the same place where a malicious SQL payload would be riding — so monitoring that section can catch injection attempts in transit.

11.5.3 Containing and Mitigating SQL Injection

Containment steps:

Mitigation controls:

The parameterized query deserves the "important" label the professor gave it, because it is the only control that removes the root cause. Compare the two styles of query construction:

-- Unsafe: input is concatenated into the SQL string as code
SELECT * FROM users WHERE username = '<user input>' AND password = '<user input>'

-- Safe: placeholders (?) stand for the values, input is sent separately as data
SELECT * FROM users WHERE username = ? AND password = ?

With the safe form, the database server knows the query structure in advance — username = ? AND password = ? — and the user's input is bound to the placeholders purely as data. Even a payload like ' OR 1=1 -- is treated as a literal value to compare against the username column, not as SQL to execute; the query returns no rows and the attack fails. This is the definitive fix; input validation (removing quotes, percent signs, equals signs) reduces the risk but is bypassable, which is why the professor's ordering — parameterized queries first — matches industry practice.

11.6 Zero-Day Attacks

11.6.1 What a Zero-Day Exploit Is

A zero-day attack uses a vulnerability in software that is unknown to the vendor. Because the vulnerability has not yet been fixed — and may not even be known — the attacker exploits the code, takes advantage of the vulnerability, and launches an attack against the systems that are vulnerable to the exploit, potentially compromising those systems. Once the zero-day exploit is known, most vendors develop a patch and distribute it to their users.

Why is a zero-day so dangerous? Compare the defenses available against a known vulnerability with those available against a zero-day. For a known vulnerability, the vendor ships a patch, antivirus and IDS signatures can be written, and security teams can hunt for the attack pattern. Against a zero-day, none of those signatures or patches exist yet: the vulnerability is unknown to the vendor, so there is no patch; it is unknown to the security community, so there are no detection signatures; and the attacker has had unlimited time to build a reliable exploit. The victim's only protections are the general-purpose controls that do not depend on knowing the specific flaw — monitoring for unusual behavior, restricting what software can run, and containing any anomaly quickly.

A useful way to see the concept is to track a vulnerability's life cycle:

1. Discovery by the attacker — the attacker finds the flaw first. From this moment until disclosure, they hold a monopoly on exploiting it: the "zero-day window."
2. Exploitation — the attacker uses the flaw against vulnerable systems (weeks, months, or years can pass while the vendor remains unaware).
3. Disclosure — the exploit becomes known, often because the attack was observed or the flaw was independently discovered.
4. Patch and distribution — the vendor develops a patch and distributes it to users, closing the window.

The "zero" in zero-day counts the days between disclosure and the vendor's fix: an exploit used on the same day the flaw is disclosed is a zero-day exploit. The practical message: because you cannot know which software will be hit next, the defense cannot wait for the patch — it must be ready for the unknown.

11.6.2 Identifying, Containing, and Mitigating Zero-Day Attacks

Since there are no signatures to match, identification leans on behavioral observation: systems acting unusually, traffic flows that do not fit the baseline, alerts from security software that watches what programs do rather than what they are named. Containment then bounds the damage — isolated systems cannot carry the attack onward, disabled services remove unneeded entry points, and changed credentials cut off anything the attacker may have learned. Mitigation layers general-purpose defenses:

• IDS/IPS — intrusion detection and prevention systems watch network traffic and host activity; an IPS can drop suspicious traffic automatically, even for attack patterns it has never seen, if the traffic violates expected behavior.
• Application allowlisting — only pre-approved programs are allowed to run; even a novel exploit that drops a new executable cannot execute it. (Contrast with blocklisting, which only stops known-bad programs.)
• Patch management — the discipline of applying vendor patches quickly once they exist; for zero-days, the value is in speed — the shorter the gap between patch release and installation, the smaller the window the exploit can use.
• Threat intelligence — information about emerging exploits and attacker tooling that lets a team prepare before an attack reaches them.
• WAF — web application firewalls sit in front of web applications, filtering malicious requests; the professor noted WAFs are one of the latest techniques used against zero-day exploit attacks, because a WAF enforcing application-layer rules can stop a novel exploit's traffic even without a signature for that specific flaw.

11.7 DNS Tunneling

11.7.1 How DNS Tunneling Works

DNS is the Domain Name System — the service that resolves a name like google.com or facebook.com into its corresponding IP address, after which the request goes to the corresponding server and the response comes back. Tunneling means establishing a dedicated link. In DNS tunneling, the attacker crafts DNS requests that contain malicious data encoded within, seemingly coming from legitimate domain names or subdomains. Compromised, attacker-controlled DNS servers receive the tunnel data with the DNS request; the malicious DNS server extracts the hidden data and forwards it to the attacker. This allows the attacker to establish a covert command channel for malicious purposes.

The mechanism in detail: the attacker routes the DNS requests to the attacker's server. When you browse google.com, the request should go to the DNS server, which finds the IP address, and the request should continue to the actual Google server and get a response. In the attack, the DNS requests are routed to the attacker's servers instead, and a covert tunnel is established: the requests travel through the tunnel to the attacker, and whatever the attacker wants to change gets changed — malware can be added, or anything else. DNS traffic is allowed through the firewalls, so the tunnel is not directed by them; once established, the attacker passes a payload from the victim machine inside the corporate network to an internal hosted server controlled by the attacker. The result is a covert, invisible, secret communication channel for malicious purposes.

The full attack flow:

The covert channel works because DNS is an allowed, ubiquitous protocol: every device must resolve names, so the firewall cannot simply block DNS without breaking internet access. The attacker exploits that trust by encoding data into the parts of DNS messages that are normally variable — most often the subdomain label of the queried name (data hides in the text before the registered domain) and the response records. To a monitoring tool that only checks "is this a valid DNS query?", each packet looks routine; to the attacker, the labels are a data pipe.

11.7.2 Identifying DNS Tunneling

Identification signals:

Each signal exploits a telltale of tunneling: real users resolve many different domains a few times each, so a flood of queries to one domain is abnormal; real domains have readable names, so names full of random characters or underscores (which are legal in DNS labels but rare in normal use) stand out; and a resolver handling thousands of tunnel queries is slower and more loaded than one handling ordinary traffic. The professor's first signal also notes the traffic volume side: exfiltrating meaningful amounts of data through DNS requires many queries, so the volume itself gives the attacker away.

11.7.3 Mitigating DNS Tunneling

Mitigation controls:

Best practices to prevent DNS tunneling: block domains based on their reputation; create stringent rules restricting the size and type of inbound and outbound queries; and harden the client OS.

11.8 Additional Malware Types (Knowledge Background)

11.8.1 Fileless Malware

Fileless malware does not install anything initially. Instead, it makes changes to files that are native to the operating system — such as PowerShell or WMI. Because the OS recognizes the editing of its own files as legitimate, a fileless attack is not caught by antivirus software. Because these attacks are stealthy, they are up to 10 times more successful than traditional malware attacks. There is no new file getting installed — that is why it is called fileless — but the malware edits OS-level files and PowerShell files and stays undetected by antivirus.

The mechanism: instead of dropping a malicious .exe, the attacker abuses tools the operating system already trusts and ships with. PowerShell is a scripting and automation environment built into Windows; WMI (Windows Management Instrumentation) is the Windows management framework. When malware executes commands through PowerShell or alters WMI objects, the operating system sees its own legitimate components running — which is exactly what antivirus expects to see. The malicious activity lives in memory and inside trusted tooling, not in a new file, so the scanner's "look for new suspicious files" model finds nothing. The professor's statistic — up to 10 times more successful than traditional malware — reflects this advantage: traditional malware gets caught by signatures once its file is known; fileless malware leaves little for a signature to match.

Real-world example — the Asteroid campaign (the name as used in the session):

11.8.2 Spyware, Adware, Trojans, Viruses, and Worms

• Spyware — spyware is about collecting information about the user's activity without their knowledge or consent. It is not limited to the desktop; it can also operate in a critical app or on a mobile phone. Where cookies are passive files with limited reach, spyware is active code that can read the registry, capture keystrokes, and watch browsing — anything a program can do.
• Adware — its main activity is to see what you are doing and, based on that, populate related ads. The danger is mainly from the privacy perspective: the data captured by adware is correlated with the data captured — overtly or covertly — about user activity on the internet, and the tool profiles the person — interests, friends, and so on — to show only related ads. Adware is often bundled with another program, quietly installed as part of a free download.
• Trojan — a trojan is a program that masquerades as something desirable; once downloaded, whatever information is happening in the machine — all the credentials — is passed on to the receiver. Trojans gain access in several ways: through backdoors, through built-in software, through unintentional software, or through flash drives. Once in place, trojans can be used by malicious actors to launch attacks or conduct ransomware attacks.
• Virus — the overall job of a virus is to damage software or system files.
• Worm — a worm self-propagates over the network, spreading on its own.

The Trojan takes its name from the wooden horse of Troy: it looks like a gift and carries an army inside. The professor's spread list (backdoors, built-in software, unintentional software, flash drives) shows the trojan's defining trait — the victim invites it in by running something that seemed useful. The worm is the opposite extreme: it needs no invitation at all, which is why the WannaCry ransomware of 2017, which combined worm-like self-propagation with encryption, spread so fast.

11.8.3 Rootkits, Keyloggers, Botnets, and Wiper Malware

• Rootkit — a rootkit gives the malicious actor remote control of the victim's computer with full administrative privileges. It is injected at the kernel level or hypervisor level, and spreads through attachments, malicious downloads, and shared drives. Because it operates at the deepest levels of the system, it can hide its own files and processes from ordinary inspection — the classic rootkit modifies the very tools an administrator would use to find it.
• Keylogger — a keylogger can be software or hardware. It logs the keys you type, and those keystrokes are sent remotely — so it is exactly what it sounds like: logging the keys. A software keylogger runs on the machine; a hardware keylogger sits between the keyboard and the computer (e.g., a small device on the USB port) and captures every keystroke regardless of what software is installed. The professor's point about remote delivery is the danger: the log of typed passwords, account numbers, and messages is transmitted to the attacker, not stored locally where the victim could find it.
• Botnet — bots are applications that perform tasks and commands; they are used for legitimate purposes such as indexing search engines. When used for malicious purposes, they take the form of self-propagating malware that connects back to a centralized server — those are the bots or botnets discussed in the DoS context as zombie agents. A compromised machine (the bot, or zombie) connects to a command-and-control server; thousands of bots together form a botnet whose combined power the controller can direct — flooding a target in a DDoS attack, sending spam, or spreading new malware.
• Wiper malware — wipe means to erase the data and ensure it cannot be recovered — that is the main functionality of this malware. Wipers are used to take down the networks in publicly operated companies across various sectors, and they are used to wipe away the traces left after an intrusion — covering up the traces weakens the organization's ability to respond, and the traces stay undetected.

One student asked to see the list:

Wrapping up: the attacks covered in this chapter were session hijacking, phishing and spear phishing, zero-day, DNS tunneling, SQL injection, denial of service and distributed denial of service — with the identification, containment, and mitigation strategies for each, plus email security through SPF, DKIM, and DMARC. The next session continues with strategic defense methods and defense in depth controls. Chapters 6 and 8 remain to be covered, and they are mostly critical reading; chapter 5 and chapter 7 are the more technical ones.

Exam Guidance Summary

• Quiz two syllabus: chapters 4, 5, and 7. (Quiz one covered chapters 1 to 3.) Chapter 5 and chapter 7 are the technically important chapters; chapters 6 and 8 are mostly critical reading, with nothing specific to explain, and can be covered quickly.
• Ransomware (exam note): this is in the syllabus. Expect the question on what ransomware is, and what preventive and detective controls you can implement so that the impact can be minimized.
• Backup scenario questions (exam note): expect scenario-based questions in the main examination — a scenario where the primary system was infected and even the backup systems got infected. Be ready to answer what went wrong, and which technical controls would have been implemented so the virus, malware, or ransomware never spreads to the backup systems. The assignment scenario is an example; the exam scenario will be similar in method, not the same.
• Man-in-the-middle scenario questions (exam note): a scenario may be given — for example, an email hijack has happened, or IP spoofing — and you will be asked which attack this comes under, and, as a cybersecurity expert, what your recommendations are to mitigate this sort of attack. Answer in that shape: what the attack is, why it happened, and the recommendations.
• SSL stripping (study advice): it is easy to say "downgrade HTTPS to HTTP," but try to understand how exactly the SSL stripping downgrade happens — it is one of the most important things to grasp. Deeper insight into the SSL/TLS handshake will come after the syllabus is done; browse to see how SSL stripping occurs when time permits.
• Email authentication (study advice): SPF, DKIM, and DMARC were covered at a high level; a full discussion of SPF and DKIM would itself take one or two sessions.
• More malware types: fileless malware, spyware, adware, trojans, viruses, worms, rootkits, keyloggers, botnets, and wiper malware were covered for knowledge perspective only — not from the exam perspective.

Key Industry Applications

• EDR and XDR in practice: endpoint detection and response and extended detection and response have replaced traditional antivirus in most companies. Managed security service providers (MSPs) offering XDR capabilities include CrowdStrike, SentinelOne, Trend Micro, and others; Microsoft Defender has XDR enabled, Cisco has its own, and IBM QRadar now comes with XDR capabilities. XDR correlates logs from endpoints, network, servers, load balancers, and VPC logs, and defends against DDoS, phishing, zero-day attacks, and APTs.
• Zero trust networking: vendors such as JetScale provide zero trust network models — never trust, but verify — where identity, device compliance, and location are checked before access is granted to the corporate network or shared drives.
• Cloud services and risk: organizations weigh regulatory requirements, risk, and cost before adopting AWS, GCP, or Microsoft Azure, or a private cloud provider for highly regulated environments; public cloud exposure is one reason DDoS risk assessment matters.
• DDoS mitigation as a service: security service providers absorb and redirect attack traffic so production systems stay available.
• Email security stack: SPF, DKIM, and DMARC are enabled by most email security tools to authenticate senders and block phishing and spear phishing; email security gateways run spam rules and blacklist checks.
• Regulatory drivers: GDPR drives cookie banners and consent; the RBI mandates HTTPS with TLS certificates for banking communications; HIPAA mandates security training; SOC 1 and SOC 2 audits mandate annual awareness training.
• Web application defenses: parameterized queries, web application firewalls (WAFs), IDS/IPS, and continuous web application security testing are the industry techniques for SQL injection and zero-day attacks.
• DNS security: DNSSEC and DNS filtering solutions analyze DNS traffic, block suspicious domains, and protect DNS response authenticity and integrity.
• Real-world phishing example: the WhatsApp "Amazon offer" message promising a 30% discount is a phishing lure — hovering over the link shows the URL is not an amazon URL.