Thanks for the suggestions; unfortunately, at least so far, there's nothing cropping up in the IIS logs to give us a hint of which page is open - which suggests they're not using an insecure querystring to do the damage, but somehow managing to pass the data as form data.

Given all the sites that have been affected (at least so far) have no public write access to the database (only read), and the content management system uses a combination of passwords and session variables to prevent unwanted access, this is getting both more puzzling - and more worrying - by the minute.

ETA - The search has finished and it has brought to light another site that's been affected. This one does have some public write access to the database (bookings and whatnot), but that's run through a fairly strict injection trap to prevent unwanted SQL commands (as are any querystrings, come to that!), while the maintenance is hidden behind an NT logon, so in theory, this shouldn't be possible...