AlienVault R&D Labs Portal. Get the latest news from our research.
Header

A few days ago, CERT-Georgia published a great report describing a cyber spionage campaign. ESET wrote a great report a few months ago as well. The report said the malware was found in Georgian Governmental Agencies including ministries, parliament, banks, ngo’s. The report also says the purpose of the malware was “Collecting Sensitive, Confidential Information about Georgian and American Security Documents” and it establishes a connection with Russian Official Security Agencies.

In this blog post we will offer a brief about the infection vectors as well as the malware behavior and we will share some IOC’s and signatures to detect the presence of the malware in your systems.

Infection method

To compromise the victims, the attackers placed javascript code or iframes into websites leading to exploit code.

The compromised website includes Georgian Government servers like ema.gov.ge. Other examples are:

- ema.gov.ge

- 31.214.140.214

- 178.32.91.70

- georgiaonline.xp3.biz

- 31.31.75.63

173.212.192.83

An example of a malicious javascript is as follow:

 

 

 

 

 

The malicious javascript present in frame.js/frame.php includes code that exploits several vulnerabilities including CVE-2010-0842,   CVE-2006-3730, MS06-057 and some Java exploits.

Examples of exploit codes found:

178.32.91.70 [/] modules[/]docs[/]newexp[.]jar https://www.virustotal.com/file/9bf88bf15ffa6888ec2a3bd9e8dc6d13b650f1122ca69cface9ccf777c32e259/analysis/

178.32.91.70 [/] modules[/]docs[/]Java-2010-0842[.]jar

https://www.virustotal.com/file/7a900cc7616cfbf2ca17350c436af2490621550ded3e29325dc31149db50c63d/analysis/

 

 

 

 

 

 

 

 

Once the exploit code is executed, the payload calc.exe that contains the malware is downloaded from the remote server.

The malware uses a custom packer to evade security security products. It also uses obfuscation to hide both the configuration values and the API calls.

The malware uses byte substraction operations to hide the strings including the configuration values:

 

 

 

 

 

 

 

 

 

 

 

After deobfuscation:

 

 

 

 

 

 

 

 

 

 

 

We can use the following Yara rule to detect the obfuscated binary:

rule GeorBotBinary
{
strings:
$a = {63 72 ?? 5F 30 00 6B 65 72 6E 65 6C 33 32 2E 64 6C 6C}

condition:
all of them
}

Based on the deofuscated strings we can also write a Yara rule to detect the presence of the malware in memory:

rule GeorBotMemory
{
strings:
$a = {53 4F 46 54 57 41 52 45 5C 00 4D 69 63 72 6F 73 6F 66 74 5C 00 57 69 6E 64 6F 77 73 5C 43 75 72 72 65 6E 74 56 65 72 73 69 6F 6E 5C 00 52 75 6E 00 55 53 42 53 45 52 56}
$b = {73 79 73 74 65 6D 33 32 5C 75 73 62 73 65 72 76 2E 65 78 65}
$c = {5C 75 73 62 73 65 72 76 2E 65 78 65}
condition:
$a and ($b or $c)
}

We use both the registry key used to maintain persistence and the executable name that the malware creates on the system (in version >=5 of the malware those values are stored on wide strings).

If we have a memory image of a system we can use Volatility to look for processes matching our Yara rule:

$ python vol.py -f /Users/jaime/tmp/geor.img yarascan -y GeorBotMemory.yara
Volatile Systems Volatility Framework 2.1_alpha

