These are not 2000 approaches, these are approaches used today (signature based detection).
The difference is that in 2000s the signatures were written by hand and described static file info, today they're often autogenerated and describe the system behavior, either by looking at one executable, or a whole network of computers. But it is still signature based detection. Since they describe the program behavior, not the program structure, then if the program itself stayed the same (the sequence of system api calls stayed the same), no runtime packing/obfuscation makes a difference to a signature. Unless obfuscation changes the behavior.
Also security is not binary, it's layered. Sometimes we can address an attack vector by using multiple levels. And sometimes it's simply worth checking for low hanging fruits if only to make the attack more expensive. The "cat and mouse" game is always about the cost of attack and cost of defense, if we raise one then we win in this area, unless the other party finds a way of lowering the cost of their side. Or unless they pay an unexpected amount of cost, for example in state sponsored malware.
By the way, some security solutions also have actual parsers for example for PowerShell, so they can actually detect string concatenation that constructs the URL.
>Also security is not binary, it's layered. Sometimes we can address an attack vector by using multiple levels. And sometimes it's simply worth checking for low hanging fruits if only to make the attack more expensive.
Defense in depth and multiple redundant layers is a legitimate technique.
But it should usually be 2 virtually unbreachable layers, like 99.999% effective, because there may be a memory leak somewhere and it will be exploited once per year or so. Because 1 layer is just shy of 100%, 2 layers is already overkill, we would do 1.1 layers if possible (but of course it's not)
Maybe if it's a multibillion dollar product you'd add a third or more impenetrable layers.
And once you have those two redundant security layers, then you add deterrents and monitors, if you want.
But relying on security measures that will maybe catch 20% of attacks or 40% of attacks as a main mechanism will lead to what some have described as swiss-cheese models. https://en.wikipedia.org/wiki/Swiss_cheese_model
So yes, sometimes you can add a cheap measure that might make things more difficult to an attacker, on top of your main line of defense, then do it. But keyword cheap, if it takes 2 minutes like using a custom port, yeah for sure do that, but if you have to write an article and invent a new theory of hooks, then it's not it.
Antivirus techniques are not used by serious development professionals that I know of, I've seen it used in IT contexts were there's non technical users that might download stuff, but even then it's not really a central technique, just something that security firms sell to non-technical execs. And it's in the context of sys admins trying to control the security environment of hundreds of employees whose actions they cannot control. In the context of developers who have to ensure the security of systems they have code for, you do not need these faith based techniques, you are importing the code, you have access to it, and you have the time resources to inspect it. These antivirus technologies are used either by personal end users that don't have the ability to verify the software or audit its source, or for IT departments that cannot even inspect the contents and packets of the software their employees are using for security reasons.