Telnet!? Really!?

I was recently analyzing data from the HITME project that was collected during the month of January. I noticed a significant spike in the observed attacks against Telnet. I was surprised to see that Telnet was being targeted at such a high rate. After all, there can’t be that many devices left with Telnet exposed to the internet, right?

Wrong. Very wrong. I discovered that there are still MILLIONS of devices with Telnet ports exposed to the internet. Due to Telnet’s lack of security, be sure to use SSH as opposed to Telnet whenever possible. If you absolutely must control a device via Telnet, at least place it behind a firewall. If you need to access the device remotely, leverage the use of a VPN. Finally, be sure to restrict access to the device to the smallest possible IP range.

The map below shows the geographical locations and number of attacks against Telnet that we observed last month. If you need any help isolating Telnet exposures, feel free to contact us by emailing info <at> microsolved.com.

Screen Shot 2015-02-10 at 11.28.10 AM

 

Podcast Episode 1 is Now Available

This episode is about 45 minutes in length and features an interview with Dave Rose (@drose0120) and Helen Patton (@OSUCISOHelen) about ethics in security, women in STEM roles and career advice for young folks considering Infosec as a career. Have feedback, let me know via Twitter (@lbhuston).

 
As always, thanks for listening and reading stateofsecurity.com!
 
Listen here: 
 
PS – We decided to restart the episode numbers, move to pod bean.com as a hosting company and make the podcast available through iTunes. We felt all of those changes, plus the informal date-based episode titles we were using before made the change a good idea.

Social Media Targeting: A Cautionary Tale

I was recently doing some deep penetration testing against an organization in a red-team, zero knowledge type exercise. The targets were aware of the test at only the highest levels of management, who had retained myself and my team for the engagement. The mission was simple, obtain either a file that listed more than 100 of their key suppliers, or obtain credentials and successfully logon to their internal supply system from an account that could obtain such a file.

Once we laid some basic groundwork, it was clear that we needed to find the key people who would have access to such data. Given the size of this multi-national company and the thousands of employees they had across continents, we faced two choices – either penetrate the network environment and work our way through it to find and obtain the victory data and/or find a specific person or set of persons who were likely to have the data themselves or have credentials and hack them get a shortcut to victory.
 
We quickly decided to try the shortcut for a week or less, preserving time for a hack the network approach should we need it as a backup. We had approximately 6 weeks to accomplish the goal. It turned out, it took less than 6 hours…
 
We turned our TigerTrax intelligence & analytics platform to the task of identifying the likely targets for the shortcut attack. In less than 30 minutes, our intelligence team had identified three likely targets who we could direcly link to the internal systems in question, or the business processes associated with the victory condition. Of these three people, one of them was an extensive participant in their local dance club scene. Their social media profile was loaded with pictures of them dancing at various locales and reviewing local dance clubs and DJs. 
 
A plan was quickly developed to use the dance club angle as an approach for the attack, and a quick malware serving web site was mocked up to look like an new night club in the target’s city. The team them posted a few other sites pointing to a new club opening and opened a social media account for the supposed club’s new name. The next day, the penetration team tested the exploits and malware against the likely OS installs of the victim (obtained from some of their social media data that was shared publicly). Once the team was sure the exploits and malware were likely to function properly, the club’s social media account sent a tweet to the account of the target and several other people linked to the club scene, inviting them to a private “soft opening” of the club — starring the favorite DJ of the target (obtained from his twitter data). Each person was sent a unique link, and only the target’s link contained the exploit and malware. Once the hook was delivered, the team sat back and waited a bit. They continued to tweet and interact with people using the club’s account throughout the rest of the day. Within hours, the target followed the club’s account and visited the exploit site. The exploit worked, and our remote access trojan (RAT) was installed and connected back to us.
 
It took the team about an hour to hoover through the laptop of the target and find the file we needed. About the same time, an automated search mechanism of the RAT returned a file called passwords.xls with a list of passwords and login information, including the victory system in question. The team grabbed the victory files, screen shotted all of our metrics and data dashboards and cleaned up after themselves. The target was none the wiser.
 
When we walked the client through this pen-test and explained how we performed our attack, what controls they lacked and how to improve their defenses, the criticality of social media profiling to attackers became crystal clear. The client asked for examples of real world attackers using such methods, and the team quickly pulled more than a dozen public breach profiles from the last few years from our threat intelligence data.
 
The bottom line is this – this is a COMMON and EFFECTIVE approach. It is trivial for attackers to accomplish these goals, given the time and will to profile your employees. The bad guys ARE doing it. The bigger question is – ARE YOU?
 
To learn more about our penetration testing, social engineering and other security testing services, please call your account executive to book a free education session or send us an email to info@microsolved.com. As always, thanks for reading and until next time, stay safe out there!

RansomWeb Attacks Observed in HITME

Unfortunately, the destructive nature of Ransomware has taken a new turn for the worse.  A new technique called RansomWeb is affecting production web-based applications.  I recently analyzed data from the HITME project and observed several RansomWeb attacks against PHP applications.  I can only assume the frequency of these attacks will increase throughout the year.  As a former Systems Administrator, I can definitively say that it would be a nightmare to bring an application back online that was affected by this variant of Ransomware.  Due to RansomWeb’s destructive nature, it is important to ensure that your organization is actively working to prevent RansomWeb from destroying any critical systems.

The attackers begin the RansomWeb process by exploiting a vulnerability within a web server or web-based application.  Once the server or application have been exploited, the attackers slowly begin encrypting key databases and files.  Once the encryption is complete, the hackers shut down the website/application and begin to demand ransom in exchange for the decryption of the corporation’s files.  Unfortunately, the attackers have even perfected using this process to encrypt system-level backups.

To prevent RansomWeb from affecting your organization, please be sure to complete the following steps on a regular basis:

  • Perform regular vulnerability assessments and penetration testing against your critical applications and servers.
  • Audit your application and system logs for any irregular entries.
  • Verify that you are performing regular application and system backups.
  • Be sure to test the backup/ restore process for your applications and systems on a regular basis.  After all, your backup/ DR process is only as effective as your last successful restore.

If you would like to discuss how we can help you prevent RansomWeb from affecting your production applications, do not hesitate to contact us by emailing info <at> microsolved.com

The Need for an Incident Recovery Policy (IRP)

Organizations have been preparing for information security issues for a number of years now and many, if not most, have embraced the need for an incident response policy and process. However, given the recent spate of breaches and compromises that we have analyzed and been involved in over the last year, we have seen an emerging need for organizations to now embrace a new kind of policy – a security incident RECOVERY policy.
 
This policy should extend from the incident response policy and create a decision framework, methodology and taxonomy for managing the aftermath of a security incident. Once the proverbial “fire has been put out”, how do we clean up the mess, recreate the records we lost, return to business as usual and analyze the impacts all of this had on our operations and long term bottom line? As a part of this process, we need to identify what was stolen, who the likely benefactors are, what conversion events have taken place or may occur in the future, how the losses impact our R&D, operational state, market position, etc. We also need to establish a good working model for communicating the fallout, identified issues, mitigations, insurance claims, discoveries and lessons learned to stakeholders, management, customers, business partners and shareholders – in addition to the insurance companies, regulators and law enforcement.
 
As you can imagine, this can be a very resource intensive process and since post-incident pressues are likely to remain high, stress levels can be approaching critical mass and politics can be rampant, having a decision framework and pre-developed methodology to work from can be a life saver. We suggest following the same policy development process, update timeframes and review/practice schedules as you do for your incident response policy.
 
If your organization would like assistance developing such a policy, or would like to work through a training exercise/practice session with an experienced team, please feel free to work with your account executive to schedule such an engagement. We also have policy templates, work sheets and other materials available to help with best practice-based approaches and policy creation/reviews.

Recently Observed Attacks By Compromised QNAP Devices

Despite the fact that the Shellshock bug was disclosed last fall, it appears that a wide variety of systems are still falling victim to the exploit.  For example, in the last 30 days, our HoneyPoint Internet Threat Monitoring Environment has observed attacks from almost 1,000 compromised QNAP devices.  If you have QNAP devices deployed, please be sure to check for the indicators of a compromised system.  If your device has not been affected, be sure to patch it immediately.

Once compromised via the Shellshock bug, the QNAP system downloads a payload that contains a shell script designed specifically for QNAP devices.  The script acts as a dropper and downloads additional malicious components prior to installing the worm and making a variety of changes to the system.  These changes include: adding a user account, changing the device’s DNS server to 8.8.8.8, creating an SSH server on port 26 and downloading/installing a patch from QNAP against the Shellshock bug.

The map below shows the locations of compromised QNAP systems that we observed to be scanning for other unpatched QNAP systems.  If you have any questions regarding this exploit, feel free to contact us by emailing info <at> microsolved.com.

Screen Shot 2015-01-27 at 1.41.31 PM

