7th Set of Notes

Insider Threats - CompTIA A+ 220-1202 - 2.5

Insider Threats

1. The Limitation of Perimeter Security:

   • Organizations invest heavily in protecting the edges of their network — firewalls, intrusion prevention systems (IPS), and other perimeter defenses

   • However, these systems offer no protection against threats that originate inside the network

   • Employees already have legitimate access to the internal systems these defenses are designed to protect

2. What Makes Insider Threats So Dangerous:

   • Insiders possess knowledge that outside attackers must work hard to obtain:

     • They know where sensitive data is stored

     • They know the security methods used to protect that data

     • They know how to copy or remove data without triggering security alerts

   • They have daily, ongoing, legitimate access — no need to break in, bypass authentication, or exploit vulnerabilities

   • Insider threats go far beyond careless behavior like writing passwords on sticky notes — they can involve deliberate, sophisticated data theft or sabotage

3. Types of Insider Threats:

   • Disgruntled Employees:

     • Staff who have become unhappy with the organization and choose to act against it

     • May steal, leak, or destroy data using their existing access privileges

   • Recruited / Manipulated Employees:

     • Outside attackers actively recruit employees to act as insiders on their behalf

     • Employees are often enticed with Bitcoin or cryptocurrency payments

     • Documented example: employees recruited to plug in a USB drive loaded with ransomware — the software starts automatically, begins encrypting systems across the organization, and the attacker collects millions in ransom while the employee receives a payment for a simple physical action

     • The recruited employee may not fully understand the scale of what they are enabling

4. Defending Against Insider Threats:

   • Update security best practices specifically to account for internal access — not just external threats

   • Implement data access controls — limit who can access sensitive data to only those who genuinely need it (least privilege principle)

   • Maintain robust, up-to-date backups — so that even if ransomware or data destruction occurs from the inside, a clean copy of the data can be restored

   • Monitor internal network activity for unusual data movement or access patterns

Key Takeaways

1. Perimeter security alone is insufficient — firewalls and IPS protect the boundary but do nothing to stop a threat that is already inside.

2. Insiders are uniquely dangerous because they combine legitimate access, institutional knowledge, and physical presence — advantages no outside attacker can easily replicate.

3. Insider threats are not always voluntary — recruitment and manipulation by outside attackers turns otherwise ordinary employees into unwitting or willing accomplices.

4. Cryptocurrency has made recruiting insiders easier — payments are fast, anonymous, and difficult to trace.

5. The best defenses combine access controls (limiting what insiders can reach), behavioral monitoring (detecting unusual internal activity), and reliable backups (ensuring recovery is possible even when an attack succeeds).

SQL Injection Attacks - CompTIA A+ 220-1202 - 2.5

SQL Injection Attacks

1. The Core Concept:

   • Most applications require authentication (username and password) to control who can access data stored in a backend database

   • A SQL injection attack allows an attacker to insert their own database commands directly into the application, bypassing authentication entirely and gaining unauthorized access to all data

   • The root cause is almost always a failure of input validation — the application does not properly check or sanitize what users type into input fields before passing it to the database

   • SQL injection is not the only form of injection attack — others include HTML, XML, and LDAP injection, all exploiting the same fundamental weakness

2. What is SQL:

   • SQL — Structured Query Language — the standard language used to interact with relational databases

   • Used by common database systems including MySQL and Microsoft SQL Server

   • A typical SQL query looks like:

     • SELECT * FROM users WHERE name = 'professor'

     • This tells the database: return all records from the users table where the name equals "professor"

3. How a SQL Injection Works:

   • Instead of entering a legitimate username, the attacker types SQL code directly into the input field

   • Example injected input: ' OR '1'='1

   • This transforms the original query into:

     • SELECT * FROM users WHERE name = 'professor' OR '1'='1'

   • Because 1=1 is always true, the condition is satisfied for every record in the database — the query returns all data regardless of the actual username

   • The injected code effectively tells the database: give me everything

   • Result: the attacker gains full ability to view, modify, or delete any data in the database — completely bypassing authentication

4. Demonstrated Example — WebGoat:

   • WebGoat is an intentionally vulnerable application used for security training and demonstrations

   • Normal login: username Smith, authentication code 3SL99A — returns only that user's own record (user ID, department, salary, authentication info)

   • SQL injection input in the name field: ' OR 1=1;--

     • The -- at the end is a SQL comment — it tells the database to ignore everything that follows, neutralizing any remaining security checks in the original query

   • Result: every record in the database is returned — all user IDs, names, departments, salaries, and authentication credentials for the entire organization

