Deception in Social Engineering

So there’s been a debate going on for awhile (2 years??) over at the Social-Engineer.com podcast over whether or not social engineering always involves some sort of deception.  The latest podcast featured guest Dr. Paul Ekman, pioneer of microexpressions.  After the interview with Dr. Ekman ended, the topic of deception in SE’ing came up again.  This time they have another host, more input,  and I decided I needed to think about this some more and do some reading.  Here are my thoughts on the topic.

tl;dr Yes, social engineering always involves some sort of deception.

So I’ll give an explanation as to why I believe social engineering always involves some sort of deception, then put it into the context of the examples given on the podcast by Jordan and Dave in their attempt to refute this.

Deception is often put into context of situations where something bad happens to the deceived; con men, scammers, etc.  This has given a false impression that deception always involves something bad happening to the deceived.  This is simply not true.  The act of deception is one thing, while the motive (or intent) behind the deception is another.  This separation is fundamental.

Deception is relational, and requires the intent of the deceiver and the expectation of the deceived to label it as such; it is the negative violation of the deceived’s expectation.

There are 5 primary types of deception [1]:

  1. Lies: making up information or giving information that is the opposite or very different from the truth.
  2. Equivocations: making an indirect, ambiguous, or contradictory statement.
  3. Concealments: omitting information that is important or relevant to the given context, or engaging in behavior that helps hide relevant information.
  4. Exaggerations: overstatement or stretching the truth to a degree.
  5. Understatements: minimization or downplaying aspects of the truth.

And there are 3 primary motives [2]:

  1. Partner-focused motives: using deception to avoid hurting the partner, to help the partner to enhance or maintain his/her self-esteem, to avoid worrying the partner, and to protect the partner’s relationship with a third party. Partner-motivated deception can sometimes be viewed as socially polite and relationally beneficial.
  2. Self-focused motives: using deception to enhance or protect their self-image, wanting to shield themselves from anger, embarrassment, or criticism. Self-focused deception is generally perceived as a more serious transgression than partner-focused deception because the deceiver is acting for selfish reasons rather than for the good of the relationship.
  3. Relationship-focused motives: using deception to limit relationship harm by avoiding conflict or relational trauma. Relationally motivated deception can be beneficial to a relationship, and other times it can be harmful by further complicating matters.

Sometime ago, the SE.org crew did a live podcast at Shmoocon in DC.  While they were recording, Johnny Long came by and gave an example he believes shows that SE’ing doesn’t always involve deception.  It goes a little something like this:

You have a guy next to you with bad breath, but you don’t want to tell him he has bad breath.  So instead of telling the guy, you pop a mint into your mouth and then start talking about how awesome they are.  This statement about how awesome they are then has the bad breathed guy asking for a mint.

This is the example that keeps coming up on the podcast.  Johnny Long contended, and Dave continues to argue, that this is not deception because you never lied to the guy.  Chris contends that it is deception because the intent was for him to ask for a mint, not just talk about how tasty they were.

It keeps being argued that it wasn’t deception because the end result was positive.  Again, whether or not it was positive is irrelevant.

  1. The deception contained concealment of information.
  2. The intent was to get the guy to ask for a mint because of his bad breath, but the expectation of the guy was asking for a mint because you said they were delicious.

From here, we can start talking about the motive/intent behind the deception.  In this case the motive was partner-focused.  You didn’t outright tell the man he had bad breath to avoid hurting him, to help him maintain his self-esteem.  While a kind gesture, it was still deception.

Other examples from the podcast:

Jordan’s example: If you’re buying a woman a drink with the intent of sleeping with her, but you don’t express your intentions, is that deceptive?  What if she already knows your intentions?

If her expectation is that your only buying her a drink as a kind gesture and as a conversation starter, then yes it’s deceptive. On the flip side, there’s no way she can absolutely know your intention. But if she expects that you’re buying her a drink with the intent of sexy-time, then it’s not deceptive.

Dave’s example: If Dave gives Chris a hug, what’s his intent?  To make Chris feel uncomfortable. Is the hug deceptive?

