A Joomla 6 security strategy should not be reduced to selecting a single firewall extension.

A compromised Joomla website can continue to appear operational while attackers use it to create thousands of hidden URLs, inject Japanese-language SEO pages, alter .htaccess, create administrator accounts, insert malicious JavaScript, install PHP backdoors or redirect selected visitors.

Google specifically identifies the Japanese Keyword Hack as a form of website compromise in which attackers create pages containing Japanese text, often in randomly generated directories, to manipulate search visibility and monetize traffic. Google also notes that attackers may add themselves as Search Console owners. (Google for Developers)

This makes Japanese SEO spam particularly important for Joomla administrators because the visible Joomla homepage may look normal while the compromise exists elsewhere in the filesystem, database, URL structure or administrator configuration.

The research therefore proposes a Joomla 6 Defense-in-Depth Architecture

Research White Paper Joomla 6 Web Application Firewall, Japanese Keyword Hack Defense, Malware Detection and Secure VPS Architecture

Research date: September 21, 2026
Scope: Joomla 6, VPS-hosted SME websites, ecommerce, SEO-spam incidents, Japanese keyword hacks, WAFs, malware detection, monitoring and recovery
Strategic organizations: IAS-Research.com, KeenComputer.com and KeenDirect.com

Executive Summary

A Joomla 6 security strategy should not be reduced to selecting a single firewall extension.

A compromised Joomla website can continue to appear operational while attackers use it to create thousands of hidden URLs, inject Japanese-language SEO pages, alter .htaccess, create administrator accounts, insert malicious JavaScript, install PHP backdoors or redirect selected visitors.

Google specifically identifies the Japanese Keyword Hack as a form of website compromise in which attackers create pages containing Japanese text, often in randomly generated directories, to manipulate search visibility and monetize traffic. Google also notes that attackers may add themselves as Search Console owners. (Google for Developers)

This makes Japanese SEO spam particularly important for Joomla administrators because the visible Joomla homepage may look normal while the compromise exists elsewhere in the filesystem, database, URL structure or administrator configuration.

The research therefore proposes a Joomla 6 Defense-in-Depth Architecture:

Edge WAF → VPS Firewall → Nginx → Joomla WAF → Vulnerability Management → Malware Detection → File Integrity → Logging/Monitoring → Backup/Recovery

Within that architecture:

• Securitycheck Free provides a free Joomla-native WAF and vulnerability scanner.
• Securitycheck Pro extends this with malware scanning, file-integrity monitoring, advanced WAF controls and centralized management. (Joomla! Extensions Directory™)
• HTProtect combines a self-updating firewall, .htaccess hardening, malware scanning, extension updates and integrity/account monitoring. (Joomla! Extensions Directory™)
• Admin Tools Core remains useful for Joomla hardening, but its commercial Professional edition provides the additional security-oriented features. (Joomla! Extensions Directory™)
• Cloudflare or another edge WAF can provide protection before traffic reaches the VPS.
• ModSecurity/OWASP CRS can provide an additional server/web-server security layer.
• Wazuh, Nagios, Fail2ban and file-integrity tools can provide infrastructure-level monitoring and response.

The strategic role of the three organizations is:

IAS-Research researches and architects → KeenComputer engineers, secures and operates → KeenDirect commercializes and validates the architecture through ecommerce.

1. The Problem: A Joomla Site Can Be "Working" While It Is Hacked

One of the most dangerous assumptions in CMS security is:

"The homepage loads, therefore the website is secure."

That is false.

A compromised Joomla website may have:

• a normal homepage;
• normal administrator login;
• normal articles;
• normal ecommerce functionality;

while simultaneously containing:

• hidden spam pages;
• malicious PHP files;
• unauthorized administrators;
• modified templates;
• malicious database records;
• injected JavaScript;
• rogue .htaccess rules;
• SEO doorway pages;
• backdoors;
• malicious redirects.

