[ AI Attacks Are Faster Automation: Defense in Depth Still Works ]

Every few months someone tells me AI changes everything about defense. I don't
think it does. Attackers have automated for as long as there's been a network
to attack, and every wave of automation got sold as the end of security as we
knew it. What AI gives an attacker is speed, scale and polish: cheaper
phishing, faster recon, exploits written sooner after a patch ships. Those
are real problems. They're also the same attacks we already know how to
stop.

An attack still has to get in, get credentials, move around and take
something out. Each of those steps is a place to stop it, and that's the
whole idea behind defense in depth: stack enough layers that no single
failure is fatal. A faster attacker still has to get through every one of
them.

This guide covers what AI actually changes, what it doesn't, and a long
checklist for hardening the things I care about: servers, accounts, DNS and
email, the home network, backups, detection, and the AI tools we're all
starting to plug into everything.

Automated attacks aren't new. A short history of attackers letting a machine
do the work:

  — 1988, the Morris worm. It spread on its own through weak passwords
    and buggy services, and slowed or crashed thousands of machines on the
    early internet.
  — 2001, Code Red. It infected about 359,000 web servers in roughly 14
    hours, with no human picking targets.
  — 2003, SQL Slammer. It doubled about every 8.5 seconds and hit most of
    its vulnerable hosts within 10 minutes.
  — 2008, Conficker. Millions of Windows machines, and a botnet that
    defenders spent years cleaning up.
  — 2016, Mirai. Cameras and DVRs still on their default passwords,
    turned into a botnet that knocked major sites offline through an attack
    on the DNS provider Dyn.
  — Every day since: credential stuffing with leaked password lists,
    scanners that sweep the whole IPv4 internet in minutes, exploit kits,
    and ransomware sold as a service.

None of those needed AI. Each one was beaten the same way: patching, fewer
exposed services, better passwords and MFA, segmentation so one machine
couldn't reach everything, and backups for when the rest failed.

Here's my honest list. Every item is an old problem, made cheaper or faster:

  — Phishing reads well now. Good grammar, the right tone, details
    scraped from LinkedIn, in any language. Bad spelling is no longer a
    warning sign.
  — Voices and faces can be faked. A cloned voice from a short clip, or a
    video call full of fake coworkers. In 2024 a finance worker at Arup in
    Hong Kong paid out about $25 million after a call like that.
  — Exploits come sooner. Turning a patch into a working exploit takes
    less skill and less time, so the gap between "patch released" and
    "attacks start" keeps shrinking.
  — Recon scales. Mapping a company's people, domains and exposed
    services is cheap now.
  — Malware varies itself. Rewritten variants dodge signatures, so
    detection that only knows what bad code looks like ages faster.
  — Bots get better at passing as people, including on CAPTCHAs.
  — Your own AI tools are a new target. Prompt injection, agents with
    more access than they need, and models that leak what's in their
    context. The OWASP Top 10 for LLM apps and MITRE ATLAS cover these.

The stages. MITRE ATT&CK still describes these attacks, because a faster
attacker still has to do the same things in the same order:

  1. Find a way in: a phished login, an unpatched service, a stolen key.
  2. Get credentials or privileges worth having.
  3. Move toward something valuable.
  4. Take it, encrypt it or break it, and get it out.

Every step is a chance to stop the attack, and the attacker needs all of them
to work. That's still the defender's advantage, AI or not.

I think about it as layers that each fail sometimes. That's fine, as long as
their failures don't line up:

What AI changes about each layer:

  — Identity. Phishing gets better, so make it pointless: passkeys and
    hardware keys can't be phished. Verify money and password requests out
    of band.
  — Exposure. Exploits come sooner, so expose less and patch what's
    left fast, especially VPNs, firewalls and routers.
  — Network. Segmentation and outbound filtering don't care how clever
    the attacker is. A camera that can't reach your NAS can't be used
    against it.
  — Endpoint. Variants beat signatures, so lean on least privilege,
    allowlisting and behavior-based detection.
  — Data. Backups that the attacker can't reach turn ransomware into a
    bad day instead of a disaster.

This is the list I actually work through. It's long on purpose: no single item
here matters much, and together they make a target that isn't worth the
effort. Start with whatever covers the most ground for you.

Accounts and identity

  — Use passkeys or FIDO2 hardware keys on the accounts that unlock all the
    others: email, the domain registrar, DNS, code hosting and the cloud.
    Register two keys and keep one somewhere safe.
  — Keep SMS and app codes for accounts that offer nothing better. Both can
    be relayed in real time by a phishing proxy.
  — Use a password manager, with a unique password everywhere. Credential
    stuffing only works on reused passwords.
  — Use a separate admin account for admin work. Your everyday login
    shouldn't be able to change the firewall.
  — Store recovery codes offline, and check who can reset your accounts:
    support desks are a favorite target for social engineering.
  — Review OAuth apps and API tokens a few times a year. Revoke what you
    don't use, and give tokens the narrowest scope and shortest life that
    works.

Servers

  — SSH by key only. Turn off passwords and root login, and allow only
    the accounts that need it. In /etc/ssh/sshd_config:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
AllowUsers deploy
MaxAuthTries 3

    Test it with sudo sshd -t, reload with sudo systemctl reload ssh, and
    keep a second session open until you've confirmed you can still log in.
  — Default-deny firewall. Allow only what the server serves:

sudo ufw default deny incoming
sudo ufw allow OpenSSH
sudo ufw allow 443/tcp
sudo ufw enable

    If a server never needs to start outbound connections, deny outgoing too
    and allow only what it needs (updates, DNS, NTP). That stops a lot of
    malware from phoning home.
  — Behind a CDN, lock the origin. If Cloudflare or another proxy
    fronts the site, have the origin firewall accept web traffic only from
    the proxy's published IP ranges, or use authenticated origin pulls.
    Otherwise attackers just go around the proxy.
  — Automatic security updates. On Debian or Ubuntu, run
    sudo dpkg-reconfigure --priority=low unattended-upgrades. Reboot for kernel
    updates on a schedule, so a patched kernel actually gets loaded.
  — Run less. List what's listening with sudo ss -tulpn and turn off
    what you don't need with sudo systemctl disable --now <service>. Every
    service you remove is one you never have to patch.
  — Brute-force throttling with fail2ban or CrowdSec on SSH and any login
    page. It won't stop a targeted attack, but it drops the noise so the real
    alerts stand out.
  — Least privilege for services. Each app gets its own unprivileged user.
    The web server can read the site but not write it, and only the deploy
    account can change files.
  — TLS done properly. TLS 1.2 and up, HSTS once you're sure, and a
    config from the Mozilla SSL Configuration Generator.
  — Security headers on every response: a strict Content-Security-Policy,
    HSTS, X-Content-Type-Options, Referrer-Policy and frame-ancestors. My
    Cloudflare + strict CSP guide covers making a strict CSP work behind
    Cloudflare.
  — Secrets out of code. No keys in git. Keep env files readable by their
    service only (chmod 600), turn on secret scanning in your repos, and
    rotate anything that leaks the same day.
  — Containers aren't a boundary by default. Don't mount the Docker socket
    into containers, run as non-root, pin image versions, and scan images
    with a tool like Trivy.
  — Dependencies. Let Dependabot or Renovate open the update pull
    requests, and actually merge them.
  — Audit yourself. sudo lynis audit system gives a hardening score and a
    to-do list. Rerun it after changes.
  — File integrity monitoring with AIDE or similar, so a changed binary or
    config file is something you hear about.
  — No admin panels on the internet. Put them behind a VPN or a zero-trust
    access proxy, or keep them on localhost and tunnel in.

Web apps and APIs

  — Rate-limit everything that writes, logs in or costs money, per IP and
    per account.
  — Turn on bot management or bot-fight features if your CDN has them, and
    make them work with your CSP instead of loosening the CSP.
  — Never trust the client. Anything a browser sends can be scripted, so
    check it on the server: scores, prices, permissions, file types.
  — Validate input on the server, use parameterized queries, and encode
    output for the context it lands in.
  — Sign or authenticate API calls, and set CORS to the origins that need it,
    not *.
  — Log auth failures and odd patterns somewhere you'll actually look.

Domain, DNS and email

  — Turn on registrar lock, and protect the registrar account like your
    email. Whoever holds the domain holds the site and the mail.
  — Add CAA records so only your chosen certificate authorities can issue
    for your domain, and turn on DNSSEC if your registrar and DNS host
    support it.
  — Watch certificate transparency logs for your domain (crt.sh, or an
    alerting service). A certificate you didn't request is an early warning.
  — Publish SPF, DKIM and a DMARC policy that ends at p=reject. AI makes
    convincing spoofed mail cheap; DMARC stops mail claiming to be from
    your domain when it isn't.
  — Domains that never send mail should say so: SPF v=spf1 -all and DMARC
    p=reject.

Home network and IoT

  — Keep the router updated, and replace it once it stops getting firmware.
    Edge devices are exactly what fast exploits go after.
  — Turn off UPnP, so devices can't open holes in your firewall on their own.
  — No port forwards for remote access. Use WireGuard or Tailscale instead,
    and never expose a NAS, a camera or Home Assistant directly.
  — Put IoT and smart-home gear on its own VLAN or SSID, with no route to
    your computers. Let the hub reach the devices, not the other way round.
  — Change every default password. Mirai did nothing cleverer than try
    them.
  — Use a guest network for guests and anything you don't trust.
  — Filter DNS with Pi-hole, AdGuard Home or a filtering resolver. It blocks
    known-bad domains, and its query log shows you what's phoning home.

Endpoints

  — Automatic OS and browser updates, and reboot when asked.
  — Full-disk encryption on anything that leaves the house.
  — Don't use an admin account day to day.
  — Keep Defender or another EDR on, and keep browser extensions to the few
    you trust. Extensions see everything you browse.
  — Use application allowlisting where you can, such as on kids' machines and
    single-purpose boxes.

Backups and recovery

  — Follow 3-2-1: three copies, on two kinds of media, one off-site.
  — Keep at least one copy offline or immutable (object lock, or a drive that
    stays unplugged). Ransomware goes after backups first.
  — Backup credentials shouldn't be the same ones an attacker gets from the
    machine being backed up.
  — Do a test restore. A backup you've never restored from is a hope, not a
    backup.
  — Write down how to rebuild your important boxes from scratch, and keep
    that somewhere other than on those boxes.

Logging and detection

  — Ship logs off the box. An attacker with root can edit local logs, but
    not the copy on another machine.
  — Alert on the things that matter: new admin accounts, new SSH keys, new
    cron jobs or services, logins from new places, and big outbound
    transfers.
  — Plant honeytokens: fake AWS keys, decoy documents, a canary DNS name.
    canarytokens.org makes them for free. Automated attackers grab everything,
    so tripwires work very well against them.
  — Prefer behavior-based detection over signatures, since varied malware
    makes signatures go stale.
  — Check the alerts. Detection nobody reads doesn't count.

Your own AI tools

  — Treat model output as untrusted input. Never pipe it straight into a
    shell, a database query or an HTML page.
  — Give agents the fewest tools and the narrowest permissions that work, and
    require a human to approve anything with side effects: sending, buying,
    deleting, deploying.
  — Assume anything the model reads can carry instructions: web pages,
    emails, documents, issue comments. That's prompt injection. The defense
    is limiting what the agent can do; don't count on it noticing.
  — Keep secrets out of prompts and context. Whatever the model can see, an
    attacker may be able to make it repeat.
  — Run model-written code in a sandbox, and log what agents do.

