Delphi CE application accesses unknown IPs

[everybyte 7]

Hello there,

 

I compile an application in Delphi CE that explicitly accesses only localhost  using TNetHTTPRequest.Get method.

However a test by VirusTotal.com reveals that application accesses a bunch of unknown IP addresses:

 

IP Traffic
192.229.211.108:80 (TCP)
20.99.184.37:443 (TCP)
20.99.185.48:443 (TCP)
20.99.186.246:443 (TCP)
209.197.3.8:80 (TCP)
23.216.147.64:443 (TCP)

 

What could be the reason for this?

 

 

[DelphiUdIT 176]

Checking some of these IPs, you notice that they transit under "edgecastcdn.net", "msn.net" and "hwcdn.net".
The first is a digital content provider (belongs to the owner of the Yahoo group), msn.net is known, hwcdn.net is the Windows update network and access is very often related to activities with Edge.

 

I don't know the reasons because i never used TNetHttp and I don't know nothing about it (except the it exists).

Edited August 24, 2023 by DelphiUdIT

[Fr0sT.Brutal 900]

Probably it's some activity from WinInet. But IDK how you get connections from Virustotal, just run a sniffer and then your app to make sure what's going on

[everybyte 7]

VirusTotal.com has a BEHAVIOR tab where application is tested for network access among other things.

If strange IP access is from WinInet then it is kind of "legal" trojan behavior.

[Patrick PREMARTIN 69]

If it's in your program (executed without debug mode), nothing else the IP you try to GET should be called. Are you sure the problem come from TNetHTTPClient ?

[Fr0sT.Brutal 900]

On 8/26/2023 at 9:43 AM, everybyte said:

VirusTotal.com has a BEHAVIOR tab where application is tested for network access among other things.

Why believe 3rd party, just check it yourself locally. You also can run Wireshark and see what exactly is sent

[everybyte 7]

A simple console application (compiled in Delphi CE 10.4) that does a single console WriteLn when checked in virustotal.com sandbox is seen accessing three IP addresses:

 

192.229.211.108:80 (TCP)                       Edgecast Networks

20.99.184.37:443 (TCP)                           Computer Sciences Corporation

a83f:8110:0:0:100:0:1800:0:53 (UDP)      This network is not allocated. This object is here for Database consistency and to allow hierarchical authorisation checks.

 

 

[rvk 33]

1 hour ago, everybyte said:

A simple console application (compiled in Delphi CE 10.4) that does a single console WriteLn when checked in virustotal.com sandbox is seen accessing three IP addresses:

The real question is: Does the program REALLY access those IPs?

 

It could be that virustotal just analyses the code and sees some unreachable code that could access those IPs. Maybe it's never called.

 

The only way to be sure is to check it yourself (as mentioned before).

 

[Kas Ob. 121]

14 hours ago, everybyte said:

A simple console application (compiled in Delphi CE 10.4) that does a single console WriteLn when checked in virustotal.com sandbox is seen accessing three IP addresses:

 

192.229.211.108:80 (TCP)                       Edgecast Networks

20.99.184.37:443 (TCP)                           Computer Sciences Corporation

a83f:8110:0:0:100:0:1800:0:53 (UDP)      This network is not allocated. This object is here for Database consistency and to allow hierarchical authorisation checks.

The UDP one is most likely secured DNS connection, the others are some shitty AV/Security software you have installed, check its settings and you will find that you are allowing to send samples from your PC, and that shit is literally sending everything to its server, every single new EXE that is not in their DB.

 

And please share with us the name of this great tool.

[Nigel Thomas 35]

9 hours ago, Kas Ob. said:

And please share with us the name of this great tool.

Windows Defender. Or at least that's my guess, as those IPs are listed in the Microsoft Sysinternals sandbox running at V/T (not running on the OP's system).

Edited November 15, 2023 by Nigel Thomas
clarifying

[DelphiUdIT 176]

Virus Total use virtual environment to test  the application, so is possible (may be sure) that some DLL of Windows environment call Internet location to do something (think about SmartScreen that search for information about executable).

 

So, that is not a Issue (and Virus Total list only one of many antivirus engine to exploit that).

 

Bye

[mvanrijnen 123]

You can check this also with procmon: Process Monitor - Sysinternals | Microsoft Learn

 

