Phishing Analysis & GRC Write-up

01

Scenario & Scope

This write-up analyses a fictional but technically realistic phishing scenario constructed for portfolio purposes using open-source intelligence methods and publicly documented attack patterns. All domain names, IP addresses, and organisational details are fabricated. The analysis methodology and GRC framework mappings reflect real-world practice.

Scenario: A member of the finance department at Nexara Solutions (fictional) received an email appearing to originate from the internal IT helpdesk, requesting urgent re-authentication due to a "suspicious login attempt." The link directed to a credential-harvesting page mimicking the organisation's Microsoft 365 login portal.

Why this matters for GRC Phishing is the most common initial access vector in data breaches (DBIR 2024). A GRC analyst's role is not only to triage the technical incident but to identify which governance controls failed or were absent — and to produce actionable, policy-level recommendations that reduce recurrence risk.

02

Email Artefact — Annotated

The intercepted message was examined in full including raw headers. Key fields are annotated below. Suspicious elements are flagged inline.

From: it-helpdesk@nexara-support.com ≠ nexara.com — spoofed domain

Reply-To: noreply@nexara-support.com same spoofed domain

To: m.dupont@nexara.com

Subject: [URGENT] Suspicious sign-in detected — verify identity within 2 hours manufactured urgency

Date: Mon, 10 Mar 2026 07:52:14 +0000

SPF: NEUTRAL — no SPF record on nexara-support.com no domain authentication

DMARC: MISSING not enforced

X-Mailer: PHPMailer 6.7.1 atypical for corporate IT

Dear Marie,

Our security systems have detected a suspicious sign-in attempt to your Nexara account from an unrecognised device (IP: 185.220.101.47, Romania).

To prevent your account from being locked, you must verify your identity within 2 hours. Failure to do so will result in temporary suspension of your Microsoft 365 access.

→ Click here to verify: https://nexara-m365-verify.pages.dev/login

IT Security Team
Nexara Solutions

03

Technical Header Analysis

Email headers were parsed programmatically using Python to extract authentication results, routing hops, and domain registration data. The following script reproduces the key extraction steps.

Python — header parsing & domain lookup (extract)

# Parse raw email headers and extract authentication signals
import email
import whois
import dns.resolver
from datetime import datetime

with open('sample_phish.eml', 'r') as f:
    msg = email.message_from_file(f)

sender_domain = 'nexara-support.com'
legit_domain  = 'nexara.com'

# --- SPF check ---
try:
    spf_record = dns.resolver.resolve(sender_domain, 'TXT')
    spf_found  = any('v=spf1' in str(r) for r in spf_record)
except:
    spf_found = False

# --- DMARC check ---
try:
    dmarc = dns.resolver.resolve(f'_dmarc.{sender_domain}', 'TXT')
    dmarc_found = True
except:
    dmarc_found = False

# --- WHOIS domain age ---
w = whois.whois(sender_domain)
creation_date = w.creation_date[0] if isinstance(w.creation_date, list) \
                else w.creation_date
domain_age_days = (datetime.now() - creation_date).days

# --- Output ---
print(f"SPF present    : {spf_found}")     # → False
print(f"DMARC present  : {dmarc_found}")   # → False
print(f"Domain age     : {domain_age_days} days")  # → 8 days

## FLAG: Newly registered domain (8 days). No SPF. No DMARC.
## Consistent with purpose-built phishing infrastructure.

Indicator of Compromise	Value	Severity	Notes
Lookalike sender domain	nexara-support.com	HIGH	Registered 8 days prior. No affiliation to nexara.com.
Absent SPF / DMARC	NEUTRAL / MISSING	HIGH	Sender domain carries no email authentication policy.
Credential-harvest URL	nexara-m365-verify.pages.dev	HIGH	Cloudflare Pages hosting. Mimics M365 login UI. Domain ≠ Microsoft.
Urgency & deadline framing	"within 2 hours"	MEDIUM	Social engineering vector. Designed to suppress critical evaluation.
Non-corporate mailer	PHPMailer 6.7.1	LOW	Inconsistent with enterprise mail infrastructure. Corroborating signal only.

04

Risk Assessment

Risk is assessed using a standard likelihood × impact matrix. The finance department is a high-value target: successful credential theft could enable fraudulent payment authorisation, access to ERP systems, or internal Business Email Compromise (BEC) escalation.

LIKELIHOOD → / IMPACT ↓

LOW / LOW

MED / LOW

HIGH / LOW

LOW / MED

MED / MED

HIGH / MED

LOW / HIGH

MED / HIGH

★ HIGH / HIGH

Low likelihood Medium likelihood High likelihood

Risk Rating HIGH. Likelihood is rated HIGH: phishing targeting finance departments is prolific, this email bypassed gateway filters, and no DMARC policy was in place to reject it automatically. Impact is rated HIGH: successful credential harvest against a finance user carries direct financial fraud risk and potential GDPR data breach notification obligations under Article 33 (72-hour notification window).

