svchost.exe tried to connect to 92.123.99.235

Hi all,

Today one of my pc’s received popup from CIS FW telling that svchost.exe wanted to connect to 92.123.99.235 on port 80. It happened as soon as I connect the PC to the net.

PC is running XP SP3, FW on custom mode, alert settings very high, svchost.exe outbound connections set on ask excepted on ports 67, 53 and 123 where they are allowed, Windows update disable.

Never received such popup before. To be noted: I changed nothing on the PC which could have triggered the attempted connections.

92.123.99.235 is a RIPE address and I couldn’t get a usefull information on it.

I tried to identify the service triggering the alert but to no avail. The PID refers to a svchost regrouping a least 10 services hence difficult to isolate one.

At each alert, I blocked the request but it kept coming back and was silently blocked by CFW.

Wondering if it could be related to MS, I tried a manual update of windows. It failed, CFW silently blocked the svchost.exe requests though the addresses were totally different from the one I mentioned.

I disconnected the PC, made a rule to block svchost for 92.123.99.235 on port 80. The manual update of windows went trough this time.

I restored the system to a previous date and everything is running fine; no more popup for a connection to that address though the PC settings are completely the same.

I made a scan with avast and malwarebytes before restoring both reported the PC safe.

I’m puzzled:

  • what is the address 92.123.99.235
  • why did svchost.exe tried to connect to it
  • could it have been a malware bot seen by the 2 scanners trying to phone home
  • how comes that having blocked a process for a certain address on a particular port by answering a popup, CFW keeps blocking its requests on the same port even if the addresses are different. If a rule is made for the same process, CFW, as it should be, blocks only the address mentionned in the rule.

Do some of you ever had this request for svchost.exe connecting to 92.123.99.235?

Boris

I ran the IP address trough the whois of cqcounter and found it belongs to Akamai:

IP Address 92.123.99.235 Host a92-123-99-235.deploy.akamaitechnologies.com Location EU, Europe City -, - - Organization AKAMAI TECHNOLOGIES ISP AKAMAI TECHNOLOGIES AS Number AS1299 TeliaNet Global Network
Akamai is a big hosting provider that distributes downloads, updates or media objects and also provides load balancing for software companies.

In short. What you are seeing is most likely an updater for a program using svchost.exe for its connection.

I remember from the days when I was using AVG 6 and 7 their av definition updates came from Akamai servers.

Thanks for you answer Eric,

I don’t think so because all the softwares installed on the PC are set to manual updates as well as windows. The only automatic update is for Avast and it doesn’t use svchost.exe for it. On top of that, nothing had change in the settings of the PC before and during the apparitions of the alerts. i had never seen them before and don’t get them anymore since I restored a previous system image hence my puzzlement.

As Eric suggested, this address belongs to AKAMAI

% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Information related to '92.123.96.0 - 92.123.111.255'

inetnum:        92.123.96.0 - 92.123.111.255
netname:        AKAMAI-PA
descr:          Akamai Technologies
country:        EU
admin-c:        NARA1-RIPE
tech-c:         NARA1-RIPE
status:         ASSIGNED PA
mnt-by:         AKAM1-RIPE-MNT
mnt-routes:     AKAM1-RIPE-MNT
changed:        ck@akamai.com 20091126
source:         RIPE

role:           Network Architecture Role Account
address:        Akamai Technologies
address:        8 Cambridge Center
address:        Cambridge, MA 02142
phone:          +1-617-938-3130
e-mail:         ip-admin@akamai.com
abuse-mailbox:  abuse@akamai.com
admin-c:        NF1714-RIPE
admin-c:        JP1944-RIPE
tech-c:         NF1714-RIPE
tech-c:         JP1944-RIPE
tech-c:         APB15-RIPE
tech-c:         CKAK-RIPE
tech-c:         PWG8-RIPE
tech-c:         MH7314-RIPE
tech-c:         TBAK-RIPE
nic-hdl:        NARA1-RIPE
notify:         ip-admin@akamai.com
changed:        ck@akamai.com 20110107
mnt-by:         AKAM1-RIPE-MNT
source:         RIPE

********************************************************************************

- why did svchost.exe tried to connect to it

If the svchost instance is the one that includes Windows updates and BITS, It’s likely related to a windows update check, possibly for a Root certificate update - MS have just released Security Advisory 2607712 in the wake of the DigiNotar fiasco - or it may simply be checking for normal updates or root changes. You can use something like CurrPorts to capture a log file, which can include the service name hosted by svchost.

- could it have been a malware bot seen by the 2 scanners trying to phone home

Unlikely malware is phoning AKAMAI

- how comes that having blocked a process for a certain address on a particular port by answering a popup, CFW keeps blocking its requests on the same port even if the addresses are different. If a rule is made for the same process, CFW, as it should be, blocks only the address mentionned in the rule.

It depends how you’ve created the rule and what the requests are?

Do some of you ever had this request for svchost.exe connecting to 92.123.99.235?

Amongst many others from AKAMAI. image 1

[attachment deleted by admin]

Thanks Radaghast for your explanations.

They seem logical except that as i mentioned automatic updates were (as it is always the case with my PC’s) disabled for windows as for all the programs. The alerts came yesterday each time I connected this PC, I had never seen them before with the same settings and they didn’t reappear after the restoration of a back image a few days old and again with exactly the same settings then when they occurred.

The rule to block the connection to the address mentioned was :
Block and lock TCP or UDP out from IP any to 92.123.99.235 where source port is any and destination port is 80.
It was placed above my usual other rules for svchost.exe and did a proper job, blocking only connection to this particular address.
That wasn’t the case when I answered block to the alert “svchost.exe wants to connect to 92.132.99.235 on port 80” as CFW blocked after that silently all resquested connections of svchost.exe on port 80 and 443, that I myself initiated when I attempted to do a manual update of windows, though the addresses were not the same as the one initially blocked.

Well everything is running fine again since the restoration of the previous system image, so I’m not anxious but simply intrigued by this unusual event on this PC.

Boris

I’m not 100% sure root certificate updates are subject to settings you may have defined for windows updates…

Edit: you can read more:

To some extent it depends on whether you’re using XP or something more recent.

XP SP3

You should read Certificate Support and the Update Root Certificates Component | Microsoft Learn

Ok, thank you.