Security visualization

As networks become ever more complex, securing them becomes more and more difficult. The solution is visualization. Using today’s state-of-the-art data visualization techniques, you can gain a far deeper understanding of what’s happening on your network right now. You can uncover hidden patterns of data, identify emerging vulnerabilities and attacks, and respond decisively with countermeasures that are far more likely to succeed than conventional methods.

WordPress TimThumb Botnets Spreads Status

0
4 months ago
in ,

Since the discovery of the WordPress TimThumb vulnerability in August 2011 by Mark Maunder, the vulnerability has been used as botnet recruitment vector, and has now spread in multiple botnets. Hundreds of WordPress blogs have been hacked, allowing potential infection of the blogs visitors, diffusion of spam and phishing campaign, DDoS, hack of other web sites (such as About.us domain name registrar), etc, etc. Some of these infected WordPress were controlled by well known C&C servers used and shared by black hats from around the world.

We are soon six month after the discovery of the vulnerability and a status on the WordPress TimThumb botnets could be done. Are the botnets still active, are less WordPress blogs vulnerable, is the pick of spread over ? We will try, through an analysis of all the WordPress TimThumb vulnerability exploitation attempts against our Honey Net, to answer these questions. The datas collected through our Honey Net are representing only a small part of the real activity of the WordPress TimThumb botnets, but these datas could also represent an extrapolation of the real activities.

List of all detected infected domains

You can find in the following table the complete list of all detected infected domains how were called during the WordPress TimThumb RFI attack, with the domain associated IP address, the country where the blog were hosted, the number of distinct source IPs how have call the related domain during the RFI attack and the live time of the domain name.

We have a total of 202 affected domains. “blogger.com.dollhousedelights.com“, hosted in Vietnam, was the affected domain how was called by the much more distinct source IPs (258), followed by “picasa.com.xpl.be” with 152 distinct source IPs, and at the third place “blogger.com.midislandrental.com” with 110 distinct source IPs.

“picasa.com.xpl.be” and “picasa.computergoogle.co.cc” have the longer live time with 105 days, followed by “wordpress.com.hostdail.com” and “blogger.com.pasbar.com” with 72 days.

Infected blogs countries repartition

You can find in the following graphs (Chart1 – Chart2) the geographically repartition of the infected blogs.

We have a total of 31 different countries for 202 affected domains. United States is in first position with 58.9% (129) of all infected blogs, followed by Australia, Canada and United Kingdom with each 3.7% (8) of all infected blogs.

Infected blogs countries repartition by number of source IPs

You can find in the following graphs (Chart3 – Chart4) the geographically repartition of the infected blogs by number of distinct source IPs how have call the infected blogs.

We have a total of 1734 distinct source IPs for 202 affected domains and 31 different hosting countries. United States is in first position with 48.5% (841), followed by Vietnam with 14% (243), Indonesia with 4.7% (82) and Taiwan with 4.1% (71).

Timeline by day of infected blogs calls and source IPs

You can find in the following timeline (Chart5) a representation by day of the infected blogs number calls and source IPs.

November 2011 was the most active month for the number of source IPs and that in December the number of source IPs has drastically decrease. You can see that during the first half of November the number of infected blogs calls have increase days after days, and since the 22 November the number of infected blogs is stabilized but is not decreasing.

Geographic timeline by day of all source IPs

In this geographic time map we’re loading datas from a Google Spreadsheet (published here). These datas are coming from our HoneyNet and are representing the geographic Wordpress TimThumb Botnet activities from 15-09-2011 to 03-12-2011.

AfterGlow representation of the WordPress TimThumb

By clicking on the following link, you can download an AfterGlow representation of the WordPress TimThumb botnets with links between each nodes.

Conclusion

WordPress TimThumb botnets are still continuing to infect new blogs, but the associated activities are decreasing since second half December. Maybe black hats are still in holidays :) My personal opinion is that we will steal continu to hear about these botnets during complete 2012.

In Memory of FileAve.com Botnet

0
6 months ago
in ,

