Level 2 — 보안 입문과 공격 스킬 기초

Level 2의 시작입니다. 지금까지가 도구를 배우는 시간이었다면, 이제부터는 도구로 문제를 깨는 시간입니다. 그 첫 무대가 워게임 — 공격 기술을 연습하라고 일부러 취약하게 만들어 둔 서버입니다. Bandit은 각 레벨의 비밀번호가 다음 레벨의 열쇠가…

읽기 →

서버에 처음 들어간 사람이 던지는 첫 질문은 "여기 뭐가 있지?"입니다. 그 질문에 답하는 도구의 왕이 find입니다. 이름, 크기, 주인, 그룹, 권한, 수정 시각 — 파일의 어떤 속성이든 조건으로 걸어 전수 조사하는 명령입니다.…

읽기 →

Bandit 중반부부터 문제의 결이 바뀝니다. 초반이 "파일 찾기"였다면 이제는 변환과 대화입니다. 꼬인 문자열을 풀고(인코딩), 네트워크 포트에 직접 말을 겁니다(소켓). 이 구간이 중요한 이유는 단순합니다 — 여기서 쓰는 도구들이 실제 현장의 맨손…

읽기 →

지금까지의 Bandit은 "찾고 읽는" 게임이었습니다. 오늘부터 격이 다른 개념이 등장합니다 — 남의 권한으로 실행되는 프로그램. 질문 하나로 시작합니다. 내 계정으로는 절대 못 여는 파일이 있습니다. 그런데 이상한 프로그램이 하나 놓여 있습니다. 이…

읽기 →

서버에는 사람이 치지 않아도 도는 일들이 있습니다. 매분 로그를 정리하고, 매시간 백업을 하고, 매일 밤 보고서를 만드는 — cron이라는 스케줄러가 돌리는 자동 작업들입니다. 여기에 해커의 질문을 얹어 봅시다. 자동으로 도는 것은 보통…

읽기 →

Step 87에서 우리는 이렇게 배웠습니다 — 공개 저장소에 비밀을 올리지 마라, 지워도 과거 커밋에 남으니까. 그때는 방어의 규칙이었습니다. 오늘은 동전의 뒷면입니다: 여러분이 익힌 git log, git show, git branch -a, git tag가…

읽기 →

Bandit이 리눅스 서버의 게임이었다면, Natas는 웹의 게임입니다. 주최는 같고(OverTheWire), 목표도 같습니다 — 다음 레벨의 비밀번호를 찾아라. 다만 이번에는 그 비밀이 서버 파일이 아니라 웹 페이지의 안팎에 숨어 있습니다. 오늘의 핵심 문장을 먼저…

읽기 →

Step 102까지 우리는 문서의 뒤를 봤습니다. 이제부터는 로직의 뒤를 봅니다. Natas 6부터는 페이지에 "소스 코드 보기" 버튼이 달립니다 — 서버의 PHP 코드를 읽는 것이 곧 풀이입니다. 서버는 요청을 받아 코드를 실행하고 결과를…

읽기 →

Step 103까지 우리는 "서버 코드를 읽는 눈"을 길렀습니다. 오늘부터는 읽는 것을 넘어 서버의 암호와 쿼리를 직접 조작합니다. Natas 11~15는 다섯 개의 관문이 사실상 두 개의 큰 산입니다 — 첫째, Step 90에서 장난감이라고…

읽기 →

여기까지 오면서 여러분은 60개 안팎의 문제를 풀었습니다. 그런데 잘 생각해 보면 그 60문제는 사실 스무 가지 남짓한 기법의 변주입니다. find 조건 검색이 세 번 나왔고, 소스 코드 읽기가 다섯 번 나왔고, 쿠키…

읽기 →

Step 99에서 setuid를 처음 만났습니다 — "파일의 주인 권한으로 실행되는" 이상한 비트. Bandit에서는 그것이 친절한 사다리였지만, 실제 서버에서 잘못 붙은 setuid는 공격자의 엘리베이터입니다. 오늘은 세 개의 특수 비트 — setu…

읽기 →

