CapstoneLesson 2 of 3

Turning Point Training Institute

Capstone B: A Beginner Digital Forensics Case

12 min readBeginner

Where you are: Capstone · 7.2 · About 45 minutes. This capstone applies Unit VI — Chapter 21 of Dr. Al-Doori's Cyber Security Essentials and Lessons 6.1 to 6.5 — with help from the email, phishing and authentication lessons in Units II to IV.

This case is entirely fictional. Every person, organisation, domain, address and message below was invented for this exercise. Domains use reserved example names, and IP addresses come from ranges reserved for documentation, so none of them belongs to anyone real. Only inspect, test or change devices, accounts and systems you own or are explicitly authorized to work with. Do not look up, contact or investigate anything from this packet outside the lesson.

What you'll be able to do

You will work through a beginner digital forensics case from start to finish.

Build a timeline from several kinds of evidence, each with its source.
List each piece of evidence and say how it should be preserved.
State clearly what the evidence cannot prove.
Write a one-page findings report that a non-expert could act on.

The case

The Riverside Community Choir is a small volunteer choir. Its treasurer, Lina Moreau, manages the choir's bank account and uses the email address treasurer@riversidechoir.example, hosted by the choir's email provider (mail.example.net). The choir chair is Peter Okafor. Members pay a spring fee each year.

On Tuesday 3 March 2026, members received an email from the treasurer's address announcing new bank details. One member, Omar Reyes, paid his fee to the new account. By early afternoon, the committee realised something was badly wrong. The committee — which owns the choir's accounts and has authorised this review — has asked you to make sense of the evidence below.

All times are in UTC unless stated otherwise.

The incident packet

Item 1: The phishing email received by Lina

code

From: "Riverside Choir Accounts" <accounts@riversidechoir-pay.example>
To: treasurer@riversidechoir.example
Subject: Action needed: choir payment account suspended

Dear Treasurer,

We were unable to verify the choir's payment account. To avoid
suspension within 2 hours, sign in and confirm your details:

    riversidechoir-pay.example/secure-login

Riverside Choir Accounts Team

Item 2: The simplified header of that email

code

Received: from mx.example.com (mx.example.com [198.51.100.14])
        by mail.example.net; Tue, 3 Mar 2026 08:55:12 +0000
Received: from [203.0.113.80] (unknown [203.0.113.80])
        by mx.example.com; Tue, 3 Mar 2026 08:55:09 +0000
Authentication-Results: mail.example.net; spf=pass; dkim=pass; dmarc=pass
        (domain checked: riversidechoir-pay.example)
From: "Riverside Choir Accounts" <accounts@riversidechoir-pay.example>
Reply-To: accounts@riversidechoir-pay.example
To: treasurer@riversidechoir.example
Date: Tue, 3 Mar 2026 08:55:01 +0000
Subject: Action needed: choir payment account suspended

Item 3: Security alerts sent to Lina's phone by her email provider's app

code

03 Mar 2026 09:20 UTC  New sign-in to treasurer@riversidechoir.example
                       Device: unrecognised Windows computer
                       IP address: 192.0.2.77 · Location: unavailable
03 Mar 2026 09:22 UTC  The password for this account was changed
03 Mar 2026 09:24 UTC  A new forwarding rule was created:
                       messages containing "payment" -> collect@example.com

Item 4: Domain registration lookup (RDAP) for the look-alike domain

Lookup performed by the committee on 3 March 2026 at 13:30.

code

Domain name:   riversidechoir-pay.example
Registrar:     Example Registrar Ltd
Created:       2026-03-01T10:02:00Z
Registrant:    REDACTED FOR PRIVACY
Name servers:  ns1.example.com, ns2.example.com
Status:        active

Item 5: Metadata excerpt from the image attached to the members' email

code

File name:      new_bank_details.jpg
File signature: JPEG (matches the extension)
Device model:   Example Phone 12
Date taken:     2026:03:02 18:41:10 (no time zone recorded)
Software:       Example Photo Editor 4.2
GPS position:   present

