Daily Cyber Threat Brief — September 14, 2026: MikroTik RouterOS

September 14, 2026 | Cyber News | Network Security

MikroTik RouterOS: patching and compromise review belong together

Internet-facing router management deserves a fresh review after recent RouterOS warnings. This brief brings together the vendor's update guidance and national incident-response reporting, then explains how defenders can separate remediation from investigation.

This is a late edition covering disclosures from September 3-10, not a claim of a new breach today.

What is confirmed

CERT Polska reported on September 5 that attackers were exploiting a combination of RouterOS vulnerabilities against devices with SSH reachable from public networks. The team says the released fixes prevent the attacks it observed. That establishes exploitation in the reported cases; it does not establish that every exposed router was compromised. CERT Polska's incident warning.

MikroTik's September 3 bulletin lists fixes in 6.49.21, 7.23.4, 7.24.2 and 7.25 beta 3. Administrators should follow the supported release channel appropriate to their deployment, rather than treating a beta as the default production choice. The vendor advises restricting management access and reviewing unfamiliar configuration even without a warning marker. MikroTik security bulletin.

The Canadian Cyber Centre's September 10 alert reinforces the need to identify installed versions, prioritize internet-exposed SSH, apply updates and examine logs. Its version table distinguishes the RouterOS 6.x, long-term, stable and development branches. Canadian Cyber Centre alert AL26-020.

Original conceptual poster: patch status and compromise status answer different questions. Select the image to enlarge.

Explore the diagram

Start with the actual inventory and management path. Coordinate the update with the service owner. Independently review accounts, scheduled tasks and configuration changes; a successful update does not explain earlier activity.

What a warning can and cannot tell you

CERT Polska explains that the Flagged mechanism recognizes selected traces of unauthorized changes. An absent flag is not proof that the device is clean, and a flag alone does not identify which vulnerability was used. Preserve the original evidence and use the vendor's linked recovery instructions when investigating a flagged device. Read the mechanism's limits and response guidance.

A practical review for network and SOC teams

1. Create a scoped device list. Record device owner, software branch, installed version, collection time and approved management route. Resolve missing inventory before marking the fleet complete.
2. Separate exposure from exploitation. An exposed service is a risk condition. An unexplained account or configuration change is an investigative lead. Neither should be replaced with a blanket assumption about the whole fleet.
3. Assign two owners or two work items. Track the update and the evidence review separately. Record the deployed version after the maintenance window and keep investigation questions open until supported by evidence.
4. Validate legitimate changes. Compare unfamiliar accounts, scheduled jobs and tunnels with approved deployment records and trusted administrator confirmation. Preserve the before-and-after configuration and log timestamps under your evidence-handling procedure.
5. Escalate unresolved activity. Involve the network service owner and incident-response team. Isolation or recovery may interrupt connectivity; use the authorized response process and protect evidence before disruptive changes.

These operational steps are Hack Invasion's general defensive analysis, not findings about your devices. Use only authorized administrative access; no exploitation is needed to validate installed versions or review retained records.

Key takeaways

• Use current vendor guidance for the correct software branch.
• Keep patch verification and compromise investigation as separate closure criteria.
• Document uncertainty when logs or configuration history are incomplete.

Related reading

• Prioritizing vulnerabilities with exposure and business impact
• Distinguishing deployment from abuse
• Cyber News archive

Sources reviewed September 14, 2026: MikroTik (September 3), CERT Polska (September 5), Canadian Cyber Centre (September 10). No actor attribution, victim count or new September 14 incident is asserted. Material corrections will be dated.

Prioritizing Vulnerabilities with Exposure, KEV and Business Impact

Technique & Investigation of the Day · Educational, defensive guidance for authorized environments.

Why it matters

A long vulnerability list is not a remediation plan. Prioritization becomes actionable when a finding is tied to the affected asset, reachable attack surface, evidence of exploitation and the consequences of failure. A severity number is one input, not a complete ordering rule.

HACK INVASION / VISUAL FIELD NOTES

Vulnerability prioritization

Original conceptual investigation workflow. No real customer data is shown.

Explore the diagram

Vulnerability prioritization: investigation path. Validate the finding; Establish reachability; Authenticated inventory and vulnerability findings with scan time and detection method.; Assign a defensible priority; Escalate; assess containment impact; Verify remediation

Select the image to open it separately for closer reading.

Required telemetry and evidence

• Authenticated inventory and vulnerability findings with scan time and detection method.
• Vendor affected-version and remediation guidance, including prerequisites and mitigations.
• Current CISA KEV evidence and any source-supported exploitation statements.
• Asset exposure, criticality, ownership, dependencies and change-window constraints.

Before drawing conclusions, record collection scope, retention and any missing fields. Keep sensitive evidence in approved internal systems.

Step-by-step investigation

1. Validate the finding

Confirm the installed product, version and vulnerable component. Distinguish a scanner inference from verified inventory. Do not attempt exploitation to prove exposure.

2. Read the vendor guidance

Check affected configurations, fixed releases and supported mitigations. A generic CVE summary may omit a prerequisite that changes the local risk or remediation plan.

3. Establish reachability

Map actual access paths and controls with the system owner. An internet-facing hostname does not prove the vulnerable interface is reachable, and an internal host can still be exposed to important threat paths.

4. Check exploitation evidence

Use the current KEV catalog and primary advisories. Distinguish public disclosure, a public proof of concept and confirmed exploitation. Absence from KEV is not proof that exploitation has never occurred.

5. Assign a defensible priority

Combine exposure, affected configuration, business impact and confirmed exploitation with the organization’s policy. Record an owner and target date rather than publishing a context-free risk score.

6. Verify remediation

Confirm the deployed fix or mitigation and retest using approved non-invasive validation. A closed ticket is not evidence that every affected instance changed. Track exceptions with review dates.

HACK INVASION / VISUAL FIELD NOTES

Vulnerability prioritization

Original conceptual evidence checklist. No real customer data is shown.

Explore the diagram

Vulnerability prioritization: evidence checklist. Authenticated inventory and vulnerability findings with scan time and detection method.; Vendor affected-version and remediation guidance, including prerequisites and mitigations.; Current CISA KEV evidence and any source-supported exploitation statements.; Asset exposure, criticality, ownership, dependencies and change-window constraints.

Select the image to open it separately for closer reading.

Read-only investigation pseudocode

INPUT validated findings and asset inventory
JOIN product, version, exposure and owner
ENRICH with vendor guidance and verified KEV status
APPLY organization priority policy and document reasons
TRACK remediation evidence and time-bound exceptions

Test and adapt: this is illustrative pseudocode, not executable vendor syntax or a tested production detector. Validate field semantics, time boundaries and results in an authorized environment. It does not change systems.

Legitimate activity versus suspicious activity

Backported fixes, disabled components and scanner fingerprints can complicate version-only findings. Record the evidence supporting a not-affected decision. Conversely, a failed scan or compensating control with untested scope does not establish safety.

Tuning and false positives

Deduplicate repeated observations by asset and component without losing history. Separate unsupported products from routine patch work. Review exceptions after exposure or vendor guidance changes, and avoid permanent risk acceptance without an accountable owner.

Escalation, containment and documentation

Escalate urgent exposure through vulnerability and service owners. Emergency mitigation can affect availability and requires a rollback and verification plan. If evidence suggests compromise, initiate an incident investigation alongside remediation; patching alone does not resolve that question.

Close with an evidence-based disposition: explained activity, supported escalation or unresolved visibility gap. Include identifiers, times, source coverage, competing explanations and the response owner.

MITRE ATT&CK context

This is a control-improvement workflow, so no adversary technique is assigned automatically. Map a specific exploitation behavior only if incident evidence supports it.

Key takeaways

• Validate the finding: define the question before broadening the search.
• Assign a defensible priority: corroborate the explanation with independent evidence.
• Keep the observed facts, assumptions and response decisions separate.

Related articles

• LOLBins threat hunting: process context and evidence correlation
• PSIRT preparation: communicating evidence and risk
• Explore the Knowledge Base

References

• CISA: Known Exploited Vulnerabilities Catalog

Original educational workflow and conceptual diagrams for Hack Invasion. Public documentation informs source-specific details; investigation decisions require local validation.

SQL injection defense, part 3: detection, logging, and ongoing protection

Originally published in 2016 when this blog covered offensive tutorials; rewritten in 2026 with a defensive focus.

Authorization notice: All security testing must only be done on systems you own or are explicitly authorized to assess. The vulnerable-site target list this post once contained has been removed. This is the third installment of our SQL injection defense series — parts 1 and 2 covered finding and fixing injection flaws; this part covers what comes after the fix: detection, logging, and ongoing protection.

