Cybersecurity & AI: test and protect your websites and apps with the latest technology

Cyber attacks are raining on the world at the rythm of thousands a day, trying to get into websites, apps, government, banking and energy infrastructures, constantly.

The goal is to disrupt services, damage the economy, create a sense of instability, helplesness and uncertainty.

The aftermath is grim: theft of sensitive data, backdoors for future attacks, service interruption, brand reputation damage, loss of customers, trust & profit.

Developers, and hackers alike, can now use the immense power and knowledge of AI to automate attacks but also pro-active defense and mitigation planning, through tools that required intensive manual work and review, which can now be automated and turned into actionable risk management and security playbooks for any company.

Only test apps and servers that you have authorization for, as trying to break security of any app/website/server without permission could be prosecuted.

You will need:

• A Kali Linux installation (you can easily set it up on a Virtual Machine or on your Windows Linux Subsystem)
• Hexstrike (clone it into a WSL folder)
• As many VPS as you can get – This is optional as things will work even without it, but you will get yourself banned from the server where you’re performing your tests, if you use your own IP as attack source
• LLM studio (to use local AIs, at no cost, if your hardware can take it) or 5ire (to use cloud AIs, e.g. with your OpenAPI or Claude API keys at the cost of tokens used for each call)

Once you have fully installed Hexstrike and the 100+ tools it provides, you are ready to pentest in-depth.

But before we proceed with that step, we should create a System & User prompt template, that can be easily-reusable for different targets, and that will provide all the results and a full doc with actionable actions and summary of findings.

With the LLM GUI of your choice, you should be able to add a System prompt, as well as as your regular User Prompt, and some like 5ire, will even provide ahandy template variables you can create an use (e.g. {{target}}) .

Automating pentesting can be powerful, but if you do it from your own IP, you will get yourself banned halfway through the pentesting.

That’s why you add you start adding IP rotation: a second layer of operational hygiene so your scans don’t get throttled, banned, or blocked before they’ve even warmed up. When you run automated scans (Nmap batches, FFUF/Gobuster wordlists, sqlmap, Burp extensions, etc.), the target often reacts the same way any decent firewall or WAF does: “Hmm, someone is knocking too fast and too consistently from the same place… block!”

To avoid that, testers often add source IP diversity, which has two goals:

1. Spread requests enough to avoid rate-limits.

2. Give you clean channels so your tools can finish their enumeration instead of hitting a wall.

You can structure the setup like this:

1. Use a VPS chain (legit, stable, and cheap)

Think of it as building your own miniature scanner constellation.
You set up several tiny VPS instances (5€–10€/month types), each running a lightweight proxy or SSH tunnel.

This gives you:

• Predictable IPs

• Reliable throughput

• No shady proxy network

• Legal control over the source of traffic

You rotate through the nodes automatically in your scripts. Tools like ProxyChains can smoothly hop between them.

2. Use Tor for certain workflows, but carefully

Tor can technically rotate your exit nodes, and ProxyChains on Kali can send tools through Tor.

However, there are caveats:

• Many security tools absolutely choke over Tor due to speed and flags.

• Most targets block Tor exit nodes by default.

• Tor breaks many tools that expect stable TCP behavior.

• It’s not appropriate for high-volume testing.

Free? Yes. Practical for full pentesting? Not really.

3. Free public proxy lists — possible but useless for real pentesting

There are free rotating proxy lists, but they:

• Are mostly dead or unstable

• Get abused constantly and are always blocked

• Leak your traffic through unknown operators (terrible for confidential pentests)

• Break TLS, break scanning, break your life

These are the worst possible choice for a professional pentest.

If you have cloud credits (students, new accounts, promo codes), you can run multiple small nodes on:

• Oracle Free Tier

• Fly.io free tier

• Render free tier

• GitHub Codespaces (with tunnels)

• GCP/AWS/Azure trial credits

These can give you a chain of rotating IPs for zero cost if you’re smart with redeployment.

The safe and sensible way to automate

An example of clean, reproducible architecture

Kali / Hexstrike machine → ProxyChains → rotating VPS proxies → target

Each VPS is tiny (1 vCPU, 512–1024 MB RAM). Each one runs either:

• a simple SOCKS5 proxy via SSH ( ssh -D 1080 user@vps )

• or a small proxy daemon like 3proxy or tinyproxy

Traffic leaves through a different IP every time, you manage rotation with a simple script from Kali, not on the nodes.

[Kali]
|
|— proxychains → [VPS #1: 45.12.X.X]
|— proxychains → [VPS #2: 162.55.X.X]
|— proxychains → [VPS #3: 65.21.X.X]
|— proxychains → [VPS #4: 89.117.X.X]
|
Target Website/API/App

1. Create 3–6 small VPS nodes (or free tier nodes).

2. Install tinyproxy, 3proxy, or just use SSH dynamic forwarding ( ssh -D ).

3. On your Kali / Hexstrike automation machine:

   • Use proxychains-ng with a chained list:

     socks5 10.1.1.10 1080
socks5 10.1.1.11 1080
socks5 10.1.1.12 1080


   • Let your scanning scripts “round-robin” across them.

4. Add randomized delays into your scripts so your pattern isn’t robotic.

If you rotate IPs too aggressively, the target may interpret it as hostile behavior, not testing and always get explicit permission for multi-IP scans.