Cybersecurity Case Studies

14.1 Final Exam Pattern and Course Wrap-Up

14.1.1 Mark Distribution and Question Pattern

The course assessment combines theoretical and practical content in equal proportion: 50 marks come from the main (external) exam, and the other 50 are internal.

The main exam is built from five questions, each worth 10 marks, so the arithmetic is simple:

$$5\text{ questions}\times 10\text{ marks per question}=50\text{ marks}$$

Every one of those five questions carries two parts, part A and part B. This lets the examiner test two different skills inside a single question — one part may check recall of a definition, while the other asks you to apply the same concept to a scenario. That is why a complete answer needs both parts: answering only part A of a 10-mark question can give you at most a fraction of the marks.

14.1.2 Group Presentations and the Last Session

Group assignments run from group 1 to group 20, with five members in each. The assignment must be submitted by the end of next week. In the next session, each group presents its assigned topic for about five minutes; the document your group has already shared is good enough to explain the topic. One or two follow-up questions may be asked after the presentation to check that the whole group is aligned with what was discussed — so every member should know the material, not just the person speaking.

The final session is interactive: a full recap of the syllabus, with timing adjusted based on how many participate. All eight chapters of the course have been covered, and the chapter notes are confirmed available on the learning portal — this was verified before moving to the final topic.

14.2 Case Study: ASP.NET Credit Card Skimming

14.2.1 The Attack on a Trusted Framework

ASP.NET is a web application development framework that helps developers dynamically create and interact with web applications. Because most organizations use it, a single weakness in how it is deployed can touch hundreds of sites at once.

In this case, attackers injected malicious code into vulnerable websites built with the framework. The injection succeeded because the attackers exploited vulnerabilities in the website code or in the server configuration — the classic root cause being a framework or configuration that was never patched, scanned, or hardened. Once inside, the injected code functioned as a credit card skimmer: it sat quietly inside the payment flow, waiting for customers to type their card details.

14.2.2 What Is a Skimmer

A skimmer is a malicious script, or sometimes a hardware device, designed to steal credit card information. The moment a user enters credit card details on a payment form, the skimmer captures them — the card number, the expiry date, and the card verification value — without the user or the website owner noticing. The stolen data is later used for fraudulent purchases: transactions performed by someone who is not a legitimate account holder, using a card the real owner never authorized.

This connects back to the earlier discussion of cyber crimes: one of the attacker's core intentions is financial gain. Skimmers are the online equivalent of the physical devices bolted onto ATMs — the same idea, the same goal, a different channel.

14.2.3 Impact of the Attack

The compromised websites unknowingly collected customer credit card data. Customers who used those websites were exposed to the risk of fraud — unauthorized purchases made with their card numbers. The organizations running the vulnerable websites suffered two kinds of damage: reputational damage, because customers stop trusting a brand that leaks card data, and potential financial losses, from refunds, chargebacks, fines, and lost business.

The root problem deserves a direct statement: a vulnerability in the framework developers used created a path for attackers to exploit the security gap and capture data entered during transactions. The websites were not hacked because the payment system was weak; they were hacked because the code and configuration beneath the payment system were never secured.

14.2.4 Preventive, Detective and Corrective Controls

Given this scenario — a vulnerable framework, an exploit, and harm to customers and organizations — the natural question is which preventive, detective and corrective controls would have limited the damage. Recall the earlier control categories: preventive, detective, corrective, and deterrent. The priority is always prevention first: stop the event before it happens, detect it if it slips through, correct the damage after the fact, and deter the attacker from trying at all.

For credit card transactions, organizations should also comply with PCI DSS, the Payment Card Industry Data Security Standard. PCI DSS lists multiple requirements designed to keep website transactions safe and secure — from encrypting card data in transit and at rest to scanning and testing the systems that handle it — and compliance would have made this attack far less likely. That is a compliance control: the standard forces the organization to close exactly the gaps this attack exploited.

Organizations should also ensure that critical transactions — the ones that sustain the business — are part of the SIEM or XDR setup. SIEM (security information and event management) collects logs from across the environment, and XDR (extended detection and response) connects endpoints, network, and cloud signals; together they continuously monitor transactions and can both detect and prevent suspicious activity. User awareness and training completes the picture: users should be able to tell a legitimate transaction from a fake one — for example, recognizing a checkout page that asks for card details twice or an email that mimics the payment service.

Implementing these multiple levels of controls at different places is what we call defense in depth: even if one layer fails, the next one is still standing. If the scanner misses the vulnerability, the monitoring catches the odd transaction; if the monitoring misses it, MFA stops the purchase; if all of that fails, compliance requirements force a documented fix.

Real-world: as a class point noted, a WAF (web application firewall) is especially valuable for zero-day attacks — attacks that exploit a vulnerability no one has patched yet. A WAF inspects web traffic at the application layer and can detect abnormal process-to-process communication and respond immediately, blocking the exploit pattern even before a patch exists.

