Customers Got Texts Pretending to Be Your Company

Why this matters

When customers start calling about a payment text you never sent, two things are happening at once. Some of your customers are handing card numbers to a stranger right now, and somewhere in your shop there is probably a hole that let the stranger know who your customers are. The order you work it in matters: every hour spent investigating before the warning goes out is another hour of customers paying the scammer in your name. Stop the bleeding first, then find the hole.

The case: a Tuesday morning at a pest control shop

A fourteen-person pest control shop with about 2,300 active accounts gets its first call at 8:10 on a Tuesday. A customer wants to know why she owes a late fee. By 10:00 the office has taken 11 calls about the same thing. One customer forwards the text:

From: (an unfamiliar 10-digit number)

Hi Dana, this is Northside Pest. Your
quarterly treatment on 6/12 shows unpaid.
Pay today to avoid a 25% late fee:
northside-pest-billing.(link)

Reply STOP to opt out

Read what is in it before reacting, because the content is evidence. It uses the customer's first name. It names her actual last treatment date. It uses a lookalike domain registered to look like the shop's. And it borrows the cadence of a real reminder, including an opt-out line. A text that only says "your pest control account is past due" could be a spray sent to thousands of random numbers. A text with the right first name and the right service date was built from a list of this shop's customers.

Stop: confirm it is not you, then cut off the link

First, rule out your own system in ten minutes. Open the sending log of whatever sends your texts: the field service software's reminder log, the texting platform, the office phone's message history. The shop finds no outbound texts after 6:00 the previous evening, and none mention a late fee. This matters because a misconfigured reminder template that is accidentally sending "unpaid" messages is a real failure that looks identical from the customer's side, and the response to it is an apology, not a fraud warning. Do not send a "this is a scam" message to customers until you have confirmed it is one.

Second, go after the link. Look up the lookalike domain's registration record to find its registrar and hosting provider, and send each one an abuse report with the text, the domain, and a sentence saying it impersonates your business to collect payments. Report the address to the major browsers' unsafe-site reporting pages as well, so that it starts showing a warning screen. None of this is fast or guaranteed, which is exactly why the customer warning goes out before you wait on it.

Contain: warn customers on channels they already trust

The warning goes out by 11:00, on three channels. The shop sends it as an email from its own domain (which passes authentication, so it is the one email a customer can trust; see related: Setting Up Email Authentication So Nobody Can Send As You), as a text from the shop's real number that customers already have saved, and as a banner on the website and a post on its business profile. The wording used:

"Some of our customers received a text this morning claiming to be from Northside Pest and asking for a late payment through a link. We did not send it. We never charge late fees by text and never ask for payment through a link we have not discussed with you. If you received it, delete it. If you paid through it, call the number on the back of your card today and tell them the charge was fraud. Questions: call us at the number on our trucks and invoices."

Three choices in that wording earn their place. It says what the shop does not do, which gives customers a rule they can apply to the next text. It tells the people who already paid exactly what to do, in one sentence, because they are the ones with something to lose. And it routes questions to a number customers can verify from a physical object, rather than a number in the message itself. It does not speculate about how the scammers got the list. Saying "our system was hacked" before you know is something you may have to take back.

Customers who paid get a phone call, not a mass message. Three of the 11 callers had paid. The office calls each one back, confirms they have contacted their card issuer, and logs it. Under federal rules a consumer's liability for fraudulent credit card charges is capped, while a debit card runs on different rules where the protection shrinks the longer the customer waits to report, and in both cases the bank handles the dispute; that is the customer's process with their bank, not yours to run, but pointing them at it quickly is the most useful thing you can do. Nobody at the shop offers to cover the loss on the call. That is a decision for the owner later, made once with full information.

Report it. File at the FTC's fraud reporting site, which feeds the database law enforcement uses. Ask customers to forward the scam text to 7726 (SPAM), which reports it to their mobile carrier. If any customer lost money, the FBI's Internet Crime Complaint Center takes reports too. Keep a log of every customer who called, when, and whether they paid. That log becomes the evidence for the diagnosis.

