Category Archives: Emerging Threats

Coming to Grips with DDoS – Response

Posted on by
1

In our first two blogs concerning Distributed Denial of Service (DDoS) attacks and small service industries, we presented measures organizations can take to prepare for and defend against DDoS attacks. In this final installment on the subject, we will discuss methods of response to these incidents.

The first thing to do when you think you are under DDoS attack is to not panic. Calm and considered responses are always more effective than immediately jumping in and possibly cutting off legitimate connection requests. An ill-considered response on your part could cause the very denial of service your attacker intended in the first place. The best thing you can do is to immediately access your incident response plans and begin to implement those pre-planned procedures you worked so hard on. We are constantly amazed at how many organizations fail to follow their own response planning in the heat of a real incident! 

The next step in the process is traffic (log) analysis. You need to be able to identify what type of attack is being perpetrated and the kinds of bogus requests that are being made. This is where large log capacities and log aggregation tools come in very handy. Being able to view a large amount of data from a central console truly helps you recognize patterns in the attack. Since application layer attacks that employ IP spoofing are presently being used, pattern and type recognition are often the only means you have to discern good traffic from bad.

Once you are able to get a handle on what the bad traffic looks like, you can start filtering it out. This is best done by appliances as close to the network edge as possible. You can also work with your ISP which may be able to assist with filtering as well as other mechanisms such as rate and connection limiting.

After the attack is under control, don’t forget to work with law enforcement agencies such as the FBI and US-CERT. They are interested in these events and may be able to assist you in finding and dealing with the perpetrators. Reporting incidents is important because it is crucial to know the number and types of DDoS attacks that are really taking place out there in order to effectively respond to them. Reporting ends up being good for everybody!

Finally, it is very important to conduct lessons learned meetings and to adjust your incident response and business continuity planning. Table top exercises and other incident preparation techniques are helpful, but nothing helps you learn the hard lessons like a real incident. Why waste the only valuable thing to come out of the whole mess!

This series is written by John Davis, MicroSolved, Inc.

Coming to Grips with DDOS – Defend

Posted on by
3

In our first blog about Distributed Denial of Service (DDoS) attacks and small service industries, we discussed measures that organizations should take to prepare themselves for DDoS attacks. In this second installment, we will go over some methods that are useful in defending networks from these attacks. (The third and final installment in this series will deal with responding to DDoS attacks).

One good way to defend your network from DDoS attacks is to hire a service organization that specializes in the problem. They typically employ algorithm-based firewalls, large networks, monitoring, and other techniques to thwart these attacks, and can be very effective. However, these services are also pretty expensive and impractical for smaller organizations unless the threat level is very high indeed. The good news is that you can do a lot to defend yourselves from DDoS attacks.

The first step is knowing exactly what it is that you are defending. Computer networks tend to grow organically and it is a sad fact that most organizations have a very imperfect picture of how their networks are set up and how they behave. To defend against DDoS, it is important to know what typical network traffic looks like throughout the business year. This helps you set proper thresholds for automated detection devices and ensures quick detection of the onset of events such as DDoS attacks.

Another step you can take to help defend against DDoS attacks is to consider a cloud-based approach for your web services. With the traffic volumes DDoS attacks can currently generate, internal web servers at smaller organizations are sure to be overwhelmed. But by employing a content distribution network in a cloud setting you vastly increase your capacity, reduce the chance of any one server becoming unserviceable and are able to deal with the event more efficiently.

It is also important to work with your Internet Service Provider (ISP) during DDoS attacks. Your ISP could help in many ways including source blocking, scrubbing, load distribution and rate limiting. In addition, it should be remembered that many DDoS attacks are launched as diversions to cover up other attacks against organizations. Ensuring that your network is properly enclaved and monitored can go a long way in protecting your information and control assets during these attacks.

This series is written by John Davis, MicroSolved, Inc.

Coming to Grips with DDoS – Prepare

Posted on by
3

This post introduces a 3 part series we are doing covering distributed denial of service attacks (DDoS) and helping organizations prepare for them. The series will cover 3 parts, Prepare, Defend and Respond. 

Part 1 of 3 – Prepare.

