Go Phish :: How To Self Test with MSI SimplePhish

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

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

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.

Threat Data Sharing in ICS/SCADA Needs Improvement

I had an interesting discussion on Twitter with a good friend earlier this week. The discussion was centered around information sharing in ICS/SCADA environments – particularly around the sharing of threat/attack pattern/vulnerability data. 

It seems to us that this sharing of information – some might call it “intelligence”, needs to improve. My friend argues that regulation from the feds and local governments have effectively made utilities and asset owners so focused on compliance, that they can’t spare the resources to share security information. Further, my friend claims that sharing information is seen as dangerous to the utility, as if the regulators ever found out that information was shared that wasn’t properly reported “up the chain”, that it could be used against the utility to indicate “negligence” or the like. I can see some of this, and I remember back to my DOE days when I heard some folks talk along the same lines back when we showed up to audit their environments, help them with incidents or otherwise contribute to their information security improvement.

When I asked on open Twitter with the #ICS/#SCADA hashtags about what hampered utilities from sharing information, the kind Twitter folks who replied talked about primarily three big issues: the lack of a common language for expressing security information (we have some common languages for this (mitre’s work, VERIS, etc.)), legal/regulatory concerns (as above) and the perceived lack of mitigations available (I wonder if this is apathy, despair or a combination of both?). 

I would like to get some wider feedback on these issues. If you don’t mind, please let me know either in comments, via private email or via Twitter (@lbhuston) what you believe the roadblocks are to information sharing in the ICS/SCADA community.

Personally, I see this as an area where a growth of “community” itself can help. Maybe if we can build stronger social ties amongst utilities, encourage friendship and sharing at a social level, empower ourselves with new mechanisms to openly share data (perhaps anonymously) and create an air of trust and equity, we can solve this problem ourselves. I know the government and industry has funded ISACs and other organizations, but it seems to me that we need something else – something more easily participatory, more social. It has to be easier and safer to share information between us than it is today. Maybe, if we made such a thing, we could all share more openly. That’s just my initial 2 cents. Please, share yours.

Thanks for reading, and until next time, stay safe out there!  

What Is Your Browser Leaking?

Today in my tweet stream, someone pointed out this site and I wanted to blog about it. The site is called stayinvisible.com and offers a quick view of some of the data that is available to a web site or an attacker who can lure someone to a website. 

The site displays a dump of a variety of common data that you might not be aware of that is leaking from your browser. There are also tips for hardening your browser settings and operating system against some of the methods used to dump the data. 

If nothing else, it might just provide an “ah ha” moment for folks not used to the information security space. Give it a try and let us know what you think of it. 

We have no association with the site, its content or the folks who run it. We just thought it was interesting. Your paranoia may vary. 🙂

Mobile Application Security Podcast with Brent Huston

Are you working with mobile applications? Trying to figure out security? In this helpful informative podcast, Brent covers 3 tips that will give you the tools you need to move forward. Often a developer isn’t certain what questions to start asking. Brent shares some common areas that include foundational practices:

Here is what you’ll learn:

    1) What you should be doing to encrypt your application

    2) Almost 50% of the apps we tested missed this powerful avenue toward leveraging knowledge that is readily available

    3) How are you storing your data? And where? Brent shares insights on data storage

Click to access the entire audio file

Keep Your Eyes on This Adobe 0-Day

A new Adobe exploit is circulating via Flash movies in the last day or so. Looks like the vulnerability is present across many Adobe products and can be exploited on Android, Linux, Windows and OS X.

Here is a link to the Dark Reading article about the issue.

You can also find the Adobe official alert here.

As this matures and evolves and gets patched, it is a good time to double check your patching process for workstation and server 3rd party software. That should now be a regular patching process like your ongoing operating system patches at this point. If not, then it is time to make it so.

Users of HoneyPoint Wasp should be able to easily any systems compromised via this attack vector using the white listing detection mechanism. Keep a closer than usual eye out for suspicious new processes running on workstations until the organization has applied the patch across the workstation environment.

SAMBA Vuln Could Be Dangerous