Why detection still matters after you've fixed the code

Parameterized queries eliminate SQL injection at the source — but no codebase stays fixed by accident. New code ships, dependencies change, legacy endpoints resurface, and regressions happen. A detection layer catches what secure coding misses and tells you when someone is actively probing your applications, which is intelligence worth having.

Log what matters

You can't detect what you don't record. Make sure these are captured and centralized:

• Full request details on database-backed endpoints: URL, parameters, user agent, source IP, and session identity.
• Database error events with the failing query context (logged server-side, never returned to the user): syntax errors, type-conversion failures, and permission denials.
• Query performance telemetry: execution time per query pattern. Time-based blind injection shows up as anomalous delays.
• Authentication and session events tied to the same requests, so you can correlate a probe with an account.
• WAF/edge block events — even blocked attempts are signal; a rising block rate against one endpoint means someone is working on it.

Build alerts that fire on real attacks

Turn the telemetry into detection rules in your SIEM:

• Error-rate anomalies: alert when database errors spike on an endpoint relative to its baseline — classic injection probing.
• Signature matches: flag requests containing SQL keywords, comment sequences, or stacked-query syntax in parameters that should never contain them. Tune to your application's normal input to control false positives.
• Behavioral anomalies: a single client cycling through many parameter values, unusually large result sets served to low-privilege sessions, or response-time patterns consistent with blind extraction.
• Known-bad correlation: match source IPs and request fingerprints against threat intelligence feeds of active scanners.

Ongoing protection: keep the fix fixed

• Test in legal labs continuously: DVWA, bWAPP, and WebGoat remain the right places to train your team and validate scanner coverage — never someone else's production site.
• Scan every release: integrate SAST and DAST into CI/CD so new injection flaws are caught before deployment, not after.
• Re-audit data access: periodically review database account privileges — least privilege drifts over time as features are added.
• Keep the WAF tuned: update rule sets, review what's being blocked, and investigate repeated blocks rather than ignoring them.
• Run tabletop exercises: walk through a "we're being probed" scenario so your team knows who triages the alert, who checks the code, and when to escalate to incident response.

Measure it

Track mean time to detect probing, the number of injection findings per release, and the percentage of database-backed endpoints covered by alerting. If those numbers improve quarter over quarter, your program is working.

Series wrap-up

Part 1 taught you to find injection flaws in your own applications using safe labs. Part 2 covered remediation — parameterized queries, least privilege, and layered controls. This part closes the loop: log the right things, alert on the right patterns, and keep testing so the flaw stays fixed. SQL injection is a solved problem technically; the remaining work is operational discipline.

How web shells end up on WordPress sites — and how to harden yours

Originally published in 2013 when this blog covered offensive tutorials; rewritten in 2026 with a defensive focus.

Authorization notice: All security testing must only be done on systems you own or are explicitly authorized to assess. The original post gave step-by-step instructions for planting a malicious shell on a WordPress site — that walkthrough has been removed entirely. This rewrite explains how attackers get shells onto sites so you can detect and stop them.

What is a web shell, and why do attackers want one?

A web shell is a malicious script (often PHP on WordPress hosts) that an attacker places on a compromised server. Once in place, it gives them a remote interface to run commands, browse files, and pivot to other sites on the same server. For defenders, a web shell on your server means the attacker already had a way in — the shell is the foothold, not the break-in.

How shells get onto WordPress sites

Attackers rarely start with the shell. They start with an opening, then use it to drop one. The common paths:

• Vulnerable plugins and themes. Outdated or abandoned plugins with file-upload or code-execution flaws are the single most common entry point. Attackers scan the internet for known-vulnerable versions automatically.
• Weak or reused admin credentials. Brute-forced or phished wp-admin logins give attackers the same file-editing powers the old post abused (Appearance → Editor, plugin uploads). Enforce strong passwords and MFA.
• Unrestricted file uploads. Forms or plugin features that accept uploads without strict type validation let attackers place executable scripts where the web server will run them.
• Compromised hosting neighbors. On shared hosting, a shell planted on one site can sometimes reach others — another reason to isolate sites and choose reputable hosting.
• Nulled/cracked themes and plugins frequently ship with backdoors pre-installed. Never use them.

Detection: signs of a shell in your logs and files