Distributed Denial of Service (DDoS) attacks use networks of compromised computers (botnets) or web servers (brobots) to flood organization websites with so much traffic that it causes them to fail. This is especially worrying for financial institutions and utilities which rely so very heavily on the availability of their services and controls. DDoS attacks are also mounted by attackers to hide fraud or other hacking activities being perpetrated on networks. Although these types of attacks are not new, they are presently increasing in frequency and especially in sophistication. Application layer DDoS attacks do a good job of mimicking normal network traffic and recent DDoS attacks have been measured at a huge 65 Gb (nearly 10 times the previous high point). The purpose of this blog is to discuss some methods small organizations can employ to properly prepare for DDoS attacks. (Later articles in this series will discuss means for defending against and responding to these attacks).

The first thing any organization should do in this effort is proper pre-planning. Ensure that DDoS is included in your risk assessment and controls planning efforts. Include reacting to these attacks in your incident response and business continuity plans. And as with all such plans, conduct practice exercises and adjust your plans according to their results. In all our years in business, MSI has never participated in a table top incident responce or disaster recovery exercise that didn’t expose planning flaws and produce valuable lessons learned.

Next, your organization should consider DDoS when choosing an ISP. It helps immensely to have an Internet provider that has enough resources and expertise to properly assist if your organization is targeted for one of these attacks. Ensure that you develop a close relationship with your ISP too – communicate your needs and expectations clearly, and find out from them exactly what their capabilities and services really are. 

Finally on the preparation side of the problem, make sure that you keep well informed about DDoS and the actual threat level it poses to your organization. Keep active in user groups and professional organizations. Use the net to gather intelligence. The Financial Service Information Sharing and Analysis Center (FS-ISAC) has plenty of useful and up to date information on DDoS. You can even turn the World Wide Web against the enemy and use it to gather intelligence on them!

–This article series is written by John Davis of MSI. 

PS – This is NOT a problem you can “purchase your way out” of. Organizations can’t and should not buy huge amounts of bandwidth as a preparation for DDoS. The cost impacts of such purchases are not effective, nor is bandwidth size an effective control in most cases. Note that some technology solutions for packet scrubbing and the like do exist. Your milage may vary with these solutions. MSI has not reviewed or tested any of the DDoS technology products as a part of this series.

Go Phish :: How To Self Test with MSI SimplePhish

Posted on by
5

Depending on who you listen to, phishing (especially spear phishing), is either on the increase or the decrease. While the pundits continue to spin marketing hype, MSI will tell you that phishing and spearphishing are involved in 99% of all of the incidents that we work. Make no mistake, it is the attack of choice for getting malware into networks and environments.

That said, about a year ago or more, MSI introduced a free tool called MSI SimplePhish, which acts as a simplified “catch” for phishing campaigns. The application, which is available for Windows and can run on workstations or even old machines, makes it quite easy to stand up a site to do your own free phishing tests to help users stay aware of this threat.

To conduct such a campaign, follow these steps:

PreCursor: Obtain permission from your security management to perform these activities and to do phishing testing. Make sure your management team supports this testing BEFORE you engage in it.

1.  Obtain the MSI SimplePhish application by clicking here.

2. Unzip the file on a the Windows system and review the README.TXT file for additional information.

3. Execute application and note the IP address of the machine you are using. The application will open a listening web server on port 8080/TCP. Remember to allow that port through any host-based firewalls or the like.

4. The application should now be ready to catch phishing attempts and log activity when the following URL structure is clicked on: http://<ip address of the windows system>:8080/ and when that URL is accessed, a generic login screen should be displayed.

5. Create an email message (or SMS, voice mail, etc.) that you intend to deliver to your victims. This message should attempt to get them to visit the site and enter their login information. An example:

Dear Bob,

This message is to inform you that an update to your W-2 tax form is required by human resources. Given the approaching tax deadline, entering this information will help us to determine if an error was made on your 2012 W-2. To access the application and complete the update process, please visit the online application by clicking here. (You would then link the clicking here text to your target URL obtained in step 4.)

6. Deliver the messages to your intended targets.

7. Watch and review the log file MSISimplePhishLog.txt (located in the same directory as the binary). Users who actually input a login and password will get written to the log as “caught”, including their IP address, the login name and **the first 3 characters** of the password they used.  Users who visit the page, but do not login, will be recorded as a “bite”, including their IP address.

