Malware_study

study about malware [매직 패킷 수신] → [인증] → [기능 실행] → [은닉] ↑ ↓ (RAW 소켓 감시) (역방향 쉘 / 포트 리다이렉션 / UDP 모니터링)

This paper aims to fill this gap by presenting what it describes as the first comprehensive study to characterize, analyze, and understand Linux malware. It involved a systematic exploration of the challenges and the design and implementation of the first malware analysis pipeline specifically tailored for Linux malware. The study conducted a large-scale measurement on 10,548 malware samples collected over one year, documenting detailed statistics and insights.

The study identified several key challenges in analyzing Linux malware:

• Target Diversity: Unlike Windows analysis which relies on detailed environment information, Linux malware targets a diverse range of devices (routers, cameras, smart TVs, etc.) built on various CPU architectures (x86, ARM, MIPS, PowerPC, etc.). Supporting these different architectures is complex, and some families like ARM present challenges due to numerous CPU variations.
• Loaders and Libraries: Linux programs use the ELF format, which can specify arbitrary loaders. Dynamically linked binaries also require specific libraries to be present. The absence of a required loader or a single library can prevent execution. Malware may use smaller, alternative libraries like uClibc or musl instead of the traditional glibc, requiring analysis environments to support these alternatives and their loaders.
• Operating System Variations: It can be challenging to distinguish ELF programs compiled for Linux from those for other ELF-compatible systems like FreeBSD or Android, as the OS/ABI field is often not informative. Kernel differences, even between Linux versions or custom embedded systems, can cause issues for dynamically linked programs and lead to crashes for statically linked ones due to syscall differences.
• Static Linking: Statically linked binaries include all their library dependencies, making them more portable but also harder to reverse engineer. They call system calls directly, making them less portable if the kernel ABI differs from what they expect. Over 80% of the samples analyzed in this study were statically linked.
• Analysis Environment: An ideal sandbox should emulate the target environment, including architecture, libraries, OS, and crucially, privileges. Unlike Windows malware, Linux malware is often designed to run with root privileges, which makes standard unprivileged analysis challenging and can impact sandbox instrumentation.
• Lack of Previous Studies: The absence of prior comprehensive work made designing a tailored analysis pipeline and building a representative dataset difficult, as little was known beforehand about Linux malware characteristics and techniques.

The analysis infrastructure developed for the study was a trial-and-error process, incrementally building components based on observed issues. It included existing tools (AVClass, IDA Pro, radare2, Nucleus) and new custom tools. The pipeline involved:

1. Data Collection: Fetching ELF files from VirusTotal reports (Nov 2016 - Nov 2017).
2. File & Metadata Analysis: Parsing ELF headers to filter non-relevant files and identify anomalous structures used for anti-analysis. AVClass was used to normalize AV labels and identify malware families. Custom ELF parsers were needed due to issues with existing tools handling malformed headers.
3. Static Analysis: Analyzing binary code using IDA Pro scripts to extract metrics and identify packed samples.
4. Dynamic Analysis: Executing samples in instrumented sandboxes for different architectures (x86, x86-64, ARM, MIPS, PowerPC). Sandboxes supported different configurations, including user/root privileges and library setups (glibc/uClibc). SystemTap was used for kernel and user probes to collect syscall traces. Differential analysis was performed for samples showing privileges-related errors or identity probing, rerunning them with root privileges to observe behavioral changes. A tool based on Unicorn was developed for dynamic unpacking of UPX variants.

Key findings from the large dataset analysis include:

• Dataset Makeup: The 10,548 samples covered over ten architectures, with a distribution different from datasets based solely on honeypots. Samples varied widely in size and complexity. Botnets dominated the landscape (69%), spread across over 25 families, likely due to poorly secured IoT devices being harvested. Other categories included backdoors, ransomware, miners, bankers, file infectors, rootkits, and more.
• Low-Level Techniques: The study documented various techniques employed by malware authors, focusing on tricks rather than family-specific behaviors.
  • ELF Header Manipulation: Malware authors often tamper with ELF headers to evade analysis tools, creating either anomalous but valid files (e.g., removing section info, reporting false OS ABI) or invalid but executable files (e.g., corrupted section info, overlapping segments). This posed significant challenges for standard tools like readelf, pyelftools, and GDB.
  • Persistence: Around 21% of samples implemented persistence strategies. Common methods included modifying system initialization scripts (/etc/rc.d/, /etc/init.d/), time-based execution using cron, file infection/replacement of system tools (like ls, ps, netstat), and altering user configuration files (.bashrc, .desktop files). Achieving system-wide persistence often requires privileged permissions.
  • Deception: Over 50% of samples attempted to hide by changing their process names. Common impersonated names included sshd, telnetd, and cron. Samples used either prctl or modified command line arguments, but none combined both techniques, making them detectable through inconsistencies. Other samples used empty names or random-looking names.
  • Required Privileges: Running with root privileges significantly impacts behavior for many samples. Differential analysis comparing user and root execution traces showed that samples with root privileges could execute privileged shell commands, drop files into protected directories, achieve system-wide persistence, tamper with the sandbox, delete protected files, and run ptrace requests on other processes. While attempts to load custom kernel modules were observed, they often failed due to missing files. Attempts to load standard modules like ip_tables.ko were successful for a small number of samples. No successful privilege escalation exploits were detected in the patched sandbox environment, but attempts using known vulnerabilities like CVE-2016-5195 were identified.
  • Packing & Polymorphism: Packing was relatively prevalent (380 samples), with UPX and its variants being the dominant form (all but three packed samples). Variants often included cosmetic modifications like different magic numbers, modified strings, or inserted junk bytes to break standard UPX tools. A few samples from the Mumblehard family used custom packing.
  • Process Interaction: Samples frequently spawned multiple processes (75% of the dataset). 13% executed external shell commands, with common commands including sh, sed, cp, rm, grep, and ps, often used for persistence or killing other processes. Process injection techniques using ptrace (PTRACE_POKETEXT, PTRACE_ATTACH) or process_vm_writev were observed in a few samples, often targeting libc processes to inject dynamic libraries.
  • Information Gathering: Malware extensively gathered information from the /proc and /sysfs virtual file systems, particularly network configuration (/proc/net/route, /proc/net/tcp), system configuration (/proc/meminfo, /proc/cpuinfo, /proc/cmdline), and processes information (/proc/<PID>/stat, /proc/<PID>/cmdline). Configuration files in /etc were also frequently accessed, especially those related to persistence (/etc/rc.d/rc.local, /etc/crontab) and network configuration (/etc/resolv.conf, /etc/hosts). Access to /etc/passwd was also noted, used by some families like Flooder to check for/add backdoor accounts.
  • Evasion: While not highly prevalent (Table XIII indicates low percentages for sandbox detection, anti-debugging, and anti-execution), several evasion techniques were identified. Sandbox detection involved checking specific files in /sys and /proc for strings like "VMware", "VirtualBox", or "QEMU", or identifying container environments or chroot jails. Some samples exited upon detection, while others adopted aggressive behaviors like attempting to delete the file system. Process enumeration was performed by many samples but not for evasion purposes in this dataset. Anti-debugging techniques mainly involved using the ptrace syscall on themselves. Anti-execution was seen in samples comparing their filename to a hardcoded string. Stalling code using sleep functions was observed in 64% of binaries, but it appeared to be used for coordination rather than evasion delays.
  • Libraries: Over 80% of samples were statically linked, though surprisingly, most were not stripped of symbols, contrasting with complex Windows malware. Dynamically linked samples most commonly used glibc (74.21%) but also uClibc (24.24%) and libgcc (9.74%), reflecting targeting of embedded systems.