14.2.5 Vulnerability Notifications: Applicability Comes First

Organizations outsource more and more of their activities to vendors, which is where third party risk management (TPRM) comes in: a dedicated team ensures that every vendor we outsource to stays compliant with organizational requirements and regulatory requirements. In banking, for instance, the bank rarely does the development itself — it outsources development and testing to a service provider, because the core business is banking, not writing code.

When a vulnerability like this is raised, the bank immediately triggers an assessment with the service provider: is this applicable to you? What is the impact to my organization? To answer that, you maintain a repository of vendor information — often called a BRP (business relationship profile; many organizations use their own names) — storing the services each vendor provides, how they provide them, the infrastructure-level connectivity, and the supporting environments. A risk assessment follows, and a published report goes to management: the direct vulnerability impact to the organization is null, but out of 50 vendors, these specific ones use the vulnerable component, we have sent responses to them asking for the impact, and here is the status of their fixes. The organization's own risk may be zero, but the vendor ecosystem's risk still has to be tracked to closure.

14.2.6 Facing Risk: Internal vs Internet-Facing Applications

Not all applications are public facing, and risk changes with exposure. An application built with the vulnerable framework but internal to the organization sits behind multiple levels of controls — network segmentation, authentication, and monitoring inside the perimeter — so the risk to the organization is far smaller. An internet-facing application, reachable by anyone on the planet, is a huge risk: every attacker's scanner can find it, and every exploitation attempt is aimed directly at the asset. The same vulnerability in the same code has two very different risk values depending on where the application sits.

14.2.7 Responding to a Zero-Day and Secure SDLC: SAST and DAST

This session is about how you, as a cybersecurity professional, respond when a zero-day attack happens or a new vulnerability is published. The cycle is understood: vulnerability leads to attackers exploiting that vulnerability, which results in damage. The response is the differentiator — the same vulnerability causes little harm in an organization that is ready, and a disaster in one that is not.

You identify the vulnerability either through a published bulletin or through a bug bounty program, where a security researcher hands you a loophole in your application — often before the attackers find it, and usually in exchange for a reward. If the vulnerability applies to your organization, you fix it with the available patch.

Even if a zero-day attack still succeeds, the regulators that come to verify due diligence will see that enough controls were deployed and that they work — and the fines and financial implications will be far less than if no controls existed. This is the practical value of documentation plus working controls: regulators punish negligence, not bad luck.

14.2.8 Prescribed Fixes and Lessons Learned

For this specific case, the prescribed fixes are:

• Secure coding practices — write the payment and checkout code with security in mind from the first line, not as an afterthought.
• Data input standardization (validating every input) — treat every field the user can type into as hostile until proven safe. Validation rejects unexpected characters before they can reach a database query or a script interpreter, which is the direct defense against injection attacks such as SQL injection.
• The use of stored procedures for database interactions to reduce the risk of SQL injection. A stored procedure fixes the query structure on the database server and treats the input as data, not as executable SQL, so an attacker's injected command cannot change what the query does. The stored-procedure choice is a database-level detail where application security specialists have deeper insight.

Lessons learned: organizations that build websites must be proactive, follow best practices, and implement strong controls to protect their websites and customer data. Business is competitive in nature — if your website gets hit by this kind of vulnerability, your competitor will seize the advantage and try to grab your business. Staying ahead of the business means updating your product while still following security best practices: speed and security are not opposites when security is built into the process.

Real-world: the demand for cybersecurity professionals — at the infrastructure level, the application level, and the compliance team — keeps rising because businesses worry about vulnerability exploitation by hackers even as they push for faster development. If you already manage a database as an infrastructure person, you can grow into security: follow the CIS benchmarks (Center for Internet Security) or the NIST benchmarks (the US standards body) to harden your database, secure access at the API level, restrict access at the role or schema level, and build a portfolio of managing databases securely.

14.3 Indicators of Attack vs Indicators of Compromise

14.3.1 Which Comes First: IOA or IOC

14.3.2 Website Indicators of Compromise

Specific indicators confirm that a website has been compromised:

• The site has been defaced — the attacker replaced the normal page content with their own.
• You click the URL and it reacts like a fake website — pages behave oddly, links go somewhere unexpected, or the layout is subtly wrong.
• It repeatedly asks the user to enter the same credit card details multiple times — a genuine checkout asks once; a skimmer asks again and again, harvesting each fresh entry.
• The browser — trying to verify the website's authenticity with its digital certificate — shows a warning or a block message saying the certificate is on the CRL, the certificate revocation list. A revoked certificate means the identity behind the site can no longer be trusted.

14.3.3 Writing Rules for XDR