Course note: the GPS coordinates have been replaced by a description for this exercise. They point to the entrance of a public library in Northport, a fictional town about 200 km from Riverside.

Item 6: Message timeline (emails and chat messages, as collected by Peter)

code

09:03  Lina -> Peter (chat): Got an odd email from "choir accounts" saying our
       payment account is suspended. I signed in through the link but the page
       just went blank?
09:31  Email from treasurer@riversidechoir.example to all 40 members:
       "Dear members, our bank has changed. Please pay the spring fee to the
       new account shown in the attached image by Friday. Lina"
       Attachment: new_bank_details.jpg
11:15  Omar -> Lina (chat): Done, paid my spring fee to the new account this
       morning.
12:38  Peter -> Lina (chat): Did you send the new bank details email? The
       committee never discussed a change.
12:41  Lina -> Peter (chat): No! And I can't sign in to the treasurer email
       any more.
12:50  Peter -> choir group chat: Do NOT pay anything to the "new account".
       That email did not come from us.

Your tasks

Work through the four tasks in order. Write your answers in your own notes before you read the model solution.

Task 1 — Build the timeline. Put every event from the packet in time order. For each entry, give the time, what happened and which item it comes from. Mark any time that is uncertain.

Task 2 — List the evidence and how to preserve it. For each item, say where it is held, what it shows and how it should be preserved. Think at two levels: what the choir can keep itself (Lesson 6.1), and what would need trained, authorised investigators (Lesson 6.4).

Task 3 — State what cannot be concluded. List at least four things the evidence does not prove, and explain why.

Task 4 — Write a one-page findings report for the choir committee, using these headings: Summary · Timeline · Evidence held · Findings · Limits · Recommended actions.

Model solution

Compare your work with the model below. Your wording will differ; what matters is the reasoning.

Task 1 — Timeline

Time (UTC)	Event	Source
1 Mar, 10:02	Look-alike domain riversidechoir-pay.example is registered	Item 4
2 Mar, 18:41 (time zone unknown)	The bank-details image is created or edited on an "Example Phone 12" with a photo editor	Item 5
3 Mar, 08:55	Phishing email reaches Lina, sent from 203.0.113.80 via mx.example.com	Items 1, 2
3 Mar, 09:03	Lina tells Peter she signed in through the email's link and the page went blank	Item 6
3 Mar, 09:20	Sign-in to the treasurer account from an unrecognised Windows computer at 192.0.2.77	Item 3
3 Mar, 09:22	Treasurer account password changed	Item 3
3 Mar, 09:24	Forwarding rule created: "payment" messages to collect@example.com	Item 3
3 Mar, 09:31	Fake "new bank details" email sent from the treasurer account to 40 members	Item 6
3 Mar, 11:15	Omar reports paying his fee to the new account	Item 6
3 Mar, 12:38–12:41	Peter queries the email; Lina confirms she did not send it and is locked out	Item 6
3 Mar, 12:50	Peter warns all members not to pay	Item 6
3 Mar, 13:30	Committee runs the registration lookup	Item 4

The image time is uncertain because no time zone was recorded and metadata can be edited.

Task 2 — Evidence and preservation

Evidence	Where it is held	What it shows	How to preserve it
Phishing email and full header (Items 1, 2)	Lina's mailbox, once recovered	The lure, the look-alike domain, the sending path and passing authentication for the attacker's own domain	Keep the original message (move it to a folder; never delete it). Save the full header ("show original") as a file. Do not click the link again
Security alerts (Item 3)	Lina's phone, in the provider's app	Times and IP of the takeover, password change and forwarding rule	Dated screenshots now; keep the alerts on the phone. The provider's own sign-in logs can be requested by authorised investigators
Forwarding rule	Treasurer account settings	Where the attacker wanted payment messages sent	After recovering the account through the provider's official process, screenshot the rule with its date, record it in the log, then delete it
Registration lookup (Item 4)	Public registration data	The domain was created two days before the attack	Save the full lookup output with the date and time it was run, because records can change
Image and metadata (Item 5)	Members' inboxes	The fake bank details, device model, edit software, date and a location	Save the original attachment file exactly as received — not a screenshot, not re-sent through apps that may strip metadata. An investigator would record a SHA-256 hash of the saved file and keep a chain of custody
Messages (Item 6)	Phones of Lina, Peter and Omar; members' inboxes	What people knew and did, and when	Export the chats or take dated screenshots; keep the members' copies of the fake email
Omar's payment record	Omar's bank	Amount, time and receiving account	Omar keeps the receipt and contacts his bank at once
Lina's computer	Lina's home	Possibly nothing — or signs of malware	Lina scans and updates it. A forensic image is only needed if malware is suspected, and only by an authorised investigator using a write blocker

