What Is Phishing? Recognizing Requests That Put Accounts at Risk

Key takeaways

• Phishing uses deceptive communication to obtain information, access, money, or another unsafe action.
• A polished message or familiar sender does not establish that a request is legitimate.
• Verify sensitive requests through a known channel that did not come from the suspicious message.
• Response should match what happened, including credentials entered, approvals given, or software executed.

Phishing is a form of social engineering that uses deceptive messages or interactions to persuade someone to disclose information or perform an unsafe action.

The attacker may want a password, a sign-in approval, a payment, a confidential document, or software installed on a device.

Imagine receiving a message saying that a shared project file is about to expire. The link opens a familiar-looking login page. Entering credentials seems like an ordinary step toward reading the document, but the page belongs to the attacker.

The Requested Action Matters More Than the Appearance

Attackers can copy branding, use convincing language, and refer to real projects. They may also send messages from compromised accounts.

The absence of spelling mistakes is therefore weak reassurance. Examine what the request asks you to do and whether it fits an independently established workflow.

The FTC’s phishing guidance describes common pretexts involving account problems, invoices, and requests to confirm information.

Urgency matters because it reduces time for verification. But an attack can also be patient, building a believable conversation before introducing a sensitive request.

Phishing Can Use Several Channels

Term	Typical meaning
Email phishing	Deceptive requests delivered through email
Spear phishing	A request tailored to a particular person or organization
Smishing	Phishing through text messages
Vishing	Voice-based deception
QR-code phishing	A code directing the recipient to a deceptive destination

The channel changes how the request is presented, not the need to verify it.

A QR code can hide the destination until it is scanned. A caller can create pressure interactively. A targeted email can draw on public information about a supplier or employee.

Some Attacks Need No Malware

A fake login page can capture credentials without installing anything. A fraudulent supplier message can redirect a payment through an otherwise legitimate banking application.

Other phishing attempts deliver malware through attachments or downloads. These are different outcomes and require different responses.

For the project-file example, the device may remain uncompromised while the account is exposed. Treating every incident as a virus problem could leave the actual account takeover unaddressed.

Check the Destination, but Do Not Stop There

The visible link text can differ from its destination. A copied brand name in part of a URL does not establish which organization controls the site.

Understanding URL structure helps, but visual inspection has limits. Legitimate services can host malicious material, and real accounts can be compromised.

HTTPS indicates an encrypted connection to the site you reached. It does not establish that the site is the organization the message claims.

For a sensitive request, open the known application or use a saved official address rather than relying on the supplied link.

Verify Through an Independent Channel

If a supplier asks for changed payment details, use an existing contact number or established approval process. A new number included in the same request leaves the attacker in control of verification.

Likewise, replying to a compromised mailbox and asking whether the message is real may simply reach the attacker again.

For the project-file example, open the organization’s normal document system or contact the colleague through a known separate channel. If the file is real, it should be possible to establish that without submitting credentials to the unexpected page.

Organizations can make this easier by defining a repeatable process for unusual payment, access, and recovery requests.

MFA Helps, but Methods Differ

Multi-factor authentication can block an attacker who has only a password. Codes and approval prompts can still be targeted through deception or real-time relay.

WebAuthn credentials are bound to the relying party rather than being reusable codes entered into any page. The WebAuthn specification explains that public-key authentication model.

This provides phishing resistance for the authentication ceremony. It does not prevent every form of fraud, malicious software, or misuse of a session after authentication.

The protection depends on the method and the surrounding account-recovery process.

Respond According to What Happened

Merely receiving a suspicious message is different from entering credentials or running an attachment.

If you entered a password, use the legitimate service from a trusted device to change it, address reuse on other accounts, and review available session and recovery controls. A password change may not terminate every existing session.

If you approved a sign-in or supplied an authentication code, report that detail too. If software ran, treat the device as potentially affected and follow the malware-response process before entering replacement credentials on it.

For a workplace account, report promptly through the established channel. If money was sent, contact the relevant payment provider using known contact information as soon as possible.

Reporting Is Part of the Defense

A useful report includes the original message where the reporting system supports it, the approximate time, and what actions were taken. Preserve evidence without continuing to interact with the suspicious request.

Fast reporting gives responders a chance to investigate related messages and account activity. It works best when people can report uncertainty or mistakes without first having to prove that an attack succeeded.

The practical habit is to pause at sensitive requests and establish their legitimacy through a channel the sender does not control.

A convincing message should not be allowed to choose the only channel through which its claim is verified.