Instead of waiting for IOCs, organizations write IOA rules based on day-to-day operations: all possible scenarios are written in a language the XDR (extended detection and response) understands, listing every possible attack case at the application level or the infrastructure level. Each rule encodes a known attack pattern as a set of conditions — if this process talks to that address, if this account logs in from two countries in ten minutes, if this file suddenly executes — and the XDR fires an alert the moment a live event matches.

The point of writing rules in advance is timing: by the time an IOC exists, the compromise is already complete. A rule written from normal operations lets the XDR flag the attempt while it is still an attempt.

14.3.4 How AI/ML-Based XDR Learns Normal Behavior

Modern XDRs are AI or ML based. Instead of relying only on hand-written rules, the XDR builds its own model of what normal looks like. On deployment, the XDR takes 30 to 60 days to learn what legitimate or normal traffic looks like; after some months it can spot what is different. It is exactly like a security guard who spends their first month learning the building's rhythms — who arrives at what time, which doors open when — and then instantly notices the person moving against the pattern.

14.4 Secure SDLC and Open Source Software Management

14.4.1 Why Developers Use External Code

Given a business requirement, developers usually know the expected input and the expected output, and they Google it — they check code repositories like GitHub for readily available code to save time, and they reuse open source libraries to deliver the needed functionality faster. From a delivery point of view this is exactly right: why rewrite a well-tested authentication library or date parser when thousands of teams already use it?

That intention is fine; the implications are the problem. Three consequences follow from every third party dependency:

• Legal implications — the code is not yours; its license governs how you may use, modify, and redistribute it.
• License management — open source software (OSS) comes under different license types, and the organization must know whether a library is licensed for educational purpose or commercial purpose before it goes into a product.
• The level of access the plugin or library gets once it is deployed as part of your code — a library that runs inside your application can reach everything the application can reach.

14.4.2 Secure SDLC and Security Requirements

Secure SDLC must be part of the software development lifecycle: security is not a phase at the end, it is a set of requirements collected from the start. Beyond the business requirements, collect the security requirements: what type of data is collected and processed — PII (personally identifiable information, data that identifies a specific person) versus non-PII, financial versus non-financial — and from that, list the applicable regulatory requirements during the initial phase itself.

14.4.3 Vetting Third Party Plugins and Open Source Libraries

Big companies and financial banks run mandatory checks on third party plugins and libraries before any of them reaches production code:

• Is any open source software (OSS) being used in this project? The project team must declare every external dependency — nothing enters quietly.
• Has it been completely vetted before being added to the production code? Vetting covers the code, the maintainers, and the history of the library.
• Has legal signed off, verifying and validating whether the license type fits? Is the OSS for educational purpose or commercial purpose? A library licensed for personal or educational use may not be usable in a commercial product at all.
• Test the plugin in a sandbox environment — a contained, isolated system where the plugin can run without touching production — and check its access level when deployed at the browser level: does it only access the application, or can it reach your program files, or even your memory?

Real-world: real projects run in sprints with two-week deadlines, and a lengthy approval process can stop you from delivering on your committed time lines. The answer is not to abandon the checks — it is to make the checks fast and predictable. Organizations should not build policies reactively after issues happen; they should proactively identify industry best practices and keep maturing their processes.

The information security policy should include an OSS policy: can a user download and use OSS, and if yes, when and how; if not, what process must be followed? Publish the list of OSS libraries approved by the security team; developers search the internal database, and if the library is on the list, the entire lifecycle shrinks — it is already pre-approved. If not, they look for an approved alternative, or coordinate with the security team to get it approved.

14.4.4 What Third Party Audits Check

Real-world: in third party audits of service providers like Infosys or CTS working for banks, the audit team checks:

• how the code is developed — the development practices behind the software;
• which plugins and third party libraries are used — the dependency inventory;
• what type of data is collected and where it is maintained — data flows and storage locations;
• whether an OSS list exists — is there a published, enforced policy;
• and when the open source libraries were last checked in and verified by security — the freshness of the vetting.

These assessments confirm that service providers follow best practices, mitigating the risk of third party plugins and libraries. The audit exists because the bank's security now depends on code the bank did not write — and on libraries inside that code that the provider itself did not write.

14.5 Security Audits and Penetration Testing

14.5.1 Strong Passwords and MFA

Strong password policies and MFA (multi-factor authentication) are basic controls — the foundation every other control sits on. Authentication asks a user to prove who they are, and the proof comes from three factor types:

• Something you know — your password.
• Something you have — a hardware token, for example an RSA token that displays a time-based one-time code that changes every 30 to 60 seconds.
• Something you are — your biometric, such as a fingerprint, face, or retina scan.

14.5.2 Vulnerability Scanning and Tool Database Freshness

Periodic security audits and penetration testing identify vulnerabilities. Security audits can be as simple as regular scans with third party tools like Qualys to keep libraries, plugins, and infrastructure up to date. The scan compares your environment against the tool's list of known vulnerabilities and reports what matches.

