Anxiety-inducing snort alert

gogeden

So. I'm a little freaked out.
Was checking the snort logs on my box today and discovered this:

03/14/14
22:24:42 	1 	TCP 	A Network Trojan was Detected 	xx.xx.xx.xx	34852 	xx.xx.xx.xx	80 	1:2008038	ET MALWARE User-Agent (Mozilla/4.0 (compatible ICS))

Kinda creeped out here.
There's multiple alerts for this and I've been scanning everything for infection on my network for the past 6 hours now.
Can someone explain what this is?
I saw "Trojan" and it creeped me right out.

I blocked the IP that it came from via Floating, WAN, and LAN, FWIW.

Please help!

cmb

Is the source inside your network, or is it the destination? I'm assuming the latter, where that's something hitting your web server, in which case it's just typical Internet noise (but check your web server logs for what that IP did to make sure). If it's coming from inside your network, that's more concerning, and indicates you have a compromised machine somewhere.

gogeden

@cmb:

Is the source inside your network, or is it the destination? I'm assuming the latter, where that's something hitting your web server, in which case it's just typical Internet noise (but check your web server logs for what that IP did to make sure). If it's coming from inside your network, that's more concerning, and indicates you have a compromised machine somewhere.

Looks like it's the source.
S***.

Well according to whois, the IP belongs to EdgeCast Networks.
There's another IP that set Snort off that belongs to Comodo.

I've been scanning everything and changing password out of sheer paranoia for about 15 hours now.
Do you have any tips with trying to figure out what machine is so damn prized for this to happen.
Snort is setup on my WAN btw.

I'll set up a sniffer on my LAN just to see.

Thank you and I look forward to your reply.

BBcan177

You can read up on the User Agent here
http://www.sans.org/reading-room/whitepapers/hackers/user-agent-field-analyzing-detecting-abnormal-malicious-organization-33874

Most times I have seen this not to be malicious. Even the WeatherNetwork can cause this alert to trip. Next time post the WAN IP address from the alert so we can help look up the Address.

I posted a few web links that can help diagnose if a IP address is known to be malicious. https://forum.pfsense.org/index.php?topic=73406.0

pfSense Snort is great but it only provides a small picture of what happened for a particular event. The new Suricata version actually captures the PCAP file so you can look at the headers and see exactly what was in the payload. However it does not provide Blocking mode currently.

As Chris had suggested you need to see if it got to anything on the LAN side. Having an IDS like "Security Onion" will log all traffic so you can do a search for an IP address and see every instance of the potential breach.

Read the following article http://dcid.me/notes/2013-jul-08

gogeden

@BBcan17:

You can read up on the User Agent here
http://www.sans.org/reading-room/whitepapers/hackers/user-agent-field-analyzing-detecting-abnormal-malicious-organization-33874

Most times I have seen this not to be malicious. Even the WeatherNetwork can cause this alert to trip. Next time post the WAN IP address from the alert so we can help look up the Address.

Here's a few of the IPs:

216.93.242.12
50.7.245.186
88.80.29.60

I've also been seeing this reported a lot:

GPL SHELLCODE x86 inc ebx NOOP

I posted a few web links that can help diagnose if a IP address is known to be malicious. https://forum.pfsense.org/index.php?topic=73406.0

pfSense Snort is great but it only provides a small picture of what happened for a particular event. The new Suricata version actually captures the PCAP file so you can look at the headers and see exactly what was in the payload. However it does not provide Blocking mode currently.

As Chris had suggested you need to see if it got to anything on the LAN side. Having an IDS like "Security Onion" will log all traffic so you can do a search for an IP address and see every instance of the potential breach.

Read the following article http://dcid.me/notes/2013-jul-08

I checked out the auth.log on one of our servers and it had a successful log in at a time where I was not at home.
So something's going on.

Thank you all for your replies and I hope you'll reply again :)
Sorry for the late response!

bmeeks

@gogeden:

@BBcan17:

You can read up on the User Agent here
http://www.sans.org/reading-room/whitepapers/hackers/user-agent-field-analyzing-detecting-abnormal-malicious-organization-33874

Most times I have seen this not to be malicious. Even the WeatherNetwork can cause this alert to trip. Next time post the WAN IP address from the alert so we can help look up the Address.

