Home > Dionaea, Honeypot, Tool-Kit > mimic-nepstats.py

mimic-nepstats.py

2009/11/10

As I discussed in my last post about Dionaea I am really impressed with the improvements to logging capabilities over Nepenthes. I’ve now had a Dionaea system online for ~24hours, which while it isn’t enough data to draw any meaningful statistics, it has provided enough data to work on some new tools. I had been intending to extend my Nepenthes tools to parse the logs and enter data into a database for additional and simpler analysis. This was promptly squashed with the migration to Dionaea, but the theory has proven to be a good one as Dionaea’s default logging to an SQLite database has made development much quicker and easier.

To get a feel for the new system, and to keep my capabilities up to speed, I’ve spent this evening writing a script to provide the same information for a Dionaea system that my Nepenthes statistics script provided previously. As usual, the script can be found over at InfoSanity, here. An initial set of results from my system is below for an example:

Statistics engine written by Andrew Waite – http://www.infosanity.co.uk

Number of submissions: 11
Number of unique samples: 10
Number of unique source IPs: 8

First sample seen: 2009-11-09 14:19:15.518382
Last sample seen: 2009-11-10 18:35:28.235052
SystemrRunning: 1 day, 4:16:12.716670
Average daily submissions: 11.0

Most recent submissions:
2009-11-10 18:35:28.235052, 195.90.106.212, emulate://, a4dde6f9e4feb8a539974022cff5f92c
2009-11-10 16:23:12.925538, 195.93.135.67, tftp://195.93.135.67/ssms.exe, 1d419d615dbe5a238bbaa569b3829a23
2009-11-10 16:00:14.846435, 195.170.57.28, tftp://195.170.57.28/ssms.exe, fd28c5e1c38caa35bf5e1987e6167f4c
2009-11-10 15:39:48.598303, 195.46.34.91, http://zonetech.info/61.exe, beee7a74712b2e3c84182c1bf18750ae
2009-11-10 13:00:29.916721, 195.95.170.138, emulate://, ddf1259a8fcef0776054460ebdf3cae4

Andrew Waite

Advertisements
Categories: Dionaea, Honeypot, Tool-Kit
  1. Markus
    2009/11/11 at 08:41

    Hi,

    query listing which dcerpc call got addressed how often, result looks like this:

    attacks|dcerpc_uuid|dcerpcservice_name|dcerpc_opnum|dcerpc_op|vuln
    3899|12345778-1234-abcd-ef00-0123456789ac|samr|62||
    3406|3919286a-b10c-11d0-9ba8-00c04fd92ef5|DSSETUP|9|DsRolerUpgradeDownlevelServer|MS04-11
    438|000001a0-0000-0000-c000-000000000046|ISystemActivator|4|RemoteCreateInstance|MS04-12
    207|4d9f4ab8-7d1c-11cf-861e-0020af6e7c57|DCOM|0|RemoteActivation|MS03-26
    73|4b324fc8-1670-01d3-1278-5a47bf6ee188|SRVSVC|31|NetPathCanonicalize|MS08-67
    37|12345778-1234-abcd-ef00-0123456789ac|samr|64||
    30|367abb81-9844-35f1-ad32-98f038001003|SVCCTL|27||
    19|8d9f4e40-a03d-11ce-8f69-08003e30051b|PNP|54|PNP_QueryResConfList|MS05-39

    Query:
    SELECT
    COUNT(*) AS attacks,
    dcerpc_uuid,
    dcerpcservice_name,
    dcerpc_opnum,
    ( SELECT dcerpcserviceop_name FROM dcerpcserviceops WHERE dcerpcservice = x.dcerpcservice and dcerpcserviceop_opnum = y.dcerpc_opnum ) AS dcerpc_op,
    ( SELECT dcerpcserviceop_vuln FROM dcerpcserviceops WHERE dcerpcservice = x.dcerpcservice and dcerpcserviceop_opnum = y.dcerpc_opnum ) AS vuln
    FROM
    dcerpcs as y
    JOIN dcerpcservices AS x ON( dcerpc_uuid = dcerpcservice_uuid)
    GROUP BY
    dcerpc_uuid,
    dcerpc_opnum
    ORDER BY
    COUNT(*)
    DESC;

    The tables dcerpcservices and dcerpcserviceops do not exist ‘yet’, you’ll have to update to current svn, and start dionaea, it will add the new tables to your existing database and populate them during startup.

  2. 2009/11/11 at 08:53

    Hi Markus,

    thanks for the tip, definitely should be useful for mapping active/trending attacks. I’ll add it to my ever growing list of queries to implement, logging to SQL has my head spinning with possibilities.

    And thanks for the time and effort it must be taking to develop these systems. I have enjoyed my time working with the systems you and the other devs have produced.

    Andrew

  3. asdf
    2009/11/19 at 23:48

    Nice script but you have a bug. If uptime is less than 1 day the daily averages will break as it tries to divide by 0. Just needs something like:

    if uptime.days > 0:
    averageDownloads = numSubmissions / uptime.days
    else:
    averageDownloads = numSubmissions

    • 2009/11/20 at 08:09

      Nice catch, I’ve never run with less than a days worth of logs so I didn’t get caught out in my testing (no excuse I know…). I’ll implement your fix and update.

      Thanks for letting me know.

  1. 2009/12/10 at 20:12
  2. 2010/06/21 at 18:08
Comments are closed.
%d bloggers like this: