Home » Posts tagged 'threatintel'

Tag Archives: threatintel

CHN v1.5 released

We’re pleased to announce the release of version 1.5 of CHN. This new version includes a number of bugfixes, new features, and a new home for documentation.

In order to support versioned documentation, we’ve moved all our documentation to https://communityhoneynetwork.readthedocs.io/. This enables us to build documentation for future releases as we go, and you to get a sneak peek at future features!

The major new feature is the inclusion of deployment scripts for honeypots in the CHN interface. Take a look at the instructions here to see how easy this has become! As a teaser, here’s a screenshot:

Scripted deploy using CHN server
Deploying Cowrie

We hope today is a good day for you to try out CHN, and give us feedback!

— Jesse



A Quick Adventure in AWS

The Friday before Labor Day, I went through the exercise of setting up a new CHN instance; the server on a local VCL-like Ubunutu 18 image, and cowrie and dionaea honeypots in each of three EC2 regions (Sydney, Singapore, Sao Paulo), and one cowrie honeypot in the same VCL IP space, for a total of 7 honeypots. All told, this took about 45 minutes (no automation on the EC2 setup, just creating a t2.nano image with minimal specs). Most of this time was spent fumbling through EC2 setup and setting up some simple bash scripts to copy/paste for the host setup. Actual time spent setting up each honeypot was probably closer to 2 minutes (mostly time spent pulling images over the network).

The following Tuesday I pulled some stats to get a sense of what those honeypots saw over the holiday weekend.

$ curl -s “http://${CHN_SERVER}/api/intel_feed/?api_key=${API_KEY}&hours_ago=96&limit=10000” |jq ‘.meta’
“size”: 3070,
“query”: “intel_feed”,
“options”: {
“limit”: “10000”,
“hours_ago”: “96”

This command is hitting the CHN server API endpoint to get a list of all honeypot hits for the last 96 hours. That’s not a bad haul of malicious IP’s of 96 hours. But how applicable is that data to OUR network?

First I examined incoming flow records, and found that we had inbound connections from 1055 of the original CHN IP’s in that time frame, or put another way, of all the IP’s we collected in that 96 hour period, we found that 34% of them visited our network in that same time frame. Next I compared the CHN IP’s against our threat intelligence sources for that same time period (so any locally generated threat intel from honeypots, network flow detections, host log reports, etc.) and found that in the same time frame our existing mechanisms detected 340 of these IP addresses (11% over all CHN IP’s, 32% of the locally active CHN IP’s).

In other words, our internal honeypots, threat intelligence feeds, and all other detection methods identified only 32% of the attacking IP addresses identified with honeypots distributed across multiple networks. I think this speaks powerfully to the case for operating and sharing honeypot data across numerous networks.

I’d also like to point out that our process for honeypot builds is now much easier (and more reliable). Our documentation now defaults to using images, built by us, hosted on Docker Hub, which eliminates many of the issues we saw in building the images locally. Building locally gives you a lot of flexibility to integrate into your central management as you wish, but using pre-built images GREATLY speeds spin-up time.

If you’ve been putting off trying out CHN, please set aside a couple hours on your calendar to try it out. If you ARE using the system today, it would be great if you could share your stories with us.

— Jesse

Join private STINGAR mailing list

Interested parties are encouraged to interact with the team via the project Github pages or in the Gitter IM community, which gives us a public space for quick questions.

Academic institutions can email Alex Merck at team-stingar@duke.edu to be added to the private STINGAR mailing list and Slack workspace.

Please include information about your organization’s interest in the STINGAR project in your request.