# Phishing and email investigation

Review displayed sender, authentication headers, destination domains and user impact together. Develop evidence without opening suspicious destinations.

Original AI-assisted SecNet educational content. Fictional local examples; not a standards provider publication, endorsement or compliance evidence. Page exercises do not create account progress.

Sources checked: 2026-10-21

## Display name and trusted receiver

The displayed helpdesk name is not the actual sender domain. Authentication-Results is meaningful only from a receiver within the relevant trust boundary; an attacker-supplied lookalike header is not proof. Passing SPF/DKIM/DMARC cannot guarantee legitimate content or a business request. Record gaps in raw headers, receiving infrastructure and forwarding context. Harbor’s text export does not parse MIME or validate actual headers.

## Domain and link chain

HTTPS describes transport, not trustworthiness. Review exact host spelling, Unicode/punycode rendering, subdomain boundaries and redirects in an authorized environment. This exercise opens no destinations and uses reserved example domains. Verify payment or credential requests through a pre-established independent channel, not contacts in the message. Running attachments or links on an analyst’s everyday machine is not an investigation step.

## User impact and other recipients

Deleting a message cannot undo a click, session or submitted information. Correlate recipients, click records, user statements and identity events within explicit windows. Scope mailbox/export authority and avoid unnecessary copies of content or personal data. MITRE T1566 supports behavioral classification; a matching record does not establish actor or campaign attribution.

## Harbor-17 email decision

mail-export provides only normalized recipient/time details, without trusted receiver headers. A familiar name cannot establish safety; missing headers alone cannot prove malice. Request raw records, domain review and user/session attribution. The desk shows a sign-in two minutes after a click: a working correlation, not a verdict. Do not close the case by deleting the message before reviewing recipient scope and identity impact.

## Working sequence

1. Preserve raw mail and receiver provenance.
2. Review trust boundary and domains.
3. Independently verify the business request.
4. Correlate click, sign-in and recipient impact.
5. Report bounded findings and evidence gaps.

## 1. The header saying pass

authPass needs trusted-receiver and alignment review. Fraudulent content remains possible after authentication passes; independently verify content and business request.

This code is a local policy model; it does not replace target/cluster testing.

### Weak implementation
```js
s=>s.authPass
```

### Corrected implementation
```js
s=>s.authPass&&s.trustedReceiver&&s.alignmentReviewed&&s.contentCorroborated
```

### Synthetic input and actual model output
```json
{
  "before": [
    {
      "name": "supported-case",
      "input": {
        "authPass": true,
        "trustedReceiver": true,
        "alignmentReviewed": true,
        "contentCorroborated": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "forged-header",
      "input": {
        "authPass": true,
        "trustedReceiver": false,
        "alignmentReviewed": true,
        "contentCorroborated": true
      },
      "expected": false,
      "observed": true,
      "matched": false
    },
    {
      "name": "pass-but-fraud",
      "input": {
        "authPass": true,
        "trustedReceiver": true,
        "alignmentReviewed": true,
        "contentCorroborated": false
      },
      "expected": false,
      "observed": true,
      "matched": false
    }
  ],
  "after": [
    {
      "name": "supported-case",
      "input": {
        "authPass": true,
        "trustedReceiver": true,
        "alignmentReviewed": true,
        "contentCorroborated": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "forged-header",
      "input": {
        "authPass": true,
        "trustedReceiver": false,
        "alignmentReviewed": true,
        "contentCorroborated": true
      },
      "expected": false,
      "observed": false,
      "matched": true
    },
    {
      "name": "pass-but-fraud",
      "input": {
        "authPass": true,
        "trustedReceiver": true,
        "alignmentReviewed": true,
        "contentCorroborated": false
      },
      "expected": false,
      "observed": false,
      "matched": true
    }
  ]
}
```

## 2. The padlock icon

HTTPS cannot make a lookalike domain trustworthy. Exact domain, redirects and independent business confirmation are separate evidence; the model contacts no URL.

