Darknet - The Darkside

Don`t Learn to HACK - Hack to LEARN. That`s our motto and we stick to it, we are all about Ethical Hacking, Penetration Testing & Computer Security. We share and comment on interesting infosec related news, tools and more. Follow us on Twitter, Facebook or RSS for the latest updates.

02 December 2006 | 18,682 views

Writing Worms for Fun or Profit

Cyber Raptors Hunting Your Data?

0x00: Preface

Media, kindly supported by AV “experts”, drawn apocalyptical vison of desctruction caused by stupid M$ Outlook / VisualBasic worm, called “ILOVEYOU”. Absurdal estimations – $10M lost for “defending the disease”, especially when you take a look at increasing with the speed of light value of AV companies market shares, made many people sick. Lame VBS application that isn’t even able to spread without luser click-me interaction, and is limited to one, desk-end operating system… Worm that sends itself to people in your addressbook, and, in it’s original version, kills mp3 files on your disk [1].

And you call it dangerous? Stop kidding.

Over year ago, with couple of friends, we started writing a project, called ‘Samhain’ (days ago, on packetstorm, I noticed cute program with same name – in fact it’s not the same app, just a coincidence ;). We wanted to see if it’s difficult to write deadly harmful Internet worm, probably much more dangerous than Morris’s worm. Our goals:

  • 1: Portability – worm must be architecture-independent, and should work on different operating systems (in fact, we focused on Unix/Unix-alikes, but developed even DOS/Win code).
  • 2: Invisibility – worm must implement stealth/masquerading techniques to hide itself in live system and stay undetected as long as it’s possible.
  • 3: Independence – worm must be able to spread autonomically, with no user interaction, using built-in exploit database.
  • 4: Learning – worm should be able to learn new exploits and techniques instantly; by launching one instance of updated worm, all other worms, using special communication channels (wormnet), should download updated version.
  • 5: Integrity – single worms and wormnet structure should be really difficult to trace and modify/intrude/kill (encryption, signing).
  • 6: Polymorphism – worm should be fully polymorphic, with no constant portion of (specific) code, to avoid detection.
  • 7: Usability – worm should be able to realize choosen mission objectives – eg. infect choosen system, then download instructions, and, when mission is completed, simply disappear from all systems.

With these seven simple principles, we started our work. This text describes our ideas, concepts and implementation issues. It is NOT the terrorist’s handbook, and has not been written to help people to write such piece of code on their own. It’s written to show that very serious potential risk, which we virtually can’t avoid or stop, isn’t only hypotetical. Code provided here is partial, often comes from first, instead of most recent, Samhain release and so on. But remember – working model has been written. And this model is deadly dangerous engine, which can be used to very, very bad things. Probably we aren’t the first people who thought about it and tried to write it, that’s what make us scared…

Winter 1998, three bored people somewhere in the middle of Europe.

Sit and relax.

0x01: Portability

This is probably the most important thing – we don’t want code that can run only on Windows, Linux or Solaris, or – worse – can run only on x86. The task is quite easy to complete if you decide to spread your code in platform-independent form. How could it be achieved? Well, most of systems have C compiler :) So we might spread worm in source code, with simple decryptor (let’s say it will be shell script).

But wait, some (not much) systems don’t have C compiler. What can we do? Using wormnet, worm during infection might ask other wormnet members for compiled binary for given platform. Wormnet details have been described in section 0x04. Anyway, binary will contain appended source code, to make futher infections possible within standard procedure. Infection scheme is described in section 0x03.

First version of our decryptor looked like this:

It used very simple (per-byte increments) “encryption” for source code with custom increment value (decryptor has been modified accordingly to choosen value – \x01, \x02, \x03 and \x04 are changed by encryptor routine). Also, this constant decryptor has been every time re-written using simple polymorphic engine (see section 0x06) to avoid constant strings. Later, we modified encryption routine to something little bit stronger (based on logistic equation number generator in chaotical window) – in fact, it only makes it more difficult to detect in inactive form.

As you can see, this decryptor (or it’s early version shown above) isn’t highly-portable – what if we don’t have bash, compiler, gzip or such utilities? Well, that’s one of reasons we’ve decided to join worms in wormnet – if sent code won’t connect back to parent and report itself, host is not marked as infected, and wormnet is asked for pre-compiled binary for given architecture (assuming we already infected this architecture somewhere in the world, and we had needed utilities, or we’re running the same architecture as infected host).

