UPI Study › Courses › Ethics in Technology › Free lessons › Lesson 9.7 Free with a free account
Trojans, Delivery Routes, and Defensive Decisions
Ethics in Technology · Chapter 9: Data Breaches, Digital Infections, and the Malware EcosystemSection 9.7 · lesson 48 of 11616 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: Computer Worms and Network Containment →← Classifying Viruses by Infection, Runtime, and ConcealmentNext lesson: Computer Worms and Network Containment →
In this lesson
Understand disguises, delivery routes, hidden capabilities, and defense beyond an apparently trustworthy download.
- Distinguish deceptive functionality from virus replication.
- Compare six delivery routes and four functional families.
- Explain compromised-browser risk and the Zeus ecosystem.
- Combine installation controls, limited authority, monitoring, and trusted recovery.
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,837 words). Read along, or search it.
Chapter 9
Trojans and Deceptive Software
A Trojan presents useful or legitimate apparent functionality while concealing a malicious function. Its name recalls misplaced trust in a gift brought inside a defended boundary. The defining idea is deception, rather than replication through infection of another host. A classic Trojan does not reproduce itself, but operators can distribute copies or deliver further malware. We examine attachments, fake downloads, false updates, bundles, unauthorized packages, and compromised supply chains. Those routes make the installation decision important, without making it the only possible point of defense. Remote access, backdoors, staged delivery, and banking theft describe four functional families that can overlap. The banking example explains why genuine encrypted transport cannot certify a compromised browser. Zeus illustrates reusable criminal software and the need for technical and international institutional cooperation. Installation controls, limited authority, monitoring, authentication, independent verification, and trustworthy recovery all contribute. We retain the mechanisms while avoiding promises that one setting or one cleanup always defeats the entire incident.
Definition and Distinction
A Useful Appearance Can Conceal an Unauthorized Function
NIST describes a Trojan horse as a seemingly useful program containing hidden malicious functionality. The useful appearance can exploit trust or legitimate permission granted to the program. Virus classification instead depends on replication through infection of a host. A classic standalone Trojan is not self-replicating, even if an operator distributes many copies. A combined campaign may include a Trojan, a virus, another payload, or existing unauthorized access. The payload is what the code does after execution, distinct from the appearance that obtained trust. Command and control supports malicious instructions, information return, or coordination. Persistence describes mechanisms that allow access or execution to continue or resume. Deliberate installation by an unsuspecting owner is common, but an administrator or automated process can also introduce code. Exploitation or an existing intrusion can introduce deceptive functionality, so the label does not exclude software vulnerabilities. Replication-only detection may miss it, while file, execution, account, network, and behavioral evidence can still expose the threat.
Delivery Routes I
Attachments, Fake Downloads, and False Updates Seek Trust
A message attachment may imitate an invoice, delivery notice, application, or familiar conversation. The content can contain executable instructions or introduce a later installer. Filtering risky content and independently verifying unexpected requests reduce that delivery opportunity. A fake download page may appear through a search result or advertisement. A plausible address and familiar branding do not establish genuine publisher provenance. Use an independently verified publisher address or trusted bookmark, and follow approved installation processes. A false update prompt claims that a browser or media component urgently needs replacement. Use the application's normal update process, or independently reach the official publisher. An unsolicited prompt is a warning sign, rather than proof that all updates offered through websites are fraudulent. A known sender's name or convincing design is insufficient evidence that the offered code is safe. The useful pause is before execution, when independent verification and maintained technical controls can interrupt misplaced trust.
Delivery Routes II
Bundling, Unlicensed Packages, and Supply Chains Add Different Risks
A bundled installer may deliver wanted software alongside additional components. Installation screens can reveal some choices, but do not expose every hidden malicious modification. A cracked or pirated package can contain unauthorized changes while promising paid functionality. Organizations can prohibit unauthorized installation and provide practical access to approved alternatives. Avoid assuming that users cannot or will not report a suspicious package; early reporting supports recovery. A supply-chain compromise alters a component, build, or update before the customer receives it. Code inserted before signing can arrive through the normal publisher with a valid signature. Not every supply-chain incident passes every check, so provenance verification remains useful. A signature supplies particular origin and integrity evidence, rather than certifying every behavior of the software. Supplier assurance, verified releases, tested deployment, segmentation, and behavioral monitoring complement the download decision. Trust must continue after installation, because a correct-looking source alone cannot address every malicious function or compromised dependency.
Four Functional Families
The Disguise Does Not Tell You the Full Capability
Remote access Trojans provide malicious viewing, control, or collection through capabilities available to the program. A backdoor creates an unauthorized route for later access. Droppers and downloaders introduce further components, separating delivery from later activity. A dropper carries or releases a stage, while a downloader retrieves one from elsewhere. Banking Trojans target financial information or activity, sometimes through the customer's browser. A single program can combine several of these roles. The disguise that obtained trust therefore does not tell responders the complete capability. Remote viewing, recording, control, or execution depends on implementation, permissions, devices, and communication. A backdoor can survive a narrow remedy, without guaranteeing permanent access despite effective eradication. An authorized remote administration tool is not automatically a Trojan simply because it permits remote control. Hidden functionality, permission, actual capabilities, and the context of use determine why a particular program is a security concern.
Remote Access and Safeguarding
Remote Control Can Adapt to What the Operator Finds
A remote operator may view the screen, inspect accessible files, or capture keystrokes. Those capabilities can expose private information and credentials. Microphone or camera access may extend surveillance beyond information already stored on the device. Available program execution can introduce more tools or alter activity within the operator's effective authority. Live direction makes an intrusion adaptable, rather than limiting it to a fixed sequence. Not every remote access program has every capability, or remains invisible to monitoring. Remote access malware and misused monitoring tools can also support stalking or domestic abuse. Someone with physical access may install monitoring without the affected person's informed permission. In that situation, personal safety should guide the response rather than a routine immediate cleanup. Use a safer device to seek qualified support and plan evidence preservation; removing access may alert an abuser. A survivor-centered safety plan should guide technical changes, without directing someone to confront the suspected operator or increase exposure.
Backdoors and Recovery
Removing the First Program May Leave Another Route
Removing the first discovered Trojan does not establish that the whole incident has ended. The operator may have added another access route, account, component, or persistence mechanism. A password change may leave a backdoor that uses a different method. That possibility does not mean the backdoor must survive effective eradication and access revocation. Responders should establish the affected systems, credentials, accounts, and subsequent activity. Use the approved process to contain affected resources and revoke compromised access. For serious or uncertain compromise, rebuilding from verified clean material can help restore device trust. Preserve necessary evidence and coordinate the recovery, rather than deleting clues before understanding the scope. A clean device alone does not revoke every stolen session or repair every cloud account. It also cannot undo information already stolen, so account and environment recovery remain necessary. Verify restored configurations, access, updates, and monitoring before normal reconnection, rather than treating one removed file as complete proof.
Droppers and Downloaders
A First Stage Can Introduce Further Components
A first-stage program may introduce additional components that perform later malicious activity. A dropper releases a component it carries, while a downloader retrieves one from elsewhere. Campaigns can combine those roles, or include several overlapping stages. Small size and ordinary appearance are possible, rather than required defining features. Staged delivery lets operators replace components or delay selected activity. For responders, finding the first file raises a broader investigation question. What was released or retrieved, and did that component actually execute? Delivery, execution, persistence, and damage are separate observations that need evidence. Additional code, stolen credentials, or unauthorized access may remain after a narrow file removal. A downloader needs a retrieval route, but every Trojan does not require continuous communication with an operator. Follow execution, file, account, and network evidence through the authorized response process to establish the full scope of the incident.
Banking Trojans
Transport Encryption Cannot Make a Compromised Endpoint Trustworthy
The source's banking example concerns malware manipulating the customer's own browser. The customer may still reach the genuine bank through a genuinely encrypted connection. Malware can capture information or change transaction details before transport encryption protects them. It may also alter the displayed payee, payment, or balance to conceal the difference. The bank's actual record can therefore differ from what the affected browser shows. Checking the destination remains useful against impersonation and fake websites. Encryption still protects the communication channel against particular interception risks. Neither check establishes that the customer's device or displayed transaction is trustworthy. Not every banking Trojan uses this exact method, so the example describes one important mechanism. Banks can apply further authentication and fraud monitoring; a logged-in session is not automatically considered unquestionable. Endpoint integrity, independent transaction verification, and appropriate reporting complement address checks and encrypted transport, rather than making those checks worthless.
Zeus Ecosystem
Reusable Criminal Software Separates Development from Operation
Zeus banking malware appeared at least as early as two thousand seven. It became a toolkit supporting separately configured criminal campaigns and financial information theft. That product-like design separated writing the underlying code from operating a campaign. A source-code leak in two thousand eleven supported derived families and reuse of features. This lineage was broader than one program or a single operator. The model lowered some barriers, without eliminating every skill or making all criminal software identical. Gameover Zeus was a later variant with decentralized botnet coordination. The two thousand fourteen disruption combined international law enforcement, private technical specialists, legal orders, and victim assistance. The related Cryptolocker disruption was another part of the coordinated action. Reducing infrastructure control did not prove that every affected device was clean or every Zeus-derived infection ended forever. Charges concern alleged conduct unless established in court; the lasting lesson joins technical recovery with coordinated institutional action.
Prevention and Containment
Control Both Entry Decisions and What Running Code Can Do
Approved software and application controls directly reduce many opportunities for deceptive execution. Their rules and trust exceptions need maintenance, rather than a promise of perfect prevention. Verified sources and managed updates address fake packages and known vulnerabilities. Supply-chain risks and existing intrusion paths still require complementary controls. Limited accounts and segmentation restrict authority and reach, while user-accessible data remains exposed to available permissions. Privilege escalation or broader authorization can expand that reach, so one limited account is not universal confinement. Behavioral monitoring correlates execution, files, accounts, and network activity to investigate suspicious evidence. An unfamiliar connection is a clue, rather than automatic proof that every document connection is malicious. Outbound restrictions and logs can reduce or expose selected communication routes, while permitted channels and offline activity still matter. Multifactor authentication limits reuse of captured credentials; prefer phishing-resistant methods where supported. No unsupported single-control ranking is needed: combine installation decisions, maintained systems, restricted authority, visibility, and response around the actual mechanism.
Independent Verification and Review
Verify the Transaction Through a Trustworthy Separate Channel
If a browser may be compromised, verifying only what it displays can repeat the same deception. Use a separately trusted bank channel, and a trustworthy separate device where needed. Confirm the actual payee and amount, rather than merely approving an unexpected login or generic notification. Reach the bank independently, instead of relying on contact details supplied in a suspicious message. Multifactor authentication helps protect account access, but does not certify a compromised endpoint or every action after login. Independent verification complements authentication, fraud monitoring, device integrity, and response. For review, distinguish deceptive functionality from a virus's host infection and self-replication. Explain why supply-chain compromise can undermine reliance on publisher provenance alone. Describe why additional stages and backdoors broaden the scope of recovery after one program is removed. Software approval creates administrative tradeoffs, so provide workable approval paths, necessary tools, and supportive reporting. Effective protection follows evidence and the full environment, without claiming that one trusted-looking channel or one cleanup defeats every attack.
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 Trojans, Delivery Routes, and Defensive Decisions
What is a Trojan horse in computing?
How do Trojans get onto a computer?
What is the difference between a RAT, a backdoor, a dropper and a downloader?
What was the Zeus banking Trojan?
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 →