Good news for every one, FileAve.com is finally down since the 18 October ! In July 2010 I have written a blog post on FileAve.com a free file hosting provider notorious for spreading thousands of malwares. FileAve.com have provide 50 MB free storage and a free sub domain for each created account (ex : http://yourname.fileave.com). FileAve.com was owned and operated by “Ripside Interactive, Inc.“, located in US, and more precisely by “Smith, Scott“, since September 2008. “Ripside Interactive, Inc.” was also owner of ripway.com, another notorious malware hoster.

FileAve.com is present in Clean MX database since the 2007-11-30, in Malc0de database since the 2010-01-11 and in our database since the 2009-02-16.

With the data’s contained in our Honeynet database, I can provide you the following statistics. FileAve.com and associated subdomains were linked to 94 other malware spreaders, but FileAve.com was the most important malware spreader in this botnet. These 95 malware spreaders were regularly contacted, by 1420 other source IP addresses, but not known for hosting malwares, in order to attempt to infect new potential vulnerable web servers or computers.

The median lifetime of the 95 malware spreaders were 5 days, with 6 of them how have a lifetime above 1 year, and 2 of the 6 with a lifetime above 2 years. On the 1420 other source IP addresses, 754 of them were directly connected to FileAve.com IP address.

43 of the malware spreaders were located in South Korea and 32 others were located in US. 837 distinct source IP addresses have contact the malware spreaders located in US and 309 others have contact malware spreaders located in South Korea.

The malware spreaders hosting country how has taken the longest time to shut down the malware spreaders is France, with only 2 malware spreaders located in this country but with an average lifetime of 184 days. The second country is China with 2 malware spreaders and with an average lifetime of 164 days. The third country is Thailand with 2 malware spreaders and with an average lifetime of 127 days. The fourth country is South Korea with 43 malware spreaders and with an average lifetime of 105 days.

FileAve.com botnet golden age have occur between March 2010 and September 2010, with the most active malware spreaders ratio, with the most source IP addresses and the most generated events.

If you are interested in more statistics about FileAve.com activities, I have written an PDF available here. Also I have create a geographic time map of all activities generated by the FileAve.com botnet.

WordPress TimThumb Botnet Visualization and Status

0
6 months ago
in

In a previous blogpost I have demonstrate that the WordPress TimThumb RFI vulnerability is used as a botnet recruitment vector. Since this blogpost 1 month has occur, and two and half months since our HoneyNet is gathering events about this botnet.

Actually we have see 30 different domains, related to 37 different IP addresses used to infect vulnerable WordPress (see table bellow).

These 30 different domains are for now related to 370 IP addresses how are surely infected WordPress. Here a representation on how is linked to how.

Also you can find by clicking on the following link a geo localization time map of all the related IP addresses.

Unix Auditd Authentication Events Analysis and Visualisations with ArcSight Logger

0
8 months ago
in ,

With the free ArcSight Logger L750MB, you can in combination with auditd SmartConnector, gather some useful informations in order to have a better overview on your Unix infrastructure Access Management or to respond to some compliances (ex : PCI-DSS, etc.).

In this blog post we will show some examples on how use ArcSight Logger search engine and visualisation capabilities.

Unix Auditd authentication events analysis

We will first analyse Unix auditd authentication events in order to understand what useful informations we can find.

We assume that login under root account is not allowed and that 500 represent the first usable user account.

We will describe here under different SSH authentication auditd events with they results. You can find in bold some important keywords.

  • Successful SSH authentication auditd events
type=USER_AUTH msg=audit(1316335353.969:348): user pid=32370 uid=0 auid=4294967295 msg='PAM: authentication acct="eromang" : exe="/usr/sbin/sshd" (hostname=macbook.zataz.loc, addr=192.168.178.25, terminal=ssh res=success)'

type=USER_LOGIN msg=audit(1316335353.991:355): user pid=32370 uid=0 auid=500 msg='uid=500: exe="/usr/sbin/sshd" (hostname=macbook.zataz.loc, addr=192.168.178.25, terminal=/dev/pts/0 res=success)'
  • Failed SSH authentication, for a valid user account, auditd events
type=USER_AUTH msg=audit(1316335438.989:362): user pid=32395 uid=0 auid=4294967295 msg='PAM: authentication acct="eromang" : exe="/usr/sbin/sshd" (hostname=macbook.zataz.loc, addr=192.168.178.25, terminal=ssh res=failed)'

type=USER_LOGIN msg=audit(1316335438.990:363): user pid=32395 uid=0 auid=4294967295 msg='acct="eromang": exe="/usr/sbin/sshd" (hostname=macbook.zataz.loc, addr=192.168.178.25, terminal=sshd res=failed)'
  • Failed SSH authentication, for non existing user account, auditd events
type=USER_AUTH msg=audit(1316335506.816:372): user pid=32403 uid=0 auid=4294967295 msg='PAM: authentication acct="?" : exe="/usr/sbin/sshd" (hostname=macbook.zataz.loc, addr=192.168.178.25, terminal=ssh res=failed)'

type=USER_LOGIN msg=audit(1316335506.817:373): user pid=32403 uid=0 auid=4294967295 msg='acct="invaliduser": exe="/usr/sbin/sshd" (hostname=macbook.zataz.loc, addr=192.168.178.25, terminal=sshd res=failed)'
  • Successful TTY authentication auditd events
type=USER_AUTH msg=audit(1316338747.834:381): user pid=2678 uid=0 auid=4294967295 msg='PAM: authentication acct="eromang" : exe="/bin/login" (hostname=?, addr=?, terminal=tty1 res=success)'

type=USER_LOGIN msg=audit(1316338747.867:437): user pid=2678 uid=0 auid=500 msg='op=login id=500 exe="/bin/login" (hostname=?, addr=?, terminal=tty1 res=success)'
  • Failed TTY authentication, for a valid user account, auditd events
type=USER_AUTH msg=audit(1316338880.990:495): user pid=32452 uid=0 auid=4294967295 msg='PAM: authentication acct="eromang" : exe="/bin/login" (hostname=?, addr=?, terminal=tty1 res=failed)'

type=USER_LOGIN msg=audit(1316338880.990:496): user pid=32452 uid=0 auid=4294967295 msg='op=login id=500 exe="/bin/login" (hostname=?, addr=?, terminal=tty1 res=failed)'
  • Failed TTY authentication, for non existing user account, auditd events
type=USER_AUTH msg=audit(1316338916.360:497): user pid=32452 uid=0 auid=4294967295 msg='PAM: authentication acct="?" : exe="/bin/login" (hostname=?, addr=?, terminal=tty1 res=failed)'

type=USER_LOGIN msg=audit(1316338916.360:498): user pid=32452 uid=0 auid=4294967295 msg='op=login acct="invaliduser" exe="/bin/login" (hostname=?, addr=?, terminal=tty1 res=failed)'

For USER_LOGIN auditd type events you will have these results :

  • Count of successful and failed authentication attempts (number of lines in the log).
  • Targeted username through auditd “acct” value, but only for failed attempts.
  • Targeted UID for successful and failed attempts through auditd “uid“, “id” and “auid” values.
  • Targeted device address and hostname (box hosting the auditd.log file, or IP/hostname present in SYSLOG log file).
  • Source address and hostname, only for remote authentication, through auditd “hostname” and “addr” values.
  • Associated terminal through “terminal” value.

FOR USER_AUTH type you will have these results :

  • Count of successful and failed authentication attempts (number of lines in the log).
  • Targeted user name through auditd “acct” value, but only valid user accounts.
  • Targeted device address and hostname (box hosting the auditd.log file, or IP/hostname present in SYSLOG log file).
  • Source address and hostname,  only for remote authentication, through auditd “hostname” and “addr” values.
  • Associated terminal through “terminal” value.

In order to provide Access Management analysis, we will focus on USER_AUTH type. With this type we can detect regular authentications and authentication brute force attacks on valid users, with valid user name display, “acct” value.

Unix Auditd authentication events searches in ArcSight Logger

On ArcSight Logger we can now play with searches in order to retrieve and analyse auditd authentication events.

The following filter will provide you all Unix auditd events.

deviceVendor = "Unix" AND deviceProduct = "auditd"

The following filter will provide you all auditd USER_AUTH type events.

deviceVendor = "Unix" AND deviceProduct = "auditd" AND deviceEventCategory = "USER_AUTH"

In order to analyse Access Management activities, we need to understand how the SmartConnector is categorizing the auditd USER_AUTH event and gather the most important fields.

  • baseEventCount : The number of occurrence of the event if aggregation is active on the SmartConnector.
  • deviceAddress : Targeted device address
  • deviceHostName : Targeted device hostname.
  • sourceAddress : The attacker address.
  • sourceHostName : The attacker hostname, if available.
  • sourceUserName : The targeted authentication username.
  • destinationProcessName : Targeted process name. “/usr/sbin/sshd” for SSH or “/bin/login” for TTY console in our cases.
  • deviceCustomString3 : The authentication result. “success” or “failed” in our cases.
  • deviceCustomString6 : For the associated terminal or tty. “ssh” or “ttyx” in our cases.
  • deviceReceiptTime : The event associated timestamp.

In the following scenario, the target was under SSH brute force attack, and the attacker has gain access to the box. We will conduct an analysis, provide you some useful search queries and operators, and try to demonstrate you that using ArcSight Logger for forensics analysis is quiet easy.

This search query is based on the last 24 hours, and we can directly see through the Logger radar that a lot of USER_AUTH requests have been made. In order to only focus on the specific fields, we will execute the following query.

deviceVendor = "Unix" AND deviceProduct = "auditd" AND deviceEventCategory = "USER_AUTH"  | cef deviceAddress deviceHostName sourceAddress sourceHostName sourceUserName destinationProcessName deviceCustomString3 deviceCustomString6 deviceReceiptTime baseEventCount

“cef” search operator will extracts values for specified fields from matching CEF events. To view only the extracted values, select “User Defined Fieldsets” in the search drill down menu. “cef” search operator will also allow you to use other search operators such as “sort“, “chart“, etc.

To focus on failed authentication attempts, execute the following query.

deviceVendor = "Unix" AND deviceProduct = "auditd" AND deviceEventCategory = "USER_AUTH"  AND deviceCustomString3 = "failed" | cef deviceAddress deviceHostName sourceAddress sourceHostName sourceUserName destinationProcessName deviceCustomString6 deviceReceiptTime  baseEventCount

To focus on successful authentication, execute the following query.

deviceVendor = "Unix" AND deviceProduct = "auditd" AND deviceEventCategory = "USER_AUTH"  AND deviceCustomString3 = "success" | cef deviceAddress deviceHostName sourceAddress sourceHostName sourceUserName destinationProcessName deviceCustomString6 deviceReceiptTime  baseEventCount

Browsing in the events is a quiet boring, ArcSight Logger provide you a query operator how will permit you to create visualisations with your search results.

  • Chart creation to count sourceUserName occurrences

Don’t forget that USER_AUTH auditd type don’t provide the targeted user name for non existing users, so we will only focus on existing sourceUserName.

deviceVendor = "Unix" AND deviceProduct = "auditd" AND deviceEventCategory = "USER_AUTH" AND sourceUserName IS NOT NULL | cef deviceAddress deviceHostName sourceAddress sourceHostName sourceUserName destinationProcessName deviceCustomString3 deviceCustomString6 deviceReceiptTime  baseEventCount | chart sum(baseEventCount) AS Total by sourceUserName

Associated to the result chart, you will also have a result table.

You can also, change the type of chart, by clicking on the upper right corner icon of the result chart frame. The available chart type are column, bar, pie, area, line, stacked column or stacked bar.

  • Chart creation to count Terminal occurences
deviceVendor = "Unix" AND deviceProduct = "auditd" AND deviceEventCategory = "USER_AUTH" AND sourceUserName IS NOT NULL | cef deviceAddress deviceHostName sourceAddress sourceHostName sourceUserName destinationProcessName deviceCustomString3 deviceCustomString6 deviceReceiptTime  baseEventCount | chart sum(baseEventCount) AS Total by deviceCustomString6

We can see that majority of the authentications are through SSH and that some are through TTY.

  • Chart creation to count sourceUserName and Terminal occurences
deviceVendor = "Unix" AND deviceProduct = "auditd" AND deviceEventCategory = "USER_AUTH" AND sourceUserName IS NOT NULL | cef deviceAddress deviceHostName sourceAddress sourceHostName sourceUserName destinationProcessName deviceCustomString3 deviceCustomString6 deviceReceiptTime  baseEventCount | chart sum(baseEventCount) AS Total by sourceUserName deviceCustomString6

  • Chart creation to count sourceUserName and authentication occurences
deviceVendor = "Unix" AND deviceProduct = "auditd" AND deviceEventCategory = "USER_AUTH" AND sourceUserName IS NOT NULL | cef deviceAddress deviceHostName sourceAddress sourceHostName sourceUserName destinationProcessName deviceCustomString3 deviceCustomString6 deviceReceiptTime  baseEventCount | chart sum(baseEventCount) AS Total by sourceUserName deviceCustomString3

We can see that only user name “eromang” has successful login.

  • Chart creation to count sourceUserName “eromang“, authentication and Terminal occurences
deviceVendor = "Unix" AND deviceProduct = "auditd" AND deviceEventCategory = "USER_AUTH" AND sourceUserName = "eromang" | cef deviceAddress deviceHostName sourceAddress sourceHostName sourceUserName destinationProcessName deviceCustomString3 deviceCustomString6 deviceReceiptTime  baseEventCount | chart sum(baseEventCount) AS Total by sourceUserName deviceCustomString3 deviceCustomString6

We can discover that user name “eromang” has successful login through “ssh” and “tty” terminals.

  • Chart creation to count sourceUserName “eromang” and successful authentication occurences
deviceVendor = "Unix" AND deviceProduct = "auditd" AND deviceEventCategory = "USER_AUTH" AND sourceUserName = "eromang" AND deviceCustomString3 = "success" | cef deviceAddress deviceHostName sourceAddress sourceHostName sourceUserName destinationProcessName deviceCustomString3 deviceCustomString6 deviceReceiptTime  baseEventCount | chart sum(baseEventCount) AS Total by sourceUserName deviceCustomString3 deviceCustomString6

  • Char creation to count sourceUserName “eromang”, successful “ssh” authentication and sourceAddress occurences
deviceVendor = "Unix" AND deviceProduct = "auditd" AND deviceEventCategory = "USER_AUTH" AND sourceUserName = "eromang" AND deviceCustomString3 = "success" AND deviceCustomString6 = "ssh" | cef deviceAddress deviceHostName sourceAddress sourceHostName sourceUserName destinationProcessName deviceCustomString3 deviceCustomString6 deviceReceiptTime  baseEventCount | chart sum(baseEventCount) AS Total by sourceAddress

We can discover two different source IP addresses.

  • Chart creation to count “ssh” authentications for both sourceAddress occurences
deviceVendor = "Unix" AND deviceProduct = "auditd" AND deviceEventCategory = "USER_AUTH"  AND (sourceAddress = "192.168.178.25" OR sourceAddress = "192.168.178.21")  AND sourceUserName = "eromang" AND deviceCustomString6 = "ssh"
| cef deviceAddress deviceHostName sourceAddress sourceHostName sourceUserName destinationProcessName deviceCustomString3 deviceCustomString6 deviceReceiptTime  baseEventCount | chart sum(baseEventCount) AS Total by deviceCustomString3 sourceAddress

We can discover that sourceAddress “192.168.178.21” has hundreds of failed login and one successful login.

  • Query to find the exact time sourceAddress has breach the target
deviceVendor = "Unix" AND deviceProduct = "auditd" AND deviceEventCategory = "USER_AUTH"  AND sourceAddress = "192.168.178.21" AND sourceUserName = "eromang" AND deviceCustomString6 = "ssh" AND deviceCustomString3 = "success" | cef deviceReceiptTime

As you can see by this example, ArcSight Logger has some powerful search engine queries and visualisation outputs how will help you to do forensics investigations for your assets.

Honeynet Forensic Challenge 5 Log Mysteries – Analysis – Part 2

0
1 year ago
in ,

Following my last post “Part 1 : SSH activities forensics“, I continue to analyse the SSH activities.

Emerging Threats is defining a default “SSH Brute Force” rule, “2001219“, with these triggers :

  • The source IP should be the same
  • The destination port should be 22/tcp
  • The sensor target should be unique (not the ssh server)
  • The thresholds are 5 matching conditions within 2 minutes

Emerging Threats rule don’t care about :

  • If multiples SSH server are in the same $HOME_NET
  • If the targeted user name is unique or not

ArcSight is defining a default “Brute Force Logins”, with these triggers :

  • The source IP should be the same
  • The target IP should be the same
  • The target port should be the same
  • The target username should be the same
  • The thresholds are 5 matching conditions within 2 minutes

We will then consider that 5 matching conditions within 2 minutes by the same source IP as our trigger to detect a SSH brute force attack.

First, we will check the stats for each source IPs how have fail to access the box and never succeeded (third Google gadget).

All the failed SSH connexions uper or equal to 5 in a timeframe of 120 seconds will be considered as this kind of attack.

The detailed stats are avaible in this Google Document under the “SSH – 5″ worksheet.

On 25 source IPs, how have fail to access the box and never succeeded, 19 would be detected by ET 2001219 rule.

4 of the 6 source IPs, non detected as a brute force attack, with a number of connexion uper than 20 are interesting, it is a real non detected brute force attack.

On ArcSight, with the default “Brute Force Logins” correlation rule, only 13 on 25 source IPs would be detected as a brute force attack.

Now we will do the same analysis for each source IPs how have fail to access the box and finaly succeeded (second Google gadget).

All the failed SSH connexions uper or equal to 5 in a timeframe of 120 seconds will be considered as this kind of attack.

The detailed stats are avaible in this Google Document under the “SSH – 6″ worksheet.

On 7 source IPs, how have fail to access the box and never succeeded, 6 would be detected, by ET 2001219 rule.

On ArcSight, with the default “Brute Force Logins” correlation rule, only 4 on 7 source IPs would be detected as a brute force attack.

More the “Brute Force Attacks” attempts are distributed in time, more patient you are, more you switch between a few targeted user accounts, less you will be discovered. ArcSight and Emerging Threats default rules will detect nothing.

Get Adobe Flash player
Go to Top