Cyber Security Practice Tasks

1.1 Find your own private IP, public IP and gateway

Why: Every security check starts with knowing which address is yours. If you mix up private and public IPs you may scan the wrong machine.

What: On your own laptop or lab VM, write down your private IP, default gateway and public IP.

How:

1. Linux/macOS: run ip -4 addr show (or ifconfig). Windows: run ipconfig.
2. Find the line with inet / IPv4 Address that is not 127.0.0.1.
3. Run ip route | grep default (Windows: Default Gateway line) to find the gateway.
4. Run curl -s https://ifconfig.me to see your public IP.
5. Write the three values in a table.

Expected output: Private IP like 192.168.1.23, gateway like 192.168.1.1, public IP that is NOT in 10.x, 172.16–31.x or 192.168.x.

1.2 Classify IPs in a bank branch device list

Why: Banks must keep ATMs and staff PCs on private networks. Spotting a public IP on an internal device is a real audit finding.

What: Use the data file below. Mark each IP as Private, Public or Loopback.

Data file: branch-devices.csv

About this file: A made-up list of devices in bank branches. Each row is one device. Columns: Device = device name; Branch = city; IP = the IPv4 address the device uses.

How:

1. Open the CSV in any editor.
2. Compare each IP with the three private ranges.
3. 127.x.x.x is loopback (the machine itself).
4. Write the class next to each row.
5. Optional: check in Python with import ipaddress; ipaddress.ip_address('10.20.1.15').is_private.

Expected output: ATM-01 Private, Teller-PC-3 Private, CCTV-NVR Private, Printer-2 Public, Health-check Loopback.

1.3 Subnet math for a hospital network

Why: Hospitals separate medical devices from guest Wi-Fi using subnets. You must know how many hosts fit.

What: For 10.50.8.0/22, find network address, broadcast, first host, last host and usable host count.

How:

1. Run python3 -c "import ipaddress as i;n=i.ip_network('10.50.8.0/22');print(n.network_address,n.broadcast_address,n.num_addresses-2)".
2. First host = network + 1, last host = broadcast − 1.
3. Check by hand: /22 leaves 10 host bits, 2^10 = 1024.

Expected output: Network 10.50.8.0, broadcast 10.50.11.255, first 10.50.8.1, last 10.50.11.254, 1022 usable hosts.

2.1 List listening ports on your own VM

Why: An open port you don't know about is a door you forgot to lock.

What: On your own Linux VM, list every listening TCP port and the program behind it.

How:

1. Run sudo ss -tulpn.
2. Look at the Local Address column (e.g. 0.0.0.0:22).
3. Note the program name in the Process column.
4. Mark which ports listen on 0.0.0.0 (all interfaces) vs 127.0.0.1 (local only).

Expected output: At least :22 sshd. If nginx is installed, :80 nginx.

2.2 Match ports to services for a retail store server

Why: Shop servers in Bengaluru or Toronto often expose FTP by mistake. You must recognise risky ports fast.

What: Use the data file. Name the protocol and say Keep, Replace or Close.

Data file: store-ports.csv

About this file: Made-up scan results from a shop's own servers. Each row is one open port. Columns: Port = port number; Seen on = which server and city.

How:

1. Look up each port in the chapter's well-known port list.
2. Decide if the protocol encrypts traffic.
3. Choose Keep (needed and safe), Replace (use a safe version) or Close.

Expected output: 21 FTP → Replace with SFTP; 22 SSH → Keep (keys only); 23 Telnet → Close; 443 HTTPS → Keep; 3306 MySQL → Close to the internet (localhost only).

2.3 Test a port with nc and curl on localhost

Why: Before opening a firewall rule you should prove a service works locally.

What: Start a tiny Python web server on port 8080 and test it.

How:

1. Run python3 -m http.server 8080 --bind 127.0.0.1 in one terminal.
2. In another run nc -zv 127.0.0.1 8080.
3. Then run curl -I http://127.0.0.1:8080/.
4. Stop the server with Ctrl+C and run nc again.

Expected output: nc says 'succeeded'/'open'; curl shows HTTP/1.0 200 OK. After stopping, nc says 'Connection refused'.

3.1 See the TCP 3-way handshake with tcpdump

Why: Attack logs talk about SYN floods and half-open scans. You must recognise SYN, SYN-ACK, ACK.

What: Capture the handshake when you curl a local web server.

How:

1. Start python3 -m http.server 8000 --bind 127.0.0.1.
2. Run sudo tcpdump -i lo -n port 8000 -c 6.
3. In a third terminal run curl -s http://127.0.0.1:8000/ >/dev/null.
4. Read the flags: [S], [S.], [.].

Expected output: Three lines in order: Flags [S], Flags [S.], Flags [.].

3.2 Put incidents on the right OSI layer

Why: Saying the right layer helps the right team fix it fast.

What: Use the data file and assign an OSI layer to each incident.

Data file: incidents.csv

About this file: Made-up incident list. Each row is one incident. Columns: Incident = what happened; City = where.

How:

1. Read the 7 layers in the chapter.
2. Match physical, data link, network, transport, application.
3. Write the layer number next to each row.

Expected output: Cable 1, ARP 2, route 3, SYN flood 4, SQL injection 7.

3.3 TCP vs UDP with DNS lookups

Why: DNS normally uses UDP; seeing it helps you spot DNS tunnelling later.

What: Capture one DNS query and see the protocol.

How:

1. Run sudo tcpdump -n -i any port 53 -c 4.
2. In another terminal run dig example.com.
3. Then run dig +tcp example.com.

Expected output: First lookup shows UDP packets; the +tcp lookup shows TCP flags [S].

4.1 Fix a too-open security group (paper task)

Why: SSH open to 0.0.0.0/0 is the most common cloud mistake.

What: Use the data file and rewrite each rule safely.

Data file: security-group.csv

About this file: Made-up inbound rules of a shop's EC2 server. Each row is one rule. Columns: Port = port allowed; Source = who may connect (0.0.0.0/0 = everyone); Purpose = why it was added.

How:

1. For each rule ask: does the whole internet need it?
2. Admin ports → your IP /32 only.
3. Databases → no internet rule; app connects locally or by security group.
4. Unused test ports → delete.

Expected output: 22 → your-ip/32; 80 → keep; 3306 → delete; 8080 → delete.

4.2 Check key file permissions before SSH

Why: SSH refuses a key that others can read, and a leaked key = server takeover.

What: Create a dummy key and set safe permissions.

How:

1. Run ssh-keygen -t ed25519 -f ~/lab-key -N ''.
2. Run ls -l ~/lab-key.
3. Run chmod 400 ~/lab-key.
4. Run ls -l ~/lab-key again.

Expected output: Permissions change to -r--------.

4.3 Read who logged in to your VM

Why: After launch, check that only you have logged in.

What: On your own VM, list recent logins and failed attempts.