Rule: GeorBotMemory
Owner: Process 833bd8e9fdf6f18 Pid 368
0x004055b3 53 4f 46 54 57 41 52 45 5c 00 4d 69 63 72 6f 73 SOFTWARE\.Micros
0x004055c3 6f 66 74 5c 00 57 69 6e 64 6f 77 73 5c 43 75 72 oft\.Windows\Cur
0x004055d3 72 65 6e 74 56 65 72 73 69 6f 6e 5c 00 52 75 6e rentVersion\.Run
0x004055e3 00 55 53 42 53 45 52 56 00 2e 64 6f 63 00 2e 78 .USBSERV..doc..x
Rule: GeorBotMemory
Owner: Process 833bd8e9fdf6f18 Pid 368
0x004059a6 73 79 73 74 65 6d 33 32 5c 75 73 62 73 65 72 76 system32\usbserv
0x004059b6 2e 65 78 65 00 43 3a 5c 57 49 4e 44 4f 57 53 5c .exe.C:\WINDOWS\
0x004059c6 73 79 73 74 65 6d 33 32 5c 75 73 62 63 6c 69 65 system32\usbclie
0x004059d6 6e 74 2e 65 78 65 00 43 3a 5c 57 49 4e 44 4f 57 nt.exe.C:\WINDOW
Rule: GeorBotMemory
Owner: Process 833bd8e9fdf6f18 Pid 368
0x004059ae 5c 75 73 62 73 65 72 76 2e 65 78 65 00 43 3a 5c \usbserv.exe.C:\
0x004059be 57 49 4e 44 4f 57 53 5c 73 79 73 74 65 6d 33 32 WINDOWS\system32
0x004059ce 5c 75 73 62 63 6c 69 65 6e 74 2e 65 78 65 00 43 \usbclient.exe.C
0x004059de 3a 5c 57 49 4e 44 4f 57 53 5c 73 79 73 74 65 6d :\WINDOWS\system

Network traffic

The malware uses HTTP to communicate with the C&C server. It contains several commands to upload and retrieve information from the victim. It also looks for malware updates every once in a while. In early versions the update version was requested from /modules/docs/upload/calc.exe on the C&C server.

 

 

 

 

 

In newer versions the malware performs a request to /calc.php and the server sends base64 encode content (it can be done using content from different servers at the same time).

 

 

 

 

 

 

 

When the malware starts it sends the following request to the C&C:

 

 

 

 

 

Every minute it sends the following HTTP request to the C&C to ask for instructions:

 

 

 

 

In newer versions the parameter “cam” was also introduced that tells the C&C whether the infected system has a webcam.

/index312.php?ver=5.1&cam=0&p=cert123&id=401acd00

You can use the following snort to detect the presence of this malware in your network:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:”ET MALWARE Georbot requesting update”; flow: to_server,established; content:”/modules/docs/upload/calc.exe”; http_uri; classtype:trojan-activity; sid:1111111112; rev:1;)

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:”ET MALWARE Georbot initial checkin”; flow: to_server,established; content:”POST”; http_method; nocase; content:”.php?ver=”; http_uri; content:”&p=cert123″; fast_pattern; http_uri; content:”&id=”; http_uri; classtype:trojan-activity; sid:1111111113; rev:1;)

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:”ET MALWARE Georbot checkin”; flow: to_server,established; content:”.php?ver=”; http_uri; content:”&p=bot123″; fast_pattern; http_uri; content:”&id=”; http_uri; classtype:trojan-activity; sid:1111111114; rev:1;)

Emerging Threats Pro has coverage for previous versions (see “ETPRO TROJAN TDSS.xcn”) but the rules I posted will work with newer versions of the malware as well.

Based on the behavior of the malware we wrote this OpenIOC rule:

 

 

 

 

 

 

You can download all the content from this blog post on the following url:

https://github.com/jaimeblasco/AlienvaultLabs/tree/master/malware_analysis/Georbot

Happy Halloween!

 

jaime.blasco

At AlienVault Jaime manages the Lab and runs the Vulnerability Research Team. Prior to working in the AlienVault lab he founded a couple of startups (Eazel, Aitsec) working on web application security, source code analysis and incident response. His background stems from a number of years working in vulnerability management, malware analysis and security researching.

More Posts - Website

Follow Me:
TwitterLinkedIn

When we launched the Open Threat Exchange (OTX) project, one of our goals was creating an open and free threat database and exchange system. We want it to be used by as many users as possible using a wide range of technologies.

That is why we are publishing some code to feed our Open Threat Exchange (OTX) data to an ArcSight SIEM using the Common Event Format via Syslog.

The Open Threat Exchange (OTX) contains an IP reputation database that offers real time information of bad actors. Using this information within a SIEM gives you new possibilities to correlate data, for example:

  • Connection to know C&C servers
  • Detection of P2P botnets
  • Data exfiltration to low reputation servers
  • Password guessing attacks from bad actors
  • Exploit/Malware access from malicious servers
Download the required files:

The configuration is very easy, just open the configuration file config_otx.py:

[main]

syslog_level = notice

syslog_facility = daemon

