New versions of your favourite open source DFIR tools – the Sleuth Kit and Autopsy, – have been released.


The Sleuth Kit 4.4.2


New Features:


usnjls tool for NTFS USN log (from noxdafox)

Added index to mime type column in DB

Use local SQLite3 if it exists (from uckelman-sf)

Blackboard Artifacts have a shortDescription metho

Bug Fixes:


Fix for highest HFS+ inum lookup (from uckelman-sf)

Fix ISO9660 crash

various performance fixes and added thread safety checks

Autopsy 4.4.1


Beta version of new central repository feature has been added for correlating artifacts across

cases; results are displayed using an Interesting Artifacts branch of the Interesting Items tree and an Other Data Sources content viewer.

Results viewer (top right area of desktop application) sorts are persistent and can be applied to either the table viewer or the thumbnail viewer.

The View Source File in Directory context menu item now works correctly.

Tagged image files in the HTML report are now displayed full-size.

Case deletion is now done using a Case menu item and both single-user and general (not auto ingest) multi-user cases can be deleted.

Content viewers (bottom right area of desktop application) now resize correctly.

Some potential deadlocks during ingest have been eliminated.

Assorted performance improvements, enhancements, and bug fixes.

저작자 표시
신고
블로그 이미지

Ryansecurity Ryansecurity

Life is fun security story

artefact 파일 문제 풀이 

아래 명령어로 파일 확인

xz 파일 형태 

xz 는 무손실 데이터 압축 프로그램 및 LZMA2 압축 알고리즘 파일 형식이다.

XZ는 7-Zip 프로그램의 축소 된 버전으로 간주 할 수 있다.

참고 링크 : https://ko.wikipedia.org/wiki/Xz


파일확장자를 xz 형태로 바꿈 


unxz 명령어를 이용 압축해제 

file 명령어 이용 파일 확인

Linux rev 1.0 ext3 확인됨 

extundelete artefact --restore-all 명령어로 파일 복구 

ls 명령어 이용 복원된 파일 확인

파일 복원 된 것을 확인

 .junk files 파일 찾는다 .


flag text is somewhere inside  


./ts8U/c0pmcYvxe  여기를 확인하여 본다.


파일 헤더 확인

JFIF (JPEG) 파일 형태라는 것을 알수 있음

파일을 복구 (00 00 -> FF D8)


복원 완료 

JPG 확인하면 Flag 값 확인 가능 





저작자 표시
신고
블로그 이미지

Ryansecurity Ryansecurity

Life is fun security story

In the past it was possible to acquire memory from linux systems by directly imaging (with dd) psudo-device files such as /dev/mem and /dev/kmem. In later kernels, this access was restricted and/or removed. To provide investigators and system administrator’s unrestricted access, loadable kernel modules were developed and made available in projects such as fmem and LiME (Linux Memory Extractor).

In this blog post I will introduce you to a scenario where LiME is used to acquire memory from a CentOS 6.5 x64 system that is physically hosted in another continent. 

LiME is a Loadable Kernel Module (LKM). LKM’s are typically designed to extend kernel functionality, and can be inserted by a user with root privileges. This sounds a little scary, and it does introduce tangible risks if done wrong. But on the positive side:

  • the LiME compiled LKM is rather small
  • the process does not require a restart
  • the LKM can be added/removed quickly
  • the resulting memory dump can be transferred over the network without writing to the local disk; and
  • the memory dump is compatible with Volatility



Getting LiME

Since LiME is distributed as source without any binaries you need to compile it yourself. You will find documentation on the internet suggesting that you jump right in and compile LiME on your target system. I recommend you first see if a pre-compiled LKM exists, or alternatively compile and test in a virtual machine first.

In either case, you first need to determine the kernel running on your target system, as the LKM you use must have been compiled on the the exact operating system, kernel version and architecture. Here we determine our target is running the kernel 2.6.32-431.5.1.el6.x86_64.

[centos@targetsystem ~]$ uname -a
Linux localhost.localdomain 2.6.32-431.5.1.el6.x86_64 #1 SMP Wed Feb 12 00:41:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux



One great reputable resource for pre-compiled LiME LKM’s is the Linux Forensics Tools Repository at Cert.org. They provide a RPM repository of forensic tools for Red Hat Enterprise Linux, CentOS and Fedora.

To check to see your specific kernel is compiled for your operating system, visit Cert and find the “repoview” for your target operating system.



Browse to “applications/forensics tools” and view the documentation on “lime-kernel-objects”. 

As of today's date the following kernels have pre-compiled LiME LKM’s for CentOS 6 / RHEL 6:

2.6.32-71
2.6.32-71.14.1
2.6.32-71.18.1
2.6.32-71.24.1
2.6.32-71.29.1
2.6.32-71.7.1
2.6.32-131.0.15
2.6.32-220
2.6.32-279
2.6.32-358.0.1
2.6.32-358.11.1
2.6.32-358.14.1
2.6.32-358.18.1
2.6.32-358.2.1
2.6.32-358.23.2
2.6.32-358.6.1
2.6.32-431
2.6.32-431.1.2.0.1
2.6.32-431.3.1



Oh no! The kind folks at Cert are not completely up to date, and my target system is running a newer kernel. That means I have to do the heavy lifting myself. 

I installed CentOS 6.5 x64 in a virtual machine and updated until I had the latest kernel matching 2.6.32-431.5.1.el6.x86_64.

[root@vmtest ~]$ yum update
[root@vmtest ~]$ yum upgrade



Since this was a kernel upgrade, I gave my virtual machine a reboot.

[root@vmtest ~]$ shutdown -r now



We now have the matching kernel, but we still need the associated kernel headers and source as well as the tools needed for compiling.

[root@vmtest ~]$ yum install gcc gcc-c++ kernel-headers kernel-source




Now we are finally ready to download and compile our LiME LKM!

[root@vmtest ~]# mkdir lime; cd lime
[root@vmtest lime]# wget https://lime-forensics.googlecode.com/files/lime-forensics-1.1-r17.tar.gz
[root@vmtest lime]# tar -xzvf lime-forensics-1.1-r17.tar.gz  
[root@vmtest lime]# cd src 
[root@vmtest src]# make
….
make -C /lib/modules/2.6.32-431.5.1.el6.x86_64/build M=/root/lime/src modules
…
[root@vmtest src]# ls lime*.ko
lime-2.6.32-431.5.1.el6.x86_64.ko



Conducting a test run

We can now test out our newly built LiME LKM on our virtual machine by loading the kernel module and dumping memory to a local file.

We are opting to create our memory image on the local file system, so I provide the argument path=/root/mem.img. LiME supports raw, padded and “lime” formats. Since volatility supports the lime format, I have provided the argument format=lime.

[root@vmtest ~]# insmod lime-2.6.32-431.5.1.el6.x86_64.ko "path=/root/mem.img format=lime"



I have validated the memory images matches the amount of RAM I allocated to the virtual machine (1GB) and that it contains valid content.

[root@vmtest ~]# ls -lah /root/mem.img 
-r--r--r--. 1 root root 1.0G Mar  9 08:11 /root/mem.img
[root@vmtest ~]# strings /root/mem.img | head -n 3
EMiL
root (hd0,0)
kernel /vmlinuz-2.6.32-431.5.1.el6.x86_64 ro root=/dev/mapper/vg_livecd-lv_root rd_NO_LUKS 



I can now remove the kernel module with one simple command:

[root@vmtest ~]# rmmod lime



Acquiring memory over the internet

Now we return to our scenario where we are trying to capture memory from a CentOS server on another continent. I opted to upload LiME LKM to a server I control and then download it via HTTP.

[root@targetserver ~]# wget http://my.server-on-the-internet.com/lime-2.6.32-431.5.1.el6.x86_64.ko




The great thing about LiME is that it is not limited to just output to a local disk or physical file. In our test run we supplied an output path with the argument path=/root/mem.img. We will instead create a TCP service using the argument path=tcp:4444.

