[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 709
  • Last Modified:

Syslog reports a PC telnetting to a device. Can't figure out how it's being done

I should preface this with:  I have had no security/digital forensics training, other than the various books I've read. Please don't make assumptions on my part, I may have missed something entirely elementary to those familiar with these things.

I apologize for the length, but wanted to be thorough.  

I've got syslog enabled on our switches, going to a splunk front-end (which has been really great for us, btw). In it, I've noticed a few entries in the syslog pertaining to a PC

#.#.#.#	%AAA-E-AUTHFAIL: Authentication failed for telnet, source - #.#.#.#

Open in new window


I've done what I consider to be a thorough examination of the source PC, which is a server I've inherited.  It is a Win2K3 machine, non-AD.  Serving database driven software via software client.  

in its running state (before I made any changes), I:

Pulled the event viewer logs off the PC
Pulled the McAfee logs off the PC
Ran a full NMAP and an authenticated full Nessus scan against the PC
Interrogated the PC for running processes, software, etc.

Results I found:
Event viewer had the typical stuff.  I saw the regular users logging in an out at their regular times.
McAfee logs didn't show an oddities.  Seemed to be running through it's usual gyrations.

Security scans didn't really reveal much to me.  There were a few open ports, but they were appropriate for the services required to run.  Patches were awaiting a reboot.  Weak SSL was in place on the IIS server, but IIS wasn't open to the outside via firewall.  RDP was of the weak variety.    OS firewall was turned off, which I dislike seeing; the vendor's product recommends it, apparently.

The processes seemed to be in order, nothing obviously non-windows or outside the software vendors services were running.  Windows updates were awaiting a reboot.

So, having found nothing unusual (to me) I did some more active interrogation.

I performed a:

McAfee .dat update - already at latest.
A full McAfee scan, looking for rootkits, etc. - no results.
Microsoft Baseline Security Analyzer scan, it complained about non-expiring passwords and updates. - made the required changes until the MBSA only complained about the updates.
At the request of my manager, performed an additional Malware scan with MalwareBytes.  Nothing found.
Interrogated the software vendor and determined IIS and other services were not needed.  Removed all unneeded software/services.
Applied a reboot for windows updates.

After reboot, I looked for further updates, and found none were available, neither for the OS nor vendors software.

I  re-scanned with Nessus and found the vulnerabilties to be lessened greatly.  Nessus is slightly paranoid with what in my opinion are merely informational alerts, but I'd rather have it that way than miss something.

Having not found much in the way of an real security issues, other than firewall, I've  attempted to gather the necessary exceptions needed to allow business to be conducted as usual.  So far, I've not turned the firewall services on.  I, personally, would rather figure this out than simply block it.

I have seen those same syslog entries continue unabated since my investigation has started.

I've considered the possibility that a user has set his IP to the same as the server to attempt some recon... wouldn't I see the IP conflicts in the event viewer though?

What have I missed, or what else should I have done or do?    

In other cases where I've found similar Syslog entries, the PC has invariably been infested with a trojan.   Dispersing a technician for a full scan has fixed this every time.
0
MU-IT
Asked:
MU-IT
  • 9
  • 7
1 Solution
 
Dave HoweCommented:
run microsoft network monitor (free from the MS site) and filter on tcp.port==23

whatever it still shows, is the offender :)
0
 
Dave HoweCommented:
and yes, if you do that you would see ip address conflicts, and /or looking at the mac table on the complaining host (or the upstream router if these aren't in the same subnet) should give you the hardware unique address of the machine asking the questions.
0
 
MU-ITAuthor Commented:
oh, jeez, I forgot that whole part.

I did run a netstat -aon to see who's listening on the telnet port, but it's not very "active".  I'd have to catch whatever it is "in the act".

I'll set this up and see what shakes out.
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
Dave HoweCommented:
yes. netstat is a snapshot of port activity.
network monitor can have a capture filter of tcp.port==23 and will *only* record traffic that matches that filter - so you can leave it running the rest of the day, and will only "see" the telnet traffic.
0
 
MU-ITAuthor Commented:
I've got it running now.  Having not run this (I do more wireshark stuff, and am embarrassed that I didn't think of this on my own!) I'm not sure the filter is applied.  Does this look correct to you?

http://i.imgur.com/dKuFS.jpg
0
 
Dave HoweCommented:
no. that's the display filter (not the capture filter)
you must also hit the "apply" button to make it take effect.
0
 
Dave HoweCommented:
and wireshark is a much better analysis tool, with one downside - it doesnt' log which program sent the data. MSNM is inferior in analysis, but tells you what exe sent the packet in question :)
0
 
MU-ITAuthor Commented:
I assumed there was a reason that the MSNM was recommended.   Thanks for your help!

0
 
MU-ITAuthor Commented:
I haven't gotten it solved yet, but feel that this is enough to fill in the gap.  I'll return to this thread with my findings.

thanks again Dave!
0
 
Dave HoweCommented:
Will look forward to finding out what it was. assuming it wasn't just a random port hit :)
0
 
MU-ITAuthor Commented:
Add'l note: The "capture filter" is under "Capture Settings" in the toolbar on MSNM 3.4.

This capture seems to be doing more along the lines of what I expected.
0
 
Dave HoweCommented:
yup. in 3.3 it was a tab in the same block as the display filter, but I think they wanted it to look more wireshark-like :)
0
 
MU-ITAuthor Commented:
McAfee's RSSensor.exe was doing the telnetting.  I've uninstalled the "feature" and haven't seen the behavior resume.  I'll continue to watch the system for a few days.

I can't find anything in the McAfee documentation, or on Google, that explains why RSSensor would be doing this.
0
 
Dave HoweCommented:
This is what RSSensor is for! :)

It is the Rogue System Detector, and basically intercepts local traffic (using a packet dll) looking for traffic from hosts that aren't already known. In those cases, it does a portscan of the target machine similar to the way that nessus/nmap does, in order to "fingerprint" the target system os.
If you want to disable this, look for "Scan detected system for OS details" in the policy config tool, and disable it  :)
0
 
MU-ITAuthor Commented:
We're not running the rogue system plugin on ePO, so I'm not sure why it was ever even installed...I should have uninstalled it when I went through the programs and services initially.  But I'm glad to have had your help in figuring it out.

Thanks again.
0
 
Dave HoweCommented:
you are welcome. at least you know now it was something relatively harmless :)
0

Featured Post

Vote for the Most Valuable Expert

It’s time to recognize experts that go above and beyond with helpful solutions and engagement on site. Choose from the top experts in the Hall of Fame or on the right rail of your favorite topic page. Look for the blue “Nominate” button on their profile to vote.

  • 9
  • 7
Tackle projects and never again get stuck behind a technical roadblock.
Join Now