Joomla's own security documentation recommends a systematic recovery process including reviewing logs, vulnerable extensions, administrator access, filesystem changes, suspicious files and server configuration after compromise. (Joomla Documentation)

Therefore:

Security must detect both attacks and unauthorized changes.

2. What Is the Japanese Keyword Hack?

The Japanese Keyword Hack is an SEO-focused website compromise.

Google describes the attack as typically creating new pages containing Japanese text in randomly generated directory names. These pages can contain affiliate links to stores selling counterfeit products and can be indexed by search engines. Attackers may also add unauthorized Search Console ownership. (Google for Developers)

Conceptually:

Attacker │ ▼ Joomla vulnerability │ ▼ Unauthorized access │ ├───────────────┐ ▼ ▼ PHP backdoor Database/file modification │ │ └───────┬───────┘ ▼ Spam page generation │ ▼ Japanese keyword pages │ ▼ Google crawls pages │ ▼ Search results │ ▼ Attacker monetization

This is not simply "SEO spam."

It is evidence that the website's security boundary has been compromised.

3. Japanese Keyword Hack Use Case #1 — Random Japanese Directories

A Joomla site may suddenly contain URLs resembling:

/example-site.com/ random-directory/ Japanese-content

The exact URLs and directory names vary.

The important forensic signal is:

Unexpected URL structures containing content that the site owner never created.

Google specifically describes randomly generated directory names as characteristic of Japanese Keyword Hack incidents. (Google for Developers)

Security controls

Detect with:

• web logs;
• filesystem monitoring;
• Joomla database inspection;
• Google Search Console;
• sitemap comparison;
• vulnerability scanning;
• malware scanning.

4. Japanese Keyword Hack Use Case #2 — Fake Product Pages

A compromised website can contain pages designed to rank for searches related to:

• branded products;
• counterfeit goods;
• commercial keywords;
• shopping terms;
• unrelated Japanese-language searches.

The attacker is exploiting the reputation and domain authority of the legitimate site.

The Joomla site becomes an SEO distribution platform.

Google describes this pattern as hacked content designed to manipulate search results. (Google for Developers)

5. Japanese Keyword Hack Use Case #3 — Cloaking

A particularly dangerous variation is cloaking.

The attacker may attempt to show:

Normal visitor ↓ Normal Joomla page

while presenting:

Search crawler ↓ Spam content

Google defines cloaking as presenting different content to users and search engines with the intent to manipulate search rankings. Google also notes that hackers commonly use cloaking to make compromises harder for site owners to detect. (Google for Developers)

Therefore simply browsing the website is insufficient.

A security assessment should compare:

• normal HTTP responses;
• crawler-visible responses;
• source HTML;
• redirects;
• canonical URLs;
• metadata;
• dynamically generated content.

6. Japanese Keyword Hack Use Case #4 — Hidden PHP Backdoor

The SEO pages may not be the original attack mechanism.

An attacker could first install persistence:

Joomla exploit ↓ PHP backdoor ↓ Persistent access ↓ Spam generator ↓ Thousands of URLs

Removing the visible Japanese pages without removing the backdoor can result in reinfection.

This is why Joomla's recovery documentation recommends looking for hidden backdoors and suspicious files rather than simply deleting visible spam. (Joomla Documentation)

7. Japanese Keyword Hack Use Case #5 — .htaccess Manipulation

Attackers may modify web-server configuration to:

• redirect users;
• alter responses;
• hide malicious directories;
• create conditional behavior;
• route traffic through malicious pages.

Therefore .htaccess should be treated as a security-sensitive asset.

HTProtect specifically emphasizes .htaccess hardening, including preventing PHP execution in upload directories and protecting sensitive files. (Joomla! Extensions Directory™)

8. Japanese Keyword Hack Use Case #6 — Unauthorized Administrator

Another important attack path is creation or modification of administrator accounts.

An attacker who obtains administrative privileges may not immediately deface the website.