People and process

  — Set a verification rule and stick to it: any request for money,
    passwords, MFA resets or gift cards gets checked through a channel you
    already trust, like calling back on a number you have.
  — Agree a code word with family, and with coworkers if you handle money.
    It's cheap and it beats a perfect voice clone.
  — Teach people to verify rather than to spot typos. AI-written phishing
    doesn't have typos.
  — Make reporting easy and blame-free. The person who clicked and said so
    in five minutes saved you; the one who stayed quiet out of fear didn't.
  — Keep a one-page incident plan: who to call, how to cut a machine off the
    network, where the backups are, which passwords to rotate first.

Some of this list running on magikh0e.pl:

  — Static origin. The site is static HTML behind Cloudflare. There's no
    database or login form on the origin for anything to inject into or
    brute-force.
  — Strict CSP. No inline scripts or styles anywhere. A small Cloudflare
    Worker adds a fresh nonce to every page, so Cloudflare's own bot checks
    can run without loosening the policy. The details are in my
    Cloudflare + strict CSP guide.
  — Bot protection on. Automated traffic gets challenged at the edge,
    before it reaches the origin.
  — The games don't trust the browser. The world boards for my
    Hack the Planet Pinball game run on Workers. Every game gets a signed
    token, writes are rate-limited, and the server checks that a score is
    possible for the time played. Records far past the current one wait for
    me to look at the game's recording before they go up.
  — No admin panel on the internet. The admin page I use for the game runs
    on my own machine, on localhost.
  — Key-only deploys. Changes go out over SSH with a key, and the source
    is backed up to a private repo.

None of these is clever on its own. Together they mean a bot has to beat
several unrelated things in a row, and most give up at the first one.

Plan as if something will get through, because eventually something will.
It's not a matter of if, it's a matter of when. Nobody gets every layer right
forever, and you only need one bad day: a missed patch, one tired click, a
vendor that gets breached. A faster attacker shrinks the time you have, so
practice the steps before you need them:

  1. Spot it: the alerts from the logging section.
  2. Contain it: pull the machine off the network (unplug it or block
     it at the switch or firewall) rather than wiping it. You'll want to know
     how they got in.
  3. Rotate: passwords, keys and tokens that machine could see, starting
     with email and anything with admin rights.
  4. Rebuild: from known-good media and backups, not by cleaning the
     infected box.
  5. Learn: find the hole and close it in every layer it got past.

The same tools help defenders. I'd use them for:

  — summarizing noisy logs and alerts into something a person will read,
  — drafting detection rules and firewall configs that I then check by hand,
  — sorting phishing reports and explaining suspicious scripts,
  — finding the bug before someone else does, in my own code.

Two rules: a human makes the call on anything that changes production, and
I don't paste secrets, keys or other people's data into a third-party AI
service.

Do AI attacks need brand-new defenses?
Mostly no. They run the same stages as every attack before them: get in, get
credentials, move around, take something. The layers that stop those stages
still work. What changes is speed, so patching and detection have to be faster,
and phishing-resistant MFA and verification rules matter more. The one new area
is securing your own AI tools.

Is MFA enough against AI-written phishing?
It depends on the kind. Codes from SMS or an authenticator app can be phished
in real time by a proxy that sits between you and the real site. Passkeys and
FIDO2 security keys are tied to the real site's address, so a fake page can't
use them. That's the kind I'd put on anything important.

Can AI write malware that gets past antivirus?
It can churn out variations that dodge signatures, which is why I lean on
things that don't care what the code looks like: least privilege, application
allowlisting, behavior-based detection and egress filtering.

How do I protect against voice-clone and deepfake scams?
Don't let a voice or a face be the proof. For money, passwords or MFA resets,
verify through a channel you already trust, like calling back on a number you
have, and agree a code word with family or coworkers. Urgency is the tell: real
requests survive a five-minute check.

Where should I start?
Passkeys or hardware keys on your email, your domain registrar and DNS, and
your code hosting. Then patch or retire anything you expose to the internet,
and make an offline backup you've actually restored from.