Find process source which executing python scripts [on hold]











up vote
-2
down vote

favorite












From last month some process is executing python scripts on my server with centos 6 with LAMP stack which are nothing but spam bots and eating server resources. Please check image below,



htop screenshot



How do I find what exactly executing these python scripts?










share|improve this question









New contributor




chaladi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











put on hold as too broad by Jeff Schaller, Stephen Harris, G-Man, RalfFriedl, msp9011 2 days ago


Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.











  • 1




    pstree -p should help you track down where it's coming from.
    – Haxiel
    Dec 5 at 19:04






  • 1




    You should be more concerned that you have unknown processes running as root. unix.stackexchange.com/questions/428721/…
    – Kusalananda
    Dec 5 at 21:13















up vote
-2
down vote

favorite












From last month some process is executing python scripts on my server with centos 6 with LAMP stack which are nothing but spam bots and eating server resources. Please check image below,



htop screenshot



How do I find what exactly executing these python scripts?










share|improve this question









New contributor




chaladi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











put on hold as too broad by Jeff Schaller, Stephen Harris, G-Man, RalfFriedl, msp9011 2 days ago


Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.











  • 1




    pstree -p should help you track down where it's coming from.
    – Haxiel
    Dec 5 at 19:04






  • 1




    You should be more concerned that you have unknown processes running as root. unix.stackexchange.com/questions/428721/…
    – Kusalananda
    Dec 5 at 21:13













up vote
-2
down vote

favorite









up vote
-2
down vote

favorite











From last month some process is executing python scripts on my server with centos 6 with LAMP stack which are nothing but spam bots and eating server resources. Please check image below,



htop screenshot



How do I find what exactly executing these python scripts?










share|improve this question









New contributor




chaladi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











From last month some process is executing python scripts on my server with centos 6 with LAMP stack which are nothing but spam bots and eating server resources. Please check image below,



htop screenshot



How do I find what exactly executing these python scripts?







centos process python cpu






share|improve this question









New contributor




chaladi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




chaladi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited Dec 5 at 19:29









Rui F Ribeiro

38.4k1479128




38.4k1479128






New contributor




chaladi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked Dec 5 at 18:57









chaladi

971




971




New contributor




chaladi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





chaladi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






chaladi is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




put on hold as too broad by Jeff Schaller, Stephen Harris, G-Man, RalfFriedl, msp9011 2 days ago


Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.






put on hold as too broad by Jeff Schaller, Stephen Harris, G-Man, RalfFriedl, msp9011 2 days ago


Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.










  • 1




    pstree -p should help you track down where it's coming from.
    – Haxiel
    Dec 5 at 19:04






  • 1




    You should be more concerned that you have unknown processes running as root. unix.stackexchange.com/questions/428721/…
    – Kusalananda
    Dec 5 at 21:13














  • 1




    pstree -p should help you track down where it's coming from.
    – Haxiel
    Dec 5 at 19:04






  • 1




    You should be more concerned that you have unknown processes running as root. unix.stackexchange.com/questions/428721/…
    – Kusalananda
    Dec 5 at 21:13








1




1




pstree -p should help you track down where it's coming from.
– Haxiel
Dec 5 at 19:04




pstree -p should help you track down where it's coming from.
– Haxiel
Dec 5 at 19:04




1




1




You should be more concerned that you have unknown processes running as root. unix.stackexchange.com/questions/428721/…
– Kusalananda
Dec 5 at 21:13




You should be more concerned that you have unknown processes running as root. unix.stackexchange.com/questions/428721/…
– Kusalananda
Dec 5 at 21:13










1 Answer
1






active

oldest

votes

















up vote
0
down vote













Instead of the htop picture, please post the text output of pstree -p and/or ps axfuw in your question if you need help finding the source process. Text output is preferable to pictures.



These processes are running as root user, and they appear to be downloading and executing perl scripts through the python script x.py. There is also a bash script go running as root.



The following is not a specific answer to your question, but hopefully some helpful information about hacks with this type of privilege.



You could attempt to find all of those scripts and see if deleting them helps, making sure to also kill all the bad processes, but since this system is "rooted" you could spend a great deal of time investigating the entire server and may never clear out all of the possible hacks/backdoors. A big issue with root level hacks is that they would have access to alter anything they want, changing configurations, replacing any of your software binaries or editing/clearing log files. You should be able to check your package manager if they messed with any files installed from packages.