From the podcast, Chris said Dave’s intent was to make him feel uncomfortable; Dave agreed.  Therefore the hug is not deceptive.

I also wanted to touch on Jordan’s attempt to differentiate between deception and tricky in the breath mint scenario.  He said that it wasn’t deceptive (his definition of deception involves something prejudicial to the deceived), but that it was maybe tricky instead.  Here’s a screenshot of the definition of “tricky” from dictionary.com:

Some may ask “how is deception ever positive?”  I’d contend that the breath mint scenario is one example.  Everybody on the SE podcast crew agrees that it was a kind gesture.  Deception is often used in romantic relations as well, with the same motive as in the breath mint scenario: to avoid hurting the feelings of the other.

Anyway, this podcast was one of my faves yet.  I’ve been eagerly awaiting for them to have Dr. Paul Ekman on the show and they definitely didn’t disappoint!

I love the podcast, and I like the addition of Jordan to the crew.  Having more perspectives on SE’ing is always welcome! :)

Victory!

I’ve finally picked this high security Brinks padlock I’ve been working at for a few days now!

I’ve always suspected that there were security pins in this lock, but never could tell exactly how many…until I watched the following video:

4 security pins??  I never would’ve guessed four, but knowing that helped a lot.  As well as knowing that the 2nd pin seems to always been the pin stack without the security pin.  So now I gotta re-pin some of my other locks…or get some new ones ;-)

Lockpicking, Waiting for Downloads…

Working at a remote branch, waiting for some downloads to finish, I spent the time lockpicking!  Lockpicking is something I’ve been interested in for awhile, but just recently started picking more.

I don’t have a lot of locks, just things I’ve collected over the years, and a 15 piece lockpick set I bought from LockPickShop.com (11 picks, 4 tension tools).  Off camera, I have a bag with the rest of my locks.  All the locks you see there are the ones I’ve opened while waiting for the download.  I never did get that Brinks open.  One day… haha

I did end up making my first padlock shim though!  I’ve bought shims before, but wanted to go the DIY route after re-watching a Deviant Ollam video.  I found a can in a recycling bin in the lunch room…

If you want to build your own, here’s some instructions Deviant did for i-hacked.com: Beer Can Padlock Shim

Differentiating Between Windows Home and Pro

In planning for an Active Directory network,  I need to figure out how many Windows Home versions there are on our network so I can calculate the costs of upgrades.  From what I’ve gathered in using Nmap’s “-O” option, it will only tell give me results such as “Windows XP” or “Windows 7″; it won’t detail specifically if it’s Home or Pro.  I posted a new thread on EthicalHacker.net (highly recommend this site/forum, by the way) and posted on Twitter to see if there was a way to figure this out remotely so that I didn’t have to visit each machine (if you haven’t also gathered, this process will be helping create an updated database of machines on the network as well).

I got 2 replies back rather quickly on EH-net (thanks dynamik and tturner!): one suggesting to use “psexec systeminfo” and the other using WMIC.  @JGamblin on Twitter also suggested “psexec systeminfo”.  Here’s the psexec and the WMIC suggestions:

psexec systeminfo | findstr /B /C:”OS Name” /C:”OS Version”

wmic /node:machinename /user:username os get | find “Windows Home”

**It was also said that “Windows Home” may not be the exact string in the WMIC query there, but that’s easily tweaked.

I’ve played around with the pstools before so I was a little familiar with them, but didn’t know about the systeminfo command of psexec.  As for WMIC, I’ve never used it, let alone heard of it.  Research and testing time!

I gave both a whirl to check the output and if they’d work given our current network setup.  I found that they both worked, except that given the way both of these methods queried the remote systems, they required valid usernames and passwords on the remote systems…and this would be impossible to do with the way the machines are currently setup: no standard admin account on every machine (something else I know I’m going to have to remedy before implementing AD – it’s on the list).

Not too long after, I got another reply on EH-net (thanks hell_razor!) suggesting an nmap NSE script:

nmap -sS -p 445 –script=smb-os-discovery.nse target_ip