14.5.3 Penetration Testing: Scope and Applicability

Penetration testing means trying to enter your system at the application level or the infrastructure level, usually done by a third party. It is an authorized, methodical attack: the tester plans, discovers weaknesses, attempts to exploit them, and reports — the same techniques a real attacker would use, but with permission and a written outcome.

When a pen test report shows no critical vulnerabilities, do not just close the report: research what the scope was, which systems were included, and whether the systems that are part of your business were actually covered by the testing. Test results and practicality can differ, and severity ratings from a tool are not the final word.

Verify the pen test approach itself: which penetration paths were used, whether application-level testing covered the OWASP Top 10 vulnerabilities — the industry-standard list of the ten most critical web application risks, such as injection, broken authentication, and misconfigured access controls — and whether the scope matches your assets. Once validated, a cybersecurity engineer or consultant provides inputs to the development team, discusses each finding, and verifies its validity. If a finding is truly critical, ask the team for a hard fix and push it immediately — a confirmed critical vulnerability is a deadline, not a discussion item.

14.5.4 VA Reports in Vendor Assessments

The same discipline applies to in-house assessments and TPRM audits of service providers: never sign off on a vulnerability assessment (VA) report blindly. Check the scope, which applications were included, whether the services the organization delivers were covered by the scanning, which tools were used, and whether the tool databases were updated. Also confirm that compliance requirements are met by the service providers — a vendor who cannot show current, in-scope scans and fresh tool databases cannot be trusted with your data, no matter what the summary slide claims.

14.6 Case Study: Malicious Chrome Extensions and Privacy Violations

14.6.1 Security Versus Privacy

Security and privacy are often confused; they are different, and the difference decides which law applies and which control works.

• Security is about securing data and the organization — maintaining confidentiality (only authorized people read it), integrity (no one changes it without permission), and availability (authorized people can reach it when needed).
• Privacy is about purpose — whatever data you collect from the end user must be used for the purpose agreed with the user.

Sharing data without concern — for example, handing it to a marketing team so they keep calling — violates privacy. Example: an employee gets health checks at a hospital, the hospital shares the data with a pharmaceutical company or a medical shop, and the shop calls saying: you have this disease, I have the medicines, take a 20% discount. That circulation of data without your concern is a privacy violation. The data was secure in transit; the violation was the purpose — a purpose you never agreed to.

14.6.2 Privacy by Design and the Seven Principles

Privacy by design builds privacy into the product, not bolted on after a complaint: seven OECD principles — notice, choice, consent, necessity, proportionality, and others — must be implemented so the application does not violate privacy. The core idea behind all of them: the user must be told what happens to their data (notice), given real options (choice), asked (consent), with the collection limited to what is necessary (necessity) and in proportion to the benefit (proportionality).

These principles descend from the Fair Information Practices developed in the 1970s — collection limitation, data quality, purpose specification, use limitation, security safeguards, openness, individual participation, and accountability. Every modern privacy regulation is a legally enforceable version of the same list.

14.6.3 Privacy Regulations Around the World

Every country has its own privacy rules, and a product that crosses borders must satisfy all of them. GDPR, the General Data Protection Regulation, is very stringent: it treats privacy as a fundamental right of European citizens, applies to any organization collecting or processing the personal information of EU/UK citizens, and its 99 sections define the roles and responsibilities of the collector, the processor, and whoever is outsourced the processing. GDPR was approved in April 2016 and became enforceable from 25 May 2018 — the date the fines started applying in practice. Fines for non-compliance are hefty — up to 4% of global annual turnover or 20 million euros, whichever is higher — which is why even US-based companies take GDPR seriously.

• CCPA (California Consumer Privacy Act) applies when your app collects California citizens' data.
• LGPD is Brazil's own requirement, closely modeled on GDPR.
• PIPEDA (Personal Information Protection and Electronic Documents Act) is Canada's law.
• India has passed the DPDP Act (Digital Personal Data Protection Act), which — similar to GDPR — frames who must follow what for vendors processing Indian citizens' data, though its compliance date has not yet been notified.

14.6.4 What the Extensions Did

The extensions used browsing data — search history and browsing habits — and injected unwanted ads into websites visited by users. They built a profile: based on your browsing, say frequent purchases of a specific category on Amazon, the extension creates a profile of your habits and injects ads for the things you are frequently interested in. Profiling without consent is a privacy violation — the profile is assembled from data collected with no agreed purpose — and the ads can be misleading or even malicious, leading to phishing sites or malware distribution platforms. The stolen browsing data could be targeted for advertising purposes or sold to third parties. Each step is the same violation wearing a different name: collection without consent, use beyond purpose, and disclosure without concern.

