First off-- -sorry its been a while. Work and life has been crazy! We had the Diamond Jubilee a few weeks back, had family visiting, lotsa work obligations... blah blah blah :)
Anyways, I took part in one of my 'in-depth' first malware/external pens the other day. First off--- so nervewracking! I felt like it took forever (aka more than 1 second) for a meterpreter shell to come back to me, so immediately I thought everything was fail. This brings me to one of the biggest lessons I learned:
BE PATIENT
You are setting up a shell perhaps thousands of miles away, potentially on horrible connections-- so don't freak out if the command which took milliseconds in lab testing took a few seconds in the real world.
HAVE A PROCESS
Your first instinct will be to quickly run things as they come to you in case you lose a connection... This is not good either because you will probably end up forgetting what you did and doing things in a nonsensical way. You need to get in, get good data, and then use that data to get further in. Some things one should think about when creating their process:
DO NOT RELY ON SCRIPTS
This really holds true for most things computer related. If you are going to use a script-- fine, but be sure you know what it is doing and understand the risks of running it. Will running it trip AV for example? Or worse yet-- drop you connection? I wanted to run a lot of scripts (hey they worked in my lab!), however my coworker (who knows a thing or two about pen testing) said to be careful... scripting can be dangerous. If you have the time-- do it by hand. The best way of ensuring you are getting the results you expect is to run the commands yourself, so drop into a shell and let loose the command line kung fu :) Of course if you have multiple machines in a short time frame this viewpoint may be altered....
OK SO WE GOT YOU... AND HERE IS HOW TO FIX IT
When you are doing a pen test-- you have to remember who this is going to, a client. A client who --sure-- wants you to get into their network, but more importantly wants you to tell them how to make their network more secure. So don't just say, 'We got SYSTEM on your device', say 'We acheived it exploiting this vulnerability (yes metasploit tells you this) and this is how to mitigate this threat.' Believe me that is much more important to them.
SCREENSHOTS ARE YOUR FRIEND
Sometimes its hard to explain technical things-- screenshots can say it all. Saying 'we established an RDP session to the victim's machine' is nice, however, showing a screenshot of the RDP session? Priceless.
Like I said before, each individual has their own way of approaching this. I think it is finding the balance between a cool head and steady fingers at the keyboard :)
Anyways, I took part in one of my 'in-depth' first malware/external pens the other day. First off--- so nervewracking! I felt like it took forever (aka more than 1 second) for a meterpreter shell to come back to me, so immediately I thought everything was fail. This brings me to one of the biggest lessons I learned:
BE PATIENT
You are setting up a shell perhaps thousands of miles away, potentially on horrible connections-- so don't freak out if the command which took milliseconds in lab testing took a few seconds in the real world.
HAVE A PROCESS
Your first instinct will be to quickly run things as they come to you in case you lose a connection... This is not good either because you will probably end up forgetting what you did and doing things in a nonsensical way. You need to get in, get good data, and then use that data to get further in. Some things one should think about when creating their process:
- Are you system?
- Have you set up persistence? (in case you lose your primary connection you have a backup)
- Have you dumped hashes?
- Can you grab LSA secrets?
- Have you looked at network information?
- Have you checked the system info?
- Have you checked the IP configuration?
- Do you know if there are administrator accounts? How about domain accounts?
DO NOT RELY ON SCRIPTS
This really holds true for most things computer related. If you are going to use a script-- fine, but be sure you know what it is doing and understand the risks of running it. Will running it trip AV for example? Or worse yet-- drop you connection? I wanted to run a lot of scripts (hey they worked in my lab!), however my coworker (who knows a thing or two about pen testing) said to be careful... scripting can be dangerous. If you have the time-- do it by hand. The best way of ensuring you are getting the results you expect is to run the commands yourself, so drop into a shell and let loose the command line kung fu :) Of course if you have multiple machines in a short time frame this viewpoint may be altered....
OK SO WE GOT YOU... AND HERE IS HOW TO FIX IT
When you are doing a pen test-- you have to remember who this is going to, a client. A client who --sure-- wants you to get into their network, but more importantly wants you to tell them how to make their network more secure. So don't just say, 'We got SYSTEM on your device', say 'We acheived it exploiting this vulnerability (yes metasploit tells you this) and this is how to mitigate this threat.' Believe me that is much more important to them.
SCREENSHOTS ARE YOUR FRIEND
Sometimes its hard to explain technical things-- screenshots can say it all. Saying 'we established an RDP session to the victim's machine' is nice, however, showing a screenshot of the RDP session? Priceless.
Like I said before, each individual has their own way of approaching this. I think it is finding the balance between a cool head and steady fingers at the keyboard :)
No comments:
Post a Comment