Search This Blog

Loading...

What have you downloaded from BitTorrent?

Wednesday, October 8, 2014

(I) Further proof the Malware Management Framework WORKS! The Tyupkin ATM Malware




Practicing Malware Management as a part of any 'good' Information Security program, you would have caught the Tyupkin malware if you managed ATM's!

The locations this malware used are known places to monitor in a Malware Management program. The following is right from the Securelist report:

1. Drops payload in \Windows\System32 (Auditing enabled, Event Code 4663)
2. Shortcut added to %AllUsersProfile%\Start Menu\Programs\Startup (ProgramData) (Auditing enabled, EventID 4663)
3. Uses the Run Key to persist (Auditing enabled, EventID 4657)
4. For net flow folks, connections on Sunday and Monday night

You can use CMD scripts, PowerShell, Python or fancy InfoSec tools to look at these locations manually; but this malware is nothing new and far from sophisticated to detect. Enable some Windows Auditing on key locations and your Security Tools and Event Logs will capture the data and alert you!

Works for Linux too, just take a look at the Mayhem Malware Analysis from VirusTotal:

Mayhem – a hidden threat for *nix web servers

Want to know more about Malware Management and actionable Detection techniques? Come see my talks at HouSecCon Thurs Oct 16th and BSidesHouston Sat Oct 18th.










Tyupkin: Manipulating ATM Machines with Malware - Securelist

#InfoSec #HackerHurricane

Monday, September 22, 2014

Sunday, September 21, 2014

Challenging ALL InfoSec people, malware discovery is not as hard as you think


After being on the Security Weekly podcast and to address a response to an email on my previous blog I decided to post this challenge to all IT and InfoSec people to get them more familiar with how easy, or hard Malware Discovery can be.

I CHALLENGE YOU TO PROVE WHAT I PREACH TO YOURSELF!

To be any good at Malware Discovery or monitoring you MUST practice the Malware Management Framework which you can find here.

I used the Home Depot / Target BlackPoS malware and their variants as an example and after some comments on my blog entry I decided to challenge the readers (YOU) to actually DO the following so you can see and experience how Malware Management works and how a little understanding of Windows goes a long way for Malware Discovery.  I don't know, or it's "too hard" is not good enough, so step up and take the challenge!

I stated to look for NEW directories and files in key directories. In the case of BlackPoS and the variants the malwarians picked on %AppData% which is \Users\<username>\AppData\Roaming along with other directories.  CryptoLocker dropped its payload in the root of %AppData%, talk about lazy and the easiest to find.

In the PoS malware they dropped files and created a NEW directory attempting to hide as Java, or Adobe Flash Player. If you practiced Malware Management and understand where Windows installs user components of applications like Java and Flash, you would know that Adobe installs their products to %AppData%\Adobe and a sub-directory of \Flash Player. For Java, user components are installed in AppData\LocalLow\Oracle or AppData\LocalLow\Sun, NOT the \Roaming directory.

The fact files were dropped in the root and two sub-directories with executables in them created in %AppData%\AdobeFlashPlayer or %AppData%\OracleJava should be a Red Flag in the worst way. Also, any NEW executable files in the core Windows directories of \Windows, Windows\System32, or \Windows\System32\WBEM directories should also send IT and InfoSec peeps into research Incident Response mode. Not to mention a NEW service being installed from \Users anything is also a monumental red flag that should be investigated.

So how hard is it to monitor for malware in these directories? Again, understand we are focusing on NEW files, not changed/modified files. Patching a system modifies files, generally speaking. Installing an application, adding a role to a server or dropping malware will result in NEW files which is low noise. Change Management or Microsoft Patch Tuesday should alert you to the change coming or your own personal system will be patched, updated or a new application added that you can use for reference to compare to an alert.

If you are using products that can monitor these directories, and remember I am suggesting this is a starting point to monitor these directories based on the complete failure of retailer security teams to practice Malware Management. If you do practice Malware Management, which takes roughly 1 hour per week, reviews of malware reports will show you other directory, keys and services to monitor for executables and scripts. Executables are files starting with 'MZ' and of course look for scripts too, .CMD, .BAT, PS1, etc. You can always expand what you are looking for, but start with executable type files.

If you use products like Carbon Black, Tanium, BigFix, TripWire, etc. you will have to spend some effort setting up what to monitor. In Carbon Black's case you see everything by default (way to noisy to catch anything) and you will need to create LOTS of Watch Lists that would have 'AppData' in the path with file types you want to watch. Watch Lists have to be whittled down to exclude known executables or paths (dangerous to do it soley by path). This will take some effort as there are 25 dirs in AppData, 14 dirs in Roaming and 5 in LocalLow on one of my systems and will vary by the function of the system and what users are allowed to install.  If you are a wide open administrator allowed environment, or allow a lot of open source applications, this will be tougher for user based systems. Servers and PoS systems will, or better be very static and much easier to setup and monitor, but still will take some effort.  Plan some significant effort to tweak tools like Carbon Black to provide you actionable results that you can alert on.  Tweak results to exclude known good and eventually you will get there. It is difficult to filter out the good from Carbon Black and users will find it a challenge to initially setup.  Like any defensive monitoring tool, test, test and test again by placing files that fail your monitoring to trigger the alert. Carbon Black is also not real time, as in TripWire, it will take 10-15 mins for results to show up in the console.  Don't forget you are looking for signed and unsigned files, don't just look for unsigned. The malwarians know how to sign malware!

Now for the HackerHurricane Challenge! Focusing on your personal or work system!

First, clean up or delete any installer .EXE's from your desktop or downloads directory for your user. You may have an admin account that setup your system so clean up any installers they created as well. No sense seeing those in the results unless you want to.

Second, open a command window and navigate to \Users. Type the following command:


  • Dir /a /s *.exe *.dll > All_Executables.txt
You can do this to just your user or all users, it's up to you.