[root@targetserver ~]# insmod lime-2.6.32-431.5.1.el6.x86_64.ko "path=tcp:4444 format=lime"




If I were situated within our clients network or port 4444 was open over the internet, I could simply use netcat to connect and transfer the memory image to my investigative laptop. 

[dan@investigativelaptop ~]# nc target.server.com 4444 > /home/dan/evidence/evidence.lime.img




Since in this scenario our server is on the internet, and a restrictive firewall is inline we are forced to get creative.

Remember how I downloaded the LiME LKM to the target server via HTTP (port 80)? That means the server can make outbound TCP connections via that port.

I can setup a netcat listener on my investigative laptop here in our lab, and opened it up to the internet. I did this by configuring my firewall to pass traffic on this port to my local LAN address, and you can achieve the same results with most routers designed for home/small office with port forwarding.

Step 1: setup netcat server at our lab listening on port 80.

[dan@investigativelaptop ~]# nc –l 80 > /home/dan/evidence/evidence.lime.img



Step 2: Run LiME LKM and configure it to wait for TCP connections on port 4444.

[root@targetserver ~]# insmod lime-2.6.32-431.5.1.el6.x86_64.ko "path=tcp:4444 format=lime"



On the target server I can now use a local netcat connection that is piped to a remote connection in our lab via port 80 (where 60.70.80.90 is our imaginary lab IP address.)

Step 3: In another shell initiate the netcat chain to transfer the memory image to my investigative laptop at our lab.

[root@targetserver ~]# nc localhost 4444 | nc 60.70.80.90 80




Voila! I now have a memory image on my investigative laptop and can start my analysis.

Below is a basic visualization of the process:



Memory Analysis with Volatility

Volatility ships with many prebuilt profiles for parsing memory dumps, but they are focused exclusively the Windows operating system. To perform memory analysis on a sample collected from linux, we need to first create a profile that matches the exact operating system, kernel version and architecture (surprise, surprise!) So let’s head back to our virtual machine where we will need to collect the required information to create a linux profile: 

  • the debug symbols (System.map*);
    • Requirements: access to the test virtual machine system running on the same operating system, kernel version and architecture
  • and information about the kernel’s data structures (vtypes).
    • Requirements: Volatility source and the necessary tools to compile vtypes running on the same operating system, kernel version and architecture.



First let’s create a folder for collection of required files.

cd ~
mkdir -p volatility-profile/boot/
mkdir -p volatility-profile/volatility/tools/linux/



Now let’s collect the debug symbols. On a CentOS system it is located in /boot/ directory. We will need to find the System.map* file that matches the active kernel version that was running when we collected the system memory (2.6.32-431.5.1.el6.x86_64).

[root@vmtest ~]# cd /boot/
[root@vmtest boot]# ls -lah System.map*
-rw-r--r--. 1 root root 2.5M Feb 11 20:07 System.map-2.6.32-431.5.1.el6.x86_64
-rw-r--r--. 1 root root 2.5M Nov 21 22:40 System.map-2.6.32-431.el6.x86_64



Copy the appropriate System.map file to the collection folder.

[root@vmtest boot]# cp System.map-2.6.32-431.5.1.el6.x86_64 ~/volatility-profile/boot/



One of the requirements to compile the vtypes is libdwarf. While this may be easily installed on some operating systems using apt-get or yum, CentOS 6.5 requires that we borrow and compile the source from the Fedora Project. The remaining prerequisites for compiling should have been installed when we compiled LiME earlier in the section Getting LiME.

[root@vmtest boot]# cd ~
[root@vmtest ~]# mkdir libdwarf
[root@vmtest libdwarf]# cd libdwarf/
[root@vmtest libdwarf]# wget http://pkgs.fedoraproject.org/repo/pkgs/libdwarf/libdwarf-20140208.tar.gz/4dc74e08a82fa1d3cab6ca6b9610761e/libdwarf-20140208.tar.gz
[root@vmtest libdwarf]# tar -xzvf libdwarf-20140208.tar.gz 
[root@vmtest dwarf-20140208]# cd dwarf-20140208/
[root@vmtest dwarf-20140208]#./configure
[root@vmtest dwarf-20140208]# make
[root@vmtest dwarfdump]# cd dwarfdump
[root@vmtest dwarfdump]# make install