as said, i'm gonna check this now 🙂  (private laptop i have CE installed, will do the same tomorrow with the Enterprise edition).

 

procmon does not detect any network connectivity

simple console app:

(and just for fun i attached the ip trace from procmon, running bds-> start project1 -> close bds)

 

 

Virustotal result:  

Link: VirusTotal - File - 956317d6f12af53a4c97db41807e9dd51fd37c30057607cecb969fc9214ccb99

Scanning:

Bkav Pro  W32.AIDetectMalware RisingTrojan.Generic@AI.100 (RDML:gihstO5MCnK0eVlOewg5Rw)
SecureAgeMalicious  VBA32  TScope.Trojan.Delf
 

IP Traffic

When executing the file being studied, it generated the following IP traffic.

• 192.229.211.108:80 (TCP)
• 20.99.184.37:443 (TCP)

 

program Project1;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils;

begin
  try
    try
      Writeln;
      Writeln('This is just a test');
    except
      on E: Exception do
        Writeln(E.ClassName, ': ', E.Message);
    end;
  finally
    Writeln;
    Write('press enter...');
    Readln;
  end;
end.

bds ip trace.txt

Edited November 15, 2023 by mvanrijnen

[everybyte 7]

@mvanrijnen:

 

  Thanks for suggestion about Process Monitor, but it did not reveal suspicious activity as reported by VirusTotal.

I also tried Fiddler, which is capable of monitoring per application, but it only seems to support HTTP and HTTPS.

Trying to find anything with Wireshark.

[everybyte 7]

On 11/15/2023 at 10:07 PM, DelphiUdIT said:

Virus Total use virtual environment to test  the application, so is possible (may be sure) that some DLL of Windows environment call Internet location to do something (think about SmartScreen that search for information about executable).

 

So, that is not a Issue (and Virus Total list only one of many antivirus engine to exploit that).

 

Bye

It is an issue in the sense that advanced users suspect a nefarious activity in your application.

[Nigel Thomas 35]

3 hours ago, everybyte said:

It is an issue in the sense that advanced users suspect a nefarious activity in your application. 

Really? Here's the VirusTotal Sysinternals Sandbox report for network activity from a scan of the Windows 10 x64 C:\Windows\regedit.exe: (not an application you'd expect to be accessing external IP addresses)

 

IP Traffic
23.216.147.64:443 (TCP)
23.216.147.76:443 (TCP)
a83f:8110:0:0:100:0:1800:0:53 (UDP)
a83f:8110:1800:0:0:0:0:0:53 (UDP)

 

Perhaps rather more worrying for your "Advanced" Users, if they see those IP addresses from a seemingly benign Microsoft application?

 

If your Advanced Users are paranoid enough to be concerned about the Sysinternals Sandbox report, point them to the other sandbox reports for your app which do not show any network connectivity.

 

Nigel

Edited November 17, 2023 by Nigel Thomas

[dummzeuch 1505]

"23.216.147.64 - It belongs to Akamai, which is a company Microsoft uses to manage traffic to their servers. In the Sysinternals report, something crashed ("WER"="Windows Error Reporting") and the report just catches Windows preparing a report to Microsoft."

 

That's from Reddit, but there are multiple other sources.

[mvanrijnen 123]

45 minutes ago, dummzeuch said:

"23.216.147.64 - It belongs to Akamai, which is a company Microsoft uses to manage traffic to their servers. In the Sysinternals report, something crashed ("WER"="Windows Error Reporting") and the report just catches Windows preparing a report to Microsoft."

 

That's from Reddit, but there are multiple other sources.

Ah see, little bit strange that a site as virustotal does not take this to consideration or report it with the found ip's.

 

 

[DelphiUdIT 176]

10 hours ago, everybyte said:

It is an issue in the sense that advanced users suspect a nefarious activity in your application.

 

1 minute ago, mvanrijnen said:

Ah see, little bit strange that a site as virustotal does not take this to consideration or report it with the found ip's.

 

Virus Total "simply" report what append to all environment when the software run. What the SO does is not under control or analyzed from VT. I think the you can send how many applications you want to Virus Total and all of them will be signaled for those "issue".

 

All the IP calls don't come from the software but from the common environment loaded, one hundred DLLs or more? Windows makes many IP calls for a multitude of needs, so this should not be a "meter" to measures an issue.

[Kas Ob. 121]