** Note that only the first 3 characters of the password are logged. This is enough to prove useful in discussions with users and to prove their use, but not enough to be useful in further attacks. The purpose of this tool is to test, assess and educate users, not to commit fraud or gather real phishing data. For this reason, and for the risks it would present to the organization, full password capture is not available in the tool and is not logged. **

8. Let the exercise run for several days, in order to catch stragglers. Once complete, analyze the logs and report the information to the security stakeholders in your organization. Don’t forget to approach the users who use successfully phished and give them some tips and information about how they should have detected this type of attack and what they should do to better manage such threats in the future.

That’s it – lather, rinse and repeat as you like!

If you would like to do more advanced phishing testing and social engineering exercises, please get in touch with an MSI account executive who can help put together a proposal and a work plan for performing deep penetration testing and/or ongoing persistent penetration testing using this and other common attack methods. As always, thanks for reading and until next time, stay safe out there!

Quick Thought on CSRF Attacks

Posted on by
Reply

Yesterday, I listened to @Grap3_Ap3 present at the Columbus OWASP local chapter on Cross Site Request Forgery (CSRF). While this attack has been around since 2001, it continues to show a strong presence in web applications across a range of platforms. Phil spent a lot of his time talking about content management systems on the public Internet, but we have seen CSRF very widely exploitable on embedded devices.

Embedded devices, often equipped with rather rudimentery web servers and applications for management, have proven to be a searing hot pain point for CSRF in our research. While that isn’t shocking or new, I definitely see an interesting and potentially dangerous collision between the growth of the “Internet of Things” and web vulnerabilities. Today, some of these platforms are toys, or novelty tools built into home appliances – BUT, the future of internetworking of our devices and our physical lives means that these web controls will eventually have larger impacts on our day to day lives.

What happens when a CSRF attack can be used to trick your teenager into clicking on a picture on the web that while they view it, they also execute a command to raise the temperature on your refrigerator to unsafe levels? Or when an embedded link in an email tricks you into a click that turns your oven onto super heat clean mode without your knowledge? Sound like a prank? Maybe. Extend it to thermostats, home automation and consumer control over alternative energy controls like solar panels and such and it might take a new form.

We are on a course of collision. Our inattention to information security and the exploding complexity and technology dependencies will soon come together in ways that may surprise us. Ignore the hyperbole, but think about it rationally. Isn’t it time we worked with organizations who make products to demand an increase in protection from some of these basic known attacks? In the future, consumers and organizations alike will vote with their dollars. How will you spend yours?

Threat Update: Wide Scale Phishing in Progress

Posted on by
Reply

GlobalDisplay Orig

Just a quick update about the ongoing threat from malware dropped by phishing attacks. There are a lot of phishing attacks currently in progress. Fishing has been a leading form of compromise for quite some time and indicators appear to point to an increasing amount of phishing attacks and a larger amounts of damage from successful exploitation.

Many organizations are reporting wide spread phishing using recycled, older malware including Zeus, Tepfer and other common remote access tools. In some cases, these malware are repackaged or otherwise modified to evade anti-virus detection. Attackers are showing medium to high levels of success with these attacks.

Once compromised, the normal bot installation and exfiltration of data occurs. For most organizations that don’t play a role in critical infrastructure, this likely means credentials, customer information and other commercially valuable data will be targeted. For critical infrastrcuture organizations, more specific  design, future state and architectural data is being targeted along with credentials, etc.

Organizations should be carefully and vigilantly reviewing their egress traffic. They should also be paying careful attention to user desktop space and the ingress/egress from the user workstation DMZ or enclaves (You DO have your user systems segregated from your core operations, correct???). Remember, you CAN NOT depend on AV or email filtering to rebuff these attacks at a meaningful level. Detection and response are key, in order to limit the length of time the attacker has access to your environment. Anything short of full eradication of their malware and tools is likely to end with them still maintaining some level of access and potentially, control.

Now is a good time to consider having a phishing penetration test performed, or to consider using MSISimplePhish to perform some phishing for yourself. Awareness alerts and training are also encouraged. This is going to be a long term threat, so we must begin to implement ongoing controls over the entire technology/ppolicy & process/awareness stack. 