Third, run the same command changing the output filename, every day, couple days, once a week or once a month and compare the first scan to the current scan using some comparing tool like Notepad++.

What do you see?

Forth, start practicing Malware Management and look in locations the analysis, reports or descriptions state malware is found. I am convinced you will find the amount of NEW files that you don't know about is surprising small, if any. Imagine now a server or PoS that does not have a user doing any installs or updates. Keep the in mind the Target and Home Depot PoS systems had not been patching their XP based PoS'.

You can also use Sha1Deep, Sha256Deep or any other utility you want that has a built in compare option to speed up the comparisons.

  • Sha1Deep64 -r -z -o e * > Master_List.txt
  • To monitor for changes:
  • Sha1Deep64 -r -z -o e -x Master_List.txt >Changes.txt
After you do this challenge over a month or longer, I think you will find that Target and Home Depot completely failed to detect easily detectable malware. You can schedule this to run hourly, daily, monthly, use one of many tools or a fancy solution like Carbon Black, TripWire, Tanium or BigFix to name a few to automate this type of monitoring.

You all have been challenged, send me your comments.

* Get the Malware Management Framework HERE

#InfoSec #HackerHurricane

Wednesday, September 10, 2014

Malware Management Framework - Home Depot would have caught their breach.. easy



Here we go again with the 'Breach of the Week'... This time it is potentially larger than Target, which is the largest known retail breach to date with over 110 million affected accounts. It just happened a year ago ;-/.


So what does the Information Technology and Information Security community do about all these breaches?

We are at a crossroads in Information Security as an industry. Products are not helping you and clearly not a magic bullet and compliance efforts like PCI obviously are not saving you either.


What we have here is a people problem. The problem is simply the people and the lack of understanding how to do Information Security engineering. Some are better than others, but clearly management does not make security engineering a priority. It's a lack of leadership, vision and the obvious problem facing our industry with all the breaches in the past 12 months. Use the information already available and look for it in your environment. Why is this so hard?
Say hello to "The Malware Management Framework". It should be every CIO, ISO, CSO, CISO and InfoSec managers new mission statement.

Case in point. The Target breach was analyzed and a report published by iSight Partners with all the details needed to detect BlackPoS/Kaptoxa for any retail business, it was released... Jan 14, 2014. That was EIGHT months ago! So any retail business with IT and InfoSec people and good leadership surely would take this information and make it a priority to check their PoS systems for any sign of PoS P0wnage. Sadly, not.


Enter Home Depot, now a confirmed breach, the size and impact yet to be understood and by the very same malware that hit Target last year. Everything Home Depot needed was at their fingertips, published, available to their leadership to step up and avoid the cluster F$@! that hit Target... As BSides Austin shirts stated on the back, "Don't be a Target"!


So where did Home Depot, the 2nd largest retailer in the US go wrong? Where did every retailer with PoS systems large enough to have an IT and InfoSec staff go wrong? Where do most companies go wrong?


They were not practicing Malware Management. We are all familiar with Vulnerability Management, it's in compliance requirements, but Malware Management? Yes, it's basically the same thing, look at alerts, descriptions, reports and analysis from the vendors, researchers Blogs and Conferences on malware instead of vulnerabilities. The information you can glean is golden and will save your ASSets.

Below I have included many well known APT, PoS and even a NIX and Mac malware analysis that EVERY single InfoSec and IT team should use to start their very own Malware Management Program. Using the "Malware Management Framework" will help you to discover malware, or validate you're malware free. If you do find something new and unknown, like we did with the WinNTI malware in June 2012, 10 months prior to the Kaspersky report was published, you should publish, release or Blog your details about your malware artifacts that will benefit everyone.

Case Study:

The malware associated with a breach where I previously worked is proof Malware Management works. We used data from published malware reports and analysis to tweak our tools. Initially using a script tweaked to look for the malware artifacts in locations APT was know to reside, we found the malware artifacts. This allowed us to catch the intruder in the act and block them from getting any information. Looking at the logs for the affected systems we were able to see some items were not enabled or properly configured and then able to tweak our logging to better detect Malwarian behavior. This led us to produce the "Windows Logging Cheat Sheet" (link below), a direct result of our Malware Management efforts. We have made this information available to everyone for FREE so people may improve their People and Process components of their Information Security programs. It works, you just need management to allocate a few resources to actually 'Fix It' as a Wendy Nather's indicated we need more of in her recent Blog (Idoneous Security) and she is dead right.


The "Malware Reporting Standard" that we propose everyone adopt will become obvious as you read through the various vendor malware analysis reports. What lacks in these reports is a consistent way to report malware artifacts, also called Indicators of Compromise (IOC). If creators of malware analysis reports used the Malware Reporting Standard, we would have more consistent reports and easier time consuming and using the valuable artifacts. The best examples of this format is SecurelList Virus Description details and oddly, US-CERT BackOff malware alert:

If The Home Depot leadership had any clue how to do effective Information Security, they would have avoided this breach. Clearly Home Depot is lacking at security engineering and not using the information from the recent breaches to ask themselves "Are we a Target?, should we prepare ourselves for a similar incident?". They could have avoided what could be over (just guessing) 200 million lost accounts, only time will tell. But, we do know this is going to cost them a small fortune, MUCH more than improving their security engineering would have cost. Target has spent $146 million USD to date on their breach!


With the Malware Management Framework we found a previously unknown APT 10 months prior to being published by Kaspersky and Home Depot could have 100% avoided their breach using this same methodology. Only 6 log events were needed to catch the Target and Home Depot breaches from a Windows log events! If only they were any good at security engineering and practicing Malware Management could this have been avoided.


This is a teaching moment for Information Security professionals worldwide, not just those that are currently under attack with Point of Sale systems and credit Cards, but for whatever is next, whatever is already there in YOUR environment!


Start practicing Malware Management before it is too late and you are the next Target or Home Depot.


#InfoSec #HackerHurricane #MalwareManagement #Breach

RESOURCES:

Below are some items to help you start using the Malware Management Framework.


Thursday, September 4, 2014

InfoSec Industry partly responsible for huge breaches, InfoSec Cons another part, you and management the last part







You know what is worse than all these HUGE Credit Card breaches? The fact that it is ridiculously easy to detect! All BackOff malware uses the %AppData% variable directory. Translated - C:\Users\\AppData\Roaming. #InfoSecFailure

If you are not watching for NEW directories being created and/or executables being dropped here (like CryptoLocker did), then your doing SecOps all wrong. This is one of the Top 5 locations you should monitor for malware. Enabling auditing on this directory alone would have caught these HUGE breaches.

These failures in SecOps are partly our own InfoSec industries fault. InfoSec Cons do not prioritize talks for defense which 90% of us attending do, nor demand defensive content, nor set aside 10-25% for defensive talks to teach our industry stuff like I stated above. #InfoSecConFailure

Please ask and demand that your InfoSec Cons set aside more time to REAL Defense in their talk selection and promote the Con is and wants defensive talks to help our own industry catch up. Because we are WAY behind and falling further back each breach that happens.

The image below is how I felt at Vegas Con week... All focused at breaking the gate, not defending the obvious gaps.






Dan Geer at the BlackHat Keynote was dead on when he said if InfoSec were a soccer game it would be 464 to 452, all offense, no defense.

Help our industry by not attending exploitation, hackery and offensive talks if your job is to defend your company. We need to evolve quickly before it is too late for us and our companies.

And yes, I have submitted 2 talks to multiple Cons on the subject of logs and malware and turned down. There were 3 Logging vendors at BlackHat, ZERO talks on logging for APT/PoS type attacks... Sad... VERY sad.

Under the current black cloud we are all under, you would think Cons would be begging for defensive content.

Ohh... And the other 4 of the Top 5 locations to monitor...

2. C:\ProgramData
3. C:\Windows - Explorer injection
4. C:\Windows\System32 - NEW dropped files
5. C:\Windows\System32\WBEM - #1 on my list

If you practiced The Malware Management Framework then this information would be obvious. Read the Kaspersky report on BackOff that proves my point.

And yes, I monitor all the above and MUCH MUCH more and share in the presentations I give.

Kaspersky/Securelist Article on BackOff malware

#InfoSec #HackerHurricane #EducationOpportunity

Thursday, July 31, 2014

The latest BackOff PoS malware is nothing new if you practice the Malware Management Framework




Proof if you were practicing the "Malware Management Framework" and reading the analysis from BlackPoS that took out Target and Neiman Marcus, you would have been prepared for BackOff that hit 600 retailers. Yes, 600 retailers!

SC Magazine article on 600 retailers affected by "BackOff" malware.

As Trustwave accurately concluded, this malware is not sophisticated. It is noisy and would have set off many of the alarms I have previously covered HERE and HERE and HERE.

Behavior of most malware share many common triggers on Windows based systems, NIX too. So why isn't anyone detecting this stuff? Small shops have no staff, PoS vendors don't use their own stuff or work with larger users to monitor for malware funkiness they can pass on. Large companies don't know how, or as I often state, "They are chasing and filing out compliance paperwork and not doing enough security engineering and defense and detective security, focused at looking for, tweaking and READING actionable alerts.

So if you read other malware analysis, because you're practicing the "Malware Management Framework" you have have set the following items and detected the malware.

1. %AppData% - C:\Users\\AppData\Roaming. If you enabled auditing of created files in this directory (Local & LocalLow too), you would have caught the malware (nsskrnl.exe & winserv.exe). Files just don't get created here normally.

2. %AppData% - C:\Users\\AppData\Roaming. The directory "OracleJava" was created and "Javaw.exe" created... If you know what is normally installed, you would find this was NOT normal for your systems, let alone a static PoS system or server. This is often a trick to create a directory or two deep to obfuscate the malware to look normal.

3. HKCU Runkey had values of #1 & #2 above.

4. HKLM & HKCU Active Setup keys were used, a little more sneaky, but known key to monitor.

As the Trustwave analysis shows there was already a Snort Sig that matched this malware. If you had reviewed this malware and tweaked your defenses, other than the names, this malware is the same... Proof the Malware Management Framework would help you discover new and advanced malware.

The Trustwave analysis did not discuss the behavior aspects of the malware, how it got there, spread, etc., but the following Windows Event ID's being logged, harvested and alerted on would have detected this malware.

1. 4688 - New Process - the executables discussed above, and probably net.exe, CMD.exe and maybe PSExec.exe as they hopped around and spread the malware.

2. 4624 - some account logged in. What accounts did and what accounts at what times are normal?

3. 5140 - A share was accessed. They most likely connected to the C$ share.

4. 4634 - A share was disconnected. Your looking for behavior of share connections.

5. 7045 - A new service is installed. Static systems don't get new services except at patch time and new installs. Change Management anyone?

6. 4663 - File auditing must be enabled on directories you want to monitor. The new files above would show up. Yes, there are ways to write to disk without Event logs being triggered in PowerShell and .NET, but this is rare.

These 6 events would have detected this and many, if not most attacks. There are many other things to enable and monitor, but practicing the Malware Management Framework from the Target breach would have prepared you for this attack and many others.

Like I always say, "If your not logging these, you're not doing it right".

For more logging to monitor, read the definitive "Windows Logging Cheet Sheet" I put together for Windows logging here for tips on what to enable, configure, gather and harvest.

Trustwave Analysis of BackOff malware

#InfoSec #HackerHurricane #malware #LogsRock #MalwareManagementFramework

Friday, July 25, 2014

Continued - Proof our industry is broken

Continuing on the PoneMon study...

The following figure shows where the interviewees get their information.



