Practical combat-industry attack and defense emergency response

Synopsis:

Server Scenario Operating System Ubuntu
Server account password: root/security123
Analyzing traffic packets in /home/security/
The relevant jar packages are in /home/security/ruoyi/.

Emergency Host: 192.168.0.211
Gateway: 192.168.0.1/24
Other puppet machines: within paragraph

The environment from an industry attack and defense of the real environment, you can refer to the above article link, said very clearly, WP + process + emergency response steps + attack steps have been written, fit the reality of the actual combat + competition environment, do not let go of every detail points
Full simulation, please do not use the tool to carry out illegal external attacks, violators will be responsible for the consequences!

1、According to the traffic packet analysis the first IP for scanning attack is

Answer: flag {192.168.0.223}

Known attacked ip 192.168.0.211 , we filter with the filter == 192.168.0.211, see suspected port probing behavior

Then filter it through a strainer. == 192.168.0.211 && == 192.168.0.223 && == 1You can see that there are more than 60,000 port probes.

Then we check the http packet, found that there is also directory scanning behavior, scanning the two ports 9988 and 12333, we go back to the host with netstat to check the external web service open to the public is precisely these two ports

‍

2, according to the traffic packet analysis of the second scanning attack IP and leakage scanning tool to flag

Answer: flag{192.168.0.200&Acunetix}

Filter Filtration == 192.168.0.211 && != 192.168.0.223 && == 1, found that ip192.168.0.200 has a scanning behavior for two web services

Filter http packets from 192.168.0.200 with the filter == 192.168.0.211 && == 192.168.0.200 && httpThe web scanner Acunetix, or AWVS, can be seen as a regular web scanner with the characteristics of the scanner.

‍

3、Submit the IP of frequent key bursting and the number of times of bursting to flag{ip&times}.

Answer: flag{192.168.0.226&1068}

Filter Filtration == 192.168.0.211 && != 192.168.0.200 && != 192.168.0.211You can see that IP 192.168.0.226 has been requesting port 12333, and the url is /login, which can be assumed to be the ip of the blasting key.

Filter Filtration == 192.168.0.211 && == 192.168.0.226If you trace the http stream, you can see that the first request is to determine the existence of the shiro framework, and the subsequent requests are to blast the key.

Filter Filtration == 192.168.0.211 && == 192.168.0.226 && == "/login", a total of 1071 times, removing the handshake and session of the initial request 3 times, for a total of 1068 bursts of the shiro key

‍

4. Submit the key that was successfully utilized by the attacker with flag {xxxxx}

Answer: flag{c+3hFGPjbgzGdrC+MHgoRQ==}

Filter Screening == 192.168.0.211&&!=192.168.0.223&&!=192.168.0.200&&!=192.168.0.226You can see that 192.168.0.242 starts off by blasting the key

Filter Screening == 192.168.0.211 && ==192.168.0.242After the unsuccessful key blasting, the attacker visited /actuator/heapdump to download the headdump and analyze it to obtain the key for subsequent attacks.

We can analyze the jar package and find the key in the src/classes/ directory in the source code

Of course, from the attacker's point of view, if the key is dynamic, we can also download the heapdump, use the relevant tools to extract the key, here I use theJDumpSpider

‍

5, submit the weak password of all services obtained by the attacker, more than one to & submit, such as flag

Answer: flag{ruoyi123&admin123&123456}

Not in the traffic, it can be found in the heapdump

‍

6, according to the emergency response method, submitted to exploit the vulnerability of successful ports, multiple to & connection, such as: flag

Answer: flag{9988&12333}

The ports known to be open to the public are ports 22, 9988, and 12333, with port 22 being a remote connection.9988The port was preempted by192.168.0.223Perform port scanning and file scanning, being192.168.0.200Scanning using AWVS was192.168.0.242Visit and download heapdump for subsequent utilization. And port 12333 is the frame built by Ruoyi, scanned and blasted by the previous IP, the last step in the192.168.0.242This IP gets the shiro key

‍

