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_serverexploit, 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_serverexploit, hosted asJuicerClient.htaPerformed 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 top=reject; sp=rejectwithruareporting, 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.