Test what you own, from the outside.

What you can add

A target is one of two kinds:

• A domain: a bare hostname such as app.example.com. Its site is tested over https. Pasting https://app.example.com/ works too, and keeps only the hostname.
• A URL: a base URL with its scheme, port and path, such as https://api.example.com:8443/v1, for an API. It can’t carry a query, a fragment or credentials.

A target has to be reachable from the internet by name. Private and reserved names such as localhost, .local, .internal and .test are refused, and so are bare IP addresses and Till’s own domains. A workspace holds up to 50 targets. Only owners and admins can add, check, run or remove them.

Prove you own it

Each target gets its own value to publish. Any one of these three proves it:

A DNS record

Add a TXT record at _tillshield. plus the hostname, holding the value TillShield shows:

_tillshield.app.example.com.  300  IN  TXT  "tillshield-verify=<value from TillShield>"

A file on the server

Serve the same value as a line of plain text at /.well-known/tillshield-verify on the target’s origin, including its port for a URL target. TillShield reads it with no redirects, from a public address only, and reads at most 4 KB.

# served at https://app.example.com/.well-known/tillshield-verify, status 200, no redirect
tillshield-verify=<value from TillShield>

A domain you already verified

A domain this workspace verified for single sign-on covers itself and every subdomain. A TillAuth custom domain covers itself. There’s nothing to publish. Instead, the domain’s own record is checked again, and a TillAuth domain also counts while it still points at TillAuth. A target one of these covers is verified the moment you add it, and that check reads only your own DNS records, never the target.

What each proof allows

A DNS record shows you control the name, but a name can point at anyone’s server. Only the file shows you control the server that answers for it. So the proofs allow different drills:

A defense drill exercises a rule rather than a target, so it needs no proof.

Checked again before every run

A proof is only as good as the moment it was seen, so every drill looks for it again before it sends a single request. It tries the method that worked last first. A drill doesn’t start when:

• no proof holds; the target then shows as lapsed if it was proven before;
• the only proof that holds doesn’t allow that drill, such as a DNS record for a load drill;
• a DNS lookup fails on Till’s side, so ownership can’t be checked. The target’s state stays as it was.

Check proof on a target, or tilldev shield drill targets check, looks for the proof straight away. Each check reaches out to the target, so a workspace can ask for 30 an hour, and one target once every 10 seconds. When no proof holds, the target shows what each check saw.

Adding, proving, lapsing and removing a target, changing its schedules or latency settings, recording or withdrawing authorisation for intrusive probes, starting a run by hand, stopping one, and the end of every load drill, with who did it, are all in the workspace audit log. Removing a target retires it: nothing runs against it again, and past runs keep its name. Adding it back gives it a new value to publish.

What any visitor can see

A passive run reads what your site already shows every visitor and judges it against 32 checks. Each check is tagged with the OWASP Top 10 category it falls under, and with ASVS requirements where one fits. A run makes only TLS handshakes, GET requests and DNS lookups, and nothing on the target is changed. Start a run with Run now on a target, from the CLI or the API, or set it to repeat.

A run goes in this order, and stops at the first step that fails:

1. It checks the proof again, as above.
2. It resolves the hostname. If any address it resolves to is private or reserved, the run is refused and nothing is sent.
3. Every connection to the target goes to those checked addresses only, so a DNS change mid-run can’t point it somewhere else. Each connection gives up after 10 seconds, and the whole run after 90 seconds.
4. It reads four sections, each on its own, so one that can’t be reached doesn’t hide the others.

