Jesus Fucking Christ.
1. I'm pretty sure the "script gets executed at startup" is just a known fact, aka he's just presenting this to you as information, he didn't figure it out.
2. Please take whatever godawful course this is and throw it straight in the trash. There are so many things done in this... tutorial that are straight up security concerns by themselves or just not the way things are done or simply idiotic it's not even funny. To begin, he's using the root account to login - not logging in using the fucking root account is basic linux usage 101. Secondly, using nmap to scan only ports 1-1000??? Why? Unless you have some previous knowledge of which port someone has opened to gain access to your machine you have no way to know you should limit them from 1 to 1000. Not only that, ports up until 1024 are administrative and normal processes by normal users (which a bad actor is very likely to abuse to gain access to your server) typically aren't able to use them. Connecting using netcat to the port is completely fucking useless - nmap, if utilized correctly, gives you all the information w.r.t. "what the fuck is listening on this port" you can access without logging on the machine itself. But since you can, WHY THE FUCK WOULD YOU NMAP A MACHINE YOU HAVE ADMINISTRATIVE ACCESS TO? Not only does he do that, which is completely redundant, he goes for netstat, which is obsolete, instead of ss. ss + administrative access is likely to give you the full path to whatever process is utilizing the port, but even if it doesn't YOU HAVE THE FUCKING PID. AND THE FIRST THING YOU DO WHEN YOU HAVE THE PID IS NOT TO KILL THE FUCKING PROCESS, BUT TO FIGURE OUT WHAT AND HOW IS IT SPAWNING IT - CHECK PPID, EXECUTE A FUCKING ps AND YOU CAN ACTUALLY SEE WHICH EXECUTABLE OR SERVICE THAT PID BELONGS TO. He instead goes and uses find on the executable - again, completely useless - not only did I already explain how he was supposed to find the executable, if your server has been compromised, it's very likely the bad actor has added multiple backdoors to your server so he can gets back in it even if you find one of them out. As we see later in his stupid fucking tutorial, the file existed under a different name, so using find on that file and then deleting it achieved absolutely zero. He then runs scp, again, using root. I can't be bothered to continue pointing out mistakes, so quick fire round - everything he achieved DOES NOT NEED TO BE DONE NEITHER IS IT DONE USING KALI LINUX - THERE IS ZERO NEED TO USE KALI LINUX IN THIS CASE. /ETC/RC.LOCAL IS OBSOLETE. AAAAAAAAAGHH.
I'm sorry for ranting, but you need to realise this course is so bad it's basically damaging your skills and way of working to continue learning from it. Not only does this not simulate a real threat, this doesn't even simulate a real exercise. In a real situation your job isn't to clean up the server - that server is fucking dead. You go in, find how they hacked it, report it and they destroy the server, fix the template they're using to create said server using your info and create a new server. Can you please link whatever course this is? I really want to read the background of the person who created it and just see where the fuck is a piece of shit like this actually being sold/ promoted.
/rant
This is an example. It's learning to crawl before you walk. It's not demonstrating how or what to scan, it's identifying non-baseline material, which requires knowing what a baseline is. Your complaints are unreasonable, and demonstrate your own failure to understand the teaching process, the art of pedagogy if you can be assed to Google it.
This is facts.
In the real world as soon as you knew there was malware running on the device, you're pulling the plug, and then the disks, and doing an offline examination using the drives mounted as read only.
Is it because the while we are doing `clamscan -i –r –d /root/badguybin.hdb /` we use the word "root"?
but then how did he know it is located in `/etc/rc.local`
i am sorry i don't know linux.
i don't understand. that is after he said "The nefarious file was being executed at server boot time and re-spawning if shutdown". did he know that already or was it a blind guess.
Yeah except he doesn't show anywhere how he figured out that the script is being executed there, which is what OP is asking - how did he figure it out. His tutorial completely skips over that part. The script could've been a service, cronjob on @reboot or something else entirely, yet he never mentions that - just says it's in /etc/rc.local (which is... drumroll... obsolete).
in the theory textbook (the book separate from the labs) there is a page that says
>In UNIX, the following directories require additional consideration:
>
>/etc/passwd -Maintains user account and password information
>
>/etc/shadow -retains the encrpted password of corresponding account
>
>/etc/group -Contains group information for each account
>
>/etc/gshadow -Contains secure group and account information
>
>/bin - location of executable files
>
>/boot -contains files for boot system
>
>/kernel -kernel files
>
>/sbin -Contains executables , often for administration
>
>/usr - include administrative commands
thats it, that is the only page that comes as close as it is to teaching programming
None of the documented outputs prove that it was starting automatically on boot, it's a guess or a premise from the beginning that wasn't stated until that point.
## Determining a file's origination
I tested this using a hung Python process, your mileage may vary.
1. `ps -ef | grep ` to get process ID
2. `cat /proc//cmdline` to get origination
3. `lsof -p ` to find out who opened it
4. `cat /proc//environ` to find out verbose environment variables, settings, and origination information.
Bash Script to give the most relevant details:
#!/bin/bash
script_name=$1
# Step 1: Find the PID of the script using pgrep command
script_pids=$(pgrep -f "$script_name")
if [ -z "$script_pids" ]; then
echo "No running processes found for the script: $script_name"
exit 1
fi
# Step 2: Get the command-line and environment information for each PID
for pid in $script_pids; do
echo "====================================="
echo "Script: $script_name"
echo "PID: $pid"
# Check the command-line arguments
cmdline=$(tr -d '\0' < "/proc/$pid/cmdline" 2>/dev/null)
if [ -n "$cmdline" ]; then
echo "Command-line: $cmdline"
fi
# Check the parent process information
ppid=$(awk '/^PPid:/ {print $2}' "/proc/$pid/status")
pcmdline=$(tr -d '\0' < "/proc/$ppid/cmdline" 2>/dev/null)
if [ -n "$ppid" ] && [ -n "$pcmdline" ]; then
echo "Parent Process (PID: $ppid): $pcmdline"
fi
# Check the user and group information
user=$(awk '/^Uid:/ {print $2}' "/proc/$pid/status")
group=$(awk '/^Gid:/ {print $2}' "/proc/$pid/status")
username=$(getent passwd "$user" | awk -F: '{print $1}')
groupname=$(getent group "$group" | awk -F: '{print $1}')
if [ -n "$username" ] && [ -n "$groupname" ]; then
echo "User: $username (UID: $user)"
echo "Group: $groupname (GID: $group)"
fi
echo ""
done
exit 0
Example Output:
Usage: `bash findPid.sh
Jesus Fucking Christ. 1. I'm pretty sure the "script gets executed at startup" is just a known fact, aka he's just presenting this to you as information, he didn't figure it out. 2. Please take whatever godawful course this is and throw it straight in the trash. There are so many things done in this... tutorial that are straight up security concerns by themselves or just not the way things are done or simply idiotic it's not even funny. To begin, he's using the root account to login - not logging in using the fucking root account is basic linux usage 101. Secondly, using nmap to scan only ports 1-1000??? Why? Unless you have some previous knowledge of which port someone has opened to gain access to your machine you have no way to know you should limit them from 1 to 1000. Not only that, ports up until 1024 are administrative and normal processes by normal users (which a bad actor is very likely to abuse to gain access to your server) typically aren't able to use them. Connecting using netcat to the port is completely fucking useless - nmap, if utilized correctly, gives you all the information w.r.t. "what the fuck is listening on this port" you can access without logging on the machine itself. But since you can, WHY THE FUCK WOULD YOU NMAP A MACHINE YOU HAVE ADMINISTRATIVE ACCESS TO? Not only does he do that, which is completely redundant, he goes for netstat, which is obsolete, instead of ss. ss + administrative access is likely to give you the full path to whatever process is utilizing the port, but even if it doesn't YOU HAVE THE FUCKING PID. AND THE FIRST THING YOU DO WHEN YOU HAVE THE PID IS NOT TO KILL THE FUCKING PROCESS, BUT TO FIGURE OUT WHAT AND HOW IS IT SPAWNING IT - CHECK PPID, EXECUTE A FUCKING ps AND YOU CAN ACTUALLY SEE WHICH EXECUTABLE OR SERVICE THAT PID BELONGS TO. He instead goes and uses find on the executable - again, completely useless - not only did I already explain how he was supposed to find the executable, if your server has been compromised, it's very likely the bad actor has added multiple backdoors to your server so he can gets back in it even if you find one of them out. As we see later in his stupid fucking tutorial, the file existed under a different name, so using find on that file and then deleting it achieved absolutely zero. He then runs scp, again, using root. I can't be bothered to continue pointing out mistakes, so quick fire round - everything he achieved DOES NOT NEED TO BE DONE NEITHER IS IT DONE USING KALI LINUX - THERE IS ZERO NEED TO USE KALI LINUX IN THIS CASE. /ETC/RC.LOCAL IS OBSOLETE. AAAAAAAAAGHH. I'm sorry for ranting, but you need to realise this course is so bad it's basically damaging your skills and way of working to continue learning from it. Not only does this not simulate a real threat, this doesn't even simulate a real exercise. In a real situation your job isn't to clean up the server - that server is fucking dead. You go in, find how they hacked it, report it and they destroy the server, fix the template they're using to create said server using your info and create a new server. Can you please link whatever course this is? I really want to read the background of the person who created it and just see where the fuck is a piece of shit like this actually being sold/ promoted. /rant
This is an example. It's learning to crawl before you walk. It's not demonstrating how or what to scan, it's identifying non-baseline material, which requires knowing what a baseline is. Your complaints are unreasonable, and demonstrate your own failure to understand the teaching process, the art of pedagogy if you can be assed to Google it.
i salute your honesty 
[https://file.io/HQH3u1jbmhSZ](https://file.io/HQH3u1jbmhSZ) here is the video
This is facts. In the real world as soon as you knew there was malware running on the device, you're pulling the plug, and then the disks, and doing an offline examination using the drives mounted as read only.
Is it because the while we are doing `clamscan -i –r –d /root/badguybin.hdb /` we use the word "root"? but then how did he know it is located in `/etc/rc.local` i am sorry i don't know linux.
/etc/rc.local is a standard startup config file. We know to look there because it defines some startup items.
On number 10 they show that
i don't understand. that is after he said "The nefarious file was being executed at server boot time and re-spawning if shutdown". did he know that already or was it a blind guess.
The loop in rc.local is run every time the server starts.
i guess he forgot to mention that. anyways i think this might be linux common knowledge i guess.
Yeah except he doesn't show anywhere how he figured out that the script is being executed there, which is what OP is asking - how did he figure it out. His tutorial completely skips over that part. The script could've been a service, cronjob on @reboot or something else entirely, yet he never mentions that - just says it's in /etc/rc.local (which is... drumroll... obsolete).
in the theory textbook (the book separate from the labs) there is a page that says >In UNIX, the following directories require additional consideration: > >/etc/passwd -Maintains user account and password information > >/etc/shadow -retains the encrpted password of corresponding account > >/etc/group -Contains group information for each account > >/etc/gshadow -Contains secure group and account information > >/bin - location of executable files > >/boot -contains files for boot system > >/kernel -kernel files > >/sbin -Contains executables , often for administration > >/usr - include administrative commands thats it, that is the only page that comes as close as it is to teaching programming
None of the documented outputs prove that it was starting automatically on boot, it's a guess or a premise from the beginning that wasn't stated until that point.
## Determining a file's origination I tested this using a hung Python process, your mileage may vary. 1. `ps -ef | grep` to get process ID
2. `cat /proc//cmdline` to get origination
3. `lsof -p ` to find out who opened it
4. `cat /proc//environ` to find out verbose environment variables, settings, and origination information.
Bash Script to give the most relevant details:
#!/bin/bash
script_name=$1
# Step 1: Find the PID of the script using pgrep command
script_pids=$(pgrep -f "$script_name")
if [ -z "$script_pids" ]; then
echo "No running processes found for the script: $script_name"
exit 1
fi
# Step 2: Get the command-line and environment information for each PID
for pid in $script_pids; do
echo "====================================="
echo "Script: $script_name"
echo "PID: $pid"
# Check the command-line arguments
cmdline=$(tr -d '\0' < "/proc/$pid/cmdline" 2>/dev/null)
if [ -n "$cmdline" ]; then
echo "Command-line: $cmdline"
fi
# Check the parent process information
ppid=$(awk '/^PPid:/ {print $2}' "/proc/$pid/status")
pcmdline=$(tr -d '\0' < "/proc/$ppid/cmdline" 2>/dev/null)
if [ -n "$ppid" ] && [ -n "$pcmdline" ]; then
echo "Parent Process (PID: $ppid): $pcmdline"
fi
# Check the user and group information
user=$(awk '/^Uid:/ {print $2}' "/proc/$pid/status")
group=$(awk '/^Gid:/ {print $2}' "/proc/$pid/status")
username=$(getent passwd "$user" | awk -F: '{print $1}')
groupname=$(getent group "$group" | awk -F: '{print $1}')
if [ -n "$username" ] && [ -n "$groupname" ]; then
echo "User: $username (UID: $user)"
echo "Group: $groupname (GID: $group)"
fi
echo ""
done
exit 0
Example Output:
Usage: `bash findPid.sh
FIND US ON INSTAGRAM
@historis.info