XINTRA TechTonik Lab Walkthrough

SCOPING NOTE

Techtonik is a technology company that builds and designs infrastructure for businesses around the world. It is a Fortune 500 company responsible for some of the largest infrastructures in the world.

You have been called in to assist after they have identified some suspicious activity on their network. Your call with the technical team has provided you insight into the environment and potential initial pivots.

The Techtonik development team raised a suspicious observation to their security team. They had noticed a new unknown user in their TeamCity server on 2024–05–25. The IT administrators also mentioned some suspicious files on the file share (hosted on TTK-FS-01).

Some additional information collected on the scoping note:

• There is a Linux server that requires analysis
• All event logs are sent to an Elastic stack
• Default defender was used and run on the hosts

Exploiting TeamCity

As we read on the scop note, “the development team raised a suspicious observation to their security team. They had noticed a new unknown user in their TeamCity server on 2024–05–25.” so we can start from here, by filtering the index and take the “TeamCity” logs on that day, and filtering by “created user” we can easily find the new user, with ID 21

Shortly after the user was created, the attacker (IP 44.222.89.156) successfully authenticated using HTTP token-based login.

The same user uploaded a suspicious plugin named “deQch48D”, suggesting possible code execution attempts

After identifying the suspicious plugin and its installation path, we can manually review it by extracting the ZIP file named deQch48D.

Each TeamCity plugin typically contains a teamcity-plugin.xml file, which includes metadata such as the plugin name, version, and description.

After uploading the malicious plugin “deQch48D.zip”, TeamCity extracted a web shell named “deQch48D.jsp”, into the web server plugin directory. Full path:/home/teamcity/build/TeamCity/webapps/ROOT/plugins/deQch48D/deQch48D.jsp, This file enabled remote command execution through HTTP requests and served as the attacker’s entry point for code execution.

The malicious plugin dropped a JSP web shell that accepted a cmd parameter via HTTP GET requests.

Based on the server’s operating system, the shell dynamically adjusted its execution method:

• On Windows, it used: cmd /C [cmd_parameter]
• On Linux, it used: /bin/bash -c [cmd_parameter]

This logic allowed the threat actor to execute arbitrary system commands through a single parameter (cmd) regardless of the underlying OS.

The initial access to the TeamCity server “TTK-DEV-01” occurred without any prior authentication events. The first recorded log was the creation of a new user “ID 21” on May 25, 2024 at 01:02. This was immediately followed by the upload of a malicious plugin “deQch48D.zip” containing a web shell “.jsp”. This behavior matches CVE-2024–27198, an authentication bypass in TeamCity that allows creating users and executing code without credentials.

Pivoting into the Environment

During the investigation of the TTK-DEV-01 Linux host, we suspected the threat actor may have attempted to escalate privileges after initial access. To confirm this, we analyzed the .bash_history located at root/home/teamcity/.bash_history

Inside this file, we observed a clear sequence of commands used to download and execute a known enumeration tool for privilege escalation:

To determine the exact time of the privilege escalation script download, we examined the .wget-hsts file on TTK-DEV-01. This file logs HSTS entries used by wget. It contained an entry for github.com with a creation time of: Epoch: 1716601543 UTC: 2024-05-25 03:05:43

This confirms that the script lp.sh (downloaded via wget) was retrieved at that exact time.

While reviewing the .bash_history from TTK-DEV-01, we noticed that the attacker was interacting with directories like /FSCode/, copying files such as DocsBackup.rar into /tmp/. That raised a flag — it looked like he was moving files from somewhere external.

So we decided to dig deeper and check the system’s fstab file located at root/etc/fstab — a place where mounted drives and shares are listed.

Boom. We found this line: //10.0.2.5/Code /FSCode cifs …

It confirmed that /FSCode/ wasn’t a normal folder — it was an SMB share mounted from a file server. That means the attacker accessed the share, grabbed a file, and staged it locally.

We found evidence in the “.bash_history” file indicating that the attacker accessed a file named “.fileshare_credentials”. This file was located in the “/root/.fileshare_credentials” and likely contained authentication details for connecting to a remote SMB file share “//10.0.2.5/Code”. After navigating to the file, we confirmed its presence and inspected its properties to determine its size in bytes. and it shows the file size is 67 byte

While review the file on text editor, we saw the credentials (username, password, and domain) stored in cleartext. These are the same credentials the system uses to connect to the SMB share at /FSCode/

The attacker achieved remote execution on “TTK-FS-01”by installing a new service named “nmetJwNKqxsodLGT” using the “techtonik\stanley.eugene” credentials.

The service binary (qcBlRiAm.exe) was hosted on the SMB share “\127.0.0.1\Code”, which maps to the shared folder previously accessed from “TTK-DEV-01”, This confirming the attacker used Service Installation as the initial method of execution.

Approximately 30 minutes after the initial service execution, the attacker installed a second malicious service named “OkMlepDlOFSIKVfc” Like the first, the executable “LZbNNNSK.exe” was loaded from the SMB share at “\127.0.0.1\Code”, again leveraging the previously mounted path.

This pattern indicates the threat actor’s persistence in maintaining execution access to TTK-FS-01

Discovering TechTonik

We identified a PowerShell command where the threat actor downloaded a suspicious binary using Invoke-WebRequest. from a suspicious Domain, this likely the C2 of attacker, The file was saved to the current working directory. Later, we found the same binary located in C:\\Code\\systoolkit\\msrdc.exe, confirming this is where it was stored and used.

By filtering the suspicious file on ELK, we got confirmed both the exact path of the file “C:\Code\systoolkit\msrdc.exe” and its hash

Also we found the execution of this tool, the attacker redirect the output to a file named “debug.log”, this file located on the CurrentDirectory of the malicious tool “C:\Code\systoolkit”

Below is the content of what the tool was doing, as we can see it collect and enumerate the compromise host “TTK-FS-01”, also it check for any vulnerability on the host, also The detailed output structure, inclusion of AppLocker checks, dynamic list generation, and references to HackTricks clearly indicate that the tool executed was WinPEAS, a well-known enumeration utility for privilege escalation on Windows systems.

Setting up the Network for Attack

After stepping on the ‘TTK-FS-01’, the attacker attempts to exclude three paths. This behavior indicates obfuscation, so Windows does not block the malicious activity on these paths.

Another suspicious binary was found at “C:\Code\systoolkit” on the host named ‘TTK-FS-01’. The file, named Serchindexer.exe, uses an icon resembling Mimikatz. After extracting its hash and checking it on VirusTotal, it was confirmed to be Mimikatz — a well-known tool used for credential theft and other malicious activities.

Another suspicious binary was found at “C:\Code\systoolkit”, this binary was used as persistent service on “TTK-FS-01”

As we continued our investigation, we searched for any child processes spawned by the malicious service. We discovered another suspicious binary located at “C:\Code\systoolkit”, named “rr.exe”, which was found to be establishing a SOCKS proxy it connect to “downloads.yxz.red:56969”, as shown below. The second image also displays the SHA1 hash of the malicious process.

On the “TTK-SQL-01”, we found an executable that was making outbound network connections to the IP address the threat actor was seen logging into TeamCity from

We noticed that “DWrite.dll” was located in the same directory as “SumatraPDF.exe”, which is unusual since that DLL is normally found in the system directory. This suggested that the attacker placed a malicious version there to take advantage of DLL sideloading.

After the malicious “DWrite.dll” was loaded by “SumatraPDF.exe”, the process immediately attempted to resolve the domain “docs.yxz.red”, indicating an attempt to reach out to the attacker’s infrastructure.

Signed Drivers and EDRSandblast

We observed the creation of two suspicious .pdb files (fltMgr.pdb and ntkrnlmp.pdb) on “TTK-SQL-01”by the binary C:\\Windows\\Temp\\LockApp.exe. This behavior is consistent with the EDRSandblast tool, which is known for dumping process memory and creating such debug artifacts.

While investigating driver-related activity on TTK-SQL-01, we filtered Sysmon Event ID 6 (Driver Load) for this host and identified that a driver named gdrv.sys was loaded. Upon further inspection, we found that the driver was signed by Giga-Byte Technology.

Another finding about the malicious driver, we identified it associated to a malicious service that was installed in the “TTK-SQL-01”, the service named “58MSKSSJ”

Dumping Credentials

We identified that the threat actor dumped the SAM registry hive using the reg.exe utility. The dump was saved as C:\Windows\Temp\1\sam.sa, as confirmed by the command line and current working directory fields in the event logs.

We also discovered a highly important finding on “TTK-SQL-01”, the attacker attempted to save the Security registry hive in the same directory where the SAM database had been previously dumped.

Later, the attacker compressed the entire directory into an archive, as shown below.

We observed that the binary “Word.exe” located at “C:\Code\systoolkit\Word.exe ” on DC, executed a WMIC commands targeting “TTK-PC-01” and “TTK-PC-02”. The command used the credentials of the user “TECHTONIK\scavo.divya” along with the password “i.BHs_Pqd9vT@GpZ” to remotely enumerate running processes on the target system. This indicates credential usage for remote WMI execution.

On the “TTK-PC-02”, we identify process creation event, the threat actor executed a renamed binary “mstrc.exe” located in “C:\Windows\Temp\”. Analysis of its metadata revealed that the original file name was “SharpChrome.exe”, a known tool used to extract saved credentials from Chrome browsers. The tool was run with the logins and cookies arguments, confirming its intent to dump web browser credentials.

Golden SAML

We identified that the threat actor executed a PowerShell script specifically crafted to extract the DKM key used by ADFS. The script utilized Get-ADObject to query the Program Data container for objects storing the key in the thumbnailPhoto attribute. This strongly indicates an attempt to access the ADFS signing certificate’s decryption material. Also the PowerShell script shows the function name that threat actor ran to retrieve the DKM key was **Get-DKMKey , the attacker used “techtonik\aadcsvc$”** to access the resource.

Getting the Goods Out

During the investigation, we identified that the attacker staged sensitive files into a compressed archive named “DocsBackup.rar”. This activity was executed using PowerShell, where the binary “cmd.exe” located under the attacker’s toolkit path “C:\Code\systoolkit\” launched robocopy with the following command:

-C robocopy C:\Temp\DocsBackup.rar \TTK-FS-01\Code\

This indicates that the threat actor prepared the archive locally under “C:\Temp\ ”and then transferred it to the shared directory on “TTK-FS-01” “\TTK-FS-01\Code\” — most likely as a staging location prior to data exfiltration.

As we identified, the .rar file was moved to the shared folder on host TTK-FS-01. We will now inspect the triage image from this host to analyze the contents of the compressed file.

Upon extraction, the RAR file yields a folder named “DocsBackup”, which contains 29 files. These represent the full contents of the compressed archive.

Also we found the rar file was located at host name “TTK-DEV-01” which is the original point of entry, This suggests “TTK-DEV-01” was used as the final staging point prior to data exfiltration.

Conclusion

This lab felt like a real investigation — not a checklist.

From spotting suspicious folders like C:\\Code\\, identifying sideloaded DLLs (Dwrite.dll), and tracking tools like SharpChrome, to uncovering credential dumping, WMI lateral movement, and even a signed Giga-Byte driver used for evasion — every step required digging.

Some parts were straightforward, others took real effort — especially tracing the DKM key access, exfil paths (DocsBackup.rar), and counting compressed files.

What made it stand out was how natural everything felt. Nothing was handed to you — you had to find it.

If you’re into hybrid investigations that combine cloud and on-prem, this lab is a solid test of patience, reasoning, and attention to detail.

🙏 Huge thanks to the team behind the magic:

• Adversarial Emulator: @ZephrFish
• Incident Responder: @svch0st
• Founder of XINTRA: @InverseCos