The Devil You Think You Know: Risks from Third Party Infrastructure

All modern information infrastructure tends to be an amalgam of stuff you built, other people’s stuff you know you use, and hidden stuff that you are unwittingly dependent on ( yours or someone else’s).

This blog entry is about part of that middle ground – on-premise services that you pay for and are integral to your operation but are in fact built and managed by a third party with whom you have a contractual relationship.

It’s based on my actual experience of late.

Here’s the nut: Any vendor who has a presence within your infrastructure that they manage may have connectivity into that infrastructure that you are unaware of.

The vendor’s infrastructure and yours may effectively be one thing.

The example:

Unplanned Connectivity

The company knew that the vendor had used the provided contractor VPN access at one time.  They had used it to set up their equipment initially.  What they did not know was that part of that set-up routinely involved the establishment of outbound site-to-site VPN tunnels from the vendor’s equipment to the vendor’s datacenter.  Those connections were built at boot time and maintained.  Vendor staff used that VPN access to get to their equipment and, if needed, from their equipment to the company equipment that they provided services for.  There was no company-accessible audit trail.  No log.

Under these conditions, the vendor and the company infrastructure are effectively one.  A compromise of the vendor is a compromise of the company.

What to do?

  • doveryai no proveryai:   It’s an old saw at this point, but always true.   “Trust, but verify”.  That trust may not just be of the vendor.  It may be of your own upper management who engineered the deal.  That can be a tough,  particularly if you are calling into question arrangements that have already been made.   But you didn’t choose this career because it was easy.   Read the doc, ask the questions, get the answers in writing.
  • Egress Filtering: You should control what traffic leaves your enterprise. Strict egress filtering rules would have denied that outbound VPN connection described above.  A daily report of such denies would alert staff to the attempt – and start the necessary round of questions.
  • Monitor your outbound traffic:  Know what’s normal.  You should be generating daily reports from your network logs and from all other intermediary devices (e.g. proxies) about outbound communication sessions – particularly ones of long duration and consistent external IP address targets.  Know what radiates out!
  • Watch your VPN logs:  The vendor stopped using company VPN once it was no longer needed.  VPN access logs would have recorded that cessation. That was an anomaly that should have been called out.  The implication is the company VPN logs were not being analyzed and reported on.  You need to know what normal traffic is for your front door.

Finally: There was nothing intentionally malicious about the vendor’s actions in the example cited.  The vendor techs were just doing their job.

It’s your job to question theirs.

 

 

How I leveraged HoneyPoint during Corporate Acquisitions

Throughout my career, I have worked for organizations that have purchased and integrated 4 companies.  The acquired companies ranged from an organization with revenues of less than $3 million per year to a publicly traded company with annualized revenues of almost $1 billion.  While the acquisitions all carried their own set of challenges, they remain among the highlights of my career.

When I pictured corporate acquisitions, I always envisioned purchasing the next big startup or buying out your leading competitor.  I didn’t realize that a majority of corporate acquisitions are an attempt to leverage existing infrastructure and shared services to turn a failing company into a profitable organization.  When I was informed that my company was about to purchase another organization, I instantly realized I was going to be working with a lot of old hardware, disgruntled employees and vulnerable systems.  Fortunately, I was able to leverage HoneyPoint to address several the aforementioned challenges.

Completing an acquisition can be overwhelming at times.  It’s important to take a step back and look at systems from a bird’s-eye view.  I always found it extremely helpful to deploy HoneyPoint Agent at the start of an acquisition.  I worked diligently to create an Agent deployment that mimicked the infrastructure of the acquired company.  This allowed me to have a centralized view of their network from one HoneyPoint console.  On more than one occasion, HoneyPoint Agent helped me to identify infected machines on the network of a recently acquired company.

Having worked for a company that has been acquired on two separate occasions, I always empathize with the employees of an acquired organization.  While it can be a scary time, it can also be looked at as an opportunity to demonstrate your talent to a new company.  I have met several talented IT Professionals throughout the 4 acquisitions that I have had the privilege of completing.  I was frequently amazed at their ability keep a critical infrastructure running on a nonexistent budget.  Unfortunately, for every talented and cooperative professional, I have encountered a few disgruntled employees.

HoneyPoint has several great features that can help identify a disgruntled employee.  For example, I was able to place documents throughout our network that would log an alert to my HoneyPoint console each time they were opened.  This would have allowed me to easily identify any disgruntled employee that was searching a file server for confidential information.  Deploying these trojanized documents throughout our network taught me a valuable lesson about HoneyPoint…it should be considered a good thing when a deployment does not generate any alerts.  In this instance, it meant that I did not identify any employees that were digging through our file shares for confidential information.