How:

1. Run last -n 10.
2. Run sudo grep 'Failed password\|Invalid user' /var/log/auth.log | tail (Amazon Linux: sudo journalctl -u sshd | grep Failed).
3. Count unique attacking IPs: ... | grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}' | sort | uniq -c | sort -rn | head.

Expected output: Your own IP in last; on a public VM, failed tries from unknown IPs.

5.1 Build a safe evidence folder

Why: Investigators keep files in a folder only they can read.

What: Create ~/case-001 with notes.txt, readable only by you.

How:

1. mkdir -p ~/case-001
2. echo 'Case for HDFC-test branch, Pune' > ~/case-001/notes.txt
3. chmod 700 ~/case-001 && chmod 600 ~/case-001/notes.txt
4. ls -ld ~/case-001; ls -l ~/case-001

Expected output: drwx------ for the folder, -rw------- for the file.

5.2 Find large and recent files

Why: Attackers drop big archives or new scripts. find helps you spot them.

What: List files in /tmp changed in the last day and files over 10 MB in /var.

How:

1. find /tmp -type f -mtime -1 -ls
2. sudo find /var -type f -size +10M -exec ls -lh {} \;
3. Write down anything unexpected.

Expected output: Mostly logs and package caches in /var.

5.3 Count lines and words in a patient export

Why: Before sending a file, check how many records it has.

What: Make the file below and count rows.

Data file: patients.csv

About this file: Made-up patient list. Each row is one patient. Columns: PatientID = unique ID; Name = patient name; City = home city.

How:

1. Save the data as patients.csv with nano.
2. Run wc -l patients.csv.
3. Run tail -n +2 patients.csv | wc -l to skip the header.

Expected output: 4 lines total, 3 records.

6.1 Top attacking IPs from a sample log

Why: grep, awk, sort and uniq turn thousands of log lines into a short answer.

What: Use the sample log and find which IP failed most.

Data file: auth-sample.log

About this file: Made-up SSH log. Each line is one login attempt. Parts: time, program (sshd), result (Failed/Accepted), user, source IP. IPs are documentation ranges, not real people.

How:

1. Save lines to auth-sample.log.
2. grep 'Failed' auth-sample.log | awk '{print $NF}' | sort | uniq -c | sort -rn

Expected output: 3 203.0.113.7 then 1 198.51.100.4.

6.2 Watch a process and its open ports

Why: Malware hides as normal names. ps + lsof show what really runs.

What: Start a Node or Python server and find its PID, user and port.

How:

1. node -e "require('http').createServer((q,r)=>r.end('ok')).listen(3000,'127.0.0.1')" & (or python3 -m http.server 3000 &)
2. ps aux | grep -E 'node|http.server' | grep -v grep
3. sudo lsof -i :3000
4. kill %1

Expected output: lsof shows the PID listening on 127.0.0.1:3000.

6.3 Hash files to detect changes

Why: A changed hash means a changed file — key for integrity checks.

What: Hash a config file, change one letter, hash again.

How:

1. echo 'limit=50000 INR' > cfg.txt; sha256sum cfg.txt
2. sed -i 's/50000/90000/' cfg.txt; sha256sum cfg.txt

Expected output: Two completely different hashes.

7.1 Read the nginx access log like an analyst

Why: Access logs show who visited, what they asked for and the result.

What: Make 5 requests on your local nginx and read them.

How:

1. sudo apt install nginx (lab VM).
2. for p in / /track /admin /.env /; do curl -s -o /dev/null http://127.0.0.1$p; done
3. sudo tail -n 5 /var/log/nginx/access.log
4. sudo awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c

Expected output: 200 for /, 404 for /track, /admin, /.env.

7.2 Block hidden files in nginx

Why: A public .git or .env leaks passwords.

What: Add a rule that denies dotfiles, then prove it.

How:

1. echo SECRET=x | sudo tee /var/www/html/.env
2. curl -s http://127.0.0.1/.env (shows SECRET — bad).
3. Add location ~ /\. { deny all; } inside the server block in /etc/nginx/sites-available/default.
4. sudo nginx -t && sudo systemctl reload nginx
5. curl again, then delete the test file.

Expected output: Before: SECRET=x. After: 403 Forbidden.

7.3 Compare Apache and nginx headers

Why: Server headers tell attackers your version.

What: Run both in Docker and compare the Server header.

How:

1. docker run -d --rm -p 8081:80 --name a httpd
2. docker run -d --rm -p 8082:80 --name n nginx
3. curl -sI localhost:8081 | grep -i server; curl -sI localhost:8082 | grep -i server
4. docker stop a n

Expected output: Apache/2.4.x and nginx/1.x — versions are visible.

8.1 Host a shop page safely in Docker

Why: Even a simple page should only serve the files you meant to publish.

What: Serve one index.html for 'Sharma Sweets, Jaipur' with nginx in Docker.

How:

1. mkdir site && echo '<h1>Sharma Sweets, Jaipur</h1>' > site/index.html
2. docker run -d --rm -p 8090:80 -v $PWD/site:/usr/share/nginx/html:ro --name s nginx
3. curl -s localhost:8090
4. curl -s -o /dev/null -w '%{http_code}' localhost:8090/../etc/passwd

Expected output: The h1 text, and 400/404 for the path trick.

8.2 Check file permissions in the web root

Why: Web files writable by www-data let a hacked app rewrite your site.

What: Make site files owned by your user and read-only for nginx.

How:

1. sudo chown -R $USER:www-data /var/www/html
2. sudo find /var/www/html -type d -exec chmod 750 {} \;
3. sudo find /var/www/html -type f -exec chmod 640 {} \;
4. curl -I http://127.0.0.1/

Expected output: Site still loads with 200.

8.3 Make a custom 404 page that leaks nothing

Why: Default error pages reveal server info.

What: Add a plain 404 page for a clinic site.

How:

1. echo 'Page not found – City Clinic, Kolkata' | sudo tee /var/www/html/404.html
2. Add error_page 404 /404.html; and server_tokens off; in nginx.
3. sudo nginx -t && sudo systemctl reload nginx
4. curl -si http://127.0.0.1/nope | head

Expected output: Your text, and Server header without version.

9.1 Turn off PHP error display

Why: PHP errors print file paths and SQL to attackers.

What: Make a page with an error and stop it showing to visitors.

How:

1. echo '<?php echo $x->y;' | sudo tee /var/www/html/err.php
2. curl -s http://127.0.0.1/err.php
3. In php.ini set display_errors = Off and log_errors = On.
4. sudo systemctl restart php*-fpm; curl again; delete err.php.

Expected output: Before: Warning with path. After: empty page; error goes to the log.

9.2 Remove phpinfo leftovers

Why: phpinfo() shows versions, paths and env vars.

What: Find and remove any info pages.

How:

