Lab 08: Performing Social Engineering Attacks

Overview

This lab simulated a social engineering attack against a fictional organization, drisst.org, in an isolated lab environment. I gathered employee details, sent a spoofed spear phishing email to capture credentials, and used a malicious payload to gain access to a workstation and then a firewall. I finished by recommending email and browser changes that would help defend against these attacks.

Objectives

  • Gather target information from a public website

  • Craft and send a spear phishing email from a spoofed address

  • Capture credentials through a fake login page

  • Deliver a payload and establish a remote session

  • Recommend defenses against spoofed email and lookalike domains

Tools and Technologies

  • Social-Engineer Toolkit (SET)

  • Metasploit Framework (hta_server exploit, Meterpreter)

  • OWASP Juice Shop (XSS delivery)

  • PuTTYgen and SSH

  • Kali Linux

  • Firefox configuration settings

Lab Writeup

Reconnaissance and Phishing Setup

  • Collected employee names and email addresses from the company’s About Us page, then chose a sender and a target

  • Tested the fake login page with test credentials and confirmed they appeared in the capture log

Spear Phishing

  • Used SET to send a single targeted email, spoofing one employee’s address to another employee

  • Wrote a short message about an upcoming product presentation, with a link to the fake login page, so that it looked like routine internal communication

  • Captured the target’s username and password when they submitted the form

Payload Delivery and Exploitation

  • Prepared a Meterpreter reverse TCP payload using the Metasploit hta_server exploit, hosted as JuicerClient.hta

  • Performed an XSS attack on the Juice Shop as part of delivering the payload

  • Received a Meterpreter session and confirmed the compromised user with getuid (DRISST\fsmith)

  • Converted the user’s PuTTY key to OpenSSH format with PuTTYgen

  • Logged in to the pfSense firewall over SSH with that key, moving from one user’s workstation to network infrastructure

Challenge: Defensive Recommendations

Email authentication for drisst.org

  • SPF (Sender Policy Framework): lists the servers allowed to send mail for the domain, so that receivers can reject mail from other servers

  • DKIM (DomainKeys Identified Mail): signs messages with a private key, which helps prevent forgery and proves that messages weren’t altered

  • DMARC (Domain-based Message Authentication, Reporting, and Conformance): requires SPF or DKIM to pass and align with the visible From domain, tells receivers how to handle failures, and sends reports to the domain owner

  • Recommended settings: publish SPF with -all, sign mail with DKIM, set DMARC to p=reject; sp=reject with rua reporting, and enable all three checks on the receiving mail server

Punycode display in Firefox

Setting network.IDN_show_punycode to true in about:config makes the address bar show the raw xn-- form of a domain, which helps expose lookalike domains that use Unicode characters.

Key Findings

  • Publicly listed names and email addresses give attackers what they need to write a convincing message

  • A short, ordinary-sounding email from a known colleague can be enough to capture credentials

  • The lab’s mail server accepted forged mail because it wasn’t checking sender authentication

  • One compromised user can lead to access to critical infrastructure when their keys provide that access

  • Technical controls such as SPF, DKIM, and DMARC reduce how much the organization depends on users spotting a phish

Key Skills Learned

  • Using public information to plan a targeted attack

  • Running a spear phishing campaign with SET

  • Handling Metasploit exploits and Meterpreter sessions

  • Using SSH keys to move from a workstation to another system

  • Translating an attack into clear defensive recommendations

Topics Covered

  • Social engineering and spear phishing

  • Email spoofing and credential harvesting

  • Client-side attacks and payload delivery

  • Lateral movement

  • Email authentication (SPF, DKIM, DMARC)

  • Homograph attacks and Punycode

Conclusion

This lab showed how an attacker can chain public information, a single convincing email, and a client-side payload into access to critical systems. It also reinforced that strong defenses have to combine technical controls with user awareness, since people are often the easiest way in.

Lab File