this is the archive page

Understanding the “attacker mindset” in security

Justin Hall is Director – Security Services for CBTS. In Part 2 of this 3-part series, Justin discusses how to better understand the “attacker mindset.”  In Part 1, Justin discussed the process of developing a background in enterprise IT.

Practitioners in the security industry are charged with protecting organizations and their assets – their computing environment, data, employees, and customers. Understanding the threats against which you are defending is critical to this protection effort. What are they after? How do they achieve their goals? What can you expect when you face them? What countermeasures and strategies are effective to employ?

The best defenders of a network are used to thinking like an attacker. So how does one develop this mindset?

Plenty of folks in our industry started as so-called “black hats” – those who attack, disrupt, or compromise computer systems for financial gain, to back a political or social cause, or to cause havoc. While this is certainly an effective approach, it’s usually not legal.

I’ve found that listening to industry veterans and seasoned practitioners, as well as former black hats, is a much better option. In that vein, try attending security conferences and events where you can listen to these folks speak and provide formal training. There’s also a good opportunity to learn about the ever-changing threat landscape, new attack techniques, and new tools.

Hundreds of security conferences take place all across the United States and other countries – look at a list and find one in your area. A way to meet local practitioners, especially ones that might be interested in providing you guidance and mentoring, is to find a Security BSides conference, which are assembled and executed by volunteers. And if you can’t make it to a security conference, most nowadays are recorded and posted online.

We can also learn to stop attackers by looking at the best practices agreed upon by experts from the security community, regulatory bodies, and technology vendors. Dozens of these standards have been used by practitioners for years and make excellent reading material if you’re looking to get ready for the industry:

  • The NIST Cyber Security Framework. As mentioned in a previous post, the CSF is a guide to developing a formal security program. Their publication 800-53r4 is also the “gold standard,” as it were, for security controls – the fundamental people, processes, and technologies you need to have in place to protect your organization.
  • The Center for Internet Security’s Top 20 Critical Security Controls. If NIST 800-53r4 is too wordy, the Top 20 is a consolidated and far more approachable standard. It’s also much more frequently updated and is shaped by feedback from the security community at large (and not just NIST).
  • The MITRE ATT&CK Framework. MITRE’s goal with this resource is to document common attacker actions and tactics, along with methods of detection on a variety of popular computing platforms.
  • The Open Web Application Security Project. A group that oversees many community-based application security standards-development projects. One of their most popular is the Top 10 Common Web Application Security Risks, an often-referenced list of the issues in web applications that developers need to consider when writing secure code.

Lots to read and watch! Come on back soon for part 3.

Read more about Security offerings from CBTS.  And read this case study to learn how CBTS helped an enterprise client form  a security strategy to advance their maturity, increase their risk management capabilities, reduce the attack surface for each business line, and improve their overall corporate security posture.

Security starts with enterprise IT knowledge

Justin Hall is Director – Security Services for CBTS. In Part 1 of this 3-part series, Justin discusses how  a core knowledge of enterprise IT is critical in order to effectively protect networks.

For several years I’ve been going back to my alma mater, the University of Cincinnati, to speak to groups of undergrad and graduate students about the information security industry. My goal is to demystify security and inspire them to consider a career in one of a dozen security disciplines.

Invariably during these talks I am asked a very common question: “How do I get a job in the security industry?” In response, I’ll share my own 20-year story, starting in PC repair and sales, moving to tech support, systems administration, and running an IT department, before jumping into a security career – first as an engineer, architect, and consultant, and then running a security team.

I’ll also share three essentials to successfully landing a security job, which I’m going to cover in this blog series. There’s no single path to the industry, to be sure. In order to develop a foundation that can land an entry-level job and provide an arc to a long-term career, it’s worth looking into these fundamentals.

Core knowledge of enterprise IT

Today, we’ll cover number one: a core knowledge of enterprise IT. This is perhaps a bit obvious – certainly someone needs to be technical and understand how a computer works to survive in security, right?

