Member Avatar for dloj333

A hosting site I use was breached and a landing page form is hacked. The hack does not affect my other domains or their forms.

I have reset .httaccess, swapped out the email address I use for the form, changed the PHPMAILER_master with the original, and put in a honeypot script. The hacks, bogus info coming to the email address on form, stops for a bit then continues in 3 to 2 minute intervals. any ideas to handle this.

  • 6 Contributors
  • 6 Replies
  • 203 Views
  • 5 Days Discussion Span
  • Latest Post Latest Post by john_111

Dani AI

Generated

Thread summary and focused next steps based on the posts by , , , , and .

The 2–3 minute cadence points strongly at automated POSTs rather than a hidden mailer, but confirmation is required. Verify server-side evidence first: scan web access logs for repeated POSTs to the form endpoint (capture IPs, user‑agents, timing), inspect the MTA/mail logs and mail queue to see which process/user sent mail, and list recently modified files and cron entries for unexpected changes. Note that client-side Spry or any JS checks are bypassable when bots do not run JavaScript (echoing ).

Immediate containment (do these before code changes): take the form handler offline or return 403 to POSTs, block offending IPs via the host firewall or .htaccess, disable direct PHP mail delivery temporarily (or reroute outbound mail through an authenticated SMTP relay), and rotate all hosting/FTP/database/mail passwords plus enable 2FA. Preserve logs and file timestamps for host forensics if a breach is suspected.

Server-side hardening (apply before re-enabling the form): require a server-validated CSRF/token set at page render, enforce a short minimum time-from-render check, and reject header-injection attempts. Example checks:

# reject header-injection attempts
if (preg_match("/[\r\n]/", $_POST['email'] ?? '')) { http_response_code(400); exit; }

# simple timing test (set $_SESSION['form_ts'] when rendering the page)
if ((time() - ($_SESSION['form_ts'] ?? 0)) < 3) { http_response_code(400); exit; }

Longer-term defenses: update PHPMailer/PHP, switch to authenticated SMTP, enable per-IP rate limiting (NGINX limit_req or Cloudflare/WAF), deploy fail2ban or similar to auto-block repeat offenders, consider alternatives to simple CAPTCHAs (hCaptcha, Cloudflare Turnstile or reCAPTCHA v3 as is testing), run malware scanners and compare to a clean backup, and ask the host for an incident report before trusting the environment again.

Recommended Answers

All 6 Replies

Member Avatar for rproffitt

Please expand on this. If you put up a form and someone writes a bot to send you garbage, that's not a hack job and not a hacked web page.

You may have to add some other verification to stop the garbage delivery.

Member Avatar for AndreRet

landing page form is hacked

Why would you say it is 'hacked', what happened. With more information we can assist, right now the question is very general with tons of possible options to solve.

I have reset .httaccess, swapped out the email address ....

The problem might be in your landing page code and not elsewhere, again, information is key.

bogus info coming to the email address on form, stops for a bit then continues in 3 to 2 minute intervals ...

What exactly happens and when, what info etc.

Member Avatar for Dani

Many bots are able to get around honeypots and CAPTCHAs. Try using a different honeypot as well as captcha. The latest version of ReCaptcha might not be good enough on its own anymore.

Member Avatar for david.tigner

I have lots of online submission forms. Most of them get real submissions but there's a few (1 or 2 or so out of a total of about 20-30) that I get those bogus garbage submissions. I'm in the process of upgrading ReCaptcha/php 7.4 to ReCaptcha 3/php 8.2. The form(s) in question haven't been upgraded yet but after that's completed, if the bogus submissions stop then that means ReCaptcha 3 works better than ReCaptcha (c. 2017). I can keep you posted on what I find after that upgrading.

Member Avatar for john_111

Why not give us the url of the page in question, then someone might spotted a weakness in the code that lets spammers through.

Member Avatar for john_111

If someone uses a browser with javascript deliberately switched off they will totally bypass your spry validation scripts. And the recaptcha script as well. Spry is antique code from about 2005 anyway, and some posts I saw elsewhere from about 8 years ago say it is considered useless even then.

The only js files are your spry and recaptcha scripts, the only php file is your email script.

So unless your host has confirmed a hack, forget the idea that your host and site were hacked, as there is not extra coded added to the page that would do anything.

Edited by john_111
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.