A talk-through drill

What this is

This is a talk-through drill, known in the security field as a tabletop exercise (TTX): a story you talk through, not a test. Nobody touches a real system. You read a situation, decide what you would do, and see what happens next. It is the way real teams rehearse an incident before they ever have one.

This one draws on everything in the course. The names and the company are invented. Any resemblance to a real business is coincidence.

The setup

Adria Verde sh.p.k. is a mid-size food distributor. It has forty staff, a warehouse, and one shared drive that holds invoices, supplier contracts, and the payroll. You are part of a small group that would handle a problem: Besa in finance, Ardit who looks after the computers, and Blerta the manager. There is no dedicated security team. That is normal, and it is the point.

Keep one question in mind at every step: what is the calm, simple thing to do here?

Inject 1, Monday morning

Besa opens an email that looks like it is from a regular supplier, NovaByte. It says an invoice is attached and payment is overdue. She clicks the link, which opens a familiar looking sign-in page, and she enters her email password to "view the document". The page then shows a plain PDF with nothing unusual in it.

Besa thinks no more about it.

Discuss:

• What just happened, in the language of the course? Which weakness was used?
• Besa did not notice anything wrong. Was there a moment where the outcome could have changed?
• Does anyone need to know about this yet? Who, and why?

Inject 2, Tuesday before dawn

Ardit gets an alert at 3am: Besa's account has asked to approve a login four times in ten minutes. Besa is asleep and did nothing. The requests are coming from somewhere far away.

Discuss:

• Connect this to Monday. What does it tell you about that "sign-in page"?
• If you were Besa and your phone buzzed with an approval you did not start, what should you do, and what should you never do?
• Multi-factor authentication (MFA) is doing something useful here even though the password is already stolen. What, exactly?

Inject 3, Wednesday

An email arrives, again looking like NovaByte. It is polite and well written. It explains that NovaByte has changed banks, sends a business email compromise (BEC) style request: please update our bank details, and asks that this month's payment of a large sum go to the new account. The invoice number matches a real order, because NovaByte itself was quietly breached weeks earlier and the attacker has been reading its genuine invoices and emails ever since.

Blerta is ready to approve it to keep the supplier happy.

Discuss:

• What is the one step that turns this from a high risk into a low one?
• Whom do you contact, and how, to confirm the change? What must you not do?
• Why is the correct number the one you already had on file, not the one in the email?

Inject 4, Thursday

Staff arrive to find the shared drive will not open. A short note sits in every folder: the files are encrypted, and there is a demand for payment to unlock them. This is ransomware. The way in was mundane: on Wednesday a second employee, not Besa, opened an "invoice" attachment from the same NovaByte thread, and the malware it planted spread to the shared drive overnight. Work stops. The last backup, Ardit thinks, was made "a while ago".

Discuss:

• List the costs Adria Verde is now facing. Which of them is the ransom, and which are bigger?
• The single most useful thing right now is a backup. What two properties must it have to actually save you?
• Does paying make the problem go away? What does the course say about relying on that?

Inject 5, Friday

A local journalist calls Blerta. They have heard a rumour that Adria Verde was "hacked" and ask for a comment. Meanwhile the team is deciding whether to report the incident to the National Authority for Cyber Security (AKSK, aksk.gov.al) and how to tell staff and suppliers what happened.

Discuss:

• What is gained by reporting early and being honest, and what is lost by staying silent?
• Trust was one of the four costs. How do the decisions today affect it, in either direction?
• Who at Adria Verde should have been told, and when, going all the way back to Monday?

Model answers

1. Phishing: a fake sign-in page harvested Besa's password. The weakness used was a person trusting a familiar-looking email and page, not a software flaw.
2. Yes: before typing her password, checking the sender's address and the page's real address, or opening the supplier's portal from a saved bookmark instead of the link.
3. Yes. Ardit should hear about it now, because a password typed into an unknown page must be treated as stolen and changed, even though nothing looks wrong yet.
4. The "sign-in page" was fake: it captured Besa's password, and someone far away is now using it to try to log in.
5. Deny the request, change the password straight away, and tell Ardit. Never tap approve for a login you did not start, not even "to make it stop".
6. MFA is the reason the stolen password is not enough on its own: the attacker still needs Besa's second factor, so the takeover stalls at the approval prompt.
7. Verify the change through a channel the email did not give you before paying anything.
8. Call NovaByte on the number already on file (or a known contact there), by phone, not by replying to the email or using any number it contains.
9. The attacker controls the email thread, so anything inside it, including a phone number, may be theirs. The number on file was obtained independently, before the compromise.
10. Downtime and lost sales, recovery and IT costs, possible fines or legal duties, and lost trust of suppliers and customers. The ransom is only one line, and usually not the biggest.
11. Recent and tested: made recently enough to lose little work, and restored at least once so you know it actually works, kept where the ransomware could not reach it.
12. No. Paying funds criminals, offers no guarantee of getting files back, and does not fix the way in; the course says to rely on backups, not payment.
13. Reporting early brings help, limits damage to others such as suppliers, and may be a legal duty; silence risks the story leaking anyway, with trust lost on top.
14. Honest, early communication protects trust; being caught hiding a breach, or letting suppliers be defrauded in silence, destroys it.
15. Ardit on Monday, as soon as Besa entered her password on a strange page; Blerta and finance by Tuesday; and the whole staff on Wednesday, so nobody else opened the "invoice".

Debrief

Walk back through the week. Almost every turn maps onto something in this course:

• Monday was phishing and a stolen password.
• Tuesday was an account takeover that MFA and a quick report could stop.
• Wednesday was payment fraud, beaten by verifying through a separate, trusted channel.
• Thursday was ransomware, where a recent, tested backup is the real defence.
• Friday was reporting and trust, where early honesty costs less than silence.

Notice how often the fix was small and calm: check the sender, do not rush, confirm on a number you already have, keep a backup you have tested, tell someone early. None of it needed a security team. All of it needed a habit.

Now rate your confidence that you would handle a real incident well from 1 to 5 again. If a number went up, that is the course working. If one is still low, you have found exactly where to look next.