Opportunities

Recall the “What problems does Frenetik help solve?” section. There are techniques one can employ to gain the upper hand.

  1. While identity is internet facing, easily guessable/discoverable, and the SSO spread nightmare is the norm, it need not be a massive vulnerability for your most critical accounts.
    • Authentication handles (User Principal names) are NOT required to be the same as the Communication Handle (E-mail address), and while the behind-the-scenes identifier for the User Principal Name is static, the User Principal Name itself (what you login with) is not, and there is no known unauthenticated mapping mechanism to take a static GUID to current UPN. So, we can take your Entra/AWS/GCP privileged user account that was previously static – like john.smith.adm@company.onmicrosoft.com and change it at random or consistent intervals to barkingrooster-256@company.onmicrosoft.com, darkcardinal-991@company.onmicrosoft.com, etc. You can do this daily, weekly, monthly, quarterly, etc. This can help with preventing targeting of privileged accounts, and make it so the adversary is never fully prepared to execute on their objectives as the previously static environement is now changing beneath their feet. How do the legitimate users know of the change? Frenetik sends them a configurable out of band alert – SMS, Signal, Burner Email, Printed Card.
  2. Modern remote access is largely moving away from the classic physical vpn appliance perpetually internet exposed at the edge, accepting in IPSEC or TLS for remote access, and direct IP to IP access. It is being replaced by the like of Secure Access Service Edge (SASE), which effectively stitches together a remote user connection egressed and connected TO the SASE cloud, and on-prem resources via a connector machine egressed and connected TO the SASE cloud. This means that there is no more internet facing, constantly poked edge vpn appliance. Rather, there are two or more parties stitched together via API’s, where application logic controls access – no more direct IP to IP communications. This creates an incredible defender opportunity independent of Frenetik, but WITH Frenetik becomes a superpower.
    • We currently integrate Frenetik In-Use deception with Microsoft Private Access and ZScaler Private Access. For a remote user with the Microsoft or ZScaler agents that are connected to their clouds, who want to access a resource through them, one can communicate to the resource via a Fully Qualified Domain Name (FQDN), for example, say I want to access an internal jumpbox at jumpbox1.internal.company.com. On the remote user machine that the DNS lookup occurs on, instead of a traditional remote access VPN that would just give answer with the real IP, these SASE solutions give you a local IP to forward to, and then via the magic of port forward and NAT magic, it connects you with the end resource on-premises via the connector. This alone is great, it means that it is possible for a defender to make it so the old school method of scanning subnets once connected to the vpn is not effective. However, we are still beholden to HUMAN NATURE, in that the hostname to resolve is unchanged. This is where Frenetik comes in. On a daily, weekly, monthly, random interval – we will change that FQDN via integration with the SASE connectors, notify your privileged users via out of band methods so they know the new hostname (to reach the same existing jumpbox), and then point the old hostname connections to your honeypot – like Thinkst Canary, or Security Onion IDH.

There you have it, new ways of identity and remote access also allow for new ways of defense! These methods are exceptionally good at defeating AI driven attacks that RELY ON PREDICTABILITY AND DISCOVERABILITY! By putting randomness in the loop, removing the discoverability, human and AI hackers are going to face a new formidable defense!!