Changing the debate..
April 23, 2009
So Brian Krebs interviewed Joe Stewart about his upcoming presentation at RSA and changing the way we do business in the realm of passive/aggressive cyberwar.
Time for an Internet A-Team?
It was a pretty good article.
I posted a challenge to them to continue the debate in a regular series working through the ins and outs and thought memes that will really serve to perculate and become real game changers. I even offered to host their data on these bad actors on my site.
As you know we have our SPOTLIGHT SHINE Bright Series that has its goals of identifying and disrupting these bad actors.
I also requested that they come on here and let me interview them to explore these new concepts and challenge them to stretch the bounds of their operational constructs. I would like to bounce some of my ideas around an echo chamber with Joe’s since we are both idea guys and see what could be possible in the real world.
Wow, Way to go guys, Moving on….
April 21, 2009
The title says it all….
Hackers Swipe Terabytes of Sensitive Pentagon Data
Apparently the F-35 program has been hacked multiple times. Nice 
Way to go with maintaining our pointy tip of the spear. You develop, we rip it from you. Billions in R&D lost. However if I was on the other side of the fence, and I had the capabilities I would steal it from you to if I knew you were too gutless to stop me or fight back.
This is entirely possible. I was on a proactive malware seek and destroy digital forensics team for a major defense contractor where we found some of our workers doing DEVELOPMENT work via AirForce Virtual Private Network remote access on small little systems such as AirForce One, the B-52, the Prowler and other air based electronic attack platforms and systems.
The developer was going out getting all kinds of little opensource and development tools and using them in his work, and somehow got all munged up with a malware infestation. Needless to say we escalated that quickly however it amplifies the seriousness of if you get compromised and what can happen.
Firms like Northrop, Lockheed, BAE, Boeing are supposed to be the best in the cyber business but with firms so large and expertise so sparse, you cant guard everything all the time constantly. Theres lots of technical solutions for things however budgets are sparse and will is low, and Beauracracy is RAMPANT. Process and Rules choke out agility and innovation.
At the end of the day I believe game changers are needed to begin the targeted and offensive attacks of known cyber operators that are doing this for profit and espinage gain. I mean doing really bad things to these people and their systems and organizations.
The gauntlet is thrown, you have been slapped, what the fuck are you going to do about it…
Series: Looking through the keyhole – 76Service
March 25, 2009
A very slick Exploit pack that is destined to have a future. Mad props to one of my favorite researchers Dancho Danchev on making this information so accessible. He provides excellent analysis and commentary and in my opinion is a leading researching with the right mindset for this work.
Series: Looking through the keyhole – Adrenaline
March 25, 2009
Adrenaline. Another good exploit pack.
Series: Looking through the keyhole – Limbo
March 25, 2009
A very sophisticated pack that has been extensively written about.
I will seek out the source code to post and see if we can glean some intelligence on the authors.
Series: Looking through the keyhole – Traffic Pro
March 25, 2009
Traffic Pro is older than Icepack and Mpack and was popular because it was cheap.
Panda did an excellent writeup on it.
Series: Looking through the keyhole – Firepack
March 25, 2009
There is a small write up about it at da Panda, and some great analysis by Dancho here and here.
Version Firepack lite 1.1, Firepack 0.18, 0.17
Exploits for some its versions are available.
Possible Sourcecode can be found for the lite version here.
Here we actually see the original Russian version.
Now we can target the Coder DIEL and track him by his ICQ number.
Series: Looking through the keyhole – Asprox
March 25, 2009
Asprox has been around for a good long time and focuses on massive SQL injection attacks and templated Phishing campaigns. This stuff is really cyberweaponry on a massive scale. It also is used by money Mules campaigns. These are used to launder ill gotten gains and extract money from accounts where assets are transfered to.
WE ARE SEEKING INTELLIENCE ON SCREENSHOTS OF THE BACKEND INTERFACES FOR ASPROX.
Here is a great link from Shadowserver Foundation on tracking the resurgance of the botnet after the Mcolo fiasco.
Fiasco because it didnt do a lick of good.
I will post code soon on what I have from ASprox. There are many sites that track this.
Asprox has also moved to Fast Flux and has even innovated that into something called Hydraflux which utilizes another layer of defense to isolate its Motherships… Uh like WOW
HydraFlux : The many headed fluxnet
“Flux” is no longer the sexy beast that it might once recently have been and the M.O is unfortunately becoming a common fixture in the criminal landscape of the internet. However, one fluxnet operation recently stood up and stood out. The emergence may simply be an evolution in one flux herder codebase, or represent a new fluxnet operation altogether. I imagine many will call it ‘rock’ (which it is not) based on URL construction alone. The uniqueness of this particular fluxnet does not become apparent until you see what is happening on the other side of the redirection going further upstream. “HydraFlux” is bestowed as a result of operational behavior based naming.
For those who have examined flux net activity you might acknowledge a few commonalities on the backend that are shared among several flux operations where the flux node to mothership relationships are one to one. ( many clients -> fluxnode:80 -> mothership:80 ) <= (this is old school, sooooo 2006/07).
Enter HydraFlux
A small flux net (at this time) where each fluxnode endpoint maintains a one to many mothership relationship *in addition* to the use of non-standard ports for upstream mothership communications. Where “many clients” -> fluxnode:80 -> Multiple_Motherships:4449 . The fluxers are breaking the rules, and btw there *are* no rules. This may be just a bad experiment since HTTP on non-standard ports can stick out like a sore thumb. Oh yes, nginx servers are upstream, and no way to validate that those hosts are not sending traffic futher upstream, though I do believe this is a case of additional layers motherships further upstream beyond what is visible from the the Fluxnode perspective.