If you are not already looking at the newest SAMBA issue, you should be paying attention. It is a stack-based buffer overflow, exploitable remotely without credentials. The MetaSploit folks are already hard at work on an exploit and some versions are rumored to be floating about the underground.

The vulnerability exists in OS X, Linux and a variety of appliance platforms using the core SAMBA code. Updates are starting to roll into the primary distributions and OS images. Ubuntu, for example, already has a fixed version available.

You can read the SAMBA folks release here for more information.

Likely, wide scale exploitation is on the horizon and malware/worm development is also predicted for this particular issue.

In terms of actions, begin to understand where SAMBA is used in your environment, reduce your attack surfaces as much as possible, implement the patches where available and increase your vigilance on SAMBA utilizing systems/processes.

Keep your eyes on this one. With this also being a fairly heavy/serious Microsoft patch day, your security team and admins might be focused on other things. You don’t want this one to slip through the cracks.

Another Good Reason to Increase Internal Security

Well, the much anticipated 2010 Verizon Data Breach Investigations Report is out, and once again it is an eye-opener! Let me say what a boon these reports are to the infosec community! Verizon and their team are to be praised and congratulated for all their hard work. These reports really help us keep current so we can protect our information from the right threats in the right ways. I know it’s not a large scale study, but I do feel it gives us good indications of trends and threats in the industry.

This particular threat report mainly gives us the data breach picture for 2009. It was compiled from nearly 900 actual incidents and includes a lot of input from the U. S. Secret Service this year. One of the surprising results of this particular report was the 26% increase in data breaches from insiders. It seems that organized cybercriminals are promising money to insiders with access to administrator level credentials. Unfortunately for these naïve inside individuals, it is proving very easy for the authorities to catch them. Also, it seems, the cybercriminals are usually not even paying them as promised! Despite these facts, it is evidently fairly easy to find plenty of insiders that are willing to sell their credentials. Go figure!

There are several ways to help counter the insider threat. The easiest thing you can do right off the bat is to ensure that those with high level access to the system don’t use the same credentials for their administrator and user accounts. You’d be amazed at what a common practice this is! All cybercriminals have to do is bust a few user level accounts and there is a VERY good chance that they will then be able to gain administrator level access. Administrator level passwords should be long, strong and ONLY used for administration purposes.

Another very effective method to counter the insider threat is to use true multi-part authentication mechanisms for administrative level access to the system; especially with very effective mechanisms such as tokens. Employing this practice means that cyber criminals not only have to steal credentials, they also have to get their hands on a token. And even if they do, it only gives them a short time to act; admin tokens are usually missed very quickly. There is also the option to employ biometrics. These can be problematic, but are improving all the time. And effective and reliable biometrics are even harder to overcome than token use.

You might say that good passwords, biometrics, and tokens won’t keep actual system and database administrators from selling out to the bad guys, which is true. However, there are other mechanisms available that can prevent lone bad-actors from compromising the system. One effective practice is management monitoring of high level access. If, every day, managers are looking at who accesses what and when, then the difficulty of stealing or corrupting data goes WAY up! Also, there are applications out there that can send out alerts when high level access is underway.

Another method, and a tried and true one, is the use of dual controls. If it takes two individuals to access systems, then cybercriminals have to corrupt two individuals and it becomes even easier for the authorities to figure out who the rats are. I don’t recommend this control except for very high value assets. The downside is that it’s a hassle to implement. There ALWAYS has to be at least two individuals available at all times or access becomes impossible. There are vacations, lunches and breaks to consider, and what happens in true emergencies such as floods, snow storms and the like? But this is a control that has been in use since long before computer systems were in place and it has proven to be very reliable.

These certainly aren’t all of the controls available to help counter the inside threat. I’m sure that you can come up with some others if you give it a little thought. But used individually, or even better, in combinations, should go a long way in protecting your data from the bad guys within!

Adobe Emergency Patch for 17 Holes

Just a quick heads up post that Adobe has just released an “emergency patch” for at least 17 holes in Reader and Acrobat. This is likely worth rushing into testing and ultimately production as PDF attacks have become all the rage lately. You can find more information about the patch here: http://www.theregister.co.uk/2010/06/29/adobe_emergency_patch/