Instead:

Compromise ↓ Create administrator ↓ Remain hidden ↓ Wait ↓ Inject SEO spam ↓ Re-enter after cleanup

This makes administrator auditing essential.

HTProtect documents monitoring for unauthorized Super Users and changed passwords, while Securitycheck Pro provides administrator protection and failed-login monitoring. (Joomla! Extensions Directory™)

9. Japanese Keyword Hack Use Case #7 — Search Console Takeover

Google has documented cases where attackers add themselves as Search Console owners during Japanese Keyword Hack attacks. (Google for Developers)

Therefore recovery should include:

• Google Search Console ownership review;
• removal of unauthorized users;
• verification-token inspection;
• sitemap review;
• security issues review;
• indexed URL review.

10. Japanese Keyword Hack Use Case #8 — Database Injection

Not every unwanted page must exist as a physical HTML/PHP file.

An attacker can potentially manipulate:

• Joomla articles;
• custom fields;
• modules;
• menus;
• metadata;
• extension tables;
• template settings;
• configuration values.

Therefore:

Filesystem scanning alone is insufficient.

A proper investigation needs both:

Filesystem + Database + Web logs + Joomla configuration + Search-engine evidence

11. Japanese Keyword Hack Use Case #9 — Malicious JavaScript

Google's hacked-content guidance identifies code injection as another type of hacked content, including malicious JavaScript and iframes. (Google for Developers)

Potential locations include:

• templates;
• modules;
• articles;
• custom HTML;
• third-party extensions;
• database records;
• injected PHP output.

This makes a malware scanner useful, but it also reinforces the need for file-integrity monitoring.

12. Japanese Keyword Hack Use Case #10 — Reinfection

This is one of the most important use cases for a security service.

Imagine:

Day 1: Japanese SEO spam discovered Day 2: Spam pages deleted Day 3: Website looks clean Day 7: Japanese pages return

This usually indicates that the original compromise was not completely eliminated.

Possible persistence points include:

• malicious PHP;
• cron jobs;
• administrator accounts;
• compromised extension;
• modified template;
• database injection;
• .htaccess;
• server credentials;
• hosting credentials.

Joomla's recovery documentation specifically warns about hidden hacks and backdoors causing reinfection. (Joomla Documentation)

13. Why a WAF Alone Cannot Solve the Japanese Keyword Hack

This distinction is fundamental.

A WAF operates primarily on requests.

A Japanese Keyword Hack may involve:

Initial exploit ↓ Backdoor installed ↓ Files modified ↓ Database modified ↓ Spam generated ↓ Search engine indexing

The WAF may successfully block future attacks but cannot necessarily identify every existing malicious file.

Therefore:

WAF = prevention/detection layer, not complete incident response.

14. Joomla 6 Security Architecture

The recommended architecture is:

INTERNET │ ▼ ┌────────────────┐ │ EDGE WAF/CDN │ │ Cloudflare etc │ └───────┬────────┘ │ ▼ ┌────────────────┐ │ UFW │ │ VPS Firewall │ └───────┬────────┘ │ ▼ ┌────────────────┐ │ NGINX │ │ TLS / Headers │ │ Rate Controls │ └───────┬────────┘ │ ▼ ┌────────────────┐ │ Joomla 6 │ └───────┬────────┘ │ ┌────────────┼────────────┐ ▼ ▼ ▼ Securitycheck HTProtect Admin Tools │ │ │ └────────────┼────────────┘ ▼ ┌─────────────────────┐ │ Malware / Integrity │ │ / Vulnerability │ └──────────┬──────────┘ │ ┌───────────┼───────────┐ ▼ ▼ ▼ Wazuh Nagios Logs │ │ │ └───────────┼───────────┘ ▼ Backup / Recovery

15. Free Joomla Security Tools

Securitycheck Free

The current Joomla Extensions Directory listing identifies Securitycheck 5.1.0 as free and Joomla 6 compatible.

