Regarding my last post

I’ve all ready received mixed feelings about my decision on Intersect and the comments in my last post about disclosure in general. I just want to clear a few things up about the future of the project.

Current progress plan

• Intersect development will continue
• Semi-Private Git repository for future updates & releases
• Current releases remain available on Github
• All code will still be open source and free of any monetary charge
• Slight license changes for public distribution (I’m not sure how this will work yet)

Ideally I’d like to let Intersect live and breathe but I think it’s hard to make a distinction between how to publish something like this intended for legitimate usage and where it becomes more harmful to the security that we’re trying to protect and advance.
With that said, I’d really enjoy to hear everyone’s feed back on this and what they think, not just project specific but the disclosure issue as a whole.

As of recent…

Over the past month and a half, it might seem that I have all but disappeared from the interweb.

I do admit I have not been as socially active around here in some time, but I assure you the rumors of my death have been greatly exaggerated.

The most noticeable decline in activity for some of you has probably been the public development of Intersect.

 

 

 

 

 

Let me just say that the Intersect project is alive and doing very well. Over the past two months, I’ve added several major features that make the previous stable build look like a joke. These features are also the same reason that the public will never see this version of Intersect.

Intersect can now inject the shells directly into other running Python processes. Processes and network connections are hidden from ls, netstat, lsof, etc. Privilege escalation modules. Fully automated data collection and exfiltration. Time-based and C&C style module execution. Onion-style data exfiltration. Modules are fully executed in memory. Network communications hidden within normal data streams. And these are only a handful of the major additions. So, what’s the problem?

Public ‘Security’ Tool Disclosure

The majority of malicious attacks, malware, exploit kits, script kiddies and the like all survive almost purely from publicly disclosed
tools and exploits. Every security researcher or programmer that publishes a new exploit, attack vector or ‘penetration testing’ utility is contributing to the exact reason we need better security in the first place.

Take a look at SQLMap. I’m not bashing it, The developers responsible for coding SQLmap are great guys. I even implemented some of Bernardo’s code into Intersect. But after all the mass SQL injection dumps sponsored by Anonymous / LulzSec that were likely performed by SQLMap and/or Havij…. it’s time to seriously re-evaluate how we disclose information.

Mass malware and exploit kits rely almost entirely on publicly disclosed exploits and attack methods. There is no evidence, that I’m aware of, to even slightly suggest that full disclosure, even ‘responsible’ disclosure, has resulted in more secure systems and lowered levels of compromise.
The problem with publishing security tools like this is that the developers have all ready done the hard part for the attacker. It’s not just some abstract write-up and a semi-working proof of concept. You are distributing a fully weaponized utility. To quote Dan Guido’s Vulnerability Disclosure talk; “It’s not 1995 anymore, script kiddies grew up too!”

tl;dr In the beginning, Intersect was a simple way to automatically collect system and user information. Now it’s turned into a full-blown Linux rootkit and backdoor with more than enough methods for a real attacker to infect, hide, persist, escalate, steal, and attack a system they otherwise would not be tempted to. I don’t want to be involved in enabling any script kiddies to pop some box and have their data end up on pastebin.

The development of Intersect will continue, just not publicly. Thanks very much to everyone who supported me and this project in the short-while that it was public. I really truly appreciate all the interest and support that everyone showed. 

Preview of the new Intersect v2.5.5

Just a few screen shots of the upcoming release of Intersect Framework 2.5.5. The official release will be out this weekend but for now here’s a little preview of the new edition in action.

 

Create.py is no more. Now you build stand-alone server-side shells with this.

 

The target only needs to run the small server script you generate with the above application. All of the modules are stored on the attackers system, encoded, sent to and executed on the target system on demand.

 

Use the main Intersect application to interact with targets, build server-side shells, or start a new client or listener.

 

Using the :client or :listener commands, you can configure Intersect to interact with your target shells.

 

New Intersect client-server system

Okay here’s the break down. All modules are stored on the attacker system. Target runs a small shell server script that the attacker connects to. When attacker executes modules, they are encoded, sent to the target, decoded and executed on the fly. tl;dr No more massive 3,000 line Python script on the target system. No more needed to cram all your modules onto the target system. Everything happens over the network, no modules are written to the target system, they are all executed purely in the shell servers memory. 

Here’s a few screenshots. New release coming soonish.

Switch to WordPress

After some debate I decided to move my blog over the WordPress. My original blog was hosted with http://www.publr.com and while they do have a very nice interface, video embeds and some other cool features, the constant downtime is too much to deal with.

The Publr service doesn’t seem to be set up all too well. If the domain receives too much traffic, every single blog is completely unreachable. Sometimes for hours at a time. 

I don’t write posts that often to begin with but when I want to, I’d like to be able to at least reach my site. So here we are…WordPress.

Documentation and Logging during a pentest

Documentation is one of the most important aspects of a good penetration test. Not only does it help you, the tester, keep track of what you’re doing and allow you to provide better results to your client but it also covers you in case anything bad happens during your penetration testing.

Let’s imagine this scenario for a minute…You’re performing a penetration test of XYZ International. You just managed to penetrate one of their systems and are starting your post-exploitation pillaging. So you start running some automated tools or even manual tasks to find the data you want. Right in the middle of your pillaging, the target box crashes. Not only does the target box crash….but the entire VLAN crashes.

Was it something you caused? Probably not. Hopefully not. Either way, XYZ International will not know for sure if you were responsible or not, unless you have proper documentation and logs of every action you performed. You might still get blamed but the chances are alot slimmer. You can show them the logs and point to the exact actions you performed, when they were performed and explain any possible side-effects, if any, those steps might have had. Long story short, Logs cover your own ass.

Without logs and documented steps that were performed, you might be out in the cold. Even in a situation where your action was the cause of a system or network crash, you will atleast be able to identify what happened, why it happened and help the client take the proper steps in correcting the problem.

Often times, penetration testers are classified too broadly in bad situations like this. The client will think because you are ‘playing the malicious attacker’ that any malicious or negative activity that happens or is found during your testing is automatically your fault. I’m sure you’ve all heard horror stories of a penetration tester finding a backdoor or botnet on a clients network during a test…they bring this to the attention of the client only to then be blamed for placing the malware there themselves. It doesn’t happen incredibly often and while we all know it’s a ridiculous claim, you need to be prepared to protect and explain yourself.

Log and document every thing you do. It will be much easier to write your final report, will help you explain the steps taken to your client and might end up saving you some trouble.

Major upgrades in the works…

There are some very big upgrades and additions being worked on right now for the Intersect Framework.
One of the problems I hear about most often is that all the modules are currently stored on the target system and the script must be executed (mostly) with direct shell access to the target.

This is obviously not ideal in many situations. With some great suggestions from someone smarter than myself (Yes, they do exist!), I started working on the next major upgrades to Intersect.

Here’s a full, but not finalized, list of all the new goodies to look out for:

• Can still build Intersect scripts in their current implementation if you wish
• All new client-server templates
  - modules will be stored on the attackers system and sent to the target only when needed
  - target will only need to run a small shell server that will receive shell commands and handle requests for incoming modules
  - when target executes a module, it will be read from the local system, encoded and sent to the target server. the target server will then decode, read the module into memory, execute the specified module tasks and pipe the output back to the client
  - no module files will need to be written or saved directly onto the target system, all the mod execution will happen purely in the shell servers memory
• New ‘dropper’ scripts
  - Various ways of getting your Intersect shell server onto the target system
  - small bash script that will download and execute the script
  - small C++ application. opens connection to the attackers system then downloads and executes the Intersect script
  - download-exec shellcode that can be sent via exploit payload, MSF payload, etc
• Completely rewritten API wrappers
  - All of the API functions will be re-written to handle the new client-server system and module handling
  - Lots of all new API functions will be implemented as well
• New Logging and Reporting system
  - Complete re-work of how Intersect logs actions, saves files and generates reports
• Module re-write
  - The majority of the current modules will be rewritten to implement the new API and client-server system