Real-world: be careful sharing personal data in public forums. At a shopping mall entrance, a lucky-dip form asks for your details for a chance to win a trip; within 48 hours you get calls from marketing teams — the collected data was sold to a team that wants a database of customers to call. The paper form and the browser extension are the same attack: a seemingly harmless request that quietly harvests data for someone else's purpose.

14.6.5 Evasion and Controls

The extensions may have appeared legitimate during the review process, only exhibiting malicious behavior after a period of time once they met social targets — a tactic that slipped through the initial evaluation. This is the evasion pattern: the extension behaves for weeks, builds a user base, then switches on the data collection when nobody is watching closely.

Preventive controls:

• Install extensions only from reputable developers — check who published it and what their track record is.
• Read the reviews from trusted sources before installing an extension.
• Be cautious of extensions that require unnecessary permissions — the TrueCaller test from section 14.6.1 applies here too.
• Review the permissions requested before installing — the install screen lists exactly what the extension can touch; treat any request beyond the stated function as a warning.

Google's response: the extensions were removed from the Chrome web store; Google improved its review process to identify future threats; and Chrome now displays a warning message when a user tries to install a removed extension.

Lesson: any malicious extension can steal data and inject unwanted ads — be cautious when installing, and treat app stores the same way: the Google Play Store runs its own check process so that no malicious extensions or apps are available there. Store review is a useful control, but the evasion tactic proves it is not perfect — the final control is the user's own review of what they are installing.

14.7 Case Study: Phishing Impersonating Video Conferencing Platforms

14.7.1 The Attack Pattern

Phishing emails attempt to trick recipients into revealing personal information or clicking malicious links. Here, fake emails appeared to come from legitimate video conferencing platforms — the attacker borrowed a trusted name to carry an untrusted link. A manufactured sense of urgency pushed the recipient to click: the meeting starts in five minutes, your account will be suspended, a patch must be installed now.

Real-world: video conferencing platforms — Zoom, Microsoft Teams, Google Meet, Cisco Webex, and GoToMeeting — have become essential tools for work, education, and short-term interactions. Phishing attackers exploit the familiarity and trust associated with these platforms to launch targeted attacks. The emails are crafted to appear legitimate, mimicking the brand and message of the real platform: click to join immediately, update your account, download patches. Each lure works because the platform is genuinely part of the user's daily routine.

14.7.2 Email Security Checks: SPF, DKIM and DMARC

From the earlier email security discussion: before clicking any link in an email, three checks verify that the email came from a legitimate source — SPF, DKIM, and DMARC.

14.7.3 The 2019 Zoom Phishing Wave

14.7.4 Prevention Best Practices

• Be cautious of unsolicited emails even when they appear legitimate — a surprise invitation from a platform you use is exactly what a phisher sends.
• Verify the sender's email; do not click the links within the emails — navigate to the platform manually by typing the address or using a saved bookmark.
• Be aware of emails urging immediate action, creating a sense of urgency — urgency is a pressure tactic, not a reason to comply.
• Check the spelling; check the domain; check the DKIM and SPF records.
• Use strong, unique passwords — a stolen credential can only reach as far as the password it unlocks.
• Restrict meetings to your corporate domain so only people within the organization can access them.
• Report phishing attempts — platforms offer reporting mechanisms, and every company has an incident security email ID to inform when a security incident happens.
• Delete phishing emails instead of forwarding or replying to them — replying confirms the address is live and invites more.

Phishing that impersonates video platforms is a persistent threat; following these best practices and staying vigilant protects you.

14.8 Case Study: COVID-Themed Phishing — Aarogya Setu and WHO

14.8.1 The Campaigns

Phishing campaigns targeted the Aarogya Setu app, launched in April 2020 to track COVID-19, and the World Health Organization (WHO), the international organization leading the global COVID-19 response. Phishing actors exploited users' trust in these organizations to launch credential-stealing attacks, sending emails with similar logos and branding elements to look legitimate, offering fake updates, registration links, or information about COVID-19 testing and vaccination — all to steal login credentials and personal information.

The pattern is the same as section 14.7: borrow a trusted name, add urgency, and direct the click to a fake page. The only difference is the bait — instead of a meeting invitation, the bait is health and safety, which makes people click faster, not slower.

14.8.2 How the Emails Worked

14.8.3 Staying Vigilant

The same best practices apply: be careful with unsolicited emails; verify the sender before clicking any link or attachment; do not click the links; verify whether the request is legitimate; be aware of very urgent emails — an urgent keyword in the subject line is a reason to verify, not to respond instantly; use strong and unique passwords; enable MFA (two-factor authentication); report phishing attempts.

Real-world: this vigilance extends beyond COVID-19 — anything from the income tax department or government sites deserves the same treatment. After July 31, an email claiming you missed your tax filing and must pay 20,000 rupees will feel urgent; verify the legitimacy of the source before responding. Hackers understand the context and craft phishing emails accordingly — tax season, exam results, natural disasters, and elections all produce the same pattern of themed lures.

14.9 Case Study: Keylogger Attack on a Construction Company

14.9.1 Why a Construction Company

Hackers always concentrate on non-security companies. They rarely attack McAfee, Norton, or other security product development companies — attacking the people who defend networks is both harder and riskier. Instead they go to financial banks, construction companies, and oil companies — organizations whose core business is something altogether different and who are less aware of cybersecurity. Many such companies lack security measures, making them more susceptible to attack.

14.9.2 The Attack

A keylogger is a software program that records the keystrokes typed on a computer. Attackers install it through various methods: phishing, infected websites, or even physical access to a device. Once installed, it remains hidden and silent, capturing every keystroke.

A keylogger is also the answer to a very specific problem: encrypted communication. When a user visits a banking site over HTTPS, the traffic between browser and server is encrypted, so an attacker sniffing the network sees nothing useful. The keylogger sits at the keyboard instead — it reads the keys before they are ever encrypted, so the strongest encryption in the world cannot protect a password that is captured at the moment of typing. That is why keyloggers remain one of the most reliable credential-stealing tools in existence.

14.9.3 Impact and Containment

With the credentials, the attackers gained access to everything: financial records and sensitive information, compromising the accounts and the security of the system, leading to financial loss and reputational damage. The construction company's money and client data were now reachable through the same trusted accounts the employees used every day.

Once the breach was identified, the company had to take immediate action to contain the damage:

• List all the accounts that got compromised — the inventory of what the attacker could reach.
• Reset the passwords — cutting off the attacker's existing access at the gate.
• Notify clients and partners if data was exposed — exposed client data is a failure to meet the regulatory requirement of securing client data, and failing to disclose it makes the situation worse.

14.9.4 Preventive Controls

Preventive controls for keylogger-style attacks:

• Restrict access to the corporate network by IP address, by MAC address, by deploying a zero trust network (ZTN) — a network design where no device or user is trusted by default and every access request is verified — by deploying certificates, or by security checks on who is accessing what information.
• Implement EDRs (endpoint detection and response) on every machine.
• Implement MFA — even if the keylogger captures a password, the stolen credential alone cannot log in.
• Train end users on social engineering — the employee's ability to recognize the fake email is the first line of defense.
• Use antivirus or EDR solutions and update software — signature updates catch known keyloggers, and patching closes the vulnerabilities keyloggers ride in on.

Keylogger attacks carry serious consequences once successful, which is why the layered approach of technical, physical, and administrative controls — defense in depth — matters. No single control catches everything: training stops some emails, EDR catches some installs, MFA neutralizes some stolen passwords, and network restrictions limit what a compromised machine can reach.

14.10 Case Study: ATM Skimming on a Business Trip

14.10.1 The Attack

An employee used a company debit card at a seemingly legitimate ATM, which had been compromised by criminals who installed a skimmer to steal card information. The skimmer captured the data from the magnetic stripe on the back of the debit card — the track data that identifies the account — while the PIN was recorded by a hidden camera or a keypad overlay placed over the real keypad to record every button press. The criminals then withdrew money — the withdrawals originated from ATMs in South America, thousands of kilometers from where the card was last used legitimately.

14.10.2 The Response and the Banking Reality

The firm contacted the bank and immediately closed the commercial account — the first priority was stopping any further withdrawals. The bank did not reimburse the stolen funds because of the account type: bank policy offered limited protection for commercial accounts compared to consumer accounts.

14.10.3 Controls Put in Place

After the incident, the firm implemented strict financial protocols for travel:

• Two separate accounts were created — one for receiving money and one for small travel expenses, so a skimmed travel card could not touch the firm's main funds.
• Company debit cards for travel were prohibited — the instrument that was skimmed was removed from the travel process entirely.
• Employees received alternatives — prepayment, small cash transactions, or major credit cards with strong protection.

The fraud and withdrawals wiped out the entire small cash reserve: the total loss came to almost 15,000 dollars, including the stolen funds and the overdraft fee. The loss figure matters twice: it is what the attack cost, and it is the number the cyber insurance claim had to cover.

14.10.4 Travel Advice for Card Use

• Credit cards typically offer greater fraud protection than debit cards: higher limits mean more recourse and a higher chance of reimbursement for fraudulent charges. A credit card dispute pauses the bill; a debit card dispute is your money missing until it is resolved.
• Set up transaction alerts or limit the transactions that can be performed in a day — a small daily limit turns a drained reserve into a single failed transaction.
• Regularly check bank statements — the firm discovered the fraud in the statements; early review limits the window of damage.
• Some banks offer withdrawal alerts for withdrawals exceeding a certain amount — a large withdrawal from a foreign ATM triggers an immediate notification.
• At ATMs: avoid poorly lit ATMs, look for signs of tampering, and do not use a suspicious machine — check the card slot and keypad for loose parts, unusual thickness, or mismatched colors.
• Protect your belongings and keep your passwords safe.