Its documented features include:

• WAF;
• SQL injection protection;
• XSS protection;
• LFI protection;
• IPv4/IPv6;
• blacklist/whitelist;
• attack logging;
• suspicious-pattern detection;
• session protection;
• file/folder permissions checking;
• .htaccess protection;
• vulnerability scanning. (Joomla! Extensions Directory™)

This makes it a strong candidate for a no-cost Joomla-native WAF.

16. HTProtect

HTProtect currently lists Joomla 6 compatibility and provides a broader security package.

Its documented functionality includes:

• self-updating firewall;
• .htaccess hardening;
• automatic extension updates;
• malware scanning;
• webshell/backdoor detection;
• malicious JavaScript detection;
• file-integrity monitoring;
• unauthorized Super User detection;
• security feeds. (Joomla! Extensions Directory™)

This makes HTProtect particularly relevant to the Japanese Keyword Hack problem, because it addresses more than HTTP request filtering.

17. Securitycheck Pro

Securitycheck Pro is the commercial evolution of Securitycheck.

The current JED listing identifies Joomla 6 compatibility and documents:

• advanced WAF;
• SQLi;
• XSS;
• LFI/RFI;
• CSRF;
• clickjacking;
• header manipulation;
• brute-force protection;
• dynamic blacklists;
• malware scanning;
• file-integrity monitoring;
• vulnerability detection;
• upload scanning;
• administrator protection;
• centralized remote management. (Joomla! Extensions Directory™)

The Pro documentation further describes cryptographic file-integrity baselines and malware scanning. (SCP Docs)

18. Securitycheck Free vs Pro vs HTProtect

Capability	Securitycheck Free	Securitycheck Pro	HTProtect
Joomla 6	✓	✓	✓
Joomla WAF	✓	✓	✓
SQLi	✓	✓	✓
XSS	✓	✓	✓
LFI	✓	✓	✓
RFI	Limited	✓	✓/rules
IP controls	✓	Advanced	✓
Dynamic blocking	Limited	✓	✓
Vulnerability detection	✓	✓	✓
Malware scanner	Limited	✓	✓
File integrity	Limited	✓	✓
Backdoor detection	Limited	✓	✓
Automatic extension updates	—	Automation features	✓
.htaccess hardening	✓	✓	✓
Admin account monitoring	Basic	✓	✓
Centralized management	—	✓	✓/service
Scheduled security tasks	Limited	✓	✓
Multi-site operation	—	✓	✓
Free	✓	—	✓

This comparison describes documented functionality rather than assigning product scores or rankings. (Joomla! Extensions Directory™)

19. Admin Tools Core

Admin Tools remains relevant because it is a widely used Joomla administration and hardening extension.

The current JED listing identifies version 7.9.2 as compatible with Joomla 4, 5 and 6. The free Core edition provides permission repair, administrator-directory protection and other administrative functions, while the commercial Professional edition adds security-oriented functionality. (Joomla! Extensions Directory™)

Therefore:

Admin Tools Core should not automatically be treated as equivalent to a full WAF.

Its value is particularly strong when used as part of a broader hardening strategy.

20. File Integrity Is Critical

A WAF sees requests.

A file-integrity system sees changes.

Securitycheck Pro's file-integrity feature establishes a cryptographic baseline and compares subsequent files against that baseline. (SCP Docs)

The model is:

Clean Joomla installation │ ▼ Cryptographic baseline │ ▼ Later scan │ ┌────┴────┐ │ │ Same hash Changed hash │ │ ▼ ▼ Normal Investigate

This is extremely useful for detecting:

• modified index.php;
• changed template files;
• modified plugins;
• new PHP files;
• malicious .htaccess;
• altered Joomla core files.

21. Malware Scanning

Securitycheck Pro documents malware scanning for suspicious code and known malware patterns, while HTProtect describes scanning for injected PHP, malicious JavaScript, web shells and backdoors. (SCP Docs)