The study also highlighted significant intra-family variety, where samples belonging to the same family exhibited diverse characteristics, likely due to the public availability of source codes for some malware classes.

In conclusion, the paper provides a foundational study on the characteristics and behaviors of Linux malware, highlighting its growing importance, the challenges in analysis, and a number of low-level techniques used, while noting that current Linux malware is not as complex as its Windows counterpart but is incorporating similar techniques.

이 주제에 대한 대부분의 자료는 블로그 게시물과 같이 파편화된 보고서 형태로 존재하며, 특정 악성 코드 패밀리(예: Mirai 봇넷)에 대한 소수의 체계적인 연구는 주로 네트워크 수준의 동작에 초점을 맞추어 진행되었습니다. 이로 인해 Linux 악성 코드 분석의 주요 과제들은 해결되지 않은 상태로 남아있었습니다. 본 연구는 이러한 격차를 메우기 위한 첫걸음으로, Linux 악성 코드 분석에 특화된 분석 파이프라인을 설계하고 구현했으며, 1년간 수집된 10,548개의 악성 코드 샘플에 대한 대규모 측정 연구 결과를 제시합니다. 이 연구는 이 분야의 향후 작업 방향을 설정하는 데 도움이 될 수 있는 통계와 통찰력을 제공합니다.

Linux 악성 코드 분석의 주요 과제

일반적인 (그리고 잠재적으로 악의적인) Linux 프로그램을 분석하는 것은 여러 특정 과제를 해결해야 합니다.

• 대상 환경의 다양성 (Target Diversity): Windows, MacOS, Android 실행 파일 분석 시스템은 기본 실행 환경에 대한 자세한 정보에 의존할 수 있지만, Linux 기반 악성 코드는 인터넷 라우터, 프린터, 감시 카메라, 스마트 TV, 의료 기기 등 매우 다양한 대상을 타겟으로 할 수 있습니다. 대상 환경에 대한 적절한 정보 없이, 올바른 실행 환경을 구성하는 것은 매우 어렵습니다.
  • 컴퓨터 아키텍처 (Computer Architectures): Linux는 수십 가지의 다른 아키텍처를 지원하는 것으로 알려져 있습니다. 이로 인해 분석가는 다양한 분석 샌드박스를 준비하고 각 아키텍처에 맞는 분석 구성 요소를 포팅해야 합니다. 이전 Mirai 봇넷 연구에서는 MIPS 32비트, ARM 32비트, x86 32비트의 세 가지 아키텍처를 지원했지만, 이는 Linux 악성 코드 환경의 작은 부분만을 커버합니다. 본 데이터셋의 약 32%만이 이 세 아키텍처에 해당했습니다. ARM과 같은 일부 패밀리는 특히 다양한 CPU 아키텍처를 포함하고 있어 지원하기 어렵습니다.
  • 로더 및 라이브러리 (Loaders and Libraries): ELF 파일 형식은 Linux 프로그램이 임의의 로더를 지정할 수 있도록 허용하며, 이 로더는 실행 파일을 메모리에 로드하고 준비하는 역할을 합니다. 분석 환경에 요청된 로더의 복사본이 없으면, 샘플이 실행되지 못할 수 있습니다. 또한, 동적으로 링크된 바이너리는 대상 시스템에 필요한 라이브러리가 있어야 합니다. 라이브러리 하나만 없어도 프로그램 실행에 실패할 수 있습니다. 특히 uClibc 또는 musl과 같이 기존 glibc의 작고 성능이 좋은 대안을 사용하는 Linux 프로그램이 흔하며, 분석 환경에는 이러한 대안뿐만 아니라 해당 로더도 설치되어 있어야 합니다.
  • 운영 체제 (Operating System): 이 연구는 Linux 바이너리에 초점을 맞추지만, FreeBSD나 Android와 같이 다른 ELF 호환 운영 체제용으로 컴파일된 ELF 프로그램을 구분하는 것이 예상외로 어려울 수 있습니다. ELF 헤더의 "OS/ABI" 필드는 실행에 필요한 운영 체제를 지정해야 하지만, 실제로는 정보가 거의 유용하지 않습니다. Linux 및 Android용 ELF 바이너리는 일반적인 "System V" OS/ABI를 지정하며, 현재 Linux 커널은 이 필드를 무시하는 경향이 있습니다. "FreeBSD"를 OS/ABI로 지정한 바이너리도 유효한 Linux 프로그램일 수 있으며, 이는 실제 악성 코드 샘플에서 악용된 트릭입니다. FreeBSD용으로 컴파일된 바이너리는 Linux에서 로드 및 실행될 수 있지만, 이는 동적으로 링크된 프로그램에만 해당됩니다. Linux와 FreeBSD의 시스템 호출 번호와 인수가 일반적으로 일치하지 않으므로, 정적으로 링크된 프로그램은 이러한 차이를 만날 때 일반적으로 충돌합니다. 이러한 차이는 Linux 커널의 다른 버전 간에도 존재할 수 있으며, 임베디드 장치 세계에서는 사용자 정의 수정이 드물지 않습니다. 이는 Linux 기반 악성 코드 데이터셋을 컴파일하는 것을 어렵게 만들고, 잘 구성된 Linux 바이너리조차 일반적인 Linux 시스템에서 제대로 실행될 것이 보장되지 않는다는 결과를 낳습니다.
