claudetools/clients/dataforth/reports/2026-05-03-jantar-account-check.md

Dataforth — Account & Mailbox Check: jantar@dataforth.com

Date: 2026-05-03 (UTC) Tenant: Dataforth Corporation (dataforth.com, 7dfa3ce8-c496-4b51-ab8d-bd3dcd78b584) Subject: Jacque Antar (UPN jantar@dataforth.com, object id daa60027-be31-47a5-87af-d728499a9cc4) Trigger: Email surfaced on a paid dark-web ID monitoring report. Tool: ComputerGuru Security Investigator (Graph read-only) — App ID bfbc12a4-f0dd-4e12-b06d-997e7271e10c Operator: Howard Enos Scope: Read-only. No remediation taken.

Summary

• MFA is ENABLED and IS being enforced. Per-user MFA state = enforced. Last 30 days of sign-ins all show MFA requirement satisfied by claim in the token. Non-interactive sign-ins (Outlook, Teams, etc.) all report authenticationRequirement: multiFactorAuthentication.
• MFA method registered: SMS only to +1 520-245-6929. No Authenticator app, no FIDO key. SMS is the weakest second factor (SIM-swap, SS7).
• Mailbox is clean of obvious breach indicators. No suspicious inbox rules, no auto-forwarding visible in Graph, no foreign sign-ins, no mass-mail patterns in sent items, no flagged risk detections. Sent items match her accounting role.
• Posture gaps to fix (separate from breach response):
  1. All 3 Conditional Access policies on this tenant are in report-only mode (enabledForReportingButNotEnforced) — including "Require MFA", "Block Legacy Authentication", and "Block Foreign Sign-Ins". The only thing enforcing MFA today is the deprecated per-user MFA toggle. Microsoft has been pushing tenants off per-user MFA for years.
  2. She has OAuth grants for legacy email scopes (IMAP, EWS, EAS) to "Apple Internet Accounts" and "eM Client". These are legitimate clients she uses, but they're protocol-level paths that the disabled "Block Legacy Auth" CA policy would close.
  3. All 30d sign-ins originate from 67.206.163.122 (Salt Lake City, UT, CenturyLink residential). Dataforth is Tucson. Either she's remote-working from SLC, uses a VPN exiting there, or this is persistent unauthorized access. Confirm with her / Mike. Same IP for 30 days = same workstation, not impersonation churn — but that workstation might or might not be hers.

Target details

Field	Value
UPN	jantar@dataforth.com
Object ID	daa60027-be31-47a5-87af-d728499a9cc4
Display name	Jacque Antar
Account enabled	true
Created	2023-12-07
Last password change	2026-03-09 (~55 days ago)
Assigned licenses	1

MFA — enabled and enforced?

Enabled: YES. Per-user MFA legacy endpoint returned perUserMfaState: enforced. Registration report: isMfaCapable: true, isMfaRegistered: true.

Enforced at sign-in: YES. Evidence:

• All 8 interactive sign-ins (last 30d) ended successfully with additionalDetails: "MFA requirement satisfied by claim in the token". That string only appears when Entra evaluated MFA and it was satisfied (either by fresh challenge or by an MFA-claim in the cached refresh token).
• Non-interactive sign-ins (10 sampled from 2026-05-02 alone — Outlook, Edge, OfficeHome, WeveAgave, etc.) all show authenticationRequirement: "multiFactorAuthentication".

Methods registered: mobilePhone only (SMS to +1 520-245-6929). defaultMfaMethod: null, userPreferredMethodForSecondaryAuthentication: sms.

Caveat — what's enforcing the MFA:

• It is the legacy per-user MFA "enforced" flag, not Conditional Access. All 3 CA policies on this tenant are in enabledForReportingButNotEnforced:
  • ACG - Require MFA for All Users — report-only
  • ACG - Block Legacy Authentication — report-only
  • ACG - Block Foreign Sign-Ins — report-only
• Security Defaults: disabled.
• This works today, but Microsoft is sunsetting per-user MFA. The CA policies should be flipped to "On".

