Using HoneyPoint to Inventory Windows Boxes on a Segment

For quite some time now, we have been using HoneyPoint Agent and Console to do some passive inventory and mapping exercises for clients, particularly those involved in ICS and SCADA deployments where active scanning to get inventories is often strongly discouraged. We had particular success with a specific client in this space a couple of weeks ago, and I wanted to discuss it here, since it has proven itself to be a useful tool and is on the top of my mind at the moment.

To get an inventory of the Windows systems on a collision domain, you simply install the Agent on a Linux box (or I suggest using the virtual appliance we already have built for your ease) and implement it and the Console. Once HoneyPoint is operational, you configure a UDP listener on port 138. From there, all of the NETBios speaking Windows systems will begin to send traffic to the host, as per the usual behavior of those systems. In this case, however, HoneyPoint will capture each source IP and log it to the Console. It will also capture the UDP datagrams from that conversation and place them as event data in the logs. By reviewing the source IPs, you can quickly and easily take stock of the Windows systems on the collision domain without sending any traffic at all to the systems. As a bonus, if you dig into the datagram data, you will also see the names of the hosts and other information.

Most of the time, this technique captures only Windows boxes, but if you have other devices out there running NETBios, they will likely get detected as well. This can include embedded systems, Unix systems running SAMBA, printers and copiers, Windows CE systems (often seen in many field equipment deployments), etc. You might be surprised what you can find.

Try this with a laptop, and move the laptop around your environment. You can pretty quickly and easily get an inventory by collision domain. You can also try dialing other NETBios ports and see if you get traffic that is routed across your switching fabric. Depending on your configuration, you might be able to gather a great deal of inventory data from a single location (especially if your network is flat and switches are poorly configured).

Give this a shot or get in touch if you would like us to come onsite and perform the inventory for you. We think it is a pretty useful technique and one that many folks are enjoying the benefits of. Let us know what you think when you give it a run in your network!

As always, thanks for reading, and until next time, stay safe out there!

PS – You can also do this with HoneyPoint Personal Edition on a Linux system, which makes it very easy and cheap to do if you don’t want to invest in a full blown HoneyPoint Security Server implementation. (You should invest though, it is a FANTASTIC detection tool!)

**(The link above is for HPPE on Windows, but if you purchase a license and contact us, we will send you the Linux build right away. You can’t easily capture port 138/UDP traffic in Windows HPPE because Windows has those ports in use…)

Brent Huston to Lead ICS/SCADA Honeypot Webinar with SANS

Our Founder and CEO, Brent Huston (@lbhuston) will be leading a SANS webinar on ICS/SCADA honeypots. The webinar is scheduled for November, 25th, 2013 and you can find more information and register by visiting this page.

The webinar will cover when honeypots are and are not useful, basic deployment strategies and insights into using them for detection in field deployments and control environments. 

Check it out, tune in and give Brent a shout out on Twitter. Thanks for reading and we hope you enjoy the webinar.

Blast From the Past: D-Link Probes in the HITME

We got a few scans for an old D-Link router vulnerability that dates back to 2009. It’s interesting to me how long scanning signatures live in online malware and scanning tools. This has lived for quite a while. 

Here are the catches from a HoneyPoint Personal Edition I have deployed at home and exposed to the Internet. Mostly, this is just to give folks looking at the scans in their logs an idea of what is going on. (xxx) replaces the IP address… 

2013-10-02 02:46:13 – HoneyPoint received a probe from 71.103.222.99 on port 80 Input: GET /HNAP1/ HTTP/1.1 Host: xxxx User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Win32) WebWasher 3.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://xxxx/ Authorization: Basic YWRtaW46dWA+NXhZQlU1d2VR Connection: keep-alive

2013-10-02 03:22:13 – HoneyPoint received a probe from 71.224.194.47 on port 80 Input: GET /HNAP1/ HTTP/1.1 Host: xxxx User-Agent: Opera/6.x (Linux 2.4.8-26mdk i686; U) [en] Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://xxxx/ Authorization: Basic YWRtaW46InkwYi4qMF5wL05G Connection: keep-alive

This probe is often associated with vulnerable D-Link routers, usually older ones, those made between 2006 and mid-2010. The original release and proof of concept exploit tool is here. The scan has also been embedded into several scanning tools and a couple of pieces of malware, so it continues to thrive.

Obviously, if you are using these older D-Link routers at home or in a business, make sure they are updated to the latest firmware, and they may still be vulnerable, depending on their age. You should replace older routers with this vulnerability if they can not be upgraded. 

The proof of concept exploit also contains an excellent doc that explains the HNAP protocol in detail. Give it a read. It’s dated, but remains very interesting.