Task 3 — What cannot be concluded

Who the attacker is. The registrant is redacted, and registration details can be false anyway.
Where the attacker is. 203.0.113.80 and 192.0.2.77 are connections at a moment in time, often shared, not people. They could be VPNs, shared networks or provider-level shared addresses.
That the sender and the person who signed in are the same. Two different IP addresses appear, and the evidence does not link them to one person.
That someone at the Northport library made the image. A library is a public place, metadata can be edited or invented, and the photo editor entry shows the image was processed. No time zone was recorded either.
That Lina's computer is infected. The evidence fits a credential-phishing page: she typed her password into the fake site. A device check is still sensible, but infection is not shown.
What the forwarding rule captured, and whether other accounts were affected. That needs the provider's records and checks of any accounts that shared the password.
That Omar's money can be recovered. Only his bank can say.

Task 4 — Model findings report

Findings report: compromise of the choir treasurer email account, 3 March 2026

Summary. On 3 March 2026, the treasurer's email account was taken over after a phishing email led the treasurer to enter her password on a look-alike website. The attacker changed the password, created a forwarding rule and sent all 40 members fake bank details. At least one member paid. The account must be recovered and secured, the payment reported to the bank, and members warned.

Timeline. A look-alike domain was registered on 1 March. A phishing email reached the treasurer at 08:55 on 3 March, and she signed in through its link shortly after 09:00. An unrecognised device signed in at 09:20, changed the password at 09:22 and created a forwarding rule at 09:24. The fake bank-details email went to members at 09:31. A member paid at 11:15. The fraud was spotted at 12:38 and members were warned at 12:50.

Evidence held. The phishing email and its header; three provider alerts; the forwarding rule (to be captured after recovery); the registration lookup output with its date; the original bank-details image; chat exports; the member's payment record.

Findings. The attack used a look-alike domain, registered two days earlier, that passed SPF, DKIM and DMARC because the attacker controlled it — so passing checks did not mean the email was genuine. The takeover began within about 20 minutes of the treasurer entering her password on the fake page. The forwarding rule suggests the attacker intended to intercept payment-related email.

Limits. The evidence does not identify the attacker or their location. IP addresses identify connections, not people. The image's location and date may be edited and point to a public place. Infection of the treasurer's computer is not shown.

Recommended actions.

Recover the treasurer account through the provider's official process; set a new unique password; sign out all sessions; capture and remove the forwarding rule; check recovery details; turn on a passkey or authenticator-app MFA.
The member who paid contacts his bank immediately with the payment details.
Report the fraud to the choir's bank, to the email provider and through the official national reporting service, with this report and the preserved evidence.
Warn all members, through a channel other than the treasurer email, that the choir's bank details have not changed.
Change the treasurer's password anywhere it was reused, and scan and update her computer.
Agree a rule for the future: any change of bank details is confirmed by phone with two committee members before it is announced.

Key Takeaways

A good timeline puts every event in order with its source, and flags times that are uncertain.
Preserve originals: the full email header, the original image file, dated screenshots and lookup outputs with the time they were run.
Passing SPF, DKIM and DMARC shows a message really came from its domain — not that the domain is honest.
IP addresses, registration data and photo metadata are leads, not identities; a strong report says clearly what the evidence cannot prove.
Only inspect, test or change devices, accounts and systems you own or are explicitly authorized to work with.

Sources

PreviousCapstone A: Your Personal Cybersecurity Audit NextFinal Assessment: 20 Questions