Catch the foothold early. Watch for:

• New or modified PHP files in uploads directories, theme/plugin folders, or odd locations (e.g., files with random names, or recently modified core files). File integrity monitoring (FIM) turns this into an automatic alert.
• Suspicious request patterns: POST requests to unfamiliar .php files, requests with encoded/obfuscated parameters, or repeated hits to a single odd URL.
• Unexpected outbound connections from the web server process — shells often "phone home" or download second-stage payloads.
• Admin activity anomalies: logins from unusual locations, new admin users you didn't create, or theme/plugin editor usage outside change windows.
• Server-side clues: processes spawned by the web server user, spikes in CPU at odd hours, or antivirus/malware scanner hits on the document root.

Hardening: make your site a hard target

• Update relentlessly: WordPress core, themes, and plugins — promptly, and remove anything unused or abandoned.
• Least privilege: file permissions that prevent the web server from writing where it shouldn't; disable the theme/plugin file editor; run PHP with functions like exec and shell_exec disabled where possible.
• Lock down uploads: restrict allowed file types, store uploads outside the web root or deny script execution in upload directories via server configuration.
• Strong authentication: MFA on all admin accounts, limit login attempts, and restrict wp-admin/wp-login access by IP where feasible.
• WAF + monitoring: a web application firewall to block known exploit patterns, plus centralized logging and FIM so tampering triggers an alert, not a surprise.
• Backups you can restore: tested, offline backups are your fastest recovery path if a shell is found — assume the whole install is untrusted and rebuild clean.

If you find a shell

Don't just delete the file — treat it as an active incident: take the site offline or isolate it, preserve logs, identify the entry point (outdated plugin? weak credentials?), rebuild from a known-clean backup or fresh install, rotate all credentials and secrets, and close the hole before going back online.

The 3-step web attack pattern — and how to break it with defense in depth

Originally published in 2013 when this blog covered offensive tutorials; rewritten in 2026 with a defensive focus.

Authorization notice: All security testing must only be done on systems you own or are explicitly authorized to assess. The original version of this post walked readers through attacking other people's websites — that content has been removed. What remains is something far more useful: understanding the pattern attackers follow so you can break it at every stage.

The attack pattern, from the defender's side

Most web compromises follow the same three phases. The 2013 version of this post inadvertently documented them from the attacker's chair. Let's flip the camera around.

Step 1: Reconnaissance — attackers map the internet

Before touching a target, attackers search at scale for exposed entry points: admin panels indexed by search engines, forgotten subdomains, and pages that reveal their technology stack. This "recon" phase is noisy by nature.

How to break it:

• Reduce your attack surface: remove or restrict indexing of admin interfaces, staging sites, and internal tools (robots.txt is a hint, not a control — use authentication and IP allow-listing).
• Monitor for reconnaissance in your logs: bursts of requests to predictable paths (login, admin, config, backup files) from a single source are a classic early indicator.
• Use external attack-surface monitoring to find what the internet sees — and close what shouldn't be public.

Step 2: Finding the entry point — attackers probe for weakness

Once a candidate page is found, attackers probe it: submitting malformed input, testing how the application handles unexpected characters, and watching error messages for clues about the underlying technology and database.

How to break it:

• Return generic error pages to users and log the details internally. Verbose stack traces and database errors are free intelligence for an attacker.
• Alert on probing behavior: repeated 4xx/5xx responses, parameter tampering, and error-rate spikes per endpoint are high-value SIEM signals.
• Harden authentication pages specifically: rate-limit login attempts, enforce MFA for admin accounts, and lock out or slow down brute-force patterns.

Step 3: Exploitation — attackers turn a flaw into access

The final step is converting a discovered weakness into access — for example, abusing an injection flaw in a login form to bypass authentication entirely. One unvalidated input, one missing control, and the attacker is inside.

How to break it:

• Fix the root cause: parameterized queries, server-side input validation, and secure session management eliminate entire classes of exploitation.
• Apply defense in depth so a single flaw isn't fatal: WAF rules, least-privilege service accounts, network segmentation, and egress filtering all raise the cost of exploitation.
• Assume breach: log authentication events centrally, alert on anomalous logins (new locations, odd hours, impossible travel), and have an incident response runbook ready before you need it.

The defender's advantage

Here's the asymmetry the original post missed: the attacker must succeed at all three steps; the defender only needs to break one of them. Reconnaissance defeated by a small attack surface, probing defeated by quiet errors and alerting, exploitation defeated by secure code and layered controls. Every step you harden compounds.

Stop thinking like the person following the three steps. Start thinking like the person who makes each step fail.

SQL injection defense: finding and fixing injection flaws in your own applications

Originally published in 2013 when this blog covered offensive tutorials; rewritten in 2026 with a defensive focus.

Authorization notice: All security testing must only be done on systems you own or are explicitly authorized to assess. Testing someone else's website without written permission is illegal in most jurisdictions — including the "vulnerable site lists" this post used to contain, which have been removed. If you find a vulnerability on someone else's site, do not exploit it; report it responsibly through the site's contact or bug bounty channel.

Why SQL injection still matters

SQL injection (SQLi) has topped vulnerability lists for over two decades, and it hasn't gone away. Attackers still probe the internet automatically for applications that concatenate user input into database queries. A single injection point can expose customer data, credentials, and entire databases. The good news: the fix is well understood, and it starts with finding the flaws in your own code before attackers find them.

Find injection flaws in your own applications — safely

Never test against live third-party sites. Instead, practice and validate your skills in legal lab environments built for exactly this purpose:

• DVWA (Damn Vulnerable Web Application) — deliberately vulnerable app with adjustable difficulty levels; ideal for learning what SQLi looks like and how defenses stop it.
• bWAPP — a buggy web app with dozens of vulnerabilities including many SQL injection variants.
• WebGoat — OWASP's interactive training app with guided SQL injection lessons and explanations.

Run these in a local VM or container, with the traffic isolated from production networks. For your own production applications, use automated scanners (DAST) and manual code review as part of your SDLC, and run authenticated assessments under a written rules of engagement.

What attacker probing looks like in your logs

Knowing what to look for is half the battle. Injection probes often leave recognizable traces:

• Requests containing SQL syntax fragments or error-triggering characters in parameters that should be plain numbers or names.
• Spikes of database error messages (syntax errors, type-conversion errors) correlated with a single client IP.
• Unusual query timing — blind injection techniques cause measurable delays, so watch for abnormal response-time patterns on database-backed endpoints.
• Exfiltration-style responses: large, unexpected result sets returned to unauthenticated or low-privilege sessions.

Feed these signals into your SIEM and alert on them — database error-rate anomalies per endpoint are one of the most reliable early warnings.

Fix and harden: the remediation playbook

• Parameterized queries (prepared statements) are the primary defense. Never build SQL by concatenating user input — pass values as parameters so the database treats them as data, not code.
• Least privilege for database accounts. Your application's DB user should not be able to drop tables or read unrelated schemas. If injection happens anyway, limited privileges contain the blast radius.
• Input validation and allow-listing as a complementary layer — validate types, lengths, and formats on the server side.
• Error handling: return generic errors to users; log the details server-side. Verbose database errors help attackers map your schema.
• WAF rules (Web Application Firewall) as defense in depth — block known injection patterns at the edge, but never treat the WAF as a substitute for fixing the code.
• Patch and scan continuously: keep frameworks and drivers updated, and re-scan after every release.

Bottom line

The vulnerable-site list this post once carried is gone, and good riddance. The defensive path is more valuable: learn injection in legal labs, instrument your logging to catch probes, and eliminate the flaw at the source with parameterized queries and least privilege. That's how you win against SQL injection — by making your own applications a dead end for it.

How Metasploit-based attacks work — and how to protect your endpoints

Originally published in 2013 when this blog covered offensive tutorials; rewritten in 2026 with a defensive focus.

The Metasploit Framework is a legitimate, widely used penetration-testing platform maintained by Rapid7. Security professionals use it — with authorization — to verify that defenses actually work. But the same framework is routinely repurposed by attackers, and understanding its attack chain at a high level is exactly what defenders need to build protections that hold up against it. This rewrite describes the attack only at the level of abstraction useful for defense: what the attacker is trying to achieve, what your telemetry should show, and how to stop it.

The anatomy of a Metasploit-based attack

A typical endpoint compromise follows a familiar chain. First, the attacker sets up infrastructure that serves exploit code — often a web page hosting browser or plugin exploits. Second, the victim is lured to that page, usually through phishing: a convincing email, message, or ad. Third, if the victim's browser or a plugin has an unpatched vulnerability, the exploit code runs and delivers a payload — a small program whose job is to connect back to the attacker and hand over control of the machine.

