Skip to content

Instantly share code, notes, and snippets.

@iidx
Last active November 14, 2020 05:46
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save iidx/b803a48eaa1a8e2a463a27eb102d4ea8 to your computer and use it in GitHub Desktop.
Save iidx/b803a48eaa1a8e2a463a27eb102d4ea8 to your computer and use it in GitHub Desktop.

To solve the problem, focus on what malware did to the registry after 2020 November 7 14:00 (UTC+9) .Therefore, it is intended to be found using the 'last modification time' of the subkey.

문제를 해결하기 위해선, 2020년 11월 7일 14시(UTC+9) 시각 이후에 실행된 악성코드가 레지스트리에 어떤 행위를 수행하였는가에 초점을 맞추면 됩니다. 따라서, 레지스트리의 마지막 키 수정 시각을 이용해 찾을 수 있도록 의도하였습니다.

The registry hive file in problem is not analyzed by normal registry analysis tools. the analysis tool should be able to load the registry transaction log file with the hive.

해당 문제의 레지스트리 하이브 파일은 일반적인 레지스트리 분석 도구로 분석되지 않습니다. 분석 도구가 레지스트리 트랜젝션 로그 파일을 하이브와 함께 로딩할 수 있어야합니다.

Registry transaction log files serve as a journal to temporarily store data before it is written to the registry hive. If the registry hive is locked, it cannot be written directly, so use that method. You can check the transaction log format from the following link.

레지스트리 트랙잭션 로그 파일은 데이터가 레지스트리 하이브에 기록되기 전에 임시적으로 데이터를 저장하는 저널 역할을 합니다. 레지스트리 하이브가 잠김 상태일 경우 직접 쓸 수 없기 때문에 해당 방식을 사용합니다. 트랜젝션 로그 형식은 다음 링크에서 확인하실 수 있습니다.

Therefore, in the case of a live system, data may only exist in the transaction log, not in the registry hive. so, collecting transaction log files in a live response environment is very important.

따라서 라이브 시스템인 경우, 레지스트리 하이브에는 존재하지 않고 트랜젝션 로그에만 데이터가 존재할 수 있습니다. 그래서 라이스 리스폰스 환경에서의 트랜젝션 로그 파일 수집은 매우 중요합니다.

In general, 'Registry Explorer' is used as a tool that loads the registry transaction log and registry hive together, but it can also be done with the python library python-registry.

일반적으로 레지스트리 트랙젝션 로그와 레지스트리 하이브를 같이 로딩시키는 도구로는 'Registry Explorer'가 사용되지만, python 라이브러리인 python-registry으로도 할 수 있습니다.

import io
from datetime import datetime
from Registry import Registry, RegistryLog


BASE_PATH = "Users\\ronron"
HIVE_FILE = f"{BASE_PATH}\\NTUSER.DAT"
LOG1_FILE = f"{BASE_PATH}\\ntuser.dat.LOG1"
LOG2_FILE = f"{BASE_PATH}\\ntuser.dat.LOG2"

primary = io.BytesIO()
with open(HIVE_FILE, 'rb') as f:
    primary.write(f.read())

primary.seek(0)
log1 = RegistryLog.RegistryLog(primary, LOG1_FILE)
primary.seek(0)
log2 = RegistryLog.RegistryLog(primary, LOG2_FILE)
primary.seek(0)

seqnum = log1.recover_hive()
seqnum = log2.recover_hive_continue(seqnum + 1)

primary.seek(0)
reg = Registry.Registry(primary)

def recursive_search(key):
    if key.timestamp() > datetime(2020, 11, 7, 5, 0, 0):
        print(key.path(), key.timestamp())
        for value in key.values():
            print(value.name(), value.raw_data())
    for subkey in key.subkeys():
        recursive_search(subkey)

recursive_search(reg.root())

If you check all the subkeys, you can see a unusual subkey called SOFTWARE\Microsoft\CTF\disas. There are values of Code00~Code100 in this subkey. These values are the executable file cut into 101 pieces, which can be judged to be stored separately for the purpose of evading detection by AV.

최하위 서브키를 모두 확인해보면 SOFTWARE\Microsoft\CTF\disas 라는 특이한 서브 키를 확인하실 수 있습니다. 이 서브키에는 Code00~Code100 이라는 값이 존재합니다. 해당 값들은 실행 파일을 101조각으로 분해한 것으로, 이는 AV의 탐지를 회피할 목적으로 분리해서 저장한 것으로 판단할 수 있습니다.

...
data = []
def recursive_search(key):
    if key.path() == "ROOT\SOFTWARE\Microsoft\CTF\disas":
        for value in key.values():
            data.append(value.raw_data())
    for subkey in key.subkeys():
        recursive_search(subkey)

recursive_search(reg.root())

with open("disas.exe", 'wb') as f:
    f.write(b"".join(data))

-The answer is Bingo{20A4FE4054CE35A4434C31372738E806642A9751}.

정답은 파일의 SHA 해시인 Bingo{20A4FE4054CE35A4434C31372738E806642A9751} 입니다.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment