首页
论坛
专栏
课程

[系统底层] [讨论]SYSTEM进程无法访问网络,如何解决?

2016-9-17 21:53 6151

[系统底层] [讨论]SYSTEM进程无法访问网络,如何解决?

2016-9-17 21:53
6151
在NT6系统,一个SYSTEM的进程,Session 0,  发现试图使用WinHTTP,WinINet等等网络组件进行网络访问,都是失败的;如 WinHttpSendRequest 一定会返回ERROR_WINHTTP_CANNOT_CONNECT 无法链接。

但是完全相同的代码(很简单),相同的程序,以当前用户(桌面交互)身份运行,在Session 1, 网络访问是正常的;

另外,在NT5(如XP)系统中,当程序以SYSTEM身份运行时,网络访问也是正常的;

我在网上查不到相关资料如何解决(都是建议不要以系统身份来运行程序),自己想跟踪一下发现不太容易弄清楚,有哪位朋友了解这个问题的吗?能否说一下原因以及该如何解决?谢谢!

[挑战]看雪.纽盾 KCTF 2019晋级赛Q3攻击方进行中……,华为P30 Pro、iPad、kindle等你来拿!

最新回复 (21)
hzqst 3 2016-9-18 13:42
2
0
谁说session 0不能访问网络的。。你让mysql、redis怎么活
JmpNext 2016-9-18 18:37
3
0
我不是这个意思,我的意思是,我写一个测试程序,使用WinHTTP下载文件,运行在SYSTEM-Session 0时,WinHttpSendRequest总是返回ERROR_WINHTTP_CANNOT_CONNECT;而在桌面用户-Session 1时, 完全没问题; 程序极简单,除了使用WinHTTP再无其它。

SYSTEM-Session 0肯定是可以访问网络的,只是我不知道应该要做什么特别的工作;

通过跟踪,暂时发现:
0:003> kn 100
# ChildEBP RetAddr  
00 00d8fb10 75786a96 ntdll!RtlSetLastWin32Error                                //00000005, 拒绝访问
01 00d8fb20 757a2432 KERNELBASE!BaseSetLastNTError+0x18
02 00d8fb34 74ffc1c8 KERNELBASE!GetOverlappedResult+0x8e        //OVERLAPPED.Internal = 0xC0000022, STATUS_ACCESS_DENIED
03 00d8fb7c 76c9e8b3 mswsock!WSPGetOverlappedResult+0x5e
04 00d8fba8 70e52418 WS2_32!WSAGetOverlappedResult+0x56
05 00d8fbdc 70e323c0 webio!WapTcpThreadPoolCompletionRoutine+0x68
06 00d8fc34 76be8094 webio!WapTpIoCompletionRoutine+0xdc
07 00d8fc58 7746e7af kernel32!BasepTpIoCallback+0x2f
08 00d8fcb4 77490748 ntdll!TppIopExecuteCallback+0x1c5
09 00d8fe1c 76c01174 ntdll!TppWorkerThread+0x5a4
0a 00d8fe28 774bb3f5 kernel32!BaseThreadInitThunk+0xe
0b 00d8fe68 774bb3c8 ntdll!__RtlUserThreadStart+0x70
0c 00d8fe80 00000000 ntdll!_RtlUserThreadStart+0x1b

在 WinHttpSendRequest -> 完成例程被调用 -> GetOverlappedResult 从内核组件中返回了 0xC0000022,  NtStatusToSocketError 后是 0x0000271D, ERROR_WINHTTP_FROM_WIN32 之后就是 0x00002EFD, 而 0x00002EFD 正是 ERROR_WINHTTP_CANNOT_CONNECT

我现在不知道 GetOverlappedResult 为什么会返回 STATUS_ACCESS_DENIED,还要去跟踪内核。

现在只能暂时怀疑可能与进程的Token有关,当然也可能不是;
JmpNext 2016-9-18 20:12
4
0
我分析错误, 0xC0000022 不是在 KERNELBASE!GetOverlappedResult 产生的,webio!WapTpIoCompletionRoutine 的第3个参数是 OVERLAPPED ,  在这个节点上 OVERLAPPED.Internal 就已经是 0xC0000022 了.....  实在很难分析,过程太长;

没有哪位朋友知道可能是什么原因吗?
JmpNext 2016-9-18 22:15
5
0
我跟踪到了 0xC0000022 的产生,但还没知道具体的原因:

1: kd> kn 100
# ChildEBP RetAddr  
00 90a374e0 8884b642 tcpip!WfpAleClassify+0x7c        //push    0C0000022h;  call tcpip!WfpReportAppErrorAsNtStatus;
01 90a3780c 88857e4d tcpip!WfpAlepAuthorizeConnect+0x866
02 90a379b8 88848655 tcpip!WfpAleAuthorizeConnect+0x308
03 90a379e8 8884730c tcpip!InetInspectConnect+0x3c
04 90a37a3c 888534b7 tcpip!TcpContinueCreateAndConnect+0x4dc
05 90a37a54 88842ae2 tcpip!TcpCreateAndConnectTcbInspectConnectRequestComplete+0xf8
06 90a37abc 88853359 tcpip!TcpCreateAndConnectTcbWorkQueueRoutine+0x4df
07 90a37b18 8e937898 tcpip!TcpCreateAndConnectTcb+0x800
08 90a37bec 8e92d504 afd!AfdSuperConnect+0x48a
09 90a37bfc 83e484bc afd!AfdDispatchDeviceControl+0x3b
0a 90a37c14 84049eee nt!IofCallDriver+0x63
0b 90a37c34 84066cd1 nt!IopSynchronousServiceTail+0x1f8
0c 90a37cd0 840694ac nt!IopXxxControlFile+0x6aa
0d 90a37d04 83e4f42a nt!NtDeviceIoControlFile+0x2a
0e 90a37d04 77db64f4 nt!KiFastCallEntry+0x12a
0f 003ae788 77db4cac ntdll!KiFastSystemCallRet
10 003ae78c 7590799f ntdll!NtDeviceIoControlFile+0xc
11 003ae824 759078bc mswsock!SockDoConnectEx+0x96
12 003ae874 7162750d mswsock!MSAFD_ConnectEx+0xbb
13 003ae950 716271ab webio!WapTcpConnectSocket+0x1ac
14 003ae968 7162701b webio!WapTcpStartConnect+0x172
15 003ae98c 7162d9dc webio!WapTcpDnsQueryCompletionRoutine+0xaa
16 003ae9c8 71626837 webio!WapTcpStartDnsQuery+0x1d6
17 003ae9ec 716266e2 webio!WaTcpConnectRequest+0x2c
18 003aea38 71626671 webio!WapHttpConnect+0x69
19 003aea58 71624105 webio!WaQueueHttpRequest+0x1c4
1a 003aea78 716240b1 webio!WapStartQueueRequest+0x2a
1b 003aea94 71624043 webio!WapGetConnectionCompletionRoutine+0xa9
1c 003aeabc 71623fae webio!WapStartGetConnection+0x115
1d 003aeae0 71623f18 webio!WapStartGetEndpoints+0xf6
1e 003aeb2c 71623db5 webio!WapAsynchronousSendHttpRequest+0x279
1f 003aeb60 71623d45 webio!WapSendHttpRequest+0x49
20 003aebb4 7167698d webio!WebSendHttpRequest+0x34
21 003aebec 716768b8 WINHTTP!WEBIO_SENDER::SendRequest+0x14e
22 003aec18 716766f0 WINHTTP!WEBIO_REQUEST::SendRequest+0x27a
23 003aec78 716763d1 WINHTTP!HTTP_USER_REQUEST::_SysSendRequest+0x40d
24 003aecbc 7167610d WINHTTP!HTTP_USER_REQUEST::_SendRequestWithDrainComplete+0x1f2
25 003aece0 71675e88 WINHTTP!HTTP_USER_REQUEST::SendRequest+0x524
26 003aedb0 001e12c3 WINHTTP!WinHttpSendRequest+0x245
27 003aff10 001e1565 MYTest!WinHttpDownLoad+0x16f
28 003aff2c 001e1578 MYTest!TEST+0x24
29 003aff38 77271174 MYTest!WinMain+0xa
2a 003aff44 77dcb3f5 kernel32!BaseThreadInitThunk+0xe
2b 003aff84 77dcb3c8 ntdll!__RtlUserThreadStart+0x70
2c 003aff9c 00000000 ntdll!_RtlUserThreadStart+0x1b

