I have been running a one-person cybersecurity practice for years. Then I discovered what happens when you pair an LLM with the right infrastructure.

This is my setup.

What I am Running

Three machines in my homelab:

• Mac mini (basement): Runs OpenClaw, my Telegram bot, automated agents
• Kraken: 4-GPU rig at for heavy compute
• Kali VM: Penetration testing playground at

The Mac mini handles the lightweight stuff — scheduling, messaging, orchestration. Kraken kicks in when I need GPU acceleration for model inference or training. The Kali VM is where I break things.

The Brains: OpenClaw + Claude

OpenClaw is an agent framework that gives me:

• A persistent agent I can message on Telegram
• Sub-agents I can spawn for parallel tasks
• Browser automation
• File system access
• MCP server integration

I talk to it like a person. Run a pen test on X. It figures out the tools, executes, reports back.

Here is what makes it different from just using Claude in the browser:

1. Persistence: The agent remembers context across conversations
2. Tool access: It can execute commands, not just suggest them
3. Automation: I can schedule recurring tasks (my daily AI pentesting research runs every morning)
4. MCP servers: I bolted on security tools directly

MCP Servers: The Force Multipliers

Model Context Protocol lets me connect AI directly to tools. My current setup:

• Metasploit: Automated vulnerability scanning
• Kali Linux: Full pen test toolkit
• Burp Suite: Web app testing
• OWASP ZAP: Automated DAST

When I tell the agent to check this URL for vulnerabilities, it spins up Burp, runs scans, parses results, and hands me a report. I do not touch the tools manually anymore.

The workflow is:

User → Telegram message → OpenClaw → Claude → MCP → Tool → Result → Telegram response

Total elapsed time: usually under a minute for basic tasks.

What Actually Happens

Let me give you a real example.

Yesterday I needed to test a client is web app. I typed:

Run a quick pen test on client-site.com, focus on OWASP Top 10

The agent:

1. Spawned a sub-agent
2. Fired up OWASP ZAP in passive mode
3. Kicked off a Nmap scan
4. Cross-referenced open ports with known exploits
5. Returned a prioritized finding list in about 45 seconds

Was it as thorough as a manual engagement? No. But it found three medium-severity issues I would have missed doing it manually. And it cost me zero extra effort.

The Numbers

• Monthly AI spend: Around $200-300 in API calls (Claude + Grok)
• Time saved: Hard to quantify, but I would guess 10-15 hours/week on repetitive tasks
• Tasks automated: Daily threat intel, vulnerability scanning, report drafting, Slack/Telegram notifications

What I would Do Different

If you are building this:

1. Start small: Do not try to automate everything. Pick one repetitive task and solve that first.
2. Do not cheap out on the LLM: The $20/month Claude subscription pays for itself in an hour. The reasoning quality difference between cheap and premium models is enormous.
3. Home lab > cloud: I run everything local. Kraken has 4 GPUs I use for model fine-tuning. Total electric bill: maybe $150/month. Compare that to AWS and it is not close.
4. MCP is the key: The integration layer matters more than the model. The better your tool connections, the more the AI can actually do.

The Point

I am a one-person shop. I do not have a team. I do not have a SOC. I do not have a devops department.

What I have is an agent that never sleeps, never complains, and can spin up a Metasploit session faster than I can remember the syntax.

The future of solo operators is not about working harder. It is about building better systems.

---

Want details on any specific piece? Hit me up.

The Pope Just Said What Everyone's Thinking About AI

Pope Leo XIV went to Rome last week and told Catholic priests to stop using ChatGPT to write their sermons. That's the leader of 1.4 billion people saying AI can't replace the real thing.

"To give a true homily is to share faith, and AI will never be able to share faith."

That's a direct quote. No fluff, no hedging. The Pope looked at what priests were doing and said cut it out.

And here's the thing—he's right.

I don't care if you're religious or not. The point isn't the theology. It's that the Pope clocked something most people in the AI hype bubble won't admit: there's a difference between generating words and having something to say.

The Roggin Report tested an AI-generated sermon. Panelists said it lacked something. They couldn't quite name it, but they knew it was missing. That's the problem with AI writing—it's technically correct, structurally sound, and completely empty. It reads like a sermon. It sounds like a sermon. But it's not a sermon. It's a rough draft that pretends to have a soul.

