7

I regularly perform pen-tests against web applications, operating systems, etc. Occasionally, I'm luck enough to do a 'red-teaming' exercise and get to attack at all conceivable points of a network (people etc as well) which is good fun and usually goes quite smoothly.

However, a client recently mentioned that they'd be interested in testing client-side (end-user) machines such as desktops/laptops as well, in order to see what type of attacks could be conducted against them, as a means of testing endpoint security (firewall/HIPS/AV/app whitelisting), and also to put their incident response program under stress.

They're looking at using custom malware to do this and are willing to let us try and propagate our own code in their environment.

Since most successful attacks these days involve client-side attacks (spear phishing, drive-by downloads, etc.) it makes sense to test the actual endpoints (which are usually a big problem). However, I'm worried that if we create a self-spreading piece of malware it will eventually get loose from the network, or that in one of the infinite possible application interactions, it will knock some server offline. Obviously the client will sign a waiver and shoulder risks like this.

Are client-side attack scenarios common requests? What other people do in these types of scenarios? Are there any methodologies to follow regarding the use of custom malware in client-side pentests?

|improve this question
  • "Are client side attack scenarios common requests?" Yes, very. "What other people do in these types of scenarios?" Attack the humans (phishing, weak passwords, etc.) then attack the client machines themselves. "Are there any methodologies to follow regarding this?" I don't usually hear about building a custom malware for this. It is done, but it's not common. A well-written custom pentesting malware won't attack key machines, it won't try to exploit machines outside the network range, it will always have a kill switch, and it will always self-destruct after a set period of time. – Adi Jun 4 '13 at 4:18
  • @Adnan yeah, the problem is writing such malware is a time-consuming task so it costs us money in the end which is bad. By attack the humans, i assume you mean social engineer them to give out passwords/install malware directly? – NULLZ Jun 4 '13 at 5:06
6

You don't need a self spreading malware in order to test the end user machines. For example, if you decide to target the end user machines browsers, applications (MS Office, PDFs, Java, Flash) or physical security of the machines, what you need is a custom exploit and a payload. The payload need not to be self spreading. You just need a type of payload that give you control over only the machine you have targeted.

Let us take an example. Suppose I want to target 10 user machines and I decided to target the their browsers. The first thing I would do is I would host the Metasploit exploits on my machine. The exploits needs to be customized in order to bypass AV and other types of defenses. I can use meterpreter as my payload. Then I would send these 10 users a link to my server which is hosting the exploit files. If out of these 10 users I managed to make 5 users connect to my Metasploit server and I successfully exploit their browsers and gain access to their machine, the meterpreter is going to give me access to only those five machines. It is not going to target every other machine in the subnet automatically. Off course if I want to pivot further from there, I can do it manually.

So in the end, I think what you need is a custom malware but that custom malware don't need to be self spreading. Make a malware that is only going to give you access to the particular machines you are targetting.

|improve this answer
  • I agree with the custom malware for sure, it needs to be able to bypass whatever AV solution they're using (usually McAfee etc), that's not the most difficult part of all this though i think – NULLZ Jun 4 '13 at 4:49
  • @D3C4FF Bypassing your shellcode from the AV is a matter of only a few seconds nowadays. It is most of the time automated as well. However, bypassing your exploit from the web AV module will require you to spend some time on the exploit code. If you are targetting Java, bypassing the AV in Java exploit is relatively more easier since you have unlimited choices of junk code between the library calls. – void_in Jun 4 '13 at 5:10
  • 2
    Having managed a fair number of targeted attacks like this I would have to agree - do not use any kind of self-replicating code! An attacker might, but as a professional, you will need to attack each link manually and pivot from each successful exploitation. – Rory Alsop♦ Jun 4 '13 at 6:38
  • @RoryAlsop Okay, so i'd simply be incorporating attacks that extend to client devices but rather than spreading, manually pivot through the network. – NULLZ Jun 4 '13 at 7:25
  • 1
    You might also add 'restrictions' to your malware 'just in case' (eg for example you share the code with someone else who wants to do similar). The restrictions should probably be both in time (eg first line of program could be return out of program if date is greater then x) and space (if machine not on this net or isn't in this list of hostname, then exit). It could be argued this is unnecessary but if nothing else it helps with peace of mind. If you do share the code it also helps make clear it's not for general use. – Duncan Jun 4 '13 at 13:21
0

We have done several client side attacks. While testing with malware is limited, we often have requests to test the security of restricted environments and assess the overal complexity of how to break out of these. I'm not aware of any common, open methodologies. Creativity is key when doing these types of assessments.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.