Category Archives: Detection in Depth

Here’s Why You Don’t Want RDP on the Internet

Posted on by
Reply

For those of you that are unfamiliar with the HITME project, it is a set of deployed HoneyPoints that gather real-world, real-time attacker data from around the world. The sensors gather attack sources, frequency, targeting information, vulnerability patterns, exploits, malware and other crucial event data for the technical team at MSI to analyze. We frequently feed these attack signatures into our vulnerability management service to ensure that our customers are tested against the most current forms of attacks being used on the Internet.

It’s also important that we take a step back and look at our HITME data from a bird’s-eye view to find common attack patterns. This allows us to give our customers a preemptive warning in the event that we identify a significant increase in a specific threat activity. We recently analyzed  some of the data that we collected during the month of November. We found that over 47% of the observed attacks in the public data set were against the Remote Desktop Protocol (RDP)(often also known as Microsoft Terminal Services). This was more than attacks against web servers, telnet servers and FTP servers combined!

Be sure that all recommended security measures are applied to RDP systems. This should include requiring the use of RDP clients that leverage high levels of encryption. If you need any assistance verifying that you are protected against attacks against your terminal servers, feel free to contact us by sending an email to info(at)microsolved(dot)com.

This post by Adam Luck.

Remember, Log Analysis is Important, Especially Now

Posted on by
Reply

Remember, during the holiday season, attacks tend to increase and so do compromises. With vacations and staff parties, monitoring the logs and investigating anomalies can quickly get forgotten. Please make sure you remain vigilant during this time and pay close attention to logs during and just after holiday breaks.

As always, thanks for reading and we wish you a safe and happy holiday season!

Client Calls HoneyPoint a “No Lose” Deployment

Posted on by
1

One of the clients we were working with recently wanted me to share their thoughts on deploying HoneyPoint Security Server with the blog audience.

His company recently installed the HoneyPoint Security Server suite into their network. Their management teams were a little nervous, at first, that offering a honeypot to attackers might attract bad people to their networks. But, when the security team explained that these were going to be simply deployed on the INTERNAL networks and not visible from the Internet, so someone would already have to be inside the network to see them, they gained approval. The security team explained that they planned to use HoneyPoint as a supplement to their existing perimeter network IDS, and their log monitoring tools.

The security team convinced their immediate manager of the HoneyPoint product by describing it as a “No Lose” product to deploy. If they dropped in the HoneyPoint Agents and captured bad actors or malware moving in the network, they would win by identifying existing compromises. If they dropped in HoneyPoint and never got a hit at all, they would win, and could tell the management that even upon closer examination with the new detection tools, the network seemed to be clean of malware and overt attacker activity. This, in combination with the other forms of detection and reporting they were doing would further strengthen their position with management that the security team was remaining vigilant. 

In the end, the team observed a few pieces of malware within the first 90 days and quickly eliminated the infections. They then began to plan on deploying HoneyPoint Agent into a malware black hole, in coordination with their internal DNS team. As of this writing, the deployment in the new position should go live within 30 days. In most cases, teams using HoneyPoint in this fashion quickly identify other more deeply hidden malware. The security team looks forward to leveraging the data from the HoneyPoint black hole to clean the environment more aggressively.

So, there you have it. Another client strikes a win with HoneyPoint. You can learn more about this “No Lose” product by getting in touch with your MSI account executive. You can also find more information by clicking here. 

Best Practices for DNS Security

Posted on by
2

I wanted to share with you a great FREE resource that I found on the Cisco web site that details a great deal of information about DNS and the best practices around securing it. While, obviously, the content is heavy on Cisco products and commands, the general information, overview and many of the ideas contained in the article are very useful for network and security admins getting used to the basics of DNS.

Additionally, there are great resources listed, including several free/open source tools that can be used to manage and monitor DNS servers. 

If you are interested in learning more about DNS or need a quick refresher, check this article out. 

You can find it here.

Several other resources are available around the web, but this seems to be one of the best summaries I have seen. As always, thanks for reading and let me know on Twitter (@lbhuston) if you have other favorite resources that you would like to share.

The Big Three Part 2: Incident Detection

Posted on by
5

Did you know that less than one out of five security incidents are detected by the organization being affected? Most organizations only find out they’ve experienced an information security incident when law enforcement comes knocking on their door, if they find out about it at all, that is. And what is more, security compromises often go undetected for months and months before they are finally discovered. This gives attackers plenty of time to get the most profit possible out of your stolen information, not to mention increasing their opportunities for further compromising your systems and the third party systems they are connected to.

Of the Big Three strategies for fighting modern cyber-crime, (incident detection, incident response and user education and awareness), incident detection is by far the hardest one to do well. This is because information security incident detection is not a simple process. No one software package or technique, no matter how expensive and sophisticated, is going to detect all security events (or even most of them to be completely honest). To be just adequate to the task, incident detection requires a lot of input from a lot of systems, it requires knowledge of what’s supposed to be on your network and how it works, it requires different types of security incident detection software packages working together harmoniously and, most importantly, it requires human attention and analysis.