The Pope also called out TikTok. Said chasing likes and followers is an "illusion" that passes for spiritual connection. Guy is 85 years old and figured out what most influencers haven't: you can have a million followers and still be alone.

Look, I'm not here to tell you AI is bad. I use it. I write with it. But there's a difference between using a tool and substituting it for the real work. A priest who lets ChatGPT write their Sunday talk is skipping the hard part—the reflection, the struggle, the actual engagement with the text. That's not a sermon. That's a paraphrase.

The Pope gets it. Maybe more people should listen.

---

References

• Futurism: Pope Implores Priests to Stop Writing Sermons Using ChatGPT
• National Catholic Reporter: Pope Leo tells priests not to use AI to write homilies
• OutKick: The Pope Is Begging Priests To Stop Using ChatGPT To Write Homilies

The 27-Second Breakout: How AI-Enabled Adversaries Are Rewriting the Rules of Cyberwarfare

When malware becomes optional and speed becomes the weapon of choice

The Numbers That Should Wake You Up

CrowdStrike's 2026 Global Threat Report dropped last week, and the statistics are sobering. We're not looking at incremental change—we're looking at a fundamental shift in how attackers operate.

The headline figures:

• 89% increase in attacks by AI-enabled adversaries
• 82% of detections in 2025 were malware-free
• 29 minutes average breakout time (down 65% from 2024)
• 27 seconds—the fastest observed breakout

Let that last number sink in. Twenty-seven seconds from initial access to lateral movement. That's not enough time to finish a sip of coffee, let alone mount an effective response.

The Rise of the "Evasive Adversary"

What CrowdStrike calls the "evasive adversary" represents a new breed of threat actor—one that doesn't need to drop malware to achieve their objectives. Instead, they're "living off the land," using legitimate tools and native system capabilities to blend into normal operations.

This isn't new in concept. PowerShell-based attacks and LOLBins (Living Off the Land Binaries) have been around for years. What's changed is the scale and sophistication that AI enables.

How AI Changes the Game

1. Automated Reconnaissance at Scale

Traditional attackers might spend days or weeks mapping a network. AI-enabled adversaries can analyze network topology, identify high-value targets, and map privilege escalation paths in minutes. The reconnaissance phase that once took a human team weeks now happens in the time it takes to brew coffee.

2. Adaptive Evasion Techniques

Machine learning models can analyze defensive patterns in real-time and adjust tactics accordingly. If one approach triggers an alert, the AI pivots instantly—testing variations until it finds a path that works. It's like playing chess against an opponent who can simulate a million moves per second.

3. Hyper-Personalized Social Engineering

AI-generated phishing has moved beyond clumsy grammar errors and generic templates. Today's AI can scrape social media, analyze communication patterns, and craft messages that mimic the writing style of colleagues, executives, or trusted vendors. The Nigerian prince has been replaced by a convincing facsimile of your CFO.

4. Malware-Free Persistence

Why drop a payload when you can use the tools already installed? AI agents can identify and abuse legitimate remote access tools, cloud services, and administrative utilities. The activity looks normal because it is normal—just weaponized.

Why Traditional Defenses Are Failing

The cybersecurity industry has spent decades building defenses around a simple model: detect the malware, block the malware, analyze the malware. But when 82% of attacks don't use malware, that model breaks down.

The Signature Problem

Signature-based detection—whether for files, network traffic, or behaviors—relies on knowing what to look for. AI-enabled adversaries generate unique approaches for each target. By the time a signature exists, the attack has already succeeded.

The Speed Gap

The average SOC takes 197 days to identify a breach. AI-enabled adversaries achieve their objectives in under 30 minutes. We're not just behind—we're operating in different time zones.

The Alert Fatigue Trap

Security teams are drowning in false positives. When everything generates an alert, analysts become desensitized. AI-enabled attackers exploit this by crafting attacks that generate just enough noise to blend in, but not enough to trigger immediate escalation.

Building a Defense for the AI Era

If we can't out-speed the attackers, we need to out-smart them. Here's what effective defense looks like in 2026:

1. Behavioral Detection Over Signature Matching

Stop looking for malware and start looking for anomalies. Baseline normal behavior for users, systems, and networks. When someone accesses resources they've never touched, at unusual times, from unexpected locations—that's your signal.

Key capabilities:

• User and Entity Behavior Analytics (UEBA)
• Network traffic analysis with ML-powered anomaly detection
• Privileged access monitoring with context-aware alerting

