I was a professional penetration tester focusing on network security for a couple of years and Impacket was an Essential piece of tooling that I used constantly. The "examples" folder in this repo contains enough utility that you could successfully pwn a bunch of windows environments with no other tools.
At the time I was working for a consulting company. After a few years of grinding through assessments over and over I wanted to take a stab at actually helping improve the security of a company rather than simply telling them what they were doing wrong. I still get to do _SOME_ offensive work, but now I also get to follow up and help design/implement a good solution to the issue.
Not OP, but if you work for a big company the goal of penetration testing runs counter to the goals of the other departments. The more bugs you find, the more that means someone else looks “bad”, so it can become hard to move up in seniority if you don’t have a good leader above you to properly align the interests of both parties so it’s collaborative rather than antagonistic
Not an issue I experienced at my old company (a consultancy) but this is a huge factor on security teams that I think is often overlooked.
"Old" style security teams often have a "you (wrote bad code|bad config|picked bad libraries), now go fix it" attitude that really doesn't do them any favors. A big part of being on any security team is building rapport with other teams and making sure that the security team is seen as a part of the company and not "the assholes who make us do extra work."
Anecdotally it seems like the more the other teams have a strong relationship with security - the more likely they are to consult the team early on and get some input on design decisions and recommendations that reduce the overhead of fixing vulns later on.
From a day to day penetration tester's perspective, I only pull out Scapy when there's a need to craft a specific packet, usually to fuzz a network interface and see if something breaks. Impacket, while something that can absolutely can be built on top of, is far more commonly used for the existing examples it comes with, as well as some more advanced tooling that the community has already built off Impacket as a foundation.
The readme says All rights reserved.But the license file is the apache license with the names swapped. That seems like a contradiction. I almost closed the tab immediately when I read the readme.
IANAL and don't care either way, but it's based on 1.1 of the Apache license, and it also has 'All rights reserved' text in it [1] so I'm not sure I understand the problem.
I believe the copyright notice in the Apache license is for the license itself, not for the software it covers. If the software is all rights reserved, then it is not open source. By definition Open Source Software grants some rights to the users. Though I'm sure it was just some boiler plate they stuck in the readme.
In any case I really just wanted to point out that it is open source, even though at a glance it looks like it might not be.
I was a professional penetration tester focusing on network security for a couple of years and Impacket was an Essential piece of tooling that I used constantly. The "examples" folder in this repo contains enough utility that you could successfully pwn a bunch of windows environments with no other tools.
It’s tangential, but as someone moving toward the offensive & network side of things, would you mind sharing why you changed fields?
At the time I was working for a consulting company. After a few years of grinding through assessments over and over I wanted to take a stab at actually helping improve the security of a company rather than simply telling them what they were doing wrong. I still get to do _SOME_ offensive work, but now I also get to follow up and help design/implement a good solution to the issue.
Not OP, but if you work for a big company the goal of penetration testing runs counter to the goals of the other departments. The more bugs you find, the more that means someone else looks “bad”, so it can become hard to move up in seniority if you don’t have a good leader above you to properly align the interests of both parties so it’s collaborative rather than antagonistic
Not an issue I experienced at my old company (a consultancy) but this is a huge factor on security teams that I think is often overlooked.
"Old" style security teams often have a "you (wrote bad code|bad config|picked bad libraries), now go fix it" attitude that really doesn't do them any favors. A big part of being on any security team is building rapport with other teams and making sure that the security team is seen as a part of the company and not "the assholes who make us do extra work."
Anecdotally it seems like the more the other teams have a strong relationship with security - the more likely they are to consult the team early on and get some input on design decisions and recommendations that reduce the overhead of fixing vulns later on.
How does this compare to scapy? From my quick look at the examples, it seems similar. Are there places where I would use one versus the other?
Would like to know this also. I don't write much python but I frequently look at scapy with jealousy. It looks like a wonderful library.
From a day to day penetration tester's perspective, I only pull out Scapy when there's a need to craft a specific packet, usually to fuzz a network interface and see if something breaks. Impacket, while something that can absolutely can be built on top of, is far more commonly used for the existing examples it comes with, as well as some more advanced tooling that the community has already built off Impacket as a foundation.
The readme says All rights reserved.But the license file is the apache license with the names swapped. That seems like a contradiction. I almost closed the tab immediately when I read the readme.
IANAL and don't care either way, but it's based on 1.1 of the Apache license, and it also has 'All rights reserved' text in it [1] so I'm not sure I understand the problem.
[1] https://www.apache.org/licenses/LICENSE-1.1
I believe the copyright notice in the Apache license is for the license itself, not for the software it covers. If the software is all rights reserved, then it is not open source. By definition Open Source Software grants some rights to the users. Though I'm sure it was just some boiler plate they stuck in the readme.
In any case I really just wanted to point out that it is open source, even though at a glance it looks like it might not be.