A lot of people have had questions about the AlienVault and Spiceworks integration that involves threat alerts that you see in the Spiceworks interface, that pops up and say “Hey, you’ve got some bad IP that one of your hosts on your network is interacting with.” There have been a lot of conversations on the community – people are asking “Hey, what do we do when we see this?” And so here’s a How-To that will give you to get a better understanding of how to deal with these types of situations.

8 Steps total

Step 1: 1. Understand Threat Alerts

1. To give you a kind of a quick overview of how the threat alerts work, AlienVault platform has this solution that we call the Open Threat Exchange (OTX). It’s basically a crowd-sourced threat intelligence sharing platform that allows us to track IP addresses of malicious hosts, and basically criminal offenders of all sorts around the globe, and we keep this huge database of all of these systems that are known to be out on the internet causing trouble. And basically we share that information within Spiceworks that give you this visibility that we refer to as Threat Alerts.

Step 2: 2. Understand how Threat Alerts work in Spiceworks

We are correlating the data from Spiceworks with our Open Threat Exchange (OTX) database for known malicious hosts. Spiceworks is providing the data to us from a netstat probe. We send alerts to the Spiceworks dashboard when netstat shows a connection with an identified OTX suspicious asset.

For example, you’ve got a host inside your network, it’s communicating with some system out on the internet, it’s a known bad IP – Spiceworks finds that connection that’s present and it looks at the connection details, goes and does a lookup in the Open Threat Exchange database, and realizes “Hey, this is a bad host”, and that’s where the alert gets triggered. No information gets sent back to AlienVault - this all happens within Spiceworks. So you’re safe in terms of privacy concerns and all of that – we’ve taken all that into consideration and made sure that you’re not sharing sensitive data with the world.

Step 3: 3. Have a look at Threat Alerts in your Spiceworks dashboard

Essentially your Spiceworks dashboard is going to pop up an alert, with a tiny alien head, either in the timeline or in the alerts widget, and it’ll say “Hey, this host inside your network is communicating with this bad IP.” Now, one of the things that is really awesome with Spiceworks is that you can click on the bad IP, and it’ll take you to the AlienVault labs page, where we tell you everything we know about who this bad IP is. You might also get alerts via email.

Step 4: 4. See AlienVault information on potential threat

When you click on an IP from one of those Threat Alerts, you will be required to enter your Spiceworks account email. Then it will take you over to our Threat Alert Details page.

There’s a bunch of good information here. All the domains that are associated with this IP, we provide those on a list. We tell you if there is a known actively malicious IP, if that’s what this is, we’ll identify it, we’ll tell you all the dates of activity that we’ve seen, and we tell you specifically the types of activity that this host is engaged in. So these icons on the lower right hand corner that say “It’s a malware IP” or “A malware domain”, or something to that effect – you could actually click on those and drill down into more information associated with the specific types of malware that are actually been known to interact with this host.

Step 5: Get more info on the threat

You will see additional details about the malware domain, including dates, findings, host file types, and more.

Note where the threat occurred. This will be the external port and the device port. Then read the information about the type of threat below on the page. Scroll down, and notice events detected by event type. The explanations above correlate to the event taxonomy shown in bubble format.

Step 6: Further Investigation into potential threat

The first place to start is really digging into that threat details page, and spending some time digging into the details associated with the activity that’s been reported for this host. Is it a malware IP, or a command and control server? Is it a spamming IP, or is it just scanning the internet? All of that information will be provided there.

You need to consider the context associated with this. So, is this a website that’s serving some kind of exploit kit, or is it a scanning host. If it’s just a scanning host, it’s probably not a huge issue. You shouldn’t run off and reimage the host just based on the threat alert associated with a scanning host.

However, if it’s a known malicious website that’s feeding, or pushing down exploit kits to people that are browsing the site, then you should be be more concerned with that, and spend a bit more time digging into it. The next logical thing to look at is “Well, is this activity ongoing?” Is this something that we’re seeing on a regular basis, or was it a one-time thing? Trying to figure out how consistent is this behavior is your next step.

Looking in the comments section on the AlienVault threat analysis page is going to hopefully help you get some insight into this particular IP. The community is out there investigating these particular threats and providing some feedback. Certainly if you’re doing an investigation, providing some of our your own feedback as to your findings will certainly enrich the community further and help people understand really kind of what’s going on with the host based on other people’s finding.

And then from there, it really comes down to digging into your environment. Let’s figure out what we can about this particular asset, let’s see if we can identify some specifics that will help us assess whether or not this is a problem. And there’s a couple of key elements here. Look at the asset associated with this threat alert. Is it a workstation, or is a server. If it’s a workstation, there’s all kinds of scenarios where this might be just a false positive.

Let’s say, for example, a user was web browsing, and they happened to web browse a server that has lots and lots of different domains linked back to it, and maybe one of those domains is hosting malware, but the domain that the user was visiting is clean, or isn’t hosting any malware. So there’s a couple of scenarios there where if you took a workstation - maybe it’s perfectly legitimate behavior.

