Chapter 7 — Email and phishing alerts | Technical Security operations and blue team

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 7 — Email and phishing alerts

Lesson map

Lesson 07 published. Map, example, EX025.

flowchart TD
  N0["Learning outcomes"]
  N1["7.1 Why email"]
  N2["7.2 Gateway alerts"]
  N3["7.3 User reports"]
  N4["7.4 The finance case"]
  N5["7.5 Removal"]
  N6["7.6 Follow-up"]
  N7["7.7 Training link"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX025"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["7.1 Why email"]
  N2["7.2 Gateway alerts"]
  N3["7.3 User reports"]
  N4["7.4 The finance case"]
  N5["7.5 Removal"]
  N6["7.6 Follow-up"]
  N7["7.7 Training link"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX025"]

[Learning outcomes]
    |
    v
[7.1 Why email]
    |
    v
[7.2 Gateway alerts]
    |
    v
[7.3 User reports]
    |
    v
[7.4 The finance case]
    |
    v
[7.5 Removal]
    |
    v
[7.6 Follow-up]
    |
    v
[7.7 Training link]
    |
    v
[Worked example] --> [Exercise EX025]

Learning outcomes

You will (1) explain why email is a common entry point; (2) read email gateway alerts; (3) handle user-reported phishing; (4) coordinate message removal and user follow-up.

7.1 Why email

Phishing emails try to trick people into opening attachments, entering passwords on fake sites or approving payments. They are one of the most common starting points of incidents. At Northgate, the finance case followed this pattern: an 'Overdue invoice' email with a link to invoice-portal.example, sent to thirteen staff. One finance officer, at the PC 10.2.0.31, entered her password on the page. Phishing aims at people rather than systems, so the gateway, user reports and proxy logs each play a part in catching it. The rest of this chapter follows that case step by step.

7.2 Gateway alerts

The email gateway scans messages and flags suspicious senders, links and attachments. It blocks many but not all. The 'Overdue invoice' email got through because its domain was newly registered and had no bad reputation yet. Gateway alerts are still useful for catching known senders and attachments, but the SOC cannot assume that a delivered message was checked and judged safe. User reports through the button fill some of the gap the gateway leaves. Carlos records which gateway checks the message passed, so the email team can judge whether a rule change is needed.

7.3 User reports

Northgate staff have a "report phishing" button. Reports go to the SOC queue. Each report gets a reply, even if the message was harmless, so people keep reporting. The finance case started with exactly such a report from a finance officer. Without the button, the email would have stayed in thirteen mailboxes and nobody would have searched the proxy for clicks. Replying to every report, even harmless ones, keeps staff reporting, which is how the SOC learns about messages the gateway missed. The SOC answers each report within the working day so that staff see their effort noticed.

7.4 The finance case

On Carlos's third day, a finance officer reports an email titled "Overdue invoice" with a link to invoice-portal.example. The gateway had let it through. Twelve other staff received it. The thirteen recipients define the search: Carlos needs to know which of them clicked and whether anyone entered a password. The gateway console shows the sender, route and link target as text, so he can triage without visiting invoice-portal.example. The headers show a newly registered domain, not the real supplier.

7.5 Removal

With approval, the email team removes the message from all twelve mailboxes and blocks the sender and domain. Removing the message stops further clicks, but it does not undo clicks that already happened, which is why the proxy search follows. Blocking the domain also protects staff who might receive a forwarded copy. Approval is required because removing mail from mailboxes touches staff's accounts. The email team records how many copies were removed, so the count of thirteen recipients can be checked against the gateway's own figures.

7.6 Follow-up

Carlos checks proxy logs (chapter 8) for anyone who clicked, and asks those users whether they entered a password. The proxy search runs from the email's arrival until its removal, so visits outside that window are not wrongly linked to it. Asking users is still needed, because the proxy shows a visit but not whether a password was typed. The finance officer at 10.2.0.31 confirmed she had entered hers. Users are asked politely and without blame, since honest answers depend on staff not fearing trouble for clicking.

7.7 Training link

The council's awareness team uses the anonymised example in next month's staff bulletin. Using the case in training makes the example real for staff without naming the finance officer. The bulletin can show the 'Overdue invoice' subject and the look of the link, so staff recognise the next one. The example is anonymised, consistent with the no-blame approach in the rest of the response. The bulletin also reminds staff where the report button is and thanks those who used it in the finance case.

Checking the message safely

Carlos never opens suspicious links on his own PC. He views the message headers in the gateway console, where sender, route and link targets are shown as text. Headers revealed the message came from a newly registered domain, not the supplier it claimed to be from. These checks are enough for triage without visiting the site.

Worked example

Of the 13 recipients, one finance PC, 10.2.0.31, visited the link twice. The user admits entering her password. Carlos asks IT to reset it and checks her account's sign-ins: none from new locations since. The case is contained within an hour.

Synthetic case. Emails, users and addresses are synthetic.

Errors and limits

Users may not admit clicking; logs fill the gap but never fully.

Exercises

EX025 — Why reply. Why reply to every report? Rubric: 3 = keeps people reporting; 2 = partial; 1 = vague; 0 = none.
EX026 — Recipients. How many staff received the email? Rubric: 3 = 13 (reporter plus 12); 2 = partial; 1 = wrong; 0 = none.
EX027 — Removal steps. What two actions followed approval? Rubric: 3 = removed from mailboxes; blocked sender and domain; 2 = one; 1 = vague; 0 = none.
EX028 — Password entered. What was done for the user who entered her password? Rubric: 3 = reset; sign-ins checked; 2 = partial; 1 = vague; 0 = none.

Synthesis

Treat phishing reports quickly, remove and block, find clickers and reset credentials.

Continue studying — chapter 07 of 18

← Chapter 06 (draft) · Course chapter index · Chapter 08 (draft) →