We've just completed our participation at the RSA Conference in San Francisco--our 7th year as exhibitor! We hope to give an update here of what's been happening at Armorize. It’s been 16 month since we've blogged. We've been too busy--there are many new partners and customers to support, many new threats to analyze, and many new technologies to develop--and this all makes spending time on the blog seem an unjustifiable luxury. We hope to resume blogging in a couple of months, but meanwhile, this blog post will serve as an update of what we've been working on in the past 16 months. In summary, we've been busy with:
- Expanding our engineering and operations team, and arranging for for their advanced training and certification.
- Developing and finalizing the HackAlert V5 API, and working on the HackAlert V6 API, which is to be released in 3Q of this year.
- Expanding HackAlert V5 API to incorporate support for APT (advanced persistent threat) detection and AFRM- (Armorize Fornsics and Reporting Methodology) based reporting.
- Developing and finalizing CodeSecure V5, and planning for CodeSecure V6.
Regarding 1), R&D expansion:
We've been expanding our engineering team and would like to congratulate the 35 colleagues who's recently passed their EC-Council Certified Ethical Hacker's certification: Adam Wei (ECC974360), Ain Chang (ECC974345), Alex Ruan (ECC974342), Allan Ku (ECC971799), Angus Wei (ECC974359), Aryan Chen (ECC974344), Carol Ru (ECC974341), Cyndi Wei (ECC974340), Eddie Chou (ECC974362), Eric Liu (ECC971746), Fred Tai (ECC971717), Hsuan Wang (ECC974346), Hyman Pan (ECC971733), Jasmine Chen (ECC974343), Jason Yang (ECC971702), Jeff Lee (ECC971815), Jimmy Huang (ECC974354), Joe Chang (ECC974361), Jordan Forssman, Lance Chang (ECC971730), In-Yee Lee (ECC971736), Mars Fu (ECC971756), Martin Chen (ECC971707), Matt Huang (ECC974356), Max Hsu (ECC974353), Michelle Juan (ECC974363), Paul Chen (ECC974358), Robin Huang (ECC971724), Roger Wang (ECC971813), Susan Chiu (ECC974347), Tom Kao (ECC971805), Van Cheng (ECC974357), Wayne Huang (ECC971814), and Wilson Chiou (ECC971812).
Continuous technical training is critical for us, and we've found training coupled with certification makes an effective combination. Next target will be CISSP and ECSP.
Regarding (2), the HackAlert V5 API:
The V3 API was first released in 2009 and is now both mature and robust. Based upon our experience operating the V3 service, we developed several generations of the HackAlert API, leveraging various new big data technologies. We released the HackAlert V4 API in 2010, which focused at providing our malvertising scanning platform. This time at RSA 2013, we released the HackAlert V5 API. Developed completely from the ground up around the latest methodologies for scalability, V5 is extremely scalable and fault tolerant, capable of handling a partner as big as Google. It also comes with an entirely new generation of malware and malvertising detection engines built from scratch starting in late 2011. This provides improved detection accuracy and coverage, as well as very detailed incident traceback reporting that precisely describes an incident’s origin, the areas of impact, and the final attack point. V3 and V4 servers, and consequently their API, are approaching their end of product life cycle. Starting from Nov 1st, 2012, new partners will not be offered an option to use either V3 or V4. We are working with existing partners now to help them migrate to HackAlert V5.
The V3 API was first released in 2009 and is now both mature and robust. Based upon our experience operating the V3 service, we developed several generations of the HackAlert API, leveraging various new big data technologies. We released the HackAlert V4 API in 2010, which focused at providing our malvertising scanning platform. This time at RSA 2013, we released the HackAlert V5 API. Developed completely from the ground up around the latest methodologies for scalability, V5 is extremely scalable and fault tolerant, capable of handling a partner as big as Google. It also comes with an entirely new generation of malware and malvertising detection engines built from scratch starting in late 2011. This provides improved detection accuracy and coverage, as well as very detailed incident traceback reporting that precisely describes an incident’s origin, the areas of impact, and the final attack point. V3 and V4 servers, and consequently their API, are approaching their end of product life cycle. Starting from Nov 1st, 2012, new partners will not be offered an option to use either V3 or V4. We are working with existing partners now to help them migrate to HackAlert V5.
Regarding (3), APT and AFRM-based reports:
AFRM-based reporting is an important new feature of the HackAlert V5 API. For every scan you submit to the HackAlert service (ex: online ad, URL, malware, document exploit), you will get a detailed, aggregated forensics report, laid out according to the Armorize Forensics Reporting Methodology (AFRM). AFRM enables you to easily comprehend the returned forensics data, and to use it for your own further analysis. AFRM reports include:
- Scene details (eg., URL, ad tag, PDF document).
- Aggregated interpretations (eg., “malicious”, “blacklisted”).
- Aggregated proofs (eg., “drive-by download”, “registry modification”, “process injection”). Proofs provide support for interpretations.
- Aggregated exhibits (eg., code snippet of shellcode, code snippet of exploit code, code snippet of HTTP responses, parameters of API calls, sections of binary files). Exhibits are sections of evidences that provide support for proofs.
- Aggregated evidences (eg., HTTP response, API calls, binary files).
- Evidence correlations (eg., Javascript 1 (Exhibit A) --> document.write (Exhibit B) --> Javascript 2 (Exhibit C) --> Load iframe 3 (Exhibit D)).
Exploit-Based Malware Infections
To explain AFRM, we first take a look at the exploit-based malware infection (EBMI) process, which is a widely used attack vector in Advanced Persistent Threats (APT). In EBMI, the victim is infected via opening a malicious document, often referred to as a document exploit. Common document exploit formats used in EBMI include Web pages, PDF files, Word files, Powerpoint files, Excel files, and Flash files embedded inside one of the previous types.
Phase 1: Exploit delivery and shellcode execution
During EBMI phase 1, the victim opens a document via a (document) renderer–defined as a software program that displays the document. Common (document, renderer) pairs include: (Web page, Web browser), (Web page containing flash, Web browser with flash support or plug-in), (Web page containing Java applets, Web browser with applet support / JRE), (PDF document, PDF reader), (Word document, MS Word), (Excel document, MS Excel), (Powerpoint document, MS Powerpoint), etc.
The document here, being malicious, is referred to as a document exploit. It contains mechanisms to exploit vulnerabilities either directly inside the renderer itself, or inside one of the renderer’s installed plug-ins (eg., Flash, Java applet, Real player, etc). If the exploited vulnerability is unknown to the renderer provider (vendor), then it is called a 0-day exploit.
This exploitation code (the exploit) is often implemented using scripting languages (eg., Javascript, Actionscript, VBScript, VBA) Two key factors make scripting languages extremely useful for this purpose: a) they provide the functionality needed to exploit the targeted vulnerability and b) being interpreted languages, it is very easy to obfuscate the exploitation code, thus making detection difficult.
Common (renderer, scripting language) pairs include (Web browsers, Javascript), (Flash, Actionscript), (PDF, JScript), (Office documents, VBA macros). Note that Javascript, Actionscript, and JScript are all ECMA-based scripting languages.
The following attacks leverage an EBMI process: a) drive-by download attacks, b) malvertising attacks, c) URL-based email attacks, and d) attachment-based email attacks. In (a) (b) and (c), the browser ultimately loads a Web page served by an exploit pack, which serves polymorphic Web-page exploits. The server that hosts the exploit pack is called the exploit server, and the involved URLs are called the exploit URLs.
Phase 2: Malware execution
When a document exploit is opened and upon successful exploitation, a dropper is often created on disk and executed. The dropper can either be the actual malware, or it can be just a tiny executable whose sole job is to download the actual malware over Internet.
In order to permanently infect the compromised system, the malware will often a) move itself to permanent disk locations and b) modify system configuration (eg., registry settings) so as to be auto executed upon every system startup. In order to hide itself from security checkers and users, the malware will often a) rename itself to seemingly legitimate filenames or b) arrange for alternative, less detectable and higher-privileged methods of execution, for example, using process injection.
Once permanently installed, the malware will typically start to a) connect back home to the command-and-control (CNC) server, or to b) send the collected information back to the attacker.
Using the HackAlert V5 API, you will not only be able to detect EBMI, but also receive detailed forensics reports on exactly what had happened during the two EBMI phases.
CodeSecure V5 offers better performance, accuracy, and language support over CodeSecure V4. Last year, I manged to convince six of my university classmates and roommates to quit their excellent jobs and join Armorize. Among them, Martin Chen now oversees CodeSecure's development. He's written an entirely separate blog and we'll be putting it up very soon.
Read more (rest of article)...
Share this: | 
|
Posts