The depth required goes beyond CPU, RAM, and a hard disk. To effectively protect any company network, one needs to recognize the critical components – servers, workstations, network devices, applications, and security defenses. How do they interact? In what network segments do they typically sit? What products or solutions are commonly used in each of these categories? At a high level, what are the essential configuration best practices for each?

For example: Imagine a network used by a physician’s office. Think about the variety of computing devices in use there: Beyond traditional workstations, multi-function printers, and laptops, you might see connected medical devices, credit-card processing machines, and surveillance cameras. Servers would run authentication systems, file management, accounting and finance, ERP, messaging, and electronic medical record apps. Some may be running from local servers, and some may sit in the cloud. Network devices will include switches, routers, wireless access points, and firewalls.

Now imagine a software company. What types of assets would be the same as the physician’s office? What would be different? How would their IT needs be similar/different? What about a retailer or bank? What happens when you add multiple sites/locations? Imagine scaling up to the size of a multinational conglomerate. Think about the pieces and parts that need to change, duplicate, or scale.

Enterprise IT involves depth and breadth

This scope of understanding is what I mean by “knowing enterprise IT.” There’s a level of depth in addition to the breadth, though. Defending an environment with Windows workstations and servers, for example, means understanding the fundamentals of what makes Windows tick – the filesystem, registry, Group Policy, configuration, and the like.

How does one acquire this knowledge?

  • Build it yourself! A home lab is a great place to get hands-on experience with enterprise IT. You could grab an old PC and install free versions of VMware’s vSphere or Microsoft’s HyperV, and deploy eval copies of Windows Server and workstation OS’s, Linux, or a variety of prebuilt VM appliances. Tons of great tutorials exist – I like this one from Paul Braren on building a VMware ESX lab.
  • You could also use free or inexpensive tiers of service offered by IaaS providers like AWS, Azure, or DigitalOcean to build VMs quickly, install and configure applications, and build virtual networks.
  • If you’re serious about improving your enterprise IT knowledge, and want to invest your time and money, find a local university or online school that offers IT courses or degree programs.
  • Finally, take the plunge and find a systems or network administration job. Without a formal education in security, it’s rare to be able to jump right in without doing the so-called “grunt work” needed to acquire real-world experience. A few years building, breaking, and fixing some enterprise networks is sure to cement your ability to operate with comfort in the industry.

Thanks for reading! Stay tuned for part two.

Read more about Security offerings from CBTS.  And read this case study to learn how CBTS helped an enterprise client form  a security strategy to advance their maturity, increase their risk management capabilities, reduce the attack surface for each business line, and improve their overall corporate security posture.

The key to strong security programs

Congrats are in order for the folks over at the National Institute of Standards and Technology! A few weeks ago, a new version of their Framework for Improving Critical Infrastructure Cybersecurity (which we call the Cyber Security Framework, or CSF) was released.

The CSF, as with most other NIST Special Publications around security, receives regular updates to keep pace with the changes in the threat landscape, the security product market, and new regulatory compliance requirements in a variety of industries. I talk often to customers who are facing the challenge of protecting their data and systems, but find it hard to adjust as those factors change year to year, and they feel there isn’t sufficient organizational focus on practicing good security.

What is a security program?

You may have heard the term “security program” before – you’d certainly hear me mention it in these conversations with customers. Maybe it’s why you clicked on this article. What is a security program? What’s so magical about it that I need it in my organization?

When I describe a security program, I’m talking about the collection of individuals, teams, and their efforts to protect their organization from a variety of threats. I’m talking about the policies, standards, and guidelines they enact to formally document roles, responsibilities, actions, and behaviors of employees, users, third-parties, and anyone else that might have a role in this protection effort. I’m talking about the management efforts to advance the maturity of the organization’s protection effort, and to mitigate risks to the business.