Here's a few of the IPs:

216.93.242.12
50.7.245.186
88.80.29.60

I've also been seeing this reported a lot:

GPL SHELLCODE x86 inc ebx NOOP

I posted a few web links that can help diagnose if a IP address is known to be malicious. https://forum.pfsense.org/index.php?topic=73406.0

pfSense Snort is great but it only provides a small picture of what happened for a particular event. The new Suricata version actually captures the PCAP file so you can look at the headers and see exactly what was in the payload. However it does not provide Blocking mode currently.

As Chris had suggested you need to see if it got to anything on the LAN side. Having an IDS like "Security Onion" will log all traffic so you can do a search for an IP address and see every instance of the potential breach.

Read the following article http://dcid.me/notes/2013-jul-08

I checked out the auth.log on one of our servers and it had a successful log in at a time where I was not at home.
So something's going on.

Thank you all for your replies and I hope you'll reply again :)
Sorry for the late response!

I think I would be a bit worried with that correlation from the auth.log entry. It might be time for a potential wipe and reload of the affected boxes. While there can certainly be some false positives with the Trojan rules, in this case with the suspicious auth.log entry (if you are positive it is truly suspicious and cannot be explained by some normal event), I would highly suspect an intruder has gained some level of access.

Bill

gogeden

@bmeeks:

@gogeden:

@BBcan17:

You can read up on the User Agent here
http://www.sans.org/reading-room/whitepapers/hackers/user-agent-field-analyzing-detecting-abnormal-malicious-organization-33874

Most times I have seen this not to be malicious. Even the WeatherNetwork can cause this alert to trip. Next time post the WAN IP address from the alert so we can help look up the Address.

Here's a few of the IPs:

216.93.242.12
50.7.245.186
88.80.29.60

I've also been seeing this reported a lot:

GPL SHELLCODE x86 inc ebx NOOP

I posted a few web links that can help diagnose if a IP address is known to be malicious. https://forum.pfsense.org/index.php?topic=73406.0

pfSense Snort is great but it only provides a small picture of what happened for a particular event. The new Suricata version actually captures the PCAP file so you can look at the headers and see exactly what was in the payload. However it does not provide Blocking mode currently.

As Chris had suggested you need to see if it got to anything on the LAN side. Having an IDS like "Security Onion" will log all traffic so you can do a search for an IP address and see every instance of the potential breach.

Read the following article http://dcid.me/notes/2013-jul-08

I checked out the auth.log on one of our servers and it had a successful log in at a time where I was not at home.
So something's going on.

Thank you all for your replies and I hope you'll reply again :)
Sorry for the late response!

I think I would be a bit worried with that correlation from the auth.log entry. It might be time for a potential wipe and reload of the affected boxes. While there can certainly be some false positives with the Trojan rules, in this case with the suspicious auth.log entry (if you are positive it is truly suspicious and cannot be explained by some normal event), I would highly suspect an intruder has gained some level of access.

Bill

What exactly is that GPL Shellcode entry anyway?
Also, do you have a link or a guide for setting up firewalls.
I have most of my rules under the "Floating" page.

Thanks for your help!

bmeeks

@gogeden:

What exactly is that GPL Shellcode entry anyway?

Also, do you have a link or a guide for setting up firewalls.
I have most of my rules under the "Floating" page.

Thanks for your help!

Shellcode composed of NOOPS (no operation) is a typical type of buffer overflow intrusion attempt. Essentially an extremely long input is supplied to a server (usually a web server) in an attempt to overflow an internal buffer and overwrite the stack such that the intruder gains unauthorized access. There are many variations of this idea.

Generally, the basic setup for a firewall is to deny all inbound traffic except maybe a handful of services that you may provide to the public (assuming you are a commercial enterprise and have say a web site and accept inbound SMTP e-mail). If you are a home user, then you basically want all inbound traffic denied by default (and that is the out-of-the-box setup for pfSense). Stateful inspection will take care of inbound replies to outbound requests from your LAN (assuming you put the LAN in accept-all mode). You can certainly get more secure than that, though. Also, I would not use Floating Rules unless you are 100% sure you need them and you understand their purpose. For most folks, the plain vanilla WAN and LAN fixed rules are OK. Also, pretty much every home network is going to be using NAT.

