As mentioned in my previous blogpost the first few posts  I’ll be following the 5-step methodology. Each step has its own clearly defined boundries, and even though people might argue that it’s old and outdated (because attacks nowadays aren’t as streamlined), it might prove to be good learning experience following it until I can stand on my own legs.

Follows are the five phases and a quick overview of what each phase covers:

  1. Reconnaissance
  2. This phase can be either (or both) passive and active; meaning that you should escalate it according to your needs. It also doesn’t need to be digital reconnaissance, but could be anything from you reading up about the target’s resources* online (on Google, LinkedIn etc) to you actively approaching its resources.
    The distinction between phase one and two are quite vague (especially when it comes to active reconnaisasance); both cover the attacker trying to find weaknesses in the target system, usually through probing the network.

  3. Scanning
  4. As mentioned in the last paragraph of the previous phase the line can be quite blurred between these two stages. Scanning could, however, be considered a more aggressive ‘active reconnaisasance’; where the active reconnaissance could potentially raise flags in the target system, this is phase is more likely to raise the same (or escalated flags) in the system.
    In this phase you are actively trying to map the system to understand what vulnerabilities might exist; what ports are opened, what services are running on those ports and are those services updated (ie. are they vulnerable?).
    As an attacker you want to focus on depth-first rather than breadth-first, if you find a potential vulnerability you should exhaust all your potential exploits before going on to the next.
    We are basically probing anything that we can reach (commonly referred to as the attack-surface) with whatever means we might have at our disposal.

  5. Gaining Access
  6. This is where you will attempt to exploit the vulnerabilties you have uncovered in in the previous stage. It could be anything from finding a vulnerable service running on a port to manipulating other resources (people, webapplications etc).
    You might attempt to deploy a metasploitable exploit or try to gain access to a server through SQLInjection.
    Remember to use the appropriate actions for the test you are attempting; feel free to do what you want in your lab environment, but please don’t drop a client’s tables if you gain access to their MySQL database(s)…

  7. Maintaining Access
  8. I’m personally quite iffy on the following two phases, but I’ll try to give a brief overview of them.
    Maintaining access is different from case to case, depending on yours and the target’s systems. If you are on a Linux-box you might find it appropriate to put a SSH-key on the attacked system so that you easily can access it from whever you have deployed your SSH-key to. Or if you are attacking a Windows-system you might find it appropriate to inser a registry key that starts your payload at startup.

    Basically it’s important to remember that this is all about ‘persistance’; you want as persistant access to the system as possible. (tip: search google for ‘persistance’ in penetration tests).

  9. Covering your tracks
  10. The title is quite self-explanatory, but it’s important to realize that basically everything that you do with the target system will be put in some sort of a log. You are basically leaving a digital foot-/finger-print behind you. So it’s important to realize that a lot of this phase actually occurs before the test even initiates; you might want to change your NIC’s (Network Interface Controller) MAC-address, use proxies and other ways of pre-emptively changing how the target percieves you.

    The second part of covering your tracks is to actively try to hide any evidence that the system has been tampered with by anyone, that way limiting the risk of the response team finding you, your backdoor or your exploits. This could be done by tampering with accesslogs, error-log, changing the command-history or clearing the event-log.
    Some of these might be more relevant on Windows and some might be more relevant on Linux.

Hopefully this brief overview might help you have given you an idea of how to perform your attack or at least how to plan it before performing it.

If I learnt anything from software development it is that the more time spent planning something, the less time you will be spending picking up the pieces when you eventually fail.

* with resources I mean anything that a target might consider resources. If your target is a company you might consider people resources, or the target’s devices and network.