I got varied results with this, but I think it depends on the operating system.  It would show “Home” or “Professional” for Windows Vista or Windows 7 systems, but not when it came to Windows XP.  Regardless, since psexec and WMIC require credentials to get the OS info, I decided to go the nmap NSE script route.

If you couldn’t tell already from the script name (smb-os-discovery), it works by connecting to each system via the SMB protocol over port 445 or 139 using the anonymous account if no account is specified (I just used the anonymous account).   This script retrieves not only the OS, but the company name, domain/workgroup, time on the remote system, etc.  Some good information not just for my purpose here, but also for attackers.

Breaking Down the TCP Idle Scan

I’m currently making my way through “Metasploit: The Penetration Tester’s Guide” (along with a couple other books that’ll be in future posts).  Chapter 3 is about information gathering – the process of gathering intelligence on your target so that you can then devise a method of attack.  In the active information gathering section, it brings up TCP idle scanning using Metasploit and Nmap.  Now I read a blog post on the PaulDotCom website awhile back on TCP idle scanning, but not knowing about this type of scan before reading the blog post, I was a little lost.  Here’s the link to the blog post on the PaulDotCom website:

New IDLE scan sees through your firewall to scan hosts inside your network!

So now that I’ve come across it in the Metasploit book, I decided it was time to read up on it more and have a good understanding before going further into the book.  After all, without good information gathering, you’re going to have issues when it comes to planning attack vectors.

The basic idea behind idle scanning is that you’re able to scan a target without ever sending a packet to the target containing your IP address.  This works by sending forged packets to the target that make it look like it’s coming from another host that is idly standing by (I assume this is where it got its name “idle scan”?).  This idle host is often referred to as a “zombie” host.


Finding your zombie host

Both Nmap and Metasploit are able to automate this process.

But I wanted to know what the process was that’s being automated.  So I started with two things:

  1. Used the “–packet-trace” option when I executed the Nmap command.
  2. Had Wireshark sniffing the traffic while I ran the Nmap command.

The Nmap command I used was:

nmap –packet-trace –script ipidseq –script-args probe-port=80 192.168.1.13

The packet trace portion of the Nmap scan can be seen below:

From this screenshot you can see that the script starts PCAP to capture the replies from the target.  Nmap then sends SYN packets to the target, then PCAP captures the replies for analysis.

Then you get a print out showing the results of said analysis.  In this case, the IP ID sequence is incremental, which is what we’re looking for in a zombie host.  From these screenshots, we’re unable to see what’s being analyzed though.  Because of this, I re-ran the scan, this time running Wireshark at the same time.

The above screenshot shows the result of one SYN packet being sent by Nmap to the target.  You can see the SYN/ACK sent by the target in return, then the attacker sending a RST packet.  What we want to see is in the IP header of the SYN/ACK packet sent by the target to the attacker.

The above image shows the IP identification number of the packet, which is “23546”.  This was the first of six reply packets sent by the target.  If you look at the IP ID of the 5 following packets, they’ll increment by one each time: 23547, 23548, 23549, 23550, and 23551.  When Nmap analyzes these replies, it sees that it increments by one and determines this host is a good candidate for a zombie to be used during an idle scan.

When I read the Metasploit page about its “ipidseq” module, it said that the only difference Nmap’s check and its own implementation was that instead of using SYN/ACK packets for its check, it uses SYN packets.  This confused me as I had just seen that Nmap’s NSE script was using SYN packets.  This led me to jump over to Nmap’s page on it’s idle scan option (-sI).  On this page I read that when you kick off an idle scan, Nmap will test the zombie host before actually doing the scan.  So I ran Nmap again with the packet-trace option, this time just running an idle scan instead of using the NSE ipidseq script.

Mind you, I was on a different network when I took the below screenshot, so the IP’s differ from what you saw in the above screenshots.