Now we can obtain a copy of the Volatility source code and compile the vtypes.

[root@vmtest dwarfdump]# cd ~
[root@vmtest ~]# mkdir volatility
[root@vmtest ~]# cd volatility
[root@vmtest volatility]# cd volatility
[root@vmtest volatility]# wget https://volatility.googlecode.com/files/volatility-2.3.1.tar.gz
[root@vmtest volatility]# tar -xzvf volatility-2.3.1.tar.gz
[root@vmtest volatility]# cd volatility-2.3.1/tools/linux/
[root@vmtest linux]# make



After successfully compiling the vtypes, we will copy the resulting module.dwarf back out to the collection folder.

[root@vmtest linux]# cp module.dwarf ~/volatility-profile/volatility/tools/linux/



Now that we have our collected the two requirements to create a system profile, let’s package them into a ZIP file, as per the requirements of Volatility.

[root@vmtest linux]# cd ~/volatility-profile/
[root@vmtest volatility-profile]# zip CentOS-6.5-2.6.32-431.5.1.el6.x86_64.zip boot/System.map-2.6.32-431.5.1.el6.x86_64 volatility/tools/linux/module.dwarf 
  adding: boot/System.map-2.6.32-431.5.1.el6.x86_64 (deflated 80%)
  adding: volatility/tools/linux/module.dwarf (deflated 90%)




On my investigative laptop I could drop this ZIP file in the default volatility profile directory, but I would rather avoid losing it in the future due to upgrades/updates. I instead will create a folder to manage my custom profiles and reference it when running volatility.

[dan@investigativelaptop evidence]# mkdir -p ~/.volatility/profiles/
cp CentOS-6.5-2.6.32-431.5.1.el6.x86_64.zip ~/.volatility/profiles/



Now I can confirm Volatility recognizes providing the new plugin directory.

[dan@investigativelaptop evidence]# vol.py --plugins=/home/dan/.volatility/profiles/ --info | grep -i profile | grep -i linux
Volatility Foundation Volatility Framework 2.3.1
LinuxCentOS-6_5-2_6_32-431_5_1_el6_x86_64x64 - A Profile for Linux CentOS-6.5-2.6.32-431.5.1.el6.x86_64 x64



Now I can start running the linux_ prefixed plugins that come shipped with Volatility to conduct memory analysis.

dan@investigativelaptop evidence]# vol.py --plugins=/home/dan/.volatility/profiles/ --profile=LinuxCentOS-6_5-2_6_32-431_5_1_el6_x86_64x64 linux_cpuinfo -f /home/dan/evidence/evidence.lime.img
Volatility Foundation Volatility Framework 2.3.1
Processor    Vendor           Model
------------ ---------------- -----
0            GenuineIntel     Intel(R) Xeon(R) CPU           X5560  @ 2.80GHz
1            GenuineIntel     Intel(R) Xeon(R) CPU           X5560  @ 2.80GHz





About the Author

Dan Caban (EnCE, CCE, ACE) works as a Principal Consultant at McAfee Foundstone Services EMEA based out of Dubai, United Arab Emirates.

References


저작자 표시 비영리 변경 금지
신고
블로그 이미지

Ryansecurity Ryansecurity

Life is fun security story

첫째, 우리는 SYN 공격 이 무엇인지 이해해야한다 . 우리 공격자의 IP 주소의리스트를 보내기때문에 (임의의 순서로, 공백으로 구분) 그래서 우리는 그들을 추적하고 그들을 막을 수 있습니다 

한 번에 플래그 SYN = 1 많은 패킷을 전송 하기 때문에 서버는 현재 과부하 상태이다.

pacp 파일을 열어서 

Open pcap with Wireshark > Statics > Conversations 탭을 열게 되면 다음과 같이 보이게 된다.


Server (victim): 128.237.255.81 인것을 확인 할 수 있고 

