Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create Get-NetstatObject.ps1 #208

Merged
merged 6 commits into from
Nov 20, 2022
Merged

Conversation

mwilco03
Copy link
Contributor

No description provided.

@mwilco03
Copy link
Contributor Author

Per conversation ref: #207
Submitted pull request

@davehull
Copy link
Owner

Do you know if there's a specific version of PS or the Get-NetTCPConnection cmdlet that returns the OwningProcess property? In my local lab running PS 5.1 and that property does not exist. Also given that Get-NetTCPConnection only returns TCP connections, it's probably worth renaming this collector from Get-NetstatObject.ps1 to something like Get-NetstatTCP.ps1.

@mwilco03
Copy link
Contributor Author

I tested on two verisons the oldest being 5.1.17134.858
Could you try the following?
Get-WMIObject -namespace Root\StandardCIMV2 -Class MSFT_NetTCPConnection
Piping that to gm or ogv to see if the wmi object has owningprocess ?
Could rewrite it with WMI if that works instead of Get-NetTCPConnection

I agree with the renaming.

@covertpanda
Copy link

Compatible after v3.0+ for PowerShell, utilizing the Get-CimInstance is a newer, better implementation. It is faster than the Get-WmiObject commands, and comply better with CIM and WSMAN standards, allowing better cross-platform compatability and more flexibility. Get-CimInstance (and all -Cim cmdlets) are able to leverage the WSMAN protocol, whereas WMI cmdlets can only use DCOM RPC. By making one tweak, it can increase speed, increase compatibility, and is implemented in native PowerShell since v3.0.

Get-CimInstance -Namespace root/StandardCimv2 -ClassName MSFT_NetTCPConnection

Should be the newer, more PS way to accomplish the same task.

@mwilco03 thoughts?

@mwilco03
Copy link
Contributor Author

100% agree with this assessment @davehull can you validate from your local lab?

@davehull
Copy link
Owner

I should have some time to check this out tomorrow. Thanks.

@mwilco03
Copy link
Contributor Author

mwilco03 commented Jul 25, 2020

@davehull @covertpanda
Per the discussion, I have refactored the code to achieve two goals, first be more readable, secondarily I have pulled the UDP information as well.

IDK how applicable it would be to an enterprise wide sweep / IR investigation but doing the code this way could also allow for functionalization of the code (ie grabbing all procs wither or not they are talking)

-Edited got it working :-)
-Edited updated pull request

@davehull
Copy link
Owner

Have you updated the PR? I've got some time today to check it out.

@mwilco03
Copy link
Contributor Author

No sorry, I’ll get it updated today.

Renamed since it now pulls udp endpoint, in tandem to tcp. Should have similar output still needs to be tested & verified but methodology should be sound.
@mwilco03
Copy link
Contributor Author

Finally got back to this updated PR

@mwilco03
Copy link
Contributor Author

Going through old requests & wondering if you've had a chance to test this.

@davehull davehull merged commit e4f608e into davehull:master Nov 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants