coworker connected to my PC through an outgoing TCP connection, how is this possible?

Red Squirrel

[H]F Junkie
Joined
Nov 29, 2009
Messages
9,217
Ok, so at work we prank each other a lot, but this just has me baffled.

So I turned on windows firewall, ensured no exceptions were added. He managed to pskill one of my processes by connecting to a server I was connected to and somehow connecting to my PC through an existing TCP session that he saw in netstat.

How is this possible? I understand that when you connect to a server a port opens up on your PC, but I did not figure these ports could be connected to directly, and even then, how did he manage to use psexec through said port?

I'm confused as to how this is done, and it makes me realize I do not understand TCP as much as I thought I did, and perhaps I have some serious vulnerabilities in my home or online servers that I don't realize I have.

So with this exploit, say I was to telnet to a port on a malicious server, through my TCP connection, the server's owner could do anything to my PC. Is this really the case?
 
Is your computer on a domain? Does he have a domain admin account or the local admin account on your computer? Do you have file & printer sharing enabled through Windows Firewall? There's your problem.
 
Yeah we're both domain admins on the network. Everything in the firewall is blocked though, it was checked as an exception but I unchecked it all. So he cannot simply connect to the PC directly.

I will try a 3rd party firewall next time, just to rule out anything specific to windows firewall. From my understanding because TCP happens at a lower layer, the domain admin level does not play any role in the traffic it allows/denies.
 
With the windows firewall, it's possible to add IP exceptions. So, for example, I put one of the DCs in the exception list so it can make outgoing connections to the client PCs. It's not easy to find this info on the client PCs.
 
But my firewall was already on to begin with, and I actually formatted today so I know he had not added his PC at some other point. He did say specificly what server I was connected to and that he used that connection, but would not explain further. My guess is some kind of monkey in the middle attack to somehow execute code on my PC through something like a RDP connection or VSphere connection. No idea how that would work.
 
But my firewall was already on to begin with, and I actually formatted today so I know he had not added his PC at some other point. He did say specificly what server I was connected to and that he used that connection, but would not explain further. My guess is some kind of monkey in the middle attack to somehow execute code on my PC through something like a RDP connection or VSphere connection. No idea how that would work.
You mentioned you are both in a domain. He could have applied a GPO to your workstation to set up the settings.

While a MIM is possible, it's easier to do what I described. Occam's razor and all that.
 
He ran pskill through/from the server you were connected to. As long as he has administrative privileges on both computers(as you said he does), it is easy as pie.

Its quite simple, firewall rules or not, exceptions are automatically created when you create an outbound connection you explicitly allow. Your firewall may close said exception the second the session is closed, but for as long as the session is open, you and said server can communicate without issue. All he did was use that information to hijack that open session to fool with your computer. Its actually the same method many "remote support" tools use to punch through firewalls and NATs.
 
Op what port is he connected to. Even though windows firewall is on Remote sharing is still enabled or disabled? All he need to do is show himself as a trusted host and he is in
 
He ran pskill through/from the server you were connected to. As long as he has administrative privileges on both computers(as you said he does), it is easy as pie.

Its quite simple, firewall rules or not, exceptions are automatically created when you create an outbound connection you explicitly allow. Your firewall may close said exception the second the session is closed, but for as long as the session is open, you and said server can communicate without issue. All he did was use that information to hijack that open session to fool with your computer. Its actually the same method many "remote support" tools use to punch through firewalls and NATs.

That's the way he explained, but how is that possible? Remote support software is different, because the client that is connecting is designed to handle that data and do what it does, but how is he pskilling me through a RDP or LDAP connection, for example?

Where I'm getting at is, let's say I'm downloading a file from a http server, and someone hacks that server, because I have an active connection there, someone can somehow connect to my PC through the port that was opened? That's the way he explained it. I always figured a firewall would differentiate between an incomming initiated connection vs an established one. So if I'm connected to the DC for example, I may have a bunch of high number ports open, but nobody should be able to connect or do anything to those ports, but I seem to be wrong with that.
 
He ran pskill through/from the server you were connected to. As long as he has administrative privileges on both computers(as you said he does), it is easy as pie.

Its quite simple, firewall rules or not, exceptions are automatically created when you create an outbound connection you explicitly allow. Your firewall may close said exception the second the session is closed, but for as long as the session is open, you and said server can communicate without issue. All he did was use that information to hijack that open session to fool with your computer. Its actually the same method many "remote support" tools use to punch through firewalls and NATs.
That doesn't sense. I'll admit right now that I don't know much about how the windows firewall operates beyond the basics, but just letting an explicit outgoing connection does not imply incoming connections from your dst are automatically accepted. In fact, in my rather limited testing, it doesn't work like that.

ie: client A opens a share on server B. While client A is able to access the share unfettered, it does not mean that server B can initiate connections back to client A.

The more I think about it, the more it would seem to be a security flap if the firewall worked as you described.
 
That doesn't sense. I'll admit right now that I don't know much about how the windows firewall operates beyond the basics, but just letting an explicit outgoing connection does not imply incoming connections from your dst are automatically accepted. In fact, in my rather limited testing, it doesn't work like that.

ie: client A opens a share on server B. While client A is able to access the share unfettered, it does not mean that server B can initiate connections back to client A.

The more I think about it, the more it would seem to be a security flap if the firewall worked as you described.

That's what I was thinking too.

Also apparantly whatever he's doing only works in windows. Of course I'm going by what he's saying, but regardless, he did manage to somehow get through the firewall without physically accessing the machine and changing settings. A GPO would only had taken effect upon login/logout or within an hour or so, so it's not something like that either and I checked. It had to do with me being connected to other servers.
 
Domain admin rights override Firewall rules on machines that have joined the domain.

Not true.

But, if you go into Windows Firewall, and Advanced, I'm sure you'll find Allow rules for RPC traffic, which is how the PS suite communicates. Which is of course Windows only...
 
Not true.

But, if you go into Windows Firewall, and Advanced, I'm sure you'll find Allow rules for RPC traffic, which is how the PS suite communicates. Which is of course Windows only...

I'm pretty sure you can't apply permission revocation from objects tagged as part of the AdminSDHolder object.
 
I'm pretty sure you can't apply permission revocation from objects tagged as part of the AdminSDHolder object.
That's not relevant to the discussion. You appear to be talking about AD, whereas we're talking about the client's firewall and GPOs.

The user attempting the connection is irrelevant to the firewall; it cares about the src IP address ( or if you have application exceptions defined, dst ports ).

I stand by my earlier guess. I'm thinking it's a GPO that's whitelisting an IP address that he's "attacking" from.
 
Your all guessing here. there's million ways to do it. But what port did he get thru. Each port has its own vulnerabilities.
 
That's not relevant to the discussion. You appear to be talking about AD, whereas we're talking about the client's firewall and GPOs.

The user attempting the connection is irrelevant to the firewall; it cares about the src IP address ( or if you have application exceptions defined, dst ports ).

agreed.
 
Back
Top