A malware scanner should therefore be part of the recovery process.

However:

Detection does not prove that every malicious artifact has been found.

Forensic analysis remains important.

22. The Japanese Keyword Hack Detection Model

KeenComputer can turn the problem into a repeatable diagnostic process.

Layer A — Search Engine Evidence

Check:

• Google Search Console;
• indexed pages;
• site queries;
• unexpected Japanese URLs;
• unexpected title tags;
• unexpected descriptions;
• Search Console users.

Layer B — Web Logs

Search for:

• suspicious POST requests;
• unusual query strings;
• requests to nonexistent PHP files;
• repeated exploitation attempts;
• abnormal user agents;
• unexpected administrative requests.

Joomla's recovery documentation specifically recommends reviewing server logs for suspicious files and POST activity. (Joomla Documentation)

Layer C — Filesystem

Check:

• PHP files;
• templates;
• plugins;
• modules;
• media;
• .htaccess;
• configuration;
• recently modified files.

Layer D — Database

Check:

• articles;
• modules;
• menus;
• users;
• user groups;
• custom fields;
• extension tables;
• metadata.

Layer E — Server

Check:

• cron;
• SSH accounts;
• system users;
• Nginx;
• PHP-FPM;
• Docker;
• environment files.

23. Japanese SEO Spam Incident Response

A recommended workflow is:

INCIDENT DISCOVERED │ ▼ Preserve evidence │ ▼ Restrict exposure │ ▼ Backup / snapshot │ ▼ Analyze logs │ ▼ Identify initial compromise │ ┌─────────┼─────────┐ ▼ ▼ ▼ Files DB Accounts │ │ │ └─────────┼─────────┘ ▼ Remove persistence │ ▼ Replace compromised code │ ▼ Update Joomla/extensions │ ▼ Rotate credentials │ ▼ Install WAF/monitoring │ ▼ Validate clean installation │ ▼ Search Console remediation │ ▼ Continuous monitoring

Joomla's official recovery guidance emphasizes taking the site offline where appropriate, scanning systems with access, updating Joomla, reviewing vulnerable extensions, replacing compromised files, examining logs, changing credentials and removing unused/vulnerable extensions. (Joomla Documentation)

24. Do Not Simply Delete the Spam Pages

This is a common mistake.

Suppose:

500 Japanese spam URLs

are discovered.

Deleting the URLs may remove the symptoms.

But the real problem could be:

backdoor.php

or:

compromised plugin

or:

administrator account

or:

malicious cron

Therefore the correct question is:

How did these pages get created?

not:

How do I delete the pages?

25. Why Backups Are Not the Complete Answer

Backups are essential, but Joomla's documentation warns that compromised backups can reproduce the compromise. (Joomla Documentation)

Therefore:

Backup + Backup integrity + Known-clean restore point + Restore testing

is more useful than simply:

Backup = security

26. KeenComputer's Role

KeenComputer should turn this architecture into a professional service.

Joomla 6 Security Assessment

Discover

Inventory the website and VPS.

Assess

Identify vulnerabilities and attack surfaces.

Clean

Investigate existing compromise.

Harden

Secure:

• Nginx;
• PHP;
• UFW;
• Joomla;
• administrator;
• filesystem;
• .htaccess.

Protect

Deploy the appropriate:

• WAF;
• malware scanner;
• integrity monitoring;
• rate limiting.

Monitor

Use:

• Wazuh;
• Nagios;
• logs;
• alerts.

Recover

Maintain:

• tested backups;
• clean recovery points;
• documented procedures.

27. KeenComputer Japanese Keyword Hack Response Service

A specialized service could be:

Joomla Japanese SEO Spam & Malware Recovery

Phase 1 — Emergency containment

• preserve evidence;
• restrict access;
• snapshot;
• backup;
• prevent further damage.

Phase 2 — Investigation