1. sudo grep -rl 'phpinfo' /var/www/
2. Delete or move each file out of the web root.
3. curl the old URL.

Expected output: 404 for the old info.php.

9.3 Escape output in a feedback form

Why: Printing user input directly allows XSS.

What: Build a tiny PHP form and fix it with htmlspecialchars.

How:

1. Create fb.php: <?php echo 'Thanks '.$_GET['n'];
2. curl 'http://127.0.0.1/fb.php?n=<b>Riya</b>' → raw tag.
3. Change to htmlspecialchars($_GET['n'] ?? '', ENT_QUOTES).
4. curl again; delete the file.

Expected output: After fix: <b>Riya</b>.

10.1 Create an orders table and query it

Why: You must read data before you can protect it.

What: Create the table from the data file in a MySQL Docker container.

Data file: shipments table

About this file: Made-up shipment records. Each row is one shipment. Columns: id = number; customer = name; city = destination; amount = practice value (not a real fee); currency = code.

How:

1. docker run -d --rm --name db -e MYSQL_ROOT_PASSWORD=labpass -p 127.0.0.1:3306:3306 mysql:8
2. Wait 20 s, then docker exec -it db mysql -uroot -plabpass
3. CREATE DATABASE lab; USE lab; CREATE TABLE ship(id INT PRIMARY KEY, customer VARCHAR(50), city VARCHAR(40), amount INT, currency CHAR(3));
4. INSERT the 3 rows.
5. SELECT customer, city FROM ship WHERE currency='INR';

Expected output: One row: Rahul Deshmukh | Aurangabad.

10.2 Make a read-only reporting user

Why: Reports should never be able to delete data.

What: Create user 'report' with SELECT only.

How:

1. CREATE USER 'report'@'%' IDENTIFIED BY 'Rep0rt!lab';
2. GRANT SELECT ON lab.* TO 'report'@'%';
3. Log in as report and try DELETE FROM lab.ship;

Expected output: ERROR 1142: DELETE command denied.

10.3 Safe query from Python vs unsafe

Why: String-built SQL is how SQL injection happens.

What: Query by city with a parameter, not string join.

How:

1. pip install pymysql
2. Unsafe: cur.execute("SELECT * FROM ship WHERE city='"+c+"'") with c="x' OR '1'='1" → all rows.
3. Safe: cur.execute('SELECT * FROM ship WHERE city=%s',(c,))
4. Compare row counts.

Expected output: Unsafe returns 3 rows; safe returns 0.

11.1 Back up before you UPDATE

Why: One wrong UPDATE without WHERE can change every customer's balance.

What: Back up table ship (from ch10 task), then run a safe UPDATE.

How:

1. docker exec db mysqldump -uroot -plabpass lab ship > ship.sql
2. START TRANSACTION;
3. UPDATE ship SET city='Pune' WHERE id=1;
4. SELECT * FROM ship; then COMMIT;

Expected output: Only row 1 changes; ship.sql exists and is not empty.

11.2 Catch a missing WHERE with safe-updates

Why: MySQL can refuse dangerous updates for you.

What: Turn on sql_safe_updates and try an UPDATE with no WHERE.

How:

1. SET sql_safe_updates=1;
2. UPDATE ship SET amount=0;
3. Read the error.

Expected output: ERROR 1175: safe update mode.

11.3 Add a foreign key for a hospital

Why: Keys stop orphan records, like a visit for a patient who doesn't exist.

What: Create patients and visits tables linked by a key.

How:

1. CREATE TABLE pat(id INT PRIMARY KEY, name VARCHAR(40));
2. CREATE TABLE visit(id INT PRIMARY KEY, pat_id INT, FOREIGN KEY(pat_id) REFERENCES pat(id));
3. INSERT INTO pat VALUES(1,'Kavya Rao');
4. INSERT INTO visit VALUES(1,99);

Expected output: ERROR 1452: foreign key constraint fails.

12.1 Read DNS records of example.com

Why: DNS tells you where a name points; wrong records cause outages and takeovers.

What: List A, AAAA, MX, NS and TXT for example.com.

How:

1. dig +short A example.com
2. Repeat for AAAA, MX, NS, TXT.

Expected output: IP addresses for A/AAAA, name servers for NS.

12.2 Spot a dangling CNAME (paper task)

Why: A CNAME pointing to a deleted cloud resource can be taken over.

What: Use the data file and mark risky records.

Data file: dns-records.csv

About this file: Made-up DNS records of a shop. Each row is one record. Columns: Name = sub-name; Type = record type; Target = where it points; Target exists? = whether that resource is still alive.

How:

1. Read each row.
2. Ask: does the target still exist?
3. Mark Risky if target is deleted.

Expected output: shop-old is Risky; others OK.

12.3 Fake a domain locally with /etc/hosts

Why: Testing on a local name avoids touching real domains.

What: Make track.lab point to 127.0.0.1.

How:

1. echo '127.0.0.1 track.lab' | sudo tee -a /etc/hosts
2. ping -c1 track.lab
3. curl -I http://track.lab/ (nginx running)
4. Remove the line afterwards.

Expected output: Ping replies from 127.0.0.1.

13.1 Two sites on one nginx

Why: Name-based hosting saves cost, but a wrong default server can show the wrong shop.

What: Serve a.lab and b.lab from different folders.

How:

1. Add both names to /etc/hosts → 127.0.0.1.
2. Create two server blocks with server_name a.lab / b.lab.
3. sudo nginx -t && sudo systemctl reload nginx
4. curl -s a.lab; curl -s b.lab

Expected output: Different page text for each name.

13.2 Self-signed HTTPS for a lab site

Why: You can practise TLS without a real domain.

What: Create a self-signed cert and serve HTTPS.

How:

1. openssl req -x509 -nodes -newkey rsa:2048 -days 7 -subj '/CN=a.lab' -keyout a.key -out a.crt
2. Add listen 443 ssl; ssl_certificate / ssl_certificate_key.
3. curl -vk https://a.lab/ 2>&1 | grep -iE 'subject|TLS'

Expected output: subject: CN=a.lab and TLSv1.3/1.2.

13.3 Check HTTP→HTTPS redirect

Why: Login pages must never stay on HTTP.

What: Prove port 80 redirects.

How:

1. Add return 301 https://$host$request_uri; to the port 80 block.
2. curl -sI http://a.lab/

Expected output: 301 with Location: https://a.lab/.

14.1 Find public objects in a bucket policy (paper)

Why: Public S3 buckets leak patient files every year.

What: Read the policy in the data file and say what is public.

Data file: policy.txt

About this file: A made-up bucket policy shown as a table. Each row is one field of one statement. Columns: Field = policy key; Value = its setting.

How:

1. Look for Principal "*".
2. Check Action and Resource.