It’s a team, led by a leader or group of leaders, much like many other teams in your organization. Yours will look similar to other teams … and also very different. There’s no one right way to build a security program (but certainly plenty of wrong ways). What helps is a guide – and the NIST CSF is a fantastic, free guide built just for that purpose.

It defines five Functions for which the security program is responsible: Identify, Protect, Detect, Respond, and Recover. It details how to build a security program, and grow it over time, to achieve this goal. And it provides a way to measure your capability and the success of the program and how to tell if it is meeting its goals.

JD Rogers, the CISO of Great American Insurance, did a fantastic talk last year on how he and his team used the CSF to develop a strategy to grow and measure the success of their security program.

CBTS will help you with security

If your organization doesn’t have a security program today, and you might be a person considered responsible for security in that organization, the NIST CSF is absolutely worth a read. It may seem daunting, but Rome (and its security program) wasn’t built in a day. You may be able to look back a few years later, after beginning these efforts, and see real change that’s been affected because of this practice. You might even sleep better at night!

If you’re interested in seeing how you stack up to the NIST CSF, or if you’d like help with those critical first steps of building your security program, come and talk to us. We’ve helped many businesses in many industries with this process and we’d love to help you.

Read more about Security offerings from CBTS

Businesses brace for EU privacy reform

The impending enforcement of the European Union’s General Data Protection Regulation (GDPR) will lead to challenges for nearly any business that operates on the internet. The sweeping privacy reforms demand a new standard in handling personal information.

There’s a good chance it leads to improved protection of personal information for everybody – simply because the technical requirements to only implement the regulations for EU citizens may outweigh just developing the capability for all of a company’s customers or users. 

What should I know about the GDPR?

If you’re unfamiliar with the GDPR, I suggest spending a few minutes watching this excellent primer from Habitu8. In short: 

  • The GDPR redefines personal information broadly, including any data that can uniquely identify an individual or the computer they’re using 
  • If you collect, store, or “process” this kind of information about EU citizens, you’ll be required to outline the ways you do so, and obtain the explicit consent for these actions from your EU users. 
  • If you pass this information to another organization – say, someone who processes it for you – you must obtain consent from EU users, as well as develop an agreement with the other organization outlining exactly how the data must be stored, used, and destroyed. 
  • EU users have the right to request a copy of the personal data you have on file for them, and it must be provided in a format that’s portable. EU users can also request that you stop using their data and destroy your copy. 
  • Most organizations operating in the EU will need to appoint a Data Protection Officer (DPO). This individual will oversee the handling of personal data in the organization, ensure compliance with the GDPR, and field any complaints or issues that arise from EU users. 
  • If you experience a data breach, you have 72 hours from the time of discovery to report it to the supervisory authority. 

The GDPR takes a firm stance on privacy by default – you must obtain consent for any collection, storage, or use of a user’s personal data – instead of assuming you can use it in any manner you like without asking. 

How do I know if the GDPR affects my business?

Perhaps you’re a small business that doesn’t operate in the EU. Why bother with the GDPR at all? Well: 

Do you operate on the internet? Allow users to sign up for an account? Unless you’re explicitly restricting access from certain geographic locations, if an EU user creates an account with you, you’re required to abide by these regulations as it pertains to their personal information – including name, address, username, email address, and yes, even the IP address you log for their session with your servers, or the cookie you issue to their web browser. 

If you don’t do business in the EU now, but you plan on expanding across the Atlantic in the future, this will end up impacting you, and you may be asked to build the processes required before you start work in that locale. It might be better to start considering implementation sooner rather than later. 

Finally, you might start seeing pressure from third parties to conform to these kinds of regulations even if the third party isn’t in the EU. Companies and consumers are all looking for ways to better protect their personal information and you might be asked to start providing similar protection or risk losing some business. 

Where can I learn more about the GDPR?

The European Data Protection Supervisor’s website has some great practical resources for starting down the path of implementation. Their legal notice on handling of personal data could be useful to duplicate for your own website, for example. They also publish the details of their own DPO’s roles and responsibilities which may act as a guide for the creation of the role inside your organization. 

If your hands are a little more damp now than when you started reading this post, that’s understandable! Let us know if we can be of assistance in navigating your GDPR challenges.

CBTS awarded Cisco Master of Security Certification

OnX, a CBTS company, is pleased to announce that it has been awarded the prestigious Cisco Master of Security Certification.

The certification includes the following Cisco practice areas:

  • Next Generation Firewall (NGFW)
  • Next Generation IPS (NGIPS)
  • Policy and Access
  • Web and Email Security
  • Advanced Threat

To achieve the Cisco Master of Security Certification, OnX, a CBTS company, had to show their exact understanding of individual Cisco security practices, as well as demonstrate a deep understanding of how those practices should function as a cohesive set of solutions. The OnX team also had to showcase current examples of successful projects in which we have integrated multiple security solutions.

No other Cisco specialization or certification demands such extensive proof of the partner’s design and implementation capabilities.

“We value our strong relationship with Cisco, and this recognition reflects our expertise in deploying a wide range of Cisco security solutions to meet our customers’ evolving needs in this complex, mission-critical space,” said Paul Khawaja, Senior Vice President OnX Canada. “OnX, a CBTS company, is proud to deliver world-class Cisco solutions in the areas of secure access and mobility, edge, and branch security, along with data center and cloud security.”


Related News:

Cisco Certifies CBTS as Unified Contact Center Enterprise Partner

CBTS recognized at Cisco Partner Summit

OnX has joined the CBTS Family

The Ten KRACK Commandments

You may have heard some buzz about a vulnerability in the Wi-Fi protocol WPA2. Of course, it’s got a cute, marketable name (Key Reinstallation AttaCK, or KRACK). It’s fairly serious, despite the clever title – the researchers that discovered and published the details of the vulnerability say in their paper:

“An attacker within range of a victim can exploit these weaknesses using key reinstallation attacks (KRACKs). Concretely, attackers can use this novel attack technique to read information that was previously assumed to be safely encrypted.”

The security community is alarmed, and rightfully so: every wireless access point and client device, including laptops, phones, tablets, and so-called smart devices, is vulnerable to this attack, if they support WPA2. The details of the attack vector are heavily technical and require an understanding of how wireless cryptography works. Briefly, an attacker uses a previously unknown weakness in the WPA2 protocol to force a Wi-Fi client to reinstall a key used to encrypt its wireless network traffic. In the process of doing this, some of the cryptographic data used to calculate the key are reset to a value that’s known by the attacker. The attacker can then decrypt the client’s wireless session data going forward, exposing the contents of the session to the attacker.

While we haven’t seen attacks demonstrated against every client or network device platform yet, we feel the attack is fundamentally sound and is likely to be exploited widely in the years to come.

The CBTS security team has been in the game for years. We’ve got recommendations to ensure your wireless communications are safe going forward – a step-by-step booklet, as it were.

  1. Patch your workstations. Ensure Windows, Mac, Linux, and ChromeOS machines are updated as soon as the operating system vendors issue security updates, and keep them up to date regularly.
  2. Patch your smartphones and tablets – any device with iOS, Android, or Windows / Blackberry. Watch out for Android, especially, as the WPA2 implementation in some Android versions (specifically Android 6.0) have been shown to allow not just traffic decryption, but actual crafting of traffic from the attacker.
  3. Patch your access points. This one’s a little tougher; you will need to log into your access points / routers regularly to see if there are updates from the vendor and apply them, which will likely require you to reboot the device.
  4. Use caution connecting to suspicious wireless networks. If your client warns you when you connect to a network you’ve never used – or one that you typically do not have any problems connecting to – make sure you ask the owner of the network if everything’s kosher.
  5. Beware of devices that might not get updates for this vulnerability, such as so-called “smart devices” or “internet of things/IOT” devices. More and more devices are shipping with “connected” capabilities, and while these features are sometimes useful, some devices may eventually be abandoned by their manufacturer. That may mean that they aren’t updated when serious issues like this come up, and they become unsafe to use.
  6. Always VPN if you can. Even if your Wi-Fi session – between your device and the wireless access point – becomes compromised, if you send your traffic in a VPN session over top of the wireless connection, you will continue to protect some of your data. Use your company VPN if you’re logging on using a company asset.
  7. Don’t conduct sensitive business over public Wi-Fi. This means online banking, shopping, stock trading, etc. If you or your company do not own or operate the wireless network, stick to the unimportant stuff. Never let no one know how much dough you hold!
  8. Report any funny business. Getting strange errors using your company wireless network? Abnormally slow traffic? Warnings going to websites that are typically fine? Let your IT department know.
  9. For IT Teams: Look for rogue wireless access points. Set up a wireless IDS to identify access points that are using the same MAC address/BSSID as yours, possibly trying to spoof your APs.
  10. For IT Teams: Force clients to use only trusted WLANs. You can configure most client OS’s to only allow connections to WLANs and SSIDs you trust, in case your users are apt to hop onto whatever open public wireless networks are around them.

Follow these rules and… you’ll be much safer surfing on Wi-Fi. Good luck, and spread love, it’s the Brooklyn way!


Related Articles

Is SMS-based Multi Factor Authentication Secure?

The key to strong security programs

Security starts with enterprise IT knowledge

Equifax: A Case Study in Vulnerability Management

By now you’ve surely heard about the Equifax breach. (Of course I have, Justin, and don’t call me Shirley.)

I was actually quite surprised when the details of this breach were announced; specifically, that the initial point of entry into the Equifax network was not phishing. Instead, the attackers found and exploited a vulnerability in a public-facing web application framework. This allowed them to take control of the server on which this software was running, and use it as an entry point to the internal network and, eventually, to 143 million PII records.

This certainly calls to mind the old adage “the attackers only have to be lucky once – you have to be lucky every time.”

Equifax used Apache Struts – the web application framework in question – as a part of its online disputes application. US-CERT, a division of the federal government charged with helping Americans protect their data from security threats, notified Equifax about a serious vulnerability in Struts. The Equifax information security team passed this notification to the IT operations teams responsible for patching, as described in the Congressional testimony from Equifax CEO Richard Smith:

“On March 9, Equifax disseminated the U.S. CERT notification internally by e-mail requesting that applicable personnel responsible for an Apache Struts installation upgrade their software. Consistent with Equifax’s patching policy, the Equifax security department required that patching occur within a 48 hour time period. We now know that the vulnerable version of Apache Struts within Equifax was not identified or patched in response to the internal March 9 notification to information technology personnel.”

In addition, he notes:

“On March 15, Equifax’s information security department also ran scans that should have identified any systems that were vulnerable to the Apache Struts issue identified by U.S. CERT. Unfortunately, however, the scans did not identify the Apache Struts vulnerability.”

So here we have two breakdowns in the system: a failure to patch, and a failure to identify the application as vulnerable.

It’s a great reminder of why we consider the discipline of vulnerability management to involve much more than simple vulnerability scanning or patching. We see it as a checks-and-balances, in a way, to the IT operations teams that manage the computing environment. A complete practice would include:

  • An authorized software list, defining which applications are permitted for use in the organization’s computing environment
  • An effort to remove unauthorized software not present on this list from the environment on a regular basis
  • Notifications from vendors responsible for software on this list concerning new vulnerabilities
  • Self-guided research from internal security staff to find undiscovered or undocumented vulnerabilities
  • Ongoing vulnerability scans to find missing patches, configuration flaws, and design weaknesses  in all network nodes – servers, workstations, network devices, mobile devices, peripherals (such as cameras, networked printers, card readers, etc.)
  • Manual identification of serious vulnerabilities that may not be picked up by vulnerability scans, researchers, penetration testers, or a red team
  • Regular reports of vulnerabilities and remediation guidance to those responsible for system administration