Following these tips minimizes the chance of falling victim to this type of fraud.

14.11 Case Study: Unencrypted Laptop with 40,000 Patient Records

14.11.1 The Incident

A healthcare executive left a work laptop containing 40,000 patient records in a locked car. The car was broken into and the laptop was stolen — the attacker gained access to the car, highlighting the limitations of physical security. A determined thief with a crowbar makes a car lock a speed bump, not a barrier.

The gap is data at rest. Data exists in two states: in transit, while it moves across a network, and at rest, while it sits on a disk. Data in transit and data at rest should always be encrypted. The first control failure was the absence of a security policy enforcing encryption by default on all laptops, both at rest and in transit. The second failure: no detection mechanism — even where a policy exists, nothing checks whether it is enforced. Both failures let the incident succeed: the policy gap meant the disk held plain patient records, and the detection gap meant nobody ever noticed the policy was not being applied.

14.11.2 Why the Lock Was Not Enough

The stolen laptop had a login lock, but a lock is only as strong as the password policy: with a strong policy, the device should lock itself automatically after more than three failed attempts, and for content this sensitive, the laptop should have been enabled with biometric access. A login lock stops casual snooping, not a determined attacker: an unlocked session, a weak password, or a brute-force attempt with enough time all defeat it.

14.11.3 Response and Compliance

The employee reported the theft promptly to the police; IT disabled the access and monitored for potential activity from the stolen laptop. Because the data was health information, the Department of Health and Human Services requirements apply and the hospital must follow the regulations — health information means HIPAA compliance comes into play. The HIPAA Security Rule requires safeguards for electronic protected health information, and a breach of 40,000 records triggers mandatory reporting and investigation.

The incident caused financial loss from remediation, monitoring, and operational disruption, plus reputational loss. Even with no evidence that any record was read, the hospital bore the cost of assuming the worst: notifying regulators, investigating, monitoring for misuse, and rebuilding patient trust.

14.11.4 Lessons Learned

Secure device handling matters — the laptop was in a locked car, and once the car is broken into, physical security can do no more. But even a stolen device must not expose data: technical controls like encryption by default, password lockout, biometric MFA, and remote control of the laptop through management tools like Jamf — which can lock the device remotely — would have prevented this outcome.

14.12 Case Study: CEO Spear-Phishing and Wire Transfer Fraud

14.12.1 The Attack

A CEO fell victim to a phishing email disguised as a response from the IRS. The disguise mattered: a message about taxes feels official, urgent, and impossible to ignore — and it came from an institution no one wants to be on the wrong side of. The email contained a malicious link that captured the login credentials — the CEO entered the portal credentials into a page that looked exactly like the real one, and the attacker recorded them. Criminals stole funds through fraud and wire transfers. Over one million was stolen and transferred to accounts in China, which were never recovered — the money crossed borders into accounts that could not be traced or reversed.

14.12.2 Reconnaissance Through Social Media

One mandate in banking: when creating user IDs on social networking sites, you must not display your tag — your department or designation; you may only say "associate of such-and-such bank." That was a stringent requirement in banks. The reason: once attackers know a person is a CFO — a non-technical buyer — they know when to strike and can perform all of those phishing attacks. The designation tells the attacker two things at once: this person has authority over money, and this person is unlikely to scrutinize a technical detail like the sender domain.

This targeted approach is spear phishing: targeting a specific group of people — or even a specific person — instead of spraying the same lure at millions. It is very successful because these people are less technical, and attackers exploit that. The difference from the earlier phishing cases: broad phishing counts on numbers; spear phishing counts on research.

14.12.3 Impact and Lessons

The email impersonated a trusted resource and compromised the CEO's login credentials; the portal's cash resources were depleted by fraudulent wire transfers. The lack of technical controls and the lack of awareness controls made the attack successful — the email sailed past every check that could have caught it, and no second factor stood between the stolen password and the wire.

Lessons: train staff to detect phishing attempts; deploy strong email security measures; require MFA; implement strong security controls; and invest in awareness and training. The CEO's technical knowledge was the weakest link in the chain, and the only control that specifically targets that link is training.

14.13 Case Study: Government Contractor Breach and the Dark Web

14.13.1 Data for Sale on the Dark Web

A government contractor's business data was offered for sale on the dark web — the site where hackers keep the data they pull out of organizations and put it up for sale. The dark web is the hidden layer of the internet, reachable only through special software, where buyers and sellers of stolen data meet anonymously. The data included a database of military clients — exactly the kind of information that turns a breach from a business problem into a national security concern.