• 정적 링크 (Static Linking): 바이너리가 정적으로 링크되면, 모든 라이브러리 종속성이 컴파일 과정의 일부로 최종 바이너리에 포함됩니다. 정적 링크는 결과 바이너리의 이식성을 높이고 (종속성이 대상 환경에 설치되지 않은 경우에도 제대로 실행되기 때문에), 역공학을 더 어렵게 만들 수 있습니다. 정적 링크는 악성 코드 분석에 또 다른, 덜 명확한 과제를 도입합니다. 이러한 바이너리는 모든 라이브러리를 포함하므로, 결과 애플리케이션은 시스템 호출을 실행하기 위해 외부 래퍼에 의존하지 않습니다. 일반 프로그램은 시스템 호출을 직접 호출하지 않고, 대신 커널과의 통신을 래핑하는 상위 수준 API 함수(일반적으로 libc의 일부)를 호출합니다. 정적으로 링크된 바이너리는 라이브러리 종속성 관점에서 이식성이 높지만, 알려지지 않은 대상 시스템에서 제공되는 커널 ABI와 다른 경우 런타임에 충돌할 수 있어 이식성이 떨어집니다.
• 분석 환경 (Analysis Environment): 이상적인 분석 샌드박스는 분석 대상 샘플이 실행될 것으로 예상되는 시스템을 가능한 한 가깝게 에뮬레이트해야 합니다. 올바른 아키텍처, 라이브러리, 운영 체제를 갖춘 환경 설정의 과제 외에도, 프로그램이 실행되어야 하는 권한 수준은 중요한 측면입니다. 일반적으로 악성 코드 분석 샌드박스는 샘플을 일반적인 비특권 사용자로 실행합니다. 관리자 권한은 악성 코드가 샌드박스 자체를 조작할 수 있도록 하고, 프로그램 동작의 계측 및 관찰을 훨씬 더 복잡하게 만들 수 있습니다. 또한 Windows 샘플이 작동하기 위해 슈퍼유저 권한을 요구하는 경우는 매우 드뭅니다. 불행하게도 Linux 악성 코드는 임베디드 대상의 일부 클래스에서와 같이 root 권한으로 실행될 것이라는 가정하에 작성되는 경우가 많습니다. 그러나 이러한 세부 정보는 분석가에게 거의 제공되지 않으므로, 이러한 샘플을 사전에 식별하기 어렵습니다.

분석 인프라 및 방법론

Linux 기반 악성 코드 분석 인프라를 설계하고 구현하는 작업은 연구 시작 시점에 Linux 악성 코드가 어떻게 작동하고 어떤 기술과 구성 요소가 필요할지에 대해 아는 바가 거의 없었기 때문에 복잡했습니다. 예를 들어, 위에서 논의된 과제들을 사전에 알지 못했으며, 정적 링크나 잘못 형성된 파일 헤더와 같은 특정 특성의 만연성이나 분석 전략에 미치는 영향에 대해 종종 잘못된 기대를 가지고 있었습니다. Windows 및 Android용 악성 파일 분석에 대한 광범위한 경험에도 불구하고, Linux 기반 악성 코드에 대해서는 특정 패밀리의 수동 분석을 설명하는 온라인 보고서를 읽음으로써 얻은 일화적인 지식만 가지고 있었습니다. 따라서 분석 파이프라인의 설계 및 구현은 시행착오 과정이 되었고, 점진적인 접근 방식을 따라 해결했습니다.