Recommendation for Jacque specifically:

1. Have her register Microsoft Authenticator (push/TOTP) as her primary, demote SMS to fallback. Self-service: https://aka.ms/mfasetup
2. Treat SMS-only as a known posture gap until Authenticator is added.

Per-check findings

1. Inbox rules (Graph v1.0)

• 1 rule, disabled. Moves messages whose header contains X-Inky-Graymail: True to a folder, then stops processing. This is a normal Inky-anti-phishing graymail filter. Not suspicious.

2. Mailbox settings (Graph)

• Auto-reply: disabled. Time zone US Mountain. Locale en-US. Nothing flagged.

3. Exchange REST (hidden rules / mailbox permissions / SendAs / Get-Mailbox)

• NOT CHECKED. Exchange admin endpoint returned HTTP 401 for the Security Investigator SP on this tenant. The "Exchange Administrator" directory role is not assigned to that SP in Dataforth. This is a known gap from the per-tenant onboarding step.
• To enable: a tenant Global Admin assigns the Exchange Administrator role to the ComputerGuru Security Investigator service principal in this tenant's Entra Roles blade (or run bash .claude/skills/remediation-tool/scripts/onboard-tenant.sh dataforth.com if cert auth works on this machine). Without it we can't see hidden inbox rules, delegates, SendAs, or the canonical ForwardingAddress / ForwardingSmtpAddress / DeliverToMailboxAndForward mailbox flags.
• The Graph-side mailbox settings show no forwarding flag (automaticRepliesSetting.status: disabled) but Graph cannot see the Exchange-only forwarding fields.

4. OAuth consents + app role assignments

• 2 user-consented OAuth grants (both consented by her, scope = legacy email):

  Resource	Client ID	Scopes
  Office 365 Exchange Online	85e650f8-5eec-4523-a9ef-fc1a031fb1d6	openid offline_access EAS.AccessAsUser.All (Apple Internet Accounts — EAS)
  Office 365 Exchange Online	25db1c08-f5a0-4f6c-bbdd-a738689b1587	IMAP.AccessAsUser.All EWS.AccessAsUser.All offline_access email openid (eM Client)

• 2 app role assignments under her account:
  • "Apple Internet Accounts" (assigned 2024-04-02)
  • "eM Client" (assigned 2024-08-26)
• Both consistent with a Mac user running Apple Mail + a Windows/Mac user running eM Client. Legitimate clients, but they consume legacy auth scopes (IMAP / EWS / EAS) that bypass modern auth challenges. The disabled "Block Legacy Auth" CA policy would normally block these.

5. Authentication methods

• 2 methods on record:
  • passwordAuthenticationMethod (last set 2026-03-09)
  • phoneAuthenticationMethod mobile, +1 520-245-6929
• No microsoftAuthenticatorAuthenticationMethod, no FIDO2, no Windows Hello, no software OATH token.

6. Sign-ins (last 30 days, interactive)

• 8 successful sign-ins. All 8 from 67.206.163.122 (Salt Lake City, UT, CenturyLink-issued residential). No failures, no foreign-geo, no legacy-auth client app types in this set.
• App: mostly "Dime Client" (a2760c41-63c9-42b5-8d58-bfa1fd9e2eb3 — Microsoft first-party app, used by some web client surfaces) + one "One Outlook Web".
• Risk level: hidden (Identity Protection not licensed).
• Action: confirm with Jacque or Mike that the SLC IP is hers (remote work, VPN, etc.). If not, treat as compromise.

7. Directory audits (last 30 days, target = jantar)

• 5 events, all benign:
  • 3 × "Update user" by Microsoft Substrate Management (Microsoft system process, automatic profile maintenance)
  • 2 × "Add member to group" on 2026-04-06 by dcenter@dataforth.com (admin activity)
• No password resets, no auth-method changes, no role grants, no app consents by anyone other than her.

8. Risky users / risk detections

