Common Cyber Attacks

A cyber attack is any deliberate attempt to steal, expose, alter, disable, or destroy data or the systems that hold it. Most real breaches do not use exotic zero-days. They reuse a small set of well-known techniques against three targets: people, networks, and web applications. Learning to recognize these patterns is the core skill of a defender. For each attack on this sheet, focus on four things: what it is, how it works at a high level, one tell-tale sign that gives it away, and the primary defense that shuts it down. Everything here is defensive and conceptual. It teaches you to spot and stop attacks, not to carry them out.

Phishing is a fraudulent message (email, text, or phone call) that impersonates someone you trust to trick you into handing over credentials, clicking a malicious link, or opening an attachment. It is the most common way attackers gain their first foothold. Variants worth knowing: Spear phishing targets one specific person using real details about them or their job. Whaling is spear phishing aimed at executives or other high-value targets. Smishing arrives by SMS text, and vishing arrives by voice call. All of these are forms of social engineering, which means manipulating a human being instead of exploiting a software bug. The attacker leans on authority, urgency, fear, or the promise of a reward to push you into acting before you think.

In a man-in-the-middle attack, the attacker quietly positions themselves between you and the server you think you are talking to, so they can read or change the traffic in transit. Classic settings include open coffee-shop Wi-Fi, a rogue access point named to look legitimate, and ARP spoofing on a local network. The main defense is encryption in transit. When traffic is protected with TLS (HTTPS), an attacker in the middle sees only ciphertext and cannot silently tamper with it. That is why a valid certificate matters, and why you can inspect a server's certificate yourself before trusting it.

A denial-of-service (DoS) attack tries to make a system unavailable to its real users, usually by exhausting a resource such as bandwidth, connections, CPU, or memory. A distributed denial-of-service (DDoS) attack does the same thing from thousands of compromised machines at once, often a botnet, which makes it much harder to block by simply banning one address. The goal is disruption, not data theft, though a DDoS is sometimes used as a smokescreen to distract defenders from another attack. Defenses work in layers: absorb the flood with a CDN or scrubbing service, filter obviously bad traffic, rate-limit each client, and keep spare capacity in reserve to ride out a spike.

Web applications get attacked when they treat untrusted user input as trusted code. Two classics dominate. SQL injection happens when input from a form or URL is glued straight into a database query, so a crafted value runs as SQL instead of being stored as data. The fix is to never build queries by concatenating strings. Use parameterized queries (prepared statements), which send the code and the data separately so input can never change the query's structure. Cross-site scripting (XSS) happens when an application returns user-supplied content in a page without escaping it, so a malicious script runs in another visitor's browser and can steal their session. The fix is to encode output for the context it lands in, add a Content-Security-Policy header, and mark session cookies HttpOnly so scripts cannot read them.

A brute-force attack simply tries password after password until one works. On its own it is slow, so attackers use smarter variants: Dictionary attacks try common words and known-bad passwords first. Credential stuffing replays username and password pairs leaked from other breaches, betting that people reuse passwords. Password spraying tries one common password (like a season plus a year) against many accounts to stay under lockout limits. Offline cracking runs against stolen password hashes, where rainbow tables can reverse unsalted hashes quickly. The defenses stack up: rate-limit and lock out repeated failures, require long unique passwords (a password manager makes this painless), store hashes with a per-user salt using a slow algorithm like bcrypt or argon2, and above all turn on multi-factor authentication, which makes a stolen password nearly useless on its own.

Many attacks target a handful of well-known network services. Knowing the port and what runs on it helps you read logs, spot exposure, and reason about defenses.

No single control stops every attack, so defenders stack independent layers, an approach called defense in depth. Patch software to remove known holes, train people to resist social engineering, encrypt traffic to defeat interception, validate and parameterize input to block injection, and require MFA to blunt password attacks. If one layer fails, the next still stands. Notice how a few controls appear again and again across the whole table: MFA, encryption in transit, input validation, and user awareness. Master those and you cover the large majority of real attacks.

Using ssh-auth.log, write ONE command for each question using pipes. Every failed-login line ends with from <IP> port <number> ssh2, so awk '{print $(NF-3)}' prints the IP address and awk '{print $(NF-5)}' prints the username, even on invalid user lines. 1. How many lines record a failed password? ( grep -c "Failed password" ) 2. List each IP address that had a failed password, with a count of its failures, sorted from most to least. ( grep, awk, sort, uniq -c, sort -nr ) 3. The busiest attacking IP eventually got in. Which account did it log into, and at what time? ( grep "Accepted" ) 4. How many different usernames did that same IP try in its failed-password lines? ( grep, grep, awk, sort -u, wc -l ) Using suspicious-email.txt, find each red flag: 5. The domain in the From: address differs from the real school domain in the To: address by exactly one character. What is the lookalike domain, and which character was swapped for what? 6. If you replied to this email, what address would your reply actually go to? ( grep "Reply-To" ) 7. How many defanged links are in the file? Count the lines containing ://. ( grep -c ) 8. The Step 2 link starts with kestrelvalley, but a hostname belongs to the domain at its right-hand end. After refanging it, what registered domain (the last two labels of the hostname) does it really go to? 9. Exactly one link uses unencrypted http instead of https. Which step is it in, and what registered domain does it go to? ( grep "hxxp://" )