PS – As an aside, I also ran the exploit through VirusTotal to see what kind of detection rate it gets. 0% was the answer, at least for that basic exploit PoC. 

Scanning Targets for PHP My Admin Scans

Another quick update today. This time an updated list of the common locations where web scanning tools in the wild are checking for PHPMyAdmin. As you know, this is one of the most common attacks against PHP sites. You should check to make sure your site does not have a real file in these locations or that if it exists, it is properly secured.

The scanners are checking the following locations these days:

//phpMyAdmin/scripts/setup.php
//phpmyadmin/scripts/setup.php
/Admin/phpMyAdmin/scripts/setup.php
/Admin/phpmyadmin/scripts/setup.php
/_PHPMYADMIN/scripts/setup.php
/_pHpMyAdMiN/scripts/setup.php
/_phpMyAdmin/scripts/setup.php
/_phpmyadmin/scripts/setup.php
/admin/phpmyadmin/scripts/setup.php
/administrator/components/com_joommyadmin/phpmyadmin/scripts/setup.php
/apache-default/phpmyadmin/scripts/setup.php
/blog/phpmyadmin/scripts/setup.php
/cpanelphpmyadmin/scripts/setup.php
/cpphpmyadmin/scripts/setup.php
/forum/phpmyadmin/scripts/setup.php
/php/phpmyadmin/scripts/setup.php
/phpMyAdmin-2.10.0.0/scripts/setup.php
/phpMyAdmin-2.10.0.1/scripts/setup.php
/phpMyAdmin-2.10.0.2/scripts/setup.php
/phpMyAdmin-2.10.0/scripts/setup.php
/phpMyAdmin-2.10.1.0/scripts/setup.php
/phpMyAdmin-2.10.2.0/scripts/setup.php
/phpMyAdmin-2.11.0.0/scripts/setup.php
/phpMyAdmin-2.11.1-all-languages/scripts/setup.php
/phpMyAdmin-2.11.1.0/scripts/setup.php
/phpMyAdmin-2.11.1.1/scripts/setup.php
/phpMyAdmin-2.11.1.2/scripts/setup.php
/phpMyAdmin-2.5.5-pl1/index.php
/phpMyAdmin-2.5.5/index.php
/phpMyAdmin-2.6.1-pl2/scripts/setup.php
/phpMyAdmin-2.6.1-pl3/scripts/setup.php
/phpMyAdmin-2.6.4-pl3/scripts/setup.php
/phpMyAdmin-2.6.4-pl4/scripts/setup.php
/phpMyAdmin-2.6.4-rc1/scripts/setup.php
/phpMyAdmin-2.6.5/scripts/setup.php
/phpMyAdmin-2.6.6/scripts/setup.php
/phpMyAdmin-2.6.9/scripts/setup.php
/phpMyAdmin-2.7.0-beta1/scripts/setup.php
/phpMyAdmin-2.7.0-pl1/scripts/setup.php
/phpMyAdmin-2.7.0-pl2/scripts/setup.php
/phpMyAdmin-2.7.0-rc1/scripts/setup.php
/phpMyAdmin-2.7.5/scripts/setup.php
/phpMyAdmin-2.7.6/scripts/setup.php
/phpMyAdmin-2.7.7/scripts/setup.php
/phpMyAdmin-2.8.2.3/scripts/setup.php
/phpMyAdmin-2.8.2/scripts/setup.php
/phpMyAdmin-2.8.3/scripts/setup.php
/phpMyAdmin-2.8.4/scripts/setup.php
/phpMyAdmin-2.8.5/scripts/setup.php
/phpMyAdmin-2.8.6/scripts/setup.php
/phpMyAdmin-2.8.7/scripts/setup.php
/phpMyAdmin-2.8.8/scripts/setup.php
/phpMyAdmin-2.8.9/scripts/setup.php
/phpMyAdmin-2.9.0-rc1/scripts/setup.php
/phpMyAdmin-2.9.0.1/scripts/setup.php
/phpMyAdmin-2.9.0.2/scripts/setup.php
/phpMyAdmin-2.9.0/scripts/setup.php
/phpMyAdmin-2.9.1/scripts/setup.php
/phpMyAdmin-2.9.2/scripts/setup.php
/phpMyAdmin-2/
/phpMyAdmin-2/scripts/setup.php
/phpMyAdmin-3.0.0-rc1-english/scripts/setup.php
/phpMyAdmin-3.0.0.0-all-languages/scripts/setup.php
/phpMyAdmin-3.0.1.0-english/scripts/setup.php
/phpMyAdmin-3.0.1.0/scripts/setup.php
/phpMyAdmin-3.0.1.1/scripts/setup.php
/phpMyAdmin-3.1.0.0-english/scripts/setup.php
/phpMyAdmin-3.1.0.0/scripts/setup.php
/phpMyAdmin-3.1.1.0-all-languages/scripts/setup.php
/phpMyAdmin-3.1.2.0-all-languages/scripts/setup.php
/phpMyAdmin-3.1.2.0-english/scripts/setup.php
/phpMyAdmin-3.1.2.0/scripts/setup.php
/phpMyAdmin-3.4.3.1/scripts/setup.php
/phpMyAdmin/
/phpMyAdmin/scripts/setup.php
/phpMyAdmin/translators.html
/phpMyAdmin2/
/phpMyAdmin2/scripts/setup.php
/phpMyAdmin3/scripts/setup.php
/phpmyadmin/
/phpmyadmin/scripts/setup.php
/phpmyadmin1/scripts/setup.php
/phpmyadmin2/
/phpmyadmin2/scripts/setup.php
/phpmyadmin3/scripts/setup.php
/typo3/phpmyadmin/scripts/setup.php
/web/phpMyAdmin/scripts/setup.php
/xampp/phpmyadmin/scripts/setup.php
<title>phpMyAdmin