NOTE: For writing extremely ugly code that can run in DOS, [ba]sh, csh, perl etc and can be compiled with C in the same time, please refer IOCCC archives [2].

Sebastian wrote virus code that can spread both on Windows/DOS platform with C compiler and Unix systems with no modifications nor any interaction. It does cross-partition infections and installs itself as compiler trojan (modifying include files to put evil instructions in every compiled source). It is called Califax and has been developed while writting Samhain, as an excercise to prove that such cross-system jumps are possible. I don’t want to include Sebastian’s sources with no permission, all I want to say
is he did it within 415 lines of c code :) Califax hasn ‘t been incorporated within Samhain project, as we don’t want to infect Winbloze for ideological reasons :P

0x02: Invisibility

After breaking into remote system, worm not always have root privledges, so first of all, we wanted to implement some techniques to hide it, make it look-like any other process in system, and make it hard to kill until there’s a chance to gain higher privledges (for details on system intrusion, please refer section 0x03). Also, we made sure it’s really hard to debug/trace running or even inactive worm – please refer section 0x05 for anti-debug code details.

Our non-privledged process masquerading code consists of following parts:

  • masquerading: walk through /proc, choose set of common process names and
    change your name to look just like one of them,
  • cyclic changes: change your name (and executable name) as well as pid
    frequently; while doing it, always keep ‘mirror’ process, in case parent
    or child get killed by walking skill-alike programs

Our goal is to make almost impossible (with common tools) to ‘catch’ process, as all /proc parameters (pid, exe name, argv[0]) are changing, and even if one of them is catched, we have ‘mirror’ project. Of course, at first we should avoid such attempts by camouflage. This comment comes from libworm README for Unices:

— snip from README —

a) Anti-scanning routines

Following routines are provided to detect anti-worm stuff, like ‘kill2’
or anything smarter. You should use them before fork()ing:

int bscan(int lifetime);

bscan performs ‘brief scanning’ using only 2 childs. Lifetime should
be set to something about 1000 microseconds. Return values:
0 – no anti-worm stuff detected, please use ascan or wscan.
1 – dumb anti-worm stuff detected (like ‘kill2’); use kill2fork()
2 – smart (or brute) stuff detected, wait patiently

int ascan(int childs,int lifetime);

ascan performs ‘advanced scanning’ using given number of childs
(values between 2 and 5 are suggested). It tests environment
using ‘fake forkbomb’ scenario. Results are more accurate:
0 – no anti-worm stuff detected (you might use wscan())
1 – anti-worm stuff in operation

int wscan(int childs,int lifetime);

wscan acts like ascan, but uses ‘walking process’ scenario. It
seems to be buggy, accidentally returning ‘1’ with no reason,
but it’s also the best detection method. Return values:
0 – no anti-worm stuff detected
1 – anti-worm stuff in operation

int kill2fork();

This is aletrnative version of fork(), designed to fool
dumb anti-worm software (use it when bscan returns 1).
Return value: similar as for fork().

b) Masquerading routines

These routines are designed to masquerade and hide current

int collect_names(int how_many);

collect_names builds process names table with up to
‘how_many’ records. This table (accessible via
‘cmdlines[]’ array) contains names of processes in
system; Return value: number of collected items.

void free_names();

this function frees space allocated by collect_names
when you don’t need cmdlines[] anymore.

int get_real_name(char* buf, int cap);

this function gets real name of executable for current
process to buf (where cap means ‘maximal length’).

int set_name_and_loop_to_main(char* newname,char* newexec);

this function changes ‘visible name’ of process to newname
(you may select something from cmdlines[]), then changes
real executable name to ‘newexec’, and loops to the
beginning of main() function. PID will be NOT changed.
Set ‘newexec’ to NULL if you don’t want to change real exec
name. Return value: non-zero on error.

Note: variables, stack and anything else will be reset. Please
use other way (pipes, files, filenames, process name) to
transfer data from old to new executable

int zero_loop(char* a0);

this function returns ‘1’ if this main() code is reached for
the first time, or ‘0’ if set_name_and_loop_to_main() was
used. Pass argv[0] as parameter. It simply checks if
real_exec_name is present in argv[0].

