Thursday, April 5, 2012

Mac OS XJava Flaw

According to Dr.Web more than 55,000 Macs are infected with the so-called Flashback Trojan. The vulnerability that the attackers are using is with the Java for OS X Lion. (CVE-2012-0507)

My .02:  With the popularity of Apple products going up and up, it was only a matter of time that attacks started shifting (even ever so slightly). While MS boxes have been and will be targets for a long time, the Mac world has been slowly becoming into focus for attackers.  However, I'd suspect there to be a bigger attacker push into the mobile platforms rather than Mac in the coming year(s). Mobile platforms (iOS & Android) are more ubiquitous by far and more people would have a cell phone than a computer of any sort. Besides, people do stuff on their phones they would never do on their computer...the weak link gets weaker...

More reading:

Ars Technica - Mac Flashback trojan exploits unpatched Java vulnerability, no password needed

Krebs on Security - Urgent Fix for Zero-Day Mac Java Flaw


Sunday, March 25, 2012

Incident Response Essentials p2

We left off at listing some of the bare minimum of artifacts needed to conduct analysis on systems that are suspected of being compromised. Before we get to tools there should be some discussion about "how" to get the artifacts.

The focus will be the acquisition of these artifacts on live systems. There are big differences in live and dead host acquisition, but right now I am focusing on live remote acquisition on an enterprise level.

So what do you need to do live remote acquisitions?

Network access:
Goes without saying, but if your enterpise has firewalls/host ips agents/ipsec/networking filtering/DACLs protecting hosts you will want to get some sort of pre-planned access capability.  If you don't you will waste valuable time getting what you need...  A little pre-planning here is key. Since we are talking about a Windows environment you will typically see systems with Windows SMB (a.k.a File & Printer Sharing) access. (IPC$).

Authentication:
In short, you'll need to be authenticated as a user with administrator privileges. Whether this is a domain admin account in the local admins group or local account, you need to have admin privileges to snag these artifacts. You'll also need that level access to connect to the box remotely.

  • Side note: You are likely responding to compromised systems with elevated privileges across the organization, and when investigating these systems those credentials could become compromised themselves. You need to adjust accordingly and I suggest creating a privileged account that is only used for IR work and heavily defended: quickly expiring passwords, heavy logging alerts on it's use, etc...
For more info see a great post on the SANS Computer Forensics Blog about this very topic:
Protecting Privileged Domain Accounts: Safeguarding Password Hashes



So you have access and the rights. Now what?

At this point you've identified the target system, you have access, now you need to get the tools/scripts to the box. **depending on your tool(s). Some tools don't have remote capability so getting them on the target box is needed.

You can do this by manually mapping and copying, copying the files from a central repository, or even have them pre-deployed on the box. (I am not necessarily a fan of pre-deployment...considering your pre-deployed tools could be tampered with on the compromised system). Utilizing a central repository can give you control over the files but allowing the ability to pull the files down to the suspect system.

To actually run the tools you will need the ability to run commands remotely. To stay with the enterprise Windows environment, PsExec is an excellent tool for these type of operations. (do it securely though, depending on how you do it, it can pass the password in cleartext.) Consider launching a command prompt on the local system with the IR account, and then run PsExec. The remote process will run under the account PsExec was launched from, and in this case it will be the IR account.

Wednesday, March 14, 2012

Incident Response Essentials p1

Obviously there are multiple layers and scenarios to consider when responding to incidents. And the tools you use to detect/collect/analyze/mitigate really depend on the threat scenario.

So what are the basics?  What do I need for the bare minimum for response operations? (w/ a focus on Windows systems)

Below is a list of the items I like to collect for response operations: (your mileage may vary)
  • $MFT- Master File Table for later parsing/analysis
  • Prefetch files
  • ntuser.dat(s) - just grab em all...
  • AutoRuns - reg entries/startup folders/services/etc.
  • Network info - ipconfig/netstat - dnscache - hosts file
  • Event Logs - OS logs - AV logs - other app logs (if applicable)
  • Scheduled Tasks 
  • Loaded DLLs
  • Memory Dumps**  If possible I like to capture the running memory from the system if space and time allows. A lot of good stuff can be pulled out of running memory if you want to learn about the malware/attack more. Will go deeper into this topic in a later post.
BTW, you can get this information easily utilizing some scripting and free tools. I'll cover those tools (free & not free) in another blog post.


Tuesday, November 1, 2011

FBI says Russian spies got close to Cabinet - Washington Times


Some interesting tid bits about the Russion spy ring break up last year:

[snip]-- a key break in the case developed in the mid-2000s after the FBI was able to decipher coded electronic communications between Moscow and the deep-cover spies. The communications were used to unravel the network, ending the FBI probe that began more than a decade ago.
Breaking the electronic codes used by the “illegals,” as the Moscow spies are called, was a milestone in the case that allowed FBI agents to pose as the spies’ handlers and identify the spies.
“Ultimately, at the end of the case, we were able to become the Russians,” Mr. Figliuzzi said. “The point where we decrypted the communications allows us to basically own the network.”

Full story at the Washington Times: FBI says Russian spies got close to Cabinet - Washington Times

Friday, September 23, 2011

From the man who discovered Stuxnet, dire warnings one year later

Stuxnet, the cyberweapon that attacked and damaged an Iranian nuclear facility, has opened a Pandora's box of cyberwar, says the man who uncovered it. A Q&A about the potential threats.


















Continued at  Christian Science Monitor....

Tuesday, August 2, 2011

Operation Shady RAT

Operation Shady RAT - "Operation Shady rat ranks with Operation Aurora (the attack on Google and many other companies in 2010) as among the most significant and potentially damaging acts of cyber-espionage yet made public. Operation Shady rat has been stealing valuable intellectual property (including government secrets, e-mail archives, legal contracts, negotiation plans for business activities, and design schematics) from more than 70 public- and private-sector organizations in 14 countries. The list of victims, which ranges from national governments to global corporations to tiny nonprofits, demonstrates with unprecedented clarity the universal scope of cyber-espionage and the vulnerability of organizations in almost every category imaginable." - Vanity Fair

Original Story: Operation Shady RAT - Vanity Fair

(update) McAfee Labs Blog: Revealed Operation Shady RAT

(update) McAfee Operation Shady RAT report (pdf)

Thursday, July 28, 2011

MoonSols BlackMoon Memory Analyst

So I got lucky enough to take a look at the memory analysis tool being developed by MoonSols called BlackMoon Memory Analyst.  Currently the tool is in Beta, but already it is looking to be a pretty solid memory analysis tool.

I can only compare it to the tools I have used such as: ResponderPro, Memoryze/Auditviewer, limited exposure to Volatility, and have worked with the fairly new Redline.  From the current looks of things BlackMoon Memory Analyst will be real nice option to take a look at when you are evaluating what you want to use.

It has a nice clean interface and navigating it is pretty easy.  I did have some issues navigating or finding things, but that could be primarily because I am slow. The tool is still in Beta so there are still some kinks in my testing. I am learning some of the functionality without reading the manual (bah! who needs a manual) so you have to take that into consideration... :)  If you've done memory analysis before though, it isn't very hard to find what you are looking for.

When initially opening it you get the choice of opening a raw memory dump, hibernation file, or Microsoft crash dump.  It has a report function that dumps out to .xml format so it should be digestible by a whole host of systems you may be able to use for IOC analysis across the enterpise.

Just some screen shots:







As a side note: MoonSols recently released their quick and easy DumpIt memory tool.  It is fast!! Check it out here: http://www.moonsols.com/2011/07/18/moonsols-dumpit-goes-mainstream/