Then i would go with option 2, or something similar. Waste the bandwidth or other resources for the sake of stealth.
Once upon a time due to a lot of restrictions, and similar 'performance' annoyances issues, i ended up doing a p2v so i could run the office computer on better/larger hardware, in effect. I have a ( office bought ) MSDN license, so changing hardware the first time didnt burn me. ( later when we started staying home a day or 2 a week, pre pandemic, i redid the office laptop as a host. just shuffled the vm back and forth when i had to come into the office ) May not work for everyone tho..
Sat Aug 05 2023 09:48:19 AM EDT from zelgomerDo they pay you for after hours? If not id say f-it and find
something else to keep yourself occupied at night. Get a hobby.
Okay, but for the sake of argument only, let's say it was to be used during normal work hours too :)
So this person devises a back door using ssh tunnelling over stunnel
(required to diguise the traffic as https because the company's
If the internal network is run by people who love security theater, they're going to catch and terminate this person eventually, so it isn't worth it.
Get an A/B switch, plug the company laptop into the big monitor, attach it to a separate VLAN on the home network, and deal with the slow VPN.
There's probably something in their company security policy that specifically prohibits trying to work around the VPN using any sort of trickery. My employer definitely has that policy in place, and they actively scan end user workstations for software that could work around it.
And then they blow the whole thing by permitting users to log in to Microsoft 365 from any computer.
Between that and us moving to a new ITSM platform, i may never need windows or a shop PC again.
Sat Aug 05 2023 11:22:57 AM EDT from IGnatius T FoobarAnd then they blow the whole thing by permitting users to log in to Microsoft 365 from any computer.
2023-08-05 15:22 from IGnatius T Foobar <ajc@citadel.org>So this person devises a back door using ssh tunnelling over stunnel
(required to diguise the traffic as https because the company's
If the internal network is run by people who love security theater,
they're going to catch and terminate this person eventually, so it
isn't worth it.
Yeah, 100% agree. That's what I would say to this hypothetical person, too.
But let's say you wanted to catch people doing this. As an IT/security person, how would you notice it short of scanning specifically for ssh -R processes? ssh use is allowed where I work, it has to be. We're all using it pretty much constantly.
I would do all of the following:
1. Block all outbound DNS lookups, except through the corporate DNS server
2. Configure that DNS server to use OpenDNS or some similar service that scans, logs, blocks, etc.
3. Force all outbound HTTP/HTTPS traffic through a proxy
4. Configure all workstations to trust a certificate that is installed on the proxy, permitting it to be a man in the middle for approved traffic
Now, if you're legitimately performing outbound SSH to external addresses, that is somewhat more difficult to supervise. There are firewall logs, of course, but those would have to be periodically scanned and searched for suspicious destinations (the "What customer is this?" question). A connection that is open "all day, every day" might turn up on a SIEM report as something worth investigating.
scuttlebutt P2P. new one for me.
( ran across it on a forum talking about moving a DHT crawler source repository off github and onto a scuttlebutt hosted git.. as the founders are banned or something )
2023-08-04 23:32 from zelgomer
Let's say, hypothetically, someone was such a workoholic that they
wanted to connect to their office PC from their home PC so that they
can work late nights and weekends. This person really prefers to use
their home PC because it's really good and has a nice big screen and so
on. Also it's super inconvenient to use the company laptop because it's
slow, the VPN requires frequent reauthentication, and security policies
and spyware has gotten so draconian that this person frankly doesn't
trust having the device in their home.
So this person devises a back door using ssh tunnelling over stunnel
(required to diguise the traffic as https because the company's
firewall won't allow ssh to make it out of the office). Which of these
two configurations do you think is the least suspicious or likely to
result in discovery?
1. Configure the office PC to open a stunnel client to a controlled
host, then use ssh over that to forward a remote port to localhost.
2. Configure the laptop to open a stunnel client to a controlled host,
then use ssh to forward that to the office PC. The laptop is Windows.
The laptop is then kept someplace isolated and connected only by
sequestered guest wifi when in use. When not in use, it's shut off and
put in a shed outside.>connection that has constant activity and never dies. 2 is more
My thoughts: 1 is simpler and more direct, but it looks like an https
wasteful since all data comes into the home network and then out again
through the vpn, but it has the benefit that traffic does go through
the vpn not wrapped in stunnel, so it looks the same as if a person
were just using the laptop normally, except for the active https
connection, but at least that comes and goes with the work hours, so it
looks like a human and not like malware.
I am the workaholic.
I also happen to be the chief sysadmin so I have an VPN link that joins a network segment in my house with office.
I dare say most offices that support people working remotely have some VPN access already set up. Ask your friendly sysadmin for your entry key.
If your firm won't let you get legit remote access you should not bother. RULE #1 of the employee is to never bother with something more than what your coworkers and direct upper-ups do.
That said:
I'd use Wireguard (UDP) to a controlled host using a well known access port (such as the UDP DNS port), since Wireguard is not a chatty protocol and won't generate traffic if you are not using it. THen you can Wireguard or ssh forward to the controlled host. The caveheat is your office sysadmin might be a motherfucker who smells like a horse who has DNS ports under interception or inspection and that would raise alarms.
Stunneling to an https port makes sense for short lived tunnels, since it will look like an https query unless looked at closely. Then again, your sysadmin might be a horse smelling motherfucker who has https traffic under inspection or interception and you are screwed again.
2023-08-07 10:07 from IGnatius T Foobar
I would do all of the following:
1. Block all outbound DNS lookups, except through the corporate DNS
Don't forget to force every DNS query not addressed to the corporate DNS into the corporate DNS server anyway via MITM. I do this a lot with office IoT devices that use hardcoded DNS servers.
ultimately, unless your IT/Security staff are morons or just dont care, that is the eventual outcome.
Tue Aug 08 2023 02:16:28 PM EDT from darknetuseryou are screwed again.