필터링을 통해 아래와 같이 확인 합니다.

Use filter to filt all packets from attack:

tcp && ip.dst == 128.237.255.81 && tcp.flags.syn == 1 && tcp.flags.ack == 0

우리는 소스 ip 정보를 통해 공격자를 알 수 있다.

We can lists source IP and it's all IP of attacker.

121.168.84.32 

75.214.206.60 

21.241.212.197 

55.53.190.191 

71.113.17.64 

120.130.138.152 

171.128.49.99 

104.220.68.36 

241.210.41.46 

33.24.97.48 

115.99.66.210

154.29.81.178 

69.232.82.51 

234.183.31.38 

102.146.88.253 

196.132.138.81 

63.193.172.89 

16.6.74.206 

94.148.118.202 

160.116.210.243 

248.237.9.18 

161.147.211.153 

207.137.67.221 

229.61.253.52 

180.70.211.154 

132.214.137.24 

132.42.241.177 

65.248.11.247 

49.201.237.5 

51.145.58.158

저작자 표시 비영리 변경 금지
신고

'computer forensics' 카테고리의 다른 글

Nullcon ctf MISC 300  (0) 2017.05.03
Acquiring Linux Memory from a Server Far Far Away  (0) 2017.02.22
DDos Syn 패킷 분석  (0) 2016.01.18
네트워크 포렌식 (backdoor)  (0) 2015.12.29
네트워크 포렌식 문제  (0) 2015.12.19
The Pmem Memory acquisition suite.  (0) 2015.04.26
블로그 이미지

Ryansecurity Ryansecurity

Life is fun security story

아래 봇 서버에서 감염된 .DLL 파일을 실행에 의해 시작 악성 트래픽에 PCAP 분석하는 솔류션을 통해 pcap 파일을 얻게 되었다.

해당 pacp 파일을 snorby 브라우저를 통해서 확인 하였다.


이 쉘 코드에 대한 표시 언뜻 보면 CPU를 통해 NOOP을 썰매로 사용 버퍼 오버플로 공격.한걸로 보여진다.

1. 클라이언트가 손상되었다 원래 웹 요청의 전체 URI는 무엇인가?

문제를 주어진 5 대의 서버가 있었다. 그들 중 네 쿠키 쉘 코드 및 잠재적 인 버퍼 오버 플로우 탈취 (209.85.143.100, 209.85.143.18와 92.122.126.216)의 문제를 제공했다. 그러나 단 하나의 (10.20.0.111) 클라이언트 실행 파일을 보내거나 쉘 코드 (그림 27)를 통해 dll을. 클라이언트 피해자가 보낸 HTTP GET 요청에 의해 필터링해야하는 URI 캡처 발견합니다.

필터링 방법 : Filter: (ip.src==10.20.0.165)&&(http.request.method==GET)&&(ip.dst==10.20.0.111)


아래 3개를 확인 결과

"banking.htm" provided by server  10.20.0.11 포트 8080으로 URI=http://10.20.0.111:8080/banking.html 되는걸 확인 할 수 있음

2. 악의적 인 서버에 최종 웹 요청의 요청은 어떤 파일 형식인가?

분석결과 아래 그림과 같이 27 드라이브 IP 주소 10.20.165의 클라이언트는 IP 주소 10.20.0.111의 손상 서버로 리디렉션되었다. 손상된 서버에서 최종 요청을 찾으려면, PCAP 서버의 IP를 소스 주소로 필터이었다. 거기에 쉽게에서 프로토콜의 HTTP 유형이 발견하고, TCP 스트림을 다음과 현명한 GIF 형식의 파일이 발견 된 대화의 서버 - 클라이언트를 필터링하여 하였다.


3. 해당 파일의 SHA1 해시는 무엇입니까?

GIF 파일로 저장 하였다 위에서 발견 SHA1 해시 값을 이진 데이터에 강조되었고

sha1sum 도구가 해시 값을 계산하는 데에 사용되었다 왜냐하면 CLI 후 아래에 보여 때문이다.