From the defender's perspective, the details of any single exploit module matter less than the pattern: unpatched software + social engineering + a callback to attacker infrastructure = compromise. Defenses that break any link in that chain defeat the attack regardless of which module is used.

What your telemetry should show

Modern endpoint and network monitoring can catch this attack chain at multiple stages. Look for:

• Phishing delivery: suspicious links or attachments in email, flagged by your email security gateway; users reporting unexpected messages.
• Exploitation: browser or application crashes followed by unusual child processes, process injection into legitimate applications, or memory-protection alerts from EDR.
• Callback (command and control): new outbound connections to unknown hosts on unusual ports, beaconing patterns (regular intervals), or DNS requests to recently registered domains.
• Post-exploitation: credential dumping attempts, lateral movement to other hosts, or disabled security tooling — all classic EDR alert categories.

The single most valuable investment here is a well-tuned EDR/XDR platform with alerts that someone actually reviews, backed by centralized logging so you can trace the chain end to end.

Hardening that defeats the attack chain

• Patch aggressively: operating systems, browsers, and plugins. Most Metasploit modules target known, patched vulnerabilities — timely patching removes the foothold entirely.
• Deploy EDR on every endpoint and keep it updated; pair it with application allowlisting on high-value systems.
• Practice least privilege: users should not run as local administrators day to day, which limits what a payload can do even if it lands.
• Filter email and web traffic: block malicious attachments and URLs before they reach users, and use DNS filtering to cut off callback infrastructure.
• Train users on phishing: the lures are the delivery mechanism; a workforce that reports suspicious messages shrinks the attack surface dramatically.
• Segment the network so a single compromised endpoint cannot reach everything else.

Testing your own defenses

If you want hands-on experience with these attack patterns, do it in an isolated lab: virtual machines you own, with no connection to production systems. Frameworks like Metasploit exist so defenders can validate that patching, EDR, and hardening actually stop real techniques — use them that way.

Authorization reminder

All security testing must only be performed on systems you own or are explicitly authorized to assess. Deploying exploit infrastructure or payloads against anyone else's systems without permission is illegal in most jurisdictions.

SQL injection defense, part 2: finding and fixing injection flaws in your own applications

Originally published in 2013 when this blog covered offensive tutorials; rewritten in 2026 with a defensive focus.

This is part 2 of our SQL injection defense series. The original version of this post published a list of third-party websites presented as targets for injection attacks — the kind of "target list" that serves no defensive purpose and puts real systems at risk. That list has been removed entirely and replaced with what actually protects applications: how to find injection flaws in systems you own, and how to fix them.

Never test systems you don't own

Scanning or probing a website for SQL injection without the owner's explicit permission is unauthorized access, and it is illegal in most jurisdictions — even if you never extract data and even if your motive is curiosity. There are no exceptions for "the site looked vulnerable" or "I was just testing." If you don't own it and don't have written authorization, don't touch it.

Learn and practice in legal labs

If you want to understand how injection works so you can defend against it, use environments built for that purpose. All of these are free, legal, and designed for learning:

• DVWA (Damn Vulnerable Web Application) — a deliberately vulnerable PHP application with graded difficulty levels, ideal for learning how injection manifests and how fixes change the behavior.
• bWAPP — a buggy web app with hundreds of vulnerabilities, including many injection variants, widely used in training courses.
• WebGoat — OWASP's intentionally insecure application with structured lessons on injection and other flaws.

Run these locally or in an isolated virtual machine — Docker makes this straightforward — never on shared or public infrastructure. Practice recognizing vulnerable code patterns, confirming flaws in the lab, and verifying that your fixes actually close them.

Finding injection flaws in your own applications

For systems you own or are authorized to assess, combine several approaches:

• Code review: search for SQL queries built by concatenating strings with user input. This is the root cause in the vast majority of cases. Review data-access layers, reporting endpoints, and legacy code first.
• Static analysis (SAST): run automated scanners in your CI pipeline to flag unsafe query construction before code ships.
• Dynamic testing (DAST) and authorized penetration tests: exercise the running application the way an attacker would, within the scope of your authorization.
• Bug bounty programs: if you run a public-facing application, a scoped bounty program lets vetted researchers report flaws to you instead of exploiting them.

Remediation that actually works