5. Why This is So Dangerous:

   • A SQL injection requires no password, no credentials, and often no technical sophistication — just knowledge of basic SQL syntax

   • It bypasses every layer of application-level authentication

   • A single successful injection can expose the entire database — including credentials that can then be used to attack other systems

Key Takeaways

1. SQL injection exploits missing or insufficient input validation — if an application blindly passes user input to a database query, it is vulnerable.

2. The OR 1=1 technique works because it creates a condition that is always true, causing the database to return all records instead of just the matching one.

3. SQL injection does not just expose data — an attacker can also use it to modify or delete database records entirely.

4. Injection attacks are not limited to SQL — HTML, XML, and LDAP injection follow the same principle and exploit the same class of vulnerability.

5. The defense is rigorous input validation and parameterized queries (also called prepared statements) — a coding practice that separates user input from SQL commands so injected code is never executed as a query.

Cross-site Scripting - CompTIA A+ 220-1202 - 2.5

Cross-Site Scripting (XSS)

1. What is XSS and Why the Abbreviation:

   • XSS — Cross-Site Scripting — an attack where malicious scripts are injected into web pages or communications to steal information from a trusted website

   • Abbreviated XSS rather than CSS to avoid confusion with CSS — Cascading Style Sheets, the unrelated web design language

   • Originally named "cross-site" because early versions exploited browser security flaws that allowed one site to share data with another — modern browsers now block this, but injection through other mechanisms remains possible

   • XSS exploits the trust a user has already established with a website — once logged in, users are trusted by that site for a period of time, and XSS hijacks that trust

2. The Script in Cross-Site Scripting:

   • Most commonly uses JavaScript — the standard scripting language supported by virtually all browsers

   • Almost no users disable JavaScript because modern websites depend on it to function

   • Other script types can also be used, but JavaScript is by far the most common vehicle

3. How a Standard XSS Attack Works:

   • The attacker sends a malicious link to the victim — commonly via email

   • When the victim clicks the link, it redirects them to a trusted website they are already logged into and runs the injected script

   • The script can:

     • Steal the victim's session cookie — a small piece of data stored in the browser that proves the user is logged in

     • Send that cookie to the attacker, who can then use it to log in as the victim without needing a username or password

   • With the stolen session, the attacker can: make purchases, change account settings, and access stored payment information

4. Demonstrated Example — WebGoat Shopping Cart:

   • On an intentionally vulnerable shopping cart application, a script was pasted into an input field

   • The script was designed to display (and in a real attack, send to the attacker) the victim's session cookie

   • Once the attacker has the session cookie they have full access to the account — equivalent to being logged in

   • Possible consequences: purchases made under the victim's name, account details changed, stored credit card information accessed

5. Persistent XSS (Stored XSS):

   • A more dangerous variant where the malicious script is permanently stored on a public web page (e.g. a social media post, a comment section)

   • Anyone who visits that page automatically runs the script in their browser — no targeted email needed

   • Harder to detect because the attacker does not need to know who the victims are in advance

   • Scale is much larger — a single stored script on a popular page can affect thousands of users

6. Real-World Case — Subaru (2017):

   • Security researcher Aaron Guzman discovered an XSS vulnerability in the Subaru web portal

   • The Subaru website issued login tokens that never expired — meaning a stolen session token gave permanent access to a user's account

   • Through the web portal, an attacker with a stolen token could:

     • Change the account's email address (locking the real owner out)

     • Unlock the vehicle's doors remotely

   • The vulnerability was responsibly disclosed and patched before any attackers exploited it

7. Defenses Against XSS:

   • Never click links in emails or on untrusted web pages — this prevents most delivered XSS scripts from reaching a trusted site

   • Use third-party browser extensions that detect and block scripts attempting to exploit XSS vulnerabilities in real time

   • Keep browsers and applications updated — many XSS vulnerabilities exist due to unpatched flaws

   • For developers: rigorously validate and sanitize all user inputs — never allow a user-supplied input field to execute as code; this is the root-level fix that prevents XSS entirely

Key Takeaways

1. XSS exploits established trust — the victim is already authenticated on the target site, so the attacker just needs to hijack that session rather than stealing a password.

