privatefirewall - would like to know more aboutt the PID

Hi,

I got two alerts from the process monitor.

PID 4920
An attempt to create a process has been detected.
Command line: C:\Temp\Tmp\CR_18ECA.tmp\setup.exe

PID 4920
An attempt to adjust process privilege level has been detected.

A little later the same message with slightly different PID# and folder name.

Yet, checking apps and services in a couple of Task Managers, the PID does not exist. Maybe temporary, self-destructing. The folder also did not show in my file manager.

How can I find out the source of all this? If the PID# gave the path associated at the time, that would be a big help. Maybe a browser malware, or a software update is involved. Sounded like a tacky request, so for now I just "block".

Any ideas for improving source detection, appreciated.

Steven

 

Might be a hidden folder. Does anyone else use the system and are you admin? Sounds kind of fishy. If you have the folder then submit the exe to virus total or any other online scanner. Other than that I would run a HMP, MBAM or Emsisoft Emergency kit.

 

What is fishy is the Temp directory in the root.

 

I would choose 'terminate' if it pops up again. It's safer and maybe it would prevent it from hiding again.

 

Hi,

JUMP TO BELOW ***

Thanks. No ongoing problem. It just would have been helpful to know what the PID process was at the time, in case the process terminates itself or something to avoid detection.

Next question. Messages like this can be a puzzle:

"Privatefirewall has blocked incoming UDP (17) packet from nnn.nnn.n.nnn:nnnnn to"

various 255.nnn or 169. numbers

I just tried a reset of the Process Monitor and I have no processes blocked, they are recognized and on allow.

How do I get the source of this ? The log "More Information" again leaves me without much to go on. For many the application line is blank.

Conceptual and practical help appreciated.

I did not have this problem on one user for some months. I am reactivating a somewhat dormant user. I see it might have to do with my little 2-puter network. Do I have do a trust by IP number? Does this involve "network security" .. e.g. Custom? I can no say "Do not display these alerts again" because I want to allow communication, e.g. printer sharing, file sharing, etc.

Ok, maybe I got it.
There were applications that were set to filter, that need "allow". Changes made, for now all ok.
Oops, I got one IGMP. I will be monitoring this, but I see the problem may be in the process of being resolved.

=============

BELOW ****

Here is the remaining problem.

Incoming IGMP packet blocked from 192.168.1.1. I tell it to trust the "remote". The messages continue, although at a mild rate.
The "local" is 224.0.0.1

Steven

 

The inbound UDP from 255.255.255.255(broadcast) is most likely coming from svchost.exe as a result of DHCP activity i.e. ports 67 or 68. from your router's DHCP server. If so, it is safe to allow this.

As far as 169.xxx.xxx.xxx, see below. You really shouldn't be seeing this address range unless something is wrong with the DHCP server on your router.

Definition: A feature of Microsoft Windows, APIPA is a DHCP failover mechanism for local networks. With APIPA, DHCP clients can obtain IP addresses when DHCP servers are non-functional. APIPA exists in all modern versions of Windows except Windows NT.

When a DHCP server fails, APIPA allocates IP addresses in the private range 169.254.0.1 to 169.254.255.254. Clients verify their address is unique on the network using ARP. When the DHCP server is again able to service requests, clients update their addresses automatically.

In APIPA, all devices use the default network mask 255.255.0.0 and all reside on the same subnet.

APIPA is enabled on all DHCP clients in Windows unless the computer's Registry is modified to disable it. APIPA can be enabled on individual network adapters.

Also Known As: Automatic Private IP Addressing; AutoNet

http://compnetworking.about.com/cs/protocolsdhcp/g/bldef_apipa.htm

RFC 1122, pages 67 and 68:

A host SHOULD support local IP multicasting on all connected networks for which a mapping from Class D IP addresses to link-layer addresses has been specified (see below). Support for local IP multicasting includes sending multicast datagrams, joining multicast groups and receiving multicast datagrams, and leaving multicast groups. This implies support for all of [RFC 1112] except the IGMP protocol itself, which is OPTIONAL.

IGMP provides gateways that are capable of multicast routing with the information required to support IP multicasting across multiple networks. At this time, multicast-routing gateways are in the experimental stage and are not widely available. For hosts that are not connected to networks with multicast-routing gateways or that do not need to receive multicast datagrams originating on other networks, IGMP serves no purpose and is therefore optional for now. However, the rest of [RFC 1112] is currently recommended for the purpose of providing IP-layer access to local network multicast addressing, as a preferable alternative to local broadcast addressing. It is expected that IGMP will become recommended at some future date, when multicast-routing gateways have become more widely available.

If IGMP is not implemented, a host SHOULD still join the "all- hosts" group (224.0.0.1) when the IP layer is initialized and remain a member for as long as the IP layer is active.
Joining the "all-hosts" group will support strictly local uses of multicasting, e.g., a gateway discovery protocol, even if IGMP is not implemented.

The mapping of IP Class D addresses to local addresses is currently specified for the following types of networks:

Ethernet/IEEE 802.3.
Any network that supports broadcast but not multicast, addressing: all IP Class D addresses map to the local broadcast address.
Any type of point-to-point link (e.g., SLIP or HDLC links): no mapping required. All IP multicast datagrams are sent as-is, inside the local framing.
Mappings for other types of networks will be specified in the future.

A host SHOULD provide a way for higher-layer protocols or applications to determine which of the host's connected network(s) support IP multicast addressing.

 

Hi,

Thanks for all your help.

Let's focus on the PID number (some messages give only a PID #). What happens when you do not see the PID# in the Task Manager. Is there another way to search it out?

Do other firewalls run into the same scenario? A PID# only, that you simply can not easily track?

Is the PID# an orphan because it was temporary and vanished, or because TaskManager does not show all the PIDs?

There is a utility called "PID Finder". I'm not sure if it gives any PIDs not in Task Manager.

Steven Avery
Bayside

 

Are you looking for PID 4920 with Task Manager before or after you block it? Based on what you've written, I believe that it is the setup.exe process. I don't use PrivateFirewall, but if you choose to block, I would imagine it terminates the process thereby making it no longer viewable in Task Manager. I would be trying to track down what process is extracting and launching C:\Temp\Tmp\CR_18ECA.tmp\setup.exe to begin with. If C:\Temp is your system temp folder, I don't think this looks any different than any other typical installer activity. When does this happen? At random times? Only immediately after rebooting? If it is right after reboot, I would check your autostart locations. Best of luck.

 

Not sure if this will help,but have you tried software like process explorer and process hacker..?

 

I believe he has.