This code is a local policy model; it does not replace target/cluster testing.

### Weak implementation
```js
s=>s.https
```

### Corrected implementation
```js
s=>s.https&&s.exactDomainReviewed&&s.redirectsReviewed&&s.businessRequestVerified
```

### Synthetic input and actual model output
```json
{
  "before": [
    {
      "name": "supported-case",
      "input": {
        "https": true,
        "exactDomainReviewed": true,
        "redirectsReviewed": true,
        "businessRequestVerified": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "lookalike",
      "input": {
        "https": true,
        "exactDomainReviewed": false,
        "redirectsReviewed": true,
        "businessRequestVerified": false
      },
      "expected": false,
      "observed": true,
      "matched": false
    },
    {
      "name": "unreviewed-redirect",
      "input": {
        "https": true,
        "exactDomainReviewed": true,
        "redirectsReviewed": false,
        "businessRequestVerified": true
      },
      "expected": false,
      "observed": true,
      "matched": false
    }
  ],
  "after": [
    {
      "name": "supported-case",
      "input": {
        "https": true,
        "exactDomainReviewed": true,
        "redirectsReviewed": true,
        "businessRequestVerified": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "lookalike",
      "input": {
        "https": true,
        "exactDomainReviewed": false,
        "redirectsReviewed": true,
        "businessRequestVerified": false
      },
      "expected": false,
      "observed": false,
      "matched": true
    },
    {
      "name": "unreviewed-redirect",
      "input": {
        "https": true,
        "exactDomainReviewed": true,
        "redirectsReviewed": false,
        "businessRequestVerified": true
      },
      "expected": false,
      "observed": false,
      "matched": true
    }
  ]
}
```

## 3. Deleted: is it over?

Deletion is only one mailbox action. Review clicks, sign-ins and other recipients before claiming user impact has been resolved.

This code is a local policy model; it does not replace target/cluster testing.

### Weak implementation
```js
s=>s.messageDeleted
```

### Corrected implementation
```js
s=>s.messageDeleted&&s.clicksReviewed&&s.signinsReviewed&&s.otherRecipientsReviewed
```

### Synthetic input and actual model output
```json
{
  "before": [
    {
      "name": "supported-case",
      "input": {
        "messageDeleted": true,
        "clicksReviewed": true,
        "signinsReviewed": true,
        "otherRecipientsReviewed": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "delete-only",
      "input": {
        "messageDeleted": true,
        "clicksReviewed": false,
        "signinsReviewed": false,
        "otherRecipientsReviewed": false
      },
      "expected": false,
      "observed": true,
      "matched": false
    },
    {
      "name": "other-recipients-unknown",
      "input": {
        "messageDeleted": true,
        "clicksReviewed": true,
        "signinsReviewed": true,
        "otherRecipientsReviewed": false
      },
      "expected": false,
      "observed": true,
      "matched": false
    }
  ],
  "after": [
    {
      "name": "supported-case",
      "input": {
        "messageDeleted": true,
        "clicksReviewed": true,
        "signinsReviewed": true,
        "otherRecipientsReviewed": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "delete-only",
      "input": {
        "messageDeleted": true,
        "clicksReviewed": false,
        "signinsReviewed": false,
        "otherRecipientsReviewed": false
      },
      "expected": false,
      "observed": false,
      "matched": true
    },
    {
      "name": "other-recipients-unknown",
      "input": {
        "messageDeleted": true,
        "clicksReviewed": true,
        "signinsReviewed": true,
        "otherRecipientsReviewed": false
      },
      "expected": false,
      "observed": false,
      "matched": true
    }
  ]
}
```

## Exit evidence

- Trusted-receiver and raw-record reference
- Recipient/click/session scope matrix

## References

- [RFC 8601 · Authentication-Results trust boundary](https://www.rfc-editor.org/rfc/rfc8601)
- [MITRE ATT&CK · Phishing T1566](https://attack.mitre.org/techniques/T1566/)