If you have any questions on phishing attacks, malware or incident response, please let us know. Our teams are used to working with these attacks and their subsequent compromises. We also have wide experience with designing enclaved architectures and implementing nuance detection mechanisms that focus on your critical assets. Feel free to touch base with us for a free 30 minute call to discuss your options for increasing security postures.

Event Announcement: ICS/SCADA Security Briefing

Posted on by
Reply

MSI, along with the teams at NexDefense and Critical Intelligence, will be participating in an online webinar about ICS/SCADA Security. The date of the event is February, 6th and you can learn more about it here. 

The event is free to attend, though registration is required. You can earn a CPE for participating! 

We hope you will tune in and check us out!

Overview of the event: 

Learning Objectives

  • Significant trends in the threat and vulnerability environment
  • Relevant trends in ICS technology
  • What proactive steps you can take
  • How to leverage security intelligence

Agenda

  • Introductions
  • ICS Cyber Security Intelligence Briefing, Michael Assante
  • ICS Threat Update, Brent Huston
  • How to Leverage Security Intelligence, Bob Huber
  • Live Q&A

Who Should View?

  • Senior Information Security Leaders, CISOs and CTOs
  • Security and Risk Analysts
  • Control system security engineers
  • Security operation leads for ICS reliant organizations

What is HPSS? :: HoneyPoint Agent

Posted on by
Reply

This post builds on the What is HPSS? Series. Previous posts are here and here. 


HoneyPoint Agent is the original detection capability of the HoneyPoint Security Server suite. Basically, it allows a system to offer up a variety of “fake services” to the network for the purpose of detection. These services can either be simple port listeners or can be complex, deeper emulations of protocols like SMTP, HTTP, Telnet, FTP, etc. These ports have no real users and no legitimate traffic flows to them. This means that anytime these ports are tampered with, the interactions are “suspicious at best and malicious at worst”. 


HPAgentOverview

Because the Agent is designed to be extremely light weight in terms of computing power needed, the Agents can be sprinkled throughout the network environment easily. Many organizations simply add Agent into default server and workstation builds, turning most of the systems in their network into sensors for detection. 

 

Other organizations deploy Agent more sporadically, either using virtual or physical appliances dedicated to HoneyPoint hosting. These organizations often assign multiple physical or virtual interfaces to the devices, allowing them to have a presence on many network segments at the same time.

 

Still other users leverage an approach called “scattersensing” by deploying HoneyPoint on systems that they move periodically around their environment. This makes for a less dependable detection mechanism, but gives them the capability to get more vision into “hotspots” where targeting is expected or where malware is more likely to pop-up. 

 

The most successful HoneyPoint Agent deployments use a combination of these tactics, along with including strategies like DNS redirection of known command and control sites and other more active forms of getting bad traffic into the HoneyPoint systems.

 

HoneyPoint Agent has proven to be very useful in identifying scanning and malware outbreaks. Customers with supposedly secure networks have found malware that had been missed for years by their traditional internal security tools. These were detected when the ongoing slow and low scanning triggered HoneyPoint deployments, particularly for SQL, Terminal Server and other commonly targeted ports.

 

HoneyPoint Agent can be configured through the command line or via a GUI application, making it easy to manage and deploy. Once installed, it is a “deploy and forget” style tool which doesn’t require ongoing tuning or signature updates. Generally speaking, customers deploy Agent and it runs for years without feeding and care.

 

HoneyPoint Agent also features MSI’s patented “defensive fuzzing” capabilities (previously known as HornetPoint mode), which can create self-defending services that attempt to take down attacker tools during their probing to interfere with propagation. Still other users automate defense with Agent using it as a means for black holing hosts that probe their environment. In these optional, more active roles, Agent can help organizations strengthen their posture with a “one strike and you’re out” kind of approach. 

 

HoneyPoint Agent runs in Linux, Windows and OS X. It communicates securely with the HoneyPoint Console. It also features user configurable services, a known scanning host ignore list (for ongoing vulnerability assessment clients) and a wide variety of common service emulation templates (available through support). 

 

