Después de que OP agregó registros, quedó claro que el problema está en el exploit de ejecución remota de código para Struts 2 (CVE-2017-5638).
Algunos enlaces adicionales:
- Nuevo exploit de ejecución remota de código de Struts2 atrapado en la naturaleza.
- CVE-2017-5638:Apache Struts2 S2-045.
La solución es actualizar Struts a la versión 2.3.32 o 2.5.10.1.
He enfrentado problemas similares antes cuando era administrador de sistemas. Creo que debe distinguir si es su servidor Tomcat o su aplicación Java.
Cuando inicia Tomcat sin la "aplicación Java infectada", ¿se habilita el cron? (Me refiero a eliminar su aplicación de Tomcat e iniciarla) Si es así, entonces tiene un problema mayor, deberá verificar los scripts de inicio y cada aplicación implementada en el servidor tomcat.
De lo contrario, estamos seguros de que su aplicación es el problema.
Si ese es el caso, vaya a:
$CATALINA_BASE/webapps/your_app
Verifica la integridad de tu aplicación, ¿hay archivos adicionales que no reconozcas?
Ahora vaya al directorio webapps de su instalación de Tomcat:
$CATALINA_BASE/webapps/
En ese directorio realice:
grep -R '91.230.47.40' *
Para encontrar el posible archivo/línea de código que causa la infección, podría ser un archivo de su aplicación o uno nuevo.
¿Tienes tu código en un sistema CSV?
Cree el archivo war fuera del servidor infectado desde su repositorio CSV y haga lo siguiente:
md5sum your_app.war
Elimine su aplicación del servidor tomcat y vuelva a implementarla, verifique que esté cargando la guerra correcta a través de md5, luego verifique si se está invocando el crontab.
Si proporciona comentarios sobre estos pasos, estaré encantado de ayudarle.
Solo tuvimos que luchar contra este tipo de ataque en un servidor, se reiniciaba sobrescribiendo crontab para nuestro usuario de tomcat como se describe anteriormente. La dirección IP era idéntica. Grep de todo el directorio de aplicaciones web para la dirección IP no reveló un culpable.
En nuestro caso, no usamos struts, pero teníamos las aplicaciones "host-manager" y "manager" en aplicaciones web, y teníamos JMX habilitado/puerto abierto. Reiniciar sin esos parece haberse resuelto, por lo que mi corazonada es que la vulnerabilidad podría estar en uno de esos. Específicamente, se corrigió una vulnerabilidad de JMX en 7.0.73 que podría ser nuestro culpable (https://tomcat.apache.org/security-7.html#Fixed_in_Apache_Tomcat_7.0.73).
Otra precaución que estamos tomando ahora es restringir el acceso a wget y chmod solo a root (solo haz chmod 770 en esos binarios).