Week 3: Exploring Backdoors and Social Engineering

What was this week about?

This week was mainly focused on family, since I’m on vacation. Because of family commitments—and spending the last two days debugging BEEF—I made less progress than in the past two weeks. Next week is also going to stay the same due to family commitments because for me, being on vacation means getting minimal access to my laptop and I assure you that this rule is not made by me but my parents. But as they say, slow progress is still progress.

That said, I did learn about real-world threats like fake URLs and Trojans. It’s surprising how easily attackers can trick users through social engineering alone. One of my goals with this particular blog is to show you how these attacks work and how you can reduce your chances of falling victim to them.

This Week’s Goals:

• Made progress in my course (~130 minutes of content completed).

• Conducted a social engineering simulation, with myself playing both the attacker and the target, to better understand how malicious URLs can be used in real-world attacks.
  As part of this experiment, I created a custom link that, when clicked, simulated how an attacker might attempt to access a device’s webcam.
  (Note: This was done entirely in a controlled and safe environment for educational purposes.)

What I learned this week:

• How to use Fatrat to generate backdoors:

  This week, I explored TheFatRat—an advanced tool used to generate backdoor payloads for penetration testing. It's often considered more effective than msfvenom due to a higher chance of bypassing antivirus software.

  I tested the generated payload on a Windows virtual machine. Interestingly, Windows Defender didn’t flag the file during download, but immediately detected and blocked it upon execution. This highlighted how some AV solutions rely more on behavioral detection at runtime than just signature-based scanning.

  

• How to make Trojans:

  As part of a simulated test, I generated a backdoor using msfvenom and disguised it with a .jpeg filename to reduce suspicion—an example of how attackers may try to trick users into executing malicious files that appear harmless.

  I acted as both the attacker and the target in this simulation. On my Kali Linux virtual machine, I launched msfconsole and set up a listener to wait for the target (my Windows VM) to execute the file. The idea was to simulate a common phishing tactic: tricking a user into running a backdoor by disguising it as an image file.

  In a real-world scenario, one way to detect this kind of attack is to check if a file claiming to be an image actually ends in .exe or another executable extension. Also, keeping built-in security features like Windows Defender enabled is crucial—they're often effective at detecting threats like this.

  In fact, during my test, Windows Defender immediately flagged and blocked the payload when I tried to download it. For educational purposes, I temporarily disabled Virus & Threat Protection in my isolated VM to observe the payload behavior in a controlled setting.

• How to Use Stormbreaker (Ethical Simulation of Social Engineering Attacks):

  I also explored Stormbreaker, a tool designed to demonstrate how attackers can use fake URLs to simulate data collection—like accessing location or webcam feeds. The goal of this test was to better understand how social engineering attacks work, so I can help raise awareness about them.

  Here’s how I set it up:

  • I ran Stormbreaker in one terminal and Ngrok, a secure tunneling service, in another.

  • Ngrok provided a public-facing URL which linked to the Stormbreaker dashboard.

  • Through this interface, I was able to simulate phishing-style pages that could (with permission) request webcam access—highlighting just how easy it is to fool someone into giving up private information.

Challenges I faced:

This week came with a few frustrating (and slightly funny) technical issues.

• I was unable to start Stormbreaker. Ironically, just like what happened with Bettercap last week, I was able to run it perfectly the day before—but not the next day.

• I was also unable to run BeEF, and this issue dragged on for two full days. Since I needed BeEF to move forward with my planned experiments, this really slowed me down.

How I solved the problems:

• Looking back… the Stormbreaker issue was kind of embarrassing. The tool wasn’t starting simply because I wasn’t connected to the internet.

As for BeEF, the problem was that I hadn’t installed (or updated) the necessary Ruby gems. Once I took care of that, everything started working as expected.

Next week’s goals:

• Complete at least 100 minutes of course content

• Use beef to implement website hacking

• Learn more about social media security

Finishing up:

Even with a few hiccups this week, my passion for this project hasn’t faded at all. If anything, these challenges are helping me learn faster and understand the real-world obstacles cybersecurity professionals face every day.

Thanks for following along—and as always, stay safe and secure on the internet!

Disclaimer:

This blog documents my personal journey in learning ethical hacking and cybersecurity with the intent to build responsible AI tools for penetration testing and system defense.

All experiments are conducted in isolated lab environments on virtual machines I own or control. This project is strictly for educational and ethical purposes.

I do not condone or promote any form of unauthorized or illegal access to systems.