To learn more about HoneyPoint Security Server or to get a demo, please contact us. We would be happy to walk you through the product and discuss how it might fit into your environment. There is even a free for personal use “Community Edition” available to get you started or to let you experience the power, ease and flexibility of the platform yourself. Just give us a call to learn more about HoneyPoint Security Server and HoneyPoint Agent. You’ll be glad you did! 


Java 0-Days are Changing Corporate Use Patterns

Posted on by
Reply

With all of the attention to the last few Java 0-days and the market value for them falling them (which many folks believe indicate there are more out there and more coming), we are starting to hear some organizations change their policies around Java, in general. 

It seems some clients have removed it from their default workstation images, restricting it to the pile of as-needed installs. A few have reported requiring more frequent Java update settings and a couple have talked about switching in-house development away from Java to different languages. 

Is your organization changing the way you view Java? How are things changing around the IT shops you work with? 

Drop us a line in the comments or via Twitter (@microsolved or @lbhuston) and let us know what YOU think!

Gameframe Follow Up

Posted on by
Reply

This is a follow up to the original Gameframe scan post here. (**Note I have defanged the urls, edit them manually if you copy and paste)

Throughout the end of December, we saw just a few more probes in the public HITME that contained the Gameframe pattern. The ports shifted between port 80 and port 3128. The initial bursts of probes we observed were on port 3131, but they seem to now be occurring across the port spectrum.

The only host the public HITME caught these probes from was: 96.254.171.2 – WHOIS – US, Verizon

A Twitter user, (@benediktkr), also pointed out probes on port 8080 from a small batch of source IPs. He also observed the same source IP, which means the scanning is likely pretty wide, given that we have seen it from several of the HITME end points. 

Here is a quick dump of the log for the few we saw at the end of December (Output from a HoneyPoint plugin): 

2012-12-19 08:12:57|96.254.171.2|80|GET hxxp://gameframe.net/headers HTTP/1.1\nUser-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 (.NET CLR 3.5.30729)\nHost: gameframe.net\nAccept-Encoding: deflate, gzip\nProxy-Connection: Keep-Alive\nAccept-Language: en-gb,en;q=0.5\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\nAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\nPragma: no-cache\nCache-Control: no-cache\n\n
2012-12-19 12:30:38|96.254.171.2|3128|GET hxxp://gameframe.net/headers HTTP/1.1\nUser-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 (.NET CLR 3.5.30729)\nHost: gameframe.net\nAccept-Encoding: deflate, gzip\nProxy-Connection: Keep-Alive\nAccept-Language: en-gb,en;q=0.5\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\nAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\nPragma: no-cache\nCache-Control: no-cache\n\n
2012-12-28 12:46:42|96.254.171.2|3128GET hxxp://gameframe.net/headers HTTP/1.1\nUser-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28 (.NET CLR 3.5.30729)\nHost: gameframe.net\nAccept-Encoding: deflate, gzip\nProxy-Connection: Keep-Alive\nAccept-Language: en-gb,en;q=0.5\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\nAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\nPragma: no-cache\nCache-Control: no-cache\n\n

We also picked up this probe, which is quite different from the others, which is interesting in general, note that the source host is also different – this time from 92.240.68.153 – WHOIS – Latvia

2012-12-27 10:29:27|92.240.68.153|80|GET hxxp://thumbs.ifood.tv/files/Salmonella_in_Vegetables.jpg HTTP/1.1 User-Agent: webcollage/1.135a Host: thumbs.ifood.tv headers HTTP/1.1\nUser-Agent: Opera/9.80 (Windows NT 6.1; WOW64) Presto/2.12.388 Version/12.10\nHost: gameframe.net\nAccept-Encoding: deflate, gzip\nProxy-Connection: Keep-Alive\nAccept-Language: en-gb,en;q=0.5\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\nAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\nPragma: no-cache\nCache-Control: no-cache\n\n

It is likely that others are simply using the headers output of this page for other types of probes and scans, likely to identify open proxies and alternate paths to avoid censorship or to use in proxy chains to help hide their origins for other purposes.

If you run a black list of IPs as a part of your defense, or redirect bad IPs to a HoneyPoint, you should likely add these two sources to the list if you aren’t using the automated approach.

We will continue to observe these probes and let you know what else we see. Thanks for reading.