As you can see, Nmap does in fact use SYN/ACK packets to probe the zombie host.  This must’ve been what the Metasploit ipidseq module page was referring to, not the NSE ipidseq script.  This is a  good tidbit of information to remember when you’re looking to run an idle scan, just in case your zombie is, or sits behind, a stateful firewall (learned about port scanning – SYN vs SYN/ACK – as it pertains to stateful vs stateless firewalls from watching Fyodor’s DEFCON 16 video).

Now that I know how the process works for finding a zombie host, it’s time to look under the hood to see how the idle scan works.


Executing the idle scan

Now to break down the idle scan as performed by Nmap.  Again, we’ll use Nmap’s handy packet-trace option to see what’s going on.

Open port

  • Attacker: 192.168.100.103
  • Zombie: 192.168.100.111
  • Target: scanme.nmap.org (74.207.244.221)
  • Command: nmap -Pn -p 80 –packet-trace -sI 192.168.100.111 scanme.nmap.org

As you saw in the last screenshot of the previous section, Nmap likes to verify the zombie host to ensure it’s viable.  Nmap sends 6 packets, each time checking the IP ID.  As you can see, the IP ID increments 1 each time from 8650 to 8655.

Then Nmap runs another check, this time checking to make sure the target accepts spoofed packets and that the zombie hosts IP ID’s aren’t changed from host to host.  What you see here is Nmap spoofing packets to the zombie making it look like they’re coming from the target.  If this is a viable zombie, this should increment the zombie’s IP ID another four.  So it should now be 8659.  The attacker then sends another probe to the zombie host, this time not spoofing its source address, to see what it’s IP ID is now causing the zombie host’s IP ID to increment one more.  And looking at the last line in the screenshot, we see that the zombie’s IP ID is now 8660 which is exactly what we wanted to see.  Now Nmap begins the idle scan.

Here you see the attacker spoofs the packet sent to the target to make it look like it’s coming from the zombie.  Then it sends a probe to the zombie host to check it’s IP ID, which in turn will cause the zombie to send a reply and increase its IP ID by one.  In the above screenshot, we see the zombies IP ID is 8662, which is two more than when we checked before.  This tells us the port is open on the target.  How do we know this?  We know that there was communication between the target and zombie before we probed the zombie for its IP ID again.  Since the port was open, the target sent an ACK to the zombie.  And being that this communication from the target was unsolicited, the zombie sent a RST packet; this increased the zombie’s IP ID by one.  So when the attacker probed the zombie again, causing its IP ID to increment one again, we saw the increase as a total of two.  This is the role the zombie host plays in an idle scan.

Closed Port

If the port were closed on the target, our spoofed packet would’ve caused the target to send a RST packet instead of an ACK packet to the zombie.  And instead of the zombie seeing the ACK and sending a RST back to the target, it would’ve seen the RST packet and just ignored it.  Therefore it’s IP ID wouldn’t have increased during this portion.  And when the attacker probed the zombie, it would’ve seen the its IP ID only increased by one, which was caused by the probe itself.

Filtered Port

A filtered port would have the same result from the zombie’s perspective.  But instead of the target sending a RST packet to the zombie, it’d simply ignore it.  Still though, the zombie would never receive a packet from the target, therefore wouldn’t send have it’s IP ID incremented.


Conclusion

And that’s the TCP idle scan!  Seeing Nmap’s packet-trace and Wireshark’s trace file during the idle scan helped me understand what exactly was going on.  I hope this write-up is able to help somebody else as well.  Now to continue on with my Metasploit book!

Standard(?) First Post

Hello World!  Sooo here’s my blog.  Here I will be blogging things pertaining to IT (I’m currently a system/network admin) and infosec (I’m working on getting into an infosec position).  Normally it’ll be things I come across during my studying that I find interesting and worth sharing, a lot will have to do with topics I needed to do more research into.  There will also be posts about solutions I’ve found that were either a pain in the ass to gather all the info for so I’m putting it all in one place, or clever fixes (IMO) I’ve come up with for certain issues I see in my job or study lab at home.  Along with sharing, typing it out in a way that I’m trying to explain/teach the reader, it’ll help embed the info into my brain better and ensure that I understand it thoroughly as well.

So here we go!