The Art of Hacking People
A young man once messaged me on Instagram after his iPhone had been stolen at an event in Maputo. He wanted to tell me what had happened next.
The following day, a message arrived on his father's phone. It claimed to be from Apple and offered a way to locate the stolen device. He followed the link and entered his account credentials. The page appeared to search for the phone, but never produced a useful result. He told me the device later disappeared from his account.
Someone had used his distress to make a request for credentials feel like a step towards recovering his phone.
What social engineering exploits
Social engineering uses deception to persuade someone to disclose information, grant access, or take an action that helps an attacker. The contact might arrive by email, text, phone call, social media, or in person.
The attacker appeals to fear, desire, authority, or the willingness to help. A familiar name or a real detail makes the story easier to accept. The person they approach might be a receptionist, a colleague, or anyone whose information or access helps them take the next step.
Examine the message and its sign-in request
In the stolen-phone story, a trusted name and a promise of recovery made the sign-in seem necessary. Explore those cues in this fictional message.
Your missing phone has been located. Confirm within 15 minutes to keep this recovery request active.
Sign in to view its location.
The sender's label suggests an official service. The message provides no independent confirmation that the sender works for Apple.
A useful check: Open the service through a trusted app or independently obtained address.
Consider a second example: an email claims that your bank account details are outdated and your account will be blocked unless you update them immediately. It addresses you by name and uses a sender address that resembles the bank's, with one small spelling change. The link leads to a page asking for your banking password.
The threatened account block gives the recipient a reason to enter their password on the linked page. The sender has copied the bank's branding to make that page appear legitimate.
For a missing iPhone, open Find My independently. Apple says it does not contact people to announce that a device has been found or ask them to share passwords and verification codes. See Apple's lost-device guidance.
What happens after the credentials are submitted
The stolen-phone lure has a commercial purpose: unlinking a device so it can be resold. Group-IB's investigation of iServer documented a service that helped phone “unlockers” send targeted messages and validate stolen credentials and one-time codes. The Maputo account fits that kind of lure, but does not establish which tools were used or how the device was removed.
In corporate attacks, the objective can extend to the authenticated session. Microsoft documented Microsoft 365 campaigns using Evilginx, an adversary-in-the-middle (AiTM) reverse proxy. It relays the login through an attacker-controlled domain and captures the session cookie issued after authentication. TOTP and SMS codes can be relayed in the same exchange: expiry limits their lifetime, but does not bind them to the legitimate website.
Operators can also automate delivery of the stolen data. Symantec observed phishing kits abusing Telegram bots for credential exfiltration. The bot supplies a notification channel; the phishing infrastructure handles capture.
This is where FIDO2 security keys and WebAuthn passkeys change the outcome. Authentication is bound to the relying party, with browser origin checks, so a lookalike domain cannot relay a valid assertion as it can an OTP. NIST explains why manually entered codes lack that protection. The identity provider (IdP) must enforce the stronger method: an easily phished fallback or recovery process leaves another route into the account.
Impersonating support during a service outage
Consider a fictional school scenario that combines a helpful conversation with a technical disruption.
First, the attacker researches the school. It has several branches, reception staff use a student-management system, and a particular supplier provides the software. Those details give the caller a plausible role.
Next, the caller introduces a problem before it happens. Claiming to work for the supplier, they ask whether the system is working, mention possible interruptions, and leave a support number.
Then the problem appears. The attacker causes a denial-of-service attack, overwhelming the server until the system becomes unavailable. The outage makes the earlier warning seem credible.
The receptionist calls the supposed helper. The caller asks for an account name and password to restore access. With students waiting to register, the request arrives with a practical reason to comply.
Finally, the service returns. The attacker stops the disruption. To the receptionist, it looks as though the technician fixed the problem. The person who obtained the credentials is remembered as someone helpful.
The account could expose student information. A further request to install a “repair tool” could put the computer at risk too. Listen to the dramatised calls and an alternative response below.
Transcript
The system is still working. An unexpected caller offers help before there is a problem.
Explore this moment
The caller has become the person the receptionist relies on to explain the outage and fix it, without their identity ever being checked.
How would you check the caller's identity?
Earlier, an unknown caller said they worked for your software supplier and left a support number. They said they might need your password to fix an outage.
Select a response to see whether it checks the caller's identity independently. You can compare all three choices.
Contact the supplier through an existing support portal or a number in the contract. The FTC's guidance on business impersonation recommends avoiding the links and numbers in an unexpected request.
Small details can build a convincing identity
An attacker may gather names, suppliers, and branch details from social profiles, company websites, public records, or discarded documents. They can also approach several people, collecting small pieces of information that make a later request more convincing.
Public supplier and branch details can help an attacker impersonate support. Check the caller's identity and the requested access through the established support process.
Trust can be built over several conversations
An example from The Art of Deception by Kevin Mitnick and William L. Simon illustrates how this relationship can develop. The following is a summary of the video-store story.
An apparent customer praises a store employee and asks how to send a compliment to the manager. In the process, the caller obtains the manager's name and details identifying the branch.
The caller then contacts a different branch, impersonating that manager. Over several weeks, the requests are ordinary: checking whether a film is available, asking for help, and making friendly conversation. Repeated contact makes the invented colleague feel familiar.
Later, the caller introduces a disruption at their branch and asks the employee to look up a customer's record. The request eventually extends to the customer's stored payment details. By then, the supposed manager has a history of apparently harmless conversations to lean on.
The early calls established familiarity before the sensitive request arrived.
Harmless favours made the caller feel like a colleague. That familiarity was carried into a request for private customer information.
Compare the ordinary favour with the later request in these newly written scenes, followed by an alternative ending.
Transcript
One of several routine conversations over a period of weeks. The caller claims to manage another branch.
Explore this moment
The pressures behind the request
These approaches often appear together:
Intimidation and authority. Someone claims to be a manager or senior technician and makes cooperation feel obligatory.
Persuasion. A request sounds reasonable and routine, supported by names and details that appear trustworthy.
Flattery and rapport. Compliments and friendly exchanges build a relationship before the sensitive request, as in the video-store example.
Assistance. An offer to fix a problem becomes a reason to disclose information or grant access, as in the school scenario.
Scarcity and urgency. A deadline makes it feel costly to pause: an offer will expire, a recovery window will close, or an account will be blocked.
Impersonation and borrowed trust. The attacker assumes the identity of a colleague, supplier, institution, or relative, using familiarity or authority to support the request.
How the request reaches the target
The approach describes the pressure; these terms describe the form the attempt takes.
| Form | What to recognise | Where to pause |
|---|---|---|
| Phishing | A deceptive message directs you towards a link, attachment, reply, or call. | Before following the route it supplies. |
| Pretexting | A fabricated role or situation makes an unusual request sound necessary. | Before treating the story as authority. |
| Baiting | An attractive offer encourages you to open, download, or connect something. | Before giving the offer access to your device or information. |
| Tailgating | Someone follows an authorised person into a restricted space. | At the access check, using the visitor process. |
Voice cloning and impersonation
Voice cloning adds another reason to check requests independently. A message that sounds like a manager or family member may still be an impersonation. The FTC recommends contacting the person using a number you already know, rather than relying on the sound of the voice.
AI can also produce polished messages and synthetic video. Spoofing can make a sender address or caller ID appear to belong to someone else; a lookalike domain uses a similar address to encourage a mistaken reading. Familiar names, numbers, voices, and faces all need an independent check when the request is sensitive.
What the Uber incident illustrates
In September 2022, Uber reported an incident involving a contractor's account. According to the company's update, an attacker obtained the contractor's password and repeatedly attempted to sign in, producing two-factor authentication requests. One request was eventually approved, giving the attacker access. From there, the attacker reached additional employee accounts and internal tools. See Uber's incident update, preserved in its SEC filing.
The repeated requests are often called MFA fatigue or push bombing. Beyond Uber's confirmed account, KPMG's contemporary summary reports a WhatsApp contact impersonating IT and asking the contractor to approve a request to stop the notifications. It also describes PowerShell scripts on an internal network share exposing administrative credentials for Thycotic, the privileged access management (PAM) system, which reportedly opened access to further secrets.
Two engineering boundaries matter here. For push-based MFA, number matching reduces accidental approvals, although an attacker can still persuade someone to enter the displayed number. Prompt throttling and alerts on repeated denials followed by approval help detect the pressure. After initial access, least privilege should restrict access to shares and secrets. PAM administration needs separate identities, just-in-time privileges and audited retrieval; administrative credentials embedded in scripts undermine that separation.
Reject and report unexpected authentication requests, even when they keep arriving.
When the target is a developer
A coding assignment can make executing unfamiliar code feel routine. In Contagious Interview, Microsoft observed fake recruiters directing developers to malicious npm projects, including abuse of trusted VS Code tasks. ReversingLabs documented recruitment lures using malicious npm and PyPI dependencies. The requested action is now code execution on a workstation that may already hold corporate access.
That access can take several forms. A session cookie represents an authenticated browser session; an OAuth access token authorises API calls within its scope. The impact of token theft is illustrated separately by GitHub's 2022 investigation into stolen Heroku and Travis CI integration tokens, which attackers used to download data from multiple organisations. An attacker holding usable tokens may have no need for another password prompt.
Executing a project is one delivery route; browser exploitation is another. In 2021, Google TAG documented attackers cultivating vulnerability researchers before sharing malicious projects or research-blog links. Some compromises followed visits from fully patched Windows and Chrome systems. That report establishes endpoint compromise, rather than session theft, but explains why even experienced researchers need isolation between untrusted material and working credentials.
Run interview projects in disposable environments without corporate browser sessions, mounted secrets or access to host agents. Keep privileged browsing separate from that work. Passkeys protect the authentication exchange; they cannot prevent sufficiently privileged malware from stealing or using an existing session.
Reporting and account protection
Learn to recognise these situations, and make trusted contacts easy to find before an incident happens.
A clear way to report suspicious requests helps people pause and check before sharing information.
Use unique passwords and enable multi-factor authentication. Where available, prefer phishing-resistant options such as FIDO/WebAuthn security keys or passkeys. Extra authentication helps, but one-time codes can still be phished and unexpected approval prompts should not be accepted. CISA explains the differences between MFA methods.
- Question unexpected requests, especially those asking for sensitive information or demanding immediate action.
- Verify the identity and the need. Call back through a known number or use an established support channel.
- Protect private information. Do not disclose passwords, verification codes, or customer details to an unverified contact.
- Check links and attachments. Open the known service independently when an unexpected message asks you to sign in or install something.
- Use technical protection, including updated devices, spam filters, endpoint protection, and firewalls.
Contain and detect compromised access
The controls above address specific steps: passkeys resist credential relay, prompt controls reduce MFA fatigue, and credential separation limits escalation. Organisations also need to constrain access after sign-in.
Constrain session use. Conditional Access can require managed, compliant devices and stronger authentication for privileged applications. Device trust should use verifiable device identity and management state. Where supported, device-bound session tokens reduce replay on another machine; Microsoft describes these identity controls and token protection. Check client and resource coverage before assuming every downstream session receives the same protection.
Correlate the evidence. Connect IdP events, endpoint process activity, PAM reads and application audit logs. A development tool launching an unexpected downloader followed by unusual credential use is a stronger lead than either event alone. Baseline legitimate activity to make those combinations useful. After a confirmed compromise, revoke affected sessions and tokens, remove unauthorised OAuth grants or authentication methods, and rotate exposed secrets. A password reset alone may leave existing access usable.
Adapted from my original article on X, published on 14 April 2026. The interactive scenarios and audio conversations are fictional teaching examples. Voices were generated with ElevenLabs.