In case you haven't, check out my web app sec blog series: www.exploit-db.com/category/maxe/ 

The best way to learn web app sec, is to learn a language such as PHP (knowing HTML, CSS and basic Javascript is elementary), and then understand why these bugs exist, how they look code-wise, and how to fix them. That way you can patch bugs, find 0days more easily, and know more. Or even create your own web app sec labs, which I've done for a few on a project basis sometime ago.

Take a look at this thread:
http://forum.intern0t.org/offensive-guides-information/1382-finding-vulnerabilities-php-sirgod.html

There are two options, one is that you pay for labs and/or training, e.g. Hacking Dojo, Offensive Security, MDSec (labs only) etc., while the other is that you set up your own lab ( http://www.securityaegis.com/pentest-lab-web-application-edition/ , there are plenty of resources on how to build your own lab, get a VMware ESXi server on an okay machine that hosts your lab, unless you host it with e.g. VMware Player or Workstation.), and use free resources such as security tube, forums, research / whitepapers, etc. (Plenty of papers on exploit-db, plenty of videos on security tube, and so on.)
It's all about asking the right question, when you search for knowledge on Google. 

It's quite common to bring our laptops on-site, and sometimes even scanner appliances as well, which can be quite huge and bulky. Sometimes when we do a host security assessment, remotely via a VPN connection or via another encrypted channel, we are told that we should save all our files in /tmp, and that any tools we install must in some cases be installed by them, or in other cases, be removed immediately after we have used them.
That's pretty much how we perform those kinds of tests. When we do wireless penetration tests, we bring our own laptops and alpha cards with good antennas as well. Otherwise, how would we be able to perform a test adequately and to e.g. high standards? 

I think you should learn more about NMAP, as it has been possible to scan multiple hosts in that tool, since the beginning I assume, as I have been able to do it for the last 10 years.  

Scheduling scans, is possible with Nessus, Qualys, Burp (pro version only afaik), Acunetix, and a variety of other tools. I can schedule almost anything natively in each program, except for NMAP in the command line as far as I am concerned.


No it won't overload the network interface if you do it with e.g. NMAP. If you use hping and send a syn flood with no timeout, you will most likely overload it, because you will be sending a million packets in a few seconds, while NMAP, even with -T5 (timing: aggressive), will probably never do that for good reasons. Same thing with scanrand.

There is no slowing down of the scanning process, only waiting for the final results. (i.e. it would take longer.)

Plus, what else should you be doing on your own computer, or your dedicated computer having a network purpose, while you scan for open services? Nothing. If you don't know what is available to you, the ethical hacker / penetration tester, there is nothing to attack server-side, so naturally like any other hacker do, you do the scans, even if it's just a simple port scan, and then you dive in further. (See Penetration Testing Frameworks, such as NIST SP800-42, PTES, etc. There's a reason why port scanning, is one of the first (not the very first), process of penetration testing, before you even think about anything else.)

Try:


Or whatever your local IP-address range is. /24 is a CIDR notation, which I won't explain in detail, but in this case it means "192.168.1.0-192.168.1.255". So, you would be scanning multiple hosts with NMAP, and I don't see any problems with that  


Exactly how do you think penetration testers, etc., work when they have to attack a network of 300, 1000, or 10000 hosts? Do you think they specify each single scan manually, or do you think they specify ranges or hosts?  

Being able to schedule scans directly with the port scanner, without using custom scripting such as bash. (I am not familiar with a default feature within the commandline package that allows this. But the Windows package should have a service that can do this, Inprotect probably has it too: http://inprotect.sourceforge.net/ )

As far as I know, if you specify a Syn Scan (TCP) -sS, or e.g. a UDP Scan (UDP) -sU, without specifying any port, the top 1000 ports are scanned. The scanning is completely different, and UDP scanning often takes longer time, due to NMAP is waiting for a time-out when it does not receive an ICMP message such as: ICMP Unreachable.


There is no conflict. A port as others stated, is a port. The actual port number, does not define whether it is TCP or UDP, the service listening on that port does. The reason why NMAP shows it as ftp-data, as that is what this port is most commonly used for (i.e. NMAP has a default list it falls back on, when the port is closed, not responding (e.g. TCP wrapped), etc.), plus it's in the "reserved ports range" (i.e. the first 1024 or 1000). You could've easily changed a configuration file within a service, and made it listen on port 20 UDP though. (Keep in mind that on most if not all Linux distributions by default, you need root privileges to listen on the reserved ports. Completely off topic, but something to keep in mind when administrating servers and moving services to different ports.)


Port 20 can be either TCP or UDP as previously stated.  As to how this happened, check the above paragraph which describes how some of NMAP functions.

Now about the status of the port:
TCP Syn Scan) The first "SYN" packet in a TCP handshake is sent to a port, if the target respond with "SYN/ACK", the port is open. (The last packet confirming that the target said the port was open, which also establishes the connection, is not sent. This last packet is an "ACK" packet. Side-note: Some services on the target system, will send an additional ACK after the "attacker" has sent his "ACK" packet. This is why there are sites about e.g. "The 3-way TCP handshake is a lie", etc.) Anyway, that is how a port is determined whether it is open. IF the target respond with a "RST" (reset) packet, the port is closed. (Meaning the target reset the connection.)

TCP Connect Scan)
This type of scan sends the entire TCP handshake. This can be useful in some scenarios/cases where Syn Scans does not work or return different results. (Rarely, but it does happen. Note that this type of scan is slower and costs more server resources as well. As the session/connection after being established, will time out unless NMAP/Fyodor has changed that.)

UDP Scan)
When this scan is issued, a UDP packet is sent to a port (can't remember exactly what type of packet, this is not so important with UDP as it is a stateless protocol, i.e. it does not perform a handshake like TCP), and if the port is open, NMAP will determine this IF there is no response. (Will show up as open/filtered.)
If the port is closed on the other hand, the target will/should send an ICMP Unreachable packet to the attacker. (This is not always the case, but some firewalls and operating systems do this.) When this type of ICMP packet is sent, it is almost safe/certain to say that the port is closed.
If such a packet however, isn't received by the attacker and the -sV (banner grabbing) flag has been set, NMAP will send additional UDP probes with common UDP requests to these services, to determine what kind of service they are. If there is no response (i.e. packets are dropped at the target which is quite common), NMAP will use it's built-in list of ports and determine what kind of service is listening based on this. (In your case, ftp-data.)


I am not sure where you got that statement from, but you are somewhat right that TCP and UDP packets are not sent in the same "packet" at the exact same time. They are sent separately, and when both scans are used, i.e. -sS and -sU, the TCP Syn Scan is done first, and then the UDP Scan.

See scan below:

Even though this is not a technical response, but in case you need full CVSS scores, some scanners such as Qualys includes that as well. (Qualys is similar to Nessus, except it's in the cloud, but they have network appliances you can deploy as well, both physical and virtual.)

There really isn't a good way of removing false positives from excel, except with some regex when you see a pattern, or by using perhaps another tool that may show the results in a better way as cd1zz suggested. I haven't tried NeXpose on enterprise networks as you describe so I can't really compare yet 

CHECK and CREST is all about money, OSCP is about learning (even price-wise). CREST is e.g., a non-profit organisation, but have you seen their certification prices? And those are just certifications, no courseware included.

http://securityreactions.tumblr.com/post/32935107872/crest

Anyway, certification wise, both should test you fairly, depending on which level you go for, as CHECK has several levels, while OSCP is one level. You can always go for OSCE or OSEE, etc., to go to the next level though.

I know with CREST and I assume with CHECK as well, that report writing skills weighs a lot more than OSCP, as the latter is about technical skills, instead of being able to write a good report.

Another issue, at least from what I've heard from a few, is that they often run out of time with CREST and some with CHECK as well. Most of those I have talked with, that are CREST or CHECK certified, have never done any OffSec courses though, so it's hard to say whether the people that did CHECK and/or CREST simply lacks technical knowledge or not.

But I do know that even very experienced people ran out of time with CREST. (A lot of information security companies in Australia (at least the more serious ones I guess) are getting CREST certified, as it may become mandatory soon lol.)

Another thing with CREST is that there is a theoretical test, and there might be one for CHECK as well. This test, at least for CREST is a bit crazy/funny, as it asks the "student" taking the test, questions that you are never going to use, well, except if time machines are invented or you test on equipment from the 80's perhaps.

The last thing, is that at least with some if not all CHECK exams, is that they change every time. Meaning you can't give out a cheatsheet, plus they require you to wipe all electronic equipment you brought into the examination room.

Some people dare to say it's harder than OSCE, I say probably not in the sense of how technical it is, as OSCE in itself, is very technical if you don't get any outside help and only follow the courseware, then you either gotta be really good or able to come up with solutions to new problems you have never seen, fast. (Even with 48 hours allocated. I have seen many people fail the first time. But also a few pass the first time, some of those that passed the first time didn't do it 100% on their own.)

But if you don't have CHECK or CREST, and you live and work in the UK, I suggest you get the certification as you will need it sooner or later.

Try: https://www.hatforce.com/

FYI it's often hard to crowd-source these kind of projects, as the target company will often worry about who is allowed to attack and if they follow the same code of conduct, as e.g. an ethical hacker would.

Will do 3xban, haven't played with all of the items yet, but I have had some fun with some of the items 

The ability to request ?wsdl from a URL where it isn't specified by default, form the XML request without redundant headers (e.g. the same header mentioned several times), interpreting WS-Security error messages and relaying them to the user saying e.g. "You need to specify a valid username and password", and when the basic request has been formed, the ability to fuzz each field, look at the response for both returned values and error messages and report that to the user :-)

In essence, creating a working XML request can sometimes be tricky with some clients where their ?wsdl specifies another endpoint than what you have been given, so the tool should also be able to use a hardcoded ?wsdl URL that does not change even if the ?wsdl says otherwise. The tool should accept sample requests provided by the user, which the user knows is working, bypassing the initial phase/process in the program of creating a working XML request that responds as it should.

Just some ideas and the most annoying issues I have come across when testing.

Oh yeah, the tool should be able to proxy as well, so it can go through Burp, etc.

I am mostly experiencing issues with a WSDL defining too much (useless) information and incorrect endpoints when I am testing a WSDL that has just been moved from one location to another (from production to development) where the WSDL hasn't been updated.

We'll grap a beer then 

Great to hear you're back in action and getting better, as ajohnson says, drink some beers when you are up to functioning 100% and within normal parameters 

Yeah, when it comes to Web Services it's hard to find any good tools. I did go through quite a few presentations (Don't drop the soap, etc.) and tools (WS Digger/Fuzzer, Acunetix, etc.) but none of them were very efficient.

Using SoapUI and Burp with e.g. the Intruder module is an easy way to fuzz. Just make sure you have a working WS request first that issues a normal response, so you have a base to start out with.

I wish there was a decent WS-scanner though, like something that actually works better than any tools out there, as I even have to spend a lot of time using SoapUI as well sometimes, when I have to figure out how the requests are formed, when the WSDL response is returning too much information about optional fields that does nothing.

I am not in charge of the difficulty of the interviews, I am only doing the preliminary screening to see what kind of skill people have (i.e. if there is a basic foundation, it's good enough for for an interview.)  Currently I'd say it isn't too hard (but not too easy either), even though it does involve theoretical and practical tests.

The practical tests (where I have created or planned most of them currently) are considered OSCP difficulty, even though some bonus challenges will be added soon, to see if anyone got OSCE (or similar) skills as well. (Those are however, bonus challenges.)

As we are looking for both new and experienced consultants, the difficulty will differ between these, but they are far from impossible to pass.

Even if you shouldn't be able to pass the interviews, this doesn't mean you're not good enough as a hacker, it only means you may need to improve some of your skills or that your skill set may not fit into the company at the moment. (You could be expert at a topic we don't deliver services for.)

So if you don't have anything holding you back, wherever you are in the world and you think you have what it takes, then send me a PM with your certifications, skills and if you have any, previous experience, as your English skills are probably better than mine. (The job contains a lot of report writing, just like any other pentesting job, so good English skills is of course required.)