Seriously? You ask CERT and Law Enforcement for more details? If you are relying on CERT as your #1 source, I think you're doing it wrong. CERT has it's place, I have used them for disclosure of a Card Key Exploit, but for "New" and "Emerging" threats? Really??? The government continues to rank poorly in their audits and are not nimble enough to be at all useful until those of us doing the actual work, that are found at the BOTTOM of this list, have already found, discussed, analyzed and published information of new and emerging threats... Who found out about the Target Breach or Heartbleed from the Feds emails before another source?

Asking your industry peers what they think was 2nd. Better, but why wouldn't your own security research be #1 and the places you consume data or read #2 & #3, which made the bottom of the list? Who are these people they interviewed? More on that later...

The following diagram shows the value they placed on how they keep up with the threat landscape... Ohhh Boyyyyyyy...


Casual conversation with security leaders was very important (thinking Executive round tables here), followed by research from independent third parties, then independent security blogs followed by security blogs and conferences which only rated 4.85 on a scale of 1-11, 1 being good.

Really? Data you get from conferences only gets a 40% on how they keep up on the threat landscape? What conferences are these folks attending? Well it's clear they are not attending, let's say it's due to lack of budget to fly to Vegas for the week long 3 Con overwhelm known as BSides, BlackHat and DefCon. If you use Point of Sale systems, there are more than enough talks to keep you up on PoS threats... Malware analysis talks too, just not enough malware APT discovery or proper logging talks (IMHO).

Analyst reports scored poorly coming in at 6.19, sorry Gartner and 451 Group.. They don't see your value it seems. Oddly Security Vendor security research and blogs came in even lower at 7.17 and 7.57 respectively. This is sad as some of the BEST data you can get for Malware Management is from these reports... Did I already state 40% say APT is their #1 concern? #FAIL. Reports from 2 years ago would have led you to detect the Target breach and other PoS fails. You seriously need to adopt "The Malware Management Framework" (dot Org) people!

If APT, malware, bad JuJu or whatever you want to call unwanted software being on your system is your #1 concern, vendors reports, blogs and research are KEY to tweaking your tools or Security Operations Center to be better at Detection & Response and Incident Response.

Left turn - On Security Operations Centers...

From another Ponemon report that was recently mentioned in SC Magazine, I would actually agree with this statistic and finding, assuming the SOC is doing the defensive stuff I am talking about, which they should be. I have however, seen some poorly skilled staff is SOC's I have assessed.

"A recent study from the Ponemon Institute revealed that companies investing in a comprehensive SOC saw a 20 percent better ROI on their security spend. These organizations saved on average $4 million more than their SOC-less peers."


Why? Probably because these people are focused at Detection and Response, the in the trenches people that can focus at finding bad JuJu by nefarious ne'er-do-wells, OK, Bad Actors ;-). I guess the interviewees for this Ponemon report did not read that Ponemon report...

Back to the original Ponemon report...



Roughly 48% was the average that the companies were 'disappointed' with the protection a security solution they purchased. Maybe their evaluation process, if they even have one, or their list of requirements was poor, or they didn't dedicate the resources to properly evaluate the product, if at all. I would say roughly 48% of the products I evaluate get tossed for poor performance, installation difficulty, user interface or excessive price for value, and failing to pass muster. Do a better job evaluating products and quit believing the sales person or vendor pitch as gospel, take 30, 60 or 90 days and do it right! A fool with a tool is still a fool... But it was in the Magic Quadrant... Maybe that is why Analyst reports scored poorly... They bought the MQ product and were 48% dissatisfied.

For some reason 80% felt Threat Modeling was essential and very important. Not enough info on what they think this means, so I'll pass on this one. The only point I want to make here is that was their highest score across all things surveyed, odd.

The conclusions of the report are beyond comment. Since the study was sponsored by Websense, let's just assume the conclusions leaned to their favor. I would say the conclusions from these two posts are FAR different, other than I agree, OVERHAUL your security solutions.

So who are the people interviewed?



Only 11% were non supervisors, managers, directors or vice presidents... Really? People like us that protect you only made up 11% or so? OK, I am supervisorial type, so let's add them in to raise it to 30%. Less than 1/3 of the interviewees are the doers, in the trench people?

I would venture to say if you were to ask only the 30% with the same company's, country and counts, the results of this survey would be FAR different. Sadly, these are the people we work for. It explains why breaches like:

Target, Neiman Marcus, Michael, Specs, a Goodwill, PF Changs, Sony, TJX, etc.. Etc.. Etc... Keep happening and take so damn long to detect. The 60% need to attend more local ISSA, OWASP, NAISG, InfraGard and ISACA meetings and attend more BSides and other local conferences and read more from people like us that share what you actually DO need to do to cut down on breaches and the costs associated with them.

#InfoSec #HackerHurricane

Thursday, July 24, 2014

Proof our industry is broken




I just read the latest Ponemon survey "Exposing the Cyber Security Cracks: A Global Perspective" and I had to laugh. The email started out with "30% of organizations would overhaul their security solutions'. My first thought, just 30%? It should be 90%, because I think only around 10% of us are good enough to catch an APT attack the report covers within an hour or worst a day. The average detection of a breach being 200-400 days, depending on what report you read and in 90% of the cases told to you by a 3rd party.

If you can't detect and respond to a breach within 1-24 hours, you are doing it wrong.


So why is this funny? Well, in figure 2 of the report it lists "Advanced Persistent Threat" as the top concern at 40%... 24% say a "Data exfiltration attack". If a "complete overhaul of the system" sits at 29%, and 22% say no changes needed, we are awesome, and 13% say nothing because they can't stop it.. Our industry is seriously broken. No way 22% can detect an APT attack within 1-24 hours. No report I have ever read of companies that have been breached has ever stated 22% of the companies surveyed successfully detected their attack with 24 hours and we are just validating their findings...

The never ending list of breaches and the length of time these companies were infected should tell us two simple facts, 1. Companies suck at detecting and responding to breaches and 2. Many companies still don't know they have been or are breached or don't care and go many many months with the ne'er-do-wells crawling around the network. My credit card just got compromised, and I suspect another retailer will announce a breach that I shopped at, when someone tells them they have been breached...

APT cannot be prevented, you will get popped, it is just a matter of when you will detect it, or in 90%+ of the cases told by a 3rd party you have been breached... Even worse, you failed to detect it and some one had to tell you.

Detection is not hard, it's just a change in mindset. A BIG change in mindset since so much of our InfoSec industry and management believe a "Prevention solution will save me", plug in the latest appliance. What will save you is people. People that know how to use tools, know and understand the limitations of the tools, admit they are not effective and retire or replace them, evolve their programs to be detective and good at Incident Response and do things outside the box. And yes, don't spend so much time and effort on compliance. People that I wish would be trained at the 3 Con Vegas week and come back significantly better than they left... Maybe defense is not as sexy as exploitation, but it is our day to day job and if you want to keep that job, get better at defense or you will get burned out, canned or be the scapegoat.

OVERHAUL:

Two of the best security tools I use and recommend are not marketed as Security tools at all, but are #1 and #2 on any list of things I would need and insist on to defend a network (Splunk and BigFix or equivalents). Then I would back fill with the necessary and focus on less costly versions of the typical tools we all use/need to be compliant, focusing on low staff impact so they can defend the network the way it needs to be defended. Stop being afraid of tossing a product that just doesn't help you and replace it with something or someone that can. 47% say they are dissatisfied with a product they implemented, 27% say not frequently dissatisfied, so some of the time they are. That is over 50% that don't like what they just implemented and are not tossing it out? Admit that your adversaries have evolved and what use to work can now be bypassed by the ne'er-do-wells and another solution, approach or methodology is needed. Anyone practice the "Malware Management Framework"? (dot Org).

And the two top reasons to replace a security product according to the report? Downtime 73% and difficult user interface 67%... How about the fact it doesn't help solve the 40% APT risk that is your top concern?









I will be attending BSides, BlackHat and Defcon in Las Vegas next month and have gone through the list of talks and discovered that the vast majority of talks are not about helping me defend against ne'er-do-wells. This is a major #FAIL in my opinion as we are not helping educate the masses, we are just WOWing them with what the bad guys could, can, might and are doing to something you may not even have or use.

Cons need to teach more defense, more detection and response. Stuff we can take back and actually do. Lessons learned from those of us that have been their, got burned or succeeded in defending our ASSets. 30% of the 3 Con week in Vegas needs, and I quote " a complete overhaul" to more defense and less offense.

29% in the Ponemon study of 4881 companies in 15 countries with 10 years average experience say they would overhaul! yet with what? how? Where can I learn what's working? I want to learn from those like myself that have lived through and successfully defended against the worst kind of APT attack. Those who have, have much to share, but alas the 3 Con week in Vegas is weak on defensive talks that 90% of us do day to day.

The report goes on to say 52% of companies don't invest in skilled staff... I say, find another gig, we have the lowest unemployment rate in the IT industry. Work for someone who gets it.

Seek out and demand Cons offer up more defensive tracks.

#InfoSec #HackerHurricane #VegasConFail

Thursday, July 10, 2014

(T) Filtering or trimming Windows logs the right way, NOT by Event ID







Have you ever worked with Windows logs and enabled all or a lot of auditing items and feel there are way too many events or noise?

Ever enabled 'Filter Platform Policy Change' to monitor the Windows Firewall connection? This auditing option will add Event ID’s 5156 and 5158 to your logs and quickly be in your Top 10 of all events generated. If you enable success for 'Process Creation' you will get Event ID’s 4688 and 4689. These four Event ID’s will probably be your Top 4 events generated.

Enabling these two auditing items will add a ton of events to your logs. While stored on a systems local disk you won't notice a thing, forwarding them to a Log Management solution you will find they add up and impact disk space and licensing. But they are some of the greatest events Windows has to offer, so use them!

Jedi Tip: Ever wanted to know what IP's and ports a Windows application is using? Maybe to make a change on your enterprise firewall? Use 'Filter Platform Policy Change - success' to see all inbound and outbound connections to and from your Windows Server or Workstation. You can even use this data to refine your Windows a Firewall rules for allowed IP's to an application like a security camera for example or remote access, see my last Blog entry for tips on this one HERE.

So how do you enable a policy item, start collecting log data yet filter the unwanted noise out? Most people do it by disabling auditing of the two items above or excluding by Event ID, which is a terrible way to filter or trim logs. Unless of course the Event ID is truly worthless and none of the events in that ID are useful to you or your admins or dev folks.

If you filter out or disable Windows firewall auditing (Event ID’s 5156 and 5158) for example; then you can't see all the inbound connections to your systems, remote connections by remote IP to the system, track users surfing to IP's, or outbound malware C&C requests. You would be forced to do this at the network layer where you cannot easily hone in on a host and what process is using an IP you are investigating.

If you filter out or disable Process Creation auditing (Event ID’s 4688 and 4689) for example; then you can't see the processes that have been launched on a system, or see what process called another process like CMD.exe calling malware.exe.

Do you need to see or keep ALL of the events of the ID's just discussed? No, you can look at Process Names and Application Names that you deem normal noise and exclude them versus eliminating by Event ID. Google Chrome Update is incredibly noisy log wise, yet probably not needed for InfoSec or forensic investigations. You could toss out GoogleUpdate.exe or Splunk*.exe and reduce your events of the four Event ID's mentioned by 50% give or take saving disk and log management licensing. The image at the top is exactly this filter before and after.

If you are wanting to try the Free version of Splunk at home or in your lab, then reducing events by tossing them out will save on the 500mb per day Splunk eval license restricts you to. Each log solution will have different ways to filter items out or blacklist them from being collected, but never ever do it by Event ID as you can or will lose valuable log data. Unless you are certain the Event ID and all its' events are worthless.

Read the definitive "Windows Logging Cheet Sheet" I put together for Windows logging here for tips on what to enable, configure, gather and harvest.