Telnet Passwords Used In Brute Force Attacks

Just a quick post today, but I wanted to give you some insight into the Telnet scans we have been seeing lately. Here are the passwords that have been used to target logins on port 23 on one of our HITME sensors in the United States. This particular system emulates a login, and the probes appear to be automated. We saw no evidence of any manual probes on this sensor in the last month that targeted telnet.

The passwords used in brute force attacks on telnet (used against the usual root/admin/etc users…): 

default
1234
220
428
436
Admin
D-Link
admin
cobr4
dreambox
echo
enable
home-modem
l
password
private
public
root
sh
user

Keep a careful eye on any systems with Telnet exposed to the Internet. They are a common attraction point to attackers.

Just a Reminder, SIP is a Popular Scanning Target

I just wanted to give you a quick reminder that SIP scanning remains quite popular on the Internet. These probes can lead to compromise and fraud against your VoIP systems. Make sure you do not have VoIP systems exposed to the Internet without proper controls. If you review your logs on the Internet perimeter, SIP scans will look similar to this:

This was captured from the HITME using HoneyPoint Personal Edition.

2013-09-30 17:02:18 – HoneyPoint received a probe from 207.127.61.156 on port 23

Input: OPTIONS sip:nm SIP/2.0

Via: SIP/2.0/TCP nm;branch=foo

From: <sip:nm@nm>;tag=root

To: <sip:nm2@nm2>

Call-ID: 50000

CSeq: 42 OPTIONS

Max-Forwards: 70

Content-Length: 0

Contact: <sip:nm@nm>

Accept: application/sdp

Keep an inventory of your VoIP exposures. They remain a high area of interest for attackers.

Ask The Experts: Favorite HoneyPoint Component

This time around, we got a question from a client where HoneyPoint was being demoed for the experts.

Q: “What is your favorite component of HoneyPoint and why? How have you used it to catch the bad guys?”

Jim Klun started off with:

My favorite component is the simplest: HoneyPoint Agent. 

It’s ease of deployment and the simple fact that all alerts from an agent are of note – someone really did touch an internal service on a box where no such service legitimately exists – makes it attractive. 
No one will argue with you about meaning. 

I have recently seen it detect a new MSSQL worm (TCP 1433) within a large enterprise – information obtained from my own laptop. The Agent I had deployed on the laptop had a 1433 listener. It captured the payload from an attacking desktop box located in an office in another US state. 

The HoneyPoint Agent info was relayed to a corporate team that managed a global IPS. They confirmed the event and immediately updated their IPS that was – ideally – protecting several hundred thousand internal machines from attack. 

Honeypoint Agent: It’s simple, it works.

Adam Hostetler added his view:

I’m a simple, no frills guy, so I just like the regular old TCP listener component built into Agent. We have stood these up on many engagements and onsite visits and picked up unexpected traffic. Sometimes malware, sometimes a misconfiguration, or sometimes something innocuous (inventory management). I also find it useful for research by exposing it to the Internet.

John Davis closed with a different view:

My favorite HoneyPoint is Wasp. Watching how skilled attackers actually compromise whole networks by initially compromising one user machine gives me the shivers! Especially since most networks we see aren’t properly enclaved and monitored. If I were a CISO, knowing what is on my network at all times would be of primary importance; including what is going on on the client side! Wasp gets you that visibility and without all the traditional overhead and complexity of other end-point monitoring and white listing tools.