This kind of formal practice is not trivial to build, but it can be done over time in a series of phases. And there’s still no guarantee you won’t miss something, as Equifax did. And even if your hygiene is perfect, the attackers could still try to phish you.

It’s not hopeless – our ultimate goal is to make attacking our organization so taxing and costly for the attacker that they give up and move on to another target; and if they are successful, identifying the breach and responding effectively. Equifax may not have been lucky this time; here’s hoping we can learn from their mistakes.


Related Articles:

BlackPOS or Something New – Tracking Point of Sale Malware

Three steps to enhancing security solutions

BlackPOS or Something New – Tracking Point of Sale Malware

Tracking Point of Sale malware and determining if the malware from the Home Depot Cyber Attack was different than what was used on Target

Using Intelligent Analysis and Adaptive Defense, all of us at CBTS Advanced Cyber Security want to learn from past attacks in order to better defend our customers from future attacks. Many times this involves finding new and novel ways to track malware, even point of sale malware. To this end, we became very interested when TrendMicro reported on a new variant of BlackPOS, which we will call MEMLOG.A for the sake of this post. In the blog post they are correlating this to the malware used to target Home Depot in the latest hack.

While it’s sensational to say that the same malware was used to target both Home Depot and Target, this is not looking like the case. There are already some entries coming out from other reverse engineers on this subject and this is not looking like BlackPOS at all.

Tracking Point of Sale Malware

In the blog post, TrendMicro alludes to the custom algorithm being used inside MEMLOG.A to validate and process CC information. “Based on our analysis, this PoS malware uses a new custom search routine to check the RAM for Track data. These custom search routines have replaced the regex search in newer PoS malware.” No other information is provided. On seeing this, we thought that perhaps these algorithms could be used as a way to track and identify Point of Sale malware. The MEMLOG.A sample that TrendMicro wrote up would be a good experiment to find out how similar these algorithms are across all Point of Sale malware.

Point of Sale malware often uses the same technique to find credit card numbers on the victim machine. The malware will scrape memory and then search for valid numbers. Regex is often used to find the numbers and then they are passed to a validation algorithm, in almost all cases this is Luhn’s algorithm. Normally, search for an implementation of Luhn’s algorithm on a Point of Sale machine will identify malware. In this case, when a custom algorithm is used, this is somewhat rare case, and interesting to anyone chasing POS malware. That said, by implementing a new and unique algorithm, the malware actually becomes easier to detect because nothing else uses that algorithm.

Detecting Point of Sale Malware

In the case of the MEMLOG.A malware that TrendMicro wrote up, the algorithms can be easily abstracted into yara rules to flag anytime the suspect algorithms exist inside a set of code. Even better, these rules will flag on other samples using the same algorithm. By implementing these rules, defenders can detect not just this version of the malware, but any version that uses this algorithm to find Track data in RAM. This will essentially force the attacker to rewrite their code or face detection.