Diagnose: how did they get the list?

By noon the warning is out and the calls are slowing. Now the question is where a list of names, phone numbers and service dates came from. The shop works four candidates.

A compromised office mailbox. Email holds customer details, and a broken-in mailbox is the most common source of a targeted list. The owner checks the mail provider's sign-in log for the two office accounts for the past 30 days: all sign-ins from the office's own network and the owner's phone. No new forwarding rules, no new connected apps. This candidate is unlikely, though not impossible.

A breach at a vendor. The texting platform or field software vendor could have leaked data. The owner emails both vendors asking whether they are aware of any incident. Neither has reported one. This stays open while the next candidate is checked, because a vendor answer can take days.

A former employee who took the list. The shop had two people leave in the past six months. The question is whether either could still export customers. See related: The Former Employee Still Had Access.

An export from the field software itself. The owner opens the software's audit log, filters for customer exports, and finds one: a full customer export on a Saturday nine days earlier at 2:14 in the morning, from a sign-in at an internet address that is not the shop's, under the login used on the shared field tablet.

That last finding answers the question and also explains the former-employee candidate. The shared tablet login had one password that every tech used, written inside the tablet case, and a seasonal tech who left in the spring knew it. Whether he used it himself or the password traveled further, the account was the hole. See related: The Shared Login Problem.

Confirming the export was the source

A plausible cause is not the same as a confirmed one, and the shop needs certainty before telling customers anything about how it happened. The export file the audit log describes contained name, mobile number and last service date for every active account on that Saturday. That is exactly the field set in the scam text, and nothing the text used came from outside it.

The sharper test is timing. The shop added 23 new accounts in the nine days between the export and the texts. If the export was the source, none of them should have received a text. Of the 41 customers who called or emailed about the text over the next two days, none was among the 23. Had even one of the new accounts been texted, the list would have had to come from somewhere with fresher data, and the vendor and mailbox candidates would reopen.

Closing the hole

• The shared tablet login is deleted the same afternoon. Each tech gets their own login, and the account the tablet uses can no longer export.
• Customer export permission is restricted to the owner, and multifactor authentication is turned on for every login that can see customer records; see related: Turning On Multifactor Authentication Without Locking Yourself Out.
• Every remaining login is reviewed against the current staff list, and two more stale accounts are removed.
• The owner sets a weekly reminder to read the audit log's export entries. An export at 2:14 on a Saturday is the kind of line that stands out in a five-minute weekly read, and this one sat unnoticed for nine days.

The obligation question

Whether this triggers a legal duty to notify customers is a separate question from whether to warn them, which the shop already did. This is not legal advice. Most state breach-notification statutes are triggered by a person's name combined with something like a Social Security number, a driver's license number or a financial account number, so a list of names, phone numbers and service dates often falls outside them; a few states define personal information more broadly, and the answer depends on the state where each customer lives, not the state your shop is in. Because this list held no financial data, the shop's exposure was the scam, not a regulated breach, but the owner confirmed that with an attorney rather than assuming it. Walk in with the audit log entry, the fields the export contained, the count of affected customers by state, and the timeline. The full decision belongs to see related: Handling a Data Breach Notification Obligation. Had the export included card or bank details, that conversation would have come before the public warning went out, not after.

What would have sent this the wrong way

Had the sending log shown a reminder template misfiring, every step after "Stop" changes: the message becomes an apology and a correction, and nothing gets reported to the FTC. Had the text carried no names or dates, the diagnosis would stop at "spray campaign using our public name," and the right investment would be the warning and the reports, not an audit-log search. And had the owner started with the audit log at 8:15, he would have found the hole by 9:30 and still been the shop whose customers paid a scammer for three more hours.

References

• Federal Trade Commission, ReportFraud.ftc.gov and consumer guidance on text message scams
• FBI Internet Crime Complaint Center (IC3)
• Fair Credit Billing Act, 15 U.S.C. 1666 (consumer credit card dispute rights)
• See related: Handling a Data Breach Notification Obligation, The Shared Login Problem, The First Hour After a Suspected Breach SOP