[DirectAdmin] Na hack, default index.php in root

[Massiefje]

Ik ben reseller van hosting voor mijn klanten. Ik gebruik daarvoor DirectAdmin (resellerhosting) die ik via een leverancier maandelijks betaal. Leverancier is (denk ik) nu niet belangrijk.

1 van de Wordpress-sites van mijn klanten is (eer)gisteren gehackt en aangepast. Dit merkte ik op, doordat er ineens een extra user was op de site (username Wordpress, met mailadres [e-mail]). Ik heb gelijk de boel nagekeken en gezien dat alle sites van deze klant aangetast waren. Dit betekent dat er php files bijgezet waren die daar niet hoorden en sommige PHP files aangetast waren.

Het opschonen ging goed. Nieuwe/schone wordpress eroverheen, WordFence gedraaid en alles was weer prima. Behalve bij 1 site...

Als ik de site/domeinnaam weggooi bij directadmin is de directory via de FTP weg. Precies zoals het hoort. Echter, als ik de domeinnaam weer toevoeg, staat er PER DIRECT een index.php in, die daar niet hoort. Als ik deze verwijder, komt hij per direct weer terug. Met aanpassen van de inhoud of het aanpassen van de rechten, staat hij gelijk weer terug.

Het lijkt alsof er een script draait op DirectAdmin die elke keer die file neerzet, echter, ik kan niet vinden waar dit gebeurt en waarom dit gebeurt.

FTP-user is verwijderd en hoofd-ftp-account is van password gewisseld, uiteraard. Alle andere sites blijven schoon (tot nu toe), dus kan ook niet via die sites komen. Deze hebben ook geen FTP toegang. SSH toegang staat niet aan. Ik kan geen andere manieren bedenken, waardoor ze eventueel op afstand die file kunnen plaatsen.

Iemand dit ooit meegemaakt en kan mij adviseren waar dit vandaan komt en hoe dit op te lossen is?

Update: Als ik onder een ander useraccount binnen DirectAdmin het domein aanmaak, dan komt daar NIET het geïnfecteerde index.php bestand te staan. Het lijkt zich dus echt binnen 1 DA useraccount te bevinden. Maar waar...?

[ Voor 6% gewijzigd door Massiefje op 19-01-2024 12:57 ]

[jugger naut]

Is het niet een cronjob die dit doet?

[Massiefje]

jugger naut schreef op vrijdag 19 januari 2024 @ 12:21:
Is het niet een cronjob die dit doet?

Dat dacht ik ook. Vergeten te vermelden. Maar CronJobs zijn leeg. Zowel voor mijn admin account als voor het gebruikersaccount.

[jugger naut]

Massiefje schreef op vrijdag 19 januari 2024 @ 12:25:
[...]


Dat dacht ik ook. Vergeten te vermelden. Maar CronJobs zijn leeg. Zowel voor mijn admin account als voor het gebruikersaccount.

Ik zou de support van de leverancier eens aanschrijven en kijken of zij iets zien. Het kunnen 101 dingen zijn namelijk.

[Massiefje]

jugger naut schreef op vrijdag 19 januari 2024 @ 12:27:
[...]


Ik zou de support van de leverancier eens aanschrijven en kijken of zij iets zien. Het kunnen 101 dingen zijn namelijk.

Ik heb al een support ticket aangemaakt. Maar kan soms lang duren. Daarom dit topic. Ik hoop dat mensen slimme ideeën hebben.

[Rensjuh]

Staat er iets in het index.php bestand waaruit je kan opmaken waar het vandaan komt?
Misschien kun je a.d.h.v. de inhoud iets gevonden krijgen over de hack en zo een oplossing vinden.

[HarryDeCowboy]

Je hebt in Directadmin ook Default Pages. Bijvoorbeeld een standaard index.php met de branding van je eigen webhostingbedrijf.
Misschien zou je daar eens kunnen kijken.

[Massiefje]

HarryDeCowboy schreef op vrijdag 19 januari 2024 @ 12:58:
Je hebt in Directadmin ook Default Pages. Bijvoorbeeld een standaard index.php met de branding van je eigen webhostingbedrijf.
Misschien zou je daar eens kunnen kijken.

Zeker een goed idee, maar daar heb ik ook al gekeken. Daar staat enkel het standaard index.html bestand.

Daarnaast zou dat een eenmalige handeling zijn: "bij aanmaken van de site, dit bestand als default plaatsen.". Dat verklaart niet waarom het bestand elke keer weer terugkomt na verwijderen. Maar dan ook echt gelijk, binnen een seconde.

[Oon]

Het enige waarmee je dit in theorie moet kunnen oplossen is de hele klant weggooien en opnieuw aanmaken, als het dan nog terugkomt betekent dat dat een andere user ook toegang heeft tot die directory, dus bijv. dat de server zelf gehackt is.

Daar doe je weinig tegen in het geval van een shared reseller pakketje dus daar moet de host dan naar kijken.

[Codemeister]

Heb je het FTP-wachtwoord al gewijzigd? Even voor de zekerheid.

[TwArbo]

Wat is de inhoud van de index.php? Wellicht kun je extra informatie vinden door via Google (of andere zoekmachines) te zoeken op de inhoud van het bestand.

Ook kun je misschien iets kenmerkends van de inhoud van het bestand via SSH door middel van grep of ack zoeken op de gehele server. Wellicht kom je dan achter een script oid wat op een manier draait.

[ Voor 40% gewijzigd door TwArbo op 19-01-2024 13:17 ]

[SG_de_Baas]

Je zou de geïnfecteerde files ook in virustotal kunnen stoppen en kijken of deze al meer vindt over de origine. Heeft me al eens eerder flink geholpen.

[Massiefje]

SG_de_Baas schreef op vrijdag 19 januari 2024 @ 13:28:
Je zou de geïnfecteerde files ook in virustotal kunnen stoppen en kijken of deze al meer vindt over de origine. Heeft me al eens eerder flink geholpen.

Goed idee. Echter, het antwoord van VirusTotal is: "No security vendors and no sandboxes flagged this file as malicious"

[AW_Bos]

Onder welke username/owner wordt het index.php bestand aangemaakt? Mogelijk geeft dat een hint?
En hoe is je PHP ingesteld? Als php-fpm?

Ik geef 9/10 kansen dan er gebruik is gemaakt van een lek in Wordpress.

[ Voor 53% gewijzigd door AW_Bos op 19-01-2024 14:32 ]

[pennywiser]

Massiefje schreef op vrijdag 19 januari 2024 @ 12:59:
[...]


Zeker een goed idee, maar daar heb ik ook al gekeken. Daar staat enkel het standaard index.html bestand.

Daarnaast zou dat een eenmalige handeling zijn: "bij aanmaken van de site, dit bestand als default plaatsen.". Dat verklaart niet waarom het bestand elke keer weer terugkomt na verwijderen. Maar dan ook echt gelijk, binnen een seconde.

Geen cronjob maar kan het dan een systemd timer zijn?

https://wiki.archlinux.org/title/systemd/Timers

Maar binnen een seconde, welk mechanisme kan zo snel checken behalve cronjobs of timers elke seconde?

[AW_Bos]

pennywiser schreef op vrijdag 19 januari 2024 @ 14:31:
[...]

Geen cronjob maar kan het dan een systemd timer zijn?

https://wiki.archlinux.org/title/systemd/Timers

Maar binnen een seconde, welk mechanisme kan zo snel checken behalve cronjobs of timers elke seconde?

Ik neig te denken aan een shell waar een botje constant op los gaat
Check vooral de acces_logs eens op de index.php en alles wat eromheen.

[Massiefje]

AW_Bos schreef op vrijdag 19 januari 2024 @ 14:29:
Onder welke username/owner wordt het index.php bestand aangemaakt? Mogelijk geeft dat een hint?
En hoe is je PHP ingesteld? Als php-fpm?

Ik geef 9/10 kansen dan er gebruik is gemaakt van een lek in Wordpress.

Dit is wat ik via FTP kan zien. Daar zie je eigenaar: ftp ftp

Echter, de andere bestanden ook allemaal...

Update: Via de filemanager van DirectAdmin zie ik username/username staan als eigenaar.

[ Voor 5% gewijzigd door Massiefje op 19-01-2024 14:38 . Reden: Extra informatie ]

[jessy100]

Massiefje schreef op vrijdag 19 januari 2024 @ 14:37:
[...]


[Afbeelding]

Dit is wat ik via FTP kan zien. Daar zie je eigenaar: ftp ftp

Echter, de andere bestanden ook allemaal...

Wat staat er in de index.php?

[AW_Bos]

En dit bestand is op 21-10-2023 aangemaakt zie ik?
Wordt dit wel aangepast? Voor hetzelfde geldt zit de hack in een ander bestand die in index wordt opgevraagd.

[ Voor 52% gewijzigd door AW_Bos op 19-01-2024 14:39 ]

[Massiefje]

AW_Bos schreef op vrijdag 19 januari 2024 @ 14:38:
En dit bestand is op 21-10-2023 aangemaakt zie ik?

Zo te zien wel ja... dat was me nog niet eens opgevallen. Alle eerdere 'besmettingen' die ik gecleand had, waren van 18-01-2024.

[pennywiser]

Zoek eens naar alle processen draaiende onder die user. Ze zijn sws via de WP voorkant binnen gekomen.

[pennywiser]

Massiefje schreef op vrijdag 19 januari 2024 @ 14:39:
[...]


Zo te zien wel ja... dat was me nog niet eens opgevallen. Alle eerdere 'besmettingen' die ik gecleand had, waren van 18-01-2024.

.htacces is van exact dezelfde tijd.

[Massiefje]

jessy100 schreef op vrijdag 19 januari 2024 @ 14:38:
[...]


Wat staat er in de index.php?

Ik wil dat bestand best posten, maar weet niet of dat mag van Tweakers?

Het lijkt erop dat het een connectie maakt via CURL naar buiten toe en daar informatie naartoe stuurt. Dit allemaal obfuscated, uiteraard, maar goed leesbaar, op zich.

[pennywiser]

Massiefje schreef op vrijdag 19 januari 2024 @ 14:40:
[...]


Ik wil dat bestand best posten, maar weet niet of dat mag van Tweakers?

Het lijkt erop dat het een connectie maakt via CURL naar buiten toe en daar informatie naartoe stuurt. Dit allemaal obfuscated, uiteraard, maar goed leesbaar, op zich.

Blokkeer als eerste dat dns IP dan even zou ik zeggen.

[AW_Bos]

Wat staat er in die htaccess?

Wat mij betreft deel je die eval() code maar, desnoods in een Pastebin zodat de virusscanner van de tweakers hier geen boord en brand in dit topic zullen gillen. maar als je eval door echo vervangt, dan zie je als het goed is het commando.

Maar heb je al iets in de logs kunnen vinden?

[ Voor 8% gewijzigd door AW_Bos op 19-01-2024 14:44 ]

[Massiefje]

AW_Bos schreef op vrijdag 19 januari 2024 @ 14:42:
Wat staat er in die htaccess?

Wat mij betreft deel je die eval() code maar, desnoods in een Pastebin zodat de virusscanner van de tweakers hier geen boord en brand in dit topic zullen gillen. maar als je eval door echo vervangt, dan zie je als het goed is het commando.

Maar heb je al iets in de logs kunnen vinden?

Pastebin is een goed idee. Hierbij het gehele index.php bestand: https://pastebin.com/nknXsULn

De .htaccess is niet zo spannend:

code:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . index.php [L]
</IfModule>

[pennywiser]

Je kan ook op laatste aangepaste bestanden checken binnen dit account. Die hack heeft files aangepast, dus welke zijn dat.

Zoiets als dit van uit de WP docroot:

code:

find $1 -type f -print0 | xargs -0 stat --format '%Y :%y %n' | sort -nr | cut -d: -f2- | head

Duurt even voor je wat ziet.

[Massiefje]

pennywiser schreef op vrijdag 19 januari 2024 @ 14:47:
Je kan ook op laatste aangepaste bestanden checken binnen dit account. Die hack heeft files aangepast, dus welke zijn dat.

Zoiets als dit van uit de WP docroot:

code:

find $1 -type f -print0 | xargs -0 stat --format '%Y :%y %n' | sort -nr | cut -d: -f2- | head

Duurt even voor je wat ziet.

Hoe voer ik dat uit? SSH Verbinding maken?

[Oid]

Massiefje schreef op vrijdag 19 januari 2024 @ 14:49:
[...]


Hoe voer ik dat uit? SSH Verbinding maken?

Yes

Ow lees in de OP dat je geen ssh mogelijkheid hebt?

[ Voor 13% gewijzigd door Oid op 19-01-2024 14:51 ]

[pennywiser]

Massiefje schreef op vrijdag 19 januari 2024 @ 14:49:
[...]


Hoe voer ik dat uit? SSH Verbinding maken?

Ja, dat moet even via SSH, en dan executen van de betreffende WP homedir of docroot, anders krijg je van de hele machines alles te zien.

En dan goed kijken naar de content van die files. Je zegt je ziet een curl, zie je die url in die files oo kweer terug bv.

Je kan ook die url even greppen met bv. een simpele

code:

grep -ir "curl_url" /

(naar je hele bak dus - of datgene waar je bij kan met deze user)

[ Voor 31% gewijzigd door pennywiser op 19-01-2024 14:55 ]

[AW_Bos]

pennywiser schreef op vrijdag 19 januari 2024 @ 14:50:
[...]

Ja, dat moet even via SSH, en dan executen van de betreffende WP homedir of docroot, anders krijg je van de hele machines alles te zien.

De TS is reseller, dus hij kan enkel in de directories van zijn eigen klanten komen.

[pennywiser]

AW_Bos schreef op vrijdag 19 januari 2024 @ 14:53:
[...]

De TS is reseller, dus hij kan enkel in de directories van zijn eigen klanten komen.

Des te beter.

[pennywiser]

Oid schreef op vrijdag 19 januari 2024 @ 14:50:
[...]


Yes

Ow lees in de OP dat je geen ssh mogelijkheid hebt?

Staat niet aan, als in dit stond niet aan dus de hack is daar niet langs geweest.

[3raser]

Wordt de gehackte website druk bezocht? Dan zijn er mogelijk meerdere bestanden geïnfecteerd die het bestand weer aanmaken als de website wordt bezocht.

[pennywiser]

Ik denk sws dat je de site even helemaal moet disablen naar buiten toe nu.

[ipsec]

In DirectAdmin heb je als reseller in de file explorer onder /domains/default/ een directory die gekopieerd wordt naar public_html (daar zit de default index.html in).
Maak je enkel het domein opnieuw aan? Of maak je de volledige user opnieuw aan?

[3raser]

ipsec schreef op vrijdag 19 januari 2024 @ 14:59:
In DirectAdmin heb je als reseller in de file explorer onder /domains/default/ een directory die gekopieerd wordt naar public_html (daar zit de default index.html in).
Maak je enkel het domein opnieuw aan? Of maak je de volledige user opnieuw aan?

Hij maakt niets opnieuw aan. Hij verwijderd of wijzigd index.php en die wordt dan direct automatisch weer aangemaakt/hersteld.

[AW_Bos]

Ik denk dat de acces-log meer duidelijkheid moet geven over wat er precies gebeurd. Ik denk aan een shell.

Als je die nu vind, dan weet je hoe het bestand steeds aangepast wordt.

[ Voor 26% gewijzigd door AW_Bos op 19-01-2024 15:14 ]

[Oid]

3raser schreef op vrijdag 19 januari 2024 @ 15:08:
[...]

Hij maakt niets opnieuw aan. Hij verwijderd of wijzigd index.php en die wordt dan direct automatisch weer aangemaakt/hersteld.

Uit de OP:

Als ik de site/domeinnaam weggooi bij directadmin is de directory via de FTP weg. Precies zoals het hoort. Echter, als ik de domeinnaam weer toevoeg, staat er PER DIRECT een index.php in, die daar niet hoort. Als ik deze verwijder, komt hij per direct weer terug. Met aanpassen van de inhoud of het aanpassen van de rechten, staat hij gelijk weer terug.

OP doet dus wel daadwerkelijk een handeling buiten index.php om.


Kan je in directadmin niet lopende processen zien? kan je daar een output van posten?

[ Voor 6% gewijzigd door Oid op 19-01-2024 15:15 ]

[pennywiser]

3raser schreef op vrijdag 19 januari 2024 @ 14:56:
Wordt de gehackte website druk bezocht? Dan zijn er mogelijk meerdere bestanden geïnfecteerd die het bestand weer aanmaken als de website wordt bezocht.

Dit is wel een goeie, het kan ook een continue call zijn vanaf 1 IP welke dit/een bepaald php scrip called en dus execute.

Dus inderdaad ook access logs @AW_Bos

[3raser]

Oid schreef op vrijdag 19 januari 2024 @ 15:14:
[...]

Uit de OP:

Als ik de site/domeinnaam weggooi bij directadmin is de directory via de FTP weg. Precies zoals het hoort. Echter, als ik de domeinnaam weer toevoeg, staat er PER DIRECT een index.php in, die daar niet hoort. Als ik deze verwijder, komt hij per direct weer terug. Met aanpassen van de inhoud of het aanpassen van de rechten, staat hij gelijk weer terug.

OP doet dus wel daadwerkelijk een handeling buiten index.php om.


Kan je in directadmin niet lopende processen zien? kan je daar een output van posten?

In diezelfde quote staat toch duidelijk:

Als ik deze verwijder, komt hij per direct weer terug. Met aanpassen van de inhoud of het aanpassen van de rechten, staat hij gelijk weer terug.

Dus zonder het domein opnieuw aan te maken wordt het bestand ook aangemaakt/gewijzigd.

[Oid]

3raser schreef op vrijdag 19 januari 2024 @ 15:23:
[...]

In diezelfde quote staat toch duidelijk:

[...]

Dus zonder het domein opnieuw aan te maken wordt het bestand ook aangemaakt/gewijzigd.

Klopt dan ook.

[AW_Bos]

De vraag is of na de domein verwijderd te hebben, er een backup wordt terug gezet?
Als de domein leeg wordt opgeleverd, en er verschijnt in no time weer hetzelfde bestand, dan vermoed ik een shell op een andere domein. Dus check de logs eens goed.

[Massiefje]

Even voor de goede orde:
- Domein aanmaken binnen het useraccount: index.php wordt geplaatst
- index.php verwijderen via FTP: index.php wordt geplaatst
- index.php aanpassen/vervangen: index.php wordt geplaatst/teruggezet

Altijd op dezelfde plek en alleen als de map klantnaam/domains/domein.nl/public_html bestaat

Er bevindt zich verder GEEN script of wordpress site meer op dit domein. De klant heeft wel andere wordpress sites binnen zijn account, maar die zijn allemaal gecontroleerd en schoon bevonden.

[Massiefje]

Ik kan binnen mijn DirectAdmin accounts geen access_logs vinden...

[pennywiser]

Massiefje schreef op vrijdag 19 januari 2024 @ 15:43:
Ik kan binnen mijn DirectAdmin accounts geen access_logs vinden...

Dan staan ze nu misschien helemaal niet aan, aanzetten eerst en dan heb je vanaf nu logs.

https://www.ipserverone.i...rror-logs-in-directadmin/

[ Voor 15% gewijzigd door pennywiser op 19-01-2024 15:46 ]

[AW_Bos]

Massiefje schreef op vrijdag 19 januari 2024 @ 15:43:
Ik kan binnen mijn DirectAdmin accounts geen access_logs vinden...

Dat is vreemd, want die zijn er gewoon. Kijk eens in je control panel van DA bij de domeinen.

[Echt niet.]

Heb je zicht op het netwerkverkeer?

[AW_Bos]

Echt niet. schreef op vrijdag 19 januari 2024 @ 15:46:
Heb je zicht op het netwerkverkeer?

Ik verwacht dat niet met een reseller-account. Je hebt daarmee enkel een overzicht over je domeinen.

[Massiefje]

pennywiser schreef op vrijdag 19 januari 2024 @ 15:45:
[...]

Dan staan ze nu misschien helemaal niet aan, aanzetten eerst en dan heb je vanaf nu logs.

https://www.ipserverone.i...rror-logs-in-directadmin/

Thanks, gevonden!

Echter, doordat ik het domein verwijderd had (uit veiligheidsoogpunt) zijn de 'oude' logfiles niet meer beschikbaar.

Bij het opnieuw aanmaken van het domein (waar index.php dus gelijk weer terugkomt) zie ik geen logfile-entries. Het komt dus niet 'van buiten', maar ergens intern.

[AW_Bos]

Massiefje schreef op vrijdag 19 januari 2024 @ 15:54:
[...]


Thanks, gevonden!

Echter, doordat ik het domein verwijderd had (uit veiligheidsoogpunt) zijn de 'oude' logfiles niet meer beschikbaar.

Bij het opnieuw aanmaken van het domein (waar index.php dus gelijk weer terugkomt) zie ik geen logfile-entries. Het komt dus niet 'van buiten', maar ergens intern.

Waar kijk je? Want de tar.gz bestanden worden 's nachts pas gegenereerd, en tot die tijd moet je in DA zelf kijken. Als je een bestand op die domein zelf bezoekt, dan moet je jouw log-entry gewoon zien staan. Zelf al is het een simpele afbeelding.

[ Voor 9% gewijzigd door AW_Bos op 19-01-2024 16:18 ]

[jurroen]

Hoewel Virustotal 'm niet flagged, is dat PHP bestand wel (een deel van) malware. Je hebt aangegeven dat het resellerhosting is. Draait die DirectAdmin server ook de mail van jouw betreffende klant?

Zo nee, maak een backup in DirectAdmin (en download deze, zit in $HOME/backups), een kopie van de files binnen het betreffende account en een database dump die je lokaal opslaat. Noteer eventuele custom DNS records. Verwijder de klant van je reselleraccount en maak deze opnieuw aan. Let op dat dit ook alle mail onder het account verwijderd.

Ik ben wel benieuwd wat de hoster qua techniek heeft om dit te voorkomen. CloudLinux kan voorkomen dat een 'breached' account kan overspringen (LVE, CageFS). Een tool als Imunify360 zou dit soort infecties toch wel moeten detecteren en op z'n minst alarmbellen af laten gaan bij de hoster.