악성코드가 LLM으로 피해자를 돈이 되는 순서대로 줄 세웁니다

Malware uses LLMs to rank victims by how much they're worth

blog.talosintelligence.com ▲ 253 댓글 135 khalidkhair

요약

VOLTA 악성코드는 훔친 자료를 LLM에 넘겨 피해자의 자산 가치와 보안 습관을 평가하게 합니다.

시스코 탈로스의 라이언 페터먼이 분석한 윈도용 정보 탈취 악성코드입니다. 제작자가 주문마다 맞춤 실행 파일을 만들어 파는 것으로 보이며, 공격자 소유 서버 없이 제3자 서비스만 사용합니다.

왜 중요한가

  • 훔친 로그를 피해자별 보고서로 정리하던 분석 작업을 AI가 대신하기 시작했습니다.
  • 필자는 이 변화가 범죄의 진입 문턱을 낮출지, 공격 규모를 키울지, 혹은 둘 다일지를 묻습니다.
  • 모델의 거절에 대비한 우회 설계가 악성코드의 표준 요건이 될 수 있다고 필자는 봅니다.

핵심 내용

  • 모은 자료를 JSON으로 묶어 OpenRouter(여러 AI 모델을 한곳에서 호출하는 서비스)로 보내고, 모델에게 포렌식 분석가 역할을 맡깁니다.
  • 결과 보고서의 "WHAT THEY'RE WORTH" 항목은 피해자의 자산을 가치별로 나누고, 다른 항목은 보안 수준과 비밀번호 습관을 평가합니다.
  • 기본 모델은 anthropic/claude-opus-4.6이며, 응답에서 거절 문구가 보이면 kimi-k2와 gemini-2.5-flash로 차례로 넘어갑니다.
  • 훔친 세션으로 Gmail의 배송 영수증을 뒤져 집 주소를 확인하고, Uber Eats와 DoorDash 주문 내역도 가져옵니다.
  • 브라우저 비밀번호와 쿠키, 결제 카드, 각종 계정 세션, SSH 키, 암호화폐 지갑, 저장된 와이파이 비밀번호를 빼 갑니다.

HN 반응

  • 일부 이용자는 자동 업데이트 도구가 위험하다며 용도별로 컴퓨터나 가상 머신을 나누자고 했고, 가상 머신도 완벽하지 않다는 반론이 나왔습니다.
  • npm 문화가 의존성 관리를 망쳤다는 비판에는, 그런 위험은 npm 이전에도 있었다는 반론과 작은 표준 라이브러리가 문제라는 보충이 이어졌습니다.

댓글

