Hey everyone, and welcome back to our series, “Linux Basics for Hackers”! I hope youâve got your coffee ready, because we’re about to dive deep into the art of digital reconnaissance.
Picture this: you’ve successfully gained your first foothold on a Linux machine. A command prompt blinks at you, waiting. What’s your next move? If you’re thinking of immediately launching some flashy exploit, hold your horses! The first, and arguably most important, phase of any hack or security audit is information gathering. Acting without knowing the landscape is like walking blindfolded into a maze; you’re more likely to hit a wall than find the prize.
In the Information Gathering in Linux | Part 1, we learned the basics of orienting ourselves. We figured out who we are (whoami, id), the system’s name (hostname), its core identity (uname), and how it talks to the outside world (ifconfig, ip, netstat). We were like tourists getting the general layout of a new city.
Today, we’re graduating from tourists to detectives. đľď¸ââď¸ We’re going to learn how to observe the inhabitants of this digital city, see what they’re up to, and listen in on their conversations. We’ll be mastering a new set of commands: ss, ps, who, and w. These tools are the bread and butter of situational awareness on any Linux system. They separate the script kiddies from the true professionals.
So, let’s get into the nitty-gritty of information gathering in Linux and turn that blinking cursor into a window of opportunity.
ss: The Supersonic Socket Scanner
Remember netstat from our last discussion? Itâs a reliable old tool, like a classic Ambassador car. It gets the job done. But what if you need speed and modern efficiency? Enter ss, which stands for Socket Statistics.
Think of it this way: netstat is like going to the library and looking through a card catalogue to find information. It works, but it takes time. ss gets its information directly from the kernel itself, making it incredibly fast. It’s the equivalent of a super-fast search engine for your system’s network connections. For a hacker who needs to be quick and quiet, ss is the go-to tool.
At its simplest, just typing ss will dump a list of all established connections.
Bash
ss
But the real power lies in its flags. Let’s look at the most useful ones for our purposes.
- -t: Show me only TCP connections.
- -u: You guessed it, show me only UDP connections.
- -l: This one is gold. Show only listening sockets. These are the open doors waiting for a knock.
- -p: Show the process (the application) using the socket. Incredibly useful!
- -n: Display the port as a number instead of trying to resolve its service name (e.g., show
22instead ofssh). This is faster and often clearer. - -a: Show all sockets (both listening and non-listening).
The real magic happens when you combine these flags. One of the most common and powerful combinations you’ll use is:
Bash
ss -tlpn
Let’s break that down: “Show me all (t)TCP sockets that are (l)listening, display their port (n)numbers, and tell me the (p)process that owns them.”
The Hacker’s Perspective on ss
Why is this command so critical? Because every listening service is a potential attack vector. When you run ss -tlpn, you’re essentially getting a list of all the public-facing doors on the system.
Imagine you run the command and see this line in the output:
LISTEN 0 128 0.0.0.0:3306 0.0.0.0:* users:(("mysqld",pid=1234,fd=30))
Bingo! A MySQL database (mysqld) is listening on port 3306 for connections from anywhere (0.0.0.0). This is an immediate point of interest. Is it an old, vulnerable version? Does it use a weak default password? You’ve just found your first potential target without breaking a sweat. You can also spot unusual services on high-numbered ports, which could be custom applications (often less secure) or even a previously planted backdoor.
who & w: Finding Out Who’s Home
Before you start trying to open doors, it’s wise to see who’s already inside the house. Performing noisy actions when the system administrator is actively logged in is a fantastic way to get caught. This is where the who and w commands come in.
who: The Simple Greeting
The who command is straightforward. It tells you who is logged into the system, from which terminal (or IP address), and since when.
Bash
who
The output might look something like this:
user1 pts/0 2025-08-09 14:10 (192.168.1.105)
root tty1 2025-08-09 13:58
This tells us that user1 is logged in remotely from the IP address 192.168.1.105, and root is logged in directly on the machine’s console (tty1).
A couple of handy flags for who:
who -b: Tells you the time of the last system boot. Good for knowing how long the system has been up.who am i: This gives you information specifically about your own session.
w: The Nosy Supervisor
The w command is like who on steroids. It gives you all the same information, but adds some incredibly valuable context: what each user is currently doing.
If who tells you that John is in the office, w tells you that John is in the office and is currently running a performance review of his team. See the difference? đ
Let’s run w:
Bash
w
The output has more columns:
- USER: The username.
- TTY: The terminal they’re using.
- FROM: Where they logged in from.
- LOGIN@: The time they logged in.
- IDLE: How long the user has been inactive. This is crucial! A long idle time means they’re likely away from their keyboard.
- JCPU: Time used by all processes attached to their TTY.
- PCPU: Time used by their current process.
- WHAT: The jackpot. The exact command they are currently running.
The Hacker’s Perspective on who and w
These commands are fundamental for stealth.
- Are you alone? If you see
rootor anadminuser is actively logged in (low idle time), you need to be extremely careful. Maybe you should wait until they log off. - Opportunity Knocks: If a user has a high
IDLEtime, it’s a much safer window to perform actions that might generate logs or alerts, like trying to escalate your privileges. - Spying on Activity: The
WHATcolumn is a goldmine. Is the admin editing a configuration file withvim /etc/nginx/nginx.conf? You now know they’re working on the web server. Are they running a custom script like/usr/local/bin/backup.sh? Perhaps that script has a vulnerability you can exploit or contains sensitive information.
Seeing sudo -i as the WHAT command for an admin tells you they have an active root shell. Tread very, very carefully.
ps: Spying on Every Process
If the operating system is a bustling company, then processes are the employees, each one performing a specific task. The ps (Process Status) command is your all-access pass to the company directory and activity log. It lets you see every single task running on the system.
This is perhaps one of the most powerful information-gathering tools at your disposal. You’ll often hear about two main “styles” of using ps, and it’s good to know both.
The Two Flavors of ps
- BSD Style (
ps aux): This is very popular and easy to remember.a: Show processes for all users.u: Display in a user-oriented format.x: Show processes not attached to a terminal (like background services or daemons).
- System V Style (
ps -ef): This style is excellent for seeing the relationships between processes.-e: Show every single process.-f: Display in full-format, which includes the parent process ID.
Bash
# BSD Style
ps aux
# System V Style
ps -ef
While ps aux is great, I personally lean towards ps -ef because of one key piece of information it provides: the PPID (Parent Process ID). This tells you which process started the one you’re looking at, allowing you to trace a process’s origin. For example, you can see that the bash shell (your command prompt) was started by the sshd process, which handled your SSH login.
The Hacker’s Perspective on ps
The ps command is your primary tool for mapping out the software landscape of the target machine. You’re not just looking for processes; you’re hunting for opportunities.
- Finding the Crown Jewels: The first thing you’ll do is look for processes running with high privileges.Bash
ps -ef | grep rootAny process running asrootis a prime target. If you can find a vulnerability in one of them, you can potentially take full control of the system. - Identifying Vulnerable Services: Are they running an outdated web server or database?Bash
ps aux | grep apache ps aux | grep nginx ps aux | grep mysqlFinding a process forapache2tells you it’s a web server. Your next step would be to find out its version and check for public exploits. - Detecting Defenses:
pscan also reveal the system’s defenses. Do you see processes likeclamd(ClamAV antivirus),snort(Intrusion Detection System), oraide(Advanced Intrusion Detection Environment)? Seeing these tells you that you’re not on an unprotected system and you’ll need to employ techniques to bypass them. - Confirming Your Payload: After you’ve run an exploit, how do you know if it worked? You use
psto look for your reverse shell or payload process. If you don’t see it running, something went wrong.
Tying It All Together: From Login to Target
Let’s walk through a quick, practical scenario to see how these commands flow together to create a clear intelligence picture.
- You gain access as a low-privilege user,
www-data. - First, you run
wto see who else is on the box. You see a user namedbobis logged in, but hisIDLEtime is over2h(2 hours). Good, he’s probably not at his desk. - Next, you run ps -ef. You pipe it to less so you can scroll through it (ps -ef | less). As you scroll, you spot a process that looks interesting:bob 1782 1 0 14:15 ? 00:00:01 python3 /home/bob/dev/webapp.py
- Aha! The user
bobis running a custom Python web application from his home directory. Custom apps are often a great source of vulnerabilities. - Now you’re curious about this app. You run ss -tlpn to see if it’s listening on a network port. You find this line:LISTEN 0 80 0.0.0.0:5000 0.0.0.0:* users:((“python3”,pid=1782,fd=3))
- Perfect. The PID
1782matches the process you found withps. The application is listening on port5000.
In just a few commands, you’ve gone from a blind shell to identifying a specific, high-potential target: a custom Python app running as user bob on port 5000. Now your attack becomes focused and intelligent.
What’s Next?
We’ve now covered how to inspect the system’s identity, its network posture, its active users, and its running processes. You have a powerful toolkit for building a comprehensive understanding of a target’s software environment.
But what about the hardware? What physical and virtual devices are attached? In the next part of our series, weâll get our hands dirty with the machine’s physical and block-level components. We’ll explore commands like lsblk (list block devices), lsusb (list USB devices), lspci (list PCI devices), and the incredibly powerful lsof (list open files). Think of it as moving from looking at the city’s inhabitants to examining the city’s actual blueprints and infrastructure.
Stay curious, keep practicing these commands, and I’ll see you in the next one!
FAQs
1. What’s the main difference between ss and netstat?
The biggest difference is speed. ss gets its information directly from the kernel’s TCP/IP stack, while the older netstat command needs to parse files in the /proc filesystem. This makes ss significantly faster and more efficient, especially on systems with many connections.
2. How can I find the process that’s using a specific port?
This is a classic use case. Combine ss or lsof. For example, to find what’s using port 80: ss -tlpn | grep :80
Or using lsof:lsof -i :80
3. What’s the difference between ps aux and ps -ef? Which one should I use?
They show similar information but in different formats. ps aux (BSD style) is user-centric. ps -ef (System V style) is process-centric and clearly shows the parent-child relationship (PID and PPID), which is very useful for tracing a process’s origin. Many veterans prefer ps -ef for its detailed, structured output, but both are valid. It often comes down to personal preference.
4. How can I see all processes run by a specific user?
You can use the -u flag with ps. For example, to see all processes being run by the user bob: ps -u bob
5. Why is information gathering so important in ethical hacking?
Information gathering is the foundation of every successful engagement. Without it, you are attacking blindly. It helps you identify potential vulnerabilities, understand the system’s defenses, choose the right exploit for the right service, and remain stealthy by knowing who is active on the system. A thorough recon phase dramatically increases your chances of success.
6. Can these commands be detected by the system administrator?
Yes, potentially. If the system has advanced auditing tools (auditd) or command-line logging enabled, a vigilant administrator can see every command you run. This is why stealth is key. Running standard system commands like ps and ss is less suspicious than running obvious hacking tools, but a long history of these commands from an unexpected user account can still raise red flags.
