In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-04-07 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >
Share
Shulou(Shulou.com)06/02 Report--
This article introduces the working principle and detection skills of SILENTTRINITY, the content is very detailed, interested friends can refer to, hope to be helpful to you.
Introduction
SILENTTRINITY is a recently released tool based on IronPython and c #. This article will discuss its working principle and detection technology in depth. Because of its powerful function, easy development and default existence in modern Windows platform, .NET has become an important component in the field of security. Because of the blue team's growing ability to detect malicious PowerShell, it began to replace PowerShell (originally used for similar reasons). IronPython is essentially a Python that is closely integrated with the .NET Framework. This means that attackers can take advantage of the power of simple Python scripts and .NET libraries to develop on the Windows platform more easily.
DLR
.net language variable types and methods are bound at compile time, while Python is an interpreted scripting language. So, how do you execute Python code in a .NET environment? The answer lies in DLR (dynamic language runtime). The following figure shows the architectural view of DLR (Microsoft 2017).
DLR is a runtime environment that allows dynamic languages such as Python to run on .NET and eventually compile to the corresponding Universal Intermediate language (CIL) format. One of the DLR components that makes this possible is dynamic object interoperability. A key feature of Python is that it does not have to declare its variable type at compile time. Instead, variable type resolution is performed at run time, which is different from the way standard .NET languages such as C # run. To solve this problem, DLR provides a data type called "dynamic". Variables assigned with "dynamic" data types are resolved at run time rather than compile time, allowing Python to maintain its dynamic nature and still run in the .NET environment. In SILENTTRINITY, IronPython code is embedded and executed in a C # object and, by extension, in a .NET environment. This means that it will first be compiled into CIL code and then become native code by using the JIT engine. We have discussed this in more detail on the blog before (part 1 and part 2).
How SILENTTRINITY works
SILENTTRINITY consists of a C2 server running Python and a C# backdoor that executes on the victim's machine using dynamic .NET assemblies. The following picture shows how SILENTTRINITY works. We will use the msbuild stager mechanism as an example.
1. First put the xml file containing the back door of c # into the victim. two。 Through MsBuild.exe execution, the C# backdoor is deserialized and loaded into memory. 3. Once implanted in memory, the backdoor connects back to the SILENTTRINITY C2 server and downloads the zip file named staged.zip into memory. The zip file actually consists of IronPython's .NET assembly and a Python script named stage.py. 4. The .NET assembly is then loaded into memory by using the .NET library. Once the assembly is loaded, the IronPython engine can be invoked to execute the stage.py.5.C2 server, which can now push Python-encoded modules to the victim.
Detect SILENTTRINITY
Now that we know how SILENTTRINITY works, let's see how to detect it. We will use it through the released Python script. NET ETW provider to track the behavior used by the underlying CLR.
Dynamic assembly loading
C#implant is actually a C # class of type "ST", and an instance of it is created dynamically at run time. This can be achieved through .NET 's "Reflection" and "Activator" libraries, as shown in the following code snippet.
Therefore, we can try to trace the existence of such function calls using the Python script, as shown in the following figure.
As shown in the figure, we can observe the JIT-Inlining failures of the "GetType" and "CreateInstance" functions, thus indicating that these functions have been executed at least once. However, we also see that the assembly load in memory is related to instance creation and the SILENTTRINITY assembly itself:
IronPython assembly
If the C # backdoor wants to use the python engine to execute python code, it must first import a set of assemblies at run time, namely:
IronPython.dll ·IronPython.Modules.dll ·Microsoft.Dynamic.dll ·Microsoft.Scripting.dll
This can be done by using the callback method of the "ResolveAssembly" event (Richter,2010). The following code snippet shows how to achieve this goal. Once the assembly is loaded correctly, the C # backdoor can use the IronPython engine to execute Python code, as shown in the following code snippet.
Since the loading of the above DLL is a key part of SILENTTRINITY, we can also try to find evidence of these assembly loads:
In this example, we can observe the dll being loaded through the "DomainModuleDCStart_V1" and "ModuleDCStart_V2" events, indicating the existence of IronPython. They are also loaded in memory and are not supported by files. However, it is important to note that the existence of these assemblies does not represent any malicious behavior itself. Legitimate .NET applications that use the IronPython engine also load these, but it is more likely to load these files from disk. However, in most enterprise environments, many applications are unlikely to use IronPython legally. Another important difference from other IronPython uses is that the assemblies involved here are used for embedded use of IronPython used by SILENTTRINITY. If IronPython is used as a stand-alone python interpreter to run in. If you call the python script on the net framework, you can see that the ipy.exe stand-alone interpreter is in use.
SafetyKatz module
SILENTTRINITY contains a number of modules in the late development phase. We will look at one of the modules, SafetyKatz. This is much like the GhostPack module of the same name, which dumps lsass's process memory and then loads Mimikatz in memory to extract credentials. The following code snippet shows the implementation of SafetyKatz in Python:
As mentioned in the dynamic language Runtime section, you can detect this by using the .NET ETW provider to track JIT and Interop events.
As expected, we were able to observe the events of interest in the interop events of VirtualAlloc and MinDumpWrite function calls from the SharpSploit module.
Process activity
In addition to looking at .NET ETW events, we can also track suspicious process activity. Because we used msbuild stager in this example, we will obviously see the msbuild process execution event.
Since MSBuild is responsible for executing the xml file, we can look for signs of xml execution executed by MSBuild. Most MSBuild events follow terminology or a common format for parents and parameters, so you can baseline normal activity and point deviations throughout the enterprise. We can also look for connections from MSBuild. The C# backdoor must periodically connect back to the C2 server to check for pending operations, as shown in the following code.
Therefore, even if there are no pending jobs, the c# backdoor must communicate with C2 periodically, or until the MSBuild process terminates. Therefore, we can search for traffic, as shown in the following figure.
Conclusion
As maintainers, this is also true when we identify IOC. This article proposes several IOC to detect the existence of SILENTTRINITY. Some IOC, such as detecting IronPython assembly loading, are themselves low fidelity metrics, but when you combine all the activities, the behavior of SILENTRINITY becomes more and more specific, which helps to find it. During the investigation, maintainers usually have to come up with an assumption, and there are several different IOC that can usually reinforce this assumption. For example, if we want to detect dynamic assembly loading, combined with IronPython assembly loading, combined with MSBuild.exe 's XML parameters and regular network connections, then we have more evidence of compromise even before a malicious module like Safetykatz runs. . We want to thank byt3bl33d3r for creating such an impressive tool.
About the working principle of SILENTTRINITY and testing skills what is shared here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.
Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.