2. A session cookie is the key target — whoever holds it can impersonate the legitimate user with no further authentication required.

3. Persistent (stored) XSS is the most dangerous form — a single injected script on a public page can silently attack every visitor.

4. Input validation by developers is the most effective fix — if applications refuse to execute user-supplied scripts, XSS cannot occur.

5. The Subaru case illustrates that XSS vulnerabilities can extend far beyond websites — into physical systems like vehicles — as more devices connect to web-based management portals.

Business Email Compromise - CompTIA A+ 220-1202 - 2.5

Business Email Compromise (BEC)

1. Why Email is a Prime Attack Vector:

   • Email is one of the most universally used communication tools in business — used multiple times daily by every employee

   • It carries an inherent sense of trust — people generally believe what arrives in their inbox

   • Every person in an organization has an email address, creating a vast attack surface

   • Automated security systems cannot reliably detect social engineering — attacks designed to manipulate human judgment rather than exploit technical flaws

2. Common BEC Attack Scenarios:

   • Real Estate Wire Fraud:

     • Attacker monitors or impersonates a title company during a real estate closing

     • Sends a fake email with fraudulent wire transfer instructions

     • Victim sends closing funds directly to the attacker's account instead of the title company

   • Gift Card Scam:

     • Attacker impersonates the CEO of the victim's company

     • Requests that an employee purchase gift cards for "employee awards"

     • Gift card codes are emailed to the attacker — untraceable and immediately cashable

   • Payroll / Direct Deposit Fraud:

     • Attacker gains access to a legitimate internal email address

     • Sends a message to payroll requesting a change to an employee's direct deposit banking information

     • On the next pay cycle, the employee's wages are deposited into the attacker's account instead

3. How BEC Attacks Are Planned and Executed:

   • BEC attacks are carefully orchestrated — attackers invest significant time before striking

   • Typical stages:

     1. Target identification — using company websites, LinkedIn, and social media to find a specific individual with access to money or sensitive data

     2. Trust building — communicating with the victim over time, posing as a trusted contact; messages may reference real ongoing projects or involve simple friendly small talk

     3. Execution — once the victim is comfortable, the attacker makes the fraudulent request (fake bank details, gift card purchase, wire transfer, etc.)

     4. Repeat exploitation — if the first attack succeeds, the attacker may return and attempt the same process again before the victim realizes what happened

4. How Attackers Disguise Themselves:

   • Compromised third-party email — attackers breach a vendor's or partner's real email account and send messages from a legitimate, trusted address

   • Domain spoofing / typosquatting — registering a domain with a subtle misspelling (e.g. profesormesser.com with one "s" instead of two) that most people would not notice at a glance

   • Spear phishing — highly targeted, personalized emails aimed at individuals with financial access, such as those in accounting or payroll departments

   • Urgency tactics — creating pressure to act quickly, bypassing the victim's normal caution and judgment

5. Defense and Prevention:

   • Verify unusual requests out-of-band — if an email from the CEO asks for gift cards, call the CEO's assistant directly to confirm; one phone call can stop the attack entirely

   • Train high-risk staff — accounting, payroll, and finance teams are prime targets and need specific training to recognize BEC patterns

   • Slow down when pressured — a sense of urgency is a major red flag; legitimate requests can withstand a short verification delay

   • Check email domains carefully — look for subtle misspellings in sender addresses

   • Know who to contact in IT — employees should always have a clear, trusted escalation path when something feels wrong

Key Takeaways

1. BEC is a social engineering attack — it exploits human trust and urgency rather than technical vulnerabilities, making it very hard for automated systems to stop.

2. Attackers invest heavily in research and relationship-building before striking — by the time the fraudulent request arrives, the victim already trusts the sender.

3. Spear phishing is the primary delivery mechanism — BEC targets specific individuals with financial access, not random employees.

4. Third-party email compromise is particularly dangerous — messages arriving from a real, legitimate vendor address give victims almost no technical way to detect the fraud.

5. The single most effective defense is human verification — a quick phone call to confirm any unusual financial request can prevent significant losses regardless of how convincing the email appears.

Supply Chain Attacks - CompTIA A+ 220-1202 - 2.5

Supply Chain Attacks

