UPI Study › Courses › Ethics in Technology › Free lessons › Lesson 9.6 Free with a free account
Classifying Viruses by Infection, Runtime, and Concealment
Ethics in Technology · Chapter 9: Data Breaches, Digital Infections, and the Malware EcosystemSection 9.6 · lesson 47 of 11615 min · free with a free account
Free preview
Create a free account to keep watching
It takes a minute and costs nothing. Your free account unlocks all of Chapter 1 and 3 more lessons of Ethics in Technology.
Lesson complete
Earn the 3 college credits for Ethics in Technology
Enrolling adds a quiz after each lesson, the graded work and the official transcript. Recommended for credit by NCCRS.
Next lesson: Trojans, Delivery Routes, and Defensive Decisions →← How Computer Viruses Became Global ThreatsNext lesson: Trojans, Delivery Routes, and Defensive Decisions →
In this lesson
Describe what a virus infects, how it remains active, and how it conceals its presence.
- Classify targets, runtime behavior, and concealment independently.
- Compare boot, file, macro, and multipartite infections.
- Distinguish encryption, polymorphism, and metamorphism.
- Select defenses from evidence, while recognizing their limits.
Free study notes
Get this lesson's notes by email
The key points and 4 practice questions with answers, in your inbox. One email, free.
One email. Unsubscribe in one click.
Transcript
Everything said in the video, section by section (1,737 words). Read along, or search it.
Chapter 9
Classifying Computer Viruses
A virus can be classified by its target, its runtime behavior, and its concealment technique. These are independent questions, so several descriptions can apply to the same program. We begin with startup code, executable files, document macros, and multiple infection areas. Then we compare activity that remains in memory with direct-action infection during an invocation. Stealth hides observations of changes, while encryption hides the stored appearance of code. The classic polymorphic model changes a wrapper around shared underlying logic. Metamorphic code changes its body while preserving its intended function. Historical examples make these distinctions concrete, without implying that every variant behaves identically. Our spreadsheet example separates supported classifications from details that remain unproven. Useful defense follows the mechanism, and combines maintained controls with trustworthy inspection and recovery. A label explains part of the risk; evidence determines what actually happened and what must be addressed.
Three Independent Axes
One Virus Can Belong to Several Categories
The first classification question asks what a virus infects. It may affect startup code, executable programs, document macros, or more than one target. The second question asks how the active code runs. Memory-resident and direct-action descriptions concern whether activity remains after the initial invocation. The third question asks how the code hides itself or its effects. Stealth, encryption, polymorphism, and metamorphism describe different concealment ideas. A single virus may belong to categories on all three axes. The defining behavior remains replication through host infection, requiring execution of relevant infected host code. A fresh deliberate user action is not necessary for every activation. The infection mechanism is essential, while a separate trigger and payload are optional. Dormancy, propagation, triggering, and payload execution provide a teaching model, rather than a mandatory schedule for every virus.
Boot Sector
Startup Code Gives an Infection an Early Execution Opportunity
Classic boot sector viruses altered disk startup code in relevant older computer designs. Starting from infected media could activate the code before ordinary operating-system inspection. Susceptible disks could then carry infection to other machines. Brain, from nineteen eighty-six, is a familiar example involving IBM PC-compatible floppy disks. Michelangelo was discovered in nineteen ninety-one and associated with a March sixth destructive trigger. The early execution opportunity could influence later system behavior or inspection. Modern bootkits and firmware malware raise related questions about startup trust. They are not automatically replicating boot sector viruses, despite the shared concern about early control. On compatible UEFI systems, Secure Boot checks permitted startup code against trusted signatures or hashes. The protection depends on configuration, maintained updates, and current trust and revocation information. It helps establish startup trust without certifying every application or guaranteeing that all firmware compromise is impossible.
File Infectors
Executable Programs Can Carry Replicating Changes
A file infector places replicating changes inside executable programs. When relevant infected code runs, it can affect other suitable program files. Some implementations add or insert code while allowing the host to appear functional. Others overwrite content, which can damage or disable the original program. An unchanged visible result does not prove that the executable remains trustworthy. Jerusalem, associated with the late nineteen eighties, deleted programs on Friday the thirteenth in relevant variants. CIH, found in nineteen ninety-eight, affected executable files on particular Windows systems. Its destructive activity could overwrite disk data and corrupt flash BIOS on susceptible hardware. That firmware damage could prevent the machine from starting, without affecting every computer identically. Authorized software sources, maintained protective tools, limited privileges, and integrity checks provide complementary protection. A familiar extension or distribution channel is insufficient assurance; clean replacement may be preferable to trusting a partially repaired file.
Macro Viruses
Documents Can Contain Executable Instructions
A macro is an application's instruction sequence for automating work inside a document or related template. A macro virus replicates through suitable documents or templates when its instructions can execute. The document format therefore does not guarantee that the contents are only inert data. Execution depends on the compatible application, macro language, available features, permissions, and settings. It is misleading to claim that every macro virus works regardless of operating system. Concept circulated widely in nineteen ninety-five as a Word macro virus. Melissa followed in nineteen ninety-nine, using Outlook distribution to the first fifty listed addresses. Microsoft began rolling out internet-origin VBA macro blocking in two thousand twenty-two for covered Windows Office applications. Versions, policies, source markings, trusted publishers, and trusted locations affect the outcome. The same change does not apply identically to Mac, mobile, or web editions. Follow approved macro policies and verify unexpected requests independently, rather than weakening protections because a document requests it.
Multipartite
More Than One Infected Area Can Sustain Reinfection
Multipartite describes infection affecting more than one target or route. A common historical combination involved disk startup code and executable program files. Infected startup code could become active and reinfect previously cleaned programs. Running an infected program could also restore infection to startup code. The diagram illustrates one possible path, rather than every implementation's complete sequence. Ghostball, discovered in nineteen eighty-nine, is an early multipartite example. Tequila, associated with nineteen ninety-one, combined startup and executable infection with concealment changes. These cases explain why repeatedly cleaning only a visible file may be insufficient. Authorized responders should identify the full scope, including remaining infection reservoirs. A trusted recovery environment and clean replacement material help avoid inspecting only through compromised code. Containment, coordinated repair or rebuilding, and recovery verification should address all affected areas together to reduce reinfection.
Runtime Behavior
Residence Describes Continued Activity, Rather Than Persistence Alone
Memory-resident code remains active beyond the initial infected host invocation. It may respond to relevant later file or system events, providing additional infection opportunities. Jerusalem and CIH exhibited this behavior in their historical environments. A non-resident, or direct-action, virus performs infection work and then returns control or ends. Vienna is a familiar early example of this second pattern. All executing code uses memory, so non-resident does not mean that it never enters RAM. It means the active infection does not remain as a resident afterward. Residence does not imply continuous infection, unlimited duration, or always faster spread. Direct-action code can still affect several reachable files during an invocation. A restart may stop current memory activity while leaving stored infection able to activate again. Inspection and recovery must therefore address infected files and startup mechanisms, alongside the code currently running in memory.
Stealth and Encryption
Hiding System Changes Differs from Scrambling Stored Code
Stealth conceals the changes an infection makes, rather than simply scrambling its stored body. It may interfere with inspection to present original content or hide an altered file size. Brain concealed boot-sector changes, while Frodo, also called forty ninety-six, concealed file changes. The related rootkit idea concerns hidden activity, without necessarily involving virus replication. Encryption instead scrambles stored code, with a routine revealing executable content when needed. Cascade is a classic encrypted example from the earlier virus era. If the reveal routine remains recognizable, it can still provide detection evidence. Approved clean media can prevent ordinary infected operating-system code from controlling an inspection. Integrity comparisons can also identify differences from suitable trusted references. Neither method guarantees that every hidden infection becomes visible; tool coverage and the recovery environment still matter. Firmware threats, incomplete inspection, or protected data may require specialist handling, rather than assuming that an external scan proves safety.
Polymorphism
The Classic Model Changes the Wrapper Around a Stable Body
The classic encrypted polymorphic model varies stored appearance across copies. It can vary encryption and the decryption routine while preserving underlying body logic. That distinction addresses the weakness of a simple unchanging reveal routine. The twelve-sixty example appeared around nineteen ninety, followed by reusable mutation tools in the early nineteen nineties. Those historical tools are relevant as context, rather than instructions for constructing concealment. Security usage can also describe other changing representations as polymorphic. The explanation connects a variable wrapper, controlled analysis, and shared revealed logic. Authorized emulation or sandbox analysis can expose unpacked content and observed behavior. A simple stored signature may miss a variable representation that these other methods can recognize. Analysis still has coverage limits, and may not reach every activation condition or execution path. A safe result in one environment is not universal proof; suspicious files belong in an approved specialist process.
Metamorphism
Changed Code Can Preserve the Same Function
Metamorphic code changes its own body while preserving its intended function. Different instruction or logic representations can perform the same task. This contrasts with the classic wrapper model that reveals one unchanged underlying body. Zmist and Simile were studied in the early two thousands as complex code-changing examples. The source diagram's changing bodies and disguises are a useful conceptual comparison. They do not prove that every metamorphic program changes every byte or has no detectable invariant. Encryption and body transformation can also appear together in actual malware. Behavior, heuristics, normalized structure, integrity evidence, and controlled analysis can complement signatures. These methods have false positives, false negatives, and practical coverage limits. A changing representation can challenge detection, without making the code invisible to every possible method. Technical complexity also does not establish prevalence; a difficult research specimen is not automatically a widespread real-world outbreak.
Worked Classification
The Spreadsheet Evidence Supports Some Labels More Strongly Than Others
Consider the hypothetical spreadsheet that contains replicating macro code and changes an application template. Those observations support a macro-virus description, assuming executable host replication is established. Whether every new spreadsheet inherits infection depends on the compatible template and document behavior. Activity continuing through the application session supports resident-like behavior in that context. It does not independently establish system-wide residence after the application closes. Each newly scrambled copy suggests encryption or another variable representation. That observation alone does not prove classic polymorphism, because the reveal routine's changes remain unobserved. It also does not prove metamorphism, which requires evidence of body transformation. The supported labels should guide further authorized inspection, while uncertainty remains explicit. Manage macros and trust exceptions, and use approved inspection and recovery processes. One protective setting does not establish complete removal, nor does one sandbox result identify every remaining infection reservoir.
Defense and Review
Categories Explain Risks; Controls Must Be Maintained Together
The categories explain why defenses must address different mechanisms together. For startup infection, maintain startup trust and manage boot media and recovery inspection. For executable infection, combine authorized software, integrity evidence, protective tools, and clean replacement. For macro infection, restrict unsafe execution and carefully manage approved trust exceptions. For multipartite infection, identify all reservoirs and verify that recovery does not allow reinfection. Concealed or changing code calls for complementary signatures, independent inspection, behavior evidence, and controlled analysis. For review, explain how a program can infect both files and startup areas. Distinguish runtime residence from stored persistence, rather than assuming a restart removes everything. Stealth hides observations, encryption hides stored form, classic polymorphism varies a wrapper, and metamorphism changes the body. The spreadsheet case shows why unsupported details should remain uncertain, even when several labels clearly apply. These historical concepts still explain broader malware mechanisms, without requiring an unsupported popularity ranking or a promise of one universal defense.
About Ethics in Technology at UPI Study
Ethics in Technology (Computer Science 195) is a self-paced online course of 116 video lessons in 15 chapters, from cybersecurity basics, privacy and surveillance to big data, hacking, malware, network defense, intellectual property, cybercrime, encryption, emerging technology and digital citizenship. It carries a NCCRS credit recommendation for 3 semester credits.
Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Enroll now → Course details Download the syllabus All Computer Science courses
Compare: Cybersecurity vs Ethics in Technology · Which ethics course?
Why take it here
Why students take Ethics in Technology with UPI Study
Where the credit goes
Universities that work with NCCRS
Ethics in Technology carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Thomas Edison State UniversitySigned partner
University of the PeopleSigned partner
Charter Oak State CollegeSigned partner
Strayer UniversitySigned partner
Columbia Southern UniversitySigned partner
Indiana TechSigned partner
Penn StateWorks with NCCRS
Southern New Hampshire UniversityWorks with NCCRS
SUNYWorks with NCCRS
+many more cooperating universitiesFind my college →Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.
FAQ
Questions students ask us
About Classifying Viruses by Infection, Runtime, and Concealment
What is a boot sector virus?
What is a macro virus?
What is a multipartite virus?
What is the difference between polymorphic and metamorphic viruses?
About the Ethics in Technology course
How many college credits is Ethics in Technology?
How much does Ethics in Technology cost and what is included?
Which universities accept UPI Study credits?
How long does Ethics in Technology take?
How are the exams done?
How do my credits reach my college?
Ready for the full course? Earn 3 credits in Ethics in Technology.
116 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.
3 credits · NCCRSEnroll →