For more details and source code on architecture-independent non-root process hiding techniques, please refer libworm sources [3] (incomplete for now, but always something).

This routines are weak and might be used only for short-term process hiding. We should as fast as possible gain root access (again, this aspect will be discussed later). Then, we have probably the most complex aspect of whole worm. Advanced process hiding is highly system-dependent, usually done by intercepting system calls. We have developed source for universal hiding modules on some systems, but it not working on every platform Samhain might attack. Techniques used there are based on well-known kernel file and process hiding modules.

Our Linux 2.0/2.1 (2.2 and 2.3 kernels weren’t known at the time ;) our module used technique later described in “abtrom” article on BUGTRAQ by (Sat, 28 Aug 1999 14:40:31) to intercept syscalls [4]. Sebastian wrote stealth file techniques (to return original contents of eventually infected files), while I developed process hiding and worm interface. Module intercepted open, lseek, llseek, mmap, fstat, stat, lstat, kill, ptrace, close, read, unlink, write and execve calls.

For example, new llseek call look this way:

In this case, we wanted to skip samhain code loader at the beginning of file. is_happy() function has been used to identify infected files. Unfortunately, it also has to check length of this loader – remember, it’s dynamically generated. This is code from is_happy() used to determine this size from our decryptor routine:

Worm isn’t spreading across the filesystem widely, so the problem doesn’t affect many files – only some executables called in boot process – to make sure we’re always resident. Process hiding is quite generic:

Also, we have to hide active network connections for wormnet and sent/received wormnet packets to avoid detection via tcpdump, sniffit etc.

That’s it, nothing uncommon. Similar code has been written for some other platforms. See my AFHaRM or Sebastian’s Adore modules for implementation of stealth techniques [5].

0x03: Independence + 0x04: Learning

Wormnet. The magic word. Wormnet is used to distribute upgraded Samhain modules (eg. new exploit plugins), and to query other worms for compiled binaries. Communication scheme isn’t really difficult, using TCP streams and broadcast messages within TCP streams. Connections are persistent. We have four types of requests:

  • infection confirmation: done simply by connecting to parent worm
    if infection succeded (no connection == failure),
  • update request: done by re-infecting system (in this case, already installed
    worm verifies signature on new worm when receiving request, then swaps
    process image by doing execve() if requesting binary has newer timestamp),
    then inheriting wormnet connections table and sending short request to
    connected clients, containing code timestamp.
  • update confirmation: if timestamp sent on update request is newer than
    timestamp of currently running worm, it should respond with ‘confirmation’,
    then download new code via the same tcp stream; then, it should verify
    code signature, and eventually swap it’s process image with new exec, then
    send update request to connected worms.
  • platform request: by sending request to every connected worm (TTL
    mechanism is in use) describing machine type, system type and system
    release, as well as IP and port specification; this request is sent
    (with decreased TTL) to other connected wormnet objects, causing
    wormnet broadcast; first worm that can provide specific binary, should
    respond connecting to given IP and port, and worm that sent platform
    request should accept it (once). Any futher connects() (might happen
    till TTL expiration) should be refused. After connecting, suitable
    binary should be sent, then passed to infection routines. Worm should
    try first with TTL approx 5, then, on failure, might increase it by 5
    and retry 3-5 times, we haven’t idea about optimal values.

Packets are “crypted” (again, nothing really strong, security by obscurity) with key assigned to specific connection (derived from parent IP address passed on infection). Type is described by one-byte field, then followed by size field and RAW data or null-terminated strings, eventually with TTL/timestamp fields (depending on type of message).

Wormnet connections structure looks arbitrary and is limited only by max per-worm connections limit. Connections are initiated from child to parent worm, usually bypassing firewall and masquerading software.

On infection, short ‘wormnet history’ list is passed to child. If parent has too many wormnet connections at time, and refuses new connection, child should connect to worm from the history list.

What about exploits? Exploits are modular (plugged into worm body), and divided in two sections – local and remote. We wanted to be platform independent, so we focused on filesystem races, bugs like -xkbdir hole in Xwindows, and inserted just a few buffer overflows, mainly for remote intrusion (but we decided to incorporate some bugs like remote pine mailcap exploit and so on… Code was kind of shell-quoting masterpiece ;)

