Jump to content


 


Register a free account to unlock additional features at BleepingComputer.com
Welcome to BleepingComputer, a free community where people like yourself come together to discuss and learn how to use their computers. Using the site is easy and fun. As a guest, you can browse and view the various discussions in the forums, but can not create a new topic or reply to an existing one unless you are logged in. Other benefits of registering an account are subscribing to topics and forums, creating a blog, and having no ads shown anywhere on the site.


Click here to Register a free account now! or read our Welcome Guide to learn how to use this site.

Photo

Unusual Connection


  • Please log in to reply
1 reply to this topic

#1 itguytim

itguytim

  • Members
  • 3 posts
  • OFFLINE
  •  
  • Local time:03:46 PM

Posted 25 October 2017 - 12:20 PM

I discovered an unusual connection between a Win 7 desktop PC (10.20.30.40) and a domain controller (10.40.30.20).  I'm not sure what it means and I'm hoping to find some information.  About a week ago, our Meraki Firewall started blocking an event where the Win 7 PC was trying to download a file from our domain controller.  It has been happening for the last 7 days at almost the same exact timeHere is part of the packet capture:

 

Internet Protocol Version 4, Src: 10.20.30.40 (10.20.30.40), Dst: 10.40.30.20 (10.40.30.20)
    Version: 4
    Header Length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
    Total Length: 171
    Identification: 0x28bf (10431)
    Flags: 0x02 (Don't Fragment)
        0... .... = Reserved bit: Not set
        .1.. .... = Don't fragment: Set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 127
    Protocol: TCP (6)
    Header checksum: 0xba18 [validation disabled]
        [Good: False]
        [Bad: False]
    Source: 10.20.30.40 (10.20.30.40)
    Destination: 10.40.30.20 (10.40.30.20)
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
Transmission Control Protocol, Src Port: 58372 (58372), Dst Port: 80 (80), Seq: 1, Ack: 1, Len: 131
    Source Port: 58372 (58372)
    Destination Port: 80 (80)
    [Stream index: 0]
    [TCP Segment Len: 131]
    Sequence number: 1    (relative sequence number)
    [Next sequence number: 132    (relative sequence number)]
    Acknowledgment number: 1    (relative ack number)
    Header Length: 20 bytes
    .... 0000 0001 1000 = Flags: 0x018 (PSH, ACK)
        000. .... .... = Reserved: Not set
        ...0 .... .... = Nonce: Not set
        .... 0... .... = Congestion Window Reduced (CWR): Not set
        .... .0.. .... = ECN-Echo: Not set
        .... ..0. .... = Urgent: Not set
        .... ...1 .... = Acknowledgment: Set
        .... .... 1... = Push: Set
        .... .... .0.. = Reset: Not set
        .... .... ..0. = Syn: Not set
        .... .... ...0 = Fin: Not set
    Window size value: 512
    [Calculated window size: 512]
    [Window size scaling factor: -1 (unknown)]
    Checksum: 0xb7d4 [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
    Urgent pointer: 0
    [SEQ/ACK analysis]
        [Bytes in flight: 131]
Hypertext Transfer Protocol
    OPTIONS /Q.exe HTTP/1.1\r\n
        [Expert Info (Chat/Sequence): OPTIONS /Q.exe HTTP/1.1\r\n]
            [OPTIONS /Q.exe HTTP/1.1\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Request Method: OPTIONS
        Request URI: /Q.exe
        Request Version: HTTP/1.1
    Connection: Keep-Alive\r\n
    User-Agent: Microsoft-WebDAV-MiniRedir/6.1.7601\r\n
    translate: f\r\n
    Host: dc01\r\n
    \r\n
    [Full request URI: http://dc01/Q.exe]
    [HTTP request 1/1]
 

 

What is strange is that we have a Q drive shared from dc01.  Is this something behind the scenes that Windows does?

 

Thanks for anyones helps!

 

 



BC AdBot (Login to Remove)

 


#2 itguytim

itguytim
  • Topic Starter

  • Members
  • 3 posts
  • OFFLINE
  •  
  • Local time:03:46 PM

Posted 26 October 2017 - 07:29 AM

Wow....so i think I found the answer.  For this particular user on this particular PC, I had a GPO that mapped the Q drive.  I looked again at the path I set in the GPO and it read "dc01\share" instead of "\\dc01\share".  That must have caused Windows to revert to HTTP.  Type just the name of a domain controller (or any PC in the domain) into the address bar of File Explorer and once DNS is resolved a web browser will open trying to connect to the PC using HTTP.  






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users