If they're using a Web Application which is freely available for download or purchase and you find a 0day in that, allowing you to get within the corporation from the outside world, the chance of that it works on the target network is high if there isn't any IPS's and / or WAF's imho :-) Of course, in some cases, configurations of the webserver, PHP, MySQL has to be taken into consideration, such as safe_mode, but even that can be broken in some versions.

But you're right that it's impossible to get exact replicas of machines really, since it doesn't stop at software level, it goes all the way down to the hardware and network equipment including configurations used.

Sorry for being unclear on my opinions, I didn't want to write an overly long reply where I might be misunderstood  

Realistic penetration testing, includes exploitation of the target but usually on a cloned network or not mission critical equipment / production equipment. (It wouldn't be good, if the server crashes while people are working.)

If you don't perform any actual attacks, it's rather a vulnerability assessment, because if you can only "guess", based on version banners and heuristics, that a target may be vulnerable, then you're just guessing and assuming the version banners are right, which can be easily spoofed / changed. (Security by obscurity, fools some people.)

Guessing that a target is safe, is not equivalent to that it really is. In some pentests, I did them after work hours to evade problems in case the server(s) shut down by accident (it can happen, even if you're very careful). In others it was possible for me to replicate parts of their services locally and then pentest those (hunt for bugs), and in case I found a bug (especially in web apps), it would be possible to confirm the bug and report it.

I haven't played much with snort, but have you checked the RAW logs which Snort outputs? It could be "BASE" not interpreting the logs in a correct way, since I assume that the rules hasn't changed much from 2.9.0.1 to 2.9.0.2

Did you try asking this question at: https://forums.snort.org/ ?

There is also a Snort emailing list, where you can submit emails to and get a much more appropriate response as well.

In essence, the problem is most likely located in:
A) BASE - The log parser / interpreter (likely)
B) The Snort rules (unlikely)
C) A setting within Snort, which you did not specify to your needs. (likely)

This is just my random guess at what seems to be most likely wrong.

