# Suspicious indicators watchlist Observations from Track Delivery and DNS, 2026-08-14 to 2026-08-17. Context: the company is visibly targeted on its finance/trade axis (spoofed bank mail, look-alike freemail addresses). Everything below needs a human answer from Narin/AKE before it can be closed. ## SLOVED 1. export.advmfr@gmail.com HIGH priority A Gmail address that mimics the company mailbox `export@advmfr.net` (pattern `.advmfr@gmail.com`). Facts observed: - `export@advmfr.net` sends to it repeatedly: 09:57 (discarded with the FedEx batch), 13:21, 16:35, 17:09 on 2026-08-17. The 09:57 event sits in the same minute as the 3 FedEx customs recipients, which strongly suggests it is CC'd on customs/shipping correspondence (invoices, shipment values, clearance documents). Why it matters: the `name.company@gmail.com` pattern is the standard setup for Business Email Compromise. If that Gmail is not controlled by the company, an outsider is receiving the full export paper trail, which is exactly what is needed to send customers or forwarders a fake "our bank details changed" invoice. Questions to answer (Narin / export team): - [ ] Does the export team own this Gmail? Who created it, who holds the password, is 2FA on? - [ ] Why is it CC'd: manual habit, or an automatic rule? - [ ] Check the mail client (Outlook) on the export PC for rules that auto-add this recipient or auto-forward. Server-side forwarders are clean (verified 2026-08-14: zero cPanel forwarders), so any auto-copy would be a client-side rule, which is also the classic persistence trick after a PC compromise. - [ ] Review the Sent folder of `export@advmfr.net`: since when does it write to this address, and what content goes there? If nobody claims the address: treat as active BEC. Change the `export@` password immediately, audit the PC, warn FedEx contacts and active customers to verify any payment-detail change by phone. If the team claims it: still a problem (company documents on an uncontrolled personal Gmail). Decide: either kill the habit, or make it an official archive the company controls. Note that its presence also weakens fraud detection, because staff get used to seeing a freemail twin of their own mailbox in threads. ## 2. narinsoda33@gmail.com MEDIUM Inbound 2026-08-17 10:31 to `account@advmfr.net` (nonexistent mailbox, rejected "No Such User Here"). Look-alike of Narin's name on freemail, aimed at an accounting-style address. Same naming trick as above, this time inbound. If mails from "Narin" at a Gmail address reach real mailboxes, staff may trust them. - [ ] Ask Narin if this Gmail is his. If not, flag the address to the team explicitly. ## 3. kasikornbank.com traffic CLOSED 2026-08-17: legitimate Initially suspected as spoof probing (`tradefinance@kasikornbank.com` writing repeatedly to the nonexistent `ACCOUNT@advmfr.net`). **Verdict after header/mailbox verification (2026-08-17): legitimate.** `chanhom@` holds 97 genuine KBank messages (Credit Advice, Copy payment message, K-eDocument daily reports, all addressed to ADVANCE MANUFACTURERS CO.,LTD.), and kasikornbank.com publishes DMARC `p=reject` with strict SPF, which makes exact-domain spoofing hard. The `ACCOUNT@` traffic is almost certainly a stale address in the bank's own records; the rejections are harmless. Optionally: ask the bank to update it. Standing rules unchanged: - Never whitelist bank domains (project rule). - Any Kasikornbank mail asking for an action (payment change, urgent transfer) is verified out-of-band, and look-alike domains (`kasikornbank-secure.com` etc.) remain the real threat to watch. ## 4. account@ / ACCOUNT@ / it@ / advance@ probing LOW (noise, but informative) Steady inbound to nonexistent finance/IT-sounding aliases (`account@`, `ACCOUNT@`, `it@`, `advance@`) from rotating senders (dhl.com billing, hungchuan.com invoices, regencyhoildays.com note the typo'd domain, cwit.ae, google bounce addresses). Attackers are mapping the company's likely finance addresses. Rejections are fine (mailboxes do not exist); no action, but it confirms the targeting. - [ ] Do NOT create these aliases, and if one is ever needed, expect immediate spam. ## 5. Self-domain spoofing phishing against hr@ ACTIVE 2026-08-19, HIGH Phishing delivered to `hr@advmfr.net`, forwarded by Narin. From forged as `advmfr.net Support ` (their own domain), subject "Email Notification!!: Reference#3034924916", body: "your WebMail Account will be blocked... verify your account". Classic webmail-credential harvesting, and well-timed: hr@ just went through days of visible mail trouble, making the "account will be blocked" lure credible. Why it got through: score stayed under both the Spam Box threshold and our score-10 rule. advmfr.net SPF ends in `~all` (softfail), so an external forger only gets a soft penalty, and DMARC is still `p=none` (observation phase). Countermeasures (deployed via the runbook flow): 1. Global filter `30-self-spoof`: From contains `@advmfr.net` AND Spam Status contains `SPF_SOFTFAIL` → Quarantine. Legit internal/Jabatus mail passes SPF, so it never softfails; only external forgeries match. 2. SPF hardening: `~all` → `-all` on advmfr.net (elevaseo.com already uses `-all`). External forgeries then hard-fail, which scores higher and gets rejected outright by many receivers. 3. The DMARC ladder (in progress) finishes the job at `p=reject`. Staff instruction to circulate: no email will ever ask you to "verify your webmail account". Anyone who clicked the link must say so (no blame) and have their mailbox password changed immediately, starting with hr@. ## Standing rule derived from all of the above Any address of the form `something.advmfr@gmail.com` or `advmfr.something@gmail.com` appearing in business threads gets reported to Bastien before anyone replies to it, whitelists it, or wires money based on it. Added to AKE's alert triggers.