각 분석 작업은 독립적인 구성 요소로 구현되었으며, 이는 여러 병렬 작업자 간에 작업 실행을 분산하고 인간 분석가가 데이터를 검사하고 시각화할 수 있는 풍부한 인터페이스를 제공하는 대화형 프레임워크에 통합되었습니다. 매일 더 많은 샘플이 분석 환경에 추가되면서, 시스템은 결과의 모든 이상 현상이나 기존 모듈 실행에서 발생한 문제(예: 새롭고 지원되지 않는 아키텍처, 샘플이 샌드박스에서 제대로 실행되지 못하게 하는 오류, 채택된 도구의 예기치 않은 충돌)를 식별하고 보고했습니다. 특정 문제가 상당수의 샘플 분석에 성공적으로 영향을 미칠 정도로 널리 퍼지면, 새로운 분석 모듈을 도입하고 문제를 해결하기 위한 새로운 기술을 설계했습니다. 프레임워크는 또한 특정 정보 추출에 책임이 있는 각 모듈의 버전을 추적하도록 설계되어, 매번 처음부터 실험을 다시 시작할 필요 없이 각 분석 루틴을 동적으로 업데이트하고 개선할 수 있었습니다.

최종 분석 파이프라인에는 AVClass, IDA Pro, radare2, Nucleus와 같은 기존 최첨단 솔루션뿐만 아니라, 이 연구를 위해 특별히 설계된 완전히 새로운 도구들도 포함되었습니다. 분석 기술은 파일 및 메타데이터 분석, 정적 분석, 동적 분석의 세 가지 그룹으로 구성됩니다.

데이터 수집: 연구 데이터는 VirusTotal intelligence API를 사용하여 2016년 11월부터 2017년 11월까지 제출된 모든 ELF 파일의 보고서를 가져와 수집되었습니다. 보고서 내용에 따라 매일 200개의 후보 샘플을 다운로드했습니다. 선택 기준은 비 Linux 바이너리를 최소화하고 당일 관찰된 각 패밀리에 대해 최소 하나의 샘플을 선택하도록 설계되었습니다. 또한 선택은 두 그룹으로 나뉘었습니다. 5개 이상의 AV 긍정 일치를 가진 샘플에서 140개, AV 점수가 1에서 5 사이인 샘플에서 60개였습니다.

데이터셋: 필터링 단계를 거친 최종 데이터셋은 10,548개의 ELF 실행 파일로 구성되었으며, 10가지 이상의 아키텍처를 포함했습니다 [49, Table I]. 이 데이터셋의 분포는 honeypots만 사용하여 수집된 다른 데이터셋과 다릅니다. 예를 들어, Mirai 봇넷에 대한 Antonakakis et al.의 데이터에서는 x86, ARM 32비트, MIPS 32비트가 데이터의 75%를 차지했지만, 본 연구 데이터셋에서는 32%에 불과했습니다. 데이터셋의 Linux 기반 악성 코드는 크기가 134바이트(단순한 백도어)에서 14.8MB(Go로 코딩된 봇넷)까지 다양했습니다. 동적으로 링크된 바이너리에서 IDA Pro는 최소 0개에서 최대 5685개의 고유 함수를 인식할 수 있었습니다. 대부분의 샘플은 10개에서 100개 사이의 심볼을 임포트했으며, 흥미롭게도 malloc은 사용하지만 free는 사용하지 않는 샘플이 10% 이상이었습니다. socket은 가장 흔한 함수 중 하나였지만, 파일 기반 루틴(예: fopen)을 요청하는 바이너리는 50% 미만이었습니다. 엔트로피는 잠재적인 패커 또는 암호화된 바이너리 블롭을 식별하는 데 중요한 역할을 하며, 데이터셋의 대부분의 바이너리는 컴파일되었지만 압축되지 않은 코드에 일반적인 값인 6 주변의 엔트로피를 가졌습니다.

악성 코드 패밀리: AVClass 도구는 데이터셋 샘플의 83%에 대해 패밀리(총 108개)를 연결할 수 있었습니다. 예상대로 DDoS 공격에 주로 사용되는 봇넷이 Linux 기반 악성 코드 환경을 지배하며, 샘플의 69%를 차지했고 25개 이상의 패밀리에 퍼져 있었습니다. 공격자들이 보호가 취약한 IoT 장치를 대규모 원격 제어 봇넷에 가입시키기 위해 악용하는 것이 이러한 만연의 한 가지 이유입니다. 또한, 일부 악성 코드 패밀리의 소스 코드가 공개적으로 사용 가능하다는 점도 변형 및 복제 소프트웨어의 수가 많아지는 이유일 수 있습니다. 봇넷 외에도 백도어, 랜섬웨어, 암호화폐 채굴기, 뱅커, 파일 감염기, 권한 상승 도구, 루트킷, 메일러, 웜, APT 캠페인에 사용되는 RAT 프로그램, CGI 기반 바이너리 웹쉘 등 다른 범주에 속하는 수천 개의 샘플도 데이터셋에 포함되어 있었습니다.

Linux 악성 코드의 세부 기술 및 특징

본 연구는 Linux 악성 코드에서 식별된 흥미로운 동작과 그 유병률에 대한 자세한 개요를 제시합니다. 목표는 악성 코드 클래스나 패밀리를 구분하는 것이 아니라, 패킹, 난독화, 프로세스 인젝션, 지속성, 회피 시도 등 악성 코드 작성자가 일반적으로 사용하는 트릭과 기술에 초점을 맞추는 것입니다.

• ELF 헤더 조작 (ELF headers Manipulation): ELF 형식은 모든 Linux 실행 파일을 저장하는 표준 형식이며, 일부 필드와 구조를 조작하여 분석 도구에 대한 첫 번째 방어선을 제공할 수 있습니다.
  • 비정상 ELF (Anomalous ELF): 가장 흔한 예(데이터셋의 5% 차지)는 ELF 섹션에 대한 모든 정보를 제거하는 것입니다. 이는 사양에 따라 유효하지만(섹션 정보는 런타임에 사용되지 않기 때문에), 전통적인 컴파일러에서는 생성되지 않는 드문 경우입니다. 다른 예는 실행 파일에 대한 잘못된 정보를 보고하는 것입니다. 예를 들어, Linux 프로그램은 다른 운영 체제 ABI(예: FreeBSD)를 보고하더라도 커널에 의해 올바르게 실행될 수 있습니다. Mumblehard 패밀리의 샘플은 헤더에서 FreeBSD를 요구한다고 보고하지만, 런타임에 시스템 호출 테이블을 테스트하여 실제 운영 체제를 감지하고 FreeBSD와 Linux 모두에서 올바르게 실행됩니다.
  • 잘못된 ELF (Invalid ELF): 이 범주에는 잘못 형성되거나 손상된 섹션 정보(데이터셋의 2% 차지)를 가진 샘플이 포함되며, 일반적으로 ELF 헤더의 잘못된 e_shoff, e_shnum, e_shentsize 필드의 결과입니다. 오버랩되는 세그먼트 헤더를 만들기 위해 ELF 헤더 파일 형식을 악용한 샘플의 증거도 발견되었습니다 [64, Table II].
  • 사용자 공간 도구에 미치는 영향 (Impact on Userspace Tools): readelf, pyelftools, GDB, IDA Pro 7과 같은 인기 있는 도구들은 비정상적인 파일은 제대로 처리할 수 있지만, 잘못된 필드를 다룰 때 오류가 발생하는 경우가 많습니다. 특히 GDB는 손상된 정보 처리에 심각한 탄력성 부족을 보였으며, IDA Pro 7만이 손상된 섹션 정보나 프로그램 실행에 영향을 미치지 않는 다른 필드를 올바르게 처리할 수 있었습니다. 연구팀은 이러한 문제 때문에 사용자 정의 ELF 파서를 작성했습니다.
• 지속성 (Persistence): 지속성은 감염된 시스템의 구성 변경을 통해 악성 실행 파일이 재부팅 또는 전원 차단 작업에 관계없이 실행될 수 있도록 하는 것입니다. 이는 숨겨진 상태를 유지하는 능력과 함께 악성 코드의 첫 번째 목표 중 하나입니다.
  • 하위 시스템 초기화 (Subsystems Initialization): 악성 코드 작성자가 채택한 가장 흔한 접근 방식입니다. 1000개 이상의 샘플이 시스템 rc 스크립트(각 실행 레벨 끝에 실행됨)를 수정하려고 시도했으며 [70, Table IV], 210개 샘플은 /etc/init.d/ 폴더 아래에 자신을 추가하고 실행 레벨 구성을 포함하는 디렉토리에 소프트 링크를 생성했습니다. 흥미롭게도 악성 프로그램은 여전히 System-V init 시스템에 크게 의존하며, systemd와 같은 최신 초기화 기술을 지원하는 샘플은 두 개에 불과했습니다. 이러한 유형의 지속성은 실행 프로세스가 권한 있는 권한을 가질 때만 작동합니다.
  • 시간 기반 실행 (Time-based Execution): Linux 시스템의 시간 기반 작업 스케줄러인 cron에 의존하는 두 번째 흔한 기술입니다. 악성 ELF 파일은 cron 구성 파일을 수정하여 고정된 시간 간격으로 실행되도록 시도합니다.
  • 파일 교체 및 감염 (File Infection and Replacement): 시스템에 발판을 유지하기 위한 또 다른 접근 방식은 대상에 이미 존재하는 애플리케이션을 교체(또는 감염)하는 것입니다. 여기에는 전통적인 바이러스와 유사한 동작뿐만 아니라, 특정 시스템 도구의 원래 기능을 전복시키는 보다 표적화된 접근 방식도 포함됩니다. EbolaChan 패밀리 샘플은 ls 도구의 시작 부분에 코드를 주입하고 원래 코드를 악성 데이터 뒤에 추가했습니다. RST, Sickabs 및 Diesel 패밀리는 20년 전 ELF 감염 기술을 여전히 사용했으며, 이 패밀리의 샘플은 오늘날에도 놀랍게 활동적인 것으로 나타났습니다. Gates 패밀리의 샘플은 /bin/ 또는 /usr/bin/ 폴더의 시스템 도구를 완전히 교체했습니다.
  • 사용자 파일 변경 (User Files Alteration): 데이터셋의 매우 적은 샘플이 ˜/.bashrc와 같은 사용자 홈 디렉토리의 구성 파일을 수정했습니다 [77, Table IV]. 이 방법을 채택하는 악성 코드 작성자는 사용자 수준에서 지속성을 확보할 수 있지만, 감염된 사용자 외의 다른 Linux 사용자는 이 지속성 메커니즘의 영향을 받지 않습니다. Handofthief 패밀리와 같은 일부 샘플은 대신 창 관리자가 사용하는 .desktop 시작 파일을 수정했습니다.
  • 연구 데이터셋의 ELF 파일 중 21%만이 하나 이상의 지속성 전략을 구현했습니다 [78, Table IV]. 그러나 지속성을 시도하는 샘플은 목표 달성을 위해 여러 기술을 연달아 시도하는 경우가 많았습니다.
• 속임수 (Deception): 스텔스 악성 코드는 언뜻 보기에 합법적이고 무해해 보이는 이름을 사용하여 자신을 숨기려 할 수 있습니다. 전반적으로, Windows 운영 체제에서 흔한 이 동작이 Linux 기반 악성 코드에서도 널리 퍼져 있음을 확인했습니다. 데이터셋의 50% 이상이 메모리에서 다른 이름을 사용했으며 [80, Table V], 상위 일반 애플리케이션을 가장했습니다 [81, Table V]. 4천 개 이상의 샘플이 prctl 시스템 호출을 PR_SET_NAME 요청과 함께 호출하거나 프로그램의 첫 번째 명령줄 인자를 수정했습니다. 이 중 11%는 일반적인 유틸리티의 이름을 사용했습니다.
• 요구되는 권한 (Required Privileges): 관리자(root)와 일반 사용자 간의 구분은 Linux 기반 악성 코드에 매우 중요합니다. 악성 샘플은 슈퍼유저 권한으로 실행될 때 다른 동작을 수행할 수 있으며, 특히 저가 임베디드 시스템이나 IoT 장치를 대상으로 할 때 악성 코드는 root로 실행되도록 설계될 수 있으며, 제한된 권한으로 분석될 경우 실행에 실패할 수 있습니다.
  • 연구팀은 먼저 모든 샘플을 일반 사용자 권한으로 실행했습니다. 실행 중 사용자 또는 그룹 ID를 검색하려는 시도(프로그램이 다음 작업을 결정하는 데 사용될 수 있음) 또는 EPERM 또는 EACCES 오류를 반환하는 리소스에 액세스하려는 시도를 감지하면, root 권한으로 샘플을 다시 분석했습니다. 이는 2637개 샘플(데이터셋의 25%)에 해당했으며, 이 중 89%에서 두 실행 추적에서 추출된 샘플 동작의 차이를 감지했습니다. root로 실행될 때 실행되지만 일반 사용자로 실행될 때는 관찰되지 않은 동작은 권한 있는 쉘 명령 및 파일 작업이 지배적이었습니다 [85, Table VII]. 악성 코드는 권한 상승을 사용하여 보호된 폴더에 파일을 생성하거나 삭제했습니다. 일부 사례에서는 root로 실행되는 악성 코드가 샌드박스 실행을 방해할 수 있었습니다. 에뮬레이션 환경 감지 시 SSH 데몬을 죽이거나 전체 파일 시스템을 삭제하는 바이너리를 발견했습니다.
  • 권한 상승 (Privileges Escalation): 커널 프로브를 사용한 동적 분석은 OS 커널의 함수를 추적할 수 있으므로, 성공적인 악용의 징후를 감지할 수 있습니다. 예를 들어, commit_creds를 모니터링하면 실행 중인 태스크에 새로운 자격 증명이 설치되었을 때 감지할 수 있습니다. 그러나 샌드박스는 최신 패치된 Linux OS로 배포되었으므로, 바이너리가 오래된 취약점을 악용하는 것을 방지했습니다. 추적 분석 결과, 머신 내에서 성공적으로 권한을 상승시키거나 사용자 자격 증명 하에서 권한 있는 작업을 수행할 수 있었던 샘플의 증거는 없었습니다. CVE-2016-5195가 가장 자주 사용된 취약점으로 나타났으며, 총 52개의 ELF 프로그램이 샌드박스에서 이를 악용하려고 시도했습니다. https://delinea.com/blog/linux-privilege-escalation
  • 커널 모듈 (Kernel Modules): 시스템 호출 추적은 샘플이 root 권한으로 실행될 때 커널 모듈을 로드 또는 언로드하려는 시도를 추적할 수 있도록 합니다. 2,637개 악성 코드 샘플 중 15개만이 커널 모듈을 성공적으로 로드했으며, 이는 IP 패킷 필터 규칙 설정에 필요한 표준 ip_tables.ko였습니다. Gates 또는 Elknot 패밀리에 속하는 119개 샘플은 사용자 정의 커널 모듈을 로드하려고 시도했지만, 분석 중 해당 .ko 파일이 없었기 때문에 실패했습니다.
• 패킹 및 다형성 (Packing & Polymorphism): 런타임 패킹은 악성 코드 작성자가 채택한 가장 흔하고 정교한 난독화 기술 중 하나입니다. Windows용 수백 개의 상업용, 무료, 지하 패커가 존재하지만, Linux 세계에서는 다릅니다. 현재까지 소수의 ELF 패커만 제안되었으며, 대부분은 개념 증명 프로젝트입니다. 유일한 예외는 UPX로, 많은 운영 체제에서 사용할 수 있는 인기 있는 오픈 소스 압축 패커입니다.
  • UPX 변형 (UPX Variations): 바닐라 UPX 및 그 변형은 데이터셋에서 가장 널리 퍼진 형태의 패킹입니다. 380개의 패킹된 바이너리 중 3개만이 이 범주에 속하지 않았습니다 [94, Table VIII]. UPX 언패킹 도구를 깨뜨리기 위해 UPX 형식에 가해진 수정 사항에는 매직 넘버 수정, UPX 문자열 수정, 정크 바이트 삽입이 포함됩니다. 그러나 이러한 샘플은 모두 동일한 기본 패킹 구조와 압축 알고리즘을 공유하며, 악성 코드 작성자가 단순히 오픈 소스 UPX 코드에 "외관상의" 변형을 적용했음을 보여줍니다.
  • 사용자 정의 패커 (Custom packers): Linux에는 공개적으로 사용 가능한 다양한 패커가 많지 않으며 UPX가 일반적으로 주요 선택입니다. 그러나 사용자 정의 패킹 형태를 구현한 세 개 샘플(모두 Mumblehard 패밀리에 속함)을 감지했습니다.
• 프로세스 상호 작용 (Process Interaction): Linux 악성 코드가 하위 프로세스 또는 시스템에 이미 설치되거나 실행 중인 다른 바이너리와 상호 작용하는 데 사용하는 기술을 다룹니다.
  • 다중 프로세스 (Multiple Processes): 데이터셋 샘플의 25%는 단일 프로세스로 구성되며, 9%는 새 프로세스를 생성하고, 43%는 총 세 개의 프로세스(프로그램을 데몬화하는 데 사용되는 "이중 fork" 패턴 때문)를 포함하며, 나머지 23%는 더 많은 수의 별도 프로세스를 생성했습니다. 여러 프로세스를 생성하는 샘플 중에는 Gafgyt, Tsunami, Mirai, XorDDos와 같은 인기 있는 봇넷이 많이 있습니다.
  • 쉘 명령 (Shell Commands): 샌드박스 내에서 분석된 샘플의 13%가 하나 이상의 외부 쉘 명령을 실행했습니다. 총 93개의 고유 명령줄 도구 실행을 등록했으며 [99, Table IX], 이 중 가장 흔한 것은 sh, sed, cp, rm, grep, ps, insmod, chmod, cat, iptables였습니다 [99, Table IX]. sed, cp, chmod와 같은 명령은 대상 시스템에서 지속성을 달성하는 데 자주 실행되며, rm은 샘플 자체의 링크를 해제하거나 bash 기록 파일을 삭제하는 데 사용됩니다.
  • 프로세스 인젝션 (Process Injection): 공격자는 실행 중인 프로세스에 새 코드를 주입하여 동작을 변경하거나, 샘플 디버깅을 더 어렵게 만들거나, 흥미로운 함수를 후킹하여 정보를 훔칠 수 있습니다. 연구팀은 다른 프로그램의 메모리에 쓰기 위해 프로세스가 사용할 수 있는 세 가지 다른 기술을 모니터링했습니다. 데이터셋에서 첫 번째 기술(ptrace syscall)을 사용하여 인젝션을 수행하는 샘플 하나를 발견했습니다. 이 샘플은 libc를 사용하는 모든 활성 프로세스에 동적 라이브러리를 주입했으며, 주입된 페이로드에서 __libc_dlopen_mode 함수를 사용하여 런타임에 동적 객체를 로드했습니다.
• 정보 수집 (Information Gathering): 정보 수집은 수집된 정보를 사용하여 샌드박스 존재를 감지하거나 샘플 실행을 제어할 수 있으므로 악성 코드 실행의 중요한 단계입니다. 시스템에 저장된 데이터는 C&C 서버에 의해 제어되는 프로그램에서 흔히 발생하듯이 원격 위치로 유출될 수도 있습니다.
  • Proc 및 Sysfs 파일 시스템 (Proc and Sysfs File Systems): proc 및 sysfs 가상 파일 시스템은 각각 프로세스, 시스템 및 하드웨어 구성에 대한 런타임 시스템 정보와 커널 하위 시스템, 하드웨어 장치 및 커널 드라이버에 대한 정보를 포함합니다. 네트워크 관련 정보(예: /proc/net/route, /proc/net/tcp, /proc/net/dev)가 데이터셋에서 가장 흔했으며 [106, 107, Table X], 시스템 구성 정보(예: 메모리 양, CPU 코어 수, CPU 특성)가 두 번째로 흔했습니다 [108, Table X, XI]. 프로세스 열거(예: ps 명령 실행, /proc/ 디렉토리 스캔)는 악성 코드의 여러 실행을 방지하거나 대상 머신에서 실행 중인 다른 관련 프로그램을 식별하는 데 사용됩니다.
  • 구성 파일 (/etc) (Configuration Files): /etc/ 폴더에 포함된 시스템 구성 파일 중에서 지속성을 달성하는 데 필요한 파일(예: /etc/rc.d/rc.local, /etc/rc.conf)이 가장 자주 액세스되었습니다 [111, Table XII]. /etc/resolv.conf (DNS resolver) 또는 /etc/hosts (호스트와 IP 주소 매핑)와 같은 네트워크 관련 구성 파일도 인기가 있었습니다. /etc/passwd (등록된 계정 목록)도 상위 항목에 포함되었으며, Flooder 샘플은 시스템에 백도어 계정 존재를 확인하기 위해 이를 사용했습니다. 계정을 찾지 못하면 /etc/passwd 및 /etc/shadow에 직접 작성하여 새 사용자를 추가했습니다.
• 회피 (Evasion): 회피의 목적은 악의적인 행동을 숨기고 가능한 한 오랫동안 감지되지 않는 것입니다. 이는 일반적으로 샘플이 분석 도구 존재를 감지하거나 분석 환경 또는 실제 대상 장치에서 실행 중인지 구별하는 것을 요구합니다.
  • 샌드박스 감지 (Sandbox Detection): 문자열 비교 계측은 시스템에서 추출된 정보를 "VMware" 또는 "QEMU"와 같은 문자열과 비교하여 샌드박스 존재를 감지하려는 여러 프로그램을 감지했습니다. /sys/class/dmi/id/product name, /sys/class/dmi/id/sys vendor 등 파일에서 정보가 수집되었습니다 [114, Table XIV]. 일부 샘플은 가상 환경에서 실행 중임을 감지하면 종료하기로 결정했지만, 다른 샘플은 파일 시스템 전체를 삭제하려는 것과 같은 더 공격적인 접근 방식을 채택했습니다.
  • 프로세스 열거 (Processes Enumeration): 데이터셋에서 /proc/ 디렉토리를 전체 스캔하는 259개 샘플을 발견했지만, 샘플 중 어느 것도 회피 목적으로 이러한 스캔을 수행하는 것으로 보이지 않았습니다. 대신 머신이 이미 감염되었는지 확인하거나 죽일 대상 프로세스를 식별하기 위해 사용되었습니다.
  • 안티 디버깅 (Anti-Debugging): 가장 흔한 안티 디버깅 기술은 ptrace 시스템 호출을 기반으로 하며, 이는 디버거에게 대상 프로세스에 "연결"할 수 있는 기능을 제공합니다. 악성 코드가 사용하는 흔한 회피 기술 중 하나는 ptrace 시스템 호출을 PTRACE_TRACEME 또는 PTRACE_ATTACH 플래그와 함께 자신에게 호출하여 다른 디버거가 이미 연결되어 있는지 감지하거나 샘플이 실행되는 동안 연결을 방지하는 것입니다. 이 메커니즘을 사용하는 63개 샘플을 발견했습니다. 또한 LD_PRELOAD 환경 변수 존재를 확인하는 샘플 하나를 식별했습니다.
  • 안티 실행 (Anti-Execution): DnsAmp 악성 코드 패밀리에 속하는 샘플은 자신의 파일 이름과 하드코딩된 문자열을 비교하는 것 외에는 어떤 동작도 보이지 않았습니다. 악성 코드 작성자는 많은 악성 코드 수집 인프라 및 분석 샌드박스가 분석 전에 파일을 이름을 변경하기 때문에 이러한 트릭을 회피 솔루션으로 사용했습니다.
  • 정체 코드 (Stalling Code): Windows 악성 코드는 종종 "정체 코드"를 사용하여 악의적인 행동 실행을 지연시키는 것으로 알려져 있습니다. 연구팀은 nanosleep 시스템 호출을 사용하는 64%의 바이너리를 발견했지만, 그 중 어느 것도 이러한 지연을 실행 정체에 사용하는 것으로 보이지 않았습니다. 대신 하위 프로세스 또는 네트워크 통신을 조정하는 데 사용되었습니다.
• 라이브러리 (Libraries): 실행 파일이 라이브러리를 사용하는 주요 방법은 동적 링크와 정적 링크 두 가지가 있습니다. 데이터셋 샘플의 80% 이상이 정적으로 링크되었습니다. 그러나 이러한 샘플 중 24%만이 심볼이 제거되었으며, 나머지는 개발자가 사용한 함수 및 변수 이름까지 포함하는 경우가 많았습니다. 동적으로 링크된 샘플의 경우 33%만이 심볼이 제거되었습니다. 악성 코드 개발자들이 수동 분석에 대한 코드를 난독화하려는 동기가 부족하다는 이 추세는 회피적인 Windows 악성 코드의 복잡성과 날카로운 대조를 이룹니다.
  • 일반적인 라이브러리 (Common Libraries): 데이터셋에서 악성 코드 샘플이 가장 자주 임포트하는 동적 라이브러리에는 glibc (74.21%), uclibc (24.24%), libgcc (9.74%) 등이 포함됩니다 [123, Table XV]. 이는 GNU C 라이브러리(glibc)가 가장 많이 요청되는 라이브러리이지만, 임베디드 시스템에서 자주 사용되는 uClibc와 같은 작은 구현에 링크되는 샘플이 24%라는 것을 보여줍니다. 또한 GCC 컴파일러가 대상 프로세서가 직접 수행할 수 없는 산술 연산을 처리하는 데 사용하는 libgcc에 거의 10%의 데이터셋이 링크된다는 점도 흥미롭습니다. 이는 데스크톱 환경에서는 드물게 사용되지만, 부동 소수점 연산을 지원하지 않는 아키텍처를 가진 임베디드 장치에서 자주 사용됩니다.

가족 내 다양성 (Intra-Family Variety): 같은 패밀리에 속하는 샘플조차도 종종 매우 다른 특성을 가지고 있음을 확인했습니다. 이는 여러 Linux 악성 코드 클래스의 소스 코드가 사용 가능하다는 점 때문일 수 있습니다. 예를 들어, 데이터셋에 743개의 샘플이 있는 인기 있는 Tsunami 악성 코드 패밀리의 경우, 샘플들은 9가지 다른 아키텍처(가장 흔한 것은 x86-64, 가장 드문 것은 Hitachi SuperH)용으로 컴파일되었습니다. 이 중 86%가 정적으로 링크되었고 13%가 심볼이 제거되었습니다. 동적으로 링크된 Tsunami 샘플은 다른 로더에 의존했으며, 엔트로피는 1.85에서 7.99까지 다양했습니다. 이러한 가변성은 정적 특징에만 국한되지 않았습니다. 동적 추적에서 일부 샘플은 사용자 수준 지속성에만 의존하고 다른 샘플은 시스템 전체 지속성을 위해 실행 레벨 스크립트나 cron 작업을 사용하는 등 다른 지속성 기술 사용을 확인했습니다.

결론: 이 연구는 Linux 기반 악성 코드에 대한 첫 번째 포괄적인 연구를 제시합니다. Linux 악성 코드에 특화된 첫 번째 분석 파이프라인의 설계 및 구현을 문서화하고, Linux 악성 코드가 악의적인 행동을 구현하는 방법에 대한 첫 번째 대규모 경험적 연구 결과를 논의합니다. 현재 Linux 악성 코드의 복잡성은 그리 높지 않지만, Windows 악성 코드에서 빌린 기술을 이미 채택하고 있는 여러 샘플을 식별했습니다. 이러한 통찰력은 이 분야의 보다 체계적인 미래 연구의 기반이 될 수 있으며, 불행히도 중요성이 점점 더 커질 수밖에 없습니다.