HyperServer tagged by Microsoft Defender for using TOR

[davidizadar]

I am currently using HyperServer in an Azure virtual machine with every available Microsoft Security tool, among them, Microsoft Defender.

Defender is detecting HyperServer making encrypted TOR-like request to a remote server, which appears as a potential security risk.
Analyzing the report, it looks like a validation of the license. If that is the case, I could ignore that destination (80.94.95.40).
Please, confirm that I am right... The alternative could be a Trojan attached to HyperServer (service).
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See https://docs.db.ripe.net/terms-conditions.html

% Note: this output has been filtered.
%       To receive output for a database update, use the "-B" flag.

% Information related to '80.94.95.0 - 80.94.95.255'
 

[Farshad Mohajeri]

Hi David

Hyperserver never makes outbound requests to a remote server unless it's configured as a cluster master with slave Hyperserver instances at fixed ip addresses. 

[Farshad Mohajeri]

BTW, is it clear that source of this remote call is Hyperserver.exe ? Are you using exe or Dll form of Hyperserver ?

Thanks 

[Farshad Mohajeri]

Another note :

Hyperserver or unigui don't make calls to validate the license. It is only done during the installation. 

[davidizadar]

I am using the HyperServer service and a Windows executable (until we switch to Linux/Ubuntu).
 

[3896] hyper_service.exe established

Outbound connection from 192.168.0.4:443 to 80.94.95.40:47324

If that is the case, I will check my application, because it uses some components that could be checking for licenses or worse.

[davidizadar]

This IP block appears to belong to a real registered network, but there are several caution flags.

What the record says

• IP Range: 80.94.95.0/24

• Company: UNMANAGED LTD

• Country: United Kingdom

• ASN: AS204428

• Address listed: Rushden, England

• Created in RIPE: 2024 allocation update (company object older)

Interpretation

This is not a fake WHOIS entry. It is a valid RIPE-assigned network block.

However:

Caution Signs

1. Name: “UNMANAGED LTD”
   This often suggests unmanaged hosting/VPS services where customers rent servers with little oversight.

2. Abuse Contact shown as @bunea.eu
   That is unusual. A mismatch between company name and abuse domain can indicate outsourced management or a messy setup.

3. Recently modified allocations
   Sometimes newer smaller providers or resellers rotate ranges frequently.

4. Hosting IP vs residential/business IP
   If someone contacted you from this IP, it is likely from a server/VPS/datacenter, not a normal home user.

Is it reputable?

If using for:

• Basic VPS hosting → Possibly legitimate

• Email sending → Higher spam risk

• Financial/security login source → Suspicious until verified

• Random website visitor → Neutral

• Scam caller / suspicious email → Red flag

My honest assessment

Legitimate registered network, but not premium-tier reputation.
More like small hosting / reseller / VPS infrastructure. I would treat traffic from it cautiously.

If you tell me the exact IP + what happened (email login alert, website visitor, scam call, server attack, etc.), I can give a much sharper risk assessment.

[Farshad Mohajeri]

7 minutes ago, davidizadar said:

I am using the HyperServer service and a Windows executable (until we switch to Linux/Ubuntu).
 

[3896] hyper_service.exe established

Outbound connection from 192.168.0.4:443 to 80.94.95.40:47324

If that is the case, I will check my application, because it uses some components that could be checking for licenses or worse.

hyper_server.exe is pre-compiled by us. So source of this call can't be your application. Otherwise your own EXE would be marked by defender.

[davidizadar]

According to ChatGPT:

If:

• Your software does not intentionally use Tor
• HyperServer does not use it
• Yet hyper_service.exe initiated the connection

then you should assume one of these until disproven:

Highest Probability Causes

1. Binary tampering / replacement
   • hyper_service.exe modified after deployment
2. DLL side-loading / dependency hijack
   • Legit EXE loads malicious DLL from local folder
3. Process injection
   • Another process injected code into hyper_service.exe
4. Supply-chain contamination
   • Build machine infected before compile/package
5. Compromised server used as persistence host

[davidizadar]

I believe the issue could be with some of the DLLs used by our program or HyperServer (OpenSSL or similar).
If no one else reported this issue, it is something I should solve.
I will let you know the results of my research.

Thanks,

David

[Farshad Mohajeri]

Please check if "hyper_server.exe" is intact using file comparison.