Cyber guy. Used to be a lurker but I guess now I can be the occasional poster.
| Site | https://mattysplo.it |
| Pronouns | He/Him |
Mattysploit
@mattysploit@infosec.exchange
- 8 Followers
- 169 Following
- 16 Posts
Each fake app in the dashboard points to a static HTML trap hosted on Azure Static Web Apps or Cloudflare Pages. Want a fake SharePoint? Clone the UI in 15 mins, add some fake docs. Fake VPN? No need to hang some open SSH bait out on the open, you just put the whole thing behind a tile.
No more junk telemetry from mass scans. Instead, you get signal-rich interactions from actors who made it through your fake login, picked a fake app, and thought they’d reached the crown jewels. All of this lives outside your real infra and adds that layer of initial access telemetry. Super handy.
If I threw up a free Cloudflare page with some CanaryTokens on it, nobody would take it seriously out on the internet. But behind a tile? Clearly it must be pRoDuCtIoN /s. I'm curious if an attacker even checks the url bar after popping through a dashboard like this.
This lets you simulate real identity flows—credential stuffing, MFA fatigue, password sprays—without touching production. You can even add basic login automation for realism, like scheduled logins or profile updates.
An IdP allows you to impersonate your real login screen and then the user dashboard enables some pretty sweet modular design. As big/expensive or small/cheap as you like. Mix in throwaway "real" services with static HTML clones. Deploy a T-Pot and call it your VPN. The attacker just sees tiles.
Since Okta doesn't require domain verification, the big advantage here is.. just make up some fake employees.. and build an SSO dashboard full of fake internal apps. To an attacker, there's functionally no way to tell the difference between the two and once inside - it looks totally legit by design.
But frankly, why stop there? With the C2 on the farm's ISP connection and as lightweight as an ARP rebroadcast is - you could feasibly just have a bunch of these all meshed together. I'm betting this is what is happening. It scales. It's cheap. There's redundancy.
Where Sygnia doesn't speculate but I'm happy to shout at clouds about is how this might work more commonly. Putting it all together, a RasPi HID and Controller C2 via ARP is - dare I say, clever? Rebroadcast over ARP would allow command injection and C2 completely outside detection - all local LAN.
The C2 also contains references to Zoom meetings and Remote Control. I've seen this myself, where a foreign remote worker simply takes screen control within a Zoom meeting and works all day through screen share. It works.. low detection.. This code here is Linux stuff though, which isn't common.
Taken in context with this portion, a decoded write to /dev/hidg0, (the device file in Linux that represents a virtual HID) you might be able to start piecing together how this likely works at scale. In other words, if the ARP listen/rebroadcast is nested with the HID write - gotta be Pi or similar:
They don't speculate too much but I'm just 'some guy' so I'm happy to. The code they found on that box is a WebSocket based C2 framework, with an interesting twist: an ARP rebroadcast and listener module:
