The Federal Bureau of Investigation (FBI) warning about iPhone and Android phishing landed in my inbox four times before lunch. Legal forwarded it, then human resources (HR), then the chief financial officer's (CFO's) assistant, then a detection engineer on my own team asking for my take.
The advice underneath the headline was the same in every forward: don't click, don't reply, delete the text. Useful consumer guidance, but incomplete as a work item for a security operations center (SOC).
I've been on the receiving end of these forwards long enough to know the two standard reactions, and both miss. One camp files the advisory under consumer noise and moves on, which is defensible when readers only review the recommendations; the other camp forwards it to all-staff and considers the job done.
The public service announcement (PSA) text under those headlines carries technical details, including domain patterns and tactic descriptions, as well as verification instructions that a detection engineer can turn into rules and a security leader can turn into procedure. Nobody in the forwarding chain did that, so I did.
In brief:
- FBI phishing PSAs are written for the person holding the phone. The SOC value sits in the tactic descriptions and infrastructure details the news coverage skips.
- Toll and delivery smishing infrastructure churns fast enough that reputation alone is insufficient; newly registered domain signals and post-click telemetry meaningfully improve coverage where they're available.
- The FBI's advice to create a private verification phrase is a verification protocol in consumer clothing. It belongs in help desk and finance procedure.
- IC3 publishes a manageable stream of PSAs, only some of which touch phishing. A biweekly review covers it; SOC teams don't need to chase each headline.
Why FBI phishing advisories are written for users, not the SOC
A consumer document by design
An IC3 PSA is a consumer document by design. Toll guidance commonly tells readers to file a complaint, check their account through the legitimate toll site, and delete the text. Impersonation guidance commonly warns readers not to share a two-factor code through messaging channels.
None of that maps directly to a rule. Consumer PSAs prioritize public actions over detailed indicators; for richer material, monitor IC3 industry alerts, joint advisories, CISA products, and any FBI or sector-sharing channels your organization can receive.
Where the SOC value actually sits
A PSA describes the lure text, the delivery channel, the pivot the attacker asks for, and the verification step the FBI thinks works. Each of those is an input: lure text feeds keyword hunts, delivery channel scopes what telemetry you can and can't see, the pivot becomes a policy red flag, and the verification step becomes procedure.
The translation usually produces at least two work streams: detection engineering where technical signals are visible, and policy or procedure where the control depends on human verification. Some advisories also need MDM, fraud, legal, communications, or vendor-risk ownership before they're actually closed out.
The recent advisories worth translating
Three recurring clusters illustrate the kind of FBI and IC3 material that keeps landing in my inbox: toll and delivery smishing, AI-enabled voice and text impersonation, and mobile app or device risk. Each cluster produces a different mix of detection and policy work.
Smishing at scale: toll and delivery lures on throwaway domains
The toll smishing item in my review was I-041224-PSA. Its sample lure used a small unpaid toll and the threat of a much larger late fee to drive the recipient toward a lookalike toll domain.
Assume toll and package campaigns can rotate through large pools of malicious domains as older infrastructure is blocked. Scope collection beyond the secure email gateway (SEG) and carrier Short Message Service (SMS) controls to account for delivery through mobile messaging channels such as iMessage and Rich Communication Services (RCS) as well.
AI voice and text impersonation of trusted figures
The useful stack starts with messaging impersonation and links generative AI fraud to spoofed-site tactics. The May 2025 PSA and a December 2025 follow-up focus on SMS and AI-generated voice messages claiming to come from senior US officials, malicious links framed as moves to separate messaging platforms, and the common pivot from initial SMS contact to an encrypted mobile application such as Signal, Telegram, or WhatsApp.
The FBI's consumer guidance recommends a secret word or phrase for family identity verification. I treat that as a prompt to build a fuller enterprise verification protocol rather than a standalone control: pair any shared phrase with an independent callback to a previously known number and, where the risk warrants it, dual approval.
More recent impersonation scenarios also include AI-generated video of senior FBI leaders steering victims to spoofed sites.
The operational caveat is the point worth repeating to executives: assume modern AI-generated content cannot be identified reliably by sight or sound alone. That's why this belongs in verification procedure rather than awareness training alone.
CrowdStrike reported a 442% increase in vishing activity from the first half to the second half of 2024; that's vendor-observed trend data rather than a market-wide rate, but it supports treating voice-based social engineering as a verification problem, not a content-recognition one.
Foreign-developed apps, and BADBOX 2.0 on managed IoT
The app-risk item most people forwarded is I-033126-PSA, Data Security Risks of Using Foreign-Developed Mobile Apps in the United States. It's primarily a data-governance advisory: app permissions, data collection scope, downloads from unofficial marketplaces, and risk from servers outside US jurisdiction. It's not where the specific BADBOX indicators come from.
Treat BADBOX 2.0 as a separate item with its own PSA. I-060525-PSA, issued in June 2025, lists the indicators worth translating into checks: apps sourced from unofficial marketplaces, requests to disable Google Play Protect, Android devices that aren't Play Protect certified, and unexplained or suspicious internet traffic. Those are most actionable on corporate-owned, fully enrolled Android and IoT devices, where your MDM can actually confirm them.
One correction applies to anyone who forwarded the stop-mixing-SMS-with-encrypted-messaging headline as an FBI phishing warning. Treat it as Cybersecurity and Infrastructure Security Agency (CISA) mobile communications guidance issued in response to telecom intrusions, not a standalone IC3 phishing PSA.
It recommends phishing-resistant FIDO authentication, end-to-end-encrypted communications, telco PINs, and device hardening, so route it to identity, mobility, and executive-protection owners, not just the SOC.
What to pull forward into detections
Smishing often lands on a device or messaging channel the SOC doesn't fully manage, so the detection work shifts toward the infrastructure around the lure and the behavior after the click, with mobile telemetry used where the organization actually has it. Domain controls and identity events deserve engineering time, with mobile device management (MDM) signals incorporated where available.
Lookalike and newly registered domains from the smishing lures
Toll and delivery smishing infrastructure can rotate fast enough that reputation alone is insufficient; assume smishing domains can disappear especially fast. That churn is why newly registered or newly seen domain signals belong in the control stack alongside reputation, not instead of it.
My operating pattern is to start in alert mode, allowlist the business software as a service (SaaS) that trips it, and then move to blocking once the false positives are understood. These signals materially improve coverage when they're available, but none of them replace user reporting, mobile-device controls, or business-process verification.
For brand lookalikes, include organization-specific crafted domains in phishing hunts, and tune similarity thresholds against your own DNS volume and brand characteristics rather than importing someone else's number.
In my last SOC, a Splunk ut_levenshtein distance of 2 against our corporate domain was workable; higher thresholds created too many false positives there. That's not a universal threshold, and it misses homoglyph and IDN/punycode variants on its own.
Pair it with dnstwist permutations loaded into a lookup, and watch certificate transparency logs for brand strings as enrichment, not full coverage, since it only surfaces newly issued certificates carrying the brand name.
Add the recurring smishing top-level domains (TLDs) such as .top, .xin, .cyou, and .vip to a rare-TLD hunt as one scoring feature, not a block rule; legitimate sites use these TLDs too. When someone in finance clicks the toll lure from a managed laptop, that combination is what fires.
Impersonation: verification protocols, not user vigilance
Detect the impersonation's purpose through the multifactor authentication (MFA) reset, the password reset, the new device enrollment, or the OAuth consent grant. Scattered Spider uses help desk social engineering, and vishing and identity-focused attacks have grown.
Treat knowledge-based questions as a low-assurance signal, not identity proof; the expected answers may be exposed through public records, breached data, or social media. Use phishing-resistant authentication, device-bound recovery methods, and verified callbacks instead.
Alert on help-desk-initiated MFA resets, Temporary Access Pass issuance, recovery-method changes, and new authenticator registrations for privileged accounts, and correlate each to a ticket. A ticket number alone isn't proof, so confirm it records an approved identity-proofing method, an authorized requester, and any required second-person approval.
Smishing- and vishing-initiated compromises generate the same post-access behaviors as other initial access vectors; your identity telemetry already sees the reset, and the detection is the reset without that verification behind it.
Mobile app inventory and egress signals
Know what your MDM can't tell you before you write the rule. Design bring your own device (BYOD) rules assuming application visibility will be limited to managed apps and work data rather than a complete personal-device inventory.
Treat user-installed iOS apps and the personal side of Android work profiles as outside organizational visibility unless your deployment proves otherwise, so the BADBOX indicators are meaningfully checkable only on corporate-owned, fully enrolled devices. Sideloaded apps remain common enough to matter, but on much of your BYOD fleet you will not see them.
Egress visibility varies by platform, enrollment mode, browser, and mobile threat-defense product. Don't assume desktop-equivalent inspection on every mobile platform, and validate exactly which connections, apps, and browsers your tools can actually observe before you write a rule against them.
Depending on the product, the useful telemetry may include network protection audit and block events, plus whatever your mobile threat defense vendor forwards to the security information and event management (SIEM) platform. Route available events into the same newly registered domain and lookalike correlations as your desktop DNS, and treat a managed-phone hit on a suspicious toll domain as a phishing report the user didn't file.
What to route to policy, not detection
Some of what the advisories describe has no telemetry at all. Those items go to a policy owner with a deadline instead of the detection backlog. That routing matters because procedure is the only available control for several of these scenarios.
Verification procedure for executives and finance
A secret word or phrase can be a pre-shared challenge for executive-to-finance requests. Pair it with callback discipline: use a previously known number rather than contact information supplied in the request. Personal challenge questions can also interrupt a cloned-voice call when the impersonator cannot supply the shared context.
In the widely reported Hong Kong deepfake fraud involving an Arup employee, a finance worker made 15 wire transfers totaling roughly $25.6 million after a video call where the apparent CFO and colleagues were synthetic. The fraud surfaced only when the employee later followed up with headquarters.
The incident reinforces why voice or video presence alone cannot establish identity, and why callback verification through a channel the requester didn't supply is worth the friction.
Write the pivot, unsolicited SMS followed by an immediate request to move to Signal or WhatsApp, into the executive protection brief as a named red flag, and make the callback rule apply to the C-suite in writing so the help desk has cover when an alleged CEO pushes back.
Reporting the SOC can't build visibility around
User reporting remains essential for SMS, consumer messaging, voice calls, and unmanaged-device lures that don't reliably generate enterprise telemetry. Treat 7726 as a carrier-reporting path, not SOC intake: most mobile carriers support forwarding unwanted texts to 7726, but it doesn't create a case in your SIEM or guarantee your team sees the evidence.
Likewise, do not expect email scanning to cover phishing delivered through SMS or consumer messaging apps; publish one intake path for text screenshots and voicemail summaries, capture sender, URL, and domain registration age on every report, and define a threshold for an all-staff advisory when matching reports indicate a campaign.
Assign an owner, deadline, and evidence-of-completion requirement for each of these. A documented procedure isn't a control until a team can execute and audit it.
Keeping this current without chasing every headline
You won't keep up by tracking every advisory as it's published. What needs to last is the process you use to review them.
Watch IC3 directly, translate on a cadence
Monitor the IC3 PSA and industry-alert pages directly through a feed reader or page-monitoring workflow where available rather than through an email notification. The volume is manageable.
Sort by type before reading, because PSAs give you tactic and policy language, FLASH reports give you indicators, and joint FBI/CISA advisories give you tactics, techniques, and procedures (TTPs) with mitigations. Check supersession every time; impersonation and messaging guidance can change as campaigns evolve.
My cadence is a 30-minute block every other Friday. I read the new feed items, tag each one detection or policy, open a ticket for anything that's either, and close the block. The last time through, the toll PSA became a rare-TLD hunt in an afternoon, and the officials PSA became two lines in the finance verification procedure.
Frequently asked questions about FBI phishing advisories
Where does the FBI publish phishing advisories?
IC3 separates consumer-facing Public Service Announcements from industry alerts, FLASH reports, and joint FBI/CISA advisories intended for more technical audiences. Alert IDs commonly use a date-based PSA format. Monitor both collections directly or relay them through an approved government-alert or security-news workflow that covers FLASH alerts and IC3 advisories.
What recent phishing threats has the FBI warned about?
A useful working watchlist includes toll-debt smishing, AI voice and SMS impersonation of senior US officials, and foreign-developed mobile app or IoT device risk, including BADBOX 2.0. Treat phishing and spoofing as recurring IC3 intake categories rather than one-off advisory topics.
How should a SOC act on a consumer-facing FBI advisory?
Split it in two. Lure text, TLDs, and delivery channel go to detection engineering as newly registered domain, lookalike, and post-click correlation work; verification advice and platform-pivot red flags go to help desk, finance, and executive protection as procedure with an owner and a date. Confirm directly that the PSA hasn't been superseded before either ticket is opened.
How often does the FBI update phishing warnings?
IC3 doesn't publish phishing advisories on a fixed schedule; individual PSAs get updated when a campaign changes, and replacement advisories may broaden the dates, targets, or tactics covered. Its industry-alert collection includes an RSS feed, which makes monitoring practical. I've found a biweekly review of the PSA and industry-alert collections frequent enough for most teams, though anyone with heavy payment-fraud or executive-targeting exposure may want faster triage for those specific categories.