New malware invokes label "cyber weapon"

New malware invokes label "cyber weapon"

A report from the BBC News online technology section ( http://www.bbc.com/news/technology-18238326 ) highlighted the discovery by Kaspersky Labs of a new malware called 'Flame' and said to be a highly complex virus.

Of particular interest to me was the following taxonomy of attackers set out in the comments of Kaspersky's chief malware expert Vitaly Kamluk:  "Currently there are three known classes of players who develop malware and spyware: hacktivists, cybercriminals and nation states.

Back in 1998 I ran a series of reports published in FEN (Forensic Expert News) into Smart Card Hacking, which was before the successful 1998 attack on GSM SIM Cards ( http://trewmte.blogspot.co.uk/2007/08/cloning-gsm-sim-card-report.html ).

In the FEN Report Part 1 (images of original below) I referred to the following taxonomy of attackers with reference to its source:

"One of the few recent articles that discuss the subject describes the design of the current range of IBM products and proposes the following taxonomy of attackers [ADD+91]:

" Class I (clever outsiders):
They are often very intelligent but may have insufficient knowledge of the system. They may have access to only moderately sophisticated equipment. They often try to take advantage of an existing weakness in thesystem, rather than try to create one.
 

" Class II (knowledgeable insiders):
They have substantial specialised technical education and experience. They have varying degrees of understanding of parts of the system but potential access to most of it. They often have highly sophisticated tools and instruments for analysis.
 

" Class III (funded organisations):
They are able to assemble teams of specialists with related and complementary skills backed by great funding resources. They are capable of in-depth analysis of the system, designing sophisticated attacks, and using the most advanced analysis tools. They may use Class II adversaries as part of the attack team."

[ADD+911] DG Abraham, GM Dolan, GP Double, JV Stevens,  "Transaction Security System", in IBM Systems Journal v 30 no 2 (1991) pp 206-229

I thought I would comment on this taxomony of attackers first published in 1991 so that researchers can have traceability back to information that tends to get airbrushed from history in the course of re-invention of newly labelled threats.

  

Background material

A copy of FEN Index ref: UPD 5/1-Vol1-FEN98 is available upon request (trewmte@gmail.com).

 

Previous discussions about Cybercrime:

http://trewmte.blogspot.co.uk/2011/10/cybercrime-really-its-ict-crime-by-any.html

http://trewmte.blogspot.co.uk/2011/09/cybercrime-procedures-deterrent-and.html

http://trewmte.blogspot.co.uk/2011/08/research-critiques-of-author.html

http://trewmte.blogspot.co.uk/2010/11/cyberbullying-report.html

http://trewmte.blogspot.co.uk/2010/10/cyber-what.html

Trace Log Generator

Trace Log Generator

I am looking into creating a new handset tool that generates a trace log of commands sent to the handset and responses received.

Quite a few times I have raised this and largely there is a stone-wall silence about why examiners 'cannot' or 'will not' provide the actual trace log associated with their examination, so that this can be checked. That is an unhealthy taboo to be active in forensics (and for evidence) and needs to be side-stepped.

The idea of the trace log that produces units of information and exported for consideration is similar to that generated by some imaging tools, which allow, as complete as possible, an examination.

This tool I believe should not compete with current tools in the same way that they perform, but the trace log should be inexpensive as the generated file will be a trace log, secured in such a manner that the original should not be altered by accident and when an examination takes place should avoid accidental contamination of the original. However, the managed principle extraction technique is based upon starting at binary and working upwards in order to allow the data to be viewed through independent products.

Additionally, I expect the trace log generator to perform tracing on a make-by-make basis, which means there should be a trace log generator module for each make. This will allow examiners to only buy what they need as opposed to have the reading capability of X-makes/models where it is an extremely low probability of examiners coming into contact with them.

There is a list of benefits but I suspect two key objectives that will benefit in the mobile forensics industry

1) Those whose job requirement limits them to push-button selection for reading an exhibit can produce the trace log first and then use another tool

2) Those who are experienced can use the trace log without needing to hector the less experienced to qualify what they have done during the acquistion examination period.

Additionally, I also envisage some form of (self)employment to arise out of this where programmers can create modules within the framework of the trace log generator and share in the revenue generation stream and at the same time see their contribution in a product generated by and for the forensic community.

I liked to know what you think?

Evidence is one thing, Understanding is another

Evidence is one thing, Understanding is another

I like Nokia. They were in at the beginning and presented the World with options, and so many walked behind, in their footsteps.  The Nokia 110 and 112 still hasn't stopped the examiner from seeing potential evidence:

Seeing through the eyes of experienced examiners:

Mobile phones - understanding their contribution to evidence.

GSM Cell Selection Process

There are many aspects of GSM that provide useful guidance to understand processes that are performed regarding cell selection. These processes provide useful background help for cell site analysis. There is discussion at this blog about C1 and C2, but here are some other processes that rarely get a mention:

C1    Normal Cell Selection   This is the process of initial cell selection, searching all RF channels.

C2    Stored List Cell Selection   This is the process of initial cell selection where BCCH carrier information (e.g. a BA list) for the selected PLMN is stored in the MS.

C3    Camped Normally   This is where the MS is camped on a cell of the registered PLMN and may be able to make and receive calls. (Whether or not the MS can make and receive calls depends on the state within the location registration process). The MS monitors received level and the system information and checks whether cell reselection is needed.

C4    Normal Cell Reselection   This is where the MS has determined that cell reselection is needed and an attempt is being made to reselect a new cell.

C5    Choose Cell   This is where the MS has returned to idle mode from "connected mode" and is choosing a suitable cell to camp on.

C6    Any Cell Selection   This is where the MS is unable to camp normally on any cell of the selected PLMN, or cannot obtain service because of certain responses to a location registration (LR) attempt. It is searching for a cell of any PLMN to camp on (so that emergency calls can be made and warning notifications can be received).

C7    Camped on any Cell   This is where the MS has camped on a cell irrespective of its PLMN identity, so that emergency calls can be made and warning notifications can be received.

C8    Any Cell Reselection   This is where the MS is attempting to reselect a cell, irrespective of PLMN identity.

C9    Choose Any Cell   This is where the MS is returning to idle mode, after having entered "connected mode" from the "camped on any cell" state to make an emergency call. It is attempting to find an acceptable cell to camp on.

Delete GPS Movements

Delete GPS Movements

I noticed an interesting app that promotes enhancing GPS location positioning using A-GPS where the app tweaks the accuracy of the results. Invariably, apps like these are generated to help users improve finding their whereabouts or where they have been. An app I am aware is GPS Status and Toolbox (https://play.google.com/store/apps/details?id=com.eclipsim.gpsstatus2) developed for Android and using the output positioning data for importing into Google Maps.

I noted in the install guide the app will delete cached GPS data:

Step 4
"Start the GPS Status and Toolbox app. Press the menu key to go to the tools menu and choose 'Manage A-GPS state' from the popped up menu."

Step 5

"After choosing 'Manage A-GPS', press the reset key to wipe out all the A-GPS data your phone must have collected. Switch off the smartphone and wait for the device to automatically gain data connectivity."

Should the app user do no more after Step 5 then the cached GPS data is lost. Clearly, there could be an evidential discovery issue here. Metadata already embedded in existing photos are unlikely to be affected.