In the wake of the recent buzz and trend in using DDE for executing arbitrary command lines and eventually compromising a system, I asked myself « what are the coolest command lines an attacker could use besides the famous powershell oneliner » ?
Glad to introduce WSC2, C2 over WebSocket. But first, a bit of context…
I’ve recently been looking into a fancy covert channel, targeting Windows familly operating systems, for either:
- deliver various malicious payloads (shellcode, binaries, scripts, whatever…)
- use it as a C2 communication channel
This is what this blog post is all about. Let’s dig into it.
This article proposes a basic technique (I mean very basic, but still efficient) for the meterpreter stage antivirus and IDS/IPS evasion, in an up-to-standards secure corporate environment, which poses many challenges, using some Powershell Fu.
NB: This article is not about how Fail2Ban works or how to install it.
If you’re running an Internet facing server, you probably know its exposed services are constantly being probed and attacks are being attempted against it. Fortunately, an extremely useful, nice and nifty tool is here to help: Fail2Ban.
Fail2Ban scans service’s log files for patterns defined as regular expressions and, if an offending pattern is found a certain number of times within a given timeframe, the corresponding source IP is banned (ie: blocked) for a configurable time, using local firewall rules such as iptables.
I’m very touchy when it comes to my server security so I’m using Fail2Ban to perform permanent bans of involved source IPs and I’m going to show you how. The problem however is that those bans do not persist across a Fail2ban server restart or a server reboot.
In this article I will show you how to add two simple lines in Fail2Ban configuration file in order to add persistency across restart.
Corporate voice network, also known as Voice over IP (VoIP) network, turns out to be an interesting target for those looking for confidential and private information. In my experience though, this target is often underestimated both by intruders or ethical hackers during their engagement, but also by company security officers.
In this article, I will go through a very practical case, using some well known tools to demonstrate the potential lack of security on VoIP networks. I’ll explain, step by step, how I’ve been using these tools, sometimes not exactly how they’re supposed to be used but that’s just how I managed to make it work altogether.
This example focuses on a specific VoIP technical environment and setup, and serves the only purpose of raising awareness on how easy it is to hack VoIP communications.