4. 클라이언트가 손상되었음을 나타냅니다 첫 번째 프레임의 수는 몇 개입니까?

이미지 "Sguil 필터링 출력"사실을 고려, 아래 질문에서 인수를 따라 그 기본 포트로 metaspoilt 사용 4444 [2] 역 HTTP의 경우, PCAP가 손상 처음으로 프레임 4722을 결과하는 소스 포트 4444에 대한 필터했다 악용되었음을 볼수 있다.

5. 한 시점에서, 악성 단절 클라이언트에 악성 파일을 전송합니다. 이 파일의 어떤 유형입니까?

Snorby에 의해 검출 된 심각도가 높은 패킷을 조사함으로써, 대부분의 트래픽이 버퍼 오버 플로우가 악용와 쉘 코드 기반 (시작 NOOP 썰매) 인 것을 명확하게 볼 수 있습니다. 그러나 그것은 하나의 IP 주소 10.20.0.111의 서버에 의해 전달 된 윈도우 실행 파일이나 DLL 파일을 나타내는 위협을 발생합니다.

추가 조사는 Sguil 이루어졌다. 첫 번째 단계는 의심스러운 서버의 IP 주소를 기준으로 모든 경고 파일러했다.



sguil 다양한 방법, 증명서 모든 TCP 시퀀스 대화를 패킷에 질의 할 수 있으며 또한 추가 조사를 위해, 와이어 샤크 networkminer 등을 통해 시퀀스를 송신한다. 

불행하게도 의심스러운 이벤트를 감지하지 않은 networkminer 또한 모든 파일의 압축을 풉니다. 따라서 의심스러운 TCP 시퀀스는 추가 조사 및 악성 파일 착취의 본질 추출 와이어 샤크로 보내졌다.


