Social Engineering in penetration tests: my point of view and my own custom tool

Social engineering techniques are frequently part of an overall security penetration test because also the “human network” need to be tested.

But, when security tests are made on human beings, is really important pay attention to etics.
Indeed, there are some social engineering moves that you simply can’t use at all if you want to stay within the lines of the law.

Now, social engineering attacks as part of penetration tests are risky, there’s no denying it.

Most penetration tests target systems, but social engineering attacks target people too often, the individuals who fall for a social engineering attack feel terrible: the “human error” is often the root cause of a security incident, but often peoples feels a social engineering attack as a personal failure.

So, in my opinion, social engineering must be used in certain situations, in order to check internal processes: in this cases, i prefer to call it “simluation”.

Obviously, this activity need to be bound by some principles:

  1. Social engineering simulations should not cause psychological distress to the subject
  2. Employees that fail the test should not be subject to public humiliation: the information can be presented as part of an education program without identifying the employee.
  3. A good postmortem/retrospective work on phishing attacks can find useful remediation work: enhancemed authentication systems to be less vulnerable to phishing (e.g. MFA),better logging/monitoring/alerting, etc.

MITMInjector, a basic tool for phishing simulations

The most used “simulation” is the phishing attack: a spear phishing attack with a good targeting may be really useful to check employee awareness.
In a good phishing simulation, the first step is the making of a good fake copy of the web app/login form targeted by the campaign.

So, in order to speed up this first step, i’ve realized a small python script, called MITMInjector [1].
This tool was initially born for debugging purposes on a closed source application developed by a retired vendor. During developmente process, I sensed also some additional capabilities, like the cloning of whole webpages, and I’ve turned the development in that direction.

MITMInjector is a simple Man-in-the-middle proxy that can serve only a single page (passed as commandline parameter), but with the capability of inject client code into that page.

The injected code is also able to return collected data to the backend using a specific entrypoint (/payload/).
Icing on the cake: support for ngrok tunnels and url shortening.

I’ve released a simple release with a restricted set of injection plugins (and a work-in-progress support for WebWorkers) on GitHub: currently, the most useful payload in phishing simulation is the “formgrabber”, that grabs contents of all forms (including login forms) of the page and sends them to the backend:

The tool comes also with a custom Dockerfile that allows the build of a container with a sample phishing page: it can be simply customized and deployed on a PaaS.
Further, the “” script is useful to automatize the deploy on Heroku PaaS, passing as argument the url to “clone” (it needs the heroku cli [2] client installed and configured):

$ ./


  2. The Heroku CLI | Heroku Dev Center

Related posts

  1. pySchö: algorithmic music composition
  2. Weekly Cybersecurity Roundup #1
  3. My Weekly RoundUp #132
  4. SpiderFoot 3.0: OSINT reconnaissance tool
  5. Facebook phishing attempt using image share notifications