Splunk 편


먼저 Splunk에서 Datper 통신 로그를 추출하기 위해 다음에 서술 방식으로 사용자 검색 명령을 만듭니다. 이 방법으로 만든 명령은 Splunk 6.3 이상에서 사용할 수 있는지 확인합니다.

Splunk 사용자 지정 검색 명령 작성 및 조사
사용자 지정 검색 명령을 다음과 같이 작성하십시오. 보다 상세한 절차에 대해서는 Splunk Documentatio [1] 을 참고하십시오.

  1. Splunklib 설치 
    다음과 같은 Web 페이지에서 SplunkSDK (SoftwareDevelopmentKit) for Python을 다운로드하고 그 안에 포함되어있는 splunklib 폴더를 $ SPLUNK_HOME / etc / apps / search / bin에 복사합니다. 
    Splunk SDK for Python 
    http://dev.splunk.com/goto/sdk-python

  2. 사용자 지정 검색 명령 스크립트 설치 
    사용자 지정 검색 명령 스크립트 datper_splunk.py을 $ SPLUNK_HOME / etc / apps / search / bin에 저장합니다. 
    또한 사용자 지정 검색 명령 스크립트는 GitHub에서 공개하고 있기 때문에, 다음의 Web 페이지에서 다운로드하여 이용하시기 바랍니다. 
    JPCERTCC / aa-tools · GitHub 
    https://github.com/JPCERTCC/aa-tools/blob/master/datper_splunk.py

  3. 구성 설정 
    $ SPLUNK_HOME / etc / apps / search / local에 2 개의 설정 파일을 만들고 각각 다음과 같이 설명합니다. 이미 파일이 존재하는 경우에도 같은 내용을 추가합니다. 

    commands.conf
    [datper] 
    filename = datper_splunk.py 
    streaming = true 
    chunked = true 
    local = true
    

    authorize.conf
    [capability :: run_script_datper] 
    [role_admin] 
    run_script_datper = enabled
    
    또한, 위의 예에서는 datper라는 이름의 사용자 지정 검색 명령을 작성하는 설정을합니다.

  4. Splunk 재시작 
    변경 한 구성을 반영하기 위해 Splunk를 다시 시작합니다. 재부팅 후 datper이라는 새로운 사용자 지정 검색 명령을 사용할 수 있습니다.

  5. 실행 
    만든 사용자 지정 검색 명령을 실행합니다. 사용자 지정 검색 명령 datper을 실행하면 Splunk의 각 이벤트 (인덱스 로그)에 대해 "is_datper"라는 필드가 생성되어 판정 결과 "yes"또는 "no"가 부여됩니다. 프록시 로그에서 날짜와 Datper의 판정 결과, 통신 목적지 IP 주소, URL을 표시하는 검색 문을 실행 한 결과의 예를 그림 1에 나타냅니다. 검색 본문의 index 및 table은 각각의 환경에 맞게 변경하십시오.
    index = proxy_log | datper | search is_datper = yes | table _time, is_datper, dst_ip, url
    
acreport-search-datper_01.png
그림 1 : 사용자 정의 검색 명령 datper 실행 결과 
클릭하면 확대됩니다


ELK 스택 편

다음으로 구축 된 ELK 스택 환경이 이미있는 것으로, Datper 통신을 조사하기위한 설정을 추가하는 방법을 소개합니다. 또한 프록시 로그는 Squid를 대상으로하고 있습니다. 또한 검증에 사용한 Elasticsearch, Logstash, Kibana 버전은 모든 5.5.1입니다.