1. What is the Supply Chain as a Security Concern:

   • Every product or service an organization uses is built from a chain of components — raw materials, manufacturers, distributors, and vendors

   • Every link in that chain is a potential entry point for an attacker

   • Organizations have full control over their own IT security but little to no visibility or control over the security practices of their suppliers and third-party providers

   • If any provider in the chain is compromised, the attacker can use that access as a bridge into your network

2. Third-Party Provider Risk:

   • Many third-party providers (network suppliers, utilities, cleaning companies, payroll firms) already have legitimate access to parts of an organization's network — often through internal portals or VPN credentials

   • This makes them an attractive stepping stone — compromising a provider gives an attacker a trusted path directly inside

   • The full list of an organization's providers creates a surprisingly large attack surface

   • Defense: many organizations now require contracts to include the right to audit the security practices of their providers — allowing visibility into weaknesses before they are exploited

3. Case Study — Target Corporation (November 2013):

   • 40 million credit card numbers were stolen — traced back to an HVAC (Heating, Ventilation, and Air Conditioning) company in Pennsylvania

   • Attack chain:

     1. The HVAC company was infected via a malicious email containing malware

     2. Attackers extracted VPN credentials the HVAC company used to access Target's vendor portal

     3. At the time, Target's network had no separation between the vendor network and the point-of-sale (POS) network

     4. Attackers moved freely from the vendor portal into every store's POS terminals

     5. Credit card data was collected for weeks before discovery

   • Key lesson: network segmentation — separating vendor access from sensitive internal systems — would have contained the breach

4. Hardware Supply Chain — Counterfeit Equipment:

   • Switches, routers, and firewalls sit inside the network and handle all passing traffic — a compromised or counterfeit device is an ideal surveillance tool

   • July 2022: the Department of Homeland Security (DHS) arrested a reseller CEO who had been selling counterfeit Cisco switches and routers

     • Over $1 billion in fake equipment sold through 30+ shell companies since 2013

     • Devices bore the Cisco label but contained non-Cisco hardware and software

     • Devices performed poorly — some caught fire before customers realized the equipment was not genuine

     • No confirmed malicious software was found, but the potential for embedded threats was significant given the scale and duration

   • Defense: vet vendors carefully, purchase from trusted authorized sources, and perform authenticity checks on hardware received

5. Software Supply Chain — Malicious Code in Updates:

   • Every software installation requires trust that the code is legitimate and unmodified

   • Most modern software includes a digital signature — a cryptographic verification that the code is exactly what the developer released

   • Risks still exist:

     • Automatic updates download and install without user review — if the update source is compromised, malicious code installs silently

     • Open source software — even though source code is publicly readable, attackers have successfully inserted malicious code that made it through review and into compiled releases

6. Case Study — SolarWinds Orion (2020):

   • One of the most significant supply chain attacks ever recorded

   • SolarWinds Orion — a network monitoring product used by over 18,000 customers worldwide, including major corporations and US federal agencies

   • Attack timeline:

     • March–June 2020 — attackers infiltrated the SolarWinds build environment and inserted malicious code before the software was digitally signed and distributed

     • December 2020 — the breach was finally discovered — the malicious code had been running in customer environments for months

   • Affected organizations included: Microsoft, Cisco, Intel, the Pentagon, Department of Homeland Security, State Department, Department of Energy, and many others

   • The digital signature was valid — customers had no technical reason to distrust the update

   • The attack fundamentally changed how organizations think about trusting software updates and vendor integrity

Key Takeaways

1. Supply chain attacks are powerful because they exploit trusted relationships — attackers gain entry through a legitimate, pre-approved connection rather than breaking through defenses directly.

2. Network segmentation is critical — the Target breach succeeded largely because vendor access and payment systems were on the same flat network; separation would have limited the damage.

3. Hardware can be weaponized — counterfeit or tampered network equipment is a real threat; organizations must verify the authenticity of devices they install.

4. Digital signatures are not foolproof — the SolarWinds attack showed that if malicious code is inserted before signing, the signature provides no protection.

5. The defense requires extending security thinking beyond your own walls — auditing vendors, segmenting networks, verifying hardware, and scrutinizing software sources are all now standard security responsibilities.

Security Vulnerabilities - CompTIA A+ 220-1202 - 2.5

Endpoint Security & Device Management

1. Standard Operating Environment (SOE):

   • Most organizations standardize their devices — similar laptops or desktops — making them easier to update, manage, and secure

   • A SOE — Standard Operating Environment defines a pre-approved, fully configured device setup that includes:

     • A specific approved set of software

     • All current security patches and updates

     • Verified compliance with organizational security requirements

   • Maintaining SOE compliance is an ongoing process — every patch or update must be tested before deployment to ensure it does not introduce new security issues

   • A non-compliant system (one outside the SOE) connected to the network creates an easy entry point for attackers

   • Tools used to enforce SOE:

     • Active Directory with Group Policy — centrally enables or disables OS features and settings across all devices

     • Next-generation firewalls — monitor all network traffic, identify every application in use, and enforce access policies

     • Background network scans — IT regularly scans for unauthorized or non-compliant devices on the network

2. Patch Management:

   • Unpatched systems contain known vulnerabilities — once a patch is released, the vulnerability it fixes becomes public knowledge and a target for attackers

   • Microsoft Patch Tuesday — the second Tuesday of every month, Microsoft releases its latest batch of security updates

     • Before Patch Tuesday, vulnerabilities are largely unknown

     • The moment patches are released, attackers begin writing exploits targeting those newly disclosed vulnerabilities

     • A race begins: organizations must test and deploy patches before attackers can exploit the unpatched systems

   • Challenges of patching at scale:

     • Large organizations may have hundreds or thousands of devices to patch simultaneously

     • Missing even a single device leaves it exposed

     • Requires dedicated processes and procedures to push patches efficiently and verify complete coverage

   • The goal: continuously improve the speed and efficiency of testing, prioritizing, and deploying patches across all systems

3. Security vs. Troubleshooting Conflicts:

   • Security tools (antivirus, personal firewalls) occasionally interfere with legitimate applications or troubleshooting tasks

   • It may be necessary to temporarily disable security tools to isolate a problem

   • Critical rule: always re-enable disabled security tools after troubleshooting — or use automated processes that restore them automatically

   • Best practice: rather than disabling security permanently when it causes conflicts, address each individual issue specifically so security and functionality can coexist

   • Permanently disabling security to avoid friction is never an acceptable solution

4. End-of-Life (EOL) and End-of-Service-Life (EOSL):

   • All operating systems have a defined support timeline with two key dates:

     • EOL — End of Life: the manufacturer stops selling the OS but may continue providing security patches and minor updates for a defined period

     • EOSL — End of Service Life: the manufacturer stops both selling and supporting the OS entirely — no further patches or security updates will be released

   • EOSL is the critical security concern — any vulnerability discovered after this date will likely never be patched

   • Some large vendors offer premium extended support at additional cost, but this is not standard or widely available

   • Any device running an EOSL operating system should be replaced or upgraded as soon as possible

5. BYOD — Bring Your Own Device:

   • Also called BYOT — Bring Your Own Technology

   • Employees use their personal mobile devices for both personal use and work — combining personal data and corporate data on one device

   • Security challenges:

     • The organization cannot fully control a personal device the way it controls company-issued hardware

     • If the device is lost, sold, or the employee leaves, corporate data must be removed without affecting personal data

   • Solution: MDM — Mobile Device Manager:

     • Partitions the device into separate personal and corporate data spaces

     • Allows IT to remotely wipe corporate data from any enrolled device via a central console — without touching personal files

     • Enforces security policies on the device

     • Monitors for malicious software that could provide an attacker access to corporate data

     • Manages the transition when employees upgrade or change devices — adding corporate data to the new device and cleanly removing it from the old one

Key Takeaways

1. A SOE is the foundation of manageable, consistent security — non-compliant devices connected to the network are one of the most common and avoidable security gaps.

2. Patch Tuesday creates a predictable monthly race — the window between patch release and full deployment is when organizations are most vulnerable, making a fast, reliable patching process essential.

3. Security tools should never be permanently disabled to solve a compatibility problem — conflicts should be resolved properly so both security and functionality work together.

4. EOSL is a hard security deadline — once a manufacturer stops releasing patches, any discovered vulnerability in that OS becomes a permanent, unresolvable risk.

5. MDM is the key to making BYOD workable — it separates personal and corporate data, enforces policies, and ensures corporate data can be cleanly removed at any time without harming the employee's personal information.

Removing Malware - CompTIA A+ 220-1202 - 2.6

Malware Removal Process — Step by Step

