Case study | Cyber Attack And Def

Year: 2013-2015

Case Study 1 - Phishing: Google/Facebook BEC Phishing Scam

Context

Between 2013 and 2015, Google and Facebook were targeted in a large business email compromise scheme built around vendor impersonation. The attacker set up a company in Latvia using the same name as Quanta Computer, a legitimate hardware supplier both companies did business with, and then sent fraudulent emails and invoices that appeared to come from the real vendor. Because the requests matched normal business activity and referenced legitimate transactions, employees authorized payments to bank accounts controlled by the fraudster instead of the real supplier.

Impact

The scheme caused losses of more than $100 million, and later DOJ statements described the fraud as involving over $120 million in attempted theft. Beyond the direct financial damage, the case showed that even major technology companies with mature security programs can still be vulnerable when attackers exploit trust in vendor relationships and payment workflows rather than malware or network intrusion. It also became one of the most widely cited examples of vendor-focused BEC fraud.

Reference

Attack Timeline

Preparation: The attacker created a lookalike company and opened bank accounts in Latvia and Cyprus to receive the stolen payments.
Impersonation: Fraudulent emails were sent to employees and agents at the victim companies, posing as representatives of the real supplier.
Invoice fraud: The emails directed the companies to send money for genuine goods and services to the fake company’s accounts rather than to the legitimate vendor.
Funds transferred: Google and Facebook processed the payments, believing they were settling valid supplier invoices.
Money movement and concealment: After receiving the wire transfers, the fraudster moved funds through additional accounts in multiple countries to make recovery harder.
Legal outcome: U.S. authorities later charged Evaldas Rimasauskas, who pleaded guilty in 2019 and was sentenced later that year.

Lessons Learned & Mitigation

Verify payment changes outside email: Banking changes, invoice reroutes, and urgent transfer requests should be confirmed by phone or another trusted channel, not by replying to the message itself.
Use dual approval for wire transfers: High-value payments and vendor-account changes should require more than one reviewer before money is sent.
Strengthen vendor validation: Organizations should maintain verified vendor contact records and treat any payment redirection request as high risk.
Protect business email accounts: Multi-factor authentication and tighter monitoring reduce the chance that attackers can convincingly impersonate internal or partner contacts.
Train finance and accounts-payable staff on BEC patterns: This type of fraud often succeeds because it looks routine, so employees handling invoices need targeted awareness training.

Reference

Case Study 2 - DDoS: Dyn / Mirai Botnet Attack

Year: 2016

Reference

Context

Attack Timeline

In October 2016, Dyn, a major DNS provider, was hit by a massive distributed denial-of-service attack that disrupted access to many popular online services. The attack was tied to the Mirai botnet, which infected large numbers of internet-connected devices such as cameras, routers, and DVRs by targeting weak security settings and default credentials. Because Dyn helped route traffic for many major websites, the attack had effects far beyond a single company and showed how insecure IoT devices could be turned into large-scale attack infrastructure.

Botnet buildup: Mirai operators compromised hundreds of thousands of IoT devices and combined them into a large botnet capable of generating major attack traffic.
Initial attack wave: On October 21, 2016, Dyn began mitigating a DDoS attack against its managed DNS infrastructure, with early impact concentrated in the U.S. East Coast region.
Service disruption spreads: As Dyn struggled with the traffic, users had difficulty reaching major platforms that depended on Dyn’s DNS services, including Twitter, PayPal, Spotify, and other high-profile sites.
Multiple attack waves: Reporting from that day described several attack phases rather than a single short burst, which made mitigation more difficult and prolonged disruption.
Aftermath and attribution: Later investigations linked Mirai’s creation to Paras Jha, Josiah White, and Dalton Norman; DOJ said the botnet reached hundreds of thousands of compromised devices at its peak.

Impact

Lessons Learned & Mitigation

The Dyn attack caused widespread availability problems across parts of North America and Europe and temporarily affected access to many major internet services. Its broader significance came from the fact that the attackers did not need to breach each website individually; by overwhelming a core infrastructure provider, they created cascading disruption across many dependent platforms at once. The incident became one of the clearest examples of how DDoS attacks against shared internet infrastructure can create outsized, systemic effects.

Secure IoT devices by default: Devices exposed to the internet should not keep factory usernames and passwords, since Mirai relied heavily on weak or default credentials.
Reduce dependency on single points of failure: Organizations that rely on critical providers such as DNS services benefit from redundancy and resilience planning. The Dyn incident showed how infrastructure concentration can increase business risk.
Use layered DDoS protection: Large-scale attacks may arrive in waves, so mitigation planning should include upstream filtering, traffic scrubbing, monitoring, and incident playbooks.
Segment and manage connected devices: Consumer and enterprise IoT devices should be inventoried, patched when possible, and separated from more sensitive systems to reduce exposure and abuse.
Treat infrastructure security as ecosystem security: The attack showed that weaknesses in one part of the internet can affect many unrelated organizations, so resilience planning must include third-party service risk.