• Parameterized queries / prepared statements are the gold standard. User input becomes data, never executable SQL.
• Use a modern ORM or query builder with safe defaults, and avoid raw query methods unless you parameterize them.
• Least privilege: application database accounts should have the minimum permissions required. A reporting user does not need write access.
• Server-side input validation as defense in depth — never as the sole control.
• Generic error handling: never expose database errors to users; log them internally where your team can investigate.
• WAF and monitoring as compensating controls while code fixes are rolled out.

After fixing, re-test to confirm the flaw is closed, and add regression tests so it doesn't return in a future release.

If you find a flaw in someone else's system

Report it through the organization's responsible-disclosure or security contact channel. Do not demonstrate the impact, do not extract data, and do not publish details before the owner has had a reasonable chance to fix it.

Authorization reminder

All security testing must only be performed on systems you own or are explicitly authorized to assess. The labs listed above exist precisely so you can build these skills without ever touching a system that isn't yours.

How automated SQL injection tools work — and how to detect and block them

Originally published in 2013 when this blog covered offensive tutorials; rewritten in 2026 with a defensive focus.

Automated SQL injection tools are among the most common weapons attackers point at web applications. Utilities such as Havij were originally marketed to penetration testers, but in the wild they are frequently used against live sites: they probe a URL parameter, fingerprint the back-end database, enumerate tables and columns, and extract data — all with almost no manual effort from the attacker. Understanding what these tools do at a high level is essential for anyone defending a web application, because the same knowledge tells you what to look for in your logs and how to shut the attack down.

How attackers use automated injection tools

At a high level, the attacker's workflow looks like this. First, they look for pages that appear to pass values into a database — classic signs are URLs carrying parameters such as ?id=. Then they test whether the application mishandles a single quote character, which produces a database error and confirms the parameter is interpreted as part of a SQL query. Once confirmed, the tool automates the tedious work: identifying the database type, listing databases and tables, and pulling data row by row.

The point is not the tool itself. A determined attacker can do all of this by hand. The takeaway for defenders is that SQL injection is a vulnerability class, not a tool problem — if your application builds SQL queries by concatenating user input, it is exploitable regardless of which utility the attacker happens to prefer.

What the attack looks like in your telemetry

Automated injection attempts are noisy, which is good news for detection. Watch for:

• Database error noise: repeated 500 errors or SQL error messages following requests containing quote characters, SQL keywords, or comment sequences.
• Enumeration patterns: bursts of requests to the same endpoint with systematically varying parameters — the signature of automated table and column dumping.
• Anomalous timing and volume: a single parameter being hit hundreds of times in minutes, or queries that take far longer than normal because the attacker is extracting data character by character.
• WAF and IDS alerts: rule hits for UNION SELECT, information-schema access, or stacked queries, especially clustered around one IP or session.

Correlate web access logs with database and application logs. A spike in slow queries against a single endpoint, paired with 5xx responses, is a strong indicator of an active injection campaign.

Fixing the root cause

Detection helps, but the durable fix is in the code:

• Use parameterized queries (prepared statements) everywhere user input reaches the database. This is the single most effective control and it eliminates the vulnerability class.
• Apply least privilege to database accounts: the application's DB user should only have the permissions it needs — no file-system access, no command execution, no schema modifications if it only reads data.
• Validate input on the server side as defense in depth, and fail safely: return generic error pages instead of raw database errors, which hand attackers free reconnaissance.
• Keep everything patched — application frameworks, database engines, and libraries.

Defense in depth

Deploy a web application firewall (WAF) with rules tuned for injection, but treat it as a safety net, not a fix. Regularly scan your own applications with SAST and DAST tools, and include injection testing in every release cycle. If you discover that a database may have been accessed, treat it as a data-breach scenario: rotate credentials, review audit logs for what was extracted, and follow your incident-response plan.

Authorization reminder

All security testing — including scanning for injection flaws — must only be performed on systems you own or are explicitly authorized to assess. Probing third-party websites for vulnerabilities without permission is illegal in most jurisdictions, regardless of intent.

Google dorks for defenders: finding your exposed assets before attackers do

Originally published in 2013 when this blog covered offensive tutorials; rewritten in 2026 with a defensive focus.

The original post taught "Google hacking" — using advanced search operators to find exposed cameras, confidential documents, and login pages, with examples tuned for snooping on strangers' infrastructure. The technique itself isn't criminal, but the direction matters. This rewrite points the same search power at the only legitimate target: your own organization's exposure.

