My Honeypot is Trendy, My Honeypot is Unpopular
One of the products of the Dshield project (https://isc.sans.edu/howto.html) is seeing what is trending in scanning activity (https://isc.sans.edu/trends.html). This sometimes drives a "request for packets" like my last shift (https://isc.sans.edu/forums/diary/Request+for+Packets+Port+15454/23888/). Most of the responses we get from such requests are logs of probes, or pcaps of SYN traffic because the ports are just not commonly used, so there's not a lot of honeypots set up for them already.
In the last reqeust I sent out, I thought of how helpful it would be to have my own open-every-port sensor to go along with my distributed closed-on-every-port sensors. Then I imagined how my logs would fill up with SSH brute forcing, and propbes for open web proxies. That didn't sound very fun or interesting-- but a sensor open on every port that isn't popular sounded more interesting.
To proof-of-concept this, I set up a listener for a range of ports which listened for ports 15000-16000. This helped confirm that port 15454 wasn't the only port targeted in the scan, and it turned out to be just a boring RDP search for weak Admin sessions.
When port 52869 showed up on the trending report, I opened up 52000 through 53000 to see what landed. This soon captured the traffic discussed in https://isc.sans.edu/forums/diary/When+Cameras+and+Routers+attack+Phones+Spike+in+CVE20148361+Exploits+Against+Port+52869/23942/
This morning's trending report noted 8983, so I retuned to ports 8000 through 9000. Unfortunately ports 8080 and 8443 are in that range so "hello proxy probes." Ignoring that I sit back and wait. The sensor is on a commercial ISP in the United States, so anything IoT centric should be hitting that soon enough.
No hits on 8983 yet, but something odd hits 8545. I'm not sure what that is off the top of my head. Generally the strategy is:
- search the dshield port report for user comments
- shodan.io search
The request that came in looks like:
The dshield report has a comment that mateches the traffic we saw:
So thanks JB, that saves me steps 2 and 3.
Sensor Ideas for DEFCON
Chris D wrote in to ask: "I'll be attending the DEFCON conference in Vegas next week which we all know will be ripe with practitioners practitioning and think this would be a good opportunity to catch and observe new exploits or techniques. Is there any application or VM image that you would recommend that can run on a laptop or Pi that poses an attractive target but is purposeful in collecting security info like PCAP data and logs that I can monitor after the fact? My thought is to have something I can carry with me while I travel and then put up on the public wifi and just see what kind of magnificent beasts I capture."
I know that DEFCON has this reputation of being "the worlds most hostile network," but I wouldn't expect to see the latest and greatest zero-days being deployed there. The only thing I've actually seen hacked on the DEFCON network were WiFi Pineapples. It is however, and interesting opportunity to collect traffic from various protocols and media.
I've done my share of "go somewhere interesting, set up a sensor, collect traffic to play with later." In my case, not a lot of post-game analysis ever went into what I captured, but it's a good exercise for when you get that phonecall sending you out on a real incident and you need to "go somewhere less-interesting, set up a sensor, and collect traffic."
Personally, I would add extra instrumentation to whatever laptop you take with you to use there. Collecting firewall logs, or setting up honeypot listeners to capture traffic and trend to compare to other networks might be insightful and not require any extra hardware.
Wi-fi specific equipment to join and monitor the public wi-fi might be of interest to you, either simply join with a hardrened and instrumented system and collect what comes at you, or going a more passive approach with sniffing via kismet. You're millage will vary depending on how they've secured it.
There will be more going on there than just Wi-fi:
- Bluetooth, which you can see what is advertising without much special hardware, or set up your own advertised service to see what comes knocking.
- Zigbee/Zwave which is somewhat popular in the IoT space.
- Sofware Defined Radio (SDR) the mind boggles at what might be available here, there's probably a lot of noise and activity on the ISM bands during some of the demonstrations and in the villages.
What portable hardware whould you suggest for a sensor, and what sort of traffic would you want to target with it?
Comments