The issue of client/user testing came up within my company today and wanted to know what you guys think. At the moment our senior Testers only appear to have come up with a solution to client/user testing which involves sending a malicious link to enumerated email addresses within the target company using CORE IMPACT.  Provided the malicious email generated by CORE manages to bypass the company's email filter, the organisations firewall allows outbound connections and the OS or any apps installed (Adobe acrobat, browser, etc) are vulnerable then a series of payloads could potentially be used to exploit... Now what would you class a legitimate test during a client/user pentest, browser exploits, malicious emails, is this something you guys already test?

What about teleworking or remote working? My company doesnt currently have any testing procedure for remote working and I believe that this is something that needs to be integrated into a pentest. The number of users that work on the road, from home etc is immense.  Shouldnt we be testing organisations VPN access, the clients being used to connect to the network via VPN (Are they locked down, patched etc). In one company I worked for a while a go, many remote workers had local admin access on their machines, accounts with passwords that do not expire (as they complained they were on the road and caused problems and got what they wanted), using a VPN solution that requires no certificate nor required to be a member of any remote access group. The VPN client was often configured with a default password that was stored in the cache.....

This leads me onto the topic of combined testing...So how should a pen test be performed? One of the issues that frustrates me is the fact that some security consultancies appear to allow one tester (junior or senior) to perform either an Internal or External Pen Test over a period of 3-5 days? Obviously it depends on the size of the scope of testing and whether it is a single web app or network test etc but isnt it always better to have more than one (two minds better than one and all that?) Also should a team of Pen Testers with different skillsets be allocated? So one whom may have good social engineering skills, one whom is strong with networking and OSs and one how is strong in web app testing (obviously depending on the scope) or do you throw one guy on a network and web app pentest for 3-5 days and hope he has success?

Sorry if this doesn't make sense or is a bit all over the place....

The core technique would be client-side exploitation. I'd write up the entire process as remote social engineering during an external penetration test. You can argue semantics all day though; just make sure it's clear what was done.


You need to be very careful with this and ensure that you're authorized to do this. Will you only be targetting company laptops or the users' own equipment? When you start doing things like friending them on Facebook, attacking their personal machines, etc., you can open yourself to serious legal problems.


This will totally depend on the customer/organization. A multi-pronged approach will most closely mimic real-world attacks. However, some organizations won't go for it. I've had people turn down social engineering because they know they'd fail and were scared of the results.

The period of time will also vary greatly. You have to remember that a very small percentage of organizations will have this type of work done simply to be proactive. A lot of those will likely be required to have this work done because of regulations. These organizations simply see this as a cost. In these circumstances, do you think you could convince them to use a team for two weeks over one person for 3-5 days? You'll obviously do better with multiple people (granted, there are diminishing returns and too many people will be detrimental). Someone might be better with wireless, databases, web apps, Windows, *nix, etc.


Patience padawan.


It depends on what filtering is in place. If they simply allow 80/443 outbound, yes. If they're doing app-level inspection and notice SSH is going over 443, it will probably be denied. They may also restrict what domains/IPs are allowed through.