NTVDM has an interface called VDD you can use to write virtual device drivers. Basically a Windows DLL loaded into NTVDM.EXE and you can call the DLL from DOS by executing illegal instructions. Often a VDD would have an associated TSR which would provide a more normal interface to DOS programs (based on software interrupts not illegal instructions.)
Microsoft provides some, and third party vendors and open source provides others (the interface is documented in the Windows DDK, or at least it used to be). In particular, Microsoft had one called REDIR which included a bridge between the DOS and Windows NETBIOS APIs. Microsoft used to ship their own Netware client with old versions of Windows and that included another, VWIPXSPX, which similarly bridges the IPX/SPX API from DOS to Windows. Novel’s Netware client for Windows had an equivalent VDD called IPXVDD - https://support.novell.com/techcenter/articles/ana19970501.h...
And see http://netfoss.com/ for a VDD which connects the DOS FOSSIL API (de facto standard for DOS BBS to talk to multiport serial cards) to TCP/IP.
QBASIC doesn’t support any of these APIs, but it can call code written in assembler, and assembler can.
Another option would be to use a virtual serial port driver which makes a TCP/IP port appear as a serial port. QBASIC has built-in support for talking to serial ports. There are a bunch of these, for example https://pcmicro.com/netserial/ or
http://com0com.sourceforge.net/ - it can be done either as a Windows kernel driver (so all Windows apps can access it) or as a VDD (only usable by DOS programs running under NTVDM but a pure user mode solution). Actually, if one uses DOSBox instead of NTVDM it has a serial-to-telnet gateway built in.
So there are lots of ways they could have solved it. Still wondering what they actually did.