The investigation revealed the data was outdated and not a current security threat — an important nuance: the listing was old data, already harvested, not a sign of an ongoing attack at the moment of discovery. The company was still exposed; the urgency was about what else the attackers might hold and how the data got out in the first place.

14.13.2 The Attack Path and Response

14.13.3 Lessons Learned

Cyber attacks can hit any business — government contractor, bank, construction firm, hospital, or consulting firm. Employee training is the most important measure, and physical, administrative, and technical controls all play an important role: continuous vulnerability scans, security protocol updates, and patch updates.

Real-world: many companies now run training tailored to roles and responsibilities — C-level executives get one kind of training, software developers another, the finance team another — so everyone understands the ways an attack could exploit their lack of cybersecurity knowledge. The senior employee who clicked the attachment is a reminder that experience does not equal cyber awareness; the training must reach the roles that the attacks actually target, with examples drawn from each role's daily work.

Exam Guidance Summary

The main exam carries 50 marks and consists of five questions, each worth 10 marks, and each question has a part A and a part B. The course assessment is a 50/50 combination of theory and practical content. The other 50 marks are internal: two quizzes, the assignments, and the group presentation; the mid-semester component is built on the quizzes.

The group presentation runs for five minutes per group in the next session, with one or two follow-up questions to check alignment, and marks are attached to the presentation. Submit the group assignment by the end of next week. The final session recaps the entire syllabus; all eight chapters are covered, and the chapter notes are confirmed on the learning portal.

Case-study guidance: the first three cases — ASP.NET credit card skimming, malicious Chrome extensions, and video conferencing phishing — are part of the syllabus; the rest are extra practice. For any case study, be ready to explain the background, what went wrong, and what went well, then the possible controls.

The case-study answer cycle: apply the cycle and the response — vulnerability to exploit to impact; then vulnerability management with monthly scanning; monitoring and detection of abnormal traffic; MFA; PCI DSS and other compliance requirements; SIEM and XDR monitoring; defense in depth with preventive, detective, corrective, and deterrent controls; WAF for zero-day attacks; applicability checks before acting on any bulletin; third party risk management for vendors; SAST and DAST in the SDLC; audits and penetration testing with scope, applicability, and tool-database freshness checks.

Conceptual recap questions: expect questions such as the IOC versus IOA ordering — indicators of attack come first, indicators of compromise confirm the event and serve forensic purposes. Also be ready on privacy regulation names — GDPR, CCPA, LGPD, PIPEDA, and India's DPDP Act — and the email security checks SPF, DKIM, and DMARC.

Key Industry Applications

Real-world: PCI DSS governs organizations involved in credit card transactions, and HIPAA governs healthcare providers serving US-based clients, with both security and privacy rules. Wherever a system handles card data or health data, compliance is a design requirement from the first sprint.

Real-world: MFA (something you know, something you have, something you are), SIEM and XDR for continuous monitoring, WAFs for zero-day protection, and EDR for endpoint detection and response are the monitoring and access-control technologies used in industry. Defense in depth is the industry pattern: no single product protects an organization.

Real-world: vulnerability scanning with tools like Qualys, penetration testing covering the OWASP Top 10, and vulnerability databases like CERT are standard practice, with the tool database freshness check as a key detail. A scanner is only as current as its vulnerability database.

Real-world: secure SDLC with SAST and DAST, open source management with approved OSS lists, and third party risk management audits of service providers like Infosys and CTS are how organizations vet code and vendors. The approved-library list and the vendor audit are the same idea at two scales: verify before you depend on it.

Real-world: privacy regulation compliance spans GDPR, CCPA, LGPD, PIPEDA, and India's DPDP Act; products like TrueCaller illustrate permission and purpose questions, and Google Chrome and the Google Play Store illustrate platform-side review controls. The purpose test — is the data used only for what the user agreed to — is the industry's privacy litmus test.

Real-world: email security relies on SPF, DKIM, and DMARC, with tools like Mimecast at the gateway, against phishing that impersonates Zoom, Microsoft Teams, Google Meet, Cisco Webex, GoToMeeting, Aarogya Setu, or the WHO. Gateway tools and human checks must work together, because attackers pick the side that is missing.

Real-world: incident response uses containment, forensic investigation, and cyber insurance; device management tools like Jamf enable remote lockout; identity checks rely on PKI and certificate revocation lists (CRL), as seen with hdfcbank.com; and social media reconnaissance via LinkedIn drives spear phishing against executives at companies like the IRS-impersonation case.

Real-world: hackers target non-security companies such as banks, construction, and oil firms; stolen data is traded on the dark web; and AI/ML-based XDR systems (for example, protecting products hosted in Amazon data centers) learn normal traffic within 30 to 60 days and alert SOC teams to anomalies. The same lesson runs through every case: assume the attacker will get in, and build the controls that make the entry pointless.