Disposable email addresses (DEA) and concerns


This post is about disposable email addresses and where to get them and concerns for organisations or whitehats defending their network/country. Disposable email addresses are something for which you don’t need an account. Understand you can only RECEIVE emails and cannot SEND. The service was first paid only but now you can get it for free from multiple locations. The email lasts from 10 minutes to a week.

Disposable email addresses are something that you can register on a site that you think you won’t be visiting often and may send you spam later or you want to hide your identify when registering. Depending on the person who is using the service, it can used in positive and/or negative ways.

 Let’s start looking at them :

  1. AirMailScreen Shot 2016-09-12 at 9.54.05 PM.png
  2. Guerrilla Mail guerilla email.png
  3. ThrowAwayMailScreen Shot 2016-09-12 at 9.50.28 PM.png
  4. MailinatorScreen Shot 2016-09-12 at 9.53.32 PM.png
  5. Temp MailScreen Shot 2016-09-12 at 9.55.35 PM.png
  6. myTemp.emailScreen Shot 2016-09-12 at 9.57.25 PM.png
  7. Email on deckScreen Shot 2016-09-12 at 9.56.36 PM.png

There are others but the mentioned ones are top hits.

As having background in Social engineering and identifying tactics that cyber criminals  and/or insiders may use with regards to this disposable email, I can think of a 2 concerns.

  1. Partners in crime can use these for their communications rather than to worry about getting tracked and/or reveal the identity of the recipient.
  2. Another concern is insiders and  how one can use the disposable emails to transfer data and/or for data exfiltration. Organisations should be on lookout of these channels or medium and can configure mail gateway and/or DLP to make sure no sensitive/confidential information is going out.

If you know other concerns please comment.

Lets hope the service is being used for good purpose.

Battling Insider Threats – Browser in the box


One of the biggest threats for any organisation is Insider Threat. An employee visiting malicious sites, drive-by downloads, uploading documents etc. , in short any web activity that can impact the organisation. Many of the organisations have chose to deploy DLP, Intrusion Detection and Prevention systems, proxies, user behaviour analytics and other expensive tools to fight against the threats but are still failing to prevent or reduce risk occurring via this threat.

From my previous post, I mentioned attackers are exploiting human characteristics – FEAR and CURIOSITY.  Employees clicking on picture of a cat and wallah the system has been infected. No matter how much security awareness we provide , there will always be risk of having internet connection on corporate network.

Wouldn’t it be good to have some functionality or an application that can prevent a malware, to infect the operating system, coming via a URL or when a user is visiting a site? It can be obfuscated scripts, executables, rootkits etc. We do have a VM that we use for sand-boxing, but let’s agree that not all users in your organisation knows how to use it and/or even understand the impact of infected system in a corporate network.  During this search I came across a tool called “Browser in the Box” created by Sirrix AG Technologies.

Browser in the box provides a virtual environment with a web browser is encapsulated in it. Therefore, when an employee is surfing internet through this browser, any suspicious/malicious files from internet will stay in this virtual environment and will not traverse through actual host operating system. All the browsing activities are isolated completely from the host operating system. “Browser in the box” also prevents any uploading of the files into the internet, which suggests the confidentiality and integrity of the organisations data is not compromised. Please note, the application is not a virtual machine (one can think that there are malware that identifies vm and will not execute), its a virtual environment similar to windows XP mode. I will try and test whether this is actually true.

The system was initially developed by Sirrix on behalf of German Federal office for Information Security. Currently the solution is open for public.

Visit Sirrix website here and  Download link here.

Incident Response and Forensics – The two towers


Been meaning write something about my experience with Incident response and forensics and how knowledge of both field helped me.

Most of the organisations have Incident Response and Forensics as 2 different department and no overlap of services or transparency is seen between them. Personally, I believe it is not a good approach as Incident Response and Forensics team should work hand in hand to get the most out of the investigation. There are organisation who thinks Forensics are only to collect evidence. Yes indeed I was shocked!!!

Both stream requires well organised plans and procedures and individuals with strong technical expertise. Both streams have standards – NIST 800-61 of IR and 800-86 for Forensics. One must understand these standards.

