• D

    That is a great question, Penny!

    There are a variety of skills that will help you be a successful Bug Hunter. Let's start with web skills.

    You need to have a pretty good understanding of what's happening behind the scenes when a web request is made. This includes things like

    • POST/GET Requests
    • HTML in general
    • Cookies/Tokens/Sessions familiarity
    • URL attributes/construction/encoding
    • Authentication mechanisms
    • Javascript (basic understanding)
    • PHP (basic understanding)
    • XML (basic understanding)
    • REST/SOAP familiarity can be helpful
    • Familiarity with common web services like
      • Apache/NGINX/IIS

    Once you understand the web systems, you can better exploit them. There are common exploits that you'll need to be familiar with such as...

    • Open Redirects
    • Sub-Domain Takeover
    • HTTP Parameter Pollution
    • Cross-Site Scripting (XSS)
    • Cross-Site Request Forgery (CSRF)
    • Injection Attacks
      • SQL Injection
      • Code Injection
        • HTML/PHP/Python/etc.
    • XML External Entities
    • Insecure Direct Object References (IDOR)
    • OAuth
    • Remote Code Execution (RCE)
    • Server Side Request Forgery (SSRF)

    This list goes on and on, but these are the vulnerabilites you're going to be looking for when hunting for bugs in a web application.

    I've alluded to this already, but getting some programming experience will be SUPER helpful. Web apps are built with languages like PHP, Python, RUST, Go, Haskell, HTML, Javascript, and others, so getting the basics of some web languages will allow you to use them to your advantage when you find them powering your target.

    You'll also need to get more than familiar with the tools of the trade. These include, but are not limited to...

    • Burp Suite
    • Sublist3r
    • Masscan
    • Recon-ng
    • theHarvester
    • SQLmap
    • SQLninja
    • Nikto
    • Dirb/Gobuster
    • WPScan
    • Joomscan
    • Droope
    • w3af
    • Netsparker
    • Arachni

    There are other skills you don't typically hear about or think about when it comes to being a bug hunter. These are skills like Enumeration and Report Writing.

    You need to be good at systematically clicking every link, reading every page's source code, looking at every web request in BurpSuite, and finding every shred of information about your target. Remember, Google is your friend and so is Shodan and duckduckgo.

    When you find a bug, you'll need to report it. This can be done directly or if you've got an account with Hackerone and/or Bugcrowd, you submit through their official channels. These reports need to follow a specific format and have specific information in them. Both Hackerone and Bugcrowd have excellent resources to explain how to write up good reports that will be accepted by their clients, so read them like 10 times. Spelling and grammar mistakes are frowned upon, so triple check for errors. Make sure that you're submitting something in-scope of the bug bounty program otherwise it will be rejected. Be prepared for the fact that you might not be first to report a bug and have your bug not pay out because it's a duplicate submission.

    Speaking of great resources, many of the tools, techniques, and technologies listed here are covered in our course library. Pentest+ and/or CEH should have much of these and I've taken great care to SHOW you them and not just tell you they exist.

    Hackerone has a FREE Bug Bounty CTF that you can actually earn your way toward invites to private bug bounty programs.

    Other learning resources that will give you some "hands-on" experience and practice...

    Well, I know that was a lot for a short question, but hopefully you've found this helpful and informative. There is so much more to this as you go down the rabbit hole, but this should be good to get you started.

    Daniel Lowrie

    posted in General Discussion read more
  • D

    Off the top of my head, I can't remember if I had any specific logging turned on other than defaults, or if the default auditing would catch anything that would leave a trail of breadcrumbs back to the attacking machine. Not every system you encounter will be logging the same way. I assume, YES.

    Assume that every box you're testing is logging. And that can easily be checked by spinning up a lab and performing the steps, then check the logs. Not only will you know for sure, but you'll have the experience which reinforces the knowledge. Don't forget to document the steps you took, any roadblocks you encountered and how you overcame them, and your results. Be DETAILED! There will be things you'll forget, so having it documented can be a real life/time saver when you attempt similar activities in the future.

    The best way to really learn this stuff is to do it! What seems like an easy thing on paper can prove to be a bear in reality. So fire up some VMs and spend some time Red Teaming, then throw on your Blue Team hat and see what's up.

    I hope this helps.

    Daniel Lowrie

    posted in CompTIA read more
  • D

    Hey, Reginal.

    If you go to the Overview video there will be an "Episode Files" link over the top right corner of the video area. That should get you what you're looking for.

    posted in Security read more
  • D

    Congrats, Julian! I'm glad we could be a part of your success and thanks for the kind words :)

    posted in CompTIA read more
  • D

    Typical turnaround time for an episode to hit the course library is usually just a few days. There are a few things that can make the time it takes to vary a bit, but that's the average.

    The CEHv10 series has just begun filming, so the first few episodes will probably be in the course library next week barring any hindrance.

    posted in Security read more
  • D

    Fear not, Brian! :D
    The course is only about half complete. We are recording new episodes and adding them as they get edited. It should be complete within the next couple of weeks (there is A LOT of material to cover and I want to be as thorough as possible). So keep an eye out for more episodes as they're added and thanks for your question.

    Daniel Lowrie

    posted in CompTIA read more
  • D

    Hey Penny,
    Sorry that you're having a bit of trouble with your nmap scan. Let's see if we can't figure out the problem.

    Let's start by verifying your IP information.
    From your Command Prompt type ipconfig and press <enter>
    Look for...

    IPv4 Address. . . . . . . . . . . . : <your IP address here>

    If your IP address isn't 192.168.219.something then this could be why your scan isn't working. But not to worry.
    Once you have your IP address information, try running...

    C:\>nmap -sT <your IP address here>

    This should return some results. Then you should also be able to scan live hosts on your network giving nmap a range of hosts (like, or just scan the whole network using CIDR notation (like

    I hope this helps you and let me know if it does. If it doesn't, let me know that too and we'll continue troubleshooting.


    posted in Security read more
  • D

    From what we've been give from CompTIA, you are spot-on as to where this exam sits between CASP and Sec+. It looks like the exam objectives are available so you can self-study those, but as far as "Official" study-guides or courses, those will be forthcoming as they take time to create and the exam is so new. We will be creating that content here in the near future, so be on the look out for that. Until then we have Pentesting content that will help supplement your self-study.

    Other penetration testing certifications will almost certainly have overlap as well, so looking at their material could help as well.

    Hope that helps,


    posted in CompTIA read more
  • D

    @christopher-zaloba This is a tricky question to answer because there are so many variables to consider. Also there is a lot of "plausible deniability" that would come into play.
    That being said, this is really the type of question that you would have to ask a lawyer to get actual, legal verification on.

    posted in Security read more
  • D

    You should be good to go by just putting double-quotes (" ") around your path like so...

    if [ -e "/usr/local/custom/path/filename" ] ; then...

    I hope that gets the job done for you.

    posted in General Discussion read more