05

GRC Framework Mapping

Each identified control gap is mapped to the relevant clause or control in ISO 27001:2022, NIST Cybersecurity Framework (CSF 2.0), and GDPR where applicable. This mapping is the core deliverable from a governance perspective — it connects a technical observation to a policy obligation.

Gap 01 No DMARC / SPF enforcement

ISO 27001:2022 — Control 8.23 (Web filtering) & 8.28 (Secure coding — email auth).
NIST CSF 2.0 — PR.PS-01 (Protective technology — email security configuration).
Finding: Organisation has no published SPF record on primary domain and no DMARC policy, permitting trivial domain spoofing. Remediation: publish SPF, deploy DMARC at p=quarantine moving to p=reject after monitoring period.

Gap 02 No phishing simulation programme

ISO 27001:2022 — Control 6.3 (Information security awareness, education and training).
NIST CSF 2.0 — PR.AT-01 (Awareness and training — all personnel).
Finding: No documented phishing simulation or awareness training programme exists. Users have no baseline resistance to social engineering. Remediation: implement quarterly simulation programme with role-specific training for finance, HR, and executive staff.

Gap 03 Incomplete breach response procedure

ISO 27001:2022 — Control 5.26 (Response to information security incidents).
NIST CSF 2.0 — RS.MA-01 (Incident management — response execution).
GDPR Art. 33 — 72-hour supervisory authority notification obligation.
Finding: Existing incident response procedure does not address credential-harvest phishing specifically, nor does it define the threshold at which a phishing incident constitutes a personal data breach under GDPR Art. 4(12). Remediation: expand IR procedure with phishing-specific playbook and GDPR breach assessment checklist.

06

Recommendations

Recommendations are prioritised by risk reduction impact and implementation effort. Each is assigned a timeframe and framework reference. This section is written for a mixed audience: IT teams require the technical detail; business and legal stakeholders require the risk and regulatory framing.

R1
Enforce DMARC at p=reject on primary domain Publish an SPF record and deploy DMARC with an initial p=quarantine policy. Monitor aggregate reports for 30 days, then escalate to p=reject. This single control eliminates the primary technical enabler of this attack class at no material cost.
Priority: Immediate Risk reduction: High Effort: Low
R2
Implement mandatory phishing simulation programme Deploy a quarterly simulated phishing programme using a platform such as GoPhish (open-source) or KnowBe4. Finance, HR, and executive users should receive targeted campaigns reflecting BEC and credential-harvest patterns. Failure to pass simulation should trigger mandatory remedial training, not disciplinary action — the goal is behaviour change, not blame.
Priority: 30 days Risk reduction: High Effort: Medium
R3
Extend IR procedure with phishing-specific playbook Add a phishing response runbook to the existing IR procedure covering: (1) containment steps upon confirmed credential harvest, (2) GDPR breach determination checklist, and (3) 72-hour notification decision tree per Art. 33. The runbook must be actionable by a non-technical team member during the critical first hour of response.
Priority: 30 days Risk reduction: High Effort: Medium
R4
Enable MFA with phishing-resistant factors on M365 Current MFA configuration permits SMS and authenticator app codes — both susceptible to real-time relay attacks. Migrate finance and executive accounts to phishing-resistant factors (FIDO2 hardware keys or Microsoft Authenticator number matching) as a priority. This renders harvested credentials non-functional even if users are deceived.
Priority: 60 days Risk reduction: High Effort: Medium
R5
Establish a lookalike domain monitoring process Register a certificate transparency log alert (e.g. via crt.sh or a commercial service) for domains containing the organisation's brand name. nexara-support.com was registered eight days before this attack. Early detection enables proactive takedown requests and user warning communications before a campaign is launched.
Priority: 90 days Risk reduction: Medium Effort: Low

07

Lessons Learned & GRC Reflection

The technical indicators in this email were not sophisticated. The lookalike domain, absent email authentication, and PHPMailer fingerprint would be caught by any email security gateway configured to check them — and by any user trained to verify sender domains before clicking. The attack succeeded (in the simulation) not because it was technically advanced, but because the governance layer failed: no DMARC policy, no simulation training, and no clear playbook for response.

This is the core GRC observation: most preventable incidents are not prevented by better technology alone, but by better governance of the technology that already exists. The organisation already had an email gateway. It already had MFA. The controls existed — they were simply not configured, enforced, or supported by adequate policy and training.

A GRC practitioner's value in this scenario is not to diagnose the email headers — that is a SOC function. It is to identify that three policy gaps existed before the attack landed, connect them to the specific regulatory obligations they create, and produce actionable guidance that closes them before the next attempt.

That is what this write-up demonstrates.

Phishing Campaign Analysis& GRC Control Gap Assessment

Scenario & Scope

Email Artefact — Annotated

Technical Header Analysis

Risk Assessment

GRC Framework Mapping

Recommendations

Lessons Learned & GRC Reflection

Phishing Campaign Analysis
& GRC Control Gap Assessment