More important would be to determine how the hacks started in the first place, or you could find that your next server gets compromised in the same way. This could range from "obvious" to "extremely difficult to determine" depending on how well you understand your system. Since we can see the processes are running as the root user, some possibilities are: the root user is compromised (they know the password), a sudo user is compromised, an exposed service is allowing remote execution, or there is a possibility of a privilege escalation exploit (lower chance of this if you keep your system up-to-date).



One thing you could try is to find all of the malicious scripts (find / -name x.py) and determine the earliest creation time of those files. Then check if the creation time matches any logins to your system from locations you do not recognize, that would indicate they knew the password and were able to login to your system. Otherwise it is an exercise in determining what services you are running on your system with that kind of access and do they have any vulnerabilities that would allow running commands as root.



Once your are done investigating, I would advise you save all the data that is important to you and then reinstall the server with a fresh operating system and do not reuse any of the passwords that were used on the previous system. Using backups (hopefully those are elsewhere and did not get hacked) on the fresh system would be preferable to reloading the previous data.






share|improve this answer




























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    0
    down vote













    Instead of the htop picture, please post the text output of pstree -p and/or ps axfuw in your question if you need help finding the source process. Text output is preferable to pictures.



    These processes are running as root user, and they appear to be downloading and executing perl scripts through the python script x.py. There is also a bash script go running as root.



    The following is not a specific answer to your question, but hopefully some helpful information about hacks with this type of privilege.



    You could attempt to find all of those scripts and see if deleting them helps, making sure to also kill all the bad processes, but since this system is "rooted" you could spend a great deal of time investigating the entire server and may never clear out all of the possible hacks/backdoors. A big issue with root level hacks is that they would have access to alter anything they want, changing configurations, replacing any of your software binaries or editing/clearing log files. You should be able to check your package manager if they messed with any files installed from packages.



    More important would be to determine how the hacks started in the first place, or you could find that your next server gets compromised in the same way. This could range from "obvious" to "extremely difficult to determine" depending on how well you understand your system. Since we can see the processes are running as the root user, some possibilities are: the root user is compromised (they know the password), a sudo user is compromised, an exposed service is allowing remote execution, or there is a possibility of a privilege escalation exploit (lower chance of this if you keep your system up-to-date).



    One thing you could try is to find all of the malicious scripts (find / -name x.py) and determine the earliest creation time of those files. Then check if the creation time matches any logins to your system from locations you do not recognize, that would indicate they knew the password and were able to login to your system. Otherwise it is an exercise in determining what services you are running on your system with that kind of access and do they have any vulnerabilities that would allow running commands as root.



    Once your are done investigating, I would advise you save all the data that is important to you and then reinstall the server with a fresh operating system and do not reuse any of the passwords that were used on the previous system. Using backups (hopefully those are elsewhere and did not get hacked) on the fresh system would be preferable to reloading the previous data.






    share|improve this answer

























      up vote
      0
      down vote













      Instead of the htop picture, please post the text output of pstree -p and/or ps axfuw in your question if you need help finding the source process. Text output is preferable to pictures.



      These processes are running as root user, and they appear to be downloading and executing perl scripts through the python script x.py. There is also a bash script go running as root.



      The following is not a specific answer to your question, but hopefully some helpful information about hacks with this type of privilege.



      You could attempt to find all of those scripts and see if deleting them helps, making sure to also kill all the bad processes, but since this system is "rooted" you could spend a great deal of time investigating the entire server and may never clear out all of the possible hacks/backdoors. A big issue with root level hacks is that they would have access to alter anything they want, changing configurations, replacing any of your software binaries or editing/clearing log files. You should be able to check your package manager if they messed with any files installed from packages.



      More important would be to determine how the hacks started in the first place, or you could find that your next server gets compromised in the same way. This could range from "obvious" to "extremely difficult to determine" depending on how well you understand your system. Since we can see the processes are running as the root user, some possibilities are: the root user is compromised (they know the password), a sudo user is compromised, an exposed service is allowing remote execution, or there is a possibility of a privilege escalation exploit (lower chance of this if you keep your system up-to-date).



      One thing you could try is to find all of the malicious scripts (find / -name x.py) and determine the earliest creation time of those files. Then check if the creation time matches any logins to your system from locations you do not recognize, that would indicate they knew the password and were able to login to your system. Otherwise it is an exercise in determining what services you are running on your system with that kind of access and do they have any vulnerabilities that would allow running commands as root.



      Once your are done investigating, I would advise you save all the data that is important to you and then reinstall the server with a fresh operating system and do not reuse any of the passwords that were used on the previous system. Using backups (hopefully those are elsewhere and did not get hacked) on the fresh system would be preferable to reloading the previous data.






      share|improve this answer























        up vote
        0
        down vote










        up vote
        0
        down vote









        Instead of the htop picture, please post the text output of pstree -p and/or ps axfuw in your question if you need help finding the source process. Text output is preferable to pictures.



        These processes are running as root user, and they appear to be downloading and executing perl scripts through the python script x.py. There is also a bash script go running as root.



        The following is not a specific answer to your question, but hopefully some helpful information about hacks with this type of privilege.



        You could attempt to find all of those scripts and see if deleting them helps, making sure to also kill all the bad processes, but since this system is "rooted" you could spend a great deal of time investigating the entire server and may never clear out all of the possible hacks/backdoors. A big issue with root level hacks is that they would have access to alter anything they want, changing configurations, replacing any of your software binaries or editing/clearing log files. You should be able to check your package manager if they messed with any files installed from packages.



        More important would be to determine how the hacks started in the first place, or you could find that your next server gets compromised in the same way. This could range from "obvious" to "extremely difficult to determine" depending on how well you understand your system. Since we can see the processes are running as the root user, some possibilities are: the root user is compromised (they know the password), a sudo user is compromised, an exposed service is allowing remote execution, or there is a possibility of a privilege escalation exploit (lower chance of this if you keep your system up-to-date).



        One thing you could try is to find all of the malicious scripts (find / -name x.py) and determine the earliest creation time of those files. Then check if the creation time matches any logins to your system from locations you do not recognize, that would indicate they knew the password and were able to login to your system. Otherwise it is an exercise in determining what services you are running on your system with that kind of access and do they have any vulnerabilities that would allow running commands as root.



        Once your are done investigating, I would advise you save all the data that is important to you and then reinstall the server with a fresh operating system and do not reuse any of the passwords that were used on the previous system. Using backups (hopefully those are elsewhere and did not get hacked) on the fresh system would be preferable to reloading the previous data.






        share|improve this answer












        Instead of the htop picture, please post the text output of pstree -p and/or ps axfuw in your question if you need help finding the source process. Text output is preferable to pictures.



        These processes are running as root user, and they appear to be downloading and executing perl scripts through the python script x.py. There is also a bash script go running as root.



        The following is not a specific answer to your question, but hopefully some helpful information about hacks with this type of privilege.



        You could attempt to find all of those scripts and see if deleting them helps, making sure to also kill all the bad processes, but since this system is "rooted" you could spend a great deal of time investigating the entire server and may never clear out all of the possible hacks/backdoors. A big issue with root level hacks is that they would have access to alter anything they want, changing configurations, replacing any of your software binaries or editing/clearing log files. You should be able to check your package manager if they messed with any files installed from packages.



        More important would be to determine how the hacks started in the first place, or you could find that your next server gets compromised in the same way. This could range from "obvious" to "extremely difficult to determine" depending on how well you understand your system. Since we can see the processes are running as the root user, some possibilities are: the root user is compromised (they know the password), a sudo user is compromised, an exposed service is allowing remote execution, or there is a possibility of a privilege escalation exploit (lower chance of this if you keep your system up-to-date).



        One thing you could try is to find all of the malicious scripts (find / -name x.py) and determine the earliest creation time of those files. Then check if the creation time matches any logins to your system from locations you do not recognize, that would indicate they knew the password and were able to login to your system. Otherwise it is an exercise in determining what services you are running on your system with that kind of access and do they have any vulnerabilities that would allow running commands as root.



        Once your are done investigating, I would advise you save all the data that is important to you and then reinstall the server with a fresh operating system and do not reuse any of the passwords that were used on the previous system. Using backups (hopefully those are elsewhere and did not get hacked) on the fresh system would be preferable to reloading the previous data.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Dec 5 at 20:25









        GracefulRestart

        1,05927




        1,05927















            Popular posts from this blog

            Accessing regular linux commands in Huawei's Dopra Linux

            Can't connect RFCOMM socket: Host is down

            Kernel panic - not syncing: Fatal Exception in Interrupt