In this part, we will focus on network traffic. More often than not, thick client applications have some sort of network connectivity. They talk to some server(s) to do things.
Previous parts are:
Discovering the Endpoints
In part 1 we did some network discovering with Procmon. Now we will do more using both Wireshark and Procmon. IRL use whatever tool you are comfortable with.
We do this because we need to figure out where the application talks to and using what protocol. At your day job, this step is probably the best bang for your buck in terms of the number of vulnerabilities found. Thick client applications are notorious for having inadequate server-side controls and trusting the client too much.
Capturing Loopback Traffic on Windows with Wireshark
Since we have deployed our FTP and MSSQL servers locally, we need to be able to capture local traffic. Windows does not have a real loopback adapter so WinPcap driver (used by Wireshark) cannot do it. The fix is using the npcap driver instead. For more information read https://wiki.wireshark.org/CaptureSetup/Loopback.
Download and install npcap from https://github.com/nmap/npcap/releases and then install Wireshark.
Recon with Wireshark
Run Wireshark, choose
Npcap Loopback Adapter, and the VM's LAN. Then start capturing traffic.
Run the patched application from the previous post but don't do anything.
Fetch Login Token
Click on the
Fetch Login Token button. We already know where it goes, but let's inspect it with Wireshark.
Looking at the capture, it's clear what the application is doing.
- Red: DNS lookup for
- Green: TCP connection to
126.96.36.199). We can see the handshake
- Orange: TLS handshake with
ServerHello, and the rest.
Normal User Login
Clear the capture and this time login with a valid set of non-admin credentials (e.g.
First, we see the TCP connection and then the login traffic to port
49622. To decode the traffic with Wireshark, right-click on any outgoing packet and select
Decode As.... Then select
TDS for the combo box under
Current. This tells Wireshark to decode all traffic to that port using the
And now packets are annotated.
- TLS is not enabled. That's bad.
- SQL queries are created on the client and sent outside. This is ripe for exploitation.
Going through the packets, select the one that says
SQL batch and see the SQL query is created client-side and sent out. Any time you see client-side queries, you should be concerned.
The following query is executed (later we will come back and play with this):
SELECT * FROM users where username='rebecca' and password='rebecca
The response contains the query results which leaks the structure of the
We know administrators can login to the application and backup data to an FTP server. We want to observe this traffic with Wireshark.
Logout and login with
admin:admin123. Note admin interface has only one button,
Backup Data to FTP Server. This should give us the clue that FTP credentials are hardcoded.
Looking at Wireshark, we will see two different streams of traffic:
- Connection to the MSSQL server.
- Connection to the FTP server.
The connection to the MSSQL server is similar to what we have seen before (port
The application connects and runs the following query:
select * from expenses
Next is the FTP connection to
localhost:22. We can see it's in cleartext and user/pass is visible.
For easier visualization, right-click on any packet in the stream and select
Follow > TCP Stream.
Application logins with
dvta:p@ssw0rd and then stores
admin.csv on the FTP server (which we can assume contains information from the
We can also register new users. Users will not be administrators. Let's look at that traffic too.
As we can see, traffic is similar to the previous parts. This time we are sending an
insert into users values('test1','password','email@example.com','0')
0 in the end. It's setting the
isadmin column that we observed earlier.
Recon with Procmon
We can do the same with Sysinternals Procmon. We can see the traffic but we can identify the endpoints. For the record, Procmon does a lot more than what we are using it for.
Quit the application, run it again, login as admin and backup the data. Then run Procmon and set the following filters similar to what we did in part 1 to identify the FTP endpoint:
Process Name contains dvta. I have set this to
containsbecause I have versioned patched executables from part 2.
Operation is TCP Connect. Or you could only enable network activity like part 1 (DVTA - Part 1 - Setup - Discover the FTP Address).
We can see connections to:
- Fetching login token from
- MSSQL server at
- FTP at
54823(ephemeral port for actual
We learned how to identify network endpoints using two tools. We did some limited traffic analysis. In the next part, we will learn how to manipulate traffic in different ways.