Post cover image

September 20, 2026

From Initial Access to Detection: Breaking the Attack Chain

Part 1 — The Offensive Side

By Aruvasaga chithan A

5 min read

Part 1 — The Offensive Side

Breaking In, Then Hunting Myself — Part 1

  1. Introduction — Why I Followed the Entire Attack Chain
  2. The Attack Path
  • Initial Access
  • Credential Discovery
  • Lateral Movement
  • Privilege Escalation
  • Persistence
  • Indicator Removal

3.Reconnaissance — Mapping the Environment

4.Initial Access — Exploiting vsFTPd 2.3.4

5.Upgrading the Shell — From Command Shell to Meterpreter

6.Credential Discovery — Finding a Forgotten Secret

7.Lateral Movement — From Metasploitable2 to Ubuntu

8.Privilege Escalation — Hunting for SUID Binaries

9.Abusing SUID find — From shadowbyte to Root

10.Persistence — SSH Authorized Keys

11.Covering My Tracks — Modifying Bash History

12.Testing Scheduled Persistence — Modifying /etc/crontab

13.What Comes Next — Switching to the Defender's Perspective

From Initial Access to Root: Following an Attack Chain Across Linux Systems

Disclaimer: This walkthrough was performed entirely inside my own isolated VirtualBox lab for security research and purple-team practice. The techniques and credentials shown here are intentionally lab-generated.

Security labs often teach individual techniques.

Exploit this service. Find this credential. Abuse this SUID binary. Create persistence.

But things become much more interesting when those techniques are connected together.

Instead of treating every technique as an isolated exercise, I wanted to follow an attack the way an attacker actually would:

Initial Access → Credential Discovery → Lateral Movement → Privilege Escalation → Persistence → Indicator Removal

So I built an isolated environment and followed the attack chain from the first compromised machine to root access on another system.

The interesting part wasn't just getting root.

It was seeing how much activity I generated along the way.

That became the foundation for Part 2, where I switched perspectives and investigated the same activity from the defensive side using Wazuh.

The Environment

I used an isolated VirtualBox environment containing:

Kali Linux
                   10.0.2.15
                       |
              -------------------
              |        |        |
          Metasploitable2      Ubuntu
           10.0.2.5          10.0.2.6
                               |
                            Wazuh
                             Agent
The systems were connected through a NAT Network.

The objective was straightforward:

Start from the attacker machine, compromise the intentionally vulnerable host, use information discovered there to move to another system, escalate privileges, and establish persistence.

Everything was performed inside my own isolated environment.

1. Mapping the Environment

I started with reconnaissance.

Using Armitage and Nmap, I mapped the systems and services exposed inside the network.

The environment contained several hosts, but two systems became particularly interesting:

  • Metasploitable2 — intentionally vulnerable
  • Ubuntu — the target I wanted to reach and escalate on

The first useful lesson appeared immediately:

Reconnaissance isn't about finding one magic vulnerability. It's about understanding what the environment gives you.

The exposed services determine where the attack can begin.

2. Getting the First Shell

Metasploitable2 was running an old vsFTPd 2.3.4 service.

The service immediately stood out during enumeration.

I used Metasploit's corresponding module:

exploit/unix/ftp/vsftpd_234_backdoor
The target was:
RHOSTS 10.0.2.5
RPORT 21
The service returned:
220 (vsFTPd 2.3.4)
After running the exploit, Metasploit reported a command shell.

I had my first foothold.

None

At this point, I wasn't root on the final target.

I had something more useful:

a foothold from which I could continue the attack.

3. Turning the Shell into Meterpreter

The initial shell was fairly limited.

So I upgraded it using Metasploit's:

post/multi/manage/shell_to_meterpreter

The module established a new Meterpreter session.

[*] Upgrading session: 1
[*] Meterpreter session 2 opened
This wasn’t necessary just to demonstrate exploitation.

I wanted to work with a more capable session for enumeration and post-exploitation.

4. Finding Credentials in an Unexpected Place

Once inside Metasploitable2, I started looking around for useful information.

Eventually I found:

/home/user/shadowbyte/notes.txt

The file contained:
Please remove the notes after using the credentials , admin
The important part was the credential information associated with the shadowbyte account.

This was a deliberately planted credential in my environment, but the lesson is very real:

Credentials don't always come from password dumps or credential-stealing malware.

They can be sitting in:

  • configuration files
  • scripts
  • notes
  • backups
  • command history
  • documentation
  • temporary files

The credential gave me a potential path to another machine.

None

5. Moving to the Ubuntu Machine

During the earlier network enumeration, Ubuntu was identified at:

10.0.2.6
SSH was exposed.

I tested the discovered credential against the system.

This time, it worked.

Success: 'shadowbyte:admin'
I now had an SSH session on Ubuntu as:shadowbyte
The important thing here was that the first compromised machine had effectively become a stepping stone.

The attack had changed from:

External foothold
      ↓
Metasploitable2
to:
Metasploitable2
      ↓
Credentials
      ↓
SSH
      ↓
Ubuntu
That’s lateral movement.

And this is where the attack became much more interesting.

None

6. Looking for a Privilege Escalation Path

I wasn't root.

So I started looking at the privileges available to the shadowbyte account.

One of the first things I checked was SUID binaries:

find / -type f -perm -4000 2>/dev/null
The system returned a number of SUID binaries.

Among them was:

/usr/bin/find
That immediately caught my attention.

A SUID binary executes with the privileges of its owner.

If the owner is root, abusing the binary can potentially result in commands executing with an effective UID of 0.

I checked the available functionality of find and then compared it with the known SUID abuse technique documented by GTFOBins.

None

7. From shadowbyte to Root

Inside the controlled environment, I used:

find . -exec /bin/sh -p \; -quit

The result was the interesting part.

whoami
root

And:
id
showed:
uid=1000(shadowbyte)
gid=1000(shadowbyte)
euid=0(root)
Notice the important detail:

My original UID was still 1000.

But the effective UID was 0.

That distinction matters when you're investigating Linux privilege escalation.

I had crossed the privilege boundary.

None None None

8. Establishing Persistence

Getting root is one thing.

Keeping access is another.

For the persistence portion of the exercise, I tested SSH authorized-key persistence.

I generated a key pair and placed the public key into:

/root/.ssh/authorized_keys
I then tested whether I could authenticate as root using the private key.

The important concept here isn't the specific command.

It's the change in access model:

Password authentication
        ↓
Compromised account
        ↓
Privilege escalation
        ↓
Root SSH key
        ↓
Potential persistent access
This behavior corresponds to SSH Authorized Keys (T1098.004) in MITRE ATT&CK.

9. Trying to Remove My Tracks

At this point, I had achieved most of the offensive objectives.

But there was another question I wanted to answer:

What happens if I try to modify the traces I left behind?

I experimented with .bash_history.

The file was modified as part of the indicator-removal exercise.

I also modified /etc/crontab with a harmless test entry:

* * * * * root echo test
From an attacker’s perspective, these actions can look like attempts to hide activity or maintain execution.

From a defender's perspective, however, they are events worth investigating.

And that difference is exactly what I wanted to explore next.

CONTINUE READING PART -2 ->Click Here

— Written by

Aruvasaga Chithan A

Ethical Hacker & Offensive Security Researcher.

Thanks for reading — your support keeps me writing. See you in the next article…

Linkedin — Github