Year: 2017

Case Study 3 - Ransomware: WannaCry Ransomware Attack

Reference

Context

Attack Timeline

In May 2017, the WannaCry ransomware outbreak spread rapidly across the world by exploiting a Windows vulnerability known as SMBv1/EternalBlue. Once a system was infected, the malware encrypted files and demanded payment in Bitcoin, while also attempting to spread automatically to other vulnerable machines on the same network. The attack became especially notable for its impact on the UK’s National Health Service, where hospitals and clinics experienced major disruption because many systems had not been patched in time.

Vulnerability exposure: Microsoft had already released security update MS17-010 before the outbreak, but many organizations had not applied it across all systems.
Outbreak begins: On May 12, 2017, WannaCry was detected spreading globally, encrypting files and locking users out of infected systems.
Rapid worm-like spread: Unlike many ransomware campaigns that rely mainly on phishing, WannaCry propagated automatically across vulnerable Windows systems, which helped it spread at unusual speed.
Healthcare disruption: NHS organizations reported ransomware impacts on May 12, and NHS England escalated its response as the number of affected trusts grew through the day.
Kill switch discovery: A security researcher identified and activated a kill-switch domain that slowed the global spread, though infected and unpatched systems remained a risk.

Impact

Lessons Learned & Mitigation

WannaCry infected hundreds of thousands of computers worldwide and reached well over 150 countries, making it one of the most widely recognized ransomware outbreaks in history. In the NHS, the attack caused widespread operational disruption, including cancelled appointments and procedures, diverted patients, and a temporary return to paper-based processes in some settings. The incident became a major example of how delayed patching and legacy exposure can turn a technical weakness into a large-scale real-world crisis.

Patch management is critical: The outbreak showed that known vulnerabilities can still cause severe harm when organizations fail to deploy updates consistently and quickly.
Segment networks and limit spread: Because WannaCry moved laterally between vulnerable machines, stronger segmentation and reduced exposure of legacy protocols can greatly reduce impact.
Retire insecure legacy services: SMBv1 and other outdated services create unnecessary risk and should be disabled where possible.
Prepare continuity plans: The NHS experience showed that cyber incidents can quickly become service-delivery emergencies, so organizations need business continuity, backup, and incident response plans that work under pressure.
Do not rely on one control: Strong ransomware defense requires layered protection, including patching, backups, endpoint security, network monitoring, and user awareness.

Year: 2008

Case Study 4 - SQL Injection: Heartland Payment Systems Breach

Reference

Context

Attack Timeline

In 2008, Heartland Payment Systems suffered one of the most significant payment-card breaches of its time after attackers gained access to its environment and installed malware that captured payment card data while transactions were being processed. Later reporting and court filings connected the intrusion chain to SQL injection techniques that helped the attackers get into targeted networks and deploy data-stealing tools. The case became a major warning sign for payment processors because it showed how a weakness in a public-facing system could lead to long-term exposure of highly sensitive transaction data in the back-end environment.

Initial compromise: Attackers used SQL injection methods to break into vulnerable systems and establish a foothold in the network.
Malware deployment: After gaining access, they installed malicious software inside the payment processing environment to collect card data in transit during transaction authorization.
Sustained data theft: According to the federal indictment tied to the broader hacking conspiracy, the attackers operated over an extended period, stealing large volumes of payment card information for resale.
Public disclosure: Heartland publicly announced the breach on January 20, 2009, stating that the intrusion had been contained and did not extend beyond 2008.
Industry and legal fallout: After disclosure, the company faced card-brand claims, investigations, litigation, and major remediation costs tied to the breach.

Impact

Lessons Learned & Mitigation

The Heartland breach is widely remembered because it exposed payment card data on an enormous scale and became one of the defining data breaches of that era. Beyond the direct compromise itself, the incident triggered financial penalties, legal disputes, and reputational damage, while also increasing pressure across the payment industry to strengthen monitoring, segmentation, and protection of transaction environments. It highlighted the danger of capturing data “in transit,” where sensitive information may still be visible inside internal systems even when organizations believe they are otherwise well protected.

Secure web applications early: SQL injection prevention has to start with strict input validation, parameterized queries, and secure coding practices so attackers cannot use front-end weaknesses to reach internal systems.
Protect sensitive data during processing: Heartland’s breach showed that transaction data can be most vulnerable while it is actively moving through payment systems, so organizations need stronger controls around in-memory and in-transit handling.
Segment critical environments: Payment processing systems should be isolated from less sensitive systems so an initial compromise does not easily lead to broad internal access. This is a direct lesson many defenders drew from the breach.
Use continuous monitoring and anomaly detection: Long-running intrusions are harder to stop when organizations lack visibility into unusual database queries, malware behavior, or unauthorized internal movement. The duration of this case showed the cost of delayed detection.
Treat compliance as a baseline, not the finish line: The breach became a major reminder that meeting standards alone does not guarantee security if attackers can still exploit application flaws and internal blind spots.

Year: 2011

