The Difference between being Rich and Wealthy.

Free AI web copilot to create summaries, insights and extended knowledge, download it at here

6344

Abstract

lass="hljs-keyword">Get-EventLog -logname security -InstanceId 4720 | Select-Object *</pre></div><figure id="9247"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*1ogBlqZ-7dNeDpNg7baIUw.png"><figcaption></figcaption></figure>Our initial assumption was accurate. Now, let’s list the privileges held by the ‘apt’ user. Since we already know this user belongs to the Administrator group, we can confirm this by enumerating the admin group.<div id="0989"><pre>net localgroup Administrators</pre></div><figure id="31eb"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*n8AmAAO-wgl9guGrSdE1PQ.png"><figcaption></figcaption></figure>However, the privileges held by the user ‘apt’ remain uncertain. To determine their access level, we will employ the Sysinternals tool called ‘<a href="https://learn.microsoft.com/en-us/sysinternals/downloads/accesschk">accesschk</a>,’ which will assist us in identifying the extent of access granted to the ‘apt’ user. Go to the respective folder and this file with the below command attribute.<div id="f085"><pre>.\accesschk64.exe apt -a *</pre></div><figure id="9f6f"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*kHHnzdbij_wQaZXIosY8sg.png"><figcaption></figcaption></figure>Indeed, it’s confirmed that the user ‘apt’ possesses full privileges within the operating system. Our next step is to identify any active sessions associated with this user. To acquire this information, we can leverage system commands, Sysinternals tools, or even examine event logs. For now, we’ll opt for the Sysinternals tool ‘<a href="https://learn.microsoft.com/en-us/sysinternals/downloads/psloggedon">PsLoggedon</a>,’ which will help us determine any active login sessions.<figure id="7a36"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*SFoW2OOgM7DZZyVHPuDfSw.png"><figcaption></figcaption></figure>This observation reveals that the user ‘apt’ has logged into the victim machine through system shares. To determine the origin of this connection, we can utilize the ‘net’ command to gather more information.<div id="d661"><pre>net session</pre></div><figure id="9ac1"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*JApyNvTUPHprvRSnyaJE6A.png"><figcaption></figcaption></figure>The observation indicates that the attacker’s machine is identified as 192.168.0.104, and the connection to the victim’s machine remains active, suggesting that the attacker is currently on that system.<h1 id="0006">Process and Service Information</h1>Now, let’s extract valuable information from processes and services, as critical data is often concealed there. To gather process information, we have two PowerShell cmdlets at our disposal: ‘Get-Process’ and ‘Get-WmiObject Win32_Process.’ I recommend using ‘WmiObject’ because it provides more comprehensive data compared to the first cmdlet. We will retrieve a list of processes running at the time of the investigation.<div id="54a8"><pre>Get-WmiObject -Class Win32_Process | select ProcessName, ProcessId,CommandLine</pre></div><figure id="ea4e"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*okLiTkQMzF-ji_193xAgCg.png"><figcaption></figcaption></figure>Numerous processes are running, making it challenging to identify anomalies. However, given that user VictimA has been compromised, we should focus on processes initiated by this user.<div id="cca5"><pre>Get-WmiObject -Class Win32_Process | where { $_.GetOwner().User -eq "VictimA" } | select ProcessId, Name, CommandLine</pre></div><figure id="4972"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*sh5NIGAVwx9SSsyg5ED1bg.png"><figcaption></figcaption></figure>We noticed that some processes initiated by user VictimA appear suspicious based on their command lines. Let’s investigate the parent-child relationships for these processes using its Process ID.<div id="3dd1"><pre>Get-WmiObject -Class Win32_Process | where processid -In 7036,5892,5776,9112,7912,460,8864 | select ParentProcessId,ProcessId, Name, CommandLine</pre></div><figure id="1b1a"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*5CeYdOtVvcy4bDPKdmxXbA.png"><figcaption></figcaption></figure>It has been observed that the ‘ad.bat’ file executed a PowerShell command. The purpose of this command was to download a PowerShell script and run it, specifying an IP address and port number as attributes. This suggests that the PowerShell script was designed to establish a reverse connection as part of an attack. The reference image is given from Process Explorer.<figure id="aaaa"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*fNdvmFTnbrtYE9MBTCAvdQ.png"><figcaption></figcaption></figure>Now that we have collected a significant amount of information about the suspicious processes, let’s shift our focus to the services, where we might find valuable insights. We will gather a list of all actively running services.<div id="6cfd"><pre>Get-WmiObject -class Win32_service |where State -eq 'Running'| <span class="hljs