To resolve problem C, check the user documentation. (It's quite long and well described.)

OSCP of course  The PWB course doesn't go directly into debugging, afaik. In fact it's mostly based around penetration testing with backtrack 

Learning the tools, from recon to exploitation and post-exploitation, and also not using the (common) tools, but also using alternative tools like Netcat (the swiss army bla bla  )

What OSCP and OSCE really takes, is primarily a lot of dedication and the ability to learn. Secondary, being able to think out of the box and think abstract yet logic. (That's what it takes of non-technical skills, but the ability to learn technical information is of course a must.)

Anyway, that's just my opinion and I know people are different too. Some might learn better in a class environment and therefore Hacking Dojo, may be better, but if you can do most on your own, then OSCP is the way to go. Even if you should get lost, there's help to get on the #offsec irc channel even though occasionally the help may be vague, not because people don't want to help, but either because you're making it too hard for yourself or because it's expected you find out by yourself because it's one of the ultimate ways to learn, you'll probably remember it the rest of your life if you do so.

For example, can you remember everything you learned during school, education, your job etc. down to almost any detail? Now compare that with what you taught yourself, by e.g. self-study, who knows it better? 

Anyway, I'm sure there's someone else that wants to help you in the right direction as well.

Sil: Nikto does more than request website directories. It also checks the HTTP options and reports them (especially if TRACE, PUT, etc. is found), it even tries to send some custom http headers you may forget to try.

I should however note, that I don't use Nikto alone. It's good as an assistant tool and there are some evasive options (and most likely timing options too) you can use, but for a primary tool it's not good enough though as previously mentioned, as an assistant tool it's perfect at least for me. It does however, create a lot of noise too, but not more noise than Owasp Dirbuster, that one creates a huge overhead.

Also, the default user agent of Nikto, contains the word Nikto. So if you just fire up Nikto without altering anything, some websites will deny you access. (Based on user agent.)  

I'm glad you explained the use of bash scripting to the other viewers of this thread as well, it's useful to know 

Courses by Offensive Security, are highly recommendable and you will learn a lot but also go through a rough period of learning, including trial and error 

I've done OSCE, and that was pain inserted directly into my cerebrum 

It was awesome though, and it has given me something I can use for the rest of my life.


I haven't tried LSO, eLearnSecurity and Heorot (Hacking Dojo) yet, but in the future I most likely will 

It's quite common for people and companies to exaggerate, even in Sweden   

There's no such thing as 100% security or "unhackable". There is however, 99,9% security which one can obtain though that is not an easy task. I believe their biggest threats are:
- Social Engineering
- Physical Attacks
- Disgruntled Employees
- Malicious / Rogue Clients
- 0days (as per usual).

Two points should be made though. One, it wouldn't surprise me if several vulnerabilities exists in their server which are not public known. Two, a hacker may already have access to their servers or communication channels but has hidden him- or her-self so well that they have not discovered this yet.

Just like some networks are already (heavily) backdoored by hackers. (Blackhats)

Nice review 

@xXxKrisxXx: Learning Assembly during the course or already knowing it is a very good idea.
Many parts of the course contains assembly language, so getting to know it is inevitable.

You don't have to be able to write assembly programs entirely yourself, but being able to understand most of what happens e.g. in a payload is not a bad idea at all 

It's an awesome course, highly recommendable!

Thanks, I've updated the thread with the current challenge  It's the hardest challenge yet, enjoy

Depending on which web application they are using on port 80, 443 and perhaps 8080, (and even alternative ports), try to replicate their setup as much as possible especially including addons. Then begin auditing / pentesting those addons locally and try to locate / find vulnerabilities in those, then if you're permitted, check if they work on the target site.

Furthermore, you can also try to replicate the software they use and fuzz that and hope you may find a 0day within that, simply by fuzzing the hell out of those services in a smart way of course.

Also, check how many vulnerabilities has been previously been found within the products / software and web applications they use, what kind of vulnerabilities are the most common to be found within these, and so forth. Your chances of finding a similar vulnerability is high in case the same type of vulnerability "respawns" within certain versions when new features are implemented.

For instance, Persistent and Non-Persistent Cross-Site Scripting vulnerabilities are quite common to be found within vBulletin, compared to SQL Injection, Local and Remote File Inclusion and especially Remote Code Execution. So if you had to pentest vBulletin, then your best bet would be Cross-Site Scripting.

There's a blog here, about a 0day found within vBulletin recently:
http://www.exploit-db.com/vbulletin-a-journey-into-0day-exploitation/

It was found by mistake, while I was doing some voluntary administrative work for another site, and after confirming the vulnerability I used a few days to research and develop a working exploit.

If the target is using custom coded software on their server it is harder to develop an exploit for of course, but if they're using a Web Application, then the possibility of a vulnerability existing is increasing on a major scale. Especially due to insufficient time for the developers to either code secure applications or learn how to do that, and of course, implementation issues 

Start by learning Windows in depth and when you've done that, learn how to use Linux (use it on a daily basis.)

While you're doing this, pick up a few web applications to learn and begin slowly with for example PHP at w3schools.com

Then pick up a scripting language like Python or Perl, I prefer Python because it has similarities to PHP even though the whitespace is a major difference.

When you're learning these, a programming language like C or C++ could be a good idea, or at least to study Assembly somewhat but wait with these since it'll probably make no sense for now.

You should of course, grab a couple of books as well, perhaps from amazon.

If you just want a link, here's probably one of the best I've seen:
http://myne-us.blogspot.com/2010/08/from-0x90-to-0x4c454554-journey-into.html

My preferences are Acunetix and Burp Suite (free, though pro sounds cool) + Nikto (open source) and W3AF (open source) mostly.

However, a Web App Scanner can only do a part of the job, you should always check vulnerabilities and potential vulnerabilities manually since there are some that a scanner may never find, for example the latest 0day in vBulletin.

The possibility of a web app scanner finding that, is low due to the complexity of the attack including user interaction.

Most of the time I'm using manual methods especially on well known web applications since the web app scanners only finds common minor risks which is good to have included in the report, but it's rarely I see anything really critical.

The power of the scanner is when it comes to iterations, such as looking for files and directories that shouldn't be there, common vulnerabilities that a hacker might not look for, such as TRACE requests enabled (which has a very low attack vector), public log files which can't be used to penetrate the target, and perhaps backup files which can be really useful. (and so forth)

Good luck with your future penetration testing of websites and of course your choice of scanner and pentesting framework.

Thanks impelse and eternal_security, and yes you are right that from the very beginning to the end it began on an intermediate skill, at least for me to the most hardcore challenge I have ever done. Still, highly recommendable 

Good luck with the course eternal_security, it'll challenge you and you'll enjoy most likely every bit of pain included within the course 

Thanks impelse and awesec, I am glad that I after so many months of struggle finally did it  There was of course, even a short period where I was unsure whether I could actually do it but I didn't give up hehe I kept fighting till I had a solution 

Thanks hayabusa, MicroJay, and sil