What is smishing?
Smishing is phishing delivered by SMS. The sender impersonates a familiar organization or person to persuade you to do something that benefits the attacker. They might ask for a password, card details or an authorization code, or for you to install an unwanted app. A link is common, but a text can also ask you to call a particular number.
Separate the delivery channel, the pretext and the goal. The channel is a text message. The pretext might be a delivery problem. The goal may be access to your bank or email account, far more than the small fee mentioned in the text. A message about a parcel gives you no reason to sign in to whatever service appears on the next screen.
The examples below illustrate common patterns rather than a particular ongoing campaign. A well-written text and a form that works smoothly can be parts of the same scam.
Why a short message can be convincing
Work and personal matters share space on a phone. A notification appears alongside collection codes, messages from family and updates from services you actually use. You rarely start by assessing the security of each one. You’re trying to collect a parcel, confirm an appointment or check a payment.
A short message has room for a problem, a deadline and one suggested solution. The pressure can be subtle. A warning that a delivery will be delayed without confirmation may be enough. If you’re already expecting a parcel, you fill in the missing context and might forget to check who sent the message.
That moment is where we think training should focus. “Watch out for suspicious messages” gives people little to act on. When a text asks for money or information, check the request through a channel you know. You can open the official app without first having to prove the text is fraudulent.
From notification to request for data
A typical text begins with a small request. You follow a link to see the details. The page takes over, using familiar colors, the service name and a short explanation. The next step may look like a routine address check or payment.
Watch for a change in what you are being asked to do. Parcel tracking turns into a card form, a bill leads to a bank login, or a security alert asks for a code. If you’re still thinking about the original task, it’s easy to miss that it no longer explains the information requested.
Ask yourself exactly what the screen is asking you to confirm. A button label tells only part of the story. If your official app describes a different transaction from the one you intended, decline it. Pause before entering information, while you can still choose how to proceed.
Banks, couriers, phone providers and public authorities
Different names can lend the same request a plausible explanation. A bank suggests an urgent need to protect funds. A courier suggests a surcharge or an incorrect address. A phone provider suggests a service interruption, and a public authority suggests an obligation you might miss. The name carries weight before you’ve had time to examine the message.
Many organizations genuinely notify customers by text, so a link or the word “urgent” alone tells you little. Consider the sender, what you were expecting, the address and the action requested. Do they fit the way you usually use the service?
Businesses can make impersonation harder by sending consistent messages. Tell customers what notifications contain, where they can verify them and which details support will never request by text. That leaves fewer exceptions for customers to interpret under pressure.
Check the address and the form separately
A shortened URL hides the destination. A longer one may put a familiar brand name in a path or subdomain that does not identify the domain owner. That distinction is easy to miss on a phone. Recognizing a word in an address is only a starting point.
A redirect means the first address may differ from the last. Legitimate services use redirects too. What matters is where you’re being asked to enter information. If you can’t verify that site, open the service independently instead of relying on its appearance.
A fake login form may work perfectly and contain no spelling mistakes. Encryption protects data on its way to that site. It does not establish that your bank or employer owns it. Giving employees a known sign-in point is more reliable than expecting them to remember what every screen looks like.
Attackers want more than passwords
One-time codes and transaction approvals are targets too. Report an unexpected request you approved even if you never entered a password. Support needs to know what you actually did. Asking only whether someone handed over their login details can miss what happened.
Multifactor authentication improves security, but methods vary in their resistance to phishing. CISA identifies FIDO/WebAuthn as phishing-resistant approaches. Choose methods that fit the risk of each account and consider how access is recovered. A weak recovery process can undermine strong sign-in controls.
Agree in advance how employees should check unusual requests to authenticate again. A clearly defined process makes an unexpected text easier to recognize as a departure from normal practice. It also reduces the number of unfamiliar access instructions people must interpret on their own.
Source CISA on phishing-resistant MFA.
When to pause
No single detail reliably distinguishes every genuine text from a fake. The following questions help identify requests that need another check. Fluent writing and a familiar logo offer no proof of origin.
- Were you expecting this, and can you check it in your official account without following the link?
- Does the task require the information requested, or is the page asking for more?
- Does an artificial deadline leave you little time to check?
- Are the address and sign-in process the ones you normally use?
- Did a request to install something, supply a code or approve a transaction appear without you initiating it?
Related at APT How Anti Phishing protects against malicious links.
What to do after receiving a suspicious text
Open the official app yourself or use an established contact channel to check. In Poland, you can forward a suspicious text unchanged to CERT Polska at 8080. Avoid circulating the active link as a warning without context. At work, follow your organization’s reporting process.
Tell your security team whether you only received the text, opened the page, entered data or approved an action. Each calls for a different response. Include the time, what you did and which account the request concerned. Leave out passwords and authorization codes.
If you entered credentials, open the real service through a known route and follow its account security procedure. For payment details, contact your bank through an official channel. At work, report the event promptly even if you’re unsure whether there was harm. A timely account of what happened is more useful than trying to reconstruct the attack alone.
Why employee phones belong in the security plan
A text can target a work account without ever passing through corporate email. Agree on the devices your organization supports, how staff should report a message and who checks device security. Pay particular attention when the same phone handles personal matters and access to company services.
Test deployment against practical questions. Does the employee know where to report a text? Can the administrator see how recent the device report is? Will anyone notice if protection is switched off? Who secures the account after an incident? A software inventory alone cannot answer these questions.
At APT, Android protection includes device status reporting to Enterprise Security Center. That visibility complements reporting procedures and identity controls. People still need to verify unexpected requests, but the organization can check whether protection is active on the devices receiving them.
Related at APT Enterprise Security Center and device reports.