First of all, you need complete sources of information. Even though it can seem to be overwhelming, it behooves us to turn on logging for everything on the network that is capable of it. Many organizations don’t log at the workstation level for example. And you can see their point; most of the action happens at the server and database level. But the unfortunate reality is that serious security compromises very often begin with simple hacks of user machines and applications.

Next, you need to be aware of all the software, firmware and hardware that are on your network at any given time. It is very difficult to monitor and detect security incidents against network resources that you aren’t even aware exist. In fact, I’ll go a step further and state that you can improve your chances of detection significantly by removing as much network clutter as possible. Only allow the devices, applications and services that are absolutely necessary for business purposes to exist on your network. The less “stuff” you have, the fewer the attack surfaces cyber-criminals have to work with and the easier it is to detect security anomalies.

The third thing that helps make information security incident detection more manageable is tuning and synchronizing the security software applications and hardware in your environment. We often see organizations that have a number of security tools in place on their networks, but we seldom see one in which all of the output and capabilities of these tools have been explored and made to work together. It is an unfortunate fact that organizations generally buy tools or subscribe to services to address particular problems that have been brought to their attention by auditors or regulators. But then the situation changes and those tools languish on the network without anyone paying much attention to them or exploring their full capabilities. Which brings to the most important factor in security incident detection: human attention and analysis.

No tool or set of tools can equal the organizational skills and anomaly detection capabilities of the human brain. That is why it is so important to have humans involved with and truly interested in information security matters. It takes human involvement to ensure that the security tools that are available are adequate to the task and are configured correctly. It takes human involvement to monitor and interpret the various outputs of those tools. And it takes human involvement to coordinate information security efforts among the other personnel employed by the organization. So if it comes down to spending money on the latest security package or on a trained infosec professional, I suggest hiring the human every time! 

—Thanks to John Davis for this post!

Monitoring: an Absolute Necessity (but a Dirty Word Nonetheless)

Posted on by
3

There is no easier way to shut down the interest of a network security or IT administrator than to say the word “monitoring”. You can just mention the word and their faces fall as if a rancid odor had suddenly entered the room! And I can’t say that I blame them. Most organizations do not recognize the true necessity of monitoring, and so do not provide proper budgeting and staffing for the function. As a result, already fully tasked (and often times inadequately prepared) IT or security personnel are tasked with the job. This not only leads to resentment, but also virtually guarantees that the job is will not be performed effectively.

And when I say human monitoring is necessary if you want to achieve any type of real information security, I mean it is NECESSARY! You can have network security appliances, third party firewall monitoring, anti-virus packages, email security software, and a host of other network security mechanisms in place and it will all be for naught if real (and properly trained) human beings are not monitoring the output. Why waste all the time, money and effort you have put into your information security program by not going that last step? It’s like building a high and impenetrable wall around a fortress but leaving the last ten percent of it unbuilt because it was just too much trouble! Here are a few tips for effective security monitoring:

  • Properly illustrate the necessity for human monitoring to management, business and IT personnel; make them understand the urgency of the need. Make a logical case for the function. Tell them real-world stories about other organizations that have failed to monitor and the consequences that they suffered as a result. If you can’t accomplish this step, the rest will never fall in line.
  • Ensure that personnel assigned to monitoring tasks of all kinds are properly trained in the function; make sure they know what to look for and how to deal with what they find.
  • Automate the logging and monitoring function as much as possible. The process is difficult enough without having to perform tedious tasks that a machine or application can easily do.
  • Ensure that you have log aggregation in place, and also ensure that other network security tool output is centralized and combined with logging data. Real world cyber-attacks are often very hard to spot. Correlating events from different tools and processes can make these attacks much more apparent. 
  • Ensure that all personnel associated with information security communicate with each other. It’s difficult to effectively detect and stop attacks if the right hand doesn’t know what the left hand is doing.
  • Ensure that logging is turned on for everything on the network that is capable of it. Attacks often start on client side machines.
  • Don’t just monitor technical outputs from machines and programs, monitor access rights and the overall security program as well:
  • Monitor access accounts of all kinds on a regular basis (at least every 90 days is recommended). Ensure that user accounts are current and that users are only allocated access rights on the system that they need to perform their jobs. Ensure that you monitor third party access to the system to this same level.
  • Pay special attention to administrative level accounts. Restrict administrative access to as few personnel as possible. Configure the system to notify proper security and IT personnel when a new administrative account is added to the network. This could be a sign that a hack is in progress.
  • Regularly monitor policies and procedures to ensure that they are effective and meet the security goals of the organization. This should be a regular part of business continuity testing and review.
Thanks to John Davis for writing this post.

HoneyPoint IP Protection Methodology

Posted on by
5

Here’s another use case scenario for HoneyPoint Security Server. This time, we show the methodology we use to scope a HoneyPoint implementation around protecting a specific set of Intellectual Property (IP). 

If you would like an in-depth discussion of our process or our capability, please feel free to reach out to us and schedule a call with our team. No commitment and no hard sale, guaranteed.

If the graphic below is blurry on your device, you can download a PDF version here.

HP_IPProtection

Using HoneyPoint to Inventory Windows Boxes on a Segment

Posted on by
7

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

Posted on by
5

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.