30개 표시 · 전체 135개
  1. akersten HN

    이런 게 밤잠을 설치게 만듭니다. Claude, ArtCraft 같은 자동 다운로드 도구가 한 달에 수만 건씩 코드 변경을 내보내고 있는데, 오염된 업데이트 하나로 이 녀석이 들어오면 사실상 끝장입니다. 소프트웨어를 "개발"하는 속도가 빨라질수록 이런 공격이 노릴 수 있는 틈도 넓어지는 것 같습니다.

    그래서 컴퓨터를 한 5대쯤 따로 두고 싶어집니다.

    • 은행 업무 전용 1대

    • 개발 전용 1대

    • 웹 브라우징 전용 1대

    • 게임 전용 1대

    • SNS 전용 1대

    10초 만에 내 디지털 생활 전체를 빼 가는 위협을 막으려면 달리 무슨 방법이 있겠습니까?

  2. DotNetCorePowa HN

    npm 같은 것들 덕분이죠.

    예전에는 자기가 가져다 쓰는 의존성은 자기가 책임졌어요.

    그런데 npm이 나오고 자바스크립트 개발자들이 시장에 쏟아져 들어오면서 "다들 그렇게 하니까" 하고 무책임하게 구는 게 당연해졌죠.

    몇 년이 지나 지금은 독립 실행형 앱까지 전부 웹 기반입니다. 자기 컴퓨터에서 뭐가 돌아가는지 아무도 모르고, 개발자들조차 자기들이 사용자에게 뭘 실행하라고 하는지 모르고요...

    거기에 바이브 코딩까지 살짝 얹으면 끝장입니다.

    우리 업계가 제대로 대접받기까지 40년이 걸렸는데, 이제 다 날아갔어요.

  3. hibikir HN

    OSS 공유 코드 저장소는 npm보다 훨씬 오래됐습니다. 하다못해 자바의 Maven Central만 봐도 그렇습니다.

    npm이 더 눈에 띄는 표적이 되는 건 표준 라이브러리가 훨씬 작고 의존성이 잘게 쪼개져 있어서, 출처가 수상한 코드가 아무 프로젝트에나 섞여 들어올 가능성이 더 크기 때문입니다. 자바 백엔드 프로젝트가 의존하는 것 대부분은 아마 같은 세 회사가 만들었거나, 규모가 크고 자리 잡은 OSS 저장소에서 나온 것일 겁니다. 그러니 운영위원회에서 신경 쓰기로 마음먹기만 하면 비교적 풀 수 있는 문제입니다. 개선되고는 있지만 충분히 빠르진 않다고 봅니다.

  4. ctkhn HN

    자바에서 저도 이 점을 많이 느꼈습니다. 우리 회사 비즈니스 로직과 무관하게 필요한 건 대부분 표준 라이브러리에 이미 있었고, 필요했던 OSS 라이브러리도 대체로 평판 좋고 잘 알려진 것들이었습니다. 개인 백엔드 프로젝트를 js로 몇 번 해 봤는데, 기능을 하나하나 npm에서 뒤져 가며 찾아야 해서 미칠 지경이었습니다. 게다가 npm 패키지는 의존 단계가 얼마나 깊어질 수 있는지 몰라서 신뢰 사슬도 훨씬 복잡하고요.

  5. hoppp HN

    자바에서 그런 공격 얘기는 보통 잘 안 들립니다. 아마 존재는 하겠지만, 파이썬과 자바스크립트가 주로 표적이 되는 건 다들 그걸 쓰기 때문일 겁니다. 닿는 범위가 넓으니까요.

  6. td521534f12 HN

    파이썬과 자바가 군침 도는 표적인 큰 이유는, 아주 오랫동안 pip와 npm이 import할 때가 아니라 패키지를 설치할 때 사용자 컴퓨터에서 코드를 실행했기 때문입니다. (제가 알기로는 pip와 npm 최신 버전에서는 바뀌는 중입니다.)

  7. eddythompson80 HN

    저는 대부분 공격 표면의 문제라고 봅니다. 의존성을 다루는 방식에서 위협 모델이나 보안 경계가 언어마다 근본적으로 다르진 않아요. Maven이나 NuGet처럼 설치 스크립트가 없는 플랫폼에서도, 설치 직후에 애플리케이션을 빌드하거나 잠깐 실행해 보게 되니 어차피 코드 실행이 일어납니다.

    npm install 단계에서 당할 확률이 더 크긴 해도, dotnet add package ... && dotnet run과 크게 다르지는 않습니다.

    다만 npmjs, pip, 심지어 cargo까지 표면이 워낙 방대해서 패키지 서명도 현실적이지 않다는 데는 동의합니다. 평균 300개 정도의 npm 패키지를 쓰는데, 서명 키 200개의 진위를 일일이 챙길 사람은 없죠. 자바 같으면 openjdk, jackson, junit, log4j 키 몇 개만 믿으면 90%는 해결되니 훨씬 쉬울 겁니다. (물론 공급망 공격이 서명 키까지 오염시키지 않았기를 바라야 하지만요.)

  8. td521534f12 HN

    설치 시 실행이 import나 실행 시 실행보다 더 큰 문제인 이유는, 요즘 개발자 상당수가 코드를 샌드박스 환경(컨테이너, VM 등) 안에서 돌려서 악성코드가 세션 토큰 같은 것에 쉽게 접근하지 못하기 때문입니다.

  9. eddythompson80 HN

    그렇게 환경을 구성하는 게 불가능하다는 얘기는 아닙니다. 다만 제 경험으로는 샌드박스 밖에서 설치한다면 실행도 샌드박스 밖에서 하게 됩니다. 컨테이너든 VM이든 샌드박스 환경 밖에서 패키지를 설치하고 안에서 실행하는 흐름 자체가 이해가 안 됩니다. 개발 컨테이너를 쓰는 사람은 툴체인 전체를 개발 컨테이너 안에 두고, VM이라면 virtio-fs나 SMB/NFS로 파일 시스템을 공유할 수야 있겠지만, 호스트에서 npm install을 하고 VM에서 실행하는 흐름은 이해가 안 됩니다. 꽤 어색해 보이는데요.

  10. td521534f12 HN

    IDE에서 자동 완성이나 소스 탐색이 되게 하려는 겁니다.

  11. bigfatkitten HN

    인프라 운영 방식도 퇴보했습니다.

    15년 전에는 운영 인프라가 인터넷으로 직접 나가지 못하게 했고, 나가야 한다면 허용 도메인 목록을 둔 명시적 프록시를 거쳤습니다. 덕분에 악성 의존성이 입힐 수 있는 피해가 상당히 제한됐죠.

    클라우드와 DevOps로 넘어가면서 그런 네트워크 보안 모델이 사라졌습니다.

  12. odo1242 HN

    클라우드에서도 VPC와 서브넷으로 그렇게 할 수 있습니다. 신경 쓰지 않아서 취약해진 사람들도 있지만, 클라우드 소프트웨어에서도 그게 모범 사례인 건 마찬가지입니다.

  13. bigfatkitten HN

    당연히 가능합니다. 하지만 침해를 당하기 전에는 하는 사람이 거의 없습니다.

    개발자들은 서버가 인터넷에서 임의의 코드를 그냥 끌어오게 두는 편의가 보안 위험보다 중요하다고 결정해 버렸습니다.

  14. malfist HN

    예전에는 자기가 가져다 쓰는 의존성은 자기가 책임졌어요.

    npm 이전 시절에 코드를 짜 본 사람에게는 현실과 맞지 않는 태도입니다.

  15. jbm HN

    맞아요. 게다가 자바스크립트만의 문제도 아니고요. XKCD의 유명한 "import antigravity" 만화도 파이썬 얘기였잖아요.

    우리는 늘 남에게 의존해 왔다는 게 현실이죠.

  16. lincon127 HN

    제 생각에 전형적인 JS 개발자와 파이썬 개발자가 그렇게 다르진 않은 것 같아요... 적어도 의존성 관리에서는요.

  17. animal_spirits HN

    그 XKCD 만화는 오히려 원글 작성자가 말한 것과 정반대를 보여 줍니다. 파이썬과 자바스크립트는 언어에 무엇을 넣고 무엇을 뺄지에서 양 극단에 있어요. 파이썬은 "배터리 포함"이라서 "pip install antigravity"가 아니라 그냥 "import antigravity"를 할 수 있는 겁니다. 반대편 끝에 있는 게 자바스크립트와 NPM이죠. 문자열 왼쪽에 공백을 채우려고 leftpad 라이브러리를 설치해야 하는 것으로 악명이 높고, 그게 npm에서 내려갔을 때 수천 개 패키지가 깨졌습니다.

  18. cyberclimb HN

    그런 걸 원하시면 QubesOS를 써 보세요. 용도마다 격리된 VM을 따로 둘 수 있습니다. OS 자체는 VM("Qube"라고 부릅니다)들을 감싸는 가벼운 하이퍼바이저입니다.

  19. palijer HN

    지금처럼 LLM이 보안을 흔드는 상황에서는 앞으로 수십 년간 VM이 완벽하게 뚫리지 않는 샌드박스일 거라고 솔직히 100% 확신하지는 못하겠어요.

  20. antonvs HN

    VM이 절대 안전하지 않다는 건 이미 입증됐지만, 여기서 문제는 그게 아닙니다.

    암호화된 디스크 볼륨이 있는 VM 안에서만 은행 앱을 돌리고, 그 안에서는 수상한 사이트를 돌아다니거나 다른 일을 하지 않는다면, LLM의 도움을 받은 공격에도 아주 잘 보호됩니다.

    이 경우 한 가지 단서가 있는데, VM 디스크 비밀번호는 비밀번호 관리자에 넣어 두지 않겠습니다. 그게 공격 경로가 되니까요.

    그래도 키로거는 여전히 쓸 만한 공격 경로입니다. 이런 것들을 막으려면 운영체제 보안이 개선되어야 할 겁니다. 예컨대 가로챌 수 없는 보호된 비밀번호 입력 방식 같은 것이 있겠죠.

  21. giovannibonetti HN

    사이버 보안에서 말하는 "기본 허용"과 "기본 거부"를 들어 보셨습니까? 전통적으로 PC, 특히 가정용 PC는 앞쪽 개념으로 만들어졌습니다. 사용자가 설치된 대부분의 것을 믿는다고 가정하는 거죠.

    문제는 악성코드가 몰래 들어올 수 있다는 점이고, 그러면 사용자는 안티바이러스라는 끔찍한 소프트웨어가 필요해집니다. 안티바이러스는 복잡한 휴리스틱으로 악성과 정상을 가려내려고 애쓰는 물건입니다. 수년간은 그럭저럭 통했지만, 세상이 변하고 위험이 커지면서 조금씩 반대 개념인 "기본 거부"로 옮겨 가고 있습니다. 앱이 무해하다고 입증될 때까지는 해로운 것으로 간주하고, 정직한 앱 개발자는 사용자에게 앱을 내놓으려면 여러 관문을 거쳐야 하죠. 앱 스토어 모델이 그렇습니다. 그럭저럭 통하긴 하지만 앱 개발자에게는 번거롭고 비용도 많이 듭니다.

    어쨌든 VM 논의로 돌아가면, 위험을 더 줄이기 위해 "기본 거부" 개념을 OS 커널 안쪽까지 더 밀어 넣게 될 것 같습니다. 작은 커널은 위험 표면이 훨씬 작고, 합리적인 가정 아래에서는 안전함을 형식적으로 검증할 수도 있을 테니까요.

  22. rwmj HN

    이건 호랑이보다 빨리 달릴 필요 없이 다른 사람보다만 빠르면 되는 상황이라고 생각해요. 삶을 VM으로 나눠 둔다면 보안에서 99%의 사람보다 낫다는 건 분명하니까요.

    주류 OS들이 언제쯤, 아니 과연 이렇게 하기 시작할지 궁금하네요.

  23. BlobberSnobber HN

    발상도 훌륭하고 구현도 훌륭해 보이는데, 하드웨어 지원이 너무 제한적입니다.

  24. pull_my_finger HN

    컨테이너 생태계도 패키지만 더 많을 뿐 본질적으로 같은 문제 아닌가요? OS 패키지도 끌어오고, 언어 런타임 패키지도 끌어오고, 계속 그렇잖아요. 저도 이 문제를 계속 생각해 왔어요.

  25. TuxSH HN

    빼내 가는 위협

    여기에 새로울 것도 없습니다. Claude Code(Auto + 기본 설정)는 문제 해결에 애를 먹으면 홈 폴더에서 "find"/"ls"를 돌리는 경향이 있습니다. 농담이면 좋겠네요.

    물론 사람들은 이런 AI 회사들이 나쁜 짓(tm)을 하지 않으리라 믿습니다. 하지만 모델 엔드포인트 URL을 바꿔치기하거나 하네스 어딘가만 오염시키면, 겉으로는 아무 이상도 없어 보일 겁니다.

  26. mystifyingpoi HN

    홈 폴더에서 "find"/"ls"를 돌리는 경향이 있습니다

    직접 겪어 봤습니다. 어떤 저장소에서 작업하는데, Claude가 AWS 리소스가 어떻게 만들어지는지 조사해야 한다고 판단하더니 말 그대로 ~/*에서 Terraform 코드를 스캔하기 시작했습니다. 그러고는 찾아낸 코드를 훑어보더군요.

    또 한 번은 Claude에게 Spring 문제 디버깅을 시켰는데, 회사 방화벽이 Maven Central을 막아 놨습니다. 그러자 필요한 jar를 어떻게든 찾으려고 말 그대로 ~/.m2 캐시를 뒤지기 시작했습니다. 그래도 못 찾으니까 빠진 jar를 빌드하겠다고 GitHub에서 Spring 소스를 클론하기 시작했고요. 클론 도중에 제가 멈췄습니다. 농담이면 좋겠는데, 키보드에서 1분 자리를 비웠을 뿐입니다.

  27. genxy HN

    모호한 프롬프트 하나 때문에 실수로 컴파일러를 만들어 버린 적도 있어요. 그리고 네, 시스템 다른 곳에 있는 "도움 되는" 코드를 찾아내긴 하죠. 그 말은 Claude가 수백만 개발자의 홈 폴더에 find ~를 돌린 기록을 갖고 있을 가능성이 높다는 뜻이기도 하고요.

  28. cluckindan HN

    에이전트를 왜 샌드박스 밖에서 돌리시는 거죠?

  29. genxy HN

    제 잘못이 맞아요. 저는 맞춤형 샌드박스 시스템을 세 가지나 만들어 봤는데도요. 구두장이 아이들은 신발이 없다더니.

  30. jumploops HN

    저는 지금이 에이전트의 초창기, 인터넷 초창기와 비슷한 시기라는 생각을 해 왔습니다. 우리 컴퓨터를 활짝 열어 놓고 새로운 프로토콜을 신나게 돌리고 있으니까요.

    머지않아(어쩌면 이미) 위협은 훨씬 복잡해질 테고, 우리는 2000년대 초반 같은 바이러스 대란으로 되돌아가게 될 겁니다.

Hacker News에서 보기 ↗