• Search Console;
• logs;
• filesystem;
• database;
• users;
• cron;
• .htaccess.

Phase 3 — Removal

• malicious files;
• unauthorized accounts;
• injected database records;
• redirects;
• backdoors.

Phase 4 — Rebuild

• clean Joomla core;
• clean extensions;
• clean template;
• secure configuration.

Phase 5 — Protection

• WAF;
• VPS firewall;
• malware scanner;
• file integrity;
• monitoring.

Phase 6 — SEO recovery

• remove hacked URLs;
• inspect Search Console;
• review sitemap;
• validate redirects;
• monitor indexing.

28. IAS-Research.com's Role

IAS-Research should provide the research and architectural intelligence behind the service.

Research topics include:

• Joomla WAF effectiveness;
• SEO-spam attack patterns;
• CMS supply-chain security;
• vulnerability management;
• DevSecOps;
• WAF rule engineering;
• malware detection;
• file-integrity architecture;
• AI-assisted incident response;
• RAG-based security knowledge systems.

The result can be converted into:

• white papers;
• technical standards;
• reference architectures;
• Joomla guides;
• security checklists;
• training programs;
• assessment methodologies.

Joomla itself emphasizes that there is no single security configuration suitable for every environment and that administrators need to understand their web-server infrastructure or obtain experienced assistance. (Joomla Documentation)

29. KeenDirect.com's Role

KeenDirect provides the commerce and application proving environment.

The same security architecture can be applied to:

• Magento;
• WooCommerce;
• Joomla ecommerce;
• OpenCart;
• B2B ecommerce.

This is important because the underlying architecture can become:

CMS + Ecommerce + VPS + WAF + Monitoring + DevSecOps

rather than a Joomla-only product.

30. Three-Organization Strategic Model

IAS-RESEARCH.COM │ Research / Architecture / Innovation │ ▼ Security Reference Architecture │ ▼ KEENCOMPUTER.COM │ Engineering / Security / Operations │ ┌────────────┼────────────┐ ▼ ▼ ▼ Joomla WordPress Magento │ │ │ └────────────┼────────────┘ ▼ KEENDIRECT.COM │ Secure Commerce │ ▼ Real Operations │ ▼ Lessons Learned │ ▼ IAS-RESEARCH

31. The Research-to-Engineering Cycle

The strategic model becomes:

Research → Architecture → Engineering → Deployment → Monitoring → Measurement → Research

This is important because security is not a one-time project.

A Joomla installation changes continuously:

• Joomla updates;
• extensions update;
• PHP changes;
• Nginx changes;
• new vulnerabilities appear;
• new attack techniques emerge;
• search-engine policies evolve;
• customer applications change.

Therefore:

Security is an operating process, not a one-time installation.

32. Proposed KeenComputer Security Standard

KC-J6-Secure

A potential internal standard could contain:

KC-J6-01

Joomla version management

KC-J6-02

Extension vulnerability management

KC-J6-03

Administrator security

KC-J6-04

VPS hardening

KC-J6-05

WAF deployment

KC-J6-06

Malware detection

KC-J6-07

File-integrity monitoring

KC-J6-08

Japanese SEO-spam detection

KC-J6-09

Search Console monitoring

KC-J6-10

Logging and SIEM

KC-J6-11

Backup and recovery

KC-J6-12

Incident response

KC-J6-13

Continuous security review

33. The Security Decision Framework

Rather than asking:

"Which WAF is best?"

the SME should ask:

Question 1

Is the website currently compromised?

Question 2

What Joomla and extension vulnerabilities exist?

Question 3

Where is the website hosted?

Question 4

Is there an edge WAF?

Question 5

Is the VPS hardened?

Question 6

Does the Joomla layer have a WAF?

Question 7

Are file modifications detected?

Question 8

Are administrator changes monitored?

Question 9

Are logs centralized?

Question 10

Can the business recover from a compromise?

