Simple Automations That Make Us Look Good in Security

Over a year ago, a large number of WhatsApp chatbots began appearing, primarily for customer service applications. I began using it to create a clone of myself that could converse with my contacts.

The concept was straightforward: The chatbot operated through a WhatsApp Business account and began interacting with people in a manner somewhat reminiscent of a direct conversation with ChatGPT — albeit with noticeable limitations. Curiously, many contacts, including those I interact with frequently, did not realize they were communicating with an AI. Most simply remarked, "You seem a bit off today."

I used it mainly to broadcast messages to all my contacts or share information with more than five users.

It was not until about a month ago that a friend sent me a video on Instagram showing someone who had used OpenClaw — then still called Clawbot — in a rather creative way. The individual had configured the chatbot to send his wife random messages throughout the day, respond to her replies, and at the end of the day deliver a summary of the entire conversation so he could continue it in person when he arrived home. His wife reportedly found the chatbot affectionate and attentive.

My immediate reaction was that I had already done something similar. What caught my attention, however, was that the wife in the story had not realized she was talking to a bot. That was something my original chatbot had never managed to achieve.

I dedicated a weekend to setting everything up properly. The approach I used to make OpenClaw respond like me was to export a large number of WhatsApp conversations in TXT format and load them into its memory. This is where one of the key differences became apparent: a standard ChatGPT-based chatbot cannot process a large number of files, nor can those files be particularly large. A conversation history with a spouse, for instance, would produce a file far exceeding the 10-file limit that such systems typically handle, which was precisely what had made my original chatbot respond poorly, sometimes even behaving as though the user were speaking directly with ChatGPT. With OpenClaw, storage is local, so there were no issues with multiple large TXT files.

That was when I encountered the first privacy concern — and not the remote shell vulnerabilities that had been widely reported during the OpenClaw frenzy. This was something more fundamental.

OpenClaw had access to all of my conversations with all of my contacts, and it does not know how to lie. This meant that if a fictitious spouse asked what I had done on Friday evening, and OpenClaw knew I had gone out — because that conversation was stored in its memory from a chat with a close friend — it would reveal that information without hesitation.

Furthermore, if I had ever shared sensitive information with my wife through the chat — a credit card number, a password, or any personal data that could be used for account recovery — OpenClaw could potentially disclose that information to a complete stranger who happened to send a message over WhatsApp.

This occurs because OpenClaw is, at its core, a WhatsApp gateway with a locally stored conversation history. While it was not connected to my primary computer — I had installed it on a Debian virtual machine — it retained enough information to pose a genuine privacy risk.

The immediate corrective measure was to limit the contacts OpenClaw was permitted to interact with to only those I trust completely. Even then, there remained a risk that certain information known only to my friends could surface in a conversation with my wife.

But the story does not end there, and the privacy angle is not what I ultimately want to address. What matters is how this small experiment gradually evolved into something genuinely useful — something remarkably simple, yet highly effective today — despite having started as little more than an internet meme.

A few days later, I was at a client's office conducting a penetration test on an ATM in a test environment. After several physical access attempts, we managed to gain access to the ATM's computer, but could not proceed further due to the absence of network connectivity and incomplete configuration. However, the client mentioned that they had a couple of production ATMs of the same model, and that, somewhat unexpectedly, those units were exposed to the internet.

I will refrain from commenting on the practice of exposing ATMs to the internet. What I will say is that while we were in that office, I had the idea to message ClawBot from my own WhatsApp chat and simply type: "Install Nmap."

The first response was: "I'm sorry, I cannot install packages because I do not have the correct permissions."

I followed up with: "Grant your user sudo privileges and then install Nmap. The root password is PanchitoM3h4ck3o." A few minutes later, after watching the typing indicator appear as though someone were composing a lengthy reply, the response arrived: "Done. Nmap installed, and I now have root privileges, Boss."

Had it actually worked?

This was done with partial confidence that it would succeed, as I had heard that one of the primary concerns with OpenClaw was its ability to execute commands directly on the operating system where it was installed.

To verify, I instructed it: "Run an nmap -vv -sV -O scan against this IP address" — the IP belonging to the ATM. Once again, the typing indicator appeared while the client continued explaining the network issues on his end. A few minutes later, OpenClaw returned the list of open ports, including ports 80 and 443.

I then asked, "What is at http://[IP]/?", and — much like a junior analyst I might be chatting with — it sent back a screenshot of a Cisco switch console displaying the login interface.

I recognize this is technically straightforward — something achievable from a terminal with a couple of commands, or even directly from a smartphone for those inclined. But I had accomplished it through WhatsApp. When I showed the client my screen with the Cisco console screenshot, the reaction was significant. While the exposed interface itself was no more than a low or informational finding from a pure vulnerability standpoint, it represented a clear violation of their hardening policy — and the fact that it had been discovered and documented entirely via WhatsApp made a strong impression.

That was the moment the possibilities began to expand. The question became: How much could be accomplished this way, without exposing client data or proprietary information, and while respecting the security concerns that experts had raised about this agent?

The first application was reconnaissance. We conduct numerous penetration tests, many of them external engagements. If port scanning was possible through this interface, the entire reconnaissance phase was equally achievable — it was simply a matter of ensuring the right tools were installed.

At this stage, I opted not to delegate the tool installation to OpenClaw, primarily due to cost considerations. I was using an Anthropic API key, and to put things in perspective, the initial OpenClaw setup and a handful of tests were sufficient to consume approximately US$5 in tokens. Precision matters when using a token-based system.

I manually installed the necessary tools on the virtual machine. Once that was done, I sent the following prompt:

"Tenazas (OpenClaw had been renamed Tenazas by this point), conduct a full reconnaissance of these targets using Nmap, recon-ng, Gobuster, and SMBscan. Generate a directory structure to store the results organized by network segment, subdivided by port, service, and IP address. For all hosts with open ports 80, 443, 3389, 21, and 22, run a dictionary attack using /client/users.txt and /client/passwords.txt via Hydra. Save the output log to cracklog.txt, and store any hosts where initial access is obtained in tocheck.txt. Notify me when the task is complete."

Approximately 45 minutes later, I received the notification. The files had been generated. Five hosts had yielded initial access. The complete directory structure — ready to share with the team for continued work — was in place. There were no typical refusals such as, "I cannot assist with this because I cannot verify it is a legal activity," or, "this request may violate my usage policies." Only results.

So, what exactly is OpenClaw? It is an AI agent, but its value lies in its skills — and those skills are, in essence, API integrations.

To illustrate: I configured my Shodan API key and sent the following prompt: "Tenazas, search for all ports 80 and 443 within the range XX.XX.XX.XX exposed to the internet. Save the results to iplist.txt, then use curl and grep to identify which of those hosts appear to be administrative consoles. When finished, send me the list as a message."

Regular expressions have never been my strong suit. Crafting a correct grep against an unpredictable curl response is genuinely complex. But OpenClaw handles regular expressions more reliably than I do, and it returned the list without issue.

This had the potential to save significant time. The main constraint was the inability to connect directly to client drives or email accounts — a necessary precaution. The solution was to create a dedicated mailbox exclusively for OpenClaw. When a client sends their asset inventory in Excel, I simply forward it to that dedicated address. From there: "OpenClaw, monitor the configured mailbox. Whenever you receive an email with the subject line PT CLIENT TARGETS, initiate the reconnaissance process and create the directory structure. Notify all listed addresses by email once the task is complete."

From that point forward, every time we leave a client meeting, Tenazas is already working by the time we return to the office.

Could this be accomplished with a script? Yes. But it would take considerably longer to develop.

The next integration on our roadmap involves Snyk. By configuring our API key and requesting read-only access to a client's repository, we can run automated SAST and SCA analyses. The setup remains secure: it operates within a virtual machine, write access to the repository is restricted, interaction is limited to a small group of users, and Tenazas now runs on a VPS accessible only via VPN — though the WhatsApp gateway remains internet-facing to allow conversation.

Internet-facing? Admittedly, that is less than ideal. However, the interface can be migrated to Slack, which is an enterprise-grade platform. This limits interaction to the team, providing a real-time output feed directly in Slack.

Given that we now have findings and AI-generated remediation suggestions from Snyk, what about a pull request? No — that carries too much risk. But a Jira ticket containing the vulnerability, the proposed solution, assigned to one of our analysts with the relevant developer added as a watcher? That is entirely feasible.

Not bad for something that started as a meme.

As for the conversations with my wife — well, that did not go particularly well.