10 hours ago, Nigel Thomas said:

Really? Here's the VirusTotal Sysinternals Sandbox report for network activity from a scan of the Windows 10 x64 C:\Windows\regedit.exe: (not an application you'd expect to be accessing external IP addresses)

 

IP Traffic
23.216.147.64:443 (TCP)
23.216.147.76:443 (TCP)
a83f:8110:0:0:100:0:1800:0:53 (UDP)
a83f:8110:1800:0:0:0:0:0:53 (UDP)

Just to clear few things here, 

 

1) All binaries that runs on Windows will go through some sort of security check, although it can be disabled or adjusted by policy editor or registry but it is not recommended.

2) All Signed files (binaries or not like cab or msi..) with certificates that have CRL (Certificate Revocation List) extension will and must be checked against the provided URL in that CRL, unless it is disabled by policy, this check happen with intervals defined and provided by the CRL server and the OS will remember to check again when you run or access that file, CRL extension is not the only one that cause such checking online but there is also the OCSP, and there is other extensions and services but less popular.

3) These checks and connections appears from the EXE but they are coming from OS DLL loaded forcibly by the OS into the memory.

4) If a file not signed it will not check for any certificates of course, but here will kick the installed security software if it is Windows Defender or else, every single one of them have an option/setting to send samples for unknown software (singed or not) to there servers for deep analysis, some of these are enabled by default, as mentioned above it could be Microsoft Defender that issuing such connections, yet and it is important find IPs to Akamai or Microsoft doesn't mean it is Windows service, it could be an 3rd party software that using Azure or Akamai CDN ....

5) almost every application will crash on these sandboxes in VirusTotal, and as these Sandboxes with Windows on default settings or may be aggressive security settings, will generate WER report and will try to send it to Microsoft, hence these extra connections.

 

 

So back to regedit.exe, it is signed and that sandbox most likely will revert to its default with each run, and each time will try to update its Root or at least the CA store, on other hand regedit have GUI and most likely will crash too and generate a report and use the WER, as evidently reported. 

[Brian Evans 105]

Note the VirusTotal sandbox uses Sysmon - Sysinternals | Microsoft Learn which logs various events based on actions done by anything not just the executable itself like Process Monitor - Sysinternals | Microsoft Learn does.  

[everybyte 7]

A console "Hello World" application compiled in Delphi 7 shows the same access pattern in VirusTotal.com test (IPv6 UDP address is different).

I consider at this point that IP access behavior is an artifact of a testing environment.

[everybyte 7]

2 hours ago, Brian Evans said:

Note the VirusTotal sandbox uses Sysmon - Sysinternals | Microsoft Learn which logs various events based on actions done by anything not just the executable itself like Process Monitor - Sysinternals | Microsoft Learn does.  

Funny that SysMon64.exe could not start in Windows 11 - there was a just screen flash.

When opening UAC stated that the app is from an unknown publisher although in properties it is actually properly signed.

[Kas Ob. 121]

8 minutes ago, everybyte said:

When opening UAC stated that the app is from an unknown publisher although in properties it is actually properly signed.

This might means your trusted root store is outdated, or there is missing trusted CA from Microsoft.

 

But i just downloaded the latest SysMon and CA is still valid till 2026, while it is 2011 issue.

 

I think your have more troubles than what you think, the security policy on your Windows 11 is in dire need to reset to default.

[everybyte 7]

1 hour ago, Kas Ob. said:

This might means your trusted root store is outdated, or there is missing trusted CA from Microsoft.

 

But i just downloaded the latest SysMon and CA is still valid till 2026, while it is 2011 issue.

 

I think your have more troubles than what you think, the security policy on your Windows 11 is in dire need to reset to default.

I have Windows 11 preinstalled so I assume it is on default settings.

The funny thing I didn't explain good enough is that ProcMon64.exe starts ok, while SysMon.64exe has a problem.

[Brian Evans 105]

1 hour ago, everybyte said:

Funny that SysMon64.exe could not start in Windows 11 - there was a just screen flash.

When opening UAC stated that the app is from an unknown publisher although in properties it is actually properly signed.

Best to run it from a command line with administrator privileges as it installs a service and needs a command line option -i  before it will do so. Been playing with it in a Windows Sandbox - Windows Security | Microsoft Learn so I must install it each time since everything poofs when I close the sandbox.