Can somebody tell me as to what pen testers typically earns?
I once talked to a firm doing pen testing and the figures they paid were the same as any other firm would pay a midlevel developer working in a regular software dept in a corporation in that city.
Assuming pen testing requires a skill level a notch or two above the 'average' developer, I would have normally assumed that ideally they would be paid significantly better.
I get the idea that most pen testers are entry-level and spend their time doing standard scanning and looking for standardized types of vulnerabilities using pre-built tools and techniques. The ones who can build those tools and come up with novel attacks against well-protected targets are the top of the heap.
What is probably scary is just how many commercial sites can be compromised by those standard well-known techniques.
> most pen testers are entry-level ... What is probably scary is just how many commercial sites can be compromised by those standard well-known techniques.
... and the thought that there's an army of underpaid, underappreciated folks who spend all day every day honing the craft to perfection.
'We used to quip that “password” is the most common password. Now it’s “password1.” Who said users haven’t learned anything about security?' -- Bruce Schneier
I think it's about on par with what developers earn for the same skill bracket and location. As a pentester, I don't think it's necessarily about having _more_ skill than developers, it's just a different set of skills.
It widely varies depending on skill level, and unfortunately I can’t compare easily as I don’t know developer salaries.
If you’re in a major tech hub in the US, 75k for a junior, 150 for a senior, and upwards from there for someone with decent experience. $300k isn’t crazy for someone really good. Those are technical roles outside of management.
But those figures are skewed toward better orgs; some companies will take a fresh grad, throw them at some junk automated tools, and call them a pentester. This area of the industry is booming with the increase of compliance mandated testing.
Can someone explain how the enumeration of subdomains on a hostname works?
I know that zone transfers is one way, but I looked up one of my domains and it includes a private subdomain I've never published anywhere.
I checked and my DNS provider does not allow zone transfers (as far as I can tell) so I'm curious how this information is obtainable.
And I mean through ordinary means, let's ignore the "your account/ISP/Registrar may be compromised" scenarios. Are there everyday scanning tools that allow for this?
"The search relies on data from our crawls of the Alexa Top 1 Million sites, Search Engines, Common Crawl, Certificate Transparency, Max Mind, Team Cymru, Shodan and scans.io."
So probably CT logs.
Also, if you've ever sent a cold-cache query to a recursive resolver that didn't employ QNAME minimization (few do), it was likely harvested by pDNS replication at the TLD nameserver level and shared with a number of commercial and research parties' databases to which DNSDumpster may subscribe.
This seems like the most likely candidate then (a resolver that caches and shares requests or CT - which I didn't know about), because the subdomain is a random string of characters so it wouldn't have been brute-forced.
Zone transfers is one way, but you can also use brute force using a common word list. You can also these days use ‘OSINT’ (open source intelligence), and use things like TLS certificate transparency logs to go looking for obscure DNS names.
I can't speak for DNSDumpster, but a common technique I use to do subdomain enumeration is just brute forcing with a wordlist. By enumerating with a large enough wordlist, you can discover matching subdomains for a target domain.
Yeah this is a random string of characters so it can't be that.. Also my logs show it getting queried by automated tools within a few weeks of being live, so I suspect it's due to someone's else's suggestion that a DNS resolver somewhere is caching and sharing request data for "research" or other reasons.
This looks cool! I have the other perspective -- I have a site that I want secured. This seems helpful for that angle also. I'd be interested if there are other resources as well that could be suggested on this thread!
You should check out the youtube channel LiveOverflow [0], it's mostly about infosec and pentesting.
As someone who is neither into infosec nor pentesting, I found it to be a very interesting and informative channel which improved my understanding of coding and security in general.
I've done a bit of pen testing and the cheat sheet presented gives very good advice in one place for the basics.
I'd love to see web devs use something like the procedures outlined as a final check before going for sign off. When testing your own stuff, do the heavy scanning stuff "internally". You can always deploy a throwaway Kali Linux box on the same VLAN if its justified.
Now as to your question: Remember that the site itself may not be the actual target. For me, an awful lot of pen testing involves perusing Facebook, Twitter and the like and obviously peruse the site itself as a user. Customer testimonies, web dev links and their site's customer testimonies and proud stories are useful. I always spider for docs and look at metadata in them. Companies House and similar registries (in the UK, other countries may have similar) is handy to help join dots. A little imagination and publicly available information can inform a decent social scam.
My top advice here is pretend to be a baddie and look at your stuff from the outside. Once you discover just how exposed everyone is, then evaluate it and then start the staff/partner/whatever training. If applicable, your telephone reception should have a human firewall on it - mine does. I'm an MD of a small company and I defy anyone to get past them. They take great pride in making calls to me from ahem friends/colleagues/etc not get through but get a request to send an email to sales@<firm>.co.uk and yet I still get the calls I want. When they are uncertain they check with me first. Make it a challenge and part of the culture and deploy honest praise for a good job done. Gatewaying all of your calls via your experts rather than a DDI to all staff is a good idea.
Notice how most of the stuff I've gone into depth about doesn't really involve anything fancy technologically. If I was a real general purpose baddie, I wouldn't be fussed about your user accounts and passwords or even your company secrets. I'd be wanting to make your accounts department send me a few thousand quid to some random account. However, the industry or purpose of your ... system ... will inform your approach to pen testing and securing. I have had to pen test a few schools and I took a rather different approach than I would for a firm of accountants.
There's no right or wrong answer and remember that a web site is not in isolation. People use them.
> gives very good advice in one place for the basics.
And it's important to remember that these are the basics. I was able to perform a privilege escalation on a site (that I was supposed to be pen testing, nothing nefarious) by using a password of something like ' admin="true" password="'. This isn't something that an automated scanner will ever uncover; this list, which is awesome, is a good starting point, but not the ending point.
None whatsoever - I was generalising. Incidentally, I should point out that whilst I have a fair idea of the plan of attack: I would be bloody useless at actually carrying it out 8)
I was using sqlmap once and was genuinely surprised how good UI it has. It automatically does so much guesswork and only asks highly important questions, but at the same time it never gets in the way. Also, it does few other things beside just SQL injection, and it surprisingly gave me shell access when I was not even looking for it.
Nice, just started reading and looking forward to it, but also I'm loving this blog setup, particulary how clean the "warning" sections are. Is it a custom setup?
There are plenty of companies offering that for a price - search for PCI DSS compliance checking.
For DIY, then start with Kali Linux - you get the whole suite of tools but be prepared to do some learning and it is non trivial, especially if you are unfamiliar with Unix. You do get a mostly working OpenVAS with the Greenbone webby frontend nearly out of the box, but it needs a bit of config https://www.kali.org/penetration-testing/openvas-vulnerabili... is a bit out of date. Even once you get it working, you have to be prepared to evaluate the output.
Also bear in mind that security means different things to different people and different systems. There is, and never can be, a magic security bullet.
People running these tools are so common that "automated reports" are routinely excluded from public bug bounty programs. The ratio of false findings to true findings is very high.
> The ratio of false findings to true findings is very high.
Had to deal with one of these canned reports a while back to satisfy some enterprise contract. Had a dozen or so JS "vulns" that were only applicable to a Node environment that were being reported for client-side use. We were not a Node shop. I couldn't believe we'd paid money for that garbage report.
It could be just me, but it looks like running that set of automated scanning tools could itself be automated. Press button, pentest done, report sent off. There must be more to the job, what else is involved?
Automated tools can only discover so much, because there are always edge cases that tools won't be able to analyze or exploit. Human creativity is a big part of penetration testing, whether it's web application assessments or other types of penetration testing, because tools have false positives, and can't come up with creative bypasses for security measures in the way a human can.
You can definitely automate many parts of testing, especially enumeration steps, but any security professional knows that a tool is no substitute for a knowledgeable hacker.