Case Study 5 - MITM: DigiNotar / Iranian Google MITM Attack

Reference

Context

Attack Timeline

In 2011, the Dutch certificate authority DigiNotar was compromised, allowing attackers to generate fraudulent digital certificates for major domains, including Google. Those fake certificates were then used in man-in-the-middle attacks that targeted users, primarily in Iran, by making malicious connections appear legitimate to the victim’s browser. The incident became one of the clearest examples of how trust in the certificate authority system can be abused when a certificate issuer is breached.

Initial compromise: Fox-IT’s investigation found signs that DigiNotar’s network had been breached in mid-2011 and that the attacker gained access to certificate-issuing systems.
Fraudulent certificate creation: After reaching DigiNotar’s certificate environment, the attacker generated rogue certificates for multiple domains, including Google services. Fox-IT later reported hundreds of fraudulent certificates tied to many different names.
MITM activity in Iran: Google reported attempted SSL man-in-the-middle attacks against its users, saying the affected users were primarily located in Iran and that a fraudulent DigiNotar-issued certificate had been used.
Public discovery and browser response: Once the compromise became public, major browser vendors moved to revoke trust in DigiNotar certificates so that users would be warned or blocked from relying on them.
Collapse of trust in DigiNotar: The breach damaged confidence so severely that DigiNotar ultimately failed as a business, and the case became a landmark certificate authority crisis.

Impact

Lessons Learned & Mitigation

The DigiNotar incident put a very large number of users at risk, with postmortem analysis indicating that more than 300,000 users, mostly in Iran, may have had communications exposed through the fraudulent certificates. Beyond the immediate surveillance risk, the breach shook global trust in the certificate authority model because it showed that compromising one trusted issuer could endanger users far beyond that one company’s customer base. The attack also helped drive stronger browser-side protections and broader discussion of certificate transparency and pinning.

Certificate authorities are high-value targets: When a CA is compromised, attackers may be able to impersonate trusted websites at scale, so CA security has to be treated as critical infrastructure.
Rapid disclosure matters: Analysis after the breach criticized the delay in incident reporting, because late disclosure gave the attack more time to affect users.
Browser-level defenses are essential: Google noted that Chrome detected the fraudulent Google certificate, and later security work around key pinning and related protections was directly shaped by this type of event.
Trust should be continuously validated: The case showed that the internet’s certificate system needs auditing, transparency, and cross-checking rather than blind trust in every approved certificate issuer.
Users and organizations must keep browsers updated: Post-incident protections only help if software updates are applied, which EFF emphasized in its analysis of the attack.

Year: 2005

Case Study 6 - Cross-Site Scripting: Samy MySpace Worm

Reference

Context

Attack Timeline

In October 2005, MySpace was hit by one of the most famous early cross-site scripting incidents when Samy Kamkar created a self-propagating worm that abused weaknesses in profile-page filtering. When a user viewed an infected profile, the embedded code automatically added Kamkar as a friend, displayed a short message on the victim’s page, and copied itself into that user’s profile so the cycle could continue. The incident became a landmark XSS case because it showed that client-side script injection could spread at enormous speed on a social platform, even without using traditional malware delivery methods.

Initial payload creation: Kamkar built JavaScript that could bypass MySpace’s filtering and execute when someone visited his profile.
Automatic social action: The worm caused visiting users to unknowingly send him a friend request and update their profile with the phrase associated with the worm.
Self-propagation: The payload copied itself to each newly affected profile, turning every infected page into another launch point.
Explosive spread: Within about 20 hours, the worm had spread to more than one million profiles, making it one of the fastest-spreading web worms ever recorded.
Platform response: MySpace temporarily shut down parts of the service so it could stop the worm and repair the vulnerability that allowed it to spread.

Impact

The Samy worm did not become famous because it destroyed data or demanded money; its importance came from how clearly it demonstrated the real-world danger of XSS on large platforms. It showed that script injection could be turned into an automated, viral mechanism capable of manipulating user actions and spreading across a social network at huge scale. The case also became an important example for secure web development because it proved that weak filtering and browser-side trust could create systemic platform-wide risk.

Lessons Learned & Mitigation

Input filtering alone is not enough: MySpace attempted to restrict dangerous code, but the worm showed that incomplete filtering can still be bypassed. Strong output encoding and safer rendering controls are essential.
XSS can defeat other protections: OWASP later highlighted the Samy worm as an example of how XSS can even undermine anti-CSRF defenses, which makes script injection especially dangerous.
User-generated content must be treated as untrusted: Social platforms, forums, and profile systems need strict handling for anything users can post or customize.
Rapid containment matters: MySpace’s shutdown response shows that platform-wide incidents may require immediate service restrictions to stop further spread.
Client-side attacks can become ecosystem-wide events: The worm proved that web application flaws are not always isolated bugs; on large platforms they can become mass-propagation incidents very quickly.

Leave comments on how this Case Study page helped you learn about certain topics. Leave criticisms on the information and ways to make it better.