The Target breach is the defining service provider supply chain attack. The attack compromised 40 million payment card numbers from customers of 1,800 Target stores — but the initial attack vector was not Target itself.
The supply chain entry point: Fazio Mechanical Services, a Pennsylvania HVAC contractor, provided remote refrigeration monitoring services for Target stores. As part of this service, Fazio technicians used VPN credentials to access Target's network remotely. Fazio was a legitimate, trusted vendor with legitimate access — but its security posture was far below Target's.
The attack sequence: (1) Attackers sent phishing emails to Fazio employees. (2) The phishing email installed the Citadel malware on Fazio's systems. (3) Citadel harvested the VPN credentials used by Fazio technicians for remote Target network access. (4) Attackers used those credentials to log into Target's network. (5) Target's internal network was insufficiently segmented — from the vendor network access point, attackers could reach internal systems including the point-of-sale (POS) management infrastructure. (6) Attackers installed RAM-scraping malware on POS terminals across ~1,800 stores, collecting payment card data as customers swiped cards.
Why the HVAC vendor? Fazio was not the intended prize — it was the path. The attackers identified that Fazio had VPN access to Target's network. A small HVAC contractor had weaker security than a major retailer. Compromise the weaker link, then use its trusted access to reach the hardened target. This is the essence of island hopping in a service provider supply chain attack.
Exam takeaways: (1) Any vendor with network access is a potential supply chain attack vector, regardless of how unrelated to IT security their actual function is. (2) Network segmentation failure is a force multiplier — if vendor access had been isolated to the HVAC monitoring systems only, the POS terminals would never have been reachable. (3) The Target breach shaped modern vendor risk management: organizations now routinely audit not just direct vendors but their vendors' security practices too.
SUNBURST is the definitive software supply chain attack. Attackers (attributed to SVR, Russia's foreign intelligence service) compromised the build pipeline of SolarWinds Orion, an IT monitoring platform with approximately 18,000 customers including Fortune 500 companies and major U.S. government agencies.
Timeline: The attackers gained access to SolarWinds' build environment sometime before early 2020. In March and June 2020, they injected the SUNBURST backdoor into legitimate Orion update packages. The updates were signed with SolarWinds' genuine code-signing certificate and distributed normally. SUNBURST activated after a 12–14 day dormancy period and used DNS-based communication to blend into normal network traffic. The compromise was discovered by cybersecurity firm FireEye (which itself was breached via SUNBURST) in December 2020 — nine months after first distribution.
Why code signing didn't help: SolarWinds' own developers compiled and signed the malicious code using their legitimate certificate. The signature was completely valid — it genuinely came from SolarWinds. But the code it was signing had already been modified by the attackers before the signing step. Signature verification confirmed "SolarWinds signed this" — it said nothing about whether the code itself was safe. Every customer's security systems that trusted "signed by SolarWinds" approved the installation of the backdoor.
Scale of impact: Affected organizations included Microsoft, Cisco, Intel, Deloitte (private sector); the Pentagon, Department of Homeland Security, State Department, Department of Energy, National Nuclear Security Administration, and U.S. Treasury (government). The NSA, CISA, and NCSC (UK) jointly attributed the attack to APT29 (Cozy Bear), a Russian SVR threat actor.
Exam takeaways: (1) Code signing proves provenance, not safety. (2) Build pipeline security is as important as application security. (3) Dormancy periods and environment detection are used by sophisticated malware to evade testing and sandbox detection. (4) An attack on one widely-deployed software product can simultaneously affect thousands of organizations.
In July 2022, the U.S. Department of Homeland Security arrested Onur Aksoy, a Florida resident who led a scheme that sold more than $1 billion in counterfeit networking equipment over nearly a decade (estimated 2013–2022).
The scheme: Aksoy operated through more than 30 shell companies to acquire counterfeit Cisco networking equipment — switches, routers, and other devices manufactured without authorization and labeled as genuine Cisco products. The devices were purchased overseas and sold through online marketplaces. Buyers believed they were purchasing genuine Cisco equipment from a legitimate reseller.
Why this matters for security: All network traffic flows through switches and routers. A counterfeit switch may have: weaker components that fail more frequently and unexpectedly; firmware that differs from the genuine product's firmware (containing unknown vulnerabilities or backdoors); and monitoring or exfiltration capabilities invisible to the owner. Some of the counterfeit devices in this case reportedly caught fire — but the security risk extends beyond physical failure to potential covert monitoring of all traffic the device handles.
Mitigation: Purchase hardware directly from Cisco or its authorized partner program resellers. Verify hardware against Cisco's authenticity verification tools (Serial Number lookup, physical security labels). Inspect hardware physically against official documentation before deployment. A "too good to be true" price from an unfamiliar reseller is a red flag.
Exam takeaway: Hardware supply chain attacks are not theoretical. When evaluating a question about hardware supply chain risk, the key concern is counterfeit or tampered hardware from unvetted resellers — and the risk is not just physical failure but potential hidden functionality (monitoring, backdoors) that the buyer cannot see.
Scenario: A security analyst investigating a data breach discovers that the initial access point was a managed service provider (MSP) that had legitimate VPN access to the organization's network. The MSP had been compromised months earlier, and the attacker used the MSP's credentials to access the organization. What type of attack is this, and what controls would have reduced the impact?
Answer: This is a service provider supply chain attack (specifically island hopping via an MSP). The attacker used the trusted relationship between the MSP and the organization as an attack vector. Controls that would have reduced impact: (1) Network segmentation — the MSP's VPN access should be restricted to only the systems it needs to manage, preventing movement to other segments even with valid credentials. (2) Behavioral monitoring on the MSP's service account — unusual access patterns (data volume, access outside normal hours, access to systems the MSP doesn't normally touch) should trigger alerts. (3) MFA on the VPN — stolen static credentials would not be sufficient if MFA were required. (4) Regular security audits of the MSP — assessing the MSP's own security posture as part of the vendor management program.
Scenario: An organization's security policy requires that all software must be cryptographically signed before installation. A software vendor's build server is compromised, and malicious code is inserted into a product update before it is compiled and signed. The update passes all signature verification checks. Has the organization's code-signing policy protected them?
Answer: No. Code signing verifies that the software was signed by the claimed publisher — it does not verify that the code is safe or that the publisher's signing process was secure. If the build server was compromised before the signing step, the malicious code is compiled into the product, and the resulting package is signed with the legitimate key. Every signature check passes because the signature is genuine. This is exactly what happened in the SolarWinds SUNBURST attack. Code signing is a necessary control but not sufficient on its own. Complementary controls: behavioral monitoring of installed software, staged deployment (testing in an isolated environment before production rollout), SBOM tracking to understand what is installed, and reproducible builds (which allow independent verification that a binary matches its source code).
Scenario: An organization purchases network switches from an online marketplace at a significant discount. After deployment, the switches perform below specification and one fails. An engineer inspects the hardware and finds the internal components do not match the manufacturer's documentation. What type of attack has occurred, and what should the organization do?
Answer: This is a hardware supply chain attack — specifically, counterfeit hardware. The organization has deployed devices of unknown origin and unknown security properties on its network. Immediate actions: (1) Remove the suspect switches from production immediately — all traffic traversing them may be at risk of monitoring or manipulation. (2) Replace with hardware purchased directly from the manufacturer or an authorized reseller. (3) Verify the replacement hardware's authenticity before deployment. (4) Conduct a forensic review of all traffic logs from the period when counterfeit switches were in use — look for signs of data exfiltration or unusual traffic patterns. (5) Review procurement processes to require purchase only from authorized sources going forward and to verify hardware authenticity at receiving.