Expected output: Anyone can GetObject on reports/*.

14.2 Practise S3 locally with MinIO

Why: You can learn S3 without an AWS bill.

What: Run MinIO in Docker, create a private bucket, upload a file.

How:

1. docker run -d --rm -p 127.0.0.1:9000:9000 --name minio minio/minio server /data
2. Use boto3 with endpoint http://127.0.0.1:9000 and keys minioadmin.
3. Create bucket invoices, upload a.txt.
4. curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:9000/invoices/a.txt

Expected output: 403 without credentials.

14.3 Make a presigned URL that expires

Why: Share one file for a short time, not the whole bucket.

What: Generate a 60-second URL in MinIO.

How:

1. Call generate_presigned_url('get_object', Params={'Bucket':'invoices','Key':'a.txt'}, ExpiresIn=60).
2. curl it now, then after 70 s.

Expected output: 200 first, 403 after expiry.

15.1 Review an RDS setup checklist (paper)

Why: Public databases are a top breach cause.

What: Mark each setting Safe or Fix.

Data file: rds-settings.csv

About this file: Made-up RDS settings. Each row is one setting. Columns: Setting = name; Value = current value.

How:

1. Read each row.
2. Decide Safe/Fix.

Expected output: Public access Fix; backups 0 days Fix; encryption on Safe.

15.2 Force TLS to MySQL

Why: Database traffic can be sniffed if not encrypted.

What: Require SSL for a user in Docker MySQL.

How:

1. ALTER USER 'report'@'%' REQUIRE SSL;
2. mysql -h127.0.0.1 -ureport -p --ssl-mode=DISABLED
3. Then with --ssl-mode=REQUIRED.

Expected output: First fails (access denied), second works.

15.3 Restore test of a backup

Why: A backup you never restored is not a backup.

What: Restore ship.sql into a new database.

How:

1. CREATE DATABASE restore_test;
2. docker exec -i db mysql -uroot -plabpass restore_test < ship.sql
3. SELECT COUNT(*) FROM restore_test.ship;

Expected output: Same row count as lab.ship.

16.1 Scan your code for secrets

Why: Keys pushed to Git are found by bots in minutes.

What: Run gitleaks on a test repo.

How:

1. git init demo && cd demo && echo 'AWS_SECRET=abc123fake' > .env && git add . && git commit -m x
2. docker run --rm -v $PWD:/r zricethezav/gitleaks detect -s /r

Expected output: gitleaks reports a leak (or flags .env).

16.2 Limit upload file types (Node)

Why: Unchecked uploads let attackers upload scripts.

What: Accept only mp4 under 50 MB with multer.

How:

1. npm i express multer
2. Use fileFilter checking mimetype video/mp4 and limits fileSize 50e6.
3. curl upload a .php file and an .mp4.

Expected output: .php rejected, .mp4 accepted.

16.3 Least-privilege IAM policy (paper)

Why: The app only needs to put/get videos in one bucket.

What: Rewrite s3:* on * to the minimum.

How:

1. List what the app does.
2. Allow only s3:PutObject and s3:GetObject on arn:aws:s3:::reels-lab/*.

Expected output: Policy with 2 actions and 1 resource.

17.1 Map what you have built

Why: You can't secure what you don't know exists.

What: List every service from ch1–16 tasks.

How:

1. Make a table: service, port, where, data held.
2. Use ss -tulpn and docker ps.

Expected output: A table of 5–10 services.

17.2 Write a one-page lab scope

Why: Professionals always write scope before testing.

What: Write what you may and may not test.

How:

1. In scope: your VM IPs, localhost.
2. Out of scope: office Wi-Fi, any real website.
3. Add dates and your name.

Expected output: A short scope doc.

17.3 Snapshot your VM before Kali

Why: Breaking a lab is normal; recovery should be one click.

What: Take a VirtualBox snapshot named clean-base.

How:

1. GUI: Machine → Take Snapshot.
2. Or VBoxManage snapshot "lab-vm" take clean-base.

Expected output: clean-base listed under Snapshots.

18.1 Legal or not? (paper)

Why: Good intent is not permission.

What: Mark each scenario Legal or Illegal.

Data file: scenarios.csv

About this file: Made-up scenarios. Each row is one situation to judge.

How:

1. Read each row.
2. Ask: written permission from the owner?

Expected output: Rows 1 and 3 Legal; 2 and 4 Illegal.

18.2 Prove your Kali VM is isolated

Why: Attack tools must not reach your home network.

What: Check Kali only sees the host-only network.

How:

1. In Kali run ip -4 addr.
2. ping -c2 8.8.8.8
3. ping -c2 <target VM IP>

Expected output: Internet ping fails; target VM ping works.

18.3 Start a testing log

Why: Logs protect you and help reports.

What: Record every command you run.

How:

1. script -a ~/pentest-$(date +%F).log
2. Run a few commands, then exit.
3. tail ~/pentest-*.log

Expected output: Commands and outputs saved with date.

19.1 Nmap your own VM

Why: Scanning shows what an attacker would see.

What: Scan the target VM's top ports.

How:

1. nmap -sV -T4 192.168.56.101 (use your VM IP)
2. Note open ports and versions.

Expected output: 22/ssh, 80/http etc. with versions.

19.2 Passive recon on a test domain

Why: Passive recon touches nothing on the target.

What: Collect public info for example.com.

How:

1. whois example.com
2. dig NS example.com
3. Open crt.sh and search example.com.

Expected output: Registrar, name servers, cert names.

19.3 Compare SYN vs connect scan in a log

Why: Defenders see scans differently.

What: Run both scans on your VM and watch with tcpdump.

How:

1. On the VM: sudo tcpdump -n port 80 -c 20.
2. From Kali: sudo nmap -sS -p80 VM then nmap -sT -p80 VM.

Expected output: -sT completes the handshake; -sS ends with RST.

20.1 Rank findings by CVSS (paper)

Why: You can't fix everything at once.

What: Sort the data file by risk.

Data file: findings.csv

About this file: Made-up scan findings. Each row is one finding. Columns: ID = finding name; CVSS = severity 0–10; Internet-facing = reachable from the internet.

How:

1. Sort by CVSS high to low.
2. Bump internet-facing items up.

Expected output: CVE-A first, then CVE-C, then CVE-B.

20.2 Scan a Docker image with Trivy

Why: Old images carry known CVEs.

What: Scan nginx:1.19 vs nginx:latest.

How:

1. docker run --rm aquasec/trivy image --severity HIGH,CRITICAL nginx:1.19
2. Repeat for nginx:latest.

Expected output: 1.19 shows many more HIGH/CRITICAL.

20.3 Run Nikto on your lab nginx

Why: Quick web misconfig check.

What: Scan your own VM's HTTP.

How:

1. nikto -h http://192.168.56.101
2. Note missing headers.

Expected output: Missing X-Frame-Options etc.

21.1 Intercept a login in Burp or ZAP

Why: Seeing raw requests is the base of web testing.

What: Proxy a login on local Juice Shop.

How:

1. docker run -d --rm -p 127.0.0.1:3000:3000 bkimminich/juice-shop
2. Set the browser proxy to ZAP/Burp on 127.0.0.1:8080.
3. Log in with a fake account; view POST /rest/user/login.

Expected output: JSON body with email and password.

21.2 Find hidden paths with ffuf

Why: Forgotten pages are common entry points.

What: Brute-force paths on localhost:3000 only.

How:

1. ffuf -u http://127.0.0.1:3000/FUZZ -w /usr/share/wordlists/dirb/common.txt -mc 200

Expected output: Paths like /ftp or /api.

21.3 Read security headers

Why: Headers block many browser attacks.

What: List headers from Juice Shop.

How:

1. curl -sI http://127.0.0.1:3000 | grep -iE 'x-frame|csp|x-content|strict-transport'

Expected output: Some headers present; others missing.

22.1 Hash and crack a lab password

Why: Understand why weak passwords fall.

What: Hash Summer2020 and crack it offline on your own file.

How:

1. echo -n 'Summer2020' | md5sum | tee hash.txt
2. hashcat -m 0 hash.txt /usr/share/wordlists/rockyou.txt --potfile-disable (or john).

Expected output: Cracked: Summer2020.

22.2 Compare hash speeds (paper + demo)

Why: Slow hashes protect passwords even after a leak.

What: Time 1000 MD5 vs a few bcrypt hashes in Python.

How:

1. Use hashlib.md5 in a loop of 1000, then bcrypt.hashpw with gensalt for 20 hashes; print both times.

Expected output: MD5 finishes in milliseconds; bcrypt is much slower.

22.3 Turn on 2FA and a password manager

Why: Even a cracked password fails without the second factor.

What: Set up a password manager and 2FA on an account you own.

How:

1. Install Bitwarden or KeePassXC.
2. Save a new long random password for a test account.
3. Enable TOTP 2FA in the account settings.

Expected output: Login needs password + code.

23.1 Launch Metasploit against a legal lab only

Why: Metasploit is for authorised labs.

What: Exploit a free TryHackMe or Metasploitable VM you own.

How:

1. Confirm written permission / room scope.
2. msfconsole
3. search the lab's suggested module
4. set RHOSTS to your lab IP; run.

Expected output: Session opens on the lab VM.

23.2 Write a one-page exploit report

Why: Reports matter more than shells.

What: Document the lab exploit.

How:

1. Write: target, CVE/module, proof (whoami), impact, fix.
2. Attach a screenshot of the session.

Expected output: A short report with fix steps.

23.3 Match module to CVE (paper)

Why: You must know what you are running.

What: Match each CVE to a Metasploit path in the data file.

Data file: modules.csv

About this file: Made-up matching exercise. Each row is one CVE. Columns: CVE = ID; Module = Metasploit path to fill or check.

How:

1. Look up each CVE name.
2. Match the module path.

Expected output: CVE-2011-2523 → vsftpd_234_backdoor; others as listed.

24.1 Capture a clear-text login

Why: HTTP sends passwords as plain text.

What: Log in over HTTP on your lab and find the password in the capture.

How:

1. Start nginx + a tiny login form over HTTP.
2. sudo tcpdump -i lo -A port 80 -c 30
3. Submit user=me password=Secret123.

Expected output: Secret123 appears in the capture.

24.2 Filter Wireshark for one host

Why: Big captures need filters.

What: Capture and filter your VM's HTTPS.

How:

1. Capture while browsing https://example.com.
2. Display filter: ip.addr==YOUR_IP && tls.
3. Follow → TLS Stream.

Expected output: Encrypted Application Data, not passwords.

24.3 Spot DNS queries in a pcap

Why: DNS shows which sites were contacted.

What: Extract DNS names from a short capture.

How:

1. sudo tcpdump -n port 53 -c 10 -w dns.pcap while you dig.
2. tcpdump -n -r dns.pcap

Expected output: example.com (or your dig name) listed.

25.1 Audit your home Wi-Fi settings

Why: Home routers are often left on WPA2/WPS.

What: Check your own router admin page.

How:

1. Log in to your gateway (often 192.168.0.1 or 192.168.1.1).
2. Note encryption: WPA3 / WPA2 / WEP / Open.
3. Check if WPS is on.

Expected output: WPA3 or WPA2-AES; WPS Off.

25.2 Separate guest Wi-Fi

Why: Guests must not reach shop POS devices.

What: Turn on the guest network on your own router.

How:

1. Enable Guest Wi-Fi.
2. Confirm guest clients cannot ping the main LAN.
3. Put only guest phones on it.

Expected output: Guest IP in a different subnet; LAN ping fails.

25.3 WEP vs WPA2 (paper)

Why: Old standards are broken.

What: Mark each standard Safe or Replace.

Data file: wifi.csv

About this file: Made-up list of Wi-Fi standards. Each row is one standard to judge.

How:

1. Read the data file.
2. Mark each row.

Expected output: WEP Replace; WPA-TKIP Replace; WPA2-AES Keep; WPA3 Keep.

26.1 List your sudo rights

Why: Too much sudo is a common finding.

What: See what your user can run as root.

How:

1. sudo -l
2. Note any NOPASSWD or wildcards.

Expected output: A short list of allowed commands.

26.2 Find SUID binaries

Why: Unexpected SUID files are a classic escalate path.

What: List SUID files and spot odd ones.

How:

1. find / -perm -4000 -type f 2>/dev/null
2. Compare with a clean Ubuntu list.

Expected output: Known tools like passwd, sudo; no random /tmp binaries.

26.3 Capabilities check

Why: Capabilities can replace full root.

What: List files with capabilities.

How:

1. getcap -r / 2>/dev/null
2. Note any with cap_setuid or cap_sys_admin.

Expected output: Usually few entries (ping, etc.).

27.1 Spot the phish (paper)

Why: Most breaches start with a click.

What: Mark each email Safe or Phish.

Data file: emails.csv

About this file: Made-up email samples. Each row is one email. Columns: From = sender; Subject = subject line; Link host = domain the link goes to.

How:

1. Check From domain, urgency, links.
2. Look at the data file.

Expected output: Rows 1 and 3 Phish; 2 Safe.

27.2 Read email headers

Why: Headers show the real path.

What: Inspect Received and Authentication-Results on a real mail to you.

How:

1. Open a mail → Show original / View headers.
2. Find SPF, DKIM, DMARC results.
3. List the Received hops.

Expected output: pass/fail lines for SPF/DKIM/DMARC.

27.3 Write a reporting checklist

Why: Staff need a clear next step.

What: Make a 5-step 'I got a phish' card.

How:

1. Include: don't click, screenshot, forward to security@, delete, tell a manager.
2. Add India's 1930 cybercrime helpline as optional.

Expected output: A one-page checklist.

28.1 Hash evidence before you open it

Why: A changed hash means the file changed.

What: Hash a sample evidence file twice.

How:

1. echo 'case note' > evidence.txt; sha256sum evidence.txt | tee hash1.txt
2. Copy the file; hash again; compare.

Expected output: Both hashes match.

28.2 Build a simple timeline

Why: Order of events proves what happened.

What: Use the data file to sort events.

Data file: events.csv

About this file: Made-up event list. Each row is one event. Columns: Time = clock time; Event = what happened.

How:

1. Sort by time.
2. Write a 4-line story.

Expected output: Login fail → success → file copy → USB mount.

28.3 Read file metadata

Why: Metadata shows created/modified times.

What: Inspect a photo or PDF you own.

How:

1. Linux: stat file.pdf or exiftool file.jpg.
2. Note Created, Modified, Author if present.

Expected output: Times and optional Author.

29.1 Fix a reflected XSS

Why: XSS steals sessions in the browser.

What: Build a vulnerable page, then escape output.

How:

1. PHP: echo $_GET['q'] → open ?q=<script>alert(1)</script>.
2. Change to htmlspecialchars($_GET['q']??'', ENT_QUOTES).

Expected output: Before: alert runs. After: tags shown as text.

29.2 Broken access control demo

Why: Changing an ID in the URL must not show another user's data.

What: Make /invoice?id=1 and /invoice?id=2; log in as user1.

How:

1. Return invoice only if session.user_id matches.
2. Try id=2 as user1.

Expected output: 403 or empty for id=2.

29.3 Security misconfiguration checklist

Why: Defaults and debug pages cause breaches.

What: Audit your local app with the checklist.

Data file: misconfig.csv

About this file: Checklist. Each row is one check to perform on your lab app.

How:

1. Check: debug off, default passwords gone, directory listing off, stack traces hidden.

Expected output: All four items Yes.

30.1 Root account checklist (paper)

Why: Root keys in daily use is a critical finding.

What: Mark each practice Safe or Fix.

Data file: root.csv

About this file: Made-up root account habits. Each row is one practice. Columns: Practice = habit; Status = current state.

How:

1. Read the data file.

Expected output: MFA on Safe; access keys on root Fix; daily root login Fix.

30.2 Enable CloudTrail in your account

Why: Without logs you cannot investigate.

What: Turn on a multi-region trail in your own AWS account.

How:

1. AWS Console → CloudTrail → Create trail.
2. Send to a private S3 bucket.
3. Make a harmless API call; find it in Event history.

Expected output: Event appears within minutes.

30.3 Restrict a security group

Why: 0.0.0.0/0 on admin ports is the classic cloud hole.

What: Edit a lab SG: SSH only from your IP.

How:

1. Find the SG of your lab EC2.
2. Change SSH source to your.public.ip/32.
3. Try SSH from another network (phone hotspot) — should fail.

Expected output: SSH works only from home IP.

31.1 Write an incident note from a log

Why: SOC analysts turn logs into tickets.

What: Use the data file and write Who/What/When/Impact/Next.

Data file: auth.csv

About this file: Made-up auth events. Each row is one attempt. Columns: Time; Result; User; IP.

How:

1. Count fails per IP.
2. Note the successful login after fails.

Expected output: 203.0.113.7 failed 3×; separate success from 192.0.2.10 — document both.

31.2 Severity triage (paper)

Why: Not every alert is Sev-1.

What: Assign Sev-1 to Sev-4.

Data file: alerts.csv

About this file: Made-up alerts. Each row is one alert to triage.

How:

1. Read each alert.
2. Think of customer impact.

Expected output: Ransomware Sev-1; phishing report Sev-3; scan noise Sev-4; payment outage Sev-1.

31.3 Build a simple SIEM query habit

Why: Queries beat scrolling.

What: Find failed SSH in the last hour on your lab.

How:

1. sudo journalctl -u ssh --since "1 hour ago" | grep Failed | wc -l
2. Group by IP with awk/sort/uniq.

Expected output: A count and top IPs.

32.1 Turn on UFW with SSH first

Why: A firewall with no SSH rule locks you out.

What: Enable UFW safely on your VM.

How:

1. sudo ufw allow OpenSSH
2. sudo ufw enable
3. sudo ufw status

Expected output: Status: active; OpenSSH ALLOW.

32.2 Disable password SSH

Why: Keys beat passwords for servers.

What: Allow only public-key login.

How:

1. Copy your key with ssh-copy-id.
2. In sshd_config: PasswordAuthentication no.
3. sudo systemctl reload ssh
4. Try password login — must fail.

Expected output: Password login rejected; key works.

32.3 Install fail2ban

Why: Auto-ban reduces noise and risk.

What: Ban after 3 fails in a lab.

How:

1. sudo apt install fail2ban
2. Set maxretry=3 in jail.local.
3. Fail SSH 3 times from a second IP; check fail2ban-client status sshd.

Expected output: Banned IP listed.

33.1 Verify a file checksum

Why: Downloads can be swapped.

What: Verify a known SHA256.

How:

1. Download a file you trust with a published checksum.
2. sha256sum file and compare to the published hash.

Expected output: Exact match.

33.2 Inspect a website certificate

Why: Wrong names or short keys are red flags.

What: Check https://example.com certificate.

How:

1. echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Expected output: Subject includes example.com; not expired.

33.3 Symmetric vs asymmetric (paper)

Why: Pick the right tool for the job.

What: Match each use case.

Data file: crypto.csv

About this file: Made-up matching. Each row is one use case. Columns: Use case; Type to fill.

How:

1. Read the data file.
2. Pick Symmetric or Asymmetric.

Expected output: Disk encryption Symmetric; code signing Asymmetric; HTTPS session keys Symmetric.

34.1 Know where to report

Why: Speed matters after fraud.

What: Write the main India reporting channels.

How:

1. National Cyber Crime Portal: cybercrime.gov.in
2. Helpline 1930 for financial fraud.
3. Local police cyber cell.

Expected output: All three written with one example each.

34.2 IT Act section match (paper)

Why: Interviews ask basic law.

What: Match section to meaning.

Data file: law.csv

About this file: Awareness table. Each row is one IT Act section. Columns: Section; Meaning to fill.

How:

1. Read each row.

Expected output: 66C identity theft; 66D cheating by personation; 43 damage/unauthorised access.

34.3 Evidence pack for a UPI fraud drill

Why: Good evidence helps the bank and police.

What: List what you would save in a drill.

How:

1. Fake SMS, UPI reference, bank SMS, call recording note, timeline.
2. Hash screenshots with sha256sum.

Expected output: A folder with ≥4 items + hashes.txt.

35.1 Read a bug bounty scope

Why: Out-of-scope tests can be illegal.

What: Open a public program page and list In/Out of scope (read only).

How:

1. Write 3 in-scope assets.
2. Write 3 out-of-scope items.
3. Note rules on automated scanning.

Expected output: Clear In and Out lists.

35.2 Map skills to a job post

Why: See what employers ask.

What: Pick one SOC/analyst JD and mark skills you have.

How:

1. List required tools.
2. Mark Have / Learning / Gap.

Expected output: A 10-row skills table.

35.3 Record a 2-minute mock answer

Why: Clear speaking wins interviews.

What: Answer: How do you secure a new Linux server?

How:

1. Use a phone voice memo.
2. Cover: updates, SSH keys, firewall, users, logs.
3. Listen and note filler words.

Expected output: Under 2 minutes, 5 points covered.

36.1 netcat listener on localhost

Why: nc is a Swiss army knife — practise safely.

What: Send a file over loopback.

How:

1. Terminal A: nc -l 127.0.0.1 4444 > out.txt
2. Terminal B: echo hello | nc 127.0.0.1 4444
3. cat out.txt

Expected output: out.txt contains hello.

36.2 curl for headers and methods

Why: curl replaces many GUI clicks.

What: Probe your lab site.

How:

1. curl -sI http://127.0.0.1/
2. curl -s -X OPTIONS -i http://127.0.0.1/
3. Note Allow and Server headers.

Expected output: Status and header lines printed.

36.3 tmux for long scans

Why: SSH drops kill long jobs without a multiplexer.

What: Run a command inside tmux.

How:

1. tmux new -s lab
2. Start ping -c 100 127.0.0.1.
3. Detach Ctrl-b d; tmux attach -t lab.

Expected output: Ping still running after attach.

37.1 Enumerate SMB on a lab VM

Why: Open shares leak files.

What: List shares on Metasploitable or your Windows lab VM.

How:

1. smbclient -L //192.168.56.101 -N
2. Try smbclient //IP/tmp -N if listed.

Expected output: Share list printed.

37.2 SNMP community string check

Why: Default public leaks host data.

What: Query your lab SNMP if enabled.

How:

1. snmpwalk -v2c -c public 127.0.0.1 system
2. If it works with public → finding.

Expected output: Either data returned (finding) or timeout (good).

37.3 Turn off SMBv1 on Windows lab

Why: SMBv1 enables wormable bugs.

What: Disable SMBv1 on your Windows lab PC.

How:

1. PowerShell Admin: Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol
2. Or use Optional Features GUI.
3. Reboot and verify.

Expected output: SMBv1 feature Disabled.

38.1 Separate admin and daily accounts

Why: Daily browsing as Domain Admin is high risk.

What: On your Windows lab, use two accounts.

How:

1. Create user alice (daily) and alice-adm (admin).
2. Browse the web only as alice.
3. Use Run as different user for admin tools.

Expected output: Two accounts exist; daily has no Domain Admins.

38.2 Read failed logons (4625)

Why: 4625 storms mean password spraying.

What: Generate and read a failed logon on your lab.

How:

1. Try a wrong password on the console.
2. Event Viewer → Security → Filter 4625.
3. Note Account Name and Source Network Address.

Expected output: At least one 4625 event.

38.3 Kerberoasting defence checklist (paper)

Why: Defence first — no attacking production AD.

What: Mark each control Present/Missing for a fictional clinic AD.

Data file: ad-def.csv

About this file: Fictional AD controls. Each row is one control. Columns: Control; In place?.

How:

1. Read the data file.

Expected output: Items with Yes = Present; No = Missing.

39.1 Detect EICAR safely

Why: EICAR is a standard harmless test string.

What: Create and scan the EICAR file.

How:

1. Create eicar.com with the official EICAR test string.
2. clamscan eicar.com

Expected output: FOUND / Eicar-Test-Signature.

39.2 Hash and look up on VirusTotal

Why: Hash lookup beats running unknown files.

What: Hash a clean file and search VirusTotal by hash only.

How:

1. sha256sum /bin/ls
2. Paste hash on virustotal.com (hash only).

Expected output: Known clean Linux binary results.

39.3 Phishing attachment rules

Why: Macros and double extensions trick users.

What: Mark each attachment Risky or OK.

Data file: attach.csv

About this file: Made-up attachments. Each row is one file name to judge.

How:

1. Read the data file.

Expected output: invoice.pdf.exe Risky; report.pdf OK; unexpected xlsm Risky.

40.1 Add nginx rate limiting

Why: Rate limits protect login and APIs.

What: Limit requests on your lab nginx only.

How:

1. Add limit_req_zone and limit_req to nginx.
2. Reload; then ab -n 100 -c 20 http://127.0.0.1/ on localhost.

Expected output: Some 503/429 responses under load.

40.2 Distinguish volumetric vs app DoS (paper)

Why: Different attacks need different defences.

What: Match each row.

Data file: dos.csv

About this file: Made-up matching. Each row is one attack type. Columns: Attack; Layer to fill.

How:

1. Read the data file.

Expected output: SYN flood Network; Slowloris Application; DNS amp Network.

40.3 Uptime check script

Why: Detect outages early.

What: Poll your lab site every minute.

How:

1. while true; do curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1/; sleep 60; done
2. Stop nginx; watch codes change to 000.

Expected output: 200 then 000 when down.

41.1 Check cookie flags in DevTools

Why: Missing flags let XSS steal sessions.

What: Log into a lab app and inspect the session cookie.

How:

1. DevTools → Application → Cookies.
2. Note Secure, HttpOnly, SameSite.

Expected output: Ideal: Secure + HttpOnly + SameSite=Lax/Strict.

41.2 Set safe cookies in Express

Why: Framework defaults are not always safe.

What: Create a Node cookie with flags.

How:

1. res.cookie('sid','x',{httpOnly:true,secure:false,sameSite:'lax'}) for HTTP lab.
2. curl -v and read Set-Cookie.

Expected output: HttpOnly and SameSite=Lax present.

41.3 CSRF defence sketch

Why: Stolen cookies still need CSRF tokens for state changes.

What: Add a synchronizer token to a lab form.

How:

1. Put a random token in the session and a hidden form field.
2. Reject POST if they differ.

Expected output: Forged POST without token fails.

42.1 Run Suricata on a pcap

Why: IDS finds known bad traffic.

What: Scan a sample pcap with Suricata in your lab.

How:

1. Install Suricata.
2. suricata -r dns.pcap -l /tmp/suricata
3. Read /tmp/suricata/fast.log or eve.json.

Expected output: Alerts or at least a clean run with stats.

42.2 Write a simple detection rule

Why: Custom rules catch your environment's threats.

What: Alert on HTTP URI containing .env.

How:

1. Add a Suricata/Snort-style rule for http.uri content .env.
2. Replay a curl to /.env through the sensor.

Expected output: Alert fires.

42.3 Honeypot vs real service (paper)

Why: Honeypots must look real but stay isolated.

What: Mark each setup Safe or Risky.

Data file: honey.csv

About this file: Made-up honeypot setups. Each row is one setup to judge.

How:

1. Read the data file.

Expected output: Isolated VM Safe; honeypot on prod VLAN Risky; internet cowrie with monitoring Safe if isolated.

43.1 Inventory home IoT

Why: You can't protect devices you forgot.

What: List every smart device on your home net.

How:

1. Check router DHCP client list.
2. Note name, IP, vendor.

Expected output: A table of ≥3 devices.

43.2 Put IoT on a guest/VLAN

Why: A hacked camera should not reach your laptop.

What: Move devices to guest Wi-Fi or IoT VLAN.

How:

1. Enable guest/IoT SSID.
2. Rejoin camera/bulb there.
3. From laptop on main LAN, try to browse camera IP.

Expected output: Camera works in app; laptop cannot reach admin page (or limited).

43.3 Default password hunt (paper)

Why: Factories still ship default passwords.

What: Mark each device habit Safe or Fix.

Data file: iot.csv

About this file: Made-up OT/IoT habits. Each row is one device. Columns: Device; Password habit.

How:

1. Read the data file.

Expected output: Default admin/admin Fix; unique password Safe; no internet exposure Safe.

44.1 Phone security check-up

Why: Phones hold email and bank apps.

What: Run through the linked check-up on your phone.

How:

1. Screen lock on.
2. OS updated.
3. App permissions reviewed.
4. Find My Device / Find My iPhone on.

Expected output: All four Yes.

44.2 Sideloading risk (paper)

Why: Apps outside official stores bypass review.

What: Mark each install path Safe or Risky.

Data file: mobile.csv

About this file: Made-up install paths. Each row is one path to judge.

How:

1. Read the data file.

Expected output: Play Store/App Store Safe; unknown APK Risky; USB debug on daily phone Risky.

44.3 Bluetooth hygiene

Why: Open Bluetooth is a quiet risk.

What: On your phone, review paired devices.

How:

1. Forget devices you don't use.
2. Turn Bluetooth off when not needed.
3. Avoid accepting pair requests from strangers.

Expected output: Unused devices removed.

45.1 Pick 5 CEH topics to revise

Why: Spaced practice beats cramming.

What: Open the revision tracker lab and mark 5 weak topics.

How:

1. Score yourself 1–5 per topic.
2. Schedule the lowest three this week.

Expected output: A short plan with dates.

45.2 Teach-back one concept

Why: Teaching proves you understand.

What: Explain ports vs protocols to a friend (or voice memo) in 3 minutes.

How:

1. Cover TCP/UDP, examples 22/80/443.
2. No jargon without meaning.

Expected output: Recording under 3 minutes.

45.3 Lab redo under time

Why: Speed comes from repetition.

What: Re-do harden-ubuntu lab with a 45-minute timer.

How:

1. Snapshot first.
2. Stop at 45 minutes; note unfinished steps.

Expected output: Checklist with Done/Not done.

46.1 Answer: CIA triad with examples

Why: Basics open interviews.

What: Write Confidentiality, Integrity, Availability examples for a hospital.

How:

1. One sentence each.
2. Indian hospital context welcome.

Expected output: Three clear examples.

46.2 Answer: How do you handle a phishing report?

Why: Process shows seniority.

What: Write 6 steps from report to close.

How:

1. Contain, preserve, analyse headers, block, reset if clicked, educate.
2. Include who you tell.

Expected output: Six steps on one page.

46.3 Answer: Difference between IDS and IPS

Why: Common compare question.

What: Write 4 bullet points.

How:

1. IDS alerts; IPS can block.
2. Placement differences.
3. False positive risk for IPS.

Expected output: Four bullets.

47.1 STAR story for an incident

Why: MNCs love STAR.

What: Write Situation, Task, Action, Result for a lab or real study incident.

How:

1. Keep Result measurable (e.g. reduced failed logins).
2. Max half a page.

Expected output: STAR with numbers.

47.2 Explain HTTPS to a manager

Why: Non-technical answers matter.

What: Write a 90-second script with no jargon, or define every term.

How:

1. Cover padlock, encryption, certificate, why login needs it.

Expected output: Manager-friendly script.

47.3 Live command: show listening ports

Why: They may hand you a terminal.

What: On your VM, demonstrate and narrate.

How:

1. ss -tulpn
2. Point to sshd and any web server.
3. Say which are expected.

Expected output: Narrated demo under 2 minutes.

48.1 Map course chapters to CEH modules

Why: See what you already covered.

What: Make a table: CEH module → our chapter numbers.

How:

1. Use ch48 map in the course.
2. Mark Strong / Weak.

Expected output: Table of modules with chapter refs.

48.2 Timed 10-question drill

Why: Exam pace matters.

What: Do 10 practice questions in 15 minutes.

How:

1. Use the tracker lab questions.
2. Score and note wrong topics.

Expected output: Score out of 10 + topic list.

48.3 Tool-to-phase match (paper)

Why: CEH asks which tool fits which phase.

What: Match the data file.

Data file: tools.csv

About this file: Made-up matching. Each row is one tool. Columns: Tool; Phase to fill.

How:

1. Read each row.

Expected output: nmap Recon; metasploit Exploitation; wireshark Analysis; john Password.

49.1 Personal 20-command sheet

Why: Your own sheet beats copying.

What: Write 20 commands you actually use, with one-line why.

How:

1. Include ss, find, grep, ufw, journalctl, curl, dig, chmod.
2. Test each once.

Expected output: 20 commands + why.

49.2 One-page incident commands

Why: Under stress you need a short list.

What: List commands for: who logged in, failed SSH, listening ports, recent files.

How:

1. last; journalctl/grep Failed; ss -tulpn; find /tmp -mtime -1.
2. Print and keep offline.

Expected output: One A4 page.

49.3 Windows equivalents

Why: Many jobs are mixed OS.

What: Match Linux → Windows.

How:

1. ss → netstat/Get-NetTCPConnection; grep → findstr/Select-String; chmod → icacls.

Expected output: A 5-row table.

50.1 10 flashcards from the glossary

Why: Bilingual terms help interviews in Maharashtra.

What: Make 10 cards: English / Marathi / one example.

How:

1. Use the course glossary.
2. Include IP, firewall, phishing, encryption, malware.

Expected output: 10 cards.

50.2 Explain phishing in Marathi

Why: Family awareness reduces home risk.

What: Write a 1-minute Marathi script (or record audio).

How:

1. Cover fake messages, don't click, call 1930 if money lost.

Expected output: 1-minute script/audio.

50.3 Fill glossary gaps

Why: Write terms you still mix up.

What: Add 5 new rows you struggled with this course.

How:

1. Term, simple English, Marathi if you know, chapter.
2. Share with a study buddy.

Expected output: 5 new rows.