Pada era Digital ini, serangan terhadap server dapat terjadi kapan saja, bahkan di waktu yang tidak terduga pada dini hari sekitar jam 1 pagi ada chat masuk dari teman saya yang intinya dia meminta tolong karena servernya telah di serang atau Compromised, okelah karena pada saat itu saya sedang ngopi santai dan langsung menyalakan monitor untuk melakukan checking dan analisys.
jadi langsung saja saya login ke VPS-nya dengan menggunakan user root karena memang beberapa kali server dia ini jebol karena memang didalamnya terdapat banyak sekali domain dan sempat dulu juga saya juga ikut membantu handle dan melakukan restorasi.
Hal pertama pada saat melakukan Incident Response kita fokus pada LOG, karena ini adalah operating sistem linux dan kebetulan yang sudah integrasi dengan cpanel jupiter jadi semua access log webserver itu disimpan pada directory /etc/apache2/logs/domlogs/ dan karena kata teman saya ini curiga mereka pegang akses root jadi untuk mem-validasi kita bisa menggunakan command last
Dan disini jika dilihat lastlogin pada IP address yang menggunakan user root aman atau tidak ada IP lain selain IP address yang memang wewenang pada VPS tersebut jadi bisa dipastikan attacker tidak mendapatkan akses root. untuk selanjutnya kita akan lebih fokus pada analisys untuk mengetahui attacker masuk dari mana dan backdoor apa saja yang mereka upload di server.
Karena memang beberapa website di build menggunakan PHP dengan tech stack laravel dan CMS wordpress, jadi saya langsung melakukan filtering file yang mempunyai indikasi backdoor dengan menggunakan find command
Terlihat dari outpunya banyak sekali PHP backdoor yang sudah di tebar oleh attacker dan pada saat dilakukan scanning dari md5 checksum pada salah satu backdoor hasilnya banyak sekali resultnya
hall ini bisa kita jadikan acuan pada saat melakukan log analisys, karena attacker menebar PHP backdoor / webshell memiliki pola yang sama yaitu diletakkan pada direktori /.well-known/463asda646d/ dan sepertinya attacker menggunakan auto mass generate unutk membuat folder serta file index.php
masuk pada directory /etc/apache2/logs/domlogs/namauser untuk monitoring access log / request pada webserver karena banyaknya domain kita tidak mungkin cek satu persatu jadi kita langsung saja filter request hanya pada path ‘/.well-known/463asda646d/index.php‘ dan ditemukan salah satu domain yang pertama kali infected anggap saja domain.xyz karena jika dilihat dari timestampnya attacker pertama kali akses pada 26/Sep/2024 jam 07:43:44 pagi
kita disini akan fokus pada domain.xyz karena dari IOC(indicator of compromised) attacker masuk melalui domain tersebut, jadi kita akan cek archive lognya pada 26 september pagi yang berada pada directory /home/log/ dan ada file yaitu domain.xyz.-Sep-2024.gz dan domain.xyz.-ssl_log-Sep–2024.gz dimana perbedaan dari 2 file tersebut yaitu pada file ssl_log request dari client menggunakan https atau TLS begitupun sebaliknya
disini setelah saya melakukan filterin dan greping menemukan IP yang mencurigakan yaitu 104.28.215.133 yang mengakses endpoint /wp-content/plugins/aa3d742778e9f335ec234e10ac868df1/get_index.php dengan response status 200
nah disini kita menemukan data yang berharga atau kalo dalam digital forensic disebut sebagai artifact, nah kita sudah menemukan salah satu IP attacker disini kita bisa dengan mudah identifikasi dari IP address tersebut pada log file
dan pada saat melihat accessnya pada IP 104.28.215.133 yaitu pertama dia melakukan request ke wp-login dan kemudian melakukan redirect ke endpoint wp-admin/plugin-install.php
Disini saya langsung konfirmasi pada teman saya, yaitu bagaimana dia melakukan konfigurasi pada wordpress dan apakah theme/plugin yang di install bersifat nulled serta bagaimana passhprase credentialnya apakah rumit atau tidak dan yang mengejutkan disini kata dia wordpress pada domain tersebut belum digunakan dan hanya hasil dari extract sebuah wp zip tanpa melakukan konfigurasi apapun.
sempet berfikir bagaimana attacker ini mendapatkan akses, setelah menghabiskan satu batang rokok akhirnya terfikir yaitu jika wordpress tanpa konfigurasi memang bisa user melakukan manual installation yaitu dengan mengakses pada endpoint wp-admin/setup-config.php jadi disini saya menggali lebih dalam pada log file yang ada
dan benar saja asumsi tadi disini attacker memperoleh initial access dengan melakukan default installation pada wordpress sekitar jam 7 pagi dan disitu juga terlihat ada request ke /index.php/2024/09/26/hello-world/ dimana page hello-world merupakan default page dari wordpress saat selesai instalasi
Disini terlihat timestamp pada file wp-config.php di jam 07:07 pagi bisa diambil kesimpulan jika analisys pada log file tersebut valid. Disini bagaimana attacker bisa melakukan instalasi tanpa mengetahui credential database yaitu dengan membuat suatu instance remote mysql pada server C2 mereka
Terlihat pada IP 194.163.155.171 dan port 443 yang merupakan remote database dari server attacker, attacker sangat cerdik dimana seharusnya request ke port selain 80 dan 443 di block oleh outbound firewall dari sini attacker melakukan setup MySQL pada port 443 yang digunakan untuk bypass pada firewall
pada saat dilakukan enumeration dan banner grabbing menggunakan nmap, benar saja di server attacker, port 443 running service MySQL
Kesimpulan
disini kita sudah membahas bagaimana melakukan Incident Response pada suatu server yang compromised, melakukan Incident Response sendiri bisa sulit bisa juga mudah tergantung dari setup server, banyaknya database, service dan juga bagaimana konfigurasi-nya bahkan ada tim khusus untuk melakukan hal semacam ini. Tetapi hal-hal seperti ini wajib dikuasai oleh sysadmin atau devops engineer dan orang-orang yang memang bertugas untuk menghandle suatu server dan teruntuk developer pastikan untuk selalu melakukan pendekatan keamanan pada source code yaitu dengan melakukan secure coding dan menerapkan best-practice dari tech stack yang digunakan. dan jangan lupa terus belajar dan melakukan eksplorasi 🙂
“Learning is never done without errors and defeat.” -Vladimir Lenin