What Google dorks are (and why defenders should know them)

Attackers routinely use operators like site:, filetype:, intitle:, and inurl: to locate misconfigured assets indexed by search engines: exposed admin panels, backup files, unprotected documents, even open webcams. If it's indexed, assume attackers have already searched for it. Defenders should run these same queries against their own domains to see what the internet sees.

A defensive dork audit for your own domain

Run these against domains you own or are authorized to assess, then fix whatever turns up:

• site:yourdomain.com filetype:pdf confidential — internal documents that leaked into the index.
• site:yourdomain.com intitle:"index of" — directory listings exposing file trees.
• site:yourdomain.com inurl:admin — admin and login interfaces visible to the public.
• site:yourdomain.com filetype:sql OR filetype:bak OR filetype:env — database dumps, backups, and config files that should never be web-accessible.
• site:yourdomain.com inurl:webcam OR intitle:"live view" — cameras or monitoring pages accidentally exposed.

What to do with what you find

• Remove or restrict it: take down exposed files, require authentication, and block directory listings.
• De-index it: use robots.txt, noindex meta tags, and Google's removal tools so the exposure doesn't persist in the cache.
• Check access logs to see whether anyone retrieved the exposed content before you closed it — that determines whether this is a cleanup or an incident.
• Automate the audit: schedule recurring external-attack-surface scans so new exposures get caught at deployment time, not months later.

Where the line is

Searching your own assets is good hygiene. Running the same operators against someone else's infrastructure to find exploitable openings is reconnaissance — and acting on it without authorization is illegal. The 2013 version of this post blurred that line with its examples; this one draws it clearly.

Authorization disclaimer

All security testing must only be done on systems you own or are explicitly authorized to assess. Use dorking to audit your own exposure; never use it to map or probe someone else's.

SQL injection: how attackers exploit it, and how to test your own apps safely

Originally published in 2013 when this blog covered offensive tutorials; rewritten in 2026 with a defensive focus.

The original post was a list of third-party websites the author claimed were vulnerable to SQL injection, presented as targets. That list is gone — deliberately. Publishing sites as attack targets is harmful, not educational. This rewrite covers the same vulnerability from the only side that matters now: how to find it in your own applications, how to fix it, and how to learn it safely.

How attackers exploit SQL injection (defender's view)

Attackers look for places where your application passes user input into a database query unsanitized. They probe by changing how the application responds — error messages, different result counts, timing differences. Once they confirm a flaw, they use it to read, alter, or delete data, or to pivot deeper into the network. From your side, the fingerprints are: odd characters in request logs, database errors echoed to clients, and queries requesting far more data than the page should display.

Test your own apps — legally

Never test this against someone else's site. Use purpose-built vulnerable applications that exist exactly for this:

• DVWA (Damn Vulnerable Web Application) — a deliberately vulnerable PHP/MySQL app you run locally, with adjustable difficulty levels.
• bWAPP (buggy Web Application) — hundreds of vulnerable scenarios, including multiple SQL injection flavors, in one local package.
• WebGoat — OWASP's interactive lessons on web flaws with guided fixes.

Run them in an isolated VM or Docker container, offline or on a closed network, and test only what you spun up yourself. Add SAST (static analysis) and DAST (dynamic scanning) tools to your own CI/CD pipeline for continuous, authorized coverage.

Finding SQL injection in your codebase

• Search for query strings built by concatenating variables — that's the pattern injection lives in.
• Review every place user input (URL parameters, form fields, headers, cookies) reaches the database.
• Check error handling: stack traces and DB errors shown to users hand attackers a roadmap.

Fixing it permanently

• Parameterized queries / prepared statements in every data-access layer — the root fix.
• Least-privilege database accounts: the web app's DB user should read/write only the tables it needs — never admin rights.
• Stored procedures and ORMs used correctly (with binding, not string interpolation) reduce exposure.
• A WAF and query monitoring as defense-in-depth: block known injection patterns and alert on anomalous query behavior — they don't replace fixing the code.
• Patch and review regularly so fixes don't regress in future releases.

Authorization disclaimer

All security testing must only be done on systems you own or are explicitly authorized to assess. Scanning or attacking real websites for SQL injection without written permission is illegal, even if your goal is "just to check."