syslog_host = 10.49.5.139

reputation_server = https://reputation.alienvault.com/

syslog_port = 514

revision = 0

[fields]

min_reliability = 2

min_priority = 2

ignore_activities =

[proxy]

enable = False

host =

user =

password =

port =

Configure your collector ip address on syslog_host and you are ready to go. The script will download the reputation data from ours servers (HTTP) and it will send that data to the collector using UDP.

Then you need to create an Active List in ArcSight to use the indicators.

If you need to access the Internet via a proxy, configure it under the proxy section.

Using this method, our reputation data is updated in an hourly basis so you can configure a cron job to execute the script once an hour.

You can also configure some filters, if you want to ignore some ff the activities we send you can use this syntax:

ignore_activities = Scanning Host,Spamming

The min_reliability is the minimum reliability value that will be send to the collector based on the reliability that OTX put to that ip address. The same with min_priority, it is the minimum priority value that will make the information to be sent.

$ python otx-arcsight.py

Server data rev is 14694

Local rev is 14694

It means the database is up to date.

$ python otx-arcsight.py

Server data rev is 14694

Local rev is 14691

Updating data from server

Downloading complete database

Sending CEF:0|AlienvaultOTX|AlienvaultOTX|1.0|100|Suspicious Host|1|src=94.248.192.110 msg=Scanning Host,http://labs.alienvault.com/labs/index.php/projects/open-source-ip-reputation-portal/information-about-ip/?ip\=94.248.192.110

Sending CEF:0|AlienvaultOTX|AlienvaultOTX|1.0|100|Suspicious Host|1|src=94.248.192.112 msg=Scanning Host,http://labs.alienvault.com/labs/index.php/projects/open-source-ip-reputation-portal/information-about-ip/?ip\=94.248.192.112

 

jaime.blasco

At AlienVault Jaime manages the Lab and runs the Vulnerability Research Team. Prior to working in the AlienVault lab he founded a couple of startups (Eazel, Aitsec) working on web application security, source code analysis and incident response. His background stems from a number of years working in vulnerability management, malware analysis and security researching.

More Posts - Website

Follow Me:
TwitterLinkedIn

Here we go again.

You know the expression, “No good deed goes unpunished”?  Well that idea has surfaced with regard to our OTX, or Open Threat Exchange.  Let me explain what I mean.

First, some background.   We launched OTX back in February with a passionate belief in the power of transparency and open source models.   But we’re also as realistic as the next guy, which means we knew that it might open a crack in the door for those with malicious intent.

So when we’re asked whether the benefit of sharing threat intelligence is worth the perceived risk, we’ve got an answer.  It’s not a flippant answer or a dismissive one.  We thought through the implications of openness, and baked that into the design of Open Threat Exchange.  And it is a continuous factor in our ongoing product decisions.

To fully respond to the question about creating risk, we need to look at potential attack vectors, within OTX.  And then consider the consequences if an attacker is able to exploit one of them.

  1. An attacker is able to introduce data into Open Threat Exchange
  2. An attacker is able to access the information that OTX distributes
  3. An attacker is able to access the information that a particular contributor shares with OTX
  4. An attacker is able to impersonate OTX and feed a particular contributor bad data

Four possibilities, each one of them carefully considered.  I hope I won’t bore you with the detail below, but it’s all important.

Attack Vector #1: An attacker is able to introduce data into Open Threat Exchange

Open Threat Exchange allows users to share reputation information for IP addresses, collaboratively creating a list of addresses known to manifest malicious behavior.  The IP may not be completely malicious, but its previous actions should be considered when evaluating any future suspicious behavior that might originate from it.

IP addresses that are not on the list are not considered to be good, they just simply are not known to be bad.  That is a  “blacklist” philosophy, and it’s the most prudent approach in this case.  Think about it. Malicious introduction of benign IP addresses could cause OSSIM / AlienVault to inappropriately classify them as suspicious but there is no way to ‘whitelist’ IP addresses (classify them as benign).

Since OTX is open to anyone, mitigating controls have been put in place.  Submissions by any source are validated by the content of other contributors, by information collected by systems run by AlienVault, AND by contributors that are known as trustworthy.  We also collect other information related to the IP address to substantiate the observed malicious behavior.  For example, indicators like a recently registered domain name, or an IP with dynamic DNS are carefully examined.  We expect our validation to largely address the potential issues coming from this attack vector.

However, even in the worst-case, if benign addresses slip through these validation mechanisms, the impact is minimal as the consequence means that false alerts would be generated by the AlienVault/OSSIM installation.

Attack Vector #2: OTX IS TOO Open, and an attacker is able to access the information we distribute

Assume that this is happening.  However, its implications are not too concerning; the attacker already knows that an IP address they control is performing malicious activity so the only information that they are gaining is potentially that one of their IP addresses is now known to be malicious.  If anything, that should render them more cautious about that address.

One variation of this risk is that an attacker might probe an environment for the use of AlienVault/OSSIM.  It is true that if an attacker were to target a single victim from a unique IP and that IP then appears in Open Threat Exchange, the attacker could confirm that the target participates in Open Threat Exchange through this penetrative validation.

However, confirming participation in the Open Threat Exchange does not actually reveal anything substantial about the defensive capabilities that are in place.  The attacker gains no information related to how the AlienVault / OSSIM installation is configured, how broadly it is deployed, what correlation rules are being used, nor do they gain any information about the other security controls that are deployed. Indeed, it sends a message that a potential target is paying smart attention to security; it might send the attacker elsewhere.

Attack Vector #3: An attacker is able to access the information that a particular contributor shares with Open Threat Exchange

Yes, to be candid, being able to isolate a particular contributor is a little more worrisome than the other attack vectors.  But even so, the information that is shared would not likely lead to a compromise.  If a contributor is sharing the list of external IP addresses that have triggered alerts, then that’s the only information that they are revealing.

If an attacker was able to access this information, they could confirm that their particular attack was detected and move on to a different strategy.  So yes, here we see the potential for an attacker to improve their efficiency since we are effectively providing them a signal from which they can determine their attack is failing.

However — and this is a huge however — we are not introducing a new vulnerability or providing breadcrumbs to further their attack.  Open Threat Exchange does not store or distribute any identifying information about who contributes the information in OTX.  This means that the only potential way for this to be exploited is through the transport of the information.  But by using the industry standard SSL protocols and valid certificates, our transport channel is no more vulnerable than any other SSL encrypted-channel. Not perfect but pretty darn good.

Attack Vector #4: An attacker impersonates the Open Threat Exchange and spoofs a contributor with bad data

The issues are similar to the first attack vector.  But instead of controlling just a few of the IP addresses on the blacklist, here the attacker is controlling all of them, potentially resulting in a large number of false alerts. This could possibly diminish the utility of the SIEM.  But simply disabling the reputation-based correlation rules would quickly address a DOS attack on the SIEM.

What’s more, actually exploiting this attack vector would require a successful man-in-the-middle attack on the SSL connection between the OSSIM / AlienVault installation and AlienVault.  A possibility, but if someone were to pay the price of doing this to you, there are more interesting encrypted connections coming from your network I am sure J.

To summarize, we’ve kept an open mind as we developed our Open Threat Exchange.  We are not oblivious to the risks.

These attack vectors have all been assessed in the context of the information we are sharing today: IP Reputation.

We also recognize that OTX isn’t static.  It shouldn’t be.  So as the platform expands and new information is shared we will consider these vectors and introduce new mitigating controls if necessary.

Good things and the right behaviors have risks associated with them. That includes sharing threat intelligence; but even if the system were to be completely compromised, the advantage an attacker might gain is minimal.  We’re proud that the dangerous status quo of self-imposed isolation is broken.  We look forward to your contributions to both OTXs – the Open Threat Exchange, and the Open Thread exchange, below.

Read more about Open Threat Exchange here, and check out the infographic featuring threat data from the first five months of the Open Threat Exchange.

The Power of All

August 2nd, 2012 | Posted by DK in Alienvault (Company) | News | OTX - (Comments Off)

A little bit over five months ago, AlienVault released the first public version of its Open Threat eXchange, OTX. We’ve just created an info graphic – titled “The 2nd United Nations: The World Comes Together to Open-Source Cyber Security ” – in order to share some interesting findings from the first five months of use.

The goal of OTX is to have a collaborative shared-intelligence platform taking input from OSSIM and its connected devices, both free open source and commercial, and providing the output free of charge in different formats for reuse.   The ‘power of all’ to collect and share threat data.

In its current form, with the IP reputation database at its core, OTX can be compared to the IAFIS fingerprint database.  A certain IP address would have its own “rap sheet” inside the OTX database with the “crimes” committed by that IP associated to it. In no way is a relationship between the crimes and the crime reporter saved, so think of it as giving anonymous tips when you share data with OTX.

To further illustrate this, please have a look at our “Most Wanted IPs” here: http://labs.alienvault.com/labs/index.php/projects/open-source-ip-reputation-portal/

At the time of this writing, the most wanted IP is 66.150.14.46, with 9865 detected “crimes” (as defined above: sharing malware, attacking one of the OSSIM installations, attacking our honeypots, etc.).

If you go to this IP’s page (or any other in the “most wanted” if that one’s clean), you will see a full list of this IP’s crimes, what we call “Malicious Activity”, such as having a malware domain pointed at it, being a known malware IP, being an IP included by other sources as part of a known network of malicious IP addresses, spamming, etc.

This database of malicious activity can serve many purposes:

  • Validate access to systems through correlation
  • Raise awareness of lower priority events with this IP in them either as source or destination
  • Visually notifying the user through the interface of this IP being “malicious” throughout the interface
  • Using the database’s contents to write firewall or correlation rules
  • Etc.

As you can see, applications can be many, and these are just the tip of the iceberg.

We have mentioned this before but we’ll say it again: the more people whose systems contribute data to OTX, the more information will be gathered and shared among OTX members.

And as with police/government databases, we don’t have to stop at IP addresses and attacks. Information such as traffic trends, statistics on type of target and on amount of traffic can all lead to enhanced detection capabilities.

There’s a big difference between the police/government databases and OTX though: you, the user, chose what to share and how, and when you want to get full insight into the results of this “collection”.

On the info graphic mentioned above we show a series of statistical results and curious data trends found in OTX during its first five months. It makes no sense repeating them in this text, but we’d like to highlight some points.

The obvious one would be to apply a golden rule that firewall admins around the world have used for decades: default deny.

If you look at the top malicious networks it would make sense for most organizations and end users (or even full ISPs) to completely drop inbound traffic from and outbound traffic to the entire IP address space of China. Of course, this is not practical and actually a somewhat dangerous precedent, since it could lead to other types of IP censorship under the excuse of “mistakes”.

What would be interesting is a statement from the Chinese government as to why their firewalls so successfully filter inbound content to their citizens, but are so bad at filtering outbound malicious activity. (Maybe free-speech-over-malware should become a common practice in some countries where free speech is harder to get in a different way…)

If we have a look at the top activities, we could quickly derive a pie chart like this one:

 

More than ½ of the top 4 activities are scanning: either port scanning, scanning for live hosts, scanning for vulnerable services, i.e. recognition. There is almost no legitimate reason for a host to be doing any of these on an external IP. It would be similar in a real life scenario to someone walking down a street at night and checking car doors or house entrances to see if they’re open.

This is pretty rudimentary stuff, but still comprises the vast majority of attacks seen out there. The more sophisticated “scanners” wouldn’t be caught by default detection configurations anyway. (Imagine a group that wants to gain entry into a building, and every week a different person walks in front of it through a crowded street taking a 3 second sneak peak at it… hard to mark as suspicious.)

The others malicious activities are even more obvious. An IP hosting malware is either:

a)    Consciously distributing it

b)   Has been intruded and is being used as a zombie server

c)    Hosts it for research purposes, in which case it should prevent it from being immediately accessible to any automated host

A real life simile to a) and b) would be meth dealing. Whether you deal directly out of your home or you’re renting your home to a meth dealer, in both cases the home should be raided and everything confiscated, destroyed, and all participants put in jail. Legislation lagging 30 years behind reality, international boundaries and similar impediments make its virtual enforcement more difficult than it sounds.

Finally, spamming should be a capital crime anyway.

On the malicious content by type, we see some more interesting trends. Even with all the hosted content (no, I won’t say the C**** word), web front-ends, mobile media and so on, executable files are still number one in malicious content. This is probably due to wide-open holes in known operating systems and software still being discovered on a continuous basis.

Securing HTML shouldn’t be so difficult if you ask me, but I guess there’s more behind developing a safe/secure HTML rendering engine than is apparent.

