Trick 1: "SVG files are safe because they are just images." TRUE or FALSE?
FALSE — SVG is XML that can embed JavaScript and HTML, not a safe image format.
This is one of the most important misconceptions about image-based vectors. People hear "image file" and mentally categorize it with JPEG, PNG, or GIF — pixel-based formats that cannot contain executable code. SVG is fundamentally different. SVG stands for Scalable Vector Graphic, and the file format is XML — a markup language. Because it is XML-based, an SVG file can legally contain <script> elements with JavaScript, HTML injection, event handlers, and external content references.
When a browser renders an SVG, it processes the XML — including any embedded script tags. A malicious SVG that looks like a simple company logo or geometric design can execute JavaScript silently in the context of the page or the application rendering it. This makes SVG a vector for cross-site scripting (XSS), credential theft, and redirect attacks.
The visual appearance of the SVG gives absolutely no indication of embedded code. Two SVG files can be visually identical — one benign, one malicious — and only differ in their XML content.
Exam tip: Browsers need input validation and SVG content sanitization to prevent execution of embedded scripts. Applications that accept user-uploaded SVG files must sanitize the XML content before serving it to other users — or should reject SVG uploads entirely in favor of pixel-based formats that cannot contain code.
This is one of the most important misconceptions about image-based vectors. People hear "image file" and mentally categorize it with JPEG, PNG, or GIF — pixel-based formats that cannot contain executable code. SVG is fundamentally different. SVG stands for Scalable Vector Graphic, and the file format is XML — a markup language. Because it is XML-based, an SVG file can legally contain <script> elements with JavaScript, HTML injection, event handlers, and external content references.
When a browser renders an SVG, it processes the XML — including any embedded script tags. A malicious SVG that looks like a simple company logo or geometric design can execute JavaScript silently in the context of the page or the application rendering it. This makes SVG a vector for cross-site scripting (XSS), credential theft, and redirect attacks.
The visual appearance of the SVG gives absolutely no indication of embedded code. Two SVG files can be visually identical — one benign, one malicious — and only differ in their XML content.
Exam tip: Browsers need input validation and SVG content sanitization to prevent execution of embedded scripts. Applications that accept user-uploaded SVG files must sanitize the XML content before serving it to other users — or should reject SVG uploads entirely in favor of pixel-based formats that cannot contain code.
Trick 2: "Changing default passwords is optional if the device is behind a firewall." TRUE or FALSE?
FALSE — default credentials must be changed regardless of network position.
The logic behind this misconception: "The device isn't reachable from the internet, so only internal users can access it, and I trust my internal users." This logic has multiple fatal flaws.
Flaw 1: Internal attackers exist. Malicious insiders, phished employees, and contractors all have internal network access. One phished employee gives an attacker access from inside the firewall. Default credentials are exactly what an attacker inside the network will try first — before attempting any technical exploit — because they require no skill and often succeed.
Flaw 2: Automated scanners find everything. When malware like Mirai gets inside a network (via phishing, removable media, or any other vector), it scans the internal network for devices with default credentials. Default credentials on an internal device become immediately useful to any malware that reaches the network.
Flaw 3: The perimeter is not a reliable boundary. Perimeter defenses fail. They can be bypassed via phishing, VPN compromise, or supply chain access. A defense strategy that assumes the internal network is always safe is a strategy that will fail when the perimeter is breached — which it eventually will be.
Exam tip: Default credentials are listed on routerpasswords.com for thousands of device models. Any attacker — internal or external — who can reach a device with default credentials has full administrator access. Change defaults immediately on deployment. Always. No exceptions based on network location.
The logic behind this misconception: "The device isn't reachable from the internet, so only internal users can access it, and I trust my internal users." This logic has multiple fatal flaws.
Flaw 1: Internal attackers exist. Malicious insiders, phished employees, and contractors all have internal network access. One phished employee gives an attacker access from inside the firewall. Default credentials are exactly what an attacker inside the network will try first — before attempting any technical exploit — because they require no skill and often succeed.
Flaw 2: Automated scanners find everything. When malware like Mirai gets inside a network (via phishing, removable media, or any other vector), it scans the internal network for devices with default credentials. Default credentials on an internal device become immediately useful to any malware that reaches the network.
Flaw 3: The perimeter is not a reliable boundary. Perimeter defenses fail. They can be bypassed via phishing, VPN compromise, or supply chain access. A defense strategy that assumes the internal network is always safe is a strategy that will fail when the perimeter is breached — which it eventually will be.
Exam tip: Default credentials are listed on routerpasswords.com for thousands of device models. Any attacker — internal or external — who can reach a device with default credentials has full administrator access. Change defaults immediately on deployment. Always. No exceptions based on network location.
Trick 3: "A supply chain attack only works against large enterprises." TRUE or FALSE?
FALSE — supply chain attacks specifically target small and mid-size organizations through MSPs.
This misconception assumes that attackers only target well-known enterprises — Target, SolarWinds, large government agencies. In reality, supply chain attacks via Managed Service Providers are specifically designed to reach small and mid-size businesses (SMBs) that would be individually uninteresting to attack but collectively provide enormous value as a group.
Consider the MSP model: a single MSP might serve 50 to 500 SMB clients — dental practices, law firms, accounting companies, local manufacturers, medical clinics. Each individual client might have annual revenue of $5 million to $50 million. Attacking any one of them directly would yield limited return for the effort. But compromising the MSP that serves all 500 clients simultaneously? That's the equivalent of breaching 500 separate organizations with one intrusion.
MSPs often have privileged, persistent, authenticated access to all client networks — the kind of access that would take months to establish through direct attack. An attacker who compromises MSP credentials or the MSP's remote management platform inherits all of that trusted access instantly.
Exam tip: Supply chain attacks follow the math of leverage. The 2013 Target breach was enabled by a small HVAC company. SolarWinds customers included small government agencies, not just Fortune 500 companies. The size of the ultimate target is less relevant than the trust relationship being exploited. Any organization that uses third-party vendors, contractors, or MSPs has supply chain exposure regardless of its own size.
This misconception assumes that attackers only target well-known enterprises — Target, SolarWinds, large government agencies. In reality, supply chain attacks via Managed Service Providers are specifically designed to reach small and mid-size businesses (SMBs) that would be individually uninteresting to attack but collectively provide enormous value as a group.
Consider the MSP model: a single MSP might serve 50 to 500 SMB clients — dental practices, law firms, accounting companies, local manufacturers, medical clinics. Each individual client might have annual revenue of $5 million to $50 million. Attacking any one of them directly would yield limited return for the effort. But compromising the MSP that serves all 500 clients simultaneously? That's the equivalent of breaching 500 separate organizations with one intrusion.
MSPs often have privileged, persistent, authenticated access to all client networks — the kind of access that would take months to establish through direct attack. An attacker who compromises MSP credentials or the MSP's remote management platform inherits all of that trusted access instantly.
Exam tip: Supply chain attacks follow the math of leverage. The 2013 Target breach was enabled by a small HVAC company. SolarWinds customers included small government agencies, not just Fortune 500 companies. The size of the ultimate target is less relevant than the trust relationship being exploited. Any organization that uses third-party vendors, contractors, or MSPs has supply chain exposure regardless of its own size.
Trick 4: "Agentless systems are safer because there's nothing installed on the client." TRUE or FALSE?
FALSE — agentless systems create a different risk: one compromised server affects every client simultaneously.
The misconception here is equating "nothing installed on the client" with "lower risk on the client." The absence of a local installation shifts the risk, not eliminates it.
With client-based software: a vulnerability affects devices that have the vulnerable version installed. Patching is distributed across individual endpoints. A compromise of one client doesn't automatically compromise others. The attacker needs to exploit the vulnerability on each target device individually, or use one compromise as a pivot point for further attacks.
With agentless software: the application runs on a server, and clients connect to server sessions. If the server is compromised, every single client that connects is immediately affected — they all run the same server-side application instance. There is no individual device to patch on the client side because nothing is installed there. The server IS the attack surface, and all clients share it.
Log4Shell is the definitive example: Log4j ran on servers, not clients. When CVE-2021-44228 was disclosed, every server running vulnerable Log4j was potentially exploitable via any client input that the server logged. The blast radius was enormous because the vulnerability was server-side — affecting the entire user population of every affected application simultaneously.
Exam tip: The key distinction for the exam is understanding the risk profile, not which is "safer." Client-based risks are distributed; agentless risks are concentrated at the server but affect everyone simultaneously. A compromised agentless server is a force multiplier for attacker impact.
The misconception here is equating "nothing installed on the client" with "lower risk on the client." The absence of a local installation shifts the risk, not eliminates it.
With client-based software: a vulnerability affects devices that have the vulnerable version installed. Patching is distributed across individual endpoints. A compromise of one client doesn't automatically compromise others. The attacker needs to exploit the vulnerability on each target device individually, or use one compromise as a pivot point for further attacks.
With agentless software: the application runs on a server, and clients connect to server sessions. If the server is compromised, every single client that connects is immediately affected — they all run the same server-side application instance. There is no individual device to patch on the client side because nothing is installed there. The server IS the attack surface, and all clients share it.
Log4Shell is the definitive example: Log4j ran on servers, not clients. When CVE-2021-44228 was disclosed, every server running vulnerable Log4j was potentially exploitable via any client input that the server logged. The blast radius was enormous because the vulnerability was server-side — affecting the entire user population of every affected application simultaneously.
Exam tip: The key distinction for the exam is understanding the risk profile, not which is "safer." Client-based risks are distributed; agentless risks are concentrated at the server but affect everyone simultaneously. A compromised agentless server is a force multiplier for attacker impact.
Trick 5: "War dialing is obsolete in the modern era." TRUE or FALSE?
FALSE — war dialing still occurs, and analog lines/modems still exist in many environments.
This misconception is understandable. Most people have not used a dial-up modem in 15–20 years. Broadband internet made analog modem connections obsolete for consumer use. But "obsolete in consumer use" is not the same as "nonexistent in critical infrastructure."
Analog phone lines and modems persist in several environments: industrial control systems and SCADA environments that were installed decades ago and never updated; legacy healthcare environments with biomedical devices and equipment using out-of-band management modems; government facilities with legacy telecommunications infrastructure; bank ATMs and point-of-sale systems in regions with unreliable broadband; building management systems for HVAC, fire alarms, and access control installed in the 1990s–2000s.
Modern war dialing is automated and can scan large phone number ranges quickly. Security assessments of enterprise phone systems regularly discover forgotten analog lines connected to network equipment, fax machines with modem capabilities that also accept direct dial-in, and legacy systems with modem access that no one in the current IT team knows exists.
Real example from the notes: a hospital penetration test found an analog modem connected to a biomedical device — it had been installed nine years earlier and forgotten by IT staff. The modem provided direct access to a device on the clinical network, completely bypassing the organization's perimeter controls.
Exam tip: The Security+ exam expects candidates to understand that legacy threats have not disappeared just because they are old. War dialing is a real technique with a real attack surface in organizations that have not audited their analog telephone infrastructure. Inventories must include analog lines and modem-capable devices, not just IP-connected systems.
This misconception is understandable. Most people have not used a dial-up modem in 15–20 years. Broadband internet made analog modem connections obsolete for consumer use. But "obsolete in consumer use" is not the same as "nonexistent in critical infrastructure."
Analog phone lines and modems persist in several environments: industrial control systems and SCADA environments that were installed decades ago and never updated; legacy healthcare environments with biomedical devices and equipment using out-of-band management modems; government facilities with legacy telecommunications infrastructure; bank ATMs and point-of-sale systems in regions with unreliable broadband; building management systems for HVAC, fire alarms, and access control installed in the 1990s–2000s.
Modern war dialing is automated and can scan large phone number ranges quickly. Security assessments of enterprise phone systems regularly discover forgotten analog lines connected to network equipment, fax machines with modem capabilities that also accept direct dial-in, and legacy systems with modem access that no one in the current IT team knows exists.
Real example from the notes: a hospital penetration test found an analog modem connected to a biomedical device — it had been installed nine years earlier and forgotten by IT staff. The modem provided direct access to a device on the clinical network, completely bypassing the organization's perimeter controls.
Exam tip: The Security+ exam expects candidates to understand that legacy threats have not disappeared just because they are old. War dialing is a real technique with a real attack surface in organizations that have not audited their analog telephone infrastructure. Inventories must include analog lines and modem-capable devices, not just IP-connected systems.
Performance Task: A new CISO is mapping all threat vectors for a mid-size healthcare company. They find: open WiFi in the waiting room, PDFs emailed with macros to clinical staff (note: PDFs don't normally have macros — catch this), USB ports enabled on all workstations, and no 802.1X on any wired ports. What recommendations do you make?
Model Answer:
Important catch first — PDFs and macros:
PDFs do not contain macros in the same way Microsoft Office documents do. VBA macros are an Office feature (Word, Excel, PowerPoint). PDF files can contain embedded JavaScript and exploit reader vulnerabilities — but the specific threat of "macros" is an Office document issue, not a PDF issue. If clinical staff are receiving Office documents (.docx, .xlsx) disguised with PDF-like names or attached alongside PDFs, the macro threat is real. If someone described the files as "PDFs with macros," this is either imprecise language (Office documents being called PDFs), a misidentification of the file type, or a test to see if you catch the technical error. The CISO should clarify exactly what file type is being received and whether macros are actually present. If the files are genuine PDFs, the concern is malicious embedded JavaScript in PDFs — a different issue requiring PDF security controls in reader software, not macro disabling.
Recommendation 1 — Open WiFi in Waiting Room (Unsecure Network Vector):
The waiting room WiFi should use a segregated guest network — completely isolated from all clinical and administrative systems. If it is currently open (no password/encryption), implement WPA3 or at minimum WPA2 with a guest network password. Ensure the guest network is on a separate VLAN with no routing to internal healthcare systems. Patient data and clinical workflows must be completely unreachable from the guest network. Open WiFi within physical reach of the building's network infrastructure also creates a rogue AP risk — anyone connecting to the open AP could potentially use it as a pivot if the network is not properly segmented.
Recommendation 2 — USB Ports Enabled (Removable Device Vector):
USB port access is a significant risk in healthcare for two reasons: (1) data exfiltration of patient health information (PHI) is a HIPAA violation with severe penalties, and (2) USB-based malware delivery and HID attacks can compromise clinical workstations. Implement USB port lockdown via endpoint management policy — restrict USB storage devices on all clinical and administrative workstations. Whitelist only specific, organization-managed USB devices (such as specific encrypted drives used for legitimate purposes) using device management tools. Physical USB port blockers can be used on workstations where software policy is insufficient. Audit existing USB activity logs to determine if unauthorized USB usage has occurred.
Recommendation 3 — No 802.1X on Wired Ports (Unsecure Network Vector):
Without 802.1X, any device physically plugged into a wired Ethernet port in the facility — including in patient rooms, waiting areas, hallways, and supply rooms — receives automatic network access. In a healthcare environment, this is especially concerning: a visitor, contractor, or attacker who locates an active Ethernet port can be on the clinical network in seconds. Implement 802.1X port-based authentication on all wired switch ports. Ports that cannot immediately support 802.1X should be placed in a restricted VLAN or physically disabled until the policy can be applied. Clinical and administrative network segments should be separated so that even if a guest or unknown device gains access to one segment, it cannot reach the other.
Recommendation 4 — File-Based Vectors for Clinical Staff:
Regardless of the PDF/macro clarification needed, clinical staff receiving potentially malicious email attachments represents a file-based vector risk. Recommendations: implement email attachment sandboxing to detonate attached files in a controlled environment before delivery; enforce macro disabling via policy for all Office applications; conduct phishing awareness training specifically for clinical staff who may be less security-aware than IT staff; implement attachment type filtering at the email gateway to block file types with no clinical business justification.
Important catch first — PDFs and macros:
PDFs do not contain macros in the same way Microsoft Office documents do. VBA macros are an Office feature (Word, Excel, PowerPoint). PDF files can contain embedded JavaScript and exploit reader vulnerabilities — but the specific threat of "macros" is an Office document issue, not a PDF issue. If clinical staff are receiving Office documents (.docx, .xlsx) disguised with PDF-like names or attached alongside PDFs, the macro threat is real. If someone described the files as "PDFs with macros," this is either imprecise language (Office documents being called PDFs), a misidentification of the file type, or a test to see if you catch the technical error. The CISO should clarify exactly what file type is being received and whether macros are actually present. If the files are genuine PDFs, the concern is malicious embedded JavaScript in PDFs — a different issue requiring PDF security controls in reader software, not macro disabling.
Recommendation 1 — Open WiFi in Waiting Room (Unsecure Network Vector):
The waiting room WiFi should use a segregated guest network — completely isolated from all clinical and administrative systems. If it is currently open (no password/encryption), implement WPA3 or at minimum WPA2 with a guest network password. Ensure the guest network is on a separate VLAN with no routing to internal healthcare systems. Patient data and clinical workflows must be completely unreachable from the guest network. Open WiFi within physical reach of the building's network infrastructure also creates a rogue AP risk — anyone connecting to the open AP could potentially use it as a pivot if the network is not properly segmented.
Recommendation 2 — USB Ports Enabled (Removable Device Vector):
USB port access is a significant risk in healthcare for two reasons: (1) data exfiltration of patient health information (PHI) is a HIPAA violation with severe penalties, and (2) USB-based malware delivery and HID attacks can compromise clinical workstations. Implement USB port lockdown via endpoint management policy — restrict USB storage devices on all clinical and administrative workstations. Whitelist only specific, organization-managed USB devices (such as specific encrypted drives used for legitimate purposes) using device management tools. Physical USB port blockers can be used on workstations where software policy is insufficient. Audit existing USB activity logs to determine if unauthorized USB usage has occurred.
Recommendation 3 — No 802.1X on Wired Ports (Unsecure Network Vector):
Without 802.1X, any device physically plugged into a wired Ethernet port in the facility — including in patient rooms, waiting areas, hallways, and supply rooms — receives automatic network access. In a healthcare environment, this is especially concerning: a visitor, contractor, or attacker who locates an active Ethernet port can be on the clinical network in seconds. Implement 802.1X port-based authentication on all wired switch ports. Ports that cannot immediately support 802.1X should be placed in a restricted VLAN or physically disabled until the policy can be applied. Clinical and administrative network segments should be separated so that even if a guest or unknown device gains access to one segment, it cannot reach the other.
Recommendation 4 — File-Based Vectors for Clinical Staff:
Regardless of the PDF/macro clarification needed, clinical staff receiving potentially malicious email attachments represents a file-based vector risk. Recommendations: implement email attachment sandboxing to detonate attached files in a controlled environment before delivery; enforce macro disabling via policy for all Office applications; conduct phishing awareness training specifically for clinical staff who may be less security-aware than IT staff; implement attachment type filtering at the email gateway to block file types with no clinical business justification.