#InfoSec #HackerHurricane #LoggingDoesntSuck

Monday, June 30, 2014

(T) How to use the Windows Firewall behind a NAT router




Ever wanted to open up a port on your home firewall, but restrict it more than a NAT router allows with raw port 1234 to IP 1.2.3.4?

Restrict it by an actual application, or 1 or 2 remote addresses, not to the whole system from anywhere on the Internet? Or easily change it because of DHCP changes on either local or remote systems? Or to allow a cloud service to send data back to one of your systems? Or allow a Web a console you want to remote into from work to check your Security System?

While playing with Splunk I found the logic of the Windows Firewall behind a NAT router changes things a bit.

The Windows Firewall has 3 Zones, you usually see this PopUp from your browser when you join a new Wireless network on your laptop for example. You will see 'Public' and 'Private' or 'Home' which is also 'Private', there is also 'Domain' for AD attached systems which we generally don't have at home.

When you are behind a NAT router you can ignore or disable everything but 'Private'. Once you open port 1234 to IP 1.2.3.4 on your home router via Port Forwarding, Gaming or whatever your router calls it, all traffic to the a Windows Firewall is seen as 'Private' or inside your network. You can test this by disabling a 'Public' rule you have for a Remote Access for example and it will still work, because it uses the 'Private' rule once NAT is involved.

So everything you will do will be an Inbound Rules and 'Private'. Notice in the image above I have VNC Server installed on my test system and it has 'Public Disabled'. Even though I remote to it over the Internet from a public address, once NAT port forwarding takes over it becomes a 'Private' rule.

Also notice that I have a Splunk Web rule that is also 'Private'. All I have to do now is craft my NAT router to pass any port range I want to the IP I want and then use the Windows Firewall to further restrict it by the remote IP's allowed to the computer or specific application. This allows me to refine my port hole in my NAT router to only the systems I want to remote from and to only the actual application (VNC Server.exe) on that port.

If your home IP changes due to DHCP renewals, then use a Dynamic DNS provider so you can refer to it by name instead of IP. This will require you to run a small utility on your system to send any IP changes to your Dynamic DNS provider.

Play with it and let me know any other tricks you might use.

#InfoSec #HackerHurricane

Monday, March 3, 2014

(T) A look at WHY the now infamous Credit Card breaches should have been detected and how YOU can detect these types of attacks

We are all too familiar with the Credit Card breaches that hit Target, Neiman Marcus, Michaels, Marriott, Holiday Inn, Sheraton, Westin, Renaissance and Radisson, possibly Sears and other retailers yet to be named.

Recently some information on the details of the malware has been released by iSight, McAfee, X-Force and others.  I took a look at the details around BlackPoS and Kaptoxa as I could not believe organizations the size of Target, Neiman Marcus, and Michaels and not mention several hotels were unable to detect such an attack.  So what would it take to “Detect and Respond” to such an attack?

First off, this malware was neither sophisticated nor overly stealthy.  It looks and acts like most malware and APT you would find, see or analyze.  As a part of my “Malware Management Framework program I review malware such as this in order to see if I could or would detect such an attack, similar attack and compare it to what I already see or know in order to tweak my detection capabilities.

First, let’s look at the diagram McAfee had in their report:
As we can see there are multiple Point-of-Sale (PoS) systems connected to the ‘Exfiltrator’ system.  This system apparently sent the CC files via FTP to a compromised Internet server that the criminals then harvested the credit card data from.  By the way, FTP is often used to send transaction reports off the PoS terminals to a central system, so FTP may be normal traffic to many.

It is not clear from the report(s); but one would also assume, for sake of having a starting point that this ‘Exfiltrator’ system, let’s call it ’Patient 0’ is where the attack against the PoS systems originated once the malwarians were in.  We know from Neiman Marcus the malware was deleted every day and reinstalled after a PoS reboot.  This would lend to the fact there is a ‘Patient 0’ system that re-infected the PoS systems as they came back up.  This means that there would be some type of traffic from ‘Patient 0’ to each PoS system and a LOT of it if this occurred daily.  According to reports, almost 60,000 events (the articles say alerts, but I don’t believe that).

With these assumptions and details we can build a pattern of noise that would have been made by such an attack and what we should have, or could do to detect and respond to such an event.  So let’s take a look at how to detect and respond to this type of attack.  I will use Windows 7 versus the Windows XP since most of you are running the latest Windows Operating System (hopefully), but everything discussed still applies to Windows XP, just with a different Event ID.  I will be referencing the latest EventID’s, someone can convert them to XP/Legacy ID’s and I will gladly post them.

TRAFFIC:

1.  FTP – The FTP traffic that went from the PoS system to ‘Patient 0’, or visa-versa should have been detected.  Even if we assume FTP is normal traffic from the PoS, or to the PoS from a central system and even if the proper central FTP system was also ‘Patient 0’ this should have been detected.
a.  Transaction logs are scheduled and deterministic.  It is highly unlikely that the malwarians used the exact same schedule and the exact same central system.
b.  Net Flow should have been used to detect this type of traffic as FTP is in the clear, the data sent by the malware was not, it was encrypted and would have looked like gibberish.
c.  The traffic outbound from ‘Patient 0’ should have been caught as well as it was going to an untrusted source.  All your FTP servers should have known IP’s that it would connect with and any variance alerted to.
d.  Any FTP server should have been configured to collect all logins and activity.  ‘Patient 0’ should have been no different.  This system received FTP transfers from many PoS systems and this behavior should have been detected as abnormal outside the normal transaction log upload time

2.  Port 445 – Windows communicates over port 445 for shares that are mapped from one Windows system to another.  The malware mapped drive “S:” to another Windows system was used by the malwarians.  This traffic should have also been known in a static environment and thus any variance alerted on.

3.  Logs – Windows logs if configured should have seen all kinds of noise from this malware.  If auditing was enabled on the PoS systems or ‘Patient 0’ then noise would have been made, a LOT of it!  Collection of known malicious behavior should have been detected.  Windows 7 Advanced Auditing should be set to ‘success and failure’ for many items.  See another future Blog article for what to set, or better yet come to BSides Austin for the Windows Logging Workshop.  For Windows XP logs, all audit logging should have been set to ‘success and failure’ and collected locally or better yet sent off to a syslog server or SIEM solution.  For the sake of argument and the sheer noise it produces, let’s assume the Windows Firewall is off, so no Packet Filtering logging is enabled.

a.  Execution of the FTP client should have been detected.  Event ID 4688 triggering on ‘ftp.exe’ should be part of malicious tools and activity monitoring.

b.  Connection between systems should have also been detected.  Event ID 4688 triggering on ‘net.exe’ should be part of malicious tools and activity monitoring.
















c.  The PoS system when connected to a share should have also been detected.  Event ID 4624 triggering a ‘Logon Type 3’ network logon should be part of malicious network activity monitoring.


















 

d.  The system the PoS connected to should have had a share connection detected.  Event ID 5140 would list the share ‘Test’ was connected and what IP address did the connection and should be part of malicious network activity monitoring.








 













e.  The system the PoS connected to should have had a share connection that disconnected detected.  Event ID 4634 would list the ‘Logon Type 3’ was ‘logged off’ and should be part of malicious network activity monitoring.



 








4.  CMD Shell executed – A command shell was used on ‘Patient 0’ as well as each PoS system.
 
a.  Event ID 4688 triggering on ‘cmd.exe’ should be part of malicious tools and activity monitoring.



 









5.  PSExec executed – The use of PSExec is very suspicious and should not be used by anyone except an administrator.

a.  Event ID 7045 triggering on ‘PSEXECSVC.EXE’ or ‘PSEXEC.EXE’ should be part of malicious tools and activity monitoring.














6.  The Malware – The malware files that were used should also have been 
detected in many ways.  The logs at a minimum could/would detect that something malicious was occurring.


a.  Event ID 7045 triggering on ‘Bladelogic.exe’ or ‘POSWDS.EXE’ (dum.exe) should be part of malicious tools and activity monitoring.



 










b.  Event ID 4688 & 4689 should be triggering as the new unknown application started and stopped with the names ‘Bladelogic.exe’ or ‘POSWDS.EXE’ (dum.exe) should be part of malicious tools and activity monitoring.



 












c.  File Auditing is not heavily used by people, but in static environments like a PoS system or file server, or every administrator system you have, it would be easy to setup File Auditing on a handful of directories, or just exclude the noisy ones.  New files being added to \System32 would have triggered the files dropping and the credit card data file ‘winxml.dll’ if File Auditing had been enabled.  Add File Auditing to ‘\System32’, ‘\Drivers’, ‘\WBEM’, ‘\Fonts’, and ‘\twain_32’ and set to audit ‘Create File’ and ‘Create Folder’ for success.



 

















d.  Event Id 4663 would have been triggered in the logs for ‘access an object – WriteData (or AddFile)’ the new files that were added by the malware and should be part of malicious tools and activity monitoring.


 












 





















7.  User Accounts – There is a fair amount of discussion around the accounts used to access the PoS and FTP system(s).  Any good InfoSec program should know what accounts are doing, especially if they are administrative accounts.  Service accounts and administrator accounts have a behavior that is fairly normal.  It is unlikely that the malwarians used the credentials ‘Best1_user’ account in normal ways.  A more likely scenario is that the monitoring of accounts was not being performed.  Successful logins for accounts will tell you more than failed attempts as a compromised account will not generate failed attempts.  The credentials may have been sniffed, cracked or key logged and then used successfully, maybe even ‘a user account was created’ which is ‘Event ID 4720’.

a.  Event Id 4624 would have been triggered in the logs for a ‘New Logon’ and should be part of malicious tools and activity monitoring.























Logging won't catch everything, especially since it must be configured, but there are so many log events I was able to reproduce that it is almost laughable that Target, Neiman Marcus, Michael's and others were unable, or unwilling to detect all this nefarious noise.  Being PCI compliant is not the same as practicing PCI compliance daily.  Compliance is one of the reasons these large breaches occur (IMHO) as we are so busy chasing and filling in compliance paperwork that we fail to actually practice REAL SECURITY.

Well Target, Neiman Marcus, Michael's and others.  I just showed you and many others "HOW", so step up and implement Malware Management and do what many of us already know.

If you are not logging it, you are NOT doing it right.

Other well-known security tools – many well known security tools would have detected the files dropping onto a PoS or Windows system by default.  Tripwire for example would see all the new files in \System32.  Custom configuration management tools would also detect new files in key places.  Carbon Black would have seen the files, processes, Registry keys and command line details from the malware.  The Windows Logging Service (WLS) would have caught the new processes and command line syntax used to trigger the new processes as well as the service being added.  I have only named a few security solutions... No Anti-Virus software would not catch anything like this until long after it was discovered.

If you collected the logs locally and ran scripts to gather log data or used a simple syslog server to grep through the logs, you could have seen this activity.  Of course a robust Log management solution like Splunk or one of the many SIEM solutions would have been another great and recommended method to detect this behavior “IF” properly configured.  Most larger organizations that have compliance requirements like PCI and are required to use an advanced logging solution.

Of course there are many more things we could do to adequately detect and respond to security incidents before they turn into a large “Event” that may have you preparing for “Breach Notification”.  So prepare now and integrate the "MalwareManagement Framework" into your Information security program before it is too late.  

Don’t be a Target!

Want to learn more?  Come to BSides Austin 2014 and take the 4 hour “Windows Logging Workshop”.  Of course watch my Blog for more on Blue Team Detection and Response techniques.

REFERENCES:

McAfee Blog:
  • http://blogs.mcafee.com/mcafee-labs/analyzing-the-target-point-of-sale-malware
McAfee Report:
  • https://kc.mcafee.com/resources/sites/MCAFEE/content/live/PRODUCT_DOCUMENTATION/24000/PD24927/en_US/McAfee_Labs_Threat_Advisory_EPOS_Data_Theft.pdf
IBM X-Force Blog:
  • http://securityintelligence.com/target-data-breach-kaptoxa-pos-malware/
Brian Krebs – Krebs on Security Blog:
  • https://krebsonsecurity.com/2014/01/new-clues-in-the-target-breach/




Thursday, February 27, 2014

If you can't detect the now infamous KAPTOXA/BlackPOS malware, boy is your InfoSec program in trouble




So we are up to 20 companies affected by the KAPTOXA/BlackPOS malware. The question is did anyone detect this easily detectable event?


"No antivirus software would have stopped the malware that attacked Neiman Marcus’ card-processing network, because it was rewritten to target the company, Kingston said. “It was very specifically designed for an attack on our systems,” he said."

First off, what is wrong with this statement? Mr. Kingston, if you are relying on Anti-Virus to catch an attack such as this APT, your Information Security Program is failing you. AV should never be expected to detect or prevent advanced attacks such as this, it is foolish to think AV would and I have news for you, AV is not designed for this type of threat... Just so you know.

Malware Management anyone?
Kingston also stated that the malware had "sophisticated features making it difficult to detect". Let's look at what we know about the KAPTOXA/BlackPOS malware.

1. We will give up the fact that an endpoint was compromised and it got onto one system. I always say "Give up the Endpoint and detect things from there". Relying on, or telling Congress the malware had a ZERO (0%) detection rate by AV is well, Duh.. All APT has a 0% detection rate. That is what makes it APT and "sophisticated".

2. The malware was a memory only resident program, or was it?  K3wl, it was good malware, as expected and your Security program should be designed for such malware and threats, you know, the stuff that has a 0% detection rate by AV.

3. The malware wrote the encrypted bits to a file located at "C:\Windows\System32\Winxml.dll. OK, any NEW file that is added to \System32 on your static core systems should be reviewed as a part of a 'Malware Management' program. Might I point out this file was NOT a .DLL, rather it was a text file? Can you say look for 'MZ' in files that claim to be executables that are not, and 'MZ' in files with non-executable extensions. TripWire BTW would have detected this file over and over again as it did system checks due to the changes, so would many other security solutions. Nope, AV would not have caught this.

4. The malware ran a script that pushed ' Winxml.dll' to a remote system. Yup, lots of connections to one system from all your POS systems... Really, that is not odd? Windows logs will show this connection, but guessing your IT and InfoSec folks did not configure this, nor were they looking for this condition. Oh yeah.. Cuz you were relying on AV.  Learn what Log Management is all about or SIEM as sales folk like to call it. Got Splunk?

5.  The location and file name for the collection point was "C:\Windows\twain_32".  Why would so many systems write to the Twain_32 directory?  This is used for scanners.  Do you have scanners on your PoS systems?

6. The account used to do all of this was behaving in a way that was probably not normal for this account. So you don't or can't monitor for administrative accounts being used outside their normal operation? No need, we have AV! Again, Log Management and Account Management would be prudent.

7. Might I point out that Windows logs will also capture the process being launched. Both CMD.exe, PSExec and FTP were used in this so called sophisticated attack. These events are captured in Windows logs, but guessing Process execution (EventID 4688 or 592 in XP) was not set to capture 'Success'. Carbon Black and the Windows Logging Service (WLS) agent would have caught this command line activity as well.

c:\windows\system32\cmd.exe, c:\windows\system32\cmd.exe /c psexec /accepteula \\<EPOS_IPaddr> -u <username> -p <password> cmd /c “taskkill /im bladelogic.exe /f”
c:\windows\system32\cmd.exe, c:\windows\system32\cmd.exe /c psexec /accepteula \\        <EPOS_IPaddr> -u <username> -p <password> -d bladelogic                                         
c:\windows\system32\cmd.exe, c:\windows\system32\cmd.exe /c move \\                              <EPOS_IPaddr>\nt\twain_32a.dll c:\program files\xxxxx\xxxxx\temp\data_2014_1_16_15_30.txt

c:\windows\system32\cmd.exe, c:\windows\system32\cmd.exe /c ftp -s:c:\program files\xxxxx\xxxxx\temp\cmd.txt

8. PSExec installs as a Windows service. Logs also capture when a NEW Service is launched. So let me guess, your folks did not look for EventID 7045 either, or EventID 4697 for XP, a Security 101 item to look for in a good Log Management Program. In the quantities seen with Target and Neiman Marcus, this is really a DUH moment.  Oh wait... maybe the fact that Neiman Marcus missed almost 60,000 alerts is the 'smack your forehead moment'.

"The 59,746 alerts set off by the malware indicated “suspicious behavior” and may have been interpreted as false positives associated with legitimate software. The report, prepared for the retailer by consultancy Protiviti, doesn’t specify why the alerts weren’t investigated."

9. Network traffic, often called NetFlow would have seen odd traffic in a static PoS environment and the SMB (port 445) and FTP traffic would have set off someones spider sense if in fact they were doing what a good InfoSec program does, look for nefarious behavior. Baseline what is normal and detect what is not.

It is clear to me the memory component was sophisticated, it grab credit card numbers and encrypted them on disk; but that is about all that was sophisticated about this malware, oh, and the fact they encrypted the stolen CC numbers is just ironic.

We need to quit chasing Compliance and start doing REAL Security Engineering to detect and catch these types of attacks. All the data I, or many others in our field was present and we would have caught this long before the massive breaches they are.


So Mr. Kingston (Neiman Marcus) and Mr. Mulligan (Target) your Information Security programs, though expensive, do little to stop the real threats facing all of us today.  You might consider hiring InfoSec people who know how to defend and spend less time on Compliance and more on Detection and Response.


#InfoSec #HackerHurricane #KAPTOXA #BlackPOS