Tag Archives: configuration

Network Device Reviews, A Less Common Assessment

Posted on by
3

One of the less common assessments that MicroSolved performs for our clients is a Network Device Review (NDR). These assessments are aimed at helping clients assess the current state of specific devices or system configurations and improving them. 

Common devices assessed via this service include:

  • Firewalls
  • Routers and switches
  • IDS/IPS deployments and configurations
  • Load balancers
  • Workstation and server install and image baselines
  • ICS & SCADA devices from back end to customer premise

This type of assessment is performed using a combination of automated tools and manual time with our security engineers. The methodology leveraged to perform the assessment is very similar to our other assessments, with the engineers doing detailed analysis of attack surfaces and evaluation of relevant controls. Reports follow a more technical path for these services, with a technically focused report set and a small management level summary, keeping the cost of these services significantly less expensive than our deeper pen-testing and fuzzing assessments.

Customers often use these services to perform spot validation or as a part of an overall hardening project to improve their security posture organically. To learn more about the NDR service, get in touch with your account executive or contact us via info (at) micro solved (dot) com for a free conversation about how the NDR can help your organization.

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

Terminal Services Attack Reductions Redux

Posted on by
3

Last week, we published a post about the high frequency of probes, scans and attacks against exposed Windows Terminal Services from the Internet. Many folks commented on Twitter to me about some of the things that can be done to minimize the risk of these exposures. As we indicated in the previous post, the best suggestions are to eliminate them altogether by placing Terminal Services exposures behind VPN connections or through the implementation of tokens/multi-factor authentication. 

Another idea is to implement specific firewall rules that block access to all but a specific set of IP addresses (such as the home IP address range of your admins or that of a specific jump host, etc.) This can go a long way to minimizing the frequency of interaction with the attack surfaces by random attacker tools, probes and scans. It also raises the bar slightly for more focused attackers by forcing them to target specific systems (where you can deploy increased monitoring).

In addition, a new tool for auditing the configuration of Terminal Services implementations came to our attention. This tool, called “rdp-sec-check”, was written by Portcullis Security and is available to the public. Our testing of the tool showed it to be quite useful in determining the configuration of exposed Terminal Services and in creating a path for hardening them wherever deployed. (Keep in mind, it is likely useful to harden the Terminal Services implementations internally to critical systems as well…)

Note that we particularly loved that the tool could be used REMOTELY. This makes it useful to audit multiple customer implementations, as well as to check RDP exposures during penetration testing engagements. 

Thanks to Portcullis for making this tool available. Hopefully between this tool to harden your deployments and our advice to minimize the exposures, we can all drive down some of the compromises and breaches that result from poor RDP implementations.

If you would like to create some threat metrics for what port 3389 Terminal Services exposures might look like for your organization, get in touch and we can discuss either metrics from the HITME or how to use HoneyPoint to gather such metrics for yourself. 

PS – Special thanks to @SecRunner for pointing out that many cloud hosting providers make Terminal Server available with default configurations when provisioning cloud systems in an ad-hoc manner. This is likely a HUGE cause for concern and may be what is keeping scans and probes for 3389/TCP so active, particularly amongst cloud-hosted HITME end points.

PSS – We also thought you might enjoy seeing a sample of the videos that show entry level attackers exactly how to crack weak passwords via Terminal Services using tools easily available on the Internet. These kinds of videos are common for low hanging fruit attack vectors. This video was randomly pulled from the Twitter stream with a search. We did not make it and are not responsible for its content. It may not be safe for work (NSFW), depending on your organization’s policies. 

 

Tip: Pre-loading Wasp Configuration Databases

Posted on by
Reply

Thanks to a couple of users who have provided this excellent tip for reducing the initial number of alerts that come in when you first deploy HoneyPoint Wasp as it learns it’s environment.

The tip is to load an initial copy of Wasp on a trusted, fresh desktop workstation image and then execute all of the applications your organization generally supports. Then, let the Wasp run for about 48 hours and populate its database with the accepted applications and the like from the default image.

Once complete, use copies of this database in your installation across the enterprise. You will then get delta alerts instead of the base alerts for things you already know and trust. This eliminates the initial set of alerts from each Wasp workstation you deploy and greatly reduces the management load of the initial roll out.

Thanks to the two folks who really worked out this method, tested it and wrote up notes for us to share the idea with you. Much appreciated!

To learn more about using Wasp to extend your malware protection, gain security visibility easily to the workstation layer and create anomaly detection techniques for your security program, give us a call or drop us a line. We look forward to sharing tips like these and success stories with you as they come in from users.