When an organisation is performing IR, imagine the responder has no forensic knowledge.

  1. The reason we perform incident response is to understand what happened, how it happened, how we can stop it to further affect/infect our systems and how we can stop in future – Preparation, Identification, Containment, Remediation, Recovery and Lesson Learned. As mentioned in my earlier blog most organisation perform Preparation, Identification and Recovery. Is this due to improper process ? Is it because the responder doesn’t know the IR Phases? Is it due to time constraints or can’t be bothered?
  2. Now to understand what happened (e.g., malware infection), one must understand malware, and how it interacts with the system and what artefacts are involved. This is where Forensic knowledge will come in place. Handling a malware incident, one must know malware analysis and in certain scenarios reverse engineering. Let’s say you are not sure its a malware infection, however system are showing signs of unusual behaviour. As an incident responder one may think to just run certain tool to identify or understand behaviour – nothing wrong however, this may alter certain files by treating them malicious – like what a endpoint protection does by performing quarantine.
  3. A forensic investigator will first manually investigate the system and learn why a system is behaving in such manner – look through process (parent/child), file paths, services etc to determine what is not part of the system. I am not saying tool will not be used but this is about a process. Forensic investigator may choose to run Redline for example.
  4. The approach taken by 2 individuals are always different but the end goal should remain the same – reduce impact and determine indicators of compromise and TTPs (Tools, techniques and procedure) that can be used in earlier detection in future. When this is not performed our adversaries will always have tactical advantage over us.

An ideal approach I prefer is that an Incident Responder must have certain knowledge of forensics that can assist him/her in making sure our investigation is not only to clean the system (an anti-virus/anti-malware can do that), but identify the artefacts and preserve them for further investigation if time permits. Forensics should be performed in parallel to incident response.

IR is more process driven and forensics allows to deep dive into systems to identify bad actors. Forensics is time consuming and most of the time organisations prefer not to include them as they want business or system to return to its normal state. IR and Forensics should also communicate to other security network team and share the outcome of investigations.

I will be writing more about IR and Forensics methodologies (technical and non-technical) and answer most common question – how do i go by starting in IR or Forensics (DFIR). This will supplement the Threat Hunting article that I am working on.

Mandatory Reads

Happy Investigation!!!!!!


Penetration Testing and Rules of engagement


This post is about globally accepted LEGAL technique to exploit a system or network to validate their deployment of security controls. Yes I am talking about PENETRATION TESTING.

With this post I would like to share an ideal approach during penetration testing and importance in following the rules of engagement. Of what I have experienced following is the normal scenario:

Customer signs engagement and scope letter. Most of the time this engagement/scope letter  contains very vague and/or no proper description of How’s and who’s of Penetration testing methodology. Sometimes they will just mention Person A and Person B will be performing a Penetration Testing on Customer A Network and rest is legal and contractual stuff. Some will also add type of penetration testing (no they won’t mention Black/Grey/White Box testing). They will say Web application Pen testing, Network Pen Testing. Although, they are in a way correct but still we need to mention it.

Suggestions : Organisation must let customers know what will be included in a Pen test. There is no room for assumptions. For any pen test one must provide the techniques and methods and especially what will be tested. One does not need to provide the tools name but techniques are important.

Defining this in the scope/engagement letter can assist pen tester to make sure he/she is not stepping over the boundaries – which are normally considered RULES OF ENGAGEMENT. Management and Pen Testers must understand this rules for a successful pen testing.

Management and organisation should also understand Pen testing should not be only performed because of compliance – unfortunately this is the driver in most cases. As Pen testing simulates an attack on any organisation it should be performed on a regular basis and for extended period of time. One should also perform external pen test to test their security controls and simulate real world attacks. Adversaries and/or cyber criminals have no time limit to gain access to your network, but Pen testers do and management must take this into consideration. Having a pen test for a week and next one next year will have zero value.

Another suggestions to pen testers is to be ready with their own way to exploit systems. Most of the time due to time constraints we use available tools and exploits to perform pen test which may give you some good results but we need to think or try to go beyond that and writing your own exploits has been proved to be a good method. If a vulnerability is identified it is a good idea to exploit it with multiple techniques if known.

Pen testers should also spend a good chunk of time in information gathering (active or passive). The more information you gather the better you will be able to exploit your target. I have always used 2 pen testers whereby PT A will continue performing information gathering – provide the results to PT B, PT B will give some information back to PT A and PT A will continue to gather information. Consider this as a to and fro situation but PT A and PT B will exchange information continuously.

PT B should concentrate on fingerprinting, enumeration, attempt to gain access to the systems, vulnerability assessment. There are many organisations and pen testers preferring running Vulnerability scanners upfront when performing pen test which I personally believe is wrong step. As we are trying to simulate attacks on organisation, we must think from the attackers point of view. Normally they don’t run vulnerability scanners straight up – the traffic generated by them is heavy and easily detectable by various security controls. These scanners can be used for verification and/or add-on to pen testing methodology to make sure we didn’t miss anything.