I don't know your level of firewall expertise, but I suggest going to Google and looking up the phrase "stateful inspection firewall" to find some good explanatory links on what this is and how it works.

Bill

gogeden

@bmeeks:

@gogeden:

What exactly is that GPL Shellcode entry anyway?

Also, do you have a link or a guide for setting up firewalls.
I have most of my rules under the "Floating" page.

Thanks for your help!

Shellcode composed of NOOPS (no operation) is a typical type of buffer overflow intrusion attempt. Essentially an extremely long input is supplied to a server (usually a web server) in an attempt to overflow an internal buffer and overwrite the stack such that the intruder gains unauthorized access. There are many variations of this idea.

Generally, the basic setup for a firewall is to deny all inbound traffic except maybe a handful of services that you may provide to the public (assuming you are a commercial enterprise and have say a web site and accept inbound SMTP e-mail). If you are a home user, then you basically want all inbound traffic denied by default (and that is the out-of-the-box setup for pfSense). Stateful inspection will take care of inbound replies to outbound requests from your LAN (assuming you put the LAN in accept-all mode). You can certainly get more secure than that, though. Also, I would not use Floating Rules unless you are 100% sure you need them and you understand their purpose. For most folks, the plain vanilla WAN and LAN fixed rules are OK. Also, pretty much every home network is going to be using NAT.

I don't know your level of firewall expertise, but I suggest going to Google and looking up the phrase "stateful inspection firewall" to find some good explanatory links on what this is and how it works.

Bill

Ahhh I see in regards to the GPL SHELLCODE bit.
How does one prevent this anyway?

I'm going to restore my pfSense box and FreeNAS (The server that is most likely compromised) box to factory settings.
Or should I format the drives?
I would think a factory reset would suffice but I can't afford to make assumptions :)

You folks are awesome here!
Thanks so much :D

bmeeks

@gogeden:

Ahhh I see in regards to the GPL SHELLCODE bit.
How does one prevent this anyway?

The best way to prevent a GPL SHELLCODE attack is to simply deny unsolicited inbound traffic. If you have to provide open Internet-facing ports in order to provide some required services (a public web site or company e-mail service, for example), then you have to make sure your servers are fully patched and sufficiently hardened. A tool like Snort can also help out immensely, but don't depend on it alone. Always stay patched and follow hardening guidelines for the server OS.

@gogeden:

I'm going to restore my pfSense box and FreeNAS (The server that is most likely compromised) box to factory settings.
Or should I format the drives?
I would think a factory reset would suffice but I can't afford to make assumptions :)

You folks are awesome here!
Thanks so much :D

If I recall, when you do the factory reset for pfSense it is going to essentially wipe the partition and start over. I don't know anything about FreeNAS, though.

Bill

gogeden

@bmeeks:

@gogeden:

Ahhh I see in regards to the GPL SHELLCODE bit.
How does one prevent this anyway?

The best way to prevent a GPL SHELLCODE attack is to simply deny unsolicited inbound traffic. If you have to provide open Internet-facing ports in order to provide some required services (a public web site or company e-mail service, for example), then you have to make sure your servers are fully patched and sufficiently hardened. A tool like Snort can also help out immensely, but don't depend on it alone. Always stay patched and follow hardening guidelines for the server OS.

@gogeden:

I'm going to restore my pfSense box and FreeNAS (The server that is most likely compromised) box to factory settings.
Or should I format the drives?
I would think a factory reset would suffice but I can't afford to make assumptions :)

You folks are awesome here!
Thanks so much :D

If I recall, when you do the factory reset for pfSense it is going to essentially wipe the partition and start over. I don't know anything about FreeNAS, though.

Bill

I did a reset last night.
Went very well.
I got more network trojan notifications again from the same IPs.
I did some reverse DNS and it turns out they're from another service I use.

I did get a GPL SHELLCODE thing though.
I'll run nmap and see if anything is open.
I doubt there is but I'll do it anyway.

Thank you Bill and everyone else! :)

cmb

Generally speaking, the shellcode signatures tend to trigger a lot of false positives on many networks, so I'd take that one less seriously than the malicious user agent, which is less likely to be a false positive (though certainly not impossible).