Pine mailcap exploit (it has been already fixed after my BUGTRAQ post, but in late 1998 it was something new and nice):

Message body contained code to be executed (shell-script to connect, download and run worm, then kill any evidence). Yes, this exploit sucks – as it required some kind of user interaction (reading e-mail), but is just an example.

Both remote and local exploits are sorted by effectiveness. Exploits that succed most of the time are tried first. Less effective ones are moved at the end. This list is inherited by child worms.

Oh, spreading. Victims are choosen by monitoring active network connections. With random probability, servers are picked from this list and attacked. In case of success, server is added to ‘visited’ list – these are not attacked anymore. In case of failure, server is not attacked until new version of worm is uploaded. Of course, internal servers list is finite and sometimes server might be attacked again (if it’s not our child and it isn’t currently connected), but who cares, attempt will be ignored or upgrade procedure will happen, depending on timestamps.

This code is used to qualify host (obtained from network stats):

0x05: Integrity

The most important thing in worm’s life is not to get caught. We have to be sure it’s not easy to trace/debug us – we want to make reverse-engineering even harder. We don’t want to expose our internal wormnet protocols, communication with kernel module and detection techniques used by worms to check for themselves, etc. Four things:

  • – hide everything: see section 0x02.
  • – hash, crypt, scramble: see sections 0x01, 0x04.
  • – don’t let them caught you: see section 0x02.
  • – avoid debugging even if we cannot hide!

We used several anti-debugger techniques, including application-dependent (bugs in strace on displaying some invalid parameters to syscalls, bugs in gdb while parsing elf headers, ommiting frame pointer, self-modyfing code and so on), as well as some universal debugger-killer routines called quite often (they aren’t really time-expensive). This is one of them:

As I told before, worm modules were signed. First, using simple signatures, then using simple private key signing (not really difficult to crack, as key was relatively short, but for sure too difficult for amateurs). This made us sure we’re going to replace our worm image with REAL worm, not dummy anti-worm flare.

0x06: Polymorphism

Polymorphic engine was quite simple – designed to make sure our decryptor will be different every time. As it has been written in shell language, it was pretty easy to add bogus commands, insert empty shell variables, add \ and break contents, or even replace some parts with $SHELL_VARIABLES declared before. Getting original content is not quite easy, but of course, all you have to do is to imitate shell parsing of this decryptor to get original contents, then you’ll be able to identify at least some common code.

Code adding \ to decryptor looks like:

0x07: Usability

It’s stupid to launch worm designed eg. to steal secret information from specific host, because we have no idea if it will work fine, and won’t be caught. If so, it might be debugged (it’s made to be hard to debug, but, as every program, it’s not impossible to do it, especially if you’re able to separate worm code). Instead, we should be able to release ‘harmless’ worm, then, when we’re sure it accessed interesting host and haven’t been caught, we might send an update, which will try to reach destination worm, replace it with our evil code, then shut down every worm it can access via wormnet (by sending signed update, that will send itself to other worms, then shut down).

Maybe it isn’t the perfect solution, but in fact it’s probably much safer than inserting even generic backdoor code by default.

0x08: What happened then?

That’s it, the Samhain project, fit into approx. 40 kB of code. What happened to it? Nothing. It hasn’t been ever released, and I never removed restrictions from lookup_victim() and infect_host() routines. It’s still lying on my hard drive, getting covered with dust and oblivion, and that’s extacly what we wanted.

I stopped developing new code and testing it in January, 1999, with Samhain 2.2 and approx. 10000 lines of code. Wojtek Bojdol has been developing his much more advanced wormnet and system infection/monitoring code till February or March, but I haven’t found enough time to incorporate his sources within mainstream source tree. Then, we removed our repository from networked server we used to exchange ideas. I gradually published some bugs used in exploit database to BUGTRAQ, some of them (especially those not discovered by me) we kept for ourselves.

The story ends. Till another rainy day, till another three bored hackers.

You may be sure it will happen. The only thing you can’t be sure is the end of next story.

0x09: References

[1] ILOVEYOU worm:
Dramatical headlines:
+ http://www.cnn.com/2000/TECH/computing/05/04/iloveyou.03/
Technical analysis:
+ http://www.securityfocus.com/templates/article.html?id=30
Source of “ILOVEYOU” worm:
+ http://packetstorm.securify.com/viral-db/love-letter-source.txt

