Social Engineering - Christopher Hadnagy [54]
The requests you make should match the pretext, too. If your pretext is being a tech support guy, you won’t “order” people around with what they must and must not do; you work for them. If you are a UPS delivery person, you don’t demand access to the server room.
As mentioned earlier, more steps may exist for perfecting a pretext, but the ones listed in this chapter can give a social engineer a solid foundation to build a perfectly believable pretext.
You might be asking, “Okay, so you listed all these principles, but now what?” How can a social engineer build a well-researched, believable, spontaneous-sounding, simple pretext that can work either on the phone or in person and get the desired results? Read on.
Successful Pretexting
To learn how to build a successful pretext, take a look at a couple of stories of social engineers who used pretexts that worked and how they developed them. Eventually they did get caught, which is why these stories are now available.
Example 1: Stanley Mark Rifkin
Stanley Mark Rifkin is credited with one of the biggest bank heists in American history (see a great article about him at www.social-engineer.org/wiki/archives/Hackers/hackers-Mark-Rifkin-Social-Engineer-furtherInfo.htm). Rifkin was a computer geek who ran a computer consulting business out of his small apartment. One of his clients was a company that serviced the computers at Security Pacific Bank. The 55-floor Security Pacific National Bank headquarters in Los Angeles looked like a granite-and-glass fortress. Dark-suited guards roamed the lobby and hidden cameras photographed customers as they made deposits and withdrawals.
This building seemed impenetrable, so how is it that Rifkin walked away with $10.2 million and never held a gun, never touched a dollar, and never held up anyone?
The bank’s wire transfer policies seemed secure. They were authorized by a numerical code that changed daily and was only given out to authorized personnel. It was posted on a wall in a secure room that only “authorized personnel” had access to.
From the archived article mentioned previously:
In October 1978, he visited Security Pacific, where bank employees easily recognized him as a computer worker. He took an elevator to the D-level, where the bank’s wire transfer room was located. A pleasant and friendly young man, he managed to talk his way into the room where the bank’s secret code-of-the-day was posted on the wall. Rifkin memorized the code and left without arousing suspicion.
Soon, bank employees in the transfer room received a phone call from a man who identified himself as Mike Hansen, an employee of the bank’s international division. The man ordered a routine transfer of funds into an account at the Irving Trust Company in New York—and he provided the secret code numbers to authorize the transaction. Nothing about the transfer appeared to be out of the ordinary, and Security Pacific transferred the money to the New York bank. What bank officials did not know was that the man who called himself Mike Hansen was in fact Stanley Rifkin, and he had used the bank’s security code to rob the bank of $10.2 million.
This scenario offers much to talk about, but for now, focus on the pretext. Think about the details of what he had to do:
He had to be confident and comfortable in order to not raise suspicion for being in that room.
He had to have a believable story when he called to do the transfer and have the details to back up his story.
He had to be spontaneous enough to go with the flow with