지금까지 우리는 "문을 뚫는 쪽"의 기술을 배웠습니다. 오늘은 시선을 바꿉니다 — 누가 언제 문을 두드렸는가를 기록하는 곳, /var/log를 읽습니다. 리눅스에서 일어난 일은 거의 전부 이 폴더에 흔적을 남깁니다. 로그인 성공과 실패, sudo…

읽기 →

여러분이 ls라고 칠 때 컴퓨터는 정확히 무엇을 실행할까요? 정답은 "때에 따라 다릅니다"입니다. 셸은 PATH라는 환경변수에 적힌 폴더들을 앞에서부터 뒤져 처음 발견한 ls를 실행합니다. 즉 "무엇이 실행되는가"는 변수 하나가 결정…

읽기 →

ls -l을 하면 파일 목록이 나옵니다. 그런데 그 "파일 이름"은 사실 파일의 실체가 아닙니다. 실체는 따로 있고, 이름은 실체를 가리키는 표창일 뿐입니다. 그리고 표창은 하나의 실체에 여러 개 붙을 수 있습니다 —…

읽기 →

지금까지 여러분은 리눅스 권한 모델의 허점을 하나씩 따로 배웠습니다. setuid, PATH 인젝션, 심볼릭 링크, cron — 각각은 개별 기법이지만, 실전의 공격자는 이것들을 하나의 점검 목록으로 봅니다. "이 서버에 올라탔다. 이제 뭘 확인하지?&quot…

읽기 →

지금까지 여러분은 nmap도, 스크립트도, 워게임 접속도 "일반 리눅스"에서 하나씩 다뤘습니다. 침투 테스터들의 실제 작업 환경은 이 도구 수백 개가 처음부터 전부 깔린 리눅스 — Kali Linux입니다. 오늘은 그 작업대를 우리 랩 안에…

읽기 →

공격 연습에는 표적이 필요합니다. 그런데 표적을 아무 데서나 구할 수는 없습니다 — 남의 서버는 범죄이고, 내 실제 서버는 위험합니다. 답은 일부러 취약하게 만들어진 연습용 가상머신, Metasploitable2(이하 MS2)입니다. 오늘은 이 표적을 들이되, 절대…

읽기 →

침투 테스트의 첫 실제 행동은 공격이 아니라 목록 작성입니다. 목표 서버에 열린 문이 몇 개이고, 각 문 뒤에 무엇이 있는지 빠짐없이 파악하는 것 — 이것이 정찰(reconnaissance)입니다. Step 81에서 nmap의 원리를 내 컴퓨터…

읽기 →

Step 113에서 우리는 대상의 "지도"를 그렸습니다 — 어떤 포트에, 어떤 서비스가, 몇 번 버전으로 돌고 있는지. 오늘은 그 지도 위에 "여기가 뚫릴 후보"라는 표시를 자동으로 얹어 주는 도구, 취약점 스캐너(vulnerabil…

읽기 →

Step 114에서 스캐너가 "CVE-2011-2523"이라는 번호를 던져 줬습니다. 이 번호는 무엇이고, 어디서 읽고, 얼마나 믿어야 할까요? 오늘은 취약점의 세계에서 통용되는 언어 — CVE 번호, CVSS 점수, PoC(개념 증명 코드) — 를 …

읽기 →

Step 115에서 우리는 "vsftpd 2.3.4 백도어 공격 코드가 Metasploit 모듈로 있다(EDB-ID 17491)"는 사실까지 확인했습니다. 오늘은 그 도구 창고의 문을 엽니다. Metasploit은 익스플로잇 프레임워크 — 수천 개의 …

읽기 →

드디어 왔습니다. 지금까지의 모든 챕터 — 포트 스캔, 버전 탐지, CVE 독서, Metasploit 조립 — 가 오늘 하나의 순간을 위해 존재했습니다. 쉘(shell) 획득: 네트워크 너머 남의 컴퓨터에서 내가 친 명령이 실행되는 순간.…

읽기 →

Step 117의 백도어 쉘은 "대상이 문을 열고 기다리고, 우리가 노크하는" 모양이었습니다. 그런데 현실의 대상은 대부분 방화벽과 NAT 뒤에 숨어 있어서, 내가 노크할 문 자체가 밖에서 보이지 않습니다. 그래서 방향을 뒤집습니다 — 대상이…

읽기 →

Step 118에서 우리는 이미 netcat(이하 nc)으로 쉘을 주고받았습니다. 그런데 nc는 쉘 도구가 아니라 TCP/UDP 파이프 그 자체입니다 — 키보드로 친 것을 네트워크로 흘려보내고, 네트워크로 온 것을 화면에 흘려보낼 뿐이지요. 이 단순함이 힘입니다.…

읽기 →

Step 117에서 여러분은 Metasploit에 대상만 알려 주고 쉘을 얻었습니다. 편했지만, 정작 "무슨 요청이 날아갔는지"는 검은 상자 속입니다. 면접관이나 팀 선배가 "그 익스플로잇이 실제로 뭘 하는 건데요?"라고 물으면 버튼…

읽기 →

Step 120에서 공격 하나를 맨손으로 재현했습니다. 오늘은 레퍼토리를 늘립니다. 취약점 박물관인 MS2에는 서비스마다 "고전"이 있습니다 — distcc는 인증 없는 명령 실행, UnrealIRCd는 백도어, Samba는 사용자명 주입. 이 고전들…

읽기 →

비밀번호를 공격하는 길은 두 갈래입니다. 살아있는 로그인 창에 계속 대입하는 온라인 공격, 그리고 해시 파일을 훔쳐 와서 내 컴퓨터에서 무한정 시도하는 오프라인 공격. 오늘은 전자입니다. 온라인 공격은 느리고, 서버 로그에 전부 기록되고,…

읽기 →

Step 122의 온라인 공격은 시도당 18ms였고, 모든 시도가 로그에 남았습니다. 그런데 만약 공격자가 서버의 비밀번호 저장소(/etc/shadow)를 통째로 훔쳐 나오면 어떻게 될까요? 대답은 오늘의 주제입니다. 해시 파일은 내 컴퓨터에서, 로그도 잠금도 없이, …

읽기 →

Step 123에서 john으로 shadow 해시를 깨 봤습니다. 그런데 현장에는 더 큰 짐승이 있습니다 — hashcat. GPU의 수천 개 연산 코어를 동원해 초당 수백억 회씩 후보를 대입하는 크래킹 도구의 끝판왕입니다. 오늘의 핵심 질문은…

읽기 →

침투에 성공해 쉘을 얻었습니다. 축하할 일이지만, 그 쉘의 주인을 확인해 보면 대부분 실망스럽습니다 — www-data, daemon 같은 아무 권한 없는 서비스 계정입니다. 오늘의 주제는 여기서 root(리눅스의 최고 권한, uid 0)까지 올라가는 길,…

읽기 →

Step 125에서 여섯 개의 정찰 명령을 배웠습니다. 그런데 실제 침투 직후에 확인할 것은 여섯 개가 아니라 수백 개입니다 — SUID, sudo, cron, 쓰기 가능 파일, 저장된 비밀번호, 커널 버전, 네트워크, 프로세스…. 이걸…

읽기 →

쉘을 얻는 순간이 끝이 아니라 시작입니다 — 이 말은 이제 귀에 익었을 것입니다. 그런데 "시작"이 정확히 무엇인지 미리 정해 두지 않으면, 현장에서는 반드시 중요한 것을 놓칩니다. 긴장한 사람의 기억력은 믿을 것이 못…

읽기 →

실무 침투 테스트의 산출물은 쉘이 아닙니다 — 보고서입니다. 고객이 돈을 내고 사는 것은 "뚫었다는 사실"이 아니라 "무엇이, 왜 뚫렸고, 어떻게 고쳐야 하는가"가 담긴 문서입니다. 지금까지 MS2(Metasploitable2)를 상…

읽기 →

MS2(Metasploitable2)는 "답을 알고 푸는 문제집"이었습니다 — 어디가 뚫리는지 이미 알고 있었으니까요. VulnHub의 머신들은 다릅니다. 난이도 표시만 있고 답은 없는 모의고사입니다. 오늘의 질문은 하나입니다 — 지금까지 익힌 순서(…

읽기 →

실전 — 대회든 시험이든 실무든 — 은 시간 싸움입니다. 같은 실력이라도 "정찰 30분, 침투 2시간, 권한 상승 2시간, 기록 1시간"처럼 배분 계획이 있는 사람이 훨씬 멀리 갑니다. 오늘의 점검은 해킹 실력이 아니라…

읽기 →

HTTP는 상태가 없습니다 — 서버는 매 요청을 처음 만난 사람처럼 대합니다. 그런데 로그인은 왜 유지될까요? 서버가 로그인 순간에 세션 ID를 쿠키로 쥐여 주고, 이후 요청마다 그것을 검사하기 때문입니다. 공격하려면 먼저 만들 줄…

읽기 →

웹 해킹의 80%는 한 문장으로 요약됩니다 — 요청을 잡아서, 보고, 고쳐서 보낸다. Burp Suite는 그 일을 위한 도구입니다. 브라우저와 서버 사이에 투명한 중간자로 끼어들어, 지나가는 모든 요청을 멈춰 세우고, 내용을 들여다보고, 고친…

읽기 →

Step 132에서 우리는 요청을 잡아 한 번 고쳐 보냈습니다. 그런데 웹 공격의 실제 노동은 반복입니다 — 따옴표를 넣어 보고, 바꿔 보고, 다시 넣어 보는 수십 번의 실험. Burp에는 그 노동을 위한 두…

읽기 →

웹 서버는 여러분을 기억하지 못합니다. HTTP는 요청 하나하나가 독립이라, 서버 입장에서 매번 "처음 온 사람"입니다. 그래서 등장한 것이 쿠키(cookie) — 로그인에 성공하면 서버가 브라우저에 쥐여 주는 신분증입니다. 이후 요청에는 이 신분증이…

읽기 →

Step 104에서 ‘ OR ‘1’=’1을 처음 성공시켰습니다. 오늘은 그 한 방을 체계로 바꿉니다. 교재는 DVWA(Damn Vulnerable Web App) — 일부러 취약하게 만든 PHP 웹앱으로, 난이도를 Low/Medium/High로 올려 가며 같은 취약점을…

읽기 →

Step 135의 공격은 로그인 문을 열었을 뿐, 데이터를 화면으로 끌어내지는 못했습니다. 오늘 배우는 UNION 인젝션은 다릅니다. 원래 쿼리의 결과에 내가 만든 쿼리의 결과를 위아래로 붙여, 테이블 목록도, 계정 목록도, 비밀번호 해시도 검색…

읽기 →

Step 136의 UNION은 화면에 출력이 있을 때의 기술입니다. 그런데 잘 만든(?) 취약 서비스는 결과를 보여 주지 않습니다 — "있습니다 / 없습니다" 두 문장만 돌아오죠. 출력이 없으면 끝일까요? 아닙니다. 참과 거짓의 차이도 정보입니다.…

읽기 →

지금까지의 인젝션(SQL, 명령어)은 서버를 공격했습니다. XSS(Cross-Site Scripting) 는 결이 다릅니다 — 서버를 거쳐 다른 사용자의 브라우저를 공격합니다. 내가 심은 <script>가 피해자의 브라우저에서 실행되면, 그 페이지의 권한으로…

읽기 →

지금까지의 XSS는 alert(1) 팝업으로 끝났습니다. 팝업은 "여기서 스크립트가 실행된다"는 증거일 뿐, 공격이 아닙니다. 실전의 XSS는 조용합니다 — 피해자의 세션 쿠키를 공격자 서버로 몰래 보내고, 공격자는 그 쿠키로 로그인 없이 피해자 행세…

읽기 →

Step 139에서 우리는 피해자의 쿠키를 훔쳐 와서 썼습니다. 그런데 쿠키를 훔치지 않고도 피해자 권한으로 일을 시키는 방법이 있습니다 — 피해자의 브라우저가 스스로 요청을 보내게 만드는 것입니다. 브라우저에는 성실한 습관이 하나 있습니다: 어떤…

읽기 →

사진 게시판에 사진 대신 실행 파일을 올릴 수 있다면 어떻게 될까요? 서버는 그 파일을 디스크에 저장하고, 공격자가 그 주소에 접속하는 순간 서버 안에서 내 코드가 실행됩니다. 이 한 장의 파일이 웹쉘(web shell)…

읽기 →

Step 141에서 우리는 웹쉘을 "올렸습니다". 오늘은 만듭니다. 웹쉘은 신비한 해커 도구가 아니라, "HTTP 요청의 파라미터를 운영체제 명령으로 실행해 주는 번역기"일 뿐입니다. 번역기의 내부를 한 줄씩 뜯어 보고, POST형·…

읽기 →

Step 142의 웹쉘은 공격자가 심는 명령 실행기였습니다. 그런데 심을 필요가 없는 경우가 있습니다 — 서버의 평범한 기능이 이미 "입력을 명령에 붙여 실행"하고 있다면, 그 기능 자체가 웹쉘입니다. "IP를 넣으면 ping을 대신 쳐…

읽기 →

Step 143의 명령 인젝션이 "명령을 심는 공격"이었다면, 오늘의 파일 포함(file inclusion)은 "읽을 파일을 고르는 공격"입니다. PHP의 include는 파일을 코드로 읽어 실행하는데, 그 파일명을 사용자 입력에서 …

읽기 →

개발자는 종종 이렇게 믿습니다. "주소를 모르면 못 찾겠지." 그러나 공격자는 사전으로 전부 두드립니다 — Step 121에서 우리가 직접 만들어 본 그 기법입니다. 오늘은 그 탐색이 실제로 무엇을 낚는지 봅니다. 웹에 통째로 올라간…

읽기 →

로그인은 공격 표면의 정문입니다. 지금까지 정문 공격의 부품들 — 브루트포스(Step 122), 세션 쿠키(Step 134), 프록시 가로채기(Step 132~133) — 를 따로 배웠습니다. 오늘은 그 부품들을 "인증 공격"이라는 하나의 체계로 조립…

읽기 →

취약점 하나를 진짜로 안다는 것은 세 가지를 다 말할 수 있다는 뜻입니다. 왜 생기는가(원리), 어떻게 터는가(공격), 어떻게 막는가(방어). 지금까지 DVWA의 여러 모듈을 Low 난이도 중심으로 털어 왔다면, 오늘은 남은 모듈을 마무리하고 Medium·High의…

읽기 →

DVWA는 2000년대 PHP 웹앱의 세계였습니다. 오늘 만나는 OWASP Juice Shop은 Node.js와 Angular로 만든 현대적 웹앱 — 화면을 그리는 일이 서버가 아니라 여러분의 브라우저에서 일어납니다. 이 변화가 공격자의 지도를 바꿉니다: 페이지 소스는…

읽기 →

어제 스코어보드를 찾고 숨겨진 경로를 열어 봤다면, 오늘은 본격적으로 남의 데이터를 건드려 봅니다. 내 장바구니 주소가 /rest/basket/6이라면 /rest/basket/7은 누구의 장바구니일까요? 숫자 하나만 바꿨는데 남의 물건이 보인다면, 그 서버는 &quot…

읽기 →

어제까지 우리는 주소의 숫자를 바꿨습니다. 오늘은 신분증 자체를 위조합니다. Juice Shop의 로그인 증표는 JWT(JSON Web Token) — 점 두 개로 이어진 긴 문자열인데, 이것은 "서버가 서명한 JSON 신분증"입니다. 서명 검사를 빼…

읽기 →

지금까지의 무대 — Bandit, Natas, DVWA, Juice Shop — 은 전부 "정해진 교과서"였습니다. 오늘부터는 "남이 낸 시험 문제"를 풉니다. 드림핵은 한국어로 된 CTF(해킹 방어 대회 형식의 문제 풀이) 플랫폼으…

읽기 →

첫 8문제를 풀었다면 눈치챘을 것입니다 — 실전 문제는 교과서대로 주지 않습니다. SQL 인젝션은 로그인 폼이 아니라 검색창에 있고, 쿠키 조작은 role=guest가 아니라 JWT로 변장해 있고, 파일 읽기는 "이미지 다운로드"라는 순한 이름 뒤에…

읽기 →

여기까지 오면 이제 문제가 여러분보다 앞서 나가기 시작합니다. 처음 보는 단어가 문제에 등장합니다 — SSTI, XPath 주입, 세션 고정, SSTI… 배운 적 없는 기법들입니다. 낙심할 필요 없습니다. 프로는 모든 기법을 아는 사람이…

읽기 →

30문제를 넘기면 데이터가 쌓입니다. 어떤 유형은 10분 컷인데, 어떤 유형은 매번 막힙니다. 이 차이를 "느낌"으로 알고 있는 것과 숫자로 알고 있는 것은 다릅니다. 약점 유형을 정확히 아는 것이 Level 3 트랙 선택의…

읽기 →

지금까지의 웹 실습은 전부 "오늘 배울 취약점"이 정해진 연습장이었습니다. SQLi 챕터에는 SQLi가 있고, XSS 챕터에는 XSS가 있었죠. 실전은 다릅니다 — 타깃은 자기 약점을 말해 주지 않습니다. 이번 프로젝트의 목표는 "뭐가 취약한…

읽기 →

인터넷 통신의 신분 확인은 암호화가 담당하는 줄 알기 쉽지만, 그 한 단계 아래 — 같은 네트워크 안에서 "이 IP를 가진 장비가 물리적으로 어디 있지?"를 묻는 프로토콜에는 신분 확인이 아예 없습니다. 그 프로토콜이…

읽기 →

한쪽만 속이면 절반만 보입니다. 피해자가 게이트웨이로 보내는 요청은 보이지만, 돌아오는 응답은 보이지 않습니다. 완전한 MITM은 양방향 — 피해자에게는 "내가 게이트웨이", 게이트웨이에게는 "내가 피해자"라고 동시에 속이는 것입니다…

읽기 →

지금까지는 "캡처하고, 필터 걸고, 패킷을 읽는" 기본기를 배웠습니다. 오늘은 분석가의 기술 세 개를 배웁니다 — 캡처 필터와 표시 필터의 구분(잡을 때 거르기 vs 잡은 뒤 보기), TCP 스트림 재조립(흩어진 패킷을 대화 하나로…

읽기 →

Step 156~157에서 여러분은 ARP를 속여 트래픽을 내 장비로 흘렸습니다. 그런데 패킷을 가로채는 것만으로는 부족할 때가 있습니다 — 피해자가 어디로 가는지 자체를 바꾸고 싶을 때. 그 열쇠가 DNS입니다. 인터넷의 전화번호부인 DNS를 속이면, 피해자는…

읽기 →

지난 챕터들에서 여러분은 중간자가 되는 법을 배웠습니다 — ARP를 속이고, 트래픽을 가로채고, DNS까지 바꿔치기했습니다. 그런데 그 모든 공격 앞에 서 있는 벽이 하나 있습니다. 바로 TLS입니다. 오늘은 MITM의 관점이 아니라 그 벽의…

읽기 →

지금까지 여러분은 문을 두드리는 쪽이었습니다 — nmap으로 열린 포트를 찾고, SSH로 들어가고, 트래픽을 가로챘습니다. 오늘은 반대편에 섭니다. 방화벽은 "어떤 패킷을 들이고 내쫓을지"를 규칙으로 정하는 문지기이고, iptables는 리눅스의 그 …

읽기 →

Step 132에서 여러분은 프록시를 "요청을 가로채서 보는 도구"로 썼습니다. 오늘은 같은 구조를 반대 방향에서 봅니다 — 서버에게 내 IP를 숨기는 도구로서의 프록시, 그리고 그 아이디어를 극한까지 밀어붙인 Tor입니다. "내 대신 요청해…

읽기 →

Step 29에서 여러분은 SSH를 "원격 터미널"로 썼습니다. 그런데 SSH 연결은 명령만 나르는 관이 아닙니다 — 그 암호화된 통로 안에 다른 프로그램의 통신을 실어 나를 수 있습니다. 이것이 포트 포워딩입니다. "밖에서는 막혔지만 안에서…

읽기 →

열거(enumeration)는 "돌 하나하나 뒤집기"입니다. 포트, 서비스 버전, 웹 경로, 사용자, 공유 폴더 — 침투 테스트에서 찾아야 할 단서는 전부 열거에서 나옵니다. 문제는 사람이 체크리스트 없이 하면 반드시 빠뜨린다는 것입니다. 그래서 실무…

읽기 →

Step 122에서 한 계정에 워드리스트를 들이붓는 수직 공격을 했고, "5회 실패 시 잠금" 하나에 공격이 멈추는 것을 봤습니다. 그런데 공격자도 배웁니다 — 잠금이 "한 계정의 연속 실패"를 세는 장치라면, 계정을 바꿔 가며…

읽기 →

유선 네트워크의 패킷은 케이블 안을 지나지만, 무선의 패킷은 공기 중에 전부 뿌려집니다. 안테나만 있으면 누구나 받을 수 있습니다. WPA2는 이 상황에서 비밀번호를 어떻게 지킬까요? 정답은 "비밀번호를 절대 보내지 않는다"입니다. 대신 접속할 때마다…

읽기 →

지금까지 우리는 기술의 문을 두드렸습니다 — 포트, 비밀번호, 웹 취약점. 그런데 침해 사고 통계에서 가장 큰 비중을 차지하는 초기 침입 경로는 기술 공격이 아니라 사람에게 보내는 한 통의 메일입니다. 이유는 단순합니다. 아무리…

읽기 →

악성코드 뉴스는 매주 나오지만, 정작 "그것이 내부에서 어떻게 생겼는가"를 아는 사람은 드뭅니다. 트로이목마와 웜과 랜섬웨어는 뉴스에서는 비슷한 단어처럼 섞이지만, 구조는 완전히 다릅니다 — 번식 방식이 다르고, 숨는 방식이 다르고, 돈을 버는 방식이…

읽기 →

백신과 공격자는 오래된 숨바꼭질을 하고 있습니다. 백신이 "알려진 악성코드의 지문"을 저장해 두면, 공격자는 같은 코드를 다른 모양으로 포장해 지문을 바꿉니다. 백신이 다시 "행동"을 보기 시작하면, 공격자는 행동마저 정상처럼 위장하…

읽기 →

OSINT(Open Source Intelligence, 공개 출처 정보)는 "뚫지 않고도 알아내는 기술"입니다. 로그인 한 번 없이, 검색과 공개 페이지만으로 한 사람의 관심사·지역·활동 시간대가 그려집니다. 비밀은 사람들이 사이트마다 같은 아이디를…

읽기 →

회사의 서버는 회사도 다 모릅니다. dev.company.com, old.company.com, vpn.company.com — 만들 때는 이유가 있었지만 담당자가 바뀌면 잊힙니다. 그런데 공격자는 잊지 않습니다. 서브도메인 하나하나가 문이고, 방치된 테스트 서버 하나…

읽기 →

지금까지 우리는 기술을 낱개로 배웠습니다 — nmap은 nmap, 쉘은 쉘. 그런데 대회와 모의해킹의 실제 형태는 다릅니다: IP 하나만 받고 시작해서, 쉘을 얻을 때까지 혼자 간다. 오늘은 그 전 과정을 시간을 재며 수행합니다.…

읽기 →

침투는 끝났지만 일은 끝나지 않았습니다. 실무 침투 테스트의 산출물은 쉘이 아니라 보고서이고, 보고서는 두 명의 독자를 위해 씁니다 — 임원("얼마나 위험한가, 뭘 해야 하나")과 엔지니어("어디를 어떻게 고치나"). 오늘은 두 갈래…

읽기 →

실제 침해 사고는 한 방에 일어나지 않습니다. 사다리처럼 올라갑니다 — 웹 취약점(입구) → 웹쉘(발판) → 제한된 권한의 쉘(정착) → 권한 상승(지배). Level 2에서 배운 조각들이 오늘 처음으로 하나의 줄기로 엮입니다. 각 단계에서…

읽기 →

수십 개의 공격 기법을 배웠습니다. 그런데 공격만 아는 사람은 반쪽입니다 — 모든 공격에는 대응하는 방어가 있고, 모든 방어에는 우회가 있습니다. 오늘은 Level 2 전체를 "공격 × 방어 × 우회"의 한 장짜리 표로…

읽기 →