[2] International Obfuscated C Code Contest archives:
+ http://www.ioccc.org

[3] Libworm – unprivledged process hiding techniques:
+ http://lcamtuf.na.export.pl/pliki/libworm.tgz

[4] “yet another article about stealth modules in linux”
+ http://www.securityfocus.com

[5] Advanced File Hide and Redirect Module (in fact, old and lame ;)
+ http://lcamtuf.na.export.pl/pliki/afharm.zip
+ ???

Again this is an old article but it’s a good one, written by Michal Zalewski and edited by Darknet


30 November 2006 | 12,435 views

Hacking Tor – A Flaw Appears?

It seems finally someone has found a flaw in the way Tor works, a way to beat it and find out who is using the system.

Perhaps an end to the most anonymous system on the Internet?

I got this info fresh from SANS.

One of our readers sent in a very worrying analysis of what appeared to be “traffic modification” (in his words) on the part of the Tor network.

The Tor (“The Onion Router”) network is an anonymizing peer-to-peer network of routers on the Internet which uses various techniques to bounce traffic around the Internet in such a way that traffic analysis becomes difficult if not impossible to perform. Tor is a perfect example of a dual-use technology: it can be used to avoid government-imposed Internet censorship or to protect the identity of a corporate whistleblower but at the same time it is sadly ideal for various nefarious uses.

It seems to point to traffic modification on an exit node, packetstorm in particular.

The key tenet of Tor is that it should protect anonymity and the reader’s analysis pointed not only to traffic modification on the part of a so-called “exit router” (the last hop in a Tor circuit before your packets reach the real destination) but also an attempt at tracking the true origin of the traffic (in a Tor network a hop only knows that the traffic comes from a previous hop but no futher back).

Both William Salusky and myself looked into the data and it seemed to implicate packetstormsecurity.org, an exit router in Denmark and, more curiously, a DNS tunnel to transmit data out (via obviously fake hosts under the t.packetstormsecurity.org domain). This last item was interesting because it replicated data which was apparently being submitted to the host via an HTTP cookie so it seemed that the idea was to have the cookie travel to the unwitting Tor user and be sent back via DNS tunnel to an external host to confirm the real identity of the host. As both of us were busy we looked a little deeper but ultimately we recommended that the reader report this to the Tor authors.

A quote from the actual paper.

Clearly Tor’s designers have done a pretty good job: I couldn’t find any weakness in Tor itself that violate the tenets set out at http://tor.eff.org/ (basically that end-to-end traffic analysis is always possible, but the traffic analysis should [be] difficult to everything but a global Echelon). So instead, I attacked the data which Tor carries the most of: web traffic.

Worrying indeed, you can download the paper here:

“Practical Onion Hacking” by Andrew Christensen

Source: SANS

28 November 2006 | 7,518 views

the Art of Virology 01h

In this part we will discuss the basic framework of a computer virus… The basics of a virus consists of two elementary procedures (others will tell you three). These are:

  • a search routine
  • a infection routine
  • [anti-detection routines]

The search routine

This routine will have to be a more delicate one [but not hard to analyze at all], because as besides the search routine itself we will include file validation two, we will check within this routine if the file is read-only file, not as in some cases in which I saw that the virus search the file, found it and only when trying to infect it he realised that is read-only, and if no check done for it the virus would crash.

The infection routine

The trivial routine in a virus, because we do not need a search routine if we say for example we make a list of wanted to infect files, this routine (in COM viruses) will only write the whole virus in the host program and write a jump to it at the start of the file… simple don’t you think?

Pseudo-Code Virus

I know it’s the second article and what do you get? only a pseudo-code virus, but be pacient because I’m not so trustful to think that you have already read the book I recommended you in the first part… so wait until the 02h will be out; till then let’s check out our first virus:

If you don’t like it in pseudo-code, maybe you’ll like it in Pascal, so dowload Dirty Nazi Virus Generator and create a virus to analyze… I didn’t try them out but in theory it should work fine… if you don’t have a pascal compiler you can try freepascal

What more do I need to know before actually starting to write viruses?