I won’t talk about compressed files since it is my belief that any problems related to compressed and .exe files can be blamed entirely on antivirus software alone.

Finally, if Adobe would drop flash in favor of HTML5 and we used a simpler .xml (or similar language) based self-contained document format, we’d have fewer headaches.

So much for talk about the malicious content, the rest of the data is more or less self-explanatory.

All of us at AlienVault — and me personally as information security enthusiast — would like to thank each and every one of you who contribute to the OTX effort.

Download OSSIM and check out the global contributions that are making OTX so valuable.

DK

Mr Wolf Wannabe.

More Posts - Website

Today we are launching the new AlienVault OSSIM v4.0.

You can download it from here.

Apart from tons of new features, we have improved the correlation engine capabilities, two of the most impressive features are:

- Taxonomy correlation based on the Category and Subcategory of the events.
- Correlation using the Open Threat Exchange (OTX) data.

The correlation directives editor has been improved so you won’t need an XML editor anymore (in theory :D).

I will share with you a couple of  basic examples that will teach you how to use the new interface to build correlation rules using this new features.

Example 1: Outbound FTP connection to an external server marked as suspicious

On this example we will see how to detect outbound FTP connections to an external server that is present on the Open Threat Exchange system that indicates that can be a malicious or hacked server where data is being exfiltrated.

To create a new correlation rule click on Intelligence->Correlation Directives and then on the button “Add Directive”

 

 

 

 

 

 

Set the priority to 5:

 

 

 

 

 

 

 

 

 

 

And create the rule for the first level (the correlation directive will have only one level)

 

 

 

 

 

Then select the Taxonomy radio button and set the product type to Firewall

 

 

 

 

 

 

On the next window, select the Taxonomy radio button once again and set the category to Network and the subcategory to FTP_activity

 

 

 

 

 

 

 

The next window is used to set the source and destination conditions. For the Source we will click on HOME_NET, that means the correlation rule with match on events that have a source address belonging to the local networks we have defined in the system. For the destination click on !HOME_NET that will match on destination address that are outside our network. Click also on Reputation options and set “Reputation to” to yes. It will match on destination addresses that are marked as suspicious on the Open Threat Exchange data.

 

 

For the next windows you can let the default values set.

Once you create the correlation directive you have to perform a last step, it is because a small bug on the web interface. Go to Intelligence->Correlation Directives and on the User category click on “Edit XML directive file”:

 

 

 

 

 

As you can see in the following screenshot, add the content type=”detector” to the rule level of the XML file:

 

 

 

 

 

 

Finally click on Restart Server and your correlation rule will be loaded on the system.

Following you can see an example of the correlation rule firing:

 

 

 

 

 

 

 

 

If you click on the details, you will see that the alarm has been fired using an event from a Cisco Pix Firewall

 

 

 

 

 

 

 

 

This correlation rule is very useful to detect information being leaked to external servers by malware or intruders.

 

Example 2: SQL injection followed by error 500 on the web server

In this example we will see how to detect potential SQL injections in our web servers. The rule will detect an SQL injection attack detected by an Intrusion Detection System (IDS) followed by an error 500 on the destination web server that indicates that an error was detected on the web application.

Let’s create a new directive:

 

 


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Let the default values for the next windows.

Then edit your recently created directive and add a new rule level:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

On the next screen you have to set the option Source, From a parent rule: Source IP from level 1 and Destination, From a Parent Rule: Destination IP from level 1 that means the source and destination should match with the values seen in the first level we created.

 

 

 

 

Set the number of ocurrences to 1:

 

 

 

 

 

 

 

The timeout to 10 seconds:

 

 

 

 
 

 

And the reliability to 8:

 

 

 

 

 

 

 

 

 

 

 

 

Now you are done, remember to edit the XML file as we did in the previous example and add the type=”detector” to both rule levels:

 

 

Enjoy it!. Remember if you have any comments or doubts feel free to ask in our brand new Alienvault OSSIM Forum

jaime.blasco

At AlienVault Jaime manages the Lab and runs the Vulnerability Research Team. Prior to working in the AlienVault lab he founded a couple of startups (Eazel, Aitsec) working on web application security, source code analysis and incident response. His background stems from a number of years working in vulnerability management, malware analysis and security researching.

More Posts - Website

Follow Me:
TwitterLinkedIn