Have a question about HoneyPoint? Want to talk about your favorite component or use case scenario? Hit us on Twitter (@lbhuston or @microsolved). We can’t wait to hear from you. Feel free to send us your question for the experts. Readers whose questions we pick for the blog get a little surprise for their contribution. As always, thanks for reading and stay safe out there! 

Using HoneyPoint as a Nuance Detection System in Utility Companies

I often get asked about how utility companies deploy HoneyPoint in an average implementation. To help folks with that, I whipped up this quick graphic that shows a sample high level deployment. 

Thanks for reading! Let me know what you think, or if you have an interest in discussing an implementation in your environment.

HoneyPoint Used to Confirm Skype URL Indexing

Last week, several sources were talking about the indexing of URLs that happen inside supposedly secure and private Skype sessions. There was a bit of press about it and we thought it would be fun to test it out and easy to do with HoneyPoint Personal Edition. Here’s how we did it:

  • First, we stood up a HoneyPoint Personal Edition and dilated port 80 with a web listener. We configured it to look like a default under construction page on an IIS box. We then exposed it to the Internet.
  • In order to cut down on noise from scanning while we were testing, we decided we would use a target page in our test URL of vixennixie.htm, since scanners aren’t generally looking for that page, if we get scanned while we are testing, it won’t interfere with our data gathering and analysis.
  • Next, we created a Skype chat between to members of the team and made sure each of us was configured for full security.
  • Once this was confirmed, we passed the URL: http://target_ip/vixennixe.htm between us. The time was 1:13pm Eastern.
  • Then, we waited.
  • Lo and behold, we got this nearly 12 hours later:

                     2013-05-22 01:09:45 – HoneyPoint received a probe from 65.52.100.214 on port 80 Input: HEAD /vixennixie.htm HTTP/1.1 Host: target_ip Connection: Keep-Alive

A whois of 65.52.100.214 shows:

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#

#
# Query terms are ambiguous. The query is assumed to be:
# “n 65.52.100.214”
#
# Use “?” to get help.
#

#
# The following results may also be obtained via:
# http://whois.arin.net/rest/nets;q=65.52.100.214?showDetails=true&showARIN=false&ext=netref2
#

NetRange: 65.52.0.0 – 65.55.255.255
CIDR: 65.52.0.0/14
OriginAS:
NetName: MICROSOFT-1BLK
NetHandle: NET-65-52-0-0-1
Parent: NET-65-0-0-0-0
NetType: Direct Assignment
RegDate: 2001-02-14
Updated: 2012-03-20
Ref: http://whois.arin.net/rest/net/NET-65-52-0-0-1

OrgName: Microsoft Corp
OrgId: MSFT
Address: One Microsoft Way
City: Redmond
StateProv: WA
PostalCode: 98052
Country: US
RegDate: 1998-07-10
Updated: 2011-04-26
Ref: http://whois.arin.net/rest/org/MSFT

OrgNOCHandle: ZM23-ARIN
OrgNOCName: Microsoft Corporation
OrgNOCPhone: +1-425-882-8080
OrgNOCEmail: noc@microsoft.com
OrgNOCRef: http://whois.arin.net/rest/poc/ZM23-ARIN

OrgTechHandle: MSFTP-ARIN
OrgTechName: MSFT-POC
OrgTechPhone: +1-425-882-8080
OrgTechEmail: iprrms@microsoft.com
OrgTechRef: http://whois.arin.net/rest/poc/MSFTP-ARIN

OrgAbuseHandle: HOTMA-ARIN
OrgAbuseName: Hotmail Abuse
OrgAbusePhone: +1-425-882-8080
OrgAbuseEmail: abuse@hotmail.com
OrgAbuseRef: http://whois.arin.net/rest/poc/HOTMA-ARIN

OrgAbuseHandle: ABUSE231-ARIN
OrgAbuseName: Abuse
OrgAbusePhone: +1-425-882-8080
OrgAbuseEmail: abuse@hotmail.com
OrgAbuseRef: http://whois.arin.net/rest/poc/ABUSE231-ARIN

OrgAbuseHandle: MSNAB-ARIN
OrgAbuseName: MSN ABUSE
OrgAbusePhone: +1-425-882-8080
OrgAbuseEmail: abuse@msn.com
OrgAbuseRef: http://whois.arin.net/rest/poc/MSNAB-ARIN

RTechHandle: ZM23-ARIN
RTechName: Microsoft Corporation
RTechPhone: +1-425-882-8080
RTechEmail: noc@microsoft.com
RTechRef: http://whois.arin.net/rest/poc/ZM23-ARIN

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#

I’ll leave it to the reader to decide what they think about the data. You can draw your own conclusions. We just appreciated yet another use for HoneyPoint and a quick and dirty project to play with. Thanks for reading!