2. Assume Breach, Detect Fast

The 27-second breakout tells us that prevention alone is insufficient. Design your architecture assuming compromise will happen. Focus on:

• Micro-segmentation: Limit lateral movement opportunities
• Zero Trust: Verify every access request, every time
• Deception technology: Honeypots and honeytokens that trigger high-fidelity alerts

3. Automate the Response

If attackers use AI for speed, defenders must match it. Manual incident response processes that take hours or days are no longer viable.

Automated response capabilities:

• Isolate compromised endpoints within seconds
• Revoke sessions and credentials automatically
• Dynamic firewall rules based on threat intelligence
• SOAR playbooks for common attack patterns

4. Threat Hunting, Not Just Monitoring

Passive monitoring waits for alerts. Threat hunting proactively searches for indicators of compromise that evaded detection.

Hunting hypotheses to explore:

• Users accessing cloud resources outside business hours
• Administrative tools executed by non-admin accounts
• Unusual data transfer volumes to external destinations
• PowerShell execution with encoded commands

5. Adversarial AI for Defense

Fight fire with fire. Deploy AI systems that:

• Generate synthetic attack scenarios for testing defenses
• Predict attacker paths based on network topology
• Automatically correlate disparate events into attack chains
• Continuously adapt detection models based on new threat intelligence

The Human Element

Technology alone won't save us. The most critical defense is a well-trained team that understands:

• What AI-enabled attacks look like in practice
• How to investigate without relying on malware signatures
• When to escalate based on behavioral indicators
• How to respond under time pressure

Invest in continuous training. Run tabletop exercises with realistic scenarios. Build muscle memory for the 27-second reality.

Looking Ahead

The 89% increase in AI-enabled attacks isn't a spike—it's the new baseline. As AI tools become more accessible and sophisticated, the barrier to entry for advanced attacks continues to drop.

We're entering an era where the question isn't "if" you'll face an AI-enabled adversary, but "when." And when that moment comes, you'll have 29 minutes—or less—to respond.

The defenders who thrive in this environment won't be the ones with the most tools or the biggest budgets. They'll be the ones who adapted their thinking, their processes, and their technology to match a threat that moves at machine speed.

The 27-second breakout is a wake-up call. The question is: are you listening?

Resources for Deeper Dive

• CrowdStrike 2026 Global Threat Report
• MITRE ATT&CK Framework: Living Off the Land
• CISA: Defending Against Malware-Free Intrusions

---

John Kennedy is a cybersecurity professional with 34 years of military experience in information warfare and 9 years in civilian penetration testing and security assessment. He writes about the intersection of AI, cloud security, and modern threat landscapes.

Here is a link to my BSIDES talk regarding the 0-day I found, exploited, and reported:

https://youtu.be/YoNrNBnmwuY

SLAE64 Exam - Assignment 7 of 7 (Cryptor)

This post is the seventh of 7 exam assignments of the Pentester Academy's x86/64 Assembly and Shellcoding on Linux.

SLAE64 - 1501

Success in these 7 assignments results in the Pentester Academy's SLAE64 certification.

http://www.securitytube-training.com/online-courses/x8664-assembly-and-shellcoding-on-linux/index.html

All 3 files  used in this assignment are here:
https://github.com/clubjk/SLAE64-3/tree/master/exam/cryptorAssignment:

• Create a custom crypter like the one shown in the “crypters” video

• Free to use any exisSng encrypSon schema 

• Can use any programming language 

I chose an AES encryption script created by Blu3Gl0w13. Check out his excellent blog here.

I elected to use the execve-stack shellcode as a base for this assignment.  I extracted its shellcode using a modified objdump command.



I pasted the shellcode into encryptor.py as well as choosing a key of 'clubjk'.




I executed the script and it outputted encrypted shellcode.



I pasted this encrypted shellcode in decryptor.py as well as adding the key of 'clubjk'.



I executed the encryptor.py and the decrypted execve-stack shellcode executed uneventfully.



It worked. Yay.

Files used in this assignment:

execve-stack.nasm
encryptor.py
decryptor.py

All are here:
https://github.com/clubjk/SLAE64-3/tree/master/exam/cryptor

SLAE64 Exam - Assignment 6 of 7 (Polymorphic Shellcode)