HTTP requests carry the user agent TillShield-Drill/1 (+https://tilldev.dev/docs/tillshield/drill), so you can find them in your logs. TillShield keeps the names and attributes of cookies, never their values, and keeps URLs without their query strings.

Ask the target directly, and read only

Active checks ask your own target questions a passive run can’t: does this path answer, does this folder list its files, what does this API share with another origin, does this link parameter send visitors somewhere else, does this name still point at a provider that claims it. They are judged against 15 checks, tagged the same way as the passive ones.

Everything a run sends is a read. There is no PUT, DELETE, PATCH or CONNECT, no password guessed, no injected payload, nothing written and nothing deleted. Two values a run sends are deliberately unreachable: the origin it uses to ask about cross-origin sharing, and the host it uses to test redirect parameters, both under a name reserved so it can never resolve. A target that honours the redirect sends nobody anywhere real.

A run goes through the same gate as every other drill, and then some of its own:

1. The proof is checked again. Active checks need the file on the server, or a DNS record over https, where the certificate ties the server to the name.
2. The hostname is resolved once; a private or reserved address refuses the run, and every request is pinned to the addresses it resolved to.
3. The target is asked for a path that cannot exist, to learn what it answers for anything missing. That answer is the baseline every later finding is measured against.
4. Each part runs on its own, so one that can’t be reached never hides the others, and a part that couldn’t run is reported as not run, never as a pass.

One run sends at most 160 requests, 4 at a time and 60 ms apart, reads at most 4 KB of each answer, and stops after 180 seconds. Requests carry the user agent TillShield-Drill/1 (+https://tilldev.dev/docs/tillshield/drill), so you can find them in your logs, and Stop ends a run within seconds and keeps what it saw. Active checks are off for a new target: turn them on under a target, with tilldev shield drill targets active <target-id> daily, or run one now with tilldev shield drill active <target-id>. When the name resolves nowhere, nothing is sent and only the DNS part runs — which is exactly when a name pointing at nothing matters most.

The one part that sends inputs built to be mishandled

Every other drill reads. Intrusive probes send values made to be parsed wrong — a stray quote, a value a template engine would evaluate, an over-long field, a sign-in that must fail — to find where your own target mishandles them. Because they reach the target in a way the other drills never do, they are off until you turn them on, and three gates stand between them and a run.

Opt in, three ways at once

1. The strongest proof. Only the file served on the target allows intrusive probes. A DNS record or a domain you verified elsewhere never does, because they prove the name, not the server.
2. Your authorisation, in writing. You record that you are authorised to test the target. The authorisation stands for 90 days and then lapses until you record it again; withdrawing it stops the probes and turns off their schedule at once.
3. A maintenance window. They run only inside a window you set — a weekday, a start time and a length from 30 minutes to 8 hours, read in the timezone you choose, up to 7 windows a target. A run started outside every window is refused.

With all three in place, run one by hand, or set a schedule to run inside the next window. Only one intrusive run happens at a time across the whole workspace. Every run goes through the same gate as the others first — the proof is checked again, the name resolves once, a private or reserved address refuses the run, and every request is pinned to the addresses it resolved — and then confirms the window is still open.

One run sends at most 240 requests, 1 at a time and 200 ms apart, reads at most 64 KB of each answer, and stops after 5 minutes. It reads at most 6 pages to find the 20 parameters it tries, and makes at most 8 failing sign-ins. Requests carry the user agent TillShield-Drill/1 (intrusive; +https://tilldev.dev/docs/tillshield/drill), so you can find them in your logs. A workspace starts 6 intrusive runs a day and one per target every 1 hour. A run stops itself if the target starts failing. Stop ends one within seconds and keeps what it saw.

How fast it answers, from where your users are

A latency run sends 5 ordinary GET requests to the target from each region, 500 ms apart, and times each one: connecting, the TLS handshake, the first byte and the whole answer. It goes through the same steps as a passive run first: the proof is checked again, the hostname is resolved once, a private or reserved address refuses the run, and every request goes to the checked address. A redirect is timed as it is and not followed. Each request gives up after 10 seconds and reads at most 1 MB of the answer, which is never kept.

Every target has a budget: the 95th-percentile total time a request should stay under, 1000 ms unless you set one from 50 ms to 30 seconds. A run lists each region with its 50th and 95th percentile, first byte, connect and TLS times and the answers it got, and judges the result against 6 checks: over budget, a slow first byte (over 800 ms), regions far slower than the rest, failed requests, and the target down from some or every region.

Measure it now with Measure now under Speed and load on a target, or set it to repeat hourly or daily; latency is off for a new target. Pick the regions it runs from, or leave it on every region that can measure when the run starts. A latency run is allowed by any proof, and a whole run ends within 4 minutes. Requests carry the user agent TillShield-Latency/1 (+https://tilldev.dev/docs/tillshield/drill) and the header x-tilldrill-run: <run id>.

How it holds up, with a hard ceiling

A load drill sends a planned rate of requests to one path on the target and records what came back, second by second. It needs the file on the server: a DNS record or a verified domain never allows one, because a name can point at someone else’s server. Plans past a cap are refused, never trimmed, and the caps are the same in the dashboard, the CLI and the API.

It stops on its own

Every region judges itself every 10 seconds, once it has sent at least 20 requests in that window. When the error rate or the 95th percentile passes the plan’s threshold, that region stops and the others are stopped with it. Errors are requests with no answer, 5xx answers and 429s. You can stop a drill at any time with Stop, the CLI or the API, and it keeps what it measured until then. A probe host reports in every 5 seconds while it runs, and stops by itself if it can’t reach TillShield for 20 seconds. A drill that runs past its length plus 3 minutes is stopped.

What a drill shows

The requests sent against the plan, the peak rate reached, the error and rate-limited shares, the 95th percentile at the start and at the peak, and a timeline in 5-second steps of what was answered, what failed and how fast. It is judged against 6 checks, such as responses slowing down sharply under load or the planned rate never being reached.

Requests carry the user agent TillShield-Load/1 (+https://tilldev.dev/docs/tillshield/drill) and the header x-tilldrill-run: <run id>, so you can find them in your logs and leave them out of your analytics. A workspace can start 10 load drills a day, one target once every 15 minutes, and run 1 at a time. Load drills never run on a schedule.

Where the traffic comes from

Latency and load run from TillShield’s probe hosts in 13 regions: Africa (south), Africa (west), Africa (east), Africa (north), Europe (west), Europe (east), Middle East, Asia (south), Asia (east), Oceania, North America (east), North America (west), South America. Each probe host checks every task it is given again before it sends anything: the address must be public, the plan must be inside the caps, and a task it can’t read is refused. A load drill runs only from probe hosts.

When no probe host is online in a region, latency in 9 of them can still be measured from TillShield’s edge, over the same pinned connection to the checked address. The edge can’t reach addresses on its own provider’s network, so for a target there that region comes back not run, with the reason. Each region shows where it really ran from.

Regions in the dashboard, tilldev shield drill regions and GET /shield/drill/regions list which regions can measure now and the addresses their traffic leaves from.

Reading a run

Each check comes out one of four ways:

A run that couldn’t collect any section fails, and still keeps each check’s reason. A run that was refused, because the proof had gone, the target was removed or an address was private, sends no checks and says why. A run that stops without finishing is marked failed after about 4 minutes, and you can start it again.

Run it on its own, hear when it gets worse

Each target repeats its passive checks daily, weekly or not at all, and a new target is set to daily. A proven target that has never run starts straight away, and after that runs one period after its last run. A lapsed target stays on its schedule: each scheduled run checks the proof again and is refused until the proof is back. Active checks have their own schedule, daily, weekly or off, and a new target has them off, so a target proven for passive checks alone never starts asking the server on its own. Latency has its own schedule too, hourly, daily or off, and both work the same way. Intrusive probes can repeat daily or weekly as well, but only once you’ve turned them on, and each run waits for the next maintenance window.

Scheduled runs alert on what changed. When a scheduled passive, active, intrusive or latency run finds checks failing at medium or above that didn’t fail on the last successful run of the same kind, it sends one alert listing them, and run.profile says which kind it was. The first run of a target counts every failure as new. A run you started yourself never alerts about failing checks, because you’re already looking at it. Any run, scheduled or started by hand, that finds the proof of a verified target gone sends one alert as the target lapses. A proof check you start yourself shows its result instead.

Alerts go where your other security alerts go: the email, Slack and webhook set under Shield → Settings → Playbooks & security alerts. See security alerts for who gets email and how to verify a webhook’s signature.

{
  "type": "tillshield.drill.checks_failing",
  "delivery_id": "6f1c…",
  "target": { "id": "9b2e…", "value": "app.example.com" },
  "run": { "id": "d41a…", "trigger": "schedule", "profile": "surface" },
  "failures": [
    { "id": "drill-cert-expiring", "title": "Certificate expires within 14 days", "level": "medium" }
  ],
  "reason": null,
  "checked_at": "2026-10-01T06:00:12.000Z",
  "link": "https://tilldev.dev/acme/shield/drill?target=9b2e…"
}

How much you can run

Scheduled runs don’t count toward the hourly limit.

Read your own APK, IPA and desktop builds

TillDrill also reads the builds you ship and judges them against 41 checks, each tagged with the OWASP MASVS control it falls under. It flags debuggable and test builds, plain-text traffic, components any app on the device can open, secret keys shipped inside the app, executables built without the usual hardening, and weak crypto, each with how to fix it. A build is your own file, so no proof of ownership is needed. Scan one under Shield → TillDrill → App builds, from the CLI, or from the API.

An Android App Bundle, a DMG, an MSI and Linux packages aren’t read as they are; the scan fails and says how to get a file it reads, such as a universal APK from bundletool build-apks --mode=universal. A build can be up to 1024 MB, sent in parts of 8 MB. A release asset TillForge stored can be scanned without uploading it again.

What is kept

Each build is read once and deleted, and only the report is kept: the app’s id and version, its settings, how each executable was built, and how each check came out. A key found in the code is kept masked, with its first few characters and its length, never in full. A scan reads at most 768 MB of uncompressed content and 4000 files, and a section it stopped short in says so. A scan that runs past 10 minutes fails. Removing a scan removes its report; the audit log keeps who started it and when.

New since the last build

A scan compares itself with the last successful scan of the same app on the same platform, matched by package name or bundle id, and marks the failing checks that passed there as new. Results read the same way as a passive run: fail, pass, doesn’t apply, or not run when a section couldn’t be read.

In CI

apps upload --wait exits 1 when the build couldn’t be read or a check at the --fail-on level or above fails. With --new-only, only failures the app’s last build didn’t have count, so a release fails on what it made worse.

# after the release build, before it ships
tilldev shield drill apps upload app/build/outputs/apk/release/app-release.apk --wait --new-only --fail-on high

A workspace can start 30 scans an hour and have 3 uploading, waiting or being read at once.

Prove your rules still fire

A defense drill tests your detection, not your servers. It takes one TillTell rule, replays the rule’s own smallest test that fires into this workspace’s security stream, and times how long TillTell takes to record the finding and how long the response takes. Nothing leaves Till and no target is needed. Start one under Shield → TillDrill → Defense drills, from the CLI, or from the API.

• The drill sends at most 200 events, 20 ms apart. Each is labelled as a drill and signed by Till. An event that claims to be a drill without that signature is handled as real traffic, so the label can’t be used to hide an attack.
• Drill events are correlated apart from real traffic and from every other drill. They can’t set off a real detection or mask one. The findings they make are drill findings in drill incidents: they never alert and stay out of the backlog.
• Every playbook step a drill finding starts is simulated. Nothing is blocked, revoked or isolated.
• Only rules over the event stream can be drilled. A draft rule records nothing and a paused one isn’t running, so neither can be drilled. A rule that groups by project writes its events to a project you pick, or the workspace’s oldest.

Proof on the coverage map

A detected drill marks the rule’s ATT&CK techniques as proven on TillTell’s coverage map for 90 days. The proof belongs to the rule version it drilled: change the rule and the proof goes until it is drilled again. A rule moved back to draft proves nothing.

In CI, defense <rule-id> --wait exits 1 when the drill is missed or refused, so a change that breaks detection fails before it ships. Waiting stops after 20 minutes, and the drill carries on.

The ports your cloud addresses answer on

Every other drill tests a site. An exposure scan tests a machine: one public address, and the ports it answers on. The address is never typed in. Addresses come from the cloud accounts you connect under Posture, and the account that lists an address is the proof that it is yours. Read them under Shield → TillDrill → Exposure.

Where an address comes from

• A sweep reads each connected account’s own inventory for the public addresses it holds. Reading an inventory touches nobody’s network.
• An address arrives with scanning off. You turn it on for the addresses you want watched, daily or weekly. An address the account stops holding is retired.
• A scan reads the account again before it makes a single connection, and is refused unless the account confirmed the address in the last 7 days. No other proof allows an exposure scan, and this proof allows nothing else.
• A workspace holds up to 250 addresses.

What a scan does

It opens a TCP connection to each of 105 well-known ports, 8 at a time and 40 ms apart, reads up to 512 bytes of whatever the service announces on connection, completes the handshake where the port speaks TLS so the certificate can be read, and closes. One scan makes at most 140 connections and stops after 4 minutes.

Scanning is off for a new address. A scheduled scan that finds a new failure at medium or above sends a security alert; a scan you start by hand never does. A workspace can have 3 scans waiting or running, start 60 a day, and scan one address once every 15 minutes. Stop ends a scan within seconds and keeps what it saw.

From the terminal

tilldev shield drill targets add app.example.com
tilldev shield drill targets add https://api.example.com/v1
tilldev shield drill targets show <target-id>     # the record and the file that prove it
tilldev shield drill targets check <target-id>    # exits 1 while no proof holds
tilldev shield drill targets                      # verified, lapsed or unverified
tilldev shield drill targets rm <target-id>

tilldev shield drill targets schedule <target-id> daily   # or weekly, or off
tilldev shield drill run <target-id> --wait               # exits 1 on a failing check at medium or above
tilldev shield drill run <target-id> --wait --fail-on high
tilldev shield drill runs --target <target-id>
tilldev shield drill runs show <run-id> --all             # every check, not only what needs attention
tilldev shield drill checks

tilldev shield drill active <target-id> --wait             # asks the target directly, reading only
tilldev shield drill targets active <target-id> weekly     # or daily, or off
tilldev shield drill stop <run-id>                        # an active run stops within seconds

tilldev shield drill targets intrusive <target-id> on      # record your authorisation; it expires after 90 days
tilldev shield drill targets intrusive <target-id> window add --day Sun --start 02:00 --minutes 120 --tz Africa/Kigali
tilldev shield drill targets intrusive <target-id> schedule weekly   # runs inside a window; or daily, or off
tilldev shield drill intrusive <target-id> --wait          # runs now, only inside an open window with authorisation on

tilldev shield drill regions                              # where latency and load run from, and their addresses
tilldev shield drill latency <target-id> --wait           # exits 1 on a failing check at medium or above
tilldev shield drill latency <target-id> --regions africa-west,europe-west --budget 600
tilldev shield drill targets latency <target-id> --schedule hourly --budget 800 --regions all
tilldev shield drill load <target-id> --peak 100 --duration 120 --path /health --wait
tilldev shield drill load <target-id> --peak 300 --duration 300 --shape steps --abort-errors 5 --abort-p95 2000 --yes
tilldev shield drill stop <run-id>                        # a load drill keeps what it measured
tilldev shield drill runs --profile load

tilldev shield drill apps upload app-release.apk --wait   # exits 1 on a failing check at medium or above
tilldev shield drill apps upload App.ipa --wait --new-only  # only checks the app's last build passed
tilldev shield drill apps releases                        # release assets TillForge stored
tilldev shield drill apps from-release <asset-id> --wait
tilldev shield drill apps                                 # newest first; --app <app-id> for one app
tilldev shield drill apps show <scan-id> --all
tilldev shield drill apps checks

tilldev shield drill defense                             # rules that can be drilled, and when each was last proven
tilldev shield drill defense tell-cred-stuffing --wait   # exits 1 when TillTell records nothing
tilldev shield drill defense show <run-id>               # time to detect and to respond

tilldev shield drill exposure sweep                      # read the connected cloud accounts for addresses
tilldev shield drill exposure                            # each address, and the ports that answered
tilldev shield drill exposure scan <address-id> --wait   # exits 1 on a failing check at medium or above
tilldev shield drill exposure schedule <address-id> weekly  # or daily, or off

A bare hostname is added as a domain, and a value starting with http:// or https:// as a URL. run --wait follows the run, prints what needs attention by section, and exits 1 when the run is refused or fails, or when a check at the --fail-on level or above fails. The level is medium unless you set it, and none never fails. active --wait, latency --wait and load --wait do the same; load asks before it starts unless you pass --yes, and Ctrl-C while it waits stops the drill. Waiting stops after 15 minutes, and the run carries on. The same operations are in the API reference under TillDrill.