SILENTTRINITY and the Python of IRON

A few weeks ago right after DerbyCon (which I wasn’t able to attend), I heard about a new post-exploitation tool called SILENTTRINITY by byt3bl33d3r, a tool developer with a l33t name with some pretty l33t tools (…I’ll stop now) such as CrackMapExec and DeathStar. This project is unique in that it utilizes Python, IronPython, and C#/.NET in order to perform post-exploitation activities similar to other frameworks such as Empire.  The benefits of using a C#/.NET approach is that it’s harder to detect than PowerShell, and SILENTTRINITY puts a spin on its approach that’s appealing to any Python enthusiast in the security world.

I heard of IronPython before but never really had the time to get into it. A few days ago, I figured now was a good time as any to help contribute to this new project by developing some basic enumeration modules. The goal of writing these modules was to completely recreate their Windows binary counterparts using just .NET assemblies, and as little of the Python standard library as possible. Between the Microsoft .NET framework documentation and some patience, I was able to create two modules: ipconfig and systeminfo (similar to Meterpreter).

Developing systeminfo

If you’re interested in creating a module for SILENTTRINITY, you can follow the steps outlined by David Tavarez here. However, instead of PyCharm, I opted to use VSCode because I really enjoy the lightweight feel and the customized options it offers.

For the sake of learning, I decided to start with something simple to navigate my way around the .NET framework. I ultimately decided that systeminfo would be my first module, as it’s one of the first commands that would be run against most Meterpreter sessions.

This was a very simple script to write and learn from. There was a slight issue, however. I was testing this module against Windows 10 and according to the documentation for System.Environment.OSVersion:

Starting with Windows 8, the OSVersion property returns the same major and minor version numbers for all Windows platforms. Therefore, we do not recommend that you retrieve the value of this property to determine the operating system version.

This presented an inconvenience as the property could not be properly used to enumerate the version of Windows nor its build version. Instead, I opted to use the kernel32.dll product version to provide an accurate way of determining the OS Version and Build. I didn’t check but I think that the majority of system DLLs could be used to find the same information (user32.dll, advapi.dll, etc).

Lessons learned

Trying to avoid using Python modules that I’m used to has led to a better understanding of the .NET Framework from an IronPython perspective. For example, in the ipconfig module, I didn’t use the ipaddress library but instead decided to learn how the System.Net.IPAddress class worked. Additionally, I started to learn to some of the limitations of the .NET Framework when it comes to interacting with some DLLs. This forced me to try to understand C# code snippets I found online and be able to apply those concepts to some other modules I’m currently working on.

What’s next?

More modules. More IronPython. More .NET. More C# interpretation.

BeaconGraph v0.2 Released!

Github Link

Summary

Last week, I released a tool called BeaconGraph aimed at supporting wireless auditing. As of this post, v0.2 has been released with some pretty big improvements over the initial release and can be found at the Github link above.

BeaconGraph is an interactive tool that visualizes client and Access Point relationships. Inspired by airgraph-ng and Bloodhound, BeaconGraph aims to support wireless security auditing. It is written in Python with some GUI support by pywebview and a Neo4j database backend. Relationship rendering is supported by cytoscape.js and the overall application is served by Flask.

Why is it needed?

I’ll start by saying that I’m not a wireless engineer or auditor by any means. I’ve never even been a network engineer or a network administrator for anything more than 10 clients/servers. So while attending a SANS SEC617: Auditing Wireless Networks course in September, a lot of concepts were new to me. During the course, we discussed the aircrack-ng suite, and although I was aware and had practiced with many of the tools in the suite, I was introduced to airgraph-ng for the first time. I thought it was a pretty cool concept to be able to visual the relationships between clients and access points and provide information about all of them. But there was one glaring problem…

While the information was valid and nicely arranged, there was no way to quickly find or display any particular part of the graph, since airgraph-ng rendered PNG files. It crossed my mind that this would be a problem in much larger graphs for auditors, or generally anyone wishing to quickly view the data provided. Additionally, it was mentioned in that class that airgraph would crash if the data provided to it was too large.

Development

Thanks to some recent interactions with Bloodhound and it’s use of neo4j for graph visualizations, the idea for BeaconGraph nearly became a reality the next day when I established a very quick proof of concept using Python and the neo4j browser. The script accepts airodump-ng formatted CSV files and parses them into client-AP relationships, then stores them in the neo4j database. It established “Probe” and “AssociatedTo” relations:

  • Probe: The client device was actively probing for some Access Point that it has saved.
  • AssociatedTo: The client device was associated to a particular AP at the time of the traffic capture.

The neo4j browser displayed all the relationships pretty nicely in some great pastel (bleh) colors but this delivery wasn’t very user friendly, as the neo4j browser is just a means of querying the database.

The next logical step was to develop a web application of some sort to be able to view the database. While Bloodhound’s use of Electron is a great model to use for the neo4j standard, I have no major experience with front-end development. So with some intermediate HTML/CSS/Javascript skills, I was able to create a decent user interface. After implementing Cytoscape.js, BeaconGraph was born!

Use Cases

Here’s where it got a bit difficult. As I mentioned, I am not a wireless network engineer so I can’t speak on the possibilities that BeaconGraph could be used for in an assessment. Here are some scenarios I thought might be possible.

  • An audit to verify the access points that portable devices have only connected to approved access points. If a device has an unapproved access point saved (like most users do), it’ll be easy to spot with BeaconGraph and “Probes” edges.
  • An audit to look for unauthorized APs in an environment. Granted, there are other tools to assist with this but BeaconGraph provides nice visuals to use in reporting.

The most recent scenario I thought of before drafting this write-up was not for auditing but from a penetration testing/red team perspective. After loading a significantly larger WiFi signal dataset gathered while traveling, I decided to perform some basic analysis with BeaconGraph to determine if there was any interesting data or attack approaches that could be discovered.

In this picture (yes, the node and neighbors are highlighted for visual pleasure!), we can see that there are a ridiculous amount of devices probing for a  TMobileWingman access point. This TMobileWingman AP is saved on nearly every T-Mobile device managed networks and can’t be removed. It uses 802.1X EAP authentication and is used for in-flight texting with GoGo. Since it can’t be removed, T-Mobile devices are constantly probing for this network and, like any other saved AP, will attempt to connect to a properly configured AP with the same ESSID. There is a possibility of trying to perform some rouge attacks with Evil Twin tool eaphammer, but that isn’t what I immediately noticed.

The device currently in focus with the MAC address of DC:EF:CA:7C:08:0E is quickly enumerated as a T-Mobile device, as it was probing for the TMobileWingman AP. That same device was also associated to free wifi access point. If this device were to be targeted as a means of gathering credentials, it would be trivial to use a Man-In-the-Middle attack to present a T-Mobile themed web page to the user.

Additionally, with BeaconGraph, it’s easy to quickly visualize which access points are the most popular (xfinitywifi, attwifi and TMobileWingman seem to be the usual culprits) and prepare a Known WLAN list for tools such as WifiPhisher during assessments.

Conclusion

BeaconGraph should be a welcome tool to any wireless auditor or penetration tester. While not yet considered a full release at just v0.2, there are plans to expand its features in the future. Graph visualization is an amazing medium to representing data for technical and management perspectives so check out BeaconGraph if this type of representation interests you!