This post is the sixth of 7 exam assignments of the Pentester Academy's x86/64 Assembly and Shellcoding on Linux.

SLAE64 - 1501

Success in these 7 assignments results in the Pentester Academy's SLAE64 certification.

http://www.securitytube-training.com/online-courses/x8664-assembly-and-shellcoding-on-linux/index.html

All 3 files  used in this assignment are here:
https://github.com/clubjk/SLAE64-3/tree/master/exam/polymorphic

Assignment:

• Take up to 3 shell codes from Shell-Storm and create polymorphic versions of them to beat pattern matching
• The polymorphic versions cannot be larger than 150% of the existing shellcode
• Bonus points for making it shorter in length than original

http://shell-storm.org/shellcode/files/shellcode-878.php - (cat /etc/password)   (82 bytes)

I took the nasm file from the above link, nasm-compiled and linked it.  Used a modified objdump command to extract its shellcode.



I pasted the shellcode into the shellcode.c template.

I compiled the shellcode.c template with the modified gcc command:

$   gcc -fno-stack-protector -z execstack shellcode1.c -o shellcode1

I executed the shellcode, confirmed that it executed "cat /etc/passwd", and noted it's size (82 bytes).

Polymorphic version of the original nasm

I made the following modifications to the original nasm to create a polymorphic version to evade pattern matching:


(did this in each of the four "xor rax, rax" commands.

I did the same thing for a "xor rdx, rdx" command.



I nasm compiled and linked it, then extracted its shellcode and pasted into the shellcode.c template.
I executed it, confirmed that it executed "cat /etc/passwd" and noted it had 97 bytes.

http://shell-storm.org/shellcode/files/shellcode-603.php - ("execve /bin/sh")  (30 bytes)

I created a binary based upon the above shellcode, then a shellcode binary  and executed it.

Then I created a polymorphic version of its nasm with the following edits.

Then I created shellcode from this nasm and executed it.



I confirmed that it executed "execve /bin/sh" as the original did and that it's size was 56 bytes.

http://shell-storm.org/shellcode/files/shellcode-896.php - (add "127.1.1.1 google.lk" to /etc/hosts)  (113 bytes)

I made the following edits in 3.nasm.

I executed the new version of the shellcode, saw that it added the line to /etc/hosts, and that it's size was 133 bytes.

Test results:

Files used in this assignment:

1.nasm
1poly.nasm
shellcode1.c
shellcode1poly.c

2.nasm
2poly.nasm
shellcode2.c
shellcode2poly.c

3.nasm
3poly.nasm
shellcode3.c
shellcode3poly.c

SLAE64 Exam - Assignment 5 of 7 (Analysis of Shellcode)

This post is the fifth of 7 exam assignments of the Pentester Academy's x86/64 Assembly and Shellcoding on Linux.

SLAE64 - 1501

Success in these 7 assignments results in the Pentester Academy's SLAE64 certification.

http://www.securitytube-training.com/online-courses/x8664-assembly-and-shellcoding-on-linux/index.html

• •  Take up at least 3 shellcode samples created using Msfpayload for linux/x86_64
  
• •  Use GDB to dissect the funcSonality of the shellcode
  
• •  Document your analysis 
  

All 3 shellcode.c's used in this assignment are here:

https://github.com/clubjk/SLAE64-3/tree/master/exam/analysis

I chose 3 msfvenom shell to analyze and disect with GDB:

• linux/x64/shell_bind_tcp
• linux/x64/shell_reverse_tcp
• linux/x64/exec

linux/x64/shell_bind_tcp

I reviewed this shell code's basic options:

The only required option for this shellcode is the LPORT which defaults to 4444

I generated shellcode in c format:

I noticed a few null bytes ("\x00") in the shellcode, so I re-ran the command with the -b (bad character removal) option:

I noted that the shellcode size was 127 bytes.

I pasted the shellcode into the shellcode.c template:

I compiled it with the following command:

$   gcc -fno-stack-protector -z execstack shellcode.c -o shellcode

I loaded the shellcode binary into GDB with the following command:

$ gdb -q ./shellcode -tui

I set up the GDB interface as follows:

Note: I defined the intel syntax via the .gdbinit file.

I "stepi'd" until the decoding loop finished:

I noticed that the code at <code+39> had decoded into something resembling a syssocket syscall (0x29).  I advanced the execution to the first syscall and examined the registers:

Note also used the "x/6xg $rsp" command to show the first six positions on the stack.

I noticed that prior to the execution of the syscall command, that rax had the syssocket value of 41, the rdi had 2, the rsi had 1 and rdx had 0.  I executed the first system call and noted the return value of 3 in rax.  

I stepi'd to the next system call and examined the registers and stack:

This time the rax had 49 (bind), the rdi had 3, the rsi had the value of the default port 4444 (0x5c11) and the rdx had a value of 16.  I executed the system call and noted the return value of 0.

I stepi'd to the next system call.

The rax had 50 (listen).  The rdi had 3 (int fd) and the rsi had memory location of port 4444.

I steps'd to the next system call.



The rax had 33 (dup).  The rdi had 4 (oldfd) and the rsi has 2 (newfd).  The syscall was followed by a jne command which repeated the syscall until the rsi decremented to 0.  Then the syscall executed with a return value of 0 in rax.

I stepi'd to the last system call.



The rax had 59 (execve).  The rdi had the memory location that holds the /bin//sh string (in hex) and the rsi had a pointer which pointed to the memloc of the /bin//sh string.

I executed the syscall, and in another terminal connected to the bind via netcat.



It worked.  Yay.

inux/x64/shell_reverse_tcp


I reviewed this shell code's basic options:


I noticed that it had two basic options; the LHOST and the LPORT(which defaults to port 4444).

I generated the shellcode in c format:

I noticed a null byte ("\x00"), so I reran it adding msfvenom's -b (bad character removal) switch:



Next, I  pasted the shellcode in the shellcode.c template:


I compiled it with the following gcc command:

$   gcc -fno-stack-protector -z execstack shellcode.c -o shellcode

I put the resulting binary (shellcode) in gdb and examined the state of the registers and stack at the start of the code section of the binary.

$ gdb -q ./shellcode -tui

I noticed that the decoding stub ended at <code+37> (after the loop finishes) and that the rest was gibberish that would decode when the loop finished.  I advanced to when the loop finishes and examined the decoded shellcode (starting at <code+39>).



After the decoding loop finished, I examined the first 8 assembly instructions and notice that now the opcode resembled a syssocket system call set up (0x29; 41).  I advanced the the first system call and examined the state of the registers and stack.



Prior to the first system call the rax contained 41 (syssocket).  The rdi contained 0; rsi was 1, rdx was 0.
I executed the syscall and noted a return value of 3 in the rax.

I advanced to the next syscall and examined the state of the registers and stack.



This time the rax held 42 (connect).  The rdi had 3; rsi held the memory location of the IP (0x0100007f; which is 127.0.0.1) and the port (0x5c11; which is 4444).  The rdx held 16 (length of string in rsi).  I executed the syscall.

Next was the dup section (33).  I stepi'd through the jne loop and watched as the rsi decremented to 0.   I executed the syscall and noted the return value of 0 in the rax.

I advanced to the next syscall.



The rax held 59 (execve). The rdi had the stack pointer to the /bin//sh string.  The rsi had the stack pointer that pointed to the memloc of the /bin//sh string.  The rdx held 0.

I executed the syscall.



It worked. Yay.

linux/x64/exec

I reviewed this shell code's basic options:


I noted that the only argument was the CMD.  I planned to the use the string "cat /etc//passwd" (added an extra "/" to the string to make it an even 16 bytes).

I generated and examined the shellcode in c format.

I noticed some null bytes, so I reran the command with the -b switch.

I pasted the shellcode into the shellcode.c template as before and compiled it with a modified gcc command as before.

Then, I put the shellcode binary in gdb.

$ gdb -q ./shellcode -tui



I set up gdb by setting a breakpoint for the beginning of the shellcode ("code") section of the c-based binary.  I also set up the tui interface to display the assembly and registers.

I saw that the decoder stub ended at the loop command (<code+37>).  Noticed that after the loop were commands that were unrecognized by gdb or unusual in shellcode.  I stepi'd through the loop function and noticed that the code from <code+39> changed to recognizable syscall preparation commands.



Seeing indications that the code after the stub had decoded properly, I advanced to the first syscall and inspected the state of the registers and stack.



The rax held 59 (execve).  The rdi held memloc of the "/bin/sh" string.  The rsi held memloc pointer to the "/bin/sh" string.  I executed the syscall.



The "cat /etc/passwd" command successfully executed.

It worked. Yay.