Setting up Honeypots
Most if not all of the handlers run honeypots, sinkholes, SPAM traps, etc in various locations around the planet. As many of you are aware they are a nice tool to see what is going on on the Internet at a specific time. Setting up a new server the other day it was interesting to see how fast it was touched by evilness. Initially it wasn't even intended as a honeypot, but it soon turned into one when "interesting" traffic started turning up. Now of course mixing business (servers original intended use) and pleasure (honeypot) aren't a good thing, so honeypot it is.
It was quite disheartening to see how fast evilness turned up:
- SSH brute force attacks port 22 < 2minutes
- SSH brute force attacks port 2222 < 4 hours
- Telnet - 8 Minutes
- Coldfusion checks ~ 30 minutes
- SQLi Check ~ 15 minutes
- Open Proxy check 3128 - 81 minutes
- Open Proxy Check 80 - 35 minutes
- Open proxy check 8080 - 48 minutes
Which got me thinking about a few things and hence this post. There are two things I'm interested in firstly when running Honeypots what do you use? There are some great resources and different tools, so what works for you. This one I just set up using the 404 project components from this site. I used Kippo for 2222 and for the rest I used actual product configured to bounce pretty much every request. It doesn't get me exactly what they are doing, but it gives me a first indication, plus I ran out of time :-(
The second thing I'd like to know is, when you set up the Honeypot for the first time how long did it take to get a hit? On our site we have a survival time. It would be interesting to know what the survival time for SSH, FTP, telnet, proxies etc is. So the next time you set up a honey pot, or if you still have the logs going back that far take a look and share. SSH with a default password less than 2 minutes. What are your stats?
Cheers
Mark
(PS if you are going to set one up, make sure you fully understand what you are about to do. You are placing a deliberately vulnerable device on the internet. Depending on your location you may be held liable for stuff that happens (IANAL). It it gets compromised, make sure it is somewhere where it can't hurt you or others. )
Google Drive Phishing
In the past we have seen malware being delivered via Google Docs. You would receive an email stating that a document had been shared and when you clicked the link bad things would start to happen. In recent weeks the same approach has increasingly been used to Phish. You would receive an email along these lines:
Hello,We sent you an attachment about your booking using Google DriveI have sent the attachment for you using Google Drive So Click the Google Drive link belowto view the attachment..<button>Google Drive</button>Once the link is clicked you are sent through to a web site where you are presented with the following screen:
Clicking on any of these will ask you for a userid and password for that service. The link in the email should be easily recognised by people as obviously not being a Google link, but many still do not check this. If you are doing an awareness campaign or reminder, maybe include some info on recognising phishing links.
Cheers
Mark
Packet Challenge for the Hivemind: What's happening with this Ethernet header?
Earlier this week, a user submitted one of those "odd packets" we all like. The packet was acquired with tcpdump, without the "-x" or "-X" option, but still, tcpdump decided to dump the entire packet in hexadecimal. I have seen tcpdump do things like this before, and usually attributed it to "packet overload". If I have tcpdump write the same traffic to disk (using the -w option) and later read it back with -r, I don't see this questionable traffic.
But I never bothered to really look into it. So today, returning from the dentist and under the influence of Novacaine after crown prep, I decided what better thing to do but to play a bit with packets.
Here is the setup:
I am running tcpdump on my firewall. I have it listen on all interfaces. The exact command line:
sudo tcpdump -i any -nn -xx not ip and not ip6 and not arp
Now if I got this filter right, I should see no IPv4, no IPv6 and no ARP . At first, I got packets like this:
21:39:55.404619 Out 00:e0:4c:68:e0:7d ethertype Unknown (0x0003), length 344: 0x0000: 0004 0001 0006 00e0 4c68 e07d 0000 0003 0x0010: 4510 0148 0000 0000 8011 2e93 0a05 00fe 0x0020: ffff ffff 0043 0044 0134 cb27 0201 0600 0x0030: 1223 3456 0000 8000 0000 0000 0a05 004a 0x0040: 0a05 00fe 0000 0000 000e f316 a4a6 0000 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 (removed remainder: all "0").
Interestingly, the packet has an "off" ethernet header that looks like it got an additional two bytes, followed by what looks like a normal IPv4 header.
On a second attempt, using the same filter, I even got some packets that got interpreted as IPv4, even though my filter should exclude them:
21:44:01.919690 IP 10.128.0.11.56559 > 10.5.1.12.80: Flags [.], ack 421172865, win 403, length 0 0x0000: 0000 0001 0006 8ab0 1e25 1fcb 0000 0800 0x0010: 4500 0028 b78a 4000 4006 6daa 0a80 000b 0x0020: 0a05 010c dcef 0050 69b5 295b 191a 9681
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter
Comments