This is an excellent question because even if the actual search and infect routine are simple to build in assembly, the DTA (Disk Transfer Area) is a little hard to understand so i’ll give you a book which will jump in your help (I advice you to read only the DTA part because the rest of it and even more I’ll treat them myself)…

The Little Black Book Of Computer Viruses

Almost forgot to mention, the password to the archive is Ludwig with the big L.

Another bitter end…

So this second part of the Art of Virology which is a bit easier to diggest than the first one, has finally ended. See you next time and hope that by the next chapter you have learned asm and read about the DTA… till then take five…

27 November 2006 | 19,802 views

Metasploit 2.7 Released – Automated Hacking

The Metasploit Framework is an advanced open-source exploit development platform. The 2.7 release includes three user interfaces, 157 exploits and 76 payloads.The Framework will run on any modern operating system that has a working Perl interpreter. The Windows installer includes a slimmed-down version of the Cygwin environment.

Windows users are encouraged to update as soon as possible. A number of improvements were made that should make the Windows experience a little less painful and a lot more reliable. All updates to 2.6 have been rolled into 2.7, along with some new exploits and minor features.

You can download the new metasploit here:

– Unix: http://metasploit.com/tools/framework-2.7.tar.gz
– Win32: http://metasploit.com/tools/framework-2.7.exe

A demonstration of the msfweb interface is running live from:


This may be the LAST 2.x version of the Metasploit Framework. All development resources are now being applied to version 3.0. More information about version 3.0 can be found online at:


Exploit modules designed for the 2.2 through 2.6 releases should maintain compatibility with 2.7. If you run into any problems using older modules with this release, please let us know.

For more information about the Framework and this release in general, please refer to the online documentation, particularly the User Guide:



24 November 2006 | 3,885 views

Oracle MEGA Patch Fixes 101 Security Bugs

Oracle in its very own style recently published a mega patch, it could be called the mother of all patches.

Actually 101 bugs…the scary part is 45 can be exploited remotely.

Oracle published the mother of all security patches containing 101 fixes for flaws in its database, application server, E-Business Suite and PeopleSoft and JD Edwards applications.

Almost half – 45 – of the flaws can be can be exploited by a hacker over a network, while at least six errors in the Oracle database http server can be exploited without the hacker requiring any user name or password. A re-assuring 22 database flaws do at least require some form of authentication.

In total, Oracle’s latest quarterly critical patch update (CPU) features 63 fixes for the database, 14 for its application server, 13 for the E-Business Suite nine for PeopleSoft and JD Edwards and two for Oracle’s Java 2 Enterprise Edition containers on the client. Oracle introduced the quarterly CPU system in November 2004.

This is the latest chapter of a painful security story for Oracle that makes Microsoft, whose software is the internet’s number-one target, appear a community role model.

If it isn’t the size of Oracle’s patches – a January CPU saw a bumper 103 fixes – then it’s their timeliness, or lack of.

Massive eh?

They are known for their lack of speed when it comes to fixing issues.

Red Database Security last year slammed Oracle for taking more than 650 days to fix six problems. And in January this year wNext-Generation Security Software (NGSS), a security research firm, released details of a hole in the Oracle’s Apache web server, saying Oracle was moving too slowly as it had taken 800 days to fix some of the problems in the January CPU.

Recently, Oracle’s response has been to chastise the likes of NGSS, accusing it of endangering users by publishing details of problems. Microsoft, at least, has had the grace to work with security vendors that post details of holes in Windows to the internet, and worked with them to fix the problem.

650 days, that’s almost 2 years. Surely that shouldn’t be tolerated.

Source: The Register

23 November 2006 | 6,430 views

Vulnerability Assessment and Operational Security Testing Methodology (VAOST) – version 0.2 released

Here is a newly released VA methodology, the author believes it to be more focused, and thus cost effective VA process. It may map to internal work, but it is probably more suited to external sites.

It’s gone through a couple of revisions so it’s a bit more polished now.

You can find the notes on the first version here.

Version 0.2 has been released after some community endorsement, there is still some work to do though, they hope to add the following shortly:

  • Pre stages to get management buy in
  • A complete worked example that shows the kind of results that can be produced
  • A more complete list of or supporting implementing software
  • A more complete list of attack tools for the authorisation checklist.
  • Better graphics
  • A standalone collection of the checklists