1. Important Caveat Before Starting:

   • These steps will not guarantee complete malware removal — malware embeds itself deeply into the OS, making full manual removal nearly impossible to confirm

   • The best practice for organizations is always to wipe the system entirely and restore from a known good image

   • This removal process exists for one specific scenario: the system will not boot properly but contains important files that must be recovered first — the goal is to get the system running just enough to retrieve those documents, then wipe and restore

2. Step 1 — Identify and Recognize Symptoms:

   • Malware symptoms range from obvious to subtle:

     • Obvious: antivirus alert messages (e.g. "Microsoft Defender found threats"), virus warnings from the OS

     • Subtle: slower boot times, sluggish performance, unusual or unexpected application error messages

   • Any of these can indicate infection — research the symptoms before drawing conclusions

3. Step 2 — Quarantine the Infected System:

   • Immediately disconnect the device from the network — malware can spread across network connections to other devices

   • Remove or disable access to USB drives and removable media — another common malware transfer vector

   • Do not back up the system at this stage — backing up an infected system will preserve the malware and restore it later

   • Disable System Restore:

     • Malware authors specifically target and infect restore points — rolling back to a restore point will simply restore the malware alongside the old configuration

     • Disabling System Restore deletes all existing restore points, removing any malware stored within them

     • This is a temporary step — System Restore will be re-enabled later after a clean image is applied

4. Step 3 — Remove the Malware:

   • Use antivirus / anti-malware software to scan and remove identified threats:

     • Ensure the antivirus engine is updated to the latest version

     • Ensure virus definitions (signatures) are current — signatures are often updated multiple times daily

     • Run a full system scan — the software will identify and automatically remove or quarantine malicious files

     • Quarantined files are moved to a restricted location — administrators can still examine them, but users cannot access or execute them

   • Problems that may arise:

     • Malware may block antivirus updates — in that case, manually download updates on a separate clean machine, transfer via USB, and install manually after booting into recovery mode

     • Malware may embed itself across multiple points in the OS, making simple file deletion insufficient

   • If the system cannot boot normally, try progressively deeper recovery options:

     • Safe Mode — loads a minimal version of Windows; may prevent some malware from running and allows file access and deletion

     • WinPE — Windows Pre-Installation Environment (accessed via the Windows Recovery Console) — boots to a command prompt with full file system access when safe mode fails

       • Can also be created manually using the ADK — Windows Assessment and Deployment Kit

     • If WinPE cannot locate the Windows installation: repair boot records or modify other startup components

5. Step 4 — Re-image or Reinstall the System:

   • Once important documents have been recovered, delete everything on the drive and restore from a known good image

   • A system image includes the OS, all drivers, required applications, and organizational configurations — restoring takes minutes and produces a verified clean system

   • Best practice: store user documents on a network drive or redirected folder rather than locally — this means wiping a local drive never risks losing important files

6. Step 5 — Configure to Prevent Reinfection:

   • Verify real-time antivirus scanning is active — monitors all activity continuously

   • Schedule periodic full scans — catches files not accessed during real-time monitoring

   • Configure automatic antivirus updates (engine and signatures) — use Task Scheduler if the antivirus software lacks a built-in scheduler

   • Verify Windows Update is configured to automatically download and install patches

   • Re-enable System Restore via System Properties → System Protection tab → Turn on system protection

   • Create a new restore point immediately — establishes a verified clean baseline to roll back to if needed in the future

7. Step 6 — User Education and Training:

   • Most malware infections involve a user action — training reduces reinfection risk

   • Training methods:

     • One-on-one sessions with the affected user

     • Posters and signs in high-traffic areas (near elevators, in break rooms)

     • Message board or break room announcements

     • Login screen messages (message of the day) — visible to every user at every login

     • Intranet pages — centralized documentation, contact information, and security best practices

Key Takeaways

1. No manual malware removal process is guaranteed — the only truly reliable fix is a full wipe and re-image; this process exists only to rescue important files first.

2. System Restore restore points are infected too — disabling System Restore and deleting all restore points is a necessary early step, not optional.

3. Never back up an infected system — doing so preserves the malware and will reintroduce it if that backup is ever restored.

4. Safe Mode → WinPE → ADK is the escalation path when normal boot fails — each provides progressively deeper access to a system that cannot start normally.

5. Storing user files on network drives makes re-imaging painless — wiping a local drive loses nothing important if data lives on the network.

6. User training is the final and often most important step — technology alone cannot prevent a determined or uninformed user from reinfecting their own system.