So another thought experiment. I was throwing the idea around with a friend and he brought up a very interesting thing. “What if” a malware writer zitified their malware. How can normal SOC operations detect it? Can an IDS (network, not host based) be somehow placed inline to inspect packets? I feel like this might break some of the ziti integrity. but maybe not? His thought was what if a custom malware was written for a specific use case to mine crypto and all traffic is zitified. But there is also the whole C2 issue as well. The C2 traffic being hidden from view.
1 Like
There are a couple of thoughts here. One, you could build a system that terminates zitified services into a security tools enclave, then picks them back up on the other side. This does break down the basic ideas of Ziti in our minds, but for regulatory compliance or other reasons, it could be possible. I would lean far more toward protecting the endpoints and whitelisting your own OpenZiti network assets as known traffic. As long as you maintain the security of your own OpenZiti network, new targets for C2C couldn’t be established. Regular audit procedures to make sure a controller has not been exploited and new services added, etc. are good practice, alongside strong protections on any deployed nodes. As far as being concerned about zitified traffic within a network from an exploited endpoint, if you have a proxy or other device intercepting TLS traffic with known trusted certificates in your enterprise, and it doesn’t work, then the traffic should be inspected from the source as to why the trusted certificate in the proxy isn’t working. The device would have to be intelligent enough to spot TLS on any port, of course, since it would not all be port 443. In the end, it is very similar to any other malware with an encrypted C2C channel, of which there are many.
2 Likes