Skip to content
CWPControl Web PanelWiki

CWP Security Audit: “mod_auth_form enabled”

Updated

CWP Security Audit: “mod_auth_form enabled” – what it means and how to handle it

WHAT THE ALERT MEANS

The audit found a “LoadModule auth_form_module” reference for Apache’s mod_auth_form.
CWP does NOT use this module (in a stock CWP httpd.conf it is commented out). It is
flagged because SEO-cloaking / “casino” malware sometimes drops a trojaned
mod_auth_form.so: a fake Apache module that uses libcurl to fetch remote content and
serves it only to search-engine bots (spam links, redirects), while normal visitors
see the real site.

IMPORTANT: the alert does NOT by itself mean you are hacked. In most cases it is only a
STALE reference left in an old backup config (e.g. httpd.conf_backup) after the module
was disabled – that is a false alarm. The first step below tells you which case you are in.
Newer CWP audit versions already skip backup files (backup, .bak, *.rpmsave,
*.cwpsave), so updating CWP alone often clears a backup-only alert.


STEP 1 – THE DECISIVE CHECK: is the module ACTUALLY loaded?

Run (as root):

/usr/local/apache/bin/httpd -M 2>/dev/null | grep -i auth_form
  • NO output -> the module is NOT loaded. The warning came from a leftover line in a
    backup file (like httpd.conf_backup). This is the harmless/false-alarm
    case -> go to CASE A.
  • Output like “auth_form_module (shared)” -> the module IS loaded into the running
    Apache -> treat it as a possible compromise -> go to CASE B.

CASE A – module NOT loaded (stale backup reference / false alarm)

  1. Confirm where the line actually is: grep -rn “auth_form_module” /usr/local/apache/conf/ If the only matches are in backup files (httpd.conf_backup, *.bak, *.rpmsave,
    *.cwpsave) and NOT in the live httpd.conf, there is nothing active – just stale text.
  2. Move the old backup out of the Apache conf directory (do not leave it there): mkdir -p /root/cwp_conf_backups
    mv /usr/local/apache/conf/httpd.conf_backup /root/cwp_conf_backups/ (Adjust the filename if grep showed a different backup file.)
  3. Update CWP so the current audit, which ignores backup files, is in place: sh /scripts/update_cwp
  4. Re-run the Security Audit from the panel. The warning should be gone.
    No Apache restart is needed in this case. (Optional, for peace of mind, still run the module inspection in CASE B step 1.)

CASE B – module IS loaded (possible trojaned module)

  1. Inspect the module file. Apache’s genuine modules never contain crawler names: ls -la /usr/local/apache/modules/mod_auth_form.so
    strings -a /usr/local/apache/modules/mod_auth_form.so | grep -iE ‘googlebot|bingbot|crawler|spider|robots|casino|redirect|base64|curl_easy|http://|https://’
    • Lots of recent modification date vs the other .so files, and/or hits for
      googlebot/bingbot/crawler/casino/redirect/curl -> this is the trojan.
    • A clean stock module shows no crawler/casino/URL strings.
  2. Find which live config added the LoadModule line: grep -rn “auth_form_module” /usr/local/apache/conf/
  3. QUARANTINE the module – DO NOT DELETE IT (keep the sample for analysis): mkdir -p /root/quarantine && chmod 700 /root/quarantine
    mv /usr/local/apache/modules/mod_auth_form.so /root/quarantine/mod_auth_form.so.$(date +%F)
    chmod 000 /root/quarantine/mod_auth_form.so.*
  4. Remove (or comment out with #) the “LoadModule … auth_form_module …” line from the
    live config file(s) grep showed in step 2. Edit only the live .conf, not the backups.
  5. Test the config and restart Apache: /usr/local/apache/bin/httpd -t
    systemctl restart httpd
  6. Verify it is gone: /usr/local/apache/bin/httpd -M 2>/dev/null | grep -i auth_form # should print nothing

IF CASE B APPLIED (a trojan was confirmed) – do a wider check

  • Re-run the CWP Security Audit from the panel; make sure it now reports OK.
  • List recently changed Apache modules (anything with an odd, recent date is suspect): ls -lat /usr/local/apache/modules/ | head -20
  • Check root cron and user crons for unknown entries: crontab -l; ls -la /etc/cron.d /var/spool/cron
  • A real trojaned module means the server was accessed. Change the root password and the
    CWP admin password, and review SSH access / authorized_keys.
  • Reply to your support ticket with the quarantined file name and the “strings” output,
    and we will help you confirm the clean-up and check for anything else left behind.

NOTE

Always QUARANTINE suspected malware (move + chmod 000), never delete it outright, so the
sample can be analysed if needed. Nothing above touches your websites or databases – it
only concerns the Apache module and config.