The story goes like this. On the first day of the New Year, the customer reported that their server could not be accessed. Checking the route, they found that the UDP traffic of an oracle+tomcat server was too large and the bandwidth was used up. During the Chinese New Year, the customer first contacted the local technical staff to get it. I haven't done it for a few days, and then there is no way to find us on the third day of the Lunar New Year...Customers are God!
Actually, I have encountered this kind of attack before. At that time, an IDC was beaten to paralysis, but the horse was not on our device, so I didn’t pay much attention...
0×01 Find Trojan Horse
First SSH login, top view the process, find the strange name command gejfhzthbp, I feel that there is a problem at first glance.
lsof–cgejfhzthbp
Check the associated file, find the external tcp connection, I don’t know if it’s a reverse shell...
Excuting an order
Whereisgejfhzthbp ls-algejfhzthbp
Check the file path. And check the file creation time, which coincides with the invasion time.
By the way, copy the files and put them in the kali virtual machine to try the power. The results in a few seconds are as follows...
I thought it was done by a foreigner before. This should prove that it was done by a Chinese...
0×02 resume business
First kill the process, the result is definitely not that simple, the process is renamed again
I tried many processes in the middle, ps -ef |grep found that the parent process is different every time, the associated process is sometimes sshd, sometimes pwd, ls, a VNC connection is installed in the middle, and then the ssh service is closed. The same is invalid, and several kills Later, it was discovered that the parent process became 1, and the level was limited. The production server should be treated conservatively, and business-oriented...
Now that someone has been invaded, first turn off the firewall's SSH mapping. After all, the server still needs to be used, so let’s write a few iptables rules.
iptables-AOUTPUT-olo-jACCEPT
Allow this machine to access this machine
iptables-AOUTPUT-mstate--stateESTABLISHED-jACCEPT
Requests to allow active access to this server
iptables-AOUTPUT–ptcp–d192.168.1.235-jACCEPT
IP whitelist that allows the server to actively access
iptables-ADROP
Denied external access
At this point, the business has returned to normal.
0×03 Find the reason
In fact, the reason I realized from the beginning was the SSH problem. I just need to help people restore the business. The web port only has tomcat. The web vulnerabilities have been checked. What struts2, manager pages, and some regular web Vulnerabilities will not exist, unless there is 0day... Oracle is not connected externally, only SSH
Based on this, I directly checked the root account ssh login log, flipped through it, and finally...
cd/var/loglesssecure
As shown in the picture above, the Indonesian IP blasting was successful, but the login of the server's intranet IP turned out to fail. I asked the customer and understood what was going on. They added equipment at the end of the year and temporarily changed the weak password for the server to facilitate various third-party technicians. After debugging, I guess I forgot to change it back. The result was a tragedy. I was logged in by a bad guy. The root password was changed and I couldn’t get on the board... I don’t know if their boss knew...
Continue to check the history file to see what others have done.
The operation process of the bad guy is basically here, he has executed a lot of scripts, who knows how much he did, I suggest the customer to reinstall the system...
0×04 postscript
The main reason is that I have little experience, I am unfamiliar with Linux operation and maintenance, and I don't know how to drive the horse out completely... Don't spray the bull.
Ningbo Autrends International Trade Co.,Ltd. , https://www.vapee-cigarettes.com