You should assume that an attacker can observe traffic. This may happen at your network endpoint, at the client's end, or somewhere in between.
On the client side, the attacker will see DNS resolution for random.example.com if he is observing your users, and he may also discover this domain name if he attempts to access to site directly (this second method depends on how tightly you control references/redirects on the main site to the subdomain).
Plus, if you are using certificates for TLS (as you should be), you will have a certificate listing random.example.com, either as the named entity or an alternative name. That will be visible on the wire.
An attacker may be able to browse the DNS zone records in a more direct fashion. As a general rule, you should assume that everything you publish to DNS is available to everyone. If a legitimate client can find the record for that subdomain, so can nefarious users. If you try to hide the subdomain name behind a wildcard record, then the attacker will know the destination IP address regardless.
In the absence of two-factor authentication, a strong password authentication implementation is your primary security. This implies both reasonably complex passwords and a modern hashing algorithm such as scrypt or Argon2. Additional measures would depend on the application and the users. If you can restrict access via firewall, that would be a good step; however, this is only feasible if users can register devices quickly or in advance.
Your question isn't clear if only hardware-based 2FA is excluded. Don't forget about the second-class 2FA options, if permissible. They are better than nothing. If you can transmit a secret to the users out of band via email/text/phone, it is a worthwhile effort.
Alternatively, you could provide a passcode during registration/enrollment, and your site will accept that code to issue a permanent cookie; that cookie can then act as the second factor.
Unfortunately, these methods can be compromised, unlike a hardware 2FA device. Realistically, most sites use nothing more than TLS and a strong password requirement, and they are fine.