Зараза 100% — убиваем её!
Осталось одно НО! — если зараза проникла единожды, проникнет и вторично!
Первое, что делаем — меняем все пароли доступа (т.к. скорее всего они уже у хакера в базе).
Второе, нужно анализировать логи веб-сервера и искать непосредственно дыру: как именно был внедрён бэкдор?
Дату создания и модификацию файла бэкдора подменили (бывает и не меняют — искать в логах гораздо проще).
Далее недолгий анализ, насторожил меня GET запросами вида

"/?option=com_contenthistory&view=history&list[ordering]=&item_id=&type_id=&list[select]=polygon%28%28/*!00000select*/*/*!00000from*/%28/*!00000select*/*/*!00000from*/%28/*!00000select*/concat_ws%280x7e3a,%28/*!00000select*/concat_ws%280x7e3a,0x534b4f54494e4b494e,username,password,0x505343%29/*!00000from*/fot6h_users%20where%20id%20=%20710%29%29as%20mk%29%60%60%29%60%60%29%29"

С какого это перепугу, в запросе иньекции SQL кода ?! явно используя дыру хотят чего то из базы поиметь — админские пароли, куки и т.д. и т.п.
Далее гуглим про дыры в «com_contenthistory» и сразу всё становится на свои места 🙂
Искать заплатки по данной дыре — дело хозяина джумлы, я же на скорую руку просто затыкаю любые запросы с вхождением com_contenthistory в параметры через .htaccess

RewriteCond %{QUERY_STRING} com_contenthistory
RewriteRule .* - [F]