Options

-title">select name,processid,status,started,state,pathname</pre></div><figure id="1a9a"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*WVIZinER8JAbBjd-6vzfgg.png"><figcaption></figcaption></figure>No suspicious findings so far, but I’d like to take a closer look at the running services associated with the Process IDs we identified during our process investigation.<div id="2ff9"><pre>Get-WmiObject -class Win32_service |where State -eq 'Running' |where processid -In 7036,5892,5776,9112,7912,460,8864| select name,processid,status,started,state,pathname</pre></div><figure id="4c35"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*6CV3yOovqZM7JUBwaHnxYA.png"><figcaption></figcaption></figure>Nothing suspicious was observed!!<h1 id="7870">Network Information</h1>As we’re aware of the reverse connection, our next step is to confirm its presence or establishment. To achieve this, we will utilize the ‘netstat’ utility. Our first action is to retrieve a list of all connections.<figure id="786e"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*Ap9HOX5ljV59a3JvaZHSVQ.png"><figcaption></figcaption></figure>Now, we’ll inspect the established connections and identify their owners. In our particular instance, we noted a connection on port 4444, and it’s associated with PowerShell, which is indicated by the PID 7912. This confirmation implies that a Command and Control session has been established on 192.168.0.108.<figure id="0027"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*z-wRQ1UG_jCLSdxaYQPCdw.png"><figcaption></figcaption></figure>We’ll now examine the nature of communication between the compromised machine and the C2C server, which typically functions as a Master-Slave relationship. To inspect this interaction, we’ll employ Wireshark<figure id="5026"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*a_g9T6ZW98cMgq_iPdOznA.png"><figcaption></figcaption></figure><h1 id="c47c">Autorun and schedule task information</h1>As we approached the final phase of our live forensics on the Windows machine, our attention was drawn to the C2C (Command and Control) connection, where the server was attempting to add a .bat file to the registry to establish persistence on the system. Before delving into the registry path, we conducted a preliminary check to see if any applications were located in the startup locations. Unfortunately, we did not discover any malicious applications in these areas.<figure id="bf7a"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*1_Ng1FqB8eP4KK8XE_jOxA.png"><figcaption></figcaption></figure>At this point, our attention is directed towards the startup commands within the registry. We’ve noticed that a registry key has been added, and the associated file is named “sd.bat.”<div id="93c4"><pre>gwmi Win32_StartupCommand</pre></div><figure id="2a07"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*6C5wTI9ysapfJD6q5WY_OA.png"><figcaption></figcaption></figure>We’ll make an effort to gather more detailed information regarding this specific startup location to gain deeper insights into the activity. This confirms that the activity recorded in network forensics has been successfully executed, and persistence has been maintained.<div id="f52f"><pre>gwmi Win32_StartupCommand | where name -eq "APT" | select *</pre></div><figure id="8544"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*lfQO-8KyGLRyWen8Hg44-g.png"><figcaption></figcaption></figure>We will now check if any other persistence activity has been observed via scheduled tasks. Unfortunately, no suspicious activity has been found.<div id="0fac"><pre>Get-ScheduledTask | where state -eq 'Ready'</pre></div><figure id="cfb5"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*EihxglbQgcwtDh4rC5VPbQ.png"><figcaption></figcaption></figure><h1 id="51e5">Indicator of Attack</h1>- New user APT has been created — Initial Access (T1078.003)

User APT added to the admin group — Privilege Escalation (T1098)
The user ‘APT’ has logged into the victim’s machine using network services from the IP address 192.168.0.104 — Lateral Movement (T1021.002)
PowerShell commands were executed from a batch file, with the aim of downloading a PowerShell script and running it, providing an IP address and port number as inputs. This indicates the establishment of a reverse shell. — Execution (T1059)
I noticed a batch file added to HKU<user>\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, indicating that this file will be executed upon user VictimA’s login. — Persistence (T1547.001)<h1 id="afc0">Conclusion</h1>The process we’ve discussed in this blog is not exhaustive, and there are other artifacts that can also be observed. We’ll aim to cover those in the next blog.</article></body>

The Difference between living Rich and Wealthy.