[help] communication with c2 : hacking | Torhoo darknet markets

A thought. Once infection is made have the program go dormant for a certain period of time. After this then make connection. Along with this maybe disguise the traffic as microsoft etc by domain squatting. Idk just some quick thoughts.

definitely going to be a major pain in the ass to network securely. i presume tor is out of the question? or any p2p protocol in general.
you're going to have to rely on a known provider, what about using a google spreadsheet for c2? network detections wont flag accessing a google site. there isn't really any way to get them to connect directly to a server you control. make it poll the google spreadsheet once every, say, 24 hours.

ive seen 'push' c2s implemented before but only through hosting a tor service on the network, which would very likely flag detections in your case.

get a sample of source traffic, try to find common services/traffic to mimic, best of luck if admins keep tabs on traffic

first of all where are you polling the request from is it .onion or to your local machine(which would be very stupid. rather, use public IP addresses e.g your router or something dynamic rather than static) t answer your question is all about your traffic bro sending out commands from unknown traffic is completely stupid so you have to be familiar with the kind of traffic that goes in and out of the company to blend with it

One thing you can do is have an open connection to an onion domain using something like Ninja which is open-source. Though with malware it will automatically assume Tor is downloaded to the systems which you wouldn't want for safer movement and less errors. For evasion and firewall bypassing simple packet spoofing can do the trick but it depends on what systems are being targeted, higher security means higher evasion and tactics. What you can do is use DNS Tunneling to encapsulate your data within DNS queries and responses. This method allows data to be exfiltrated over DNS traffic, which is often allowed through firewalls or you can use HTTPS Tunneling which is similar to DNS tunneling, but uses HTTPS to encapsulate your data. This can be more effective for larger data exfiltrations as HTTPS traffic is more common and less likely to be inspected.

You're absolutely right in identifying the main weakness in most C2 frameworks — the reliance on constant or periodic beaconing creates a very visible footprint, especially in environments where traffic is monitored or logs are regularly audited. What you’re looking for is essentially a true push-style C2 — something that lies fully dormant until it receives a signal to act. That’s harder to implement but totally doable, especially if you’re aiming for long-term stealth and don’t want to raise red flags over several months.

One approach is to separate the trigger mechanism from the actual C2 channel. For instance, instead of having your implant reach out at regular intervals, you could design it to wake up only when it sees a certain “trigger” — like a change in a DNS TXT record, a file drop on a shared drive, or a specific USB being connected. The key is that the trigger channel should look completely benign and not associated with command/control at all. DNS-based triggers are popular, especially in secure environments where outbound DNS is still allowed but HTTP/S is heavily inspected.

Once triggered, the implant could then initiate a short-lived outbound connection, do what it needs to, and then shut itself back down — ideally without leaving persistent processes running or open sockets. The less time it spends alive, the better. Some even go further and design the payloads to live entirely in memory, avoid writing anything to disk, and only reach out using protocols already common in the environment — like mimicking software update traffic or using legitimate API calls.

Another angle to consider is “callback scheduling with jitter.” Instead of polling every 5 minutes like most default C2s do, stretch it out to hours or even days, with randomization. Combine that with environment-aware logic (only connect when the user is active, or only if a particular domain resolves a certain way), and you dramatically reduce the chances of being picked up in a netflow review.

Firewall evasion is trickier, especially without third-party platforms like GitHub or Discord. You’d have to go for either something internal (like SMB-based C2 if the machines are on the same LAN) or use something external that’s indistinguishable from regular business traffic — think cloud hosting under non-obvious domains, or tunneling through whitelisted domains.

All that said — it’s not just about tech. Timing, environmental awareness, and blending in with normal operations are what make or break these kinds of setups. Pull it off right, and you’re basically a ghost.