Another key consideration - Is the user reporting any unusual or suspicious behavior associated with their system? Typically, when malware gets on a workstation or on a host, it conducting all kinds of strange activity and just behaving in really odd ways. So maybe their web browser doesn’t work like it used to, or maybe they’re getting lots of popups, you know, there’s all kinds of different things that they’ll possibly see if there’s a full blown malware infection on their host. So changes are they will have noticed some unusual behavior. So that’s a good thing, is to just ask the user “Hey, what have you seen on this particular… on your system? Has it been behaving strangely lately?” and then pivot from there and figure out what else you can identify with the workstation.

If we’re talking about a server, that’s kind of a different matter altogether. Typically, people aren’t sitting on a server browsing the internet and hitting bad hosts, right. So that’s a pretty clear-cut case where “Hey, there’s a potential issue with this system”. If it’s interacting with a known bad host out on the internet, it’s really pretty easy to assess “Is this legitimate behavior or not?”

If it is legitimate activity, then obviously it’s a false positive and you can disregard the alert, but there’s a couple of things that you can do to try to figure that out. First off, look at the threat IP that we’ve reported and trying to figure out “Hey, do we possibly have some software on this server that might be interacting with that system for some reason?” There are, on occasion, instances where content serving servers might get flagged as bad IPs, and maybe there’s some software that’s actually connecting to a content server to download some software updates or something like that, and it just happens to coincide with the system that’s also been flagged as a malware domain. So in that case, sure, it could explain the behavior and maybe it’s legitimate, but that’s what you should be looking for, is trying to find something that will explain why this behavior would actually be happening.
Having the context of whether you’re working with a server asset or a workstation asset is going to help, and then kind of moving on through your network, if you’ve got tools in place that can help you assess the security of your environment, it’s going to be a really big advantage.

So working with an Intrusion Detection or Intrusion Prevention System is a big benefit. A lot of folks have firewalls that have IPS modules in them drilling down into that system and digging through the alerts to see if there are alerts that correspond with this known bad IP – those are basically good sources of information to help you figure out if this activity is actually malicious.

And then if you’ve got a SEIM or a log management system of some sort, certainly drilling down into those systems and identifying if there’s any alerts associated with either the asset internally, or this known bad IP out on the internet, those things are going to be really good sources of information as well. If you don’t have any of these types of tools, I definitely recommend looking at investing in some, some kind of log management or SEIM solution, an IDS is really critical to having good security visibility, and some other platforms that can help you out with these things. Assuming you don’t have any of that at your disposal at the moment, just going back and looking through your network device logs is a good practice.

In addition, your firewall might be logging to a sys log server or something where you’re storing log data for an extended period of time. If you’ve got access to that type of information, then it’s going to be extremely helpful for you to assess at least how long has this activity been going on.

Another thing to look for us is any type of suspicious activity that’s coming from the asset. So assuming a system that’s been flagged as the asset inside of your network, and this is the asset that was associated with the known bad IP, you might look for information in the logs to indicate that some suspicious activity is happening from this host.

So what about a false positive? A false positive is basically an instance where we’ve reported a threat alert of some sort and you look into it and you figure out that “Hey, you know what? This is actually just typical user behavior. It’s not anything that I’m significantly concerned about. I’ve confirmed that the system is not infected. There is no suspicious activity originating from it. Etc. etc.” So what do we do with that? Well, the AlienVault team is actually purging the Open Threat Exchange database of false positive IPs on an ongoing basis. We do it every 30 minutes. Just provide us the feedback via the AlienVault Open Threat Exchange threat analysis page.

As the community gives us feedback, we’re going to go in and make sure that we keep the OTX database clean, so that it’s just bad IPs that are being reported, and keeping the system up-to-date fully in that regard.

Step 7: You can optionally get tips for fixing the problem

You can download the Remediation Tips guide. You'll need to fill out a form. You can find this, and the other optional items under "Next Steps" in a blue box to the right.

Step 8: You can optionally see associated domains

You can find this, and the other optional items under "Next Steps" in a blue box to the right.

21 Comments

Perfect, and in good form! 12k of text makes for a succinct two-minute read, thank you very much. And now I know more than I did before about this new underlying mechanism. Quick question for you, is your OTX scanning v4 and v6 IPs? Thanks again, Kate!

I'm a little late to the party, but great explanation. I have been using Spiceworks + AlienVault for quite a while now, but this gives a deeper understanding of behing-the-scenes stuff. Thanks a lot for this, Kate.

If Spiceworks is really just looking at netstat, can't it tell us the process name/ID as well in addition to the host thats communicating with the suspicious IP? It can help us determine if it's legit or not....

This is a really great addition to spiceworks, it has aided me so much in blocking communication with malicious ips and websites. It's also a great help in stopping ransomware before it gets out of hand.

Every time I click on 'View Threat Details' link on the spiceworks alert, I get a splash page to "enter your spiceworks account email to learn about this threat." I enter my spiceworks email and click on Go (a bajillion times) but nothing happens. Thus, I can't view the threat details. Also, when we google the suspicious IP, such as 209.58.130.199, I get nothing. Last, I go directly to AlienVault's website and search but nothing as well. I just turned off auto-creating a ticket and have alert only enabled.
PLEASE HELP!