ELK 스택 설정

  1. 스크립트 설치 
    다음과 같은 Web 페이지에서 datper_elk.py을 다운로드하여 원하는 디렉토리에 설치합니다. 
    JPCERTCC / aa-tools · GitHub 
    https://github.com/JPCERTCC/aa-tools/blob/master/datper_elk.py
    이상에서는 스크립트를 / opt / bin에 설치 한 것으로합니다.

  2. Logstash 설정 
    Logstash 프록시 로그를 읽고 스크립트 Datper 통신 여부 판정 결과의 필드를 추가하도록 구성 파일을 만듭니다. 
    이미 프록시 로그를 읽는 설정이 작성된 경우에는 2.1의 설정을 날려 2.2로 이동합니다. 

    2.1. input 설정
    input { 
      file { 
        type => "squid" 
        start_position => "beginning" 
        path => "/var/log/squid3/access.log"] 
      } 
    }
    
    Logstash은 기본적으로 로그에 새로 추가 된 행을 처리하도록되어 전체 로그 파일을 가져올 경우 "start_position =>"begining ""의 설정이 필요합니다. 
    "path"는 캡처 로그 파일을 작성합니다. 

    2.2. filter 설정
    filter { 
      if [type] == "squid"{ 
        grok { 
          match => "message", "% {NUMBER : timestamp} \ s + % {NUMBER : response_time} % {IP : src_ip} % {WORD : squid_request_status} / % {NUMBER : http_status_code} % {NUMBER : reply_size_include_header} % {WORD : http_method} % {WORD : http_protocol} : // % {HOSTNAME : dst_host} % {NOTSPACE : request_url} % {NOTSPACE : user} % {WORD : squid } / (? : - | % {IP : dst_ip}) % {NOTSPACE : content_type} "] 
          add_tag =>"squid "] 
        } 
        date { 
          match =>"timestamp ","UNIX "] 
        } 
        ruby { 
          code = > 'require "open3" 
                   message = event.get ( "message") 
                   cmd = "/opt/bin/datper_elk.py \'# {message} \ ' "
                   stdin, stdout, stderr = Open3.popen3 (cmd) 
                   event.set ( "datper"stdout.read) 
                   ' 
        } 
      } 
    }
    

    위의 설정은 grok 필터 Squid 로그에서 각 필드를 추출하여 date 필터에서 UNIX 시간의 타임 스탬프를 날짜 형식으로 변환합니다. 위의 예는 Squid의 기본 로그 형식의 경우 설정이며, 로그 형식이 combined의 경우는 다음과 같이 COMBINEDAPACHELOG 패턴 등을 사용하여 필드를 추출하여 date 필터의 패턴을 변경해야합니다 .
        grok { 
          match => { 
    "message"=> "% {COMBINEDAPACHELOG} % {WORD : squid_request_status} % {WORD : squid}" 
    } 
        } 
        date { 
          match => "timestamp", "dd / MMM / yyyy : HH : mm : ss Z "] 
        }
    

    ruby 필터는 스크립트를 실행하고 스크립트에서 반환 된 결과를 datper 필드로 추가합니다. ruby 필터 code에 cmd를 스크립트의 위치는 "1 스크립트 설치"에서 설치 한 장소를 설명합니다. 또한, 상기 ruby ​​필터 code는 Logstash5.0 이후 Event API에 맞춘 기술이며, 이전 버전에서는 다음과 같이 기술 할 필요가 있습니다.
    code => 'require "open3" 
             message = event [ "message"] 
                   cmd = "/opt/bin/datper_elk.py \'# {message} \ '" 
                   stdin, stdout, stderr, status = Open3.popen3 (cmd) 
                   event [ "datper"] = stdout.read 
                   '
    

    2.3 output 설정
    output { 
       elasticsearch { 
           hosts => "localhost : 9200" 
           index => "squid-access" 
       } 
    }
    

    hosts에 Elasticsearch의 호스트 이름, index 이름에 원하는 이름을 설정합니다. 
    Logstash에 2.1에서 2.3의 설정이 포함 된 설정 파일을 읽어 들여 실행하고 로그 파일이 문제없이 받아 들여지는 Elasticsearch에 인덱스가 만들어집니다.

  3. Kibana에서 인덱스 패턴 생성 및 로그 검색 
    Kibana의 Web UI에 액세스하여 인덱스 이름을 입력하여 패턴을 만듭니다. 그림 2는 "2. Logstash 설정"의 설명에서 볼 수 있듯이 인덱스 이름을 squid-access, time filter 필드를 timestamp하고 있습니다.
    acreport-search-datper_02.png
    그림 2 : 인덱스 패턴 생성 
    클릭하면 확대됩니다

    Discover 화면을 보면 datper 필드에 스크립트에 의한 판정 결과가 그림 3과 같이 들어 있습니다.
    acreport-search-datper_03.png
    그림 3 : Discover 화면 
    클릭하면 확대됩니다

    또한 기존의 인덱스에 datper 필드를 추가 할 경우에는 Elasticsearch URL과 인덱스 이름을 지정하고 datper_elk.py을 실행하여 필드를 추가 할 수 있습니다. Elasticsearch의 URL이 http : // localhost : 9200 프록시 로그 인덱스 이름이 squid-access의 경우의 실행 예는 다음과 같습니다.
    /opt/bin/datper_elk.py http : // localhost : 9200 squid-access


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

Ryansecurity Ryansecurity

Life is fun security story

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

티스토리 툴바