Unfortunately, I have been a part of acquisitions where the IT staff of the acquired organization were not retained.  While it was purely a business decision, the layoffs posed a serious risk of creating disgruntled employees.  This could lead an employee of the acquired company to attempt to cause harm to systems owned and operated by the acquiring organization.  During each acquisition, I deployed HoneyPoint Agents that mimicked the Infrastructure of my company.  This allowed me to identify any instance of an individual attempting to scan systems that were owned by the parent organization.  While I did not catch any individuals in the act, I was able to rest assured knowing that I had the capability to do so.

I highly recommend leveraging HoneyPoint during your next M&A.  It will help you address several of the challenges that are associated with the M&A process.  If you have any questions about HoneyPoint and how it can help your organization, please contact us at info <at> microsolved.com.

Cyber-Civic Responsibility

More and more we are a folk who expect others to protect us from society’s ills and to take care of our dirty work for us. We have police and courts to protect us from violence and larceny. We take it as certain that someone will pick up our garbage, keep our electricity flowing and make sure that our water is clean. And rightly so! After all, isn’t that why we elect officials? Isn’t that why we pay all those fees and taxes that hit us from every side? Life is so complex now that no one has the mental and emotional resources to think and care about every little thing that affects us. We have to draw the line somewhere just to cope and remain sane.

Unfortunately, most of us have put information security and the unrestricted use of our delightful new cyber-toys on the wrong side of that line. We dismissively expect the ISPs, the software developers, the anti-virus personnel, the government, and who knows all else to keep our information secure for us. And they try their best. The problem is that “they” simply can’t do it. Although computer use seems like old and well established technology to many of us, it is really in its infancy and is expanding explosively in unexpected directions. None of the regulations, devices or software packages designed to secure networked computers really work well or for long. They are always too limited, too weak and too late.

The only thing that really has a chance of working is if we all start taking responsibility for our own share of the problem. We need to change our complacent attitudes and realize that it is our civic duty to become actively involved in this concern. It won’t be easy or pleasant. We will need to keep ourselves well-schooled on the subject. We will need to endure security procedures that make computer use a little less convenient and free. And we will need to keep close tabs on the regulators and manufacturers and demand that effective security becomes an integral part of the system. Remember, our place in the world and even our physical safety depends on it! Isn’t that worth a little of our time and patience?

This post by John Davis.

Network Segmentation: A Best Practice We Should All be Using

It would be nice to be able to say that we are winning the war; that network security efforts are slowly getting the better of the bad guys. But I cant do that. Despite all the money being thrown at security tools and hosted services, the cyber-thugs are improving their game at a faster rate than we are. The ten worst known cyber security breaches of this century have all taken place since 2008, and 2013 and 2014 are notorious for their information security incidents.

I think there are a multitude of reasons for this state of affairs to exist. One is confusion, indecisiveness and slow reaction times among regulatory bodies and standards providers. Another is the check the boxcompliance mentality that exists both in government agencies and in the private sector. A third is simply the insane rate of innovation in the information technology realm. There are many more. But despite the reasons, one thing is clear: we have to stop rigidly complying with baseline standards and move into the more flexible and effective world of best practices. And today the best practice I want to touch on is network segmentation.

In our business we see a lot of computer networks that are just flat. There is little or no network segmentation and anyone on the inside can pretty much see everything. I cant begin to tell you how easy this kind of setup makes it for us during penetration testing success is virtually assured! And its amazing how even just basic network segmentation can slow us down or stop us all together.

A good reason to start with network segmentation is that you can go at in easy stages. Maybe you can begin by segmenting off a separate development or test network. Those are pretty basic and can give your networking team some valuable experience for more difficult efforts to come. Then you can ensure that user spaceis separated from server space. Doing just that much can have an amazing effect – it really helps to thwart successful cyber-attacks.

As the team gains confidence in their abilities, they can move onto the next step: real enclaving of the network. This is anything but a trivial effort, and it requires detailed knowledge of the various functions of the different business departments and how information moves into and out of each one of them (a task made very much easier if the company has a good business continuity program and business impact analysis in place). But in the long run these efforts will be well worth the trouble. It is very difficult indeed to gain access to or exfiltrate information from a well enclaved network especially from the Internet.

This blog post by John Davis.