其中 tcpip!WfpAleClassify 单步执行结果如下:

tcpip!WfpAleClassify:
0008:88887640 55              push    ebp
0008:88887641 8bec            mov     ebp,esp
0008:88887643 51              push    ecx
0008:88887644 53              push    ebx
0008:88887645 56              push    esi
0008:88887646 33db            xor     ebx,ebx
0008:88887648 57              push    edi
0008:88887649 8b7d08          mov     edi,dword ptr [ebp+8]
0008:8888764c 895dfc          mov     dword ptr [ebp-4],ebx
0008:8888764f be94a58e88      mov     esi,offset tcpip!`string' (888ea594)
0008:88887654 385d14          cmp     byte ptr [ebp+14h],bl
0008:88887657 740b            je      tcpip!WfpAleClassify+0x26 (88887664)

0008:88887664 ff751c          push    dword ptr [ebp+1Ch]
0008:88887667 0fb707          movzx   eax,word ptr [edi]
0008:8888766a 53              push    ebx
0008:8888766b ff7510          push    dword ptr [ebp+10h]
0008:8888766e ff750c          push    dword ptr [ebp+0Ch]
0008:88887671 57              push    edi
0008:88887672 50              push    eax
0008:88887673 e81bd30000      call    tcpip!KfdClassify (88894993			//返回 false
0008:88887678 3bc3            cmp     eax,ebx
0008:8888767a 7410            je      tcpip!WfpAleClassify+0x4e (8888768c)	//Yes

0008:8888768c 8b4d18          mov     ecx,dword ptr [ebp+18h]
0008:8888768f 3bcb            cmp     ecx,ebx
0008:88887691 741c            je      tcpip!WfpAleClassify+0x71 (888876af)	//No
0008:88887693 8b450c          mov     eax,dword ptr [ebp+0Ch]
0008:88887696 8b4064          mov     eax,dword ptr [eax+64h]
0008:88887699 3bc3            cmp     eax,ebx
0008:8888769b 7412            je      tcpip!WfpAleClassify+0x71 (888876af)	//No
0008:8888769d 385829          cmp     byte ptr [eax+29h],bl
0008:888876a0 740d            je      tcpip!WfpAleClassify+0x71 (888876af)	//Yes


0008:888876af 8b451c          mov     eax,dword ptr [ebp+1Ch]
0008:888876b2 813801100000    cmp     dword ptr [eax],1001h
0008:888876b8 7540            jne     tcpip!WfpAleClassify+0xbc (888876fa)	//No
0008:888876ba 6a01            push    1
0008:888876bc 53              push    ebx
0008:888876bd 68220000c0      push    0C0000022h
0008:888876c2 56              push    esi
0008:888876c3 53              push    ebx
0008:888876c4 e805d2ffff      call    tcpip!WfpReportAppErrorAsNtStatus (888848ce)


下一步将对比在 桌面用户-Session 1 环境下运行时的过程有什么不同,不知道能不能找到原因;
JmpNext 2016-9-19 21:56
6
0
看来,在NT6, SYSTEM进程可能就是被系统禁止进行TCP连接的;

据测试确定,程序被svchost.exe运行起来的时候,是SYSTEM身份,到tcpip!CheckConnectBypass的时候,第3个参数的第1个成员,值将是 07h,  就将导致WfpAlepAuthorizeConnect继续调用WfpAleClassify, 而WfpAleClassify将返回0xC0000022,其实没有错误产生,就是系统禁止了当前身份的进程进行TCP连接。

而以桌面用户的身份运行程序的时候,CheckConnectBypass第3个参数的第1个成员,值将是 1002h, WfpAlepAuthorizeConnect 基本是马上返回了 STATUS_SUCCESS ;

当以SYSTEM身份运行时,在CheckConnectBypass返回后下断,手动将 07h 改为 1002h, 仅此一点,WfpAlepAuthorizeConnect 就返回了STATUS_SUCCESS,  网络连接成功了,程序运作正常了!

粗略看了一下CheckConnectBypass,其将调用BuildEnumConditions, 而在这个函数中出现GetApplicationIdField, GetUserIdField ... 等, 可见其可能是在构建一些与进程、用户相关的信息,以供稍候检查;

另外,如果svchost.exe 以 CreateProcessAsUser 来创建进程(用的是explorer的Token),程序访问网络是成功的! 可见,这个问题就是进程的用户身份的问题,SYSTEM这个身份,在NT6,可能被系统禁止了tcp连接;(在xp等NT5系统是没有这个问题的)

WfpAleAuthorizeConnect 具体工作原理我并不知道, 但从函数名称理解,这个很可能是类似于防火墙, 就是:现在有一个TCP连接请求,是否通过?  在SYSTEM身份的时候,返回的是0xC0000022 - STATUS_ACCESS_DENIED - 拒绝!

我现在暂时怀疑系统可以对此进行设置(如在注册表的什么地方),但是不清楚。

或许会放弃,越往下,过程越长越多越复杂,真不是我等菜鸟可以弄清楚的;
JmpNext 2016-9-19 22:10
7
0
另外,这个问题还牵涉到netio.sys,比如,tcpip!CheckConnectBypass 会调用NETIO!KfdCheckConnectBypass 与 NETIO!KfdCheckAndCacheConnectBypass 等,netio内部维护了一个 gWfpGlobal , 这可能是一个表,有点儿类似于白名单;KfdCheckConnectBypass 的时候会 FindConnectBypassCacheEntry 从这个表中找匹配 ...
shayi 9 2016-9-19 22:54
8
0
0008:888876af 8b451c          mov     eax,dword ptr [ebp+1Ch]
0008:888876b2 813801100000    cmp     dword ptr [eax],1001h
0008:888876b8 7540            jne     tcpip!WfpAleClassify+0xbc (888876fa)  //No
0008:888876ba 6a01            push    1
0008:888876bc 53              push    ebx
0008:888876bd 68220000c0      push    0C0000022h
0008:888876c2 56              push    esi
0008:888876c3 53              push    ebx
0008:888876c4 e805d2ffff      call    tcpip!WfpReportAppErrorAsNtStatus (888848ce)

注意这里,ebp+1ch 是不是tcpip!WfpAlepAuthorizeConnect() 传递给 tcpip!WfpAleClassify() 的第一个参数?它被复制到 eax 中,然后与立即数 0x1001 比较,看来结果是相等的,因此调用 tcpip!WfpReportAppErrorAsNtStatus() ,现在就要回溯分析,为啥
0x1001 会导致 0xC0000022 拒绝访问,看来是被 Windows 过滤平台中的钩子函数给禁止连接了;

另外,你可以编程方式,在 system 进程中创建内核线程(PsCreateSystemThread())来建立网络连接,尝试绕过潜在的进程用户身份或令牌检查。据我所知,如果编写驱动来使用 Winsock Kernel,而不是使用那些用户模式网络 API ,是可以绕过令牌检查逻辑的,比如 WskConnect(),WskAccept() 等等。
OXFFFFFFFE 2016-9-19 23:20
9
0
你是系统里面有其他防火墙吧   

这肯定不是系统自己的限制, 这样限制还得了, 所有服务程序, web 服务器, 数据库 , 不是全都不能用?
JmpNext 2016-9-19 23:23
10
0
系统是纯净的,没安装任何第三方软件; 并且,系统自带的防火墙确认已关闭。 按现在这个情况来看,系统肯定默认限制了SYSTEM的tcp连接权限,而系统可能开放了某种方法可以去除这种限制; 至于一些服务程序,不一定全在LocalSystem, 可能是在LocalSerivce或者NetworkService等,在这些身份下,访问网络当然是没问题的。
JmpNext 2016-9-20 00:40
11
0
[QUOTE=shayi;1445677]0008:888876af 8b451c          mov     eax,dword ptr [ebp+1Ch]
0008:888876b2 813801100000    cmp     dword ptr [eax],1001h
0008:888876b8 7540          ...[/QUOTE]

tcpip!CheckConnectBypass+0xf7
tcpip!WfpAleAuthorizeConnect+0x20d

关键点在于 CheckConnectBypass 获得的值(上面提到), SYSTEM的是07h, 桌面用户为1002h;如果是1002h, 在随后的 WfpAleAuthorizeConnect 调用 WfpAlepAuthorizeConnect 时, WfpAlepAuthorizeConnect 不再调用WfpAleClassify, 而是基本直接就返回STATUS_SUCCESS; 现在是要弄清楚为什么SYSTEM是07h, 而桌面用户是1002h;  要弄清楚并不简单,因为就是要搞清楚各种的数据结构以及其成员的作用意义,都需要大量的时间。
blackcore 2016-9-20 08:52
12
0
你可以用socket
JmpNext 2016-9-20 16:43
13
0
这种情况下使用socket估计是一样的下场,socket一样要通过tcpip.sys; 要绕过这个问题,还有很多迂回的办法,比如,可以CreateProcessAsUser以桌面用户身份运行程序,工作是没问题的; 现在只是测试而已,不是要开发什么, 现在只是想学习一下,弄清楚这个问题而已, 避开这个问题而转用其它方法没有任何意义。
OXFFFFFFFE 2016-9-22 11:54
14
0
socket如果也有这问题......那mysql那些真的是没法用了.....

另外我再次确认了一下...我的一个服务程序 , 调用的wininet获取版本信息.
在WIN7/8/10环境下全部正常

用的是MFC的那个CInternetFile
JmpNext 2016-9-22 17:17
15
0
我是这样怀疑的,这个限制不是指定于"SYSTEM"身份,而是指定了"某个进程"!  而某个SYSTEM-svchost.exe ,在NT6系统,被系统禁止了TCP连接;

越往底下分析,就会发现大量的类似于防火墙的函数被调用;

这个禁止,怀疑是系统固定的,就是不能通过"系统自带的防火墙接口"来设置或者关闭;

我通过无数次的测试,Windbg+VMWare实时分析,加IDA逆向,甚至我弄清楚了一些结构的作用,确定那个svchost.exe被系统禁止了TCP连接。
JmpNext 2016-9-22 17:33
16
0
这个问题我已经无法继续研究下去了,因为底层实在太复杂,并且所有书籍、百度、Google都找不到任何相关的资料,对那片底层的了解基本是0;

0c 8d8ab764 88768396 NETIO!KfdGetLayerActionFromEnumTemplate+0x56
0d 8d8ab784 8887b1f9 NETIO!KfdCheckAndCacheConnectBypass+0x26
0e 8d8ab854 88882d52 tcpip!CheckConnectBypass+0xf7

CheckConnectBypass 是一个关键点,我猜它的意思可能就是,现在tcpip要创建一个tcp连接,请求NETIO来验证: 这个连接是否"放过"; 而那个SYSTEM-svchost的结果就是STATUS_ACCESS_DENIED, 拒绝;

我逆向了一些函数,你看 KfdGetLayerActionFromEnumTemplate 是这样的:

NTSTATUS __stdcall KfdGetLayerActionFromEnumTemplate(WORD wLayerNum, void *pInStruct, ST28 *pParentST28)
{
	NTSTATUS	ntStatus;
	STGL		unkst;
	ST28		LocalST28, *pTempST28;
	
	
	//初始化
	memset(pParentST28, 0, sizeof(ST28));
	pParentST28->dwUnk_18 = 1;
	pParentST28->dwValue = 8;
	memcpy(&LocalST28, pParentST28, sizeof(ST28));

	memset(&unkst, 0, sizeof(unkst));
	unkst.dwUnk_0C = 0xFFFF;
	
	//循环  Enum .. GetNext .. Free
	ntStatus = FeEnumLayer(wLayerNum, pInStruct, 0, (void**)&unkst.pRevST);			//Enum
	if(ntStatus == STATUS_SUCCESS)
	{
		for(;;)
		{
			WORD	wTemp;
			
			
			ntStatus = FeGetNextFilter((void**)&unkst.pRevST, (int)&pTempST28);	//GetNext
			if(ntStatus || pTempST28 == NULL)
				break;
			
			wTemp = (WORD)pTempST28->pSTin28->dwUnk_10;
			if (wTemp == (WORD)unkst.dwUnk_0C)
			{
				if(unkst.bBOOL3 == TRUE)
					goto __FOREND;				//下一次循环
			}
			else
			{
				unkst.bBOOL3 = FALSE;
				unkst.dwUnk_0C = wTemp;
			}

			if(IsFilterBypassAvailable(pInStruct, pTempST28))						//FilterBypass  Is Available ?
			{
				if(pTempST28->pSTin28->dwValue & 0x4000)
				{
					if(IsActiveCallout(pTempST28, 0, 0) == TRUE)					//Callout Is Active?
						pParentST28->dwValue = 7;//循环将结束
					else
						goto __FOREND;			//下一次循环
				}

				UpdateClassifyOut(&LocalST28, pParentST28, pTempST28, NULL, &unkst);//Update

				if(pTempST28->pSTin28->dwValue & 0x1000)
				{
					unkst.bBOOL3 = TRUE;
					if(pTempST28->pSTin28->dwValue == 0x1001)
						unkst.bBOOL1 = TRUE;
				}
			}
			else
			{
				if(pTempST28->pSTin28->dwValue != 0x1002)
					pParentST28->dwValue = 7;	//循环将结束
				else
					unkst.bBOOL2 = TRUE;
			}

		__FOREND:
			if(!_InterlockedExchangeAdd((volatile LONG *)&pTempST28->dwUnk_08, 0xFFFFFFFF))
				HandleFilterFree( pTempST28 );//Free

			if(pParentST28->dwValue == 7)
				break;
		}
  }
  FreeMatchBufList( unkst.pRevST );			 //Free

  //Result
  if(ntStatus == STATUS_SUCCESS)
  {
	  if( pParentST28->dwValue == 8 )
		  pParentST28->dwValue = 0x1002;

	  if( unkst.bBOOL1 && unkst.bBOOL2 )
		  pParentST28->dwValue = 7;
  }
  else
  {
	  pParentST28->dwValue = 7;
	  WfpReportError(ntStatus, "KfdGetLayerActionFromEnumTemplate");
  }

  return ntStatus;
}


KfdGetLayerActionFromEnumTemplate 其实也是一个关键点, 如果这个函数将值置为 7, 基本上就Over了,因为 7 将"间接"导致后来的结果: STATUS_ACCESS_DENIED;如果将值置为 1002, 后面一切都是成功的!!!

从这个函数上可以看到,其实是一个 Enum -> GetNext -> Is Available/Is Active -> Update -> Free 的循环;  这让人想到"对比过滤规则"....

我回到最开始的起点上想, 或许我走了一个大大的弯路,钻进死胡同了, 或许有一个公开的、系统开放的方法或者接口,可以控制这个过程,但我不知道而已。

现在我想去进程的Token上找答案,看看Token的那个地方影响了这个过程,如果是SID,基本也是没救了。
JmpNext 2016-9-24 20:18
17
0
已经彻底被这个问题弄服了,我越来越觉这是微软在NT6系统中故意加入的,WinHttpOpen不拦, WinHttpConnect 不拦, 等你WinHttpSendRequest了就返回个 ERROR_WINHTTP_CANNOT_CONNECT ,让你以为是网络服务器无法连接,其实不是,而是系统底层组件搞个了STATUS_ACCESS_DENIED;

明明是系统 STATUS_ACCESS_DENIED,  WinHttpSendRequest却不返回ERROR_ACCESS_DENIED,而是返回 ERROR_WINHTTP_CANNOT_CONNECT  来误导人,使人误以为是网络服务器无法连接;

这是那个测试进程从某个svchost.exe继承的Token, 现在已经十分确定问题的起点在Token,因为如果Windbg手动改_EPROCESS的Token为Explorer的Token,连接是成功的;

1: kd> !token -n
Thread is not impersonating. Using process token...
_EPROCESS 835b83e0, _ETHREAD 857573d8, _TOKEN 985199a8
TS Session ID: 0
User: S-1-5-18 (Well Known Group: NT AUTHORITY\SYSTEM)
Groups:
00 S-1-16-16384 Unrecognized SID
    Attributes - GroupIntegrity GroupIntegrityEnabled
01 S-1-1-0 (Well Known Group: localhost\Everyone)
    Attributes - Mandatory Default Enabled
02 S-1-5-32-545 (Alias: BUILTIN\Users)
    Attributes - Mandatory Default Enabled
03 S-1-5-6 (Well Known Group: NT AUTHORITY\SERVICE)
    Attributes - Mandatory Default Enabled
04 S-1-2-1 (Well Known Group: localhost\控制台登录)
    Attributes - Mandatory Default Enabled
05 S-1-5-11 (Well Known Group: NT AUTHORITY\Authenticated Users)
    Attributes - Mandatory Default Enabled
06 S-1-5-15 (Well Known Group: NT AUTHORITY\This Organization)
    Attributes - Mandatory Default Enabled
07 S-1-5-80-1580948945-3239616721-2529237571-3761093093-1214243633 (Well Known Group: NT SERVICE\AudioEndpointBuilder)
    Attributes - Default Enabled Owner
08 S-1-5-80-1987853863-1639573247-1110726908-1137832616-3599624523 (Well Known Group: NT SERVICE\CscService)
    Attributes - Default Enabled Owner
09 S-1-5-80-3787436395-2174616005-3003730137-1094982900-1570567328 (Well Known Group: NT SERVICE\dot3svc)
    Attributes - Default Owner
10 S-1-5-80-89818136-74175777-88572358-3912780041-2421659406 (Well Known Group: NT SERVICE\hidserv)
    Attributes - Default Owner
11 S-1-5-80-4028305664-2774326660-44957573-2454826285-2129126537 (Well Known Group: NT SERVICE\HomeGroupListener)
    Attributes - Default Owner
12 S-1-5-80-2506443892-94066030-1663014834-2885971264-4189966690 (Well Known Group: NT SERVICE\IPBusEnum)
    Attributes - Default Owner
13 S-1-5-80-2898649604-2335086160-1904548223-3761738420-3855444835 (Well Known Group: NT SERVICE\Netman)
    Attributes - Default Enabled Owner
14 S-1-5-80-1948712186-1330865447-943413596-1669284603-1648638051 (Well Known Group: NT SERVICE\PcaSvc)
    Attributes - Default Enabled Owner
15 S-1-5-80-949921180-3923668869-394927020-528789358-3592448931 (Well Known Group: NT SERVICE\TabletInputService)
    Attributes - Default Owner
16 S-1-5-80-768763963-4214222998-2156221936-2953597973-713500239 (Well Known Group: NT SERVICE\TrkWks)
    Attributes - Default Enabled Owner
17 S-1-5-80-2014626298-1656748749-3847481816-918933055-2469338456 (Well Known Group: NT SERVICE\UmRdpService)
    Attributes - Default Owner
18 S-1-5-80-2815190569-4075358141-1041947382-2198045348-980246365 (Well Known Group: NT SERVICE\UxSms)
    Attributes - Default Enabled Owner
19 S-1-5-80-3524758515-3090971750-345616940-2322499744-3530715838 (Well Known Group: NT SERVICE\WdiSystemHost)
    Attributes - Default Enabled Owner
20 S-1-5-80-1428027539-3309602793-2678353003-1498846795-3763184142 (Well Known Group: NT SERVICE\Wlansvc)
    Attributes - Default Owner
21 S-1-5-80-113310567-2163499630-2787090463-221477905-209227094 (Well Known Group: NT SERVICE\WPDBusEnum)
    Attributes - Default Enabled Owner
22 S-1-5-80-2652678385-582572993-1835434367-1344795993-749280709 (Well Known Group: NT SERVICE\wudfsvc)
    Attributes - Default Owner
23 S-1-5-5-0-70393 (no name mapped)
    Attributes - Mandatory Default Enabled LogonId
24 S-1-2-0 (Well Known Group: localhost\LOCAL)
    Attributes - Mandatory Default Enabled
25 S-1-5-32-544 (Alias: BUILTIN\Administrators)
    Attributes - Default Enabled Owner
Primary Group: S-1-5-18 (Well Known Group: NT AUTHORITY\SYSTEM)
Privs:
03 0x000000003 SeAssignPrimaryTokenPrivilege     Attributes -
05 0x000000005 SeIncreaseQuotaPrivilege          Attributes -
07 0x000000007 SeTcbPrivilege                    Attributes - Enabled Default
08 0x000000008 SeSecurityPrivilege               Attributes -
09 0x000000009 SeTakeOwnershipPrivilege          Attributes -
10 0x00000000a SeLoadDriverPrivilege             Attributes -
13 0x00000000d SeProfileSingleProcessPrivilege   Attributes - Enabled Default
14 0x00000000e SeIncreaseBasePriorityPrivilege   Attributes - Enabled Default
16 0x000000010 SeCreatePermanentPrivilege        Attributes - Enabled Default
18 0x000000012 SeRestorePrivilege                Attributes -
20 0x000000014 SeDebugPrivilege                  Attributes - Enabled Default
21 0x000000015 SeAuditPrivilege                  Attributes - Enabled Default
22 0x000000016 SeSystemEnvironmentPrivilege      Attributes -
23 0x000000017 SeChangeNotifyPrivilege           Attributes - Enabled Default
29 0x00000001d SeImpersonatePrivilege            Attributes - Enabled Default
30 0x00000001e SeCreateGlobalPrivilege           Attributes - Enabled Default
Authentication ID:         (0,3e7)
Impersonation Level:       Anonymous
TokenType:                 Primary
Source: Advapi             TokenFlags: 0x2800 ( Token in use )
Token ID: 7703a            ParentToken ID: 0
Modified ID:               (0, 77151)
RestrictedSidCount: 0      RestrictedSids: 00000000
OriginatingLogonSession: 3e7

现在怀疑,这个进程的用户(SYSTEM)所属的某个组(Group)可能被限制了TCP连接; 但是找不出来,有朋友能看出这个Token有什么问题吗?
iceway 2016-9-24 23:29
18
0
怎么可能,我注入SYSTEM的进程直接都可以用SOCKET通信
cvcvxk 10 2016-9-24 23:53
19
0
是因为某svchost默认没有联网的权限...你可以试试把所有的权限都Enable一下
elapseyear 2016-10-8 20:06
20
0
system进程是内核态进程,还有cmd也判断为system进程。可能有驱动在联网。如果是svchost进程那就得考虑网络函数等方面。
bydarkst 2018-11-1 12:53
21
0
偶然发现一例跟你一样的现象,已找到解决办法。
shuyangzjg 2018-11-12 13:45
22
0
bydarkst 偶然发现一例跟你一样的现象,已找到解决办法。
哥们 怎么解决的呢
游客
登录 | 注册 方可回帖
返回