rule Production_POS_CC_Algorithm
author = “Nick Hoffman – CBTS – ACS”
description = “Finds CC validation routines”
//00401224 |> /48 /DEC EAX
//00401225 |. |0FBE0C06 |MOVSX ECX,BYTE PTR DS:[ESI+EAX]
//00401229 |. |83E9 30 |SUB ECX,30
//0040122C |. |85FF |TEST EDI,EDI
//0040122E |. |75 04 |JNZ SHORT b579c886.00401234
//00401230 |. |8B4C8D D4 |MOV ECX,DWORD PTR SS:[EBP+ECX*4-2C]
//00401234 |> |03D9 |ADD EBX,ECX
//00401236 |. |33C9 |XOR ECX,ECX
//00401238 |. |85FF |TEST EDI,EDI
//0040123A |. |0F94C1 |SETE CL
//0040123D |. |8BF9 |MOV EDI,ECX
//0040123F |> |85C0 TEST EAX,EAX
//00401241 |.^\75 E1 \JNZ SHORT b579c886.00401224
$a = {480FBE0C0683E93085FF75 048B4C8DD403D933C985FF0F94C18BF985C075 E1 }
//004011DC |. 895D D4 MOV [LOCAL.11],EBX
//004011DF |. C745 D8 02000000 MOV [LOCAL.10],2
//004011E6 |. C745 DC 04000000 MOV [LOCAL.9],4
//004011ED |. C745 E0 06000000 MOV [LOCAL.8],6
//004011F4 |. C745 E4 08000000 MOV [LOCAL.7],8
//004011FB |. 8945 E8 MOV [LOCAL.6],EAX
//004011FE |. C745 EC 03000000 MOV [LOCAL.5],3
//00401205 |. C745 F0 05000000 MOV [LOCAL.4],5
//0040120C |. C745 F4 07000000 MOV [LOCAL.3],7
//00401213 |. C745 F8 09000000 MOV [LOCAL.2],9
$loadevenodd = {895D ?? C745 ?? 02000000 C745 ?? 04000000 C745 ?? 06000000 C745 ?? 08000000 8945 ?? C745 ?? 03000000 C745 ?? 05000000 C745 ?? 07000000 C745 ?? 09000000}
//.text:0040136E ; 22: if ( v4 )
//.text:0040136E 83 7D E0 00 cmp [ebp+var_20],
//.text:00401372 74 1F jz short loc_401393
//.text:00401374 ; 24: v6 *= 2;
//.text:00401374 8B 45 F8 mov eax, [ebp+var_8]
//.text:00401377 D1 E0 shl eax, 1
//.text:00401379 89 45 F8 mov [ebp+var_8], eax
//.text:0040137C ; 25: if ( (signed int)v6 > 9 )
//.text:0040137C 83 7D F8 09 cmp [ebp+var_8], 9
//.text:00401380 7E 11 jle short loc_401393
//.text:00401382 ; 26: v6 = (signed int)v6 % 10+ 1;
//.text:00401382 8B 45 F8 mov eax, [ebp+var_8]
//.text:00401385 99 cdq
//.text:00401386 B9 0A 00 00 00 mov ecx, 0Ah
//.text:0040138B F7 F9 idiv ecx
//.text:0040138D 83 C2 01 add edx, 1
//.text:00401390 89 55 F8 mov [ebp+var_8], edx
//.text:00401393 ; 28: v4 = v4 == 0;
//.text:00401393 loc_401393: CODE XREF: //.text:00401393 sub_4012D0+B0j
//.text:00401393 33 C0 xor eax, eax
//.text:00401395 83 7D E0 00 cmp [ebp+var_20], 0
//.text:00401399 0F 94 C0 setz al
//.text:0040139C 89 45 E0 mov [ebp+var_20], eax
//.text:0040139F ; 29: v3 += v6;
//.text:0040139F 8B 45 D4 mov eax, [ebp+var_2C]
//.text:004013A2 03 45 F8 add eax, [ebp+var_8]
//.text:004013A5 89 45 D4 mov [ebp+var_2C], eax
//.text:004013A8 EB 8C jmp short loc_401336
//.text:004013AA ; 31: result = v3 % 10 == 0;
//.text:004013AA loc_4013AA: ; //.text:004013AA 8B 45 D4 mov eax, [ebp+var_2C]
//.text:004013AD 99 cdq
//.text:004013AE B9 0A 00 00 00 mov ecx, 10
//.text:004013B3 F7 F9 idiv ecx
//.text:004013B5 F7 DA neg edx
//.text:004013B7 1B D2 sbb edx, edx
//.text:004013B9 42 inc edx
//.text:004013BA 8B C2 mov eax, edx
//.text:004013BC ; 42: return result;
$blackpos = {83 7D E0 00 74 1F 8B 45 F8 D1 E0 89 45 F8 83 7D F8 09 7E 11 8B 45 F8 99 B9 0A 00 00 00 F7 F9 83 C2 01 89 55 F8 33 C0 83 7D E0 00 0F 94 C0 89 45 E0 8B 45 D4 03 45 F8 89 45 D4 EB 8C 8B 45 D4 99 B9 0A 00 00 00 F7 F9 F7 DA 1B D2 42 8B C2}
any of them

Comparing the Algorithms

Now that we know how to detect this new malware, let’s look at how it differs from past Point of Sale malware samples. In many cases Point of Sale malware has used a variant of Luhn’s algorithm. Understanding the different ways that this algorithm is implemented can help us differentiate between families of malware. Taking a look at a classic Luhn’s would yield the following code (in C++)

int confirm( const char *id)
bool is_odd_dgt = true;
int s = 0;
const char *cp;

for(cp=id; *cp; cp++);
while(cp > id) {
int k = toInt(*cp);
if (is_odd_dgt) {
s += k;
else {
s += (k!=9)? (2*k)%9 : 9;
is_odd_dgt = !is_odd_dgt;
return 0 == s%10;

Now let’s compare this to the MEMLOG.A malware. For MEMLOG.A the following function stands out.

BlackPOS POS Malware

In classic Luhn’s implementation logic is used to keep track of odd and even numbers. In the MEMLOG.A implementation a lookup table is used to track odd and even numbers. This is a stylistic difference that is significant in determining the origin of each piece of malware.

Translating the MEMLOG.A implementation into pseudo-code will show the following

v1 = 0;
v6 = 0;
v7 = 2;
v8 = 4;
v9 = 6;
v10 = 8;
v11 = 1;
v12 = 3;
v13 = 5;
v14 = 7;
v15 = 9;
v2 = 1;
v3 = strlen(a1);
while ( v3 ) {
v4 = a1[v3] – 48;
if ( !v2 )
v4 = *(&v6; + v4);
v1 += v4;
v2 = v2 == 0;
return v1 % 10 == 0;

Comparing the MEMLOG.A pseudo-code to pseudo-code from the BlackPOS samples found in Target, shows us that these are two very different implementations.

int __cdecl sub_4012D0(char *a1)
int result; // eax@2
char v2; // [sp+Ch] [bp-F0h]@1
int v3; // [sp+D0h] [bp-2Ch]@6
int v4; // [sp+DCh] [bp-20h]@6
size_t i; // [sp+E8h] [bp-14h]@6
size_t v6; // [sp+F4h] [bp-8h]@3
memset(&v2;, 0xCCu, 0xF0u);
if ( a1 )
v6 = strlen(a1);
if ( (signed int)v6 >= 13 && (signed int)v6 <= 19 )
v4 = 0;
v3 = 0;
for ( i = v6 – 1; (signed int)i > -1; –i )
if ( !isdigit(a1[i]) )
return 0;
v6 = a1[i] – 48;
if ( v4 )
v6 *= 2;
if ( (signed int)v6 > 9 )
v6 = (signed int)v6 % 10 + 1;
v4 = v4 == 0;
v3 += v6;
result = v3 % 10 == 0;
result = 0;
result = 0;
return result;

The BlackPOS sample would align more with a close (classic) implementation of Luhn’s. Our MEMLOG.A sample is using the idea of Luhn’s with a different implementation.

While this is just one small piece of the functionality of these two families of malware, it helps highlight the differences both stylistically and functionally.

Chasing these algorithms will help in tracking the different evolutions of this malware (and algorithm) over time. By pulling indicators of longevity like this algorithm from known malware, we can push that defense out to our clients. Now they’re protected against what hit Home Depot and any other variant that follows.

Related Articles:

Equifax: A Case Study in Vulnerability Management

Three steps to enhancing security solutions