Forum Replies Created

Viewing 14 reply threads
  • Author
    • #53862

      You should get the SecurityTube Python course (or Pentest Academy subscription) and go through that. You make actual tools, and Vivek provides additional ideas for features to add, as well as stand-alone challenges/exercises where you have to create your own tool from scratch.

      You can always start by automating tedious day-to-day tasks. It might just be sorting or organizing information, but you’ll build your skills while becoming more efficient at your job.

      If you have any interest in working on an open source MSSP platform, I know the Custodiet guys were looking for additional people. I’m not sure if its fully public yet, but I can put you in touch if you’re interested in that.

    • #53906

      Like impelse said, just bridge GNS3 to an interface on your system, which can be a virtual interface: http://www.gns3.net/documentation/gns3/connecting-gns3-to-real-networks/

      All you need to do is dual-home your pfSense VM and connect one interface to the GNS3 network and the other to your internal virtual network with all your servers, desktops, etc.

    • #53897

      @lexuscan wrote:

      How do testers ensure that they are not missing things out or retesting what has already been tested?

      I think you would have to be *really* disorganized to start retesting things you’ve already done. It’s also very rare for you to be given time to inspect every service on every system. Things are going to be missed unless you have an extremely tiny scope or have been given a ridiculous amount of time. A better question is how to be the most efficient, so you can make the best use of your time.

      @lexuscan wrote:

      how much preparation is required before starting the actual testing? Do testers sit for a few minutes before and go: “right, there are 20 pages and 100 input fields. What I am going to tackle first?”, or something like “okay, I have a list of 21 attacking vectors I want to test against; I’ll start with A, B and then move to C”, or is it more like “meh, there are something like 21 attacking vectors, I’ll start with the ones that come to mind first and then will take note as I go along”?

      Recon / info gathering is part of the test, which you start immediately. Are you asking about exploitation? i.e. how much do you learn before you move forward?

      I think a lot of the answers to these questions are going to vary based on personal experience and intuition. I typically follow a path as soon as I discover it and pick up where I left off if it doesn’t pan out. Additionally, you can have scans, etc. running in the background while you’re manually looking at something. It’s a huge waste to do something like wait for a large scan to finish before you start diving into it yourself.

      It’s going to vary based on the engagement as well. Maybe you’re doing an external engagement and know you’ll be encountering a lot of web servers. Do a quick scan across the ranges for only 80 and 443, then do a larger scan that includes thousands of ports, all the fancy script checks, etc. while you’re manually reviewing the websites.

      It’d be rare for your system to legitimately need to be sitting idle a majority of the time. You can also start with a scan of 21, 22, and 23, and have hydra or something doing password guessing while you’re onto something else. You may come back to valid credentials when you’re done with whatever else you were working on.

      I typically spend the majority of my time on post-exploitation activities, so the sooner I can establish a foothold and start digging deeper, the better. These aren’t vulnerability assessments, and it’s not my job to comprehensively identify and verify vulnerabilities across the network. I strive for as much breadth as time allows, but I’m really there to demonstrate the overall impact of their security deficiencies. That might be gaining access to sensitive information, obtaining domain admin privileges, etc. I’m not going to set the main objective aside just to validate a large number of miscellaneous vulnerabilities that have little-to-no-chance of leading anywhere substantial.

      @lexuscan wrote:

      Also, during a pentest, what does the tester do to keep track what has been tested, what needs tested, evidence gathering and correlation. How do they tackle all the ideas and keep them organized? Do they use just a One Note and paste everything in there.

      Again, this is going to vary a lot just based on personal preferences. I’d just try different things until you find what works for you. A guy I really respect is an absolute ninja with Emacs’ Org Mode and probably the most organized person I’ve ever seen.

      I typically paste windowed screenshots directly into the Word document, possibly pasting into GIMP first to do any obfuscation or other edits. I’ll just save them off separately if I know they’re only for evidence and won’t be reported on. I do the same thing for text output. I get what I think will be relevant for the report into Word and leave full text files in my evidence archive.

      I try to get as much into the report as I go though. It’s really tedious to try to sort back through everything after the end of the engagement. What’s easier, going through 300 pages of MSF logs to find the few lines you want to show, or just copy/pasting the text while it’s in front of you?

      Try to save as much as you can as a fail-safe in case you miss something. For example, you can use the script command in terminal, log within screen, MSF’s spool command, and so on. PCAPs are handy since you can retrieve an enormous amount of information from them (and having them is a good CYA policy in case you get blamed for something you didn’t do).

      Experience helps here too. After writing a large number of reports, you have a pretty good idea what you want to keep and what you should just keep in the evidence archive in case anyone questions your findings at a later date. You also find your groove and write scripts and little tools to help you sort and organize your information. For example, I wrote a short script that’ll create greppable Nessus output from the Nessus XML files (like NMap’s gnmap files). I might decide to focus on a certain group of vulnerabilities, then grep -v them from my working file, and repeat until the working file is empty.

      I know people that work exclusively with text files, general note-taking software Evernote/One Note, and specialized pentesting apps (Dradis, Lair). I personally use text files and Word. If it’s a team engagement, I’ll just throw up a new MediaWiki install. Spend some time experimenting with the various options that are available and see what works for you.

    • #53860

      There’s no reason you need to make a choice after two years, and even if you choose to go strictly offensive or defensive, there’s no reason you can’t go in a different direction later. Hell, I’ve done defensive > offensive > Microsoft Excel Specialist (management) > offensive.

      Keep learning and growing and you’ll be fine. Try to focus more on core concepts than specific technologies that may not exist or totally change within a couple of years. Programming and networking knowledge will be beneficial no matter which route you go. Just don’t allow yourself to stagnate, which is truly how you’ll kill your career.

      If you’re that torn, try to find something that allows you to do both. Perhaps a consulting position that has you doing implementation when there isn’t pentest work available. Also, incident response requires strong knowledge of both.

    • #53870

      Start working on absolute foundation topics. Learn Wireshark and tcpdump inside-and-out.

      Go through the assembly and exploitation tutorials on Corelan, SecurityTube, Open Security Training, The Gray Corner, etc.

      There are a ton of free resources available, and if you’re just starting out, you could easily spend 6-12 months on those resources. Don’t just learn how to run Metasploit (but if you want to ignore my advice and skip ahead, OffSec even has a free and comprehensive Metasploit course).

      Mastering this topics at the start will make everything else easier later, and that’ll allow you to keep moving forward while you save for later courses.

    • #53899

      If you’re serious about this, setup a lab environment and attack yourself. Observe what you can find on the network level for various types of attacks.

      The following course and book topics should provide you with a good starting place for brainstorming thesis topics.

    • #53890

      Just apply and get approved as a mentor if you’re interested in it. You’re not under any obligation to do anything after that.

      I believe you need a minimum of four people, and you’re responsible for spreading the word, obtaining a space for the weekly meetings, etc. It can be difficult to get going from a logistical perspective.

      The money itself isn’t worth the trouble IMHO. It’s something extra, but you really do need to be interested in it from a community perspective, like you stated you are.

      You also need a stable schedule because you have to commit to weekly sessions (one book per week), which makes it pretty much impossible for anyone who has a traveling position.

      Do you have any other specific questions or concerns? I’m not really sure what you want to know.

    • #51851

      If you guys want to post general topics you’re struggling with, we can try to provide additional resources.

      Also, feel free to PM me if you’re concerned about spoiling anything by posting publicly (though you won’t get any spoilers in return ;))

    • #53842

      With the videos, just be sure to download them and back them up within the timeframe they give you. They watermark all the videos with your contact information, and there’s an additional cost to have them recreate them for you if you lose them later.

      You can use MSF once, but there are some systems they explicitly prohibit you from using it. This will all be detailed in your exam pack.

      And kitrap0d has been removed from getsystem. It used to be a fourth option, but now there are only these three:

      meterpreter > getsystem -h
      Usage: getsystem [options]

      Attempt to elevate your privilege to that of local system.


      -h Help Banner.
      -t The technique to use. (Default to '0').
      0 : All techniques available
      1 : Service - Named Pipe Impersonation (In Memory/Admin)
      2 : Service - Named Pipe Impersonation (Dropper/Admin)
      3 : Service - Token Duplication (In Memory/Admin)
    • #53827

      While it’s cool that you’re digging into the bytes, you’ll probably find Scapy to be much more useful for what you’re trying to do: http://www.secdev.org/projects/scapy/

      @bahr wrote:

      IHL field of IPv4 Header

      version = version_ihl >> 4

      As I am able to understand, the following line takes the binary representation of the version_ihl variable and shifts it 4 bits to the right, corresponding to dividing version_ihl with by 2^4, is that correct? And if so, why are we doing this?

      Not really. Bit shifting left/right will multiple/divide by two for integers (and this can get tricky if you’re dealing with signed integers).

      However, you’re not dealing with an integer value, but rather two nibbles (four bits), which make up the first byte of the IP header. The first nibble is the IP Version, and the next is the IP Header Length.

      69 is a common integer value for this field, so we’ll start with that (I’m using the interactive Python shell, and format() is simply used to show eight binary digits that are zero-padded):

      >>> x=69
      >>> format(x, '08b')
      >>> y=x>>4
      >>> format(y, '08b')

      So what this effectively does is move the IP Version value (0100) into the IP Header Length field and discards the IP Header Length value (0101). The bits that are shifted in (from the left) are zeros, which makes the new value 00000100. Also, this value is assigned to the variable, so the original value isn’t actually modified.

      You can see we still have the original value, which is the first byte we pulled from the header, and the new variable has a value of four, which is indeed the IP Version of the packet:

      >>> x
      >>> y

      @bahr wrote:

      and here as I understand it, we take 0xF (15 in hex) and do a logical AND of the binary representation of 15 with the binary representation of what is in versino_ihl. I don’t understand this part at all really :-[

      ihl = version_ihl & 0xF

      To get the header length, the first nibble must be converted to zeros. This can be done by ANDing the original byte with 00001111 (0xf). The following code section shows the original byte’s value and the binary representation of 0xf.

      >>> format(x, '08b')
      >>> format(0xf, '08b')

      As expected, ANDing these two values removes the value of the IP Version and gives us the value of the IP Header Length (5).

      >>> z = x&0xf
      >>> format(z, '08b')
      >>> z

      The value of the IP Header Length represents the number of words (32 bits/4 bytes) that make up the IP Header, so multiplying this number by four will give us the actual number of bytes (5*4=20, which is the standard size if options are not specified).
      @bahr wrote:

      TCP Header Unpacking

      So the example unpacks the TCP header by the following format string:

       tcph = unpack('!HHLLBBHHH' , tcp_header)

      and then when referring to the tcp header documentation on wikipedia I see that the data offset header field is 4 bit in size, so according to my understanding that must correspond to the first ‘B’ in the “!HHLLBBHHH” format string.

      So what I get out of this is that:

      – We unpack source and destination port into an unsigned short type in python, corresponding to the first 2 HH

      @bahr wrote:

      – We unpack sequence number into a an unsigned long type in python, and the same for acknowledgement number

      @bahr wrote:

      – Then we come to the 4 bit Data Offset header, which seems to be unpacked into a 1 byte sized integer python type by using the B format specifier, that corresponds to a unsigned char C type?

      Not exactly. There’s eight bits in a byte, so again, you’re getting the first nibble, which is the Offset, along with the next nibble, which is Reserved. Also, chars are the same as one-byte integers: https://docs.python.org/2/library/struct.html#format-characters
      @bahr wrote:

      This is where I get lost again completely :-[ According to the TCP header documentation, the data offset is only 4 bits in size. Why and how do I know I should unpack this into a python integer type that is 1 byte of size?

      It’s very difficult to work with memory that isn’t a multiple of one-byte. In Python, one byte is the smallest value you can unpack.
      @bahr wrote:

      Also don’t I then waste 4 bits of unused space, as the header field is only 4 bits in size, but I’m storing it in a datatype that is 1 byte of size?

      The waste is negligible, and as I said earlier, you can’t really work with values that aren’t multiples of one-byte.
      @bahr wrote:

      And why exactly do we use the B format string which is corresponding to a unsigned char C type, to unpack the data offset field? How do I know that I should use this format string instead of lets say the c or b format string specifiers?

      Because you want a positive integer. The c format is a one-byte string in python, not an integer, and b will give you values -128 to 127, and you’re never going to have a negative Offset.

      b would hypothetically work as long as you never have a value greater than 127. However, remember that the value you want is only the first nibble. Therefore, the value may only be 15 (1111), but as the first nibble, this was make the value of the byte you’ve retrieved 11110000 (assuming the Reserved bits are all zeros). This value is 240, which is obviously greater than 127, and it would cause your code to return invalid values, as shown below:

      >>> 0b11110000
      >>> hex(0b11110000)
      >>> struct.unpack('b', 'xf0')
      >>> struct.unpack('B', 'xf0')
      >>> struct.unpack('c', 'xf0')

      @bahr wrote:

      Then this is followed later by the following piece of code:

      doff_reserved = tcph[4]
      tcph_length = doff_reserved >> 4

      Why do we again do a bitwise shift 4 times to the right here? What is the purpose of this?

      This is the same thing we saw earlier. I’ll use 80, which is a common value for this field:

      >>> x = 80
      >>> format(x, '08b')
      >>> y = x>>4
      >>> format(y, '08b')
      >>> y

      After the shift, we get 5, which is the actual value (and much more realistic than 80)

    • #53830

      These will give you a general idea of the overall penetration testing process:

      In terms of the web application, OWASP has a section for code review, along with a ton of other resources for attacks, safeguards, tools, etc.:

    • #53815

      It’s unlikely that activity would get noticed unless they’re actively working with the logs at the time, but more mature environment/more advanced controls may detect repeated 404s and blacklist the source IP or do things like intercept and respond to all requests with 200 messages.

      In general, you really have these options:

      1. Simply tune the tools to go so slow you avoid detection
      2. Do recon/run noisy tools from alternate locations (a pool of VPSes, through TOR, etc)
      3. Generate so much fake noise that your legitimate requests get lost in all that (i.e. make a few dozen/hundred requests with a spoofed source IP for each legitimate request)
      4. Perform attacks manually that aren’t flagged by signature or heuristic systems.

      The latter often works a lot better for specific, targeted attacks than noisy scanning/enumeration attacks. Maybe you can fragment packets in such a manner that avoids IDS detection, but when they’re reassembled into an HTTP GET request, the web server is still going to log the request. However, maybe you can find ways around that as well. For example, maybe the web server will disclose the existence of an item through a less common request (TRACE, DELETE, etc.) that the server isn’t configured to log.

    • #53819

      Congrats on the OSCP, that’s quite an accomplishment! Based on the subject alone, I initially thought this thread would be someone whining about the OSCP being too difficult, so I was pleasantly surprised when I actually read your post.

      If you haven’t already done so, write a penetration tester version of your resume. Highlight all the security responsibilities in the role(s) you’ve had, and emphasize everything that’s as close to penetration testing as you possibly can (network scanning, vulnerability analysis, patching, system hardening, password auditing, etc.). If you haven’t done those things, get permission to do them, and then do them. See if you can even get some exploitation approved, so you can also add internal penetration testing activities.

      The CEH is a multiple-choice marketing cert, so no, it’s not going to hold a candle to the OSCP. It may open some doors with HR or recruiters, and it will satisfy a DOD checkbox if you’re trying to go that route (but others can be used for that). Aside from potentially helping you get your foot in the door somewhere, it’s really not well-respected by technical professionals. It’s not going to hurt you, but you already have the one that matters to those people.

      What’s your official title? You first said you’ve been an IT professional for ~5 years, but your second post makes it sound like you’ve been in a support position that entire time. If so, that’s getting to be a long time in a support role, and the lack of advancement may be viewed negatively by some people.

      What other certifications do you have? Everything we do revolves around general IT, so certifications like the CCNA will definitely lend you more credibility. As great as the OSCP is, it doesn’t encompass everything. I’ve met OSCPs who haven’t been able to do basic network troubleshooting. A large component of penetration testing is explaining why the current configuration is vulnerable, how to remediate it, and what the potential repercussions of remediation may be. It’s unlikely that someone who lacks those core skills and knowledge would be able to do those tasks well.

      If you don’t have a blog, start one. Put your OSCP review and other things you learn/are working on there. That will demonstrate your knowledge and writing skills (writing reports is a big piece of the equation, so make sure the message you’re sending is that you’re a competent writer). Unrelated, but the same is true for the quality of your resume. If there are errors and your thoughts are jumbled on such an important document, one can only imagine what the quality of your reports would look like. I’m not implying that your resume is in poor shape; I’m just emphasizing the important of making sure it’s polished.

      What are you doing for networking (the kind that doesn’t involve bits and bytes)? Are there DC[Area Code], OWASP, ISSA, ISACA, etc. meetings in your area? BSides? Do you attend any larger conferences? DefCon will likely be overwhelming if you aren’t yet acclimated to cons, but if nothing else, you should definitely head out to DerbyCon later this year. That should be a relatively short trip for you too. Snag your ticket quickly though; it’s a smaller con that will sell out.

      Are you open to relocating and/or traveling? You’re not in a great area for InfoSec, or even IT in general, so being able to broaden your horizons will significantly increase your likelihood of success.

    • #53708

      @jjlipp56 wrote:

      Though I am virgin to penetration

      *Slow Clap* 8)

      You should start by reviewing the syllabus: http://www.offensive-security.com/documentation/penetration-testing-with-kali.pdf

      Let us know if you have questions about specific topics, and we can point you in the right direction for those.

      You really have two options:

      1. Thoroughly research each topic in advance and take the plunge when you feel you’re ready
      2. Dive in right away, knowing you’ll be way over your head, and then research each problem area as you encounter them (if you go this route, start with 30 days of lab time, then get another 60-90 when you’re ready to give it a serious shot)

      Don’t take this the wrong way, but having A+-level skills does very little to prepare you for this course (though I agree that doesn’t make you an idiot ;)). There are also significant gaps between the OSCP and other security certifications, ranging from Security+ to much more advanced ones (including those that focus on penetration testing). Having solid Linux, network analysis (Wireshark/TCPDump), scripting (Bash/Python), and other such skills is just the beginning.

      Honestly, I think you should just go for it and see what you think. If it piques your interest, study up and hit the labs hard again at a later date. You need a really broad set of skills to do well as a penetration tester, and you may decide that learning and maintaining all those skills is more work than it’s worth. I’ve invested decent chunks of money within other areas of IT as well as potential careers outside of IT, and I’ve found that while I ultimately “wasted” money on those endeavors, I also appreciated the peace-of-mind I obtained from knowing I genuinely explored that option and it ultimately wasn’t what I wanted to do.

      That was last piece was fairly off-topic, but I wanted to share since you seemed to have been on the fence for awhile. Penetration testing isn’t for everyone, and there’s nothing wrong with that. Regardless of what you ultimately decide to do, you’ll still learn a lot and get your money’s worth. Even if you decide to do defensive security work or continue working in a more general IT role, understanding offensive tools and techniques will help you defend against them better as well as assist you with making security-conscious decisions when configuring various technologies.

    • #53808

      I’m pretty sure I remember you from back on TE. Congrats on wrapping up all Cisco work, as well as the transition to the darker side 😉

      Keep us updated on your progress, and let us know if there’s anything we can help with.

Viewing 14 reply threads

Copyright ©2021 Caendra, Inc.

Contact Us

Thoughts, suggestions, issues? Send us an email, and we'll get back to you.


Sign in with Caendra

Forgot password?Sign up

Forgot your details?