다음 단계는 TCP 시퀀스의 특성을 조사 하였다. 와이어 샤크에 수출하는 모든 패킷이 하나의 TCP 대화 한, 어떤 패킷을 선택하여 TCP 스트림을 다음함으로써 "DOS 모드에서 실행할 수 없습니다"악성 파일에 의해 실행되는 일부 일부 스크립트가 밝혀졌습니다."악성 프로그램"클라이언트 상기 제 1 부 대화 서버가 추출 하였다 (그림 의 성격을 알 수 있습니다. 그것을 헤더를 읽어 파일 확장자 등에 대한 기본 정보를 제공 

내가 제일 포렌식 도구를 사용하여 DLL 또는 EXE 파일입니다 중 하나를 발견합니다. 그러나 결과는 이메일에 첨부 파일 다운로드시 거부에 대한 설명과 함께.


따라서 서버에 의해 주입 된 악성 파일은 "urlmon.dll을"입니다.

6. 악성 파일의 SHA1 해시는 무엇입니까? 

다음과 같이 수출 악성 파일의 SHA1을 계산하기 위해 분투 분포 (보안 어니언) 명령 시설은 터미널 평가를 기반으로 된 도구 이용합니다.

7. 어떤 취약점을 이용하였는가?

피해자가 악성 URI에 액세스하여 손상했기 때문에, 취약한 소프트웨어가 일부 브라우저있다. 그것을 어떤 발견하기 위해 HTTP 프로토콜의 세부 사항은 모질라 4.0 브라우저를 나타내는 사용자 에이전트를 확인해야합니다.

8.(CVE-$ year- $ 숫자의 형태로 답) 이용되었다 여기에 취약점을 커버 해당 CVE 보안 공지를 제공 할 수 있습니다.

어니언 보안 침입 탐지 시스템은 Snort 규칙 데이터베이스를 사용하여 서명에 기초하여 검출된다. 이 경우 경고는 사용자 에이전트가 모질라 브라우저 지정된 페이로드와 홈 네트워크에 대한 TCP 인터넷 소켓에서 vulnerbalities 찾고 서명 SID 2000419으로 팝업했다. 



먼저 나는 악의적 인 DLL에 대한 칼리 리눅스 (그림)에서 사용할 수 searchsploit 도구를 사용합니다. 결과는 Internet Explorer 버전 7.0 및 5.0 공격을 반환합니다.


더 연구를 수행하고 질문 5, 7, 기사도 9에서 수집 한 정보에 따라가 "어떻게 역 백도어를 만들려면"이 것은 악용이 프로젝트 오로라를 기반으로 가정을 구동한다. [4] 방법 중 하나는 이것에 대한 CVE를 찾을 수 착취는 해당 정보로 또는 구글 엔진을 사용하여 간단한 검색 별 취약점 연구소의 데이터베이스를 통해 검색입니다. [5] 다른 방법은 안티 바이러스를 사용하여 파일을 검색하는 것입니다.CVE는 CVE-2010-0249이다.

9. 캡처로부터, 침입자가 액세스의 소정 형태 (즉, 인터페이스), 클라이언트에 공격자가 "GET"않는 액세스 무슨 (유형)를 얻는 것은 분명하다?

그림에 표시된대로 쉘 코드가 만들어졌습니다. 추가 조사가 경고 "아니 오프셋 TCP 쉘 코드와 ET 쉘 코드 가능한 전화"가 발생 순서에 Sguil에서 수행 된 액세스에 대한 자세한 내용을 찾을 수 있습니다.


정확히 경고를 따라 트리거 무엇으로 얻으려면, 리퀘스트 요청했다.


전사를 통해 스크롤하면 Windows 커널 (32)에 대한 라이브러리의 주입이 수행 된 증거가있다 [6]. 추출 암호에 대한 라이브러리의 실행이 meterpreter 작성 (VNC 및 탐색 할 수를 사용하여 장치의 화면을 제어 할 수 있도록 메타 스플로 잇 기반의 페이로드를, 업로드 및 다운로드 파일은 [7]) 암호화 역 쉘을 생성하는 (추출 40분의 56 스탠드 HTTP를 통해 암호화를 제안 SSL 개시에서 키 40분의 56 [8] 비트). reverse_https을 제안하는 모든 메타 스플로 잇은 SSL 세션 내부 meterpreter 백도어 연결을 생성하는 이용한다. [9]

REF: 


[1] Kyle Haugsness, SANS, “Intrusion Detection FAQ: What is polymorphic shell code and what can it do?”. Internet: http://www.sans.org/security-resources/idfaq/polymorphic_shell.php [Mar 22, 2014]


[2] Offensive Security, “Msfpayload”. Internet: http://www.offensive-security.com/metasploit-unleashed/Msfpayload. [Mar 22, 2014]


[3] SourceFire Forum,”CVE Mapping to Snort Rule”. Internet:https://community.sourcefire.com/questions/cve-mapping-to-snort-rule. Nov 7, 2012 [Mar 22, 2014]


[4] Damballa, “The Command Structure of the Aurora Botnet”, Internet:https://www.damballa.com/downloads/r_pubs/Aurora_Botnet_Command_Structure.pdf, [Mar 22, 2014]


[5] Extraexploit, “IExplorer 0day CVE-2010-0249 – Exploit-Comele/Hydraq/Aurora”. Internet:http://extraexploit.blogspot.ie/2010/01/iexplorer-0day-cve-2010-0249.html, Jan 20, 2010 [Mar 22, 2014]


[6] Jarkko Turkulainen, “Remote Library Injection”. Internet:http://www.nologin.org/Downloads/Papers/remote-library-injection.pdf, [Mar 22, 2014]


[7] Variuos Authors, Wikipedia, “Metasploit Project”. Internet:http://en.wikipedia.org/wiki/Metasploit_Project, Mar 9, 2014 [Mar 22, 2014]


[8] OpenSSL, “Ciphers(1)”, Internet: https://www.openssl.org/docs/apps/ciphers.html, [Mar 22, 2014]


[9] NEtresec, “How to detect reverse https backdoors”, Jul 9, 2011 [Mar 22, 2014]


저작자 표시 비영리 변경 금지
신고
블로그 이미지

Ryansecurity Ryansecurity

Life is fun security story

티스토리 툴바