• HTTP 403 Forbidden — "Your tenant is not licensed for this feature." Identity Protection requires Entra ID P2; Dataforth's SKUs (O365 Business Premium, Business Standard, Exchange Standard) include P1 only. Not checkable on this tenant.

9. Sent items (last 25)

• Normal accounting/AP work: Patricia at times-biz.com (external bookkeeper), AMoreno + sabreu at crestins.com (insurance broker), Paychex contacts (nknippel@, cknoll@), internal Dataforth (Kellynwackerly@, tdean@, dcenter@, ghaubner@, ofest@, ltobey@, shipping@), various vendor reply-thread subjects ("Sales Invoice", "Statement", "JE to correct AP issue", "Commissions", "ACH", "Bank", "PER1 and PIN1").
• No blast patterns, no unusual external recipients, no obvious phishing or BEC payloads. Subject lines and recipient mix consistent with her finance role.

10. Deleted items (last 25 visible)

• Only 3 items: 1 promotional email (info-az-specialists.com@shared1.ccsend.com), 2 self-sent items (probably saved-then-discarded drafts). Low count likely indicates Deleted Items is being emptied regularly or auto-purged by retention. Not flagged, but anomalous low count means a mailbox-level audit log search would be needed if you want to see what was deleted earlier.

Suspicious items pulled from above

• All 30d sign-ins from a single Salt Lake City residential IP (Dataforth is Tucson). Not a breach indicator on its own — the IP is consistent for 30 days, suggesting one persistent client. Confirm with Jacque or Mike whether she works from SLC / uses a VPN there.
• Two OAuth grants to legacy-auth third-party email clients (eM Client, Apple Mail). These are legitimate apps but they keep IMAP/EWS/EAS sessions alive that the dormant "Block Legacy Auth" CA policy would otherwise close. Ask whether she still uses both clients.

Gaps — checks not completed

Gap	Reason	Fix
Hidden inbox rules, delegates, SendAs, mailbox forwarding fields	Exchange Admin role not assigned to Security Investigator SP in this tenant (HTTP 401)	Tenant Global Admin: assign "Exchange Administrator" to SP bfbc12a4-... in Entra Roles. Or run onboard-tenant.sh dataforth.com after fixing PyJWT on operator workstation.
Identity Protection (riskyUsers, riskDetections)	Tenant not licensed for AAD/Entra ID P2	Out of scope — would require license upgrade for ~$9/user/mo.

Next actions

1. Confirm SLC sign-in IP with Mike or Jacque — is 67.206.163.122 her? (single highest-value question)
2. Have Jacque add Microsoft Authenticator as MFA method, demote SMS to backup. Self-service: https://aka.ms/mfasetup. Could be done in 2 minutes during her next phone call with us.
3. Force a password reset as a precaution given the dark-web hit (separate /remediation-tool remediate jantar@dataforth.com password-reset would do it after explicit YES — currently NOT executed).
4. Tenant-level posture (separate engagement, discuss with Mike before doing):
   • Flip the 3 ACG CA policies from report-only to On.
   • Assign Exchange Administrator to the Security Investigator SP so we can see hidden rules / forwarding on future investigations.
   • Decide whether eM Client / Apple Mail (legacy-auth scopes) are still needed — if yes, those users will need an exemption when "Block Legacy Auth" is enforced.

Data artifacts

Raw JSON in /tmp/remediation-tool/7dfa3ce8-c496-4b51-ab8d-bd3dcd78b584/user-breach/jantar_dataforth_com/:

• 00_user.json, 01_inbox_rules_graph.json, 02_mailbox_settings.json
• 04a_oauth_grants.json, 04b_app_role_assignments.json
• 05_auth_methods.json, 06_signins.json, 07_dir_audits.json
• 08a_risky_user.json (403 — not licensed), 08b_risk_detections.json (403)
• 09_sent.json, 10_deleted.json
• mfa_perUserState.json, mfa_regDetails.json, ca_policies.json, secdef.json
• 03a_InboxRule_hidden.json / 03d_Mailbox.json are EMPTY (Exchange 401)