You can download VAOST version 0.2 here:

VAOST 0.2 (doc version)

The author welcomes your feedback and comments. The VAOST forum area where you can get the files will accept guest (ie un-registered) posts so you can add your comments there if you desire (note we will delete defamatory and rude posts to prevent our being sued!).

It is work in progress and we still have a long way to go, but hopefully, we can get there with your help.

The general VAOST forum can be found here.

22 November 2006 | 14,934 views

Web 2.0 Hacking with Firefox and it’s plugins

A dream come true, would I say… recently found this article on securityfocus, it’s awesome… all that you need (beside Firefox) is pointed out in the article, so go on, what are you waiting for…


21 November 2006 | 7,844 views

AttackAPI 0.8 JavaScript Hacking Suite Available

AttackAPI provides simple and intuitive web programmable interface for composing attack vectors with JavaScript and other client (and server) related technologies. The current release supports several browser based attacking techniques, simple but powerful JavaScript console and powerful attack channel and associated API for controlling zombies.

The standalone components of the library can be found at the following locations:

One infrastructure tool is available here:

I would recommend AttackAPI 0.8 to everyone who is interested in high-end hacking not because I wrote it but because it provides a good demonstration of what is possible today. That, I hope will take our awareness even further.

AttackAPI slowly moves to its 1.0 release where I am planning to standardize its core, fix discovered bugs and make it even more cross-platformed. Still, there is a long way to go but I am willing to take my chances. There are plans for 0.9 but I will keep them undisclosed for now.

So what 0.8 has to offer? There are a couple of things that worth attention. I will start in chronological order.

The Client interface can be used to enumerate the current client. It has functionalities to fingerprint the current operating system, installed plugins, the browser in use and the local NATed IP address and hostname. This tool is brilliant for doing the first steps of any targeted attack.

The Server, on the other hand, can be used to fingerprint the current server. It provides information about its domain, IP address, platform, server software and the application architecture. Its purpose is to identify what is currently available. That is important because the Web is very distributed and agile network and controlling dozens of infected clients is a mission on its own.

Full information on AttackAPI is available here:

AttackAPI 0.8

19 November 2006 | 7,239 views

Hackers’ Project – Browser Exploit Code Hiding

Hackers are developing new software that will help hide browser attack code from some types of security software.

The software, called VoMM (eVade o’ Matic Module), uses a variety of techniques to mix up known exploit code so as to make it unrecognizable to some types of antivirus software.

Using these techniques, VoMM “can create an endless number of variants of an exploit,” said Aviv Raff, one of the developers behind the project.

“It aims to provide several techniques out of the box to make browser exploits (mostly) undetectable,” according to a blog posting by one of the project’s founders, a hacker going by the name of “LMH.” That posting can be found here.

The software users server-side scripting technology to create new versions of the exploit code, which then get delivered to browser users when they visit the attacker’s Web site. By making a number of cosmetic changes to the code that do not affect its functionality, VoMM creates a new version of the malicious software that cannot be detected by “signature-based” techniques.

Signature-based antivirus products analyze known malware and then create a digital fingerprint that allows the antivirus software to identify malicious code. By adding extra components — tabs and spaces, and random comments and variable names — that are not included in known signatures, VOMM creates software that can evade detection.

The VoMM code is expected to be included in a new module for the upcoming 3.0 version of the widely used Metasploit hacking toolkit, Raff said. Metasploit developer HD Moore is also developing the VoMM software. Raff’s blog posting on the project can be found here.

Source: Infoworld

17 November 2006 | 5,753 views

w3bfukk0r 0.2 Forced Browsing Tool Released

w3bfukk0r is a forced browsing tool, it basically scans webservers (HTTP/HTTPS) for a directory by using HTTP HEAD command and brute force mechanism based on a word list. Features:

  • HTTP/HTTPS(SSL) support
  • Banner grabbing
  • User-Agent faking
  • Proxy support (HTTP/S)
  • Reports found and non-existend directories

Example output:

Note: Not all webservers are handling HTTP status codes correctly, so if the webserver doesn’t care about RFCs the report generated by w3bfukk0r may include false positives. Maybe we’ll find a good method to detect those false positives.

You can download w3bfukk0r 0.2 here: