suspicious outbound traffic!

[esetid 0]

See image below. From time to time, this Windows process (Host Process for Windows Services) is trying to connect to a remote server (hosted-by.illuminati.es // 77.67.11.96 ).

 

The domain name is suspicious. I would like someone more knowledgeable to shed some light on this, and if it's symptomatic of the presence of malware on my box (Win7 32bit) .

 

Thank you.

 

https://i.imgur.com/KFt10jW.png

 

[Arakasi 549]

German company.

hxxp://en.wikipedia.org/wiki/Tinet

hxxp://www.gtt.net/

 

It seems like a legitimate company, but if it is not your internet service provider, and the fact its on port 80, i would just create a deny rule permanently next time it pops up, and do a reset on your browsers. All of them.

Check for any programs installed by Tinet

 

It doesnt really confirm or deny you have malware.

Do a full In-depth scan with ESET and post results.

[esetid 0]

I don't have any software by Tinet installed. Did a full in depth scan with ESET/bitdefender, nothing shows up.

 

I was more interested in insights on why is a Windows system process trying to connect to a remote server that isn't owned by Microsoft nor by a CDN.

 

Thanks a lot for the quick reply.

Edited November 3, 2014 by esetid

[Arakasi 549]

Well its a host process. Not really windows, but using windows.

Me personally i would hunt down where its coming from and whats causing it.

Start with Task Scheduler, and move to startup entries, browser extensions, proxies in your net adapters, browsers, drivers etc. Check the vendors of your net adapters too.

Move to the registry and look for it there too. Thats just me though. I know my personal system better than habits of family members.

With ESET scans coming back clean, your most likely free of malware. Intusions are a totally different ballpark.

Good luck.

[not_satisfied 0]

 

I don't have any software by Tinet installed.

 

 

You don't need software specifically from Tinet, because that wouldn't make any sense since software for the masses wouldn't be their business model. Tinet does (or yet better did) ip transit, bandwidth management, mpls and similar stuff. Wikipedia says (https://en.wikipedia.org/wiki/Tinet):

"Tinet SpA and Neutral Tandem, Inc., provided voice, IP Transit, Ethernet and hosted services to carriers, service providers, and content management firms based in over 80 countries and six continents".

 

Then Tinet was rebrandet as Intelliquent (https://en.wikipedia.org/wiki/Inteliquent), which did other routing related services, and then they sold the business to GTT which does pretty much the same. Wikipedia says (https://en.wikipedia.org/wiki/Global_Telecom_%26_Technology):

"...is a multinational telecommunications and Internet service provider company headquartered in McLean, Virginia. GTT operates a Tier 1 network, and provides IP transit and MPLS transport services to enterprise, government, and carrier customers in over 80 countries"

 

So, I wouldn't block that domain / IP as long as you aren't sure that you really don't have anything which would use a service which relies on any one of the services from said companies. I believe I remember someone on a french linux forum blocking stuff from (back then) Intelliquent and then some websites wouldn't work for them because back then those companies did some load balancing over their services or it was part of Akamai Caching or something.

 

I'd really suggest researching that matter before blocking something prematurely (even if the domain sounds dodgy, I don't know why they'd register something like that. Maybe bored admins...). 

 

But that're just my two cents.

Edited November 3, 2014 by not_satisfied

[rugk 397]

Just FYI the process is svchost.exe. This is a windows process which mainly is used to run services. This services can be internal Windows services, but in your case it seems to be a non-Windows service.

 

So you could try to narrow it down to the specific svchost.exe process (there are more than one of this) and then (with disabling e.g.) you could even narrow it down to a specific service.

[Arakasi 549]

How hard is it to delete a created rule.

Dumb rule of thumb to just allow things that are questionable.

Dont make a habbit of allowing the unknown according to "not_satisfied_with_life".

If you are unsure, block it if short notice, research after and delete the block if necessary.

Seems to be safe traffic though according to encyclopedia-satisfied.

Good luck. Good to be cautious and ask for assistance!

[SweX 871]

How hard is it to delete a created rule.

Dumb rule of thumb to just allow things that are questionable.

Dont make a habbit of allowing the unknown according to "not_satisfied_with_life".

If you are unsure, block it if short notice, research after and delete the block if necessary.

Seems to be safe traffic though according to encyclopedia-satisfied.

Good luck. Good to be cautious and ask for assistance!

Yep I fully agree. 

[not_satisfied 0]

Dumb rule of thumb to just allow things that are questionable.

 

You are certainly entitled to your opinion, but I'd really like to know the reasoning behind this. If you call something dumb at least give a how&why (besides ease of deleting a rule ... I mean 'cmon, that's really up to the program used and not an indicator whether it's cool to block anything), otherwise it's just plain stupid and ignorant.

 

In case you mangled the important part while reading: We are talking about unknown outbound traffic (originating from svchost) here. In my book it's just a "dumb rule of thumb" to just block anything unknown or when you are unsure in this matter. It's the same as people deleting unknown files from their PC and afterwards wondering whether it could've been malware and why all of a sudden they get this weird errors on boot.

 

Let's assume the originating process and traffic were indeed malicious, then it would do no good to just block it. Since it's outbound the system is already compromised and blocking or unblocking said traffic will not change anything about that. It can even create a totally false sense of security.* However, if we assume somewhat intelligent malware, which should be relatively common these days, or a directly attacking entity, even if very less likely, blocking the traffic will do two or three things a) alert the attacker that something is wrong and b) probably lead to the discovery of the security feature which put the block in place (in case the attacker didn't know this yet, but that's unlikely in this setup) and c) lead to a change in the attackers approach. c) is bad. It's very bad, because you can't predict what will happen. With this kind of access an attacker could for example disable your filtering capabilities without you even knowing. Or the attacker could hook into another process, which is already allowed to communicate outbound, like your browser, and you wouldn't be able to monitor this (if your HIPS fails at this point that is, but if he's already this deep in your system I'd say it has a pretty good chance at failing or at being subverted). Or an attacker could delete all his payloads from the system upon discovery, now you aren't any wiser and can only assume the system has been compromised based on circumstantial evidence at best. Since you don't know what he did or didn't do to the system the best thing would be to rebuild from scratch or use a backup ... but then again, if you don't know if something malicious (and what) had been on the system how are you sure it isn't in your latest backup? Bottom line, one can't know what would happen and if something evil is having a tea party with your svchost and chatting happily away, then it's quite too late to block anything. Even if it'd be spewing out all your passwords into the ether in this single request it doesn't matter, since you can't be sure what happened before and how the malware is structured. Therefore you should change all important details using a secure system anyway.

You certainly won't be able to stop common malware infecting the system using host-bound outbound filtering, since most exploits will happen in the context of other applications, like your browser, which already have permission to establish inbound & outbound connections anyway. (Otherwise it'd be sad being that browser.) So, while blocking a malicious outbound request provides no real benefit in terms of system security it can make the aftermath and analysis of what happened to a system so much more complicated if you're dealing with an attack which reacts to such things (and you should assume this if it's an unknown event like described above). Things might look slightly different if the system is supervised by a NIDS, but then again you'd be more likely running NOD32 BE not ESS Home. 

 

Let's assume it is a privacy related incident. It would be reasonable to block this, however, in my book that'd be in a category somewhere between 'anticipated incident' and 'known problem', so you should be aware of what to expect/block beforehand. Even if you couldn't possibly know about any issues and there is unknown traffic from an unknown process in my opinion you should put system security above privacy concerns and act as if it's malware, since obviously you can't tell the difference.

 

Let's assume the originating process and traffic were legitimate, it would do no good blocking it, but also it probably wouldn't do any harm blocking it short term. However, when you do your research and come to no conclusion, because there is so little information (or you are searching wrong) what do you do? Is uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to good or malicious, what about 3.f.ix.de, elb020015-953005921.us-east-1.elb.amazonaws.com or hosted-by.illuminati.es for that matter (don't mind the examples.)? You could keep the block, just to be on the safe side...now we changed short to long term without a second thought.

But then what if, for example, the legitimate traffic is actually belonging to an update routine, which now fails and does so silently and gracefully, because the programmer didn't anticipate someone blocking network communication? Now you build yourself a homemade security hole. It might seem unlikely but I've seen just too many people doing this, because they didn't know better. Blocking e.g. something like a1293.d.akamai.net seems to be popular, I can understand it, it looks like something dodgy, too (for some at least). Though it often won't really fail silently, but then again people don't seem to care that much or don't see the failure for one reason or another. In the end this doesn't matter for arguments sake, because even with legit traffic we're back to distinguishing unknown good from unknown bad traffic - as before. You can't and then you're are back to square one.

 

And just because I find it unfathomably important I'll repeat it once: If there is real malicious outbound traffic originating from a very privileged process you can forget about blocking it, because it is already too late at this stage. Just halt and analyze the system to access what went wrong (and what was compromised if applicable) and revert to backup.

 

Now you got more than my two cents of spare change. I frankly don't care if you block or unblock all unknown outbound traffic, whatever fits your sense of relative security, just don't have a false one. I have seen it backfire just too many times so for me it's a no-go. If you don't see any problems with the things I stated it's fine, whatever works for you. But if you declare something as 'dumb' at the very least give an explanation as to why it presumably is and in this context that'd be all the benefits of blocking all unknown outbound traffic. I see some (largely privacy related) merits, but imo they don't outweigh the possible cons of breached system security & thwarted analysis.

 

 

 

 

_____________

*) It can even be very dangerous for some people who are not familiar with how software works, in that they assume blocking traffic would be equivalent to removing malware from their system. But that's a different story.

[Arakasi 549]

Hello again,

 

In regards to your response, i give great credit for the time and passion put forth to explain your side.

We like to read around here.

 

The dumb statement regarding allowing an unknown questionable connection for the "user" who if classified as inexperienced or little to no understanding of IT, the recommendation should always be to block any unknown sources until you can find out what it is.

 

Shall we take this one step further and evaluate how firewalls work when placed in such a scenario where the user is in full control when placed in a conditional, dialogue prompt that is interactive such as Allow or Deny ?

The firewall will automatically block or hold the connection until a choice is made. If you want to go research while its on the screen sure, but some connections will timeout, depending on type.

 

My simple response nonetheless is still similar to safe browsing tactics. If you do not know, "DONT" until you find out. Thats all.

[SCR 195]

For some computers are well understood and for others they are one of those mysteries of life.  I guess I fall in to an area several clicks beyond a normal user but yet still consider computers rather mysterious. Not everyone is interested in learning the why, what and how a computer does what it does. For those a computer should work like the TV. Connect a few wires to the back, turn it on and it works never caring about the technical side of how the picture and sound gets there. With a TV they channel surf on the computer they Internet surf completely unaware of the difference and that dangerous things lurk on the Internet that can take advantage of their lack of knowledge to know the difference.

 

I'm not in the 'not interested' group and remain curious about technical things but it is a slow learning process with out formal training. Many times I am way over my head. But, I do know enough to not let something connect to the Internet that I am warned about by software that I purchased to protect me. To advise people to just allow anything that pops up and requests a connection is rather like telling them to just turn the software off and wing it. Is it better to block the connection even if the computer is compromised or allow the connection and compound the problem? I am not advocating to block everything permanently but rather to at least block it till you find out what it is.

 

I live by "When in Doubt .. Don't" and "The Dumbest question is the one not asked." Fortunately for me, and many others, these forums are here to ask dumb questions and receive smart answers. I am grateful for the patience of the knowledgeable participants of this forum who can help me in my quest for knowledge and help keep me safe in the process.

[keyes 0]

Hello, I am not a user of ESET, but your post caught my attention. I have seen network activity from the same illuminati address, towards steam.exe (steam is a drm games service.

Is there anymore information on this?