7、According to the traffic packet analysis, submit the attacker using the key to detect the successful dnslog address

Answer: flag{}

Attackers who utilize key probing successfully will generally test to see if the machine is out of the network, often utilizing dnslog for testing, filter screening == 192.168.0.211 && dnsIf you exclude the normal dns address, you can find the address of the dnslog.

‍

8. According to the traffic packet analysis, submit the address and port of the attacker's bouncing shell with flag {&port}

Answer: flag{192.168.0.251:8888}

We continue to filter the ip to get the correct key, because the attack is wakui framework, go to the http protocol, we filter http protocol, filter syntax == 192.168.0.211 && == 192.168.0.242 && httpI'm borrowing this.chain-Aiju Big Brother's diagram to illustrate a shiro deserialization attack

Here we can reverse the flow from bottom to top to decrypt, because the previous bursting key, bursting construction chain, etc. many times, from top to bottom to find a bad location

Here's the command base64 decoded to see the address and port of the bounce shell

‍

9, the attacker placed in the host fscan (has been renamed), after scanning to take down an eternal blue vulnerability host, as a clue to submit the fscan absolute path

Answer: flag{/opt/.f/.s/.c/.a/.n}

Filter Filtration==192.168.0.211 && ==192.168.0.251 && ==8888, locating bouncing shell traffic

Because of taking down an Eternal Blue vulnerability host, we directly search for MS17-010, and fscan execution will generate the file by default

grep -rl 'MS17-010' / 2>/dev/null # Filter by keywords

You can see the path out, but why is it also in the traffic package? Let's see what chain-aiju master said:In the TCP/IP protocol, the session needs to go through three handshakes and four waves, and the traffic packets exist because of SYN, and there is plaintext traffic in the ACK packets

Filter Filtrationip.dst192.168.0.211&&ip.src192.168.0.251 && ==8888 && == 1 && == 1The following is a list of the packets that will be filtered according to the flags and then viewed in the clear text.

‍

10. Alternative method: submit the MD5 value of this fscan tool with flag {xxxxxx}

Answer: flag{b8053bcd04ce9d7d19c7f36830a9f26b}

Q: What if he deleted the file, how do you fuzzy search? This is a new question from china-aiju master, a new angle to locate fscan directories, using md5 values (tool md5sum)

List the md5 of the executable, output it to a file, and then compare fscan's md5

find / -type f -executable -exec md5sum {} \; >

‍

11, the attacker in order to maintain permissions, placed in the host simulation of remote control tools, need to submit the download address of this remote control tool to flag

Answer: flag{:12345/}

We can continue to see the download address in the traffic

But how do we find out from the host side? By troubleshooting the scheduled tasks can be seen, you can see that every ten minutes to execute . If you look at this file, you can see that it is executed every ten minutes.

‍

12, the attacker knows that you will find this way, so it creates a related script, using other methods to download, submit the absolute path of the script

Answer: flag{/home/security/upload/.CCC/.}

In addition to scheduled tasks, linux also has a troubleshooting item boot, we can view through the systemctl, his execution file path in /etc/systemd/system/, to create the task is to locate the file name through this directory to create the task name, the use of the following commands can be in accordance with the last change in the time of the sort, from the bottom to the top to look at the suspicious files

ls -l --time-style=long-iso /etc/systemd/system/ | sort -k 6,7

Here's one that's obviously not a system startup item, so let's check it out to find the path

‍

13. The attacker creates a hidden user, submits this user's username, submits it as flag {xxxx}

Answer: flag{xj1zhoudi@kali}

cat /etc/passwd |grep bash

This command only sees two users with login privileges, then looks at the /.ssh directory of the loggable user and looks at the public key file, and sees the suspicious username in /root/.ssh/.id_rsa.pub

You can actually see the download of this public key file in the traffic of the bounce shell as well

‍

PS: This question is recorded by china-Aizhou master in a real battle, penetration part explains the hacker's attack ideas, you can go to the public number to see, the link is here:/s/2eYZGnDaD6M0sdrIVPhbhQ

‍