Kiersti Esparza we've had this happen before, so we've cloned and replaced the form but we continued to see the fillouts, now coming from an 'unknown' form ID. They were also coming in from a single form at a volume of ~10k/hour which exceeded the 'limits' put in place by the rate limiting you mentioned. This was January of 2018 so maybe things are better now, but this is certainly a widespread problem that we appreciate Marketo tackling!
We've had a payload attack recently and having tried most of what you mention i can say that:
1. Honeypot. does not work. It takes seconds for someone to detect your honeypot requirement and then set their bot to post 1000s upon 1000s of forms that meet the requirement (happened in our case).
2. Changing forms is not working, bc if the bots go directly into the database via form submission link they don't care about the actual form ID
3. CAPTCHA. we've tried regular. See #2
i'm currently researching this problem in more detail but for now i see 2 possible options:
1. drop using marketo forms
2. employ a team of developers to implement some means of protecting the form from backend
both options will require considerable time, $$ and energy
Re: 2: You must turn on the corresponding Treasure Chest option, then an active form ID is necessary for a post to be processed. Yes, the attacker can still get or guess a valid ID, but it's not true that any ID will work.
Re: 3: reCAPTCHA works quite well. You can't expect it to stop the form post completely in this environment. Instead, you tombstone all failing leads prior to any other processing, then delete them. Managing the order of operations is essential.
but my IT department warned me that this won't solve the problem entirely
I don't know what they're referring to, because if "the" problem is automated posts that don't pass reCAPTCHA, and you are able to use reCAPTCHA for your audience, then it does solve the problem. No, it doesn't stop the leads from being initially created, but you don't get charged for leads that are deleted promptly.
for example, we've had recent case with a webinar connected via GTW. Bc of the multiple spam submits per second the connection fell down so the real people were not able to register.
i can't say it's a disaster but obviously it's not something i'd like to solve on a Saturday night
all in all, i can live with t but i would prefer not to if there was a way
Did that happen because you were automatically adding them to a program before validating the reCAPTCHA? The idea is the reCAPTCHA validation must happen before all other campaigns -- the lead should be sorted into any other flows/programs/lists if they may have failed the test.
Adchoices