This produces a security architecture decision, rather than a product purchase decision.

34. Overall Findings

The research produces several important findings.

Finding 1 — Japanese Keyword Hack is an intrusion indicator

Japanese SEO pages should be treated as evidence of compromise, not merely an SEO problem. Google explicitly describes the Japanese Keyword Hack as a hacked-site pattern. (Google for Developers)

Finding 2 — WAF is necessary but insufficient

A WAF can block malicious requests but cannot guarantee detection of existing backdoors, compromised files or database manipulation.

Finding 3 — File integrity is essential

Unauthorized file modification is an important signal in CMS compromise. Securitycheck Pro and other modern Joomla security tools address this directly. (SCP Docs)

Finding 4 — Vulnerability management is fundamental

A vulnerable extension can become the initial entry point.

Finding 5 — Recovery is part of security

A security architecture without tested recovery remains incomplete.

Finding 6 — Joomla security must extend to the VPS

Joomla cannot be secured independently from:

• PHP;
• Nginx;
• Linux;
• SSH;
• firewall;
• DNS;
• backups;
• credentials.

Joomla's own security documentation makes this broader infrastructure point explicitly. (Joomla Documentation)

35. Recommended Architecture for an SME Joomla 6 VPS

For a free/low-cost architecture:

Cloudflare ↓ UFW ↓ Nginx ↓ Securitycheck Free or HTProtect ↓ Malware / Integrity monitoring ↓ Wazuh/Nagios ↓ Off-site backups

For a professional managed deployment:

Cloudflare / Edge WAF ↓ UFW ↓ Nginx ↓ Joomla 6 ↓ Securitycheck Pro / HTProtect ↓ Malware Scanner ↓ File Integrity ↓ Wazuh ↓ Nagios ↓ Off-site Verified Backups ↓ Incident Response Plan

36. Final Strategic Conclusion

The purpose of this research is not ultimately to declare one Joomla extension the winner.

The deeper conclusion is:

Japanese Keyword Hacks demonstrate why Joomla security must be engineered as a layered system.

A website can have a functioning homepage while attackers maintain hidden access, generate thousands of spam pages, manipulate search results and retain persistence.

Consequently, the security model should be:

Prevent → Detect → Respond → Recover → Learn

And the organizational model should be:

IAS-Research

Research → Threat Modeling → Architecture → Innovation

KeenComputer

Assess → Engineer → Secure → Monitor → Recover

KeenDirect

Deploy → Commercialize → Operate → Measure

The resulting business proposition is therefore:

IAS-Research develops the security knowledge and architecture; KeenComputer turns that architecture into secure, monitored infrastructure; KeenDirect applies the architecture to real digital commerce.

That is a stronger strategic position than selling a particular Joomla WAF.

Key References

• Joomla Security Checklist — Hacked or Defaced: Joomla's official recovery guidance, including log review, vulnerable extensions, credential rotation, replacement of compromised files and investigation of backdoors. (Joomla Documentation)
• Joomla Site Recovery: official recovery principles for compromised websites. (Joomla Documentation)
• Joomla Hosting and Server Setup: permissions, server maintenance and backup/recovery guidance. (Joomla Documentation)
• Google Search Central — #NoHacked: documented Japanese Keyword Hack, cloaked-keyword hack and gibberish-hack cases. (Google for Developers)
• Google Search Central — Spam Policies: hacked content, cloaking and SEO manipulation. (Google for Developers)
• Securitycheck: current Joomla 6-compatible free WAF/security extension. (Joomla! Extensions Directory™)
• Securitycheck Pro: current Joomla 6-compatible WAF, malware, integrity, vulnerability and centralized-management suite. (Joomla! Extensions Directory™)
• HTProtect: current Joomla 6 security/firewall/malware/auto-update architecture. (Joomla! Extensions Directory™)
• Admin Tools: Joomla 6-compatible Core and Professional security architecture. (Joomla! Extensions Directory™)