Lastly, providing a report of pen test to customer. Report should provide all the findings, techniques and methods use to collect information and how information was used to gain access to the system, what vulnerability, types of exploit used and outcome of the exploitation – privilege access, data exfiltration, install/modify applications and/or files etc. Screenshots are considered ideal. Having these information will assist pen testers to draft recommendations that are actionable rather just  telling to update and patch.

Please visit following site for more information :


Ransomware extensions and filenames

As we all know Ransomware is currently one of the biggest threat to any organisation and therefore we must understand how a ransomware works and its digital footprint. Every application when executed leaves a footprint on the system and sometimes we call them dropper. A footprint for Microsoft word is filename.doc for example.

Similarly, when ranswomware is executed it will leave certain files and have following extensions and files :

*want your files back.*
how to decrypt aes files.lnk

Recently updated WannaCry and SOREBRECT ransomware extensions.

Courtesy Bleeping Computer and kinomakino.

The extensions can be used during Hunting phase or timeline analysis where analysts are looking for suspicious/malicious files on a host. Further information can be found here.

Happy Hunting!!!

Threat Hunting and Pyramid of Pain

The buzz word first came in 2014 and individuals who were actually performing activities such as hunting for adversaries within network interested in Threat Hunting agreed with it on all aspects. During Threat Hunting and/or intelligence gathering or incident response we are mostly concentrating on identifying indicators of compromise and normally follow these steps:

  1. Collect Indicators of Compromise – Basic/Advanced Threat intelligence platform – Yes I have collected Indicators of compromise from all over world than what ?
  2. Compare the IOCs with internal logs – SIEM – to understand the extent of infection – lateral movements as we say. One can also use specific tools for this – carbon black, palantir, dark trace etc.
  3. Detect and mitigation – most of the time by running anti-virus and/or restoring the system from backup or re-installing a fresh copy.

Most organisation perform mentioned points believing that this is their Incident Response plan and threat hunting procedure, but they actually only performed 2-3 stages – Identification, Recovery and Follow-up/lesson learned.

This is somewhat I call as Reactive approach, as the name suggests incident response – responding to an incident. However, there is another approach -pro-active approach – where team of experience Incident Responders will look through the network and identify anomalies and/or unwanted entities within a network. Threat Hunting was it called. The days of external organisations notifying you of an infection or data exfil or their own data showing up on pastebin are increasing and organisation must have Threat Hunting and IR capabilities well invested and implemented. Proper Process and procedure are important as well in understanding how to perform these duties. Consider following:

Following is the pyramid of pain

pyramid of pain


The diagram has a scale that shows relationship between the indicators of compromise a Threat Hunter or an incident responder can find and how much pain it will cause to use them to detect the adversary.

Threat hunting and Incident response goes beyond just deploying a product within the network and responding based on what it alerts. It goes beyond normal rule and/or signature based mechanisms to detect threats that one cannot detect with just plug-n-play devices. Both requires human factor to perform these actions. Deep diving into the networks and looking for adversaries (active defense and/or pro-active investigations) is a must have within the organisation and Incident Responders and IT Team must work hand in hand. And don’t forget to involve Forensics. Yes, we need forensics to gather evidence properly.

Threat Hunting phases :

  1. Create and/or define Hypotheses
  2. Investigate via tools and techniques
  3. Identify new patterns and TTP (Tools, techniques and procedure)
  4. Inform and update analytics platform and/or database
  5. Start 1

It’s my pleasure to announce that I recently got honoured to co-author a book with Don Murdoch. The book will be used as a field guide and/or playbook for Threat hunters during Threat Hunting.

Happy Hunting !!!!

Phishing SMS – A failed attempt

Just about an hour ago I received an text from one of my mentors. Excited, I read but I know him very well and knew it wasn’t him.

The phishing text :

It’s possible to do 10 k in 10 day.


I texted him directly with a new message rather than responding the message and verified that it was indeed phishing.

1. The message had no phone number associated.

2. Looking at the details of the name – the sender – they were empty. Normally, if a contact on you address book sends a message you can see their serials stored on your phone.

Possible motives :

1. By sending an text an attacker can verify that number exist or not via a delivery notification.

2. If someone responds – response in this case is not feasible as it has no return number – than attacker can continue with social engineering attack.

3. Likely I was targeted and attacker was trying to deceive me to click on the link and get the some results back to him/her.

Will be analysing the link to understand if it has any